[Leos] Leave the distributed IT support units where they are to continue providing localized services but have the heads of those units directly report to the director of ITS (or to a user services department head to oversee all the distributed service units who reports to the director of ITS). Combine all the localized helpdesks into one that then routes the calls to the appropriate units. Centralize, where practical, all of the distributed servers, DNS, etc.
[Me] We'll leave CIO discussion for another day, as I wrote yesterday.
- The kinds of centralized services Rob and Leos mention go along with what we've been discussing.
- To the extent possible, I'd like to see all servers that are connected to the network under the oversight of the infrastructure folks, with secure access provided, sort of on an ISP model, to the user support people and power users who need it.
- An alternate model for faculty/staff tech support:
- a faculty/staff support subunit, within User Services,
- localized support teams in that subunit.
- Version 0.5 had two subunits of User Services: faculty/staff support and classroom, lab and event support, with "cops on the beat" to provide localized support within those subunits.
- keep day-to-day support close to the user,
- let users know that they still have "their" techies,
- provide the opportunities for cross-fertilization, cross-training, career development, and adoption of best practices we need.
- Fitting in specialized services like training coordination and second-level A/V support.
- How best to provide localized support for Nursing and Biology, which are located away from the other Arts and Sciences departments.
- Providing extended hours of support.
- Providing backup when one team is swamped or short-handed.
- Newnan Center tech support.
4 comments:
What version do you envision containing the details of where individuals will be placed in the new organizational structure?
Who or what group will make those initial decisions?
How will he or she or they make those decisions?
When will those initial decisions be made?
I am concerned that as we go forward with the “human” part of this reorganization we are glossing over the “hardware” reorganization that will be required. In a lot of ways, the technical reorganization or centralization of enterprise services will be a more disruptive and time consuming task than the organizational reordering ever could be. Is it possible we are putting the cart before the horse? The more I think about it the more complicated it gets. We need teams of people to start matching servers and services that can be migrated or consolidated. We need to identify physical space requirements, power needs, environmental conditioning capacities, changes in network requirements, hard drive capacities, software version compatibilities, and so much more it makes my head hurt to think about. But think about it we must and the sooner the better. If we wait until January, we will have wasted the time between now and then. There are obvious services and applications that cry out as a starting point. Let’s get started.
Thank you, Rob, for pointing out the obvious that has been screaming out for attention! Can anyone imagine what a mess this is going to be? A quite unnecessary mess, that is. Rob said we're putting the cart before the horse, but it is far more like the horse will be shot and the assumption will be that cart will still be as functional as it was, and the end users will be none the wiser. However, I do believe the driver of that cart will abandon ship and the mess will continue to worsen.
Interesting to know.
Post a Comment