Posted: Fri Feb 21, 2014 5:48 am Post subject: Outsourced application management with ITIL - basics..
I work at an it System Integrator company doing traditional on-premises sales and implementation of complex ERP applications. I am tasked with building an organization providing end client support/application management after go live and doing so with reasonable adherence to ITIL, with the value proposition based on predictable cost and result to the client. As I am a novice to this, please forgive me and spare yourself the time if you’re frustrated by newbie questions.
I’ve got some trouble getting to grips with the framework and how it applies to this situation and would appreciate any advice. Here’s a few things I’ve had a hard time wrapping my head around. First, consider this:
- We are not selling Software as a Service. The ownership remains with the client. What I am offering could be called outsourcing of ITSM processes. Thus, the traditional ITIL examples of “Printing” as a service do not directly apply. The “service” that I am providing is ITSM/Service Delivery.
- I still want to be able to package the offerings within a client specific SLA, which could include the following “services” (yes I know they’re a mixup of processes, process outcomes and a function). There will be more, these are examples.
— Version upgrade: we’ll keep you on the latest versions, fixed yearly fee, no later than x months after SW vendor release
— Change management: we’ll do perfective/adaptive changes/adaptations, TM billed, with a SLA’d initiation time (i.e. development starts x days after approved requirements)
— Incident/Problem management executed through a service desk. We’ll even do user support for “I don’t know how to do this” cases (TM or per call billed, while “real incidents” may be fixed fee). Yearly fee for us even answering the phone.
— Service Request fulfillment with SLA’d response time for a number of predefined service procedures
My rather vague questions are as follows:
— If these offerings, which will be items in an SLA, can’t be called “Services”, then what would I call them? I suppose this is a common situation/question?
— What are the individual procedures executed as a result of a “request for service” called? Services?
— If an incident turns out (as it does more than half the time) to be a user error or data error, I do not want to simply reject and close. Most times this is not known until after investigation (remember, complex application and processes). I need to “restore service” by kindly assisting the user. This has value to my customers and is an important part of the offering. Sometimes, the user may even know that it is not an incident but a support request, but I still want to provide that. What would be the most appropriate way of labeling this? I believe I can execute through the Incident Management process, but would that be sacrilegious?
— Or should the “fake incident” remain an incident of the type “User error”?
— Or is the “fake incident” a Request for Service of type “ad hoc user assistance” ?
-- Or is it a problem, as I need to teach the user how to do what he needs to do himself the next time, thus preventing incident recurrence?
— Or is this something ITIL doesn’t even want to deal with as what I am doing is really a help desk?
If anybody has been in a similar setup, I’d be very interested in talking to you
Joined: Sep 16, 2006 Posts: 3350 Location: London, UK
Posted: Fri Feb 21, 2014 8:04 am Post subject:
Change your focus is the first thing
IT Service Management is what you are doing.
Use the following to assist in the definition - CoBIT, ISO20000, ISO27001, ISO9000/9001, ITIL, CMMi, (Development practices as well - Agile, SCRUM, DevOps)
What are you going to be is a application support vendor.
So you are either supporting the out of the box application, the customized version, or both.
So your customer will have the following
Application process faults - the form or module does not do what it is suppose to do
Application data faults - the details entered did not come out correctly
Application run time faults - application code failures where the fault is the core code not the customizable (customer)
Application configuration errors
Application performance issues
Operating System faults
So with the above, the reaction is one of the following
1 - develop a application custom code fix
2 - develop a application data fix
3 - request a vendor patch
4 - do nothing as it out of scope of your responsibility and return the issue to the customer (vendor)
Please update and I will continue. I have been involved in what you are asking for the past 5 years _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Basically the reason behind most of the companies using Scrum is its efficiency the kind of outcome we get from it is superb.
Having knowledge about it can help a lot in managing the productivity in a good way and at the same time it has all those things that needs in making a product better in terms of the production.
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