I would approach it from a standpoint of who in your organization is going to take ownership of a particular function, and become the process manager for things that take place in that part of the application.
Our experience with ITSM 7.x is that it is sufficiently complex that you need one additional person in the Remedy shop to be the application administrator. They configure IT staff into companies, organizations, and support groups, with appropriate application permissions and licenses, as your IT organization changes/evolves/reorganizes and IT staff move between groups. If you implement multi-tenancy this becomes more complex since the support staff may reside in different companies in ITSM. This person also deals with all of the application configuration requests for approvals, service targets, categorizations, etc., and user questions of all kinds. They do NOT, however, own any of the processes. This position is in addition to the Remedy system administrator/developer (me) who deals with customizations, patches, upgrades, installs, and spends most of his/her time working on the next version of the system that will be placed into production. I have retained most of the control over SLM as well, since it creates actual workflow on the system and has the potential to bring the entire system to a crawl if someone starts building ill-advised service targets. Our central helpdesk manager "owns" Incident and Problem, although the 25+ distributed/central IT support areas "own" all of the equivalent activities within their support queues and customer organizations; some have separate helpdesk operations. The Remedy shop makes no attempt to manage their activities, other than to prevent problems that might affect the system or application. The helpdesk manager also "owns" Kinetic Request, a functional equivalent to Service Request Management. He develops new service items upon request from other IT support groups or his own helpdesk, tests them, organizes them into the appropriate service catalog permissions-wise, and implements them with almost no involvement of the Remedy group. He only comes to me if he needs a change to the integration between Kinetic Request and Incident Management. In a similar manner, our helpdesk central supervisor "owns" Remedy Knowledge Management. He develops and manages all of the content, acting as the knowledge architect for the enterprise, while also backing up the manager on all aspects of Incident and Problem Management. The two of them are also responsible for the online training material for use by other IT staff who must learn the application. We have offered Change Management to the central IT organization, but since they have not been able to come up with a Change Manager or group that is willing to act as such inside the ITSM application, we have not implemented it. It is a business process management function, not a technical function, although that person/group will have to become familiar with the Change and Release Management modules. Since they still prefer to piddle about with email groups and a sharepoint calendar, and I have no resource to dedicate to the task, I only use Change Management internally. We will have the same problem with Asset Management when we install it in 7.6.03 (we did not have a license for it for 7.0.02), in that we are not staffed to do this for the enterprise, nor is it our responsibility to do so, and even if we can acquire data through discovery there will be no one with the responsibility to keep it current. It probably does not help that we are located on the main campus with the helpdesk, not on the satellite campus with the central computing organization; we are not in a position to coordinate business processes for or with them on a daily, continuous basis. These are issues that are awaiting our future university CIO, and his/her boss the university system CIO; they are over my pay grade. So we get by with two people in the Remedy shop, but unless they want to add staff to my group we are in no position to take over the management of any IT _business_ processes. I would not recommend that you do so, either, unless your IT organization is so small and coherent that you are already doing some of these functions. In that case, you will need to add process managers with the authority to enforce those business practices. Make sure that your boss(es) understand that the processes have to be managed by someone with the authority to do it; just having the technology isn't enough. Sorry, I guess that turned into a bit of a rant. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Sanford, Claire Sent: Wednesday, November 03, 2010 2:48 PM To: [email protected] Subject: Re: ITSM 7.6.03 "resources" required ** I guess I was not clear enough.... we are talking about once the system is live... how many bodies will it need to support it and all the processes. The Upgrade/Migration build process we pretty much have covered. Do we need a process manager/architect for each of the applications? _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
