Joined: Feb 28, 2005 Posts: 6 Location: Minneapolis
Posted: Tue Mar 01, 2005 7:31 am Post subject: Tools - Tools - Tools
ITIL says you can implement with out a new tool.
We are a VERY large company and still use an old mainframe based green screen tool. At some point I feel the tool does need some integration with the areas of ITIL. Incident record - and automating that information into a Problem record with a link to the incident? We are also missing some the service delivery modules.
1. How can a company really implament ITIL without some automation and basic function of the tools?
2. I need to write proposal to look at tools and possibly justify something new. If you have gone thru this effort - do you have any helpful hints with a company that is not willing to spend a $1 million dollars on a tool.
We need hard dollars and not soft dollars for this justification. So my first effort is justify a study on replacing the tool.
Joined: Jan 23, 2005 Posts: 11 Location: Australia
Posted: Tue Mar 01, 2005 1:01 pm Post subject: Tools, Tools, Tools
You are correct it is very difficult for a large organisation to gain any efficiencies from Incident Management with just process change. However not impossible, if your current tool can be configured to support the new process. Based on your description of the tool this may be difficult unless you own the source code and are willing to spend a lot of dollars on re-developing the tool.
The best advice I could give you is to:
1. Re-design your Incident Management process
2. Identify the functional requirements of a supporting toolset
3. Review your current toolset for its capability to support the requirements (based on the outcome you may need to go to the market)
4. Introduce a level of process change to streamline and improve your current operation - including appropriate prioritisation of requests, standard templates for gathering information, assign an Incident Manager to monitor the process, undertake escalations, etc
5. Introduce the changed or new toolset and your new end-2-end incident management process
The good news is you don't need to spend a lot of money on a new toolset. There are some really competitive service management products in the market place which provide support for Incident, Problem, Change and Configuration Management - which should probably be your first focus. Monitoring tools, software packaging and deployment tools may already be in place to some degree and can be integrated with most service management products.
Some business justification for the introduction of a new toolset might include:
- Current legacy toolset has significant support costs to administer and maintain
- May not be supported by the vendor or supplier anymore
- Does not have an underlying configuration management database enabling the tracking of incidents or requests to specific items of infrastructure - proactive problem management
- Improve the operational efficiency of staff - ability to handle greater number of customer requests
- Improve the customer experience - consistency in process by support personnel, able to meet customer expectations
- Current system does not enable the relating of incidents, problems, known errors and changes
Some business improvements might include:
Improved customer satisfaction through:
o Improved responsiveness to customer incidents and requests
o Improved communication on the status of incidents and requests
o Consistency of process across all staff
o Reduction in the use of technical jargon.
Improved business and IT alignment through:
o Improved familiarity with customer needs and priorities
o A common process for incident management
o Consistent terms and definitions used by support staff.
Improved staff satisfaction through
o Alignment to a single incident management process
o Better communication and information sharing between support staff
Reduced cost of service provision through:
o Accurate and timely recording of activities associated with incident management
o Ability to accurately identify billable activities
o Improved responsiveness to incidents
o Improved knowledge management arising from incidents and problems.
Deliver value added services through:
o The ability to share incident management capabilities with other organisations (processes, tools, knowledge management)
o Reduction in the cost of general support services, ability to devote effort to new projects and services.
In order to define these for your organisation, take some metrics and identify what efficiencies you could gain from improving the performance of the process. Find out what drives your customers crazy and address these issues first up.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Sun Mar 13, 2005 3:55 pm Post subject:
Been there done that - twice - and Ouch!
ITIL (and ITIL consultants) de-emphasize the lets-buy-something-to-take-care-of-this-requirement approach (common in a lot of IT production shops) because of the obvious implementation gotcha: No matter how good your tool for automating processes is, you can't automate a process you don't already have.
That is one of the key reasons a tool-set oriented approach fails - and I've seen it fail.
I also think one of the key factors you need to consider is not how big a company is, but how complex and heterogeneous it's IT infrastructure and support processes are.
If you have a highly centralized shop, with a limited number of clearly definable services to the business, the tool set approach is safer: But the corollary to that is, it is less necessary. In such a context I would be looking as simple request logging and tracking software that was ITIL friendly (something in the "Heat" market segment). These are strictly buy and deploy products, that everyone can get their heads around quickly.
(Tip: If you have a feeling in your big toe that management are heading down the buy-our-way-to-ITIL-compliance road, and that there will be tears before bedtime - it is better for a smaller, less costly acquisition to fail. The lessons will be easier to digest, the recriminations less career shattering, and you might get lucky and discovering the unsuitability of the tool-set approach will just be part of a stepwise learning process. Whereas a huge, expensive, time-consuming implementation that goes belly-up because it was ill-conceived from day one, is a whole world of pain for every one involved.)
If you have a large and complicated shop, then an industrial strength tool is going to be required somewhere along the way, and you are looking at the likes of HP's Service Desk, CA's UniCentre, or BMC's (Remedy) ITSM suite, among others.
These should not be approached as 'products' - ie., as a matrix of features and purchasing costs. The trick at this level is, the more you really need one of these, the less likely there are going to work "Out of the Box". You are going to face some heavy customization issues. And to assess this well you need to differentiate and rate:
1) The flexibility of your own process and staff (including the IT org chart),
2) The flexibility of the product under examination (ie - how much flexibility is embedded in standard admin and configuration, and how much in coding work)
Because you will need to assess the gap between your organization and the OTB state of the product, and decide what the best path to alignment between the two is.
1) You are buying a solution to a business problem - part product, and part services from the vendor. I agree with Tania's response - assessing the business value is essential.
2) The services component - consultancy and customization work - is the most-likely source of a cost-blowout (be prepared).
3) Don't just tell the vendors the features you want - or the ITIL capabilities you require - they love this because they can quite honestly say 'yes' to every one.
4) Present your business (the IT shop) to them and assess how accurately they understand it, and how well they communicated that understanding back to you.
If they can't talk to you about your own stuff in a way you can readily understand (low on jargon, high on insight) then the relationship is doomed to be rocky,
5) See if you can identify one or two limited "case studies" from your own operations, that reflect a point where your way of doing things does diverge from the OTB assumptions of a product, and where the product will need to be aligned rather than the process (for what ever reason - cost, politics, legal, available in-house skills, etc.) - give them sample data, and scenarios, and ask them to present a working proof-of-concept of the product's/consultancy team's, customization capability - with a report on how long it took, how much they would have charged, and samples of everything they would have handed back to you - especially documentation. If they want to charge you for this, try and find the money - the long term savings from making the right choice will more than pay for it.
I can't offer any suggestions on price because with these products the cost will depend on the number of staff that need to use them on a daily basis, (and I'm not in the US), but in AUD a full Service Support and Service Level Management package with customizations for say around 75 to 100 high-need users of the system - plus portal access for a very large end-user base - would be between 100K (squeezing every penny) and 250K.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum