Outsourced application management with ITIL - basics..

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
Posts: 1
Joined: Wed Feb 19, 2014 7:00 pm

Thu Feb 20, 2014 2:48 pm

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 :-)

Thanks a lot

User avatar
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Thu Feb 20, 2014 5:04 pm

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
User avatar
Posts: 9
Joined: Wed May 21, 2014 8:00 pm

Thu May 22, 2014 3:59 am

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.
Post Reply