Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design 4.2.4.3 says:

Supporting services IT services that support or ‘underpin’ the customer-facing services.  These are typically invisible to the customer… such as infrastructure services, network services, application services or technical services.

Yet the in the prior section 4.2.4.2, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit

itSMF Regional Seminars: Where Speed Dating meets Networking?!

Speed Dating meets Networking?

When I went to my first itSMF Regional Seminar last month, I never would have believed that I would be putting those words together!

The event (hosted by Attenda for the London and South East region) was focussed on End to End Service Management, as well as that all important networking element.

According to outgoing Chair Jane Suter, their last attempts hadn’t been quite as successful, revolving around groups moving from room to room.  However, on arrival, we were handed slips of paper with what looked like safe-combinations on them, and corresponding numbers were dotted about the venue, the idea being that at the various breakouts, we proceeded to the relevant number on the list to meet with like minded numbers!

This worked really well until we got to lunch time when we actually missed out one session altogether and the feedback session for the last one took a while – but it was actually a very valuable session.

I suggested that they should build in the time to do more detailed feedback, because after each presentation, and then each networking session, we were encouraged to look at the subject matter and incorporate those into our introductions.

I’m sure it’s an approach that has been done before, but was a pretty effective mechanism and a good icebreaker, especially for a few of us who were first-timers at these events.

The Role of the new CIO in an End-to-End Service Management Environment – Mark Fowle, Attenda

This was a well presented and well thought out presentation, not pitching Attenda, but putting forward their perspective based on their customer base.

The presentation focused on how the IT Director role was perhaps drifting away and being replaced with that of a Chief Information Officer as a key contributor – moving away from pure technical focus and looking to solve business problems.

When I put this in context with a CIO pitch a week later at the itSMF UK Software Tools Forum in Manchester – the focus of is very much on achieving business outcomes, setting and achieving meaningful Key Performance Indicators (KPIs).

Enforcing Service Management practices through interoperable systems – Neil Forster, Attenda

Neil’s time was perhaps a little shorter than he had intended, as he ran us through how Attenda put a management layer over the top of their third party tools to provide them with platform to get information to their engineers, when they need it.

Neil focused in three key areas – Event Management, Incident Problem and Change Management, and Service Knowledge Management

They have developed mechanisms to have their engineers check for likely “best bet” matching tickets, and with links to knowledge based articles approved by team leads.

His key message was the presentation of information at the point of need, as well as embedding knowledge in the process.

Service Management in an Agile/SOA environment.

The final speaker of the day was Graham Youngs, from Tata Consulting Services –I had been on the periphery of an Agile-run software development project for an ITSM deployment and until that project the only scrum I had heard of had everything to do with Rugby Union and nothing at all to do with ITSM!

In fact what it focusses on is speed of change versus quality of service, and what I could draw from my own experiences was that a good Agile project manager is as much a key to a development team’s success.

In my own experience, although there were attempts to break down the barriers between development and operations, it still needed flexibility and a firm hand from the agile/development management side to keep members of the team focused on their immediate role as well as the bigger picture.

Overall impressions

  • Highlights

A friendly environment and easy to network thanks to the “speed dating approach”

  • Things to improve

The structure of the networking breakouts were relevant to the day’s theme and I think that they should allow some feedback time on the sessions as the group become very interactive at that point, making the seminar worthwhile.

Asset Automation Brings Harmonious Orchestration

Bob Janssen, CTO, RES Software "IT must look at better ways of managing IT through innovative approaches to automation and orchestration"

RES Software chief technology offer Bob Janssen says that IT management is being pushed in different directions, so how can we steady stage and make sure we’re all singing from the same song-sheet?

The facts are simple, businesses want more information for decision-making and insight into customers, while individual users are accessing applications and working on more devices from smartphones and tablets to laptops and the traditional desktop. At the same time, IT has to provide better services to users across all these devices, which means new challenges and more platforms to support with the same level of resources.

It’s a cacophony of service management sound

To keep up with the demands of users and support business objectives, IT must look at better ways of managing IT through innovative approaches to automation and orchestration.

How do we speed up the IT production line?

For the IT team, there is the constant challenge of completing new projects, like migrating to Windows 7 or rolling out new applications to the business, all against the backdrop of tightening budgets and shrinking staffs. The natural response to this is to cut down on manual intervention wherever possible by automating IT management.

From an IT service management (ITSM) perspective, automation can deliver more benefits to the business. Responses to typical IT problems like application upgrades or operating system migrations can be automated, so users can get the best experience without demanding direct intervention from the IT team.

For companies looking at IT automation, the main benefit is that they can improve internal processes and reduce the manual effort required of common, recurring tasks. Their emphasis (in a perfect world) should be on making everything run properly the first time around and cutting the time spent on tasks in the future.

The end result should be:

  • less time spent delivering patches,
  • less time spent updating desktops,
  • less time spent migrating operating systems,
  • less time needed for other day-to-day tasks.

There are other benefits too: automated processes can be done uniformly across all machines, reducing potential for error and improving reliability. Plus, time saved through automation can help keep costs lower, while maintaining service quality.

After automation comes service orchestration

The next step after automation is to take a fresh look at service orchestration. At first glance, this may seem similar to IT automation: it is aimed at making the mechanics of a process run smoothly, with minimal human intervention. In fact, service orchestration is something bigger: it looks at how IT-related processes interact with the other business functions and assets engaged with the same processes. This means that a project undertaken by IT may actually enable IT to deliver value to the larger organization – not just to IT.

The aim of service orchestration is to apply the potential of IT automation to common business tasks. Again, the end result should be a smoother process for end-users, and more efficient results for the business. Plus it will involve interaction with those business units in order to be successful. Orchestration also goes further into aligning IT with business activities, ensuring that IT continues to deliver better service and support to the organisation as a whole.

Organising onboarding

A prime example of service orchestration is around onboarding: new users entering an organisation.

Certainly new employees must be provided with the right level of access to IT resources, applications and data; but how this is achieved can tell you a lot about how the organisation approaches IT management – and ITSM in particular.

Here’s a typical scenario:

The new employee is provided with a desktop or laptop to work on, and the necessary applications are either installed on that machine or delivered to that machine as a service. Finally, the user is set up in Active Directory and granted role-based access rights and permissions, as well as access to printers and shared drives.

In most environments, these interactions are manual: the IT staff adds the employee to the right domains, provides the appropriate permissions, installs applications, and sources the desktop or laptop. Documenting the employee’s resource requirements, securing the necessary approvals, and implementing those resources can take at least many hours – and quite often days. But service orchestration can drastically reduce this time by automating the process. Also, the new employee’s business unit – which is already specifying the employee’s unique resource and access requirements – can be given more control over delivering the employee’s new technology.

Instead of relying on the traditional “heavy lifting” approach of person-to-person interaction between IT staff and the rest of the business, an IT service can be set up to automate this interaction. For example, an HR application can be used to define each new employee’s application and data access privileges based on his or her job description and seniority level.

A task that can take hours and engage multiple staff resources is reduced to minutes, with little to no “hands on” interaction. Investing the time up-front to set up this capability can save enormous amounts of time longer term, as the new IT services can then be applied to every new employee at every level. It also reduces human interaction, and the possibility of time consuming error.

The service orchestration score

Service orchestration provides more opportunities for improving service delivery throughout an employee’s lifecycle within the business through service catalogues and self-service portals. Based on ITIL guidance, building up a service catalogue makes it easier for IT to provide a list of relevant IT services in one place for users to access.

But service orchestration can take this one stage further, by automating deployment of business processes. Approval processes and permissions can be built into the service orchestration process to ensure that managers within the organisation maintain proper levels of control.

A working example:

For example, password resets and printer access tasks – which often make up the bulk of service desk calls – can be automated. Doing so not only makes life easier for the IT team, it helps employees return to productivity more rapidly as well.

What does the future hold for IT?

At the heart of automation and service orchestration is the recognition that human time and effort is an expensive approach to managing IT. By automating IT management where possible, it frees up time that would otherwise be spent on low-value tasks that “keep the lights on”, and instead let IT concentrate on how those assets are used to create value for individuals and for the business as a whole.

For those in charge of IT, whether they are responsible for overall budget spend or for keeping desktops running day-to-day, this change represents a big shift. Instead of being solely a back-office function, IT has to step into the limelight and be part of wider business projects from the start.

It also links into changing how companies think about their IT assets from the start: rather than being static assets that remain the same for years, these applications and services can change rapidly depending on what endpoint a user is on, whether they are mobile or office-based, and how their job differs depending on circumstances. All of these criteria can be changing at once for each user, so the ITAM function has to respond to this. Doing it manually represents a huge potential time-sink, so automation is the only way that it can be achieved cost-effectively.

Automation and orchestration is therefore a necessary investment for the future of IT management. As internal IT professionals, this level of control provides greater opportunities to improve service delivery, while it also offers more time to concentrate on where value can be created and delivered.

Bob Janssen is CTO for RES Software. He has spent over ten years establishing and growing RES Software in its mission to help customers with their desktop and IT management requirements.

Do SLAs hinder collaborative relationships with our supply chain?

Pretty much all outsourcing contracts in the IT Service Management world rely on, or at the very least, utilise the Service Level Agreement (SLA).

Certainly they are important as they are the physical representation of performance of the contracting party and used as the measure by which trends in supplier performance is understood.

But is there too much reliance on SLAs as a measure of performance and are they often inserted by the eager contract or procurement manager to mitigate risk or provide a means for the insertion of penalty / reward clauses because “that is what is expected in a contract”?

In my personal experience SLAs are often poorly defined or their alignment to the realities of IT service delivery misunderstood.  Because of that, there has been many mitigating circumstances offered as to why an SLA has been failed by the contracted organisation, followed with significant discussion as to whether the mitigation can be accepted.  This has a tendency to suck up both time, effort and therefore money, from both organisations into managing the performance measures, drafting contract change notices and often not looking at the root cause of why SLAs are being missed or in one case I have dealt with perpetually exceeded (plainly in that case the SLAs were too generous or measuring the wrong outcomes).

Problem 1

The vendor will look to win the opportunity and subsequently concern themselves with making the delivery side work (especially when the bid team is not going to be involved in delivery).  They will obviously try their utmost to meet the targets set, but also expect to provide mitigations in the event of failed SLAs.  They have the experience of dealing with a number of clients and so have reference points to support them, whereas the contracting organisation does not have the same level of experience or number of reference points.

A common resolution is the instigation of a continuous performance improvement plan, and when that has been met redrafting of workable SLAs agreed by both parties, or if it fails penalty clauses or litigation.

Problem 2

Poorly defined requirements from the customer.  Either they are unsure what they want, have over / under specified the level of service really needed, they are looking to outsource a problem, or the business units have been poorly engaged, if at all, by procurement through the tender process.  In such circumstances the supplier is almost being set up to fail from the outset (which from their experience they will probably realise) and therefore they will look to manage their way around the issues as they arise.

The common resolution is a redefinition of the SLAs probably with an element of contract renegotiation once the customer has determined the service it expects or requires.

So what should a good SLA really be about?  A well constructed SLA should be seen as an important measure to support a positive contractual relationship, it should also be periodically reviewed for its applicability in light of changing business demand.  However, the SLA should not replace or overshadow the development of the relationship between the customer and supplier.  Rather, the SLAs in place should support a collaborative attitude towards delivering a contract outcome that benefits both parties; the customer receives the service they need, the supplier makes the profit margin they expected and the customer is satisfied with.

Neither party should be wasting time and money negotiating mitigations, instead the time saved can be spent on delivering future value.  Unfortunately developing proper, mutually beneficial collaborative relationships in a business environment is not easy where customer and supplier aspirations are not aligned.

The "Fantasy" ITSM team

Who would be in your fantasy ITSM implementation team?

After years of experience deploying ITSM solutions in a variety of customers,  and in the midst of a major soccer tournament here in Europe which brings out the managerial expert in football-watching folk, I found myself musing on what would be my “Fantasy” ITSM team.

What is that seemingly mythical combination of team members that brings about either an aura of calm  or a maelstrom of chaos.

The ITSM Solution Architect

Quite often with fingers in various pies – a little project management here, a touch of subject-matter-expert (SME) there and a healthy dose of OCD in terms of getting Visio lines to snap to geometry.

You will typically work directly with customers, to understand what magic is required to get this Service Management tool malarkey to work.

And then – you find yourself stuck in the middle of a team trying to get processes and tools to live in harmony, so maybe add the role “politican” to your skill-set.

Size does NOT matter

No really – believe me, it does not where ITSM projects are concerned.

My most recent deployments have been as part of outsourcing projects – and even within those beasts of burden, the projects have ranged from the Service Management work-stream being a small part of a large outsourcing project, or a small group running as jacks-of-all-trades.

But there is one common denominator in all this – the need to dovetail the team’s efforts into reworking of the process with the development/customisation of the tool.

Potential Pitfalls

1) Don’t Make Me a Liar…

Process Implementation and Solution rests in two camps.  If you are lucky, the project will have a work-stream specifically for Service Management and the two areas can advance in lock step with each other.
And they NEED to.

The Process team has to know what the capabilities, and at times limitations, of the tool as they are redefining processes.

The worst case scenario here is that the earth is promised, yet for whatever reason the tool simply cannot deliver, leaving everyone looking a little foolish.

2) You can Have it all…

Of course the flip side of the coin is that you twist the tool to do anything you want, and add anything to the process.

That tends not to help much either, (see above re: foolish)

3) So Happy Together…

There are several ways, in my opinion, to bring the Process and Tool together, without uber-educating one individual to be a complete Service Manager, Process Implementation Manager, and Tool Subject Matter Expert!

(Mind you, just think what you could ask as a daily rate!)

  • A single work-stream which brings together the Service Management Processes and the tool implementation team together.
  • It requires a strong, knowledgeable Project Manager who can understand the technical, and process elements, but steps back and manages the project using those resources.
  • Collaboration between the members of the team – there is absolutely nothing wrong with a little skills cross-pollination.
  • It doesn’t hurt to herd Process folk towards the tool – yes I know, it’s horrible and it involves clicking and things, but it does bring to life those lovely diagrams you make!
  • Actually – it also doesn’t hurt for Solution Architects to perhaps get up closer and personal with some of the administration of a system so that they can combine brain-power with the Subject Matter Experts/developers from time to time

Is it ever possible to do things “turnkey”?

Now that IS a good question.

“Turnkey” is a phrase I heard all the live-long day on one project, where it was assumed that customers would just sign on the dotted line, leaving us to go and pretty much do what we wanted.

Once upon a time, maybe that could have been true, but not in the 20 odd years I have worked in the industry!

1) Requirements Gathering

No two customers ever have exactly the same business requirements.  But most companies will have developed decent sets of templates to drive out specific requirements – standardised questions and a repeatable approach helps here.

2) ITSM Solution

Ah, we architects LOVE our solution templates – plug in requirements and it might be useful to work out what belongs to Process, what are Organisational and whatever left is Tool.

THEN figure out what the tool does easily, what the contract says, and work out where your implementation headaches will b

3) Process

Here’s where we start to overlap.  Whether your tool solutions are high or detailed level, it is likely to start to cross some boundaries especially if the definitions for elements like Impact and Urgency need to be configured in the tool.

The solution needs to reflect the way the process has been written and the process needs to be implementable.

This cannot be done in isolation and also is likely to involve SMEs or developers for more fine tuning of the tool – do not leave them out of the equation.

4) Tool Implementation

The magic area where it all miraculously comes together!

Priorities, urgency, impact, fields, workflows, data loading… need I go on?

People wonder why Service Management deployments take a while!

Some things, of course, can be standardised,  for example supplying standard data loading templates, but sources of information will differ, and it is worth remembering that often the project will have to interact with groups who are maybe not directly involved with the ITSM project.

A fool with a tool… how to avoid that scenario!

There can never be a single person who possesses all the tools to make a Service Management Deployment a success – it has to be a team effort.

The best project managers have a degree of technical skill in Service Management, but can remove themselves from interfering in the technical detail.

The best process managers are actively involved with working alongside the implementation team and perhaps involved in developing testing material to aid that familiarisation.

The best teams have engaged service managers who have a vested interest in what is coming their way – all too often they are either the last people to be informed, or worse they feel they are too busy to give it the time – a recipe for disaster, every time.

The best architects understand at the very least the ITIL basics to hold their own in process/solution design discussions, and it is better still if they can hold their own in the more heated debates of “the book says” vs. “the tool does, in alignment with ITIL Best Practice

The best implementation teams have a good bond between architect and SME; often two heads can be better than one in getting darned pesky tickets to go where you want them to.

The nature of the deployment beast is that you may have some, but probably not all of your perfect team attributes but if enough of balance can be struck between the vital roles Process Implementation and Tool Implementation play during a deployment – then I think you are half way there.

Image credit

Back to Basics: Why DO the ITIL Foundation Certification?

I was actually asked this question recently by a former colleague working in the IT Asset Management arena, in the context of whether the certification would help them in terms of IT contracting.

I had to think long and hard about my answer, and having learned the hard way in previously trying to get contract work, it does tend to be something that recruiters expect contractors to have, particularly in the ITSM arena.

What’s the real value of ITIL Foundation Certification

I decided to track down the trainer who got me through my Foundation to get his views.

Neil Wilson is an ITIL expert and accredited trainer.  He says:

“The harsh reality is that organisations want it [ITIL], want to start practicing it, but don’t necessarily want to pay for it.

“They can choose who they want.

“It’s a foot in the door, and it gets you on the shortlist.”

He went on to give examples of recent class attendees who have spent many years in the IT industry, but who have never formalised their experience, and have found themselves having to face the prospect of studying.

“Whether we agree with the game, we have to have bits of paper and qualifications.”

I’m too old for this learning lark

This was the crux of my discussion with my colleague – and I am not going to lie, to cram all that stuff in for the Multiple-choice test on top of life, and in my advancing years was not a pleasant prospect.

But in my class, there were several people like me who had faced the spectre of redundancy and saw this as something necessary to help at least get your CV through the first set of scans.

Neil Wilson explains the basics.

“My advice for people who are worried about it – there is no short cut around it.

“You just have to get your head around it, whether that be classroom based or via self-study.”

It culminates in a one hour exam, 40 multiple choice questions, with 26 or more to pass.

“There is an argument for having this format as an appropriate way of testing people’s knowledge and understanding.

“The qualification gets this broad perspective of what the issues are – how do you test that?  With an exam.”

Yoda: "You must unlearn what you have learned"

Unlearn what you have learned

While it sounds a little Yoda™ -like in utterance, it is a valid piece of advice.

Most professionals working in or on the periphery of ITSM/ITAM will have an understanding of the basics in terms of terminology and basic process flow.

And so they should – remember we are talking best practice, here – not quantum physics.

BUT – to get through the exam you perhaps need to put aside what you know of real world situations and just learn what you need to PASS the exam.

Look at it like re-taking your driving test once you have established all those bad habits after you initially passed (we ALL have them!)

Isn’t that a bit defeatist?

Well not really – the Foundation Certificate is just that.  It gives the candidate a good grounding in the terminology and the concepts of ITIL, and at all times it constantly emphasises the fact that you go on a journey, and the need to adapt what you are learning to your own environment.

Is there anything I need to do beforehand?

There are some decent materials out there that can at least give you a ready reference for terminology – which in most cases is half the battle for the exam.

One of the things I found was at The ITIL Training Zone – where they offer ITIL Mind Maps and, more recently, ITIL on a Page.

I was able to catch up with their Head of Online Education, Claire Agutter at the Service Desk and IT Support Show 2012 to learn more.

She explained:

 “The mind maps were something that I found useful and we made freely available, as an effort to build up a trusted training brand.”

“People tell us they take these with them on courses!”

So is it worth it?

There are a couple of ways to look at this:

  • ITSM Credibility

For anyone working in the ITSM arena, there is little doubt in my mind that having a good understanding of the ITIL basics is going to help the team as a whole.

There are alternatives for companies who might balk at putting teams through the certification process.

Remember to balance the theory with common sense and practice.

  • Marketability

At the risk of sounding mercenary – anything, these days, that edges you closer to the start line in the race for jobs/better positions is a good thing.

Let’s be realistic – we work to make money to live.  If having at least the certification means you might be able to negotiate a better starting rate on contracts, or puts you in the frame to move up through the ITSM job structure in your organisation, then it is no bad thing.

  • Choose what works for you.  Classroom learning is an expense and takes up time, but it puts you in an environment where you have no choice but to soak it all in.  Self-study will give you a little more flexibility to study in your own time, but can be equally stressful when it comes to putting the time aside to focus on it.  If you have no self-discipline to do that, then be honest with yourself from the start!

Has it helped me?

For me, gaining my ITIL certification meant I could approach a change in role in terms of process consultancy with a little more comfort.

In my previous roles I could get by with my versions of the books and some background knowledge, happy in the knowledge we had Process Implementation Managers who handled all that other stuff.  I just needed to argue my case for the tool vs process.

But for my next role it was roles reversed – the focus was on process consultancy, with my technical expertise then helping us to develop the tool accordingly – the deeper dive into the basic foundation of ITIL gave me that balance.

I personally think it is worth the 3 days and a couple of nights of pain (if you do a typical course) to have the certification under your belt.

What you do with it afterwards, or more importantly what it can do for you…?  Well that’s another story.

Image credit

Assessment Criteria for Request Fulfilment

We will soon begin our review of Request Fulfilment offerings in the ITSM market place. Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.

In my previous article I looked at what ITIL 2011 had added to the process, and some of the pitfalls we may have seen in trying to implement Request Fulfilment in the past.

I would now like to take a look at what this means, in practical terms, when approaching Request Fulfilment – what should we be looking for?

At the recent UK itSMF ITSM Software Tools Forum event in Manchester, vendors spoke to the audience at length about transitioning from IT focussed decisions, to business outcomes, and this is an area where Request Fulfilment could come into its own, especially in the sphere of interaction by non-IT users.

But a transition is a gradual thing, and the importance of the concept of conformance should not be forgotten. I think it remains an important element for any vendor’s toolset to be comparable to identified, accepted benchmarks, as well as unpicking the practicalities of deployment a solution.

Principles vs. Process

What is more important at this stage, is the ease of which a tool’s capability can be displayed.

Demos at shows are slick and well prepared and I dare say a lot of us have had to go through the rigours of setting up demos and knowing what to click, how and where.

What we are looking for vendors to do is demonstrate to us how easy is it to start from scratch, ideally with meaningful options for an end user to start with.

Suggested Criteria


It is probably too much of an extreme to launch from recognisable standards and certification/verification platforms, to merely focussing on the look and feel of menus and options for end users in one fell swoop.

So for that reason, I am including a need to understand how vendors align to accepted best practice standards.

Overall Alignment

  • Have our target vendors aligned to ITIL and if so, to which version?
  • How do the set up roles and users to perform functions?
  • What demo capabilities can they offer potential customers?

 Request Models

  • What request workflows are available out-of-the-box
  • How easy is it to develop more specific workflows?
  • What additional administration is required for deeper customisation? At what cost?

Menu Selection

  • How is your self-help portal set up?
  • How do you incorporate new service descriptions for your users?
  • How much administration is needed to do the more bespoke work?

Request Status Tracking

  • Show us how any request is tracked throughout its lifecycle?
  • Who can see it, and when, and which teams can change it/move it on its way?

Prioritising & Escalating Requests

  • Show us how your tool prioritises requests and how they can be escalated?
  • What kind of other factors can affect a ticket (for example breaching SLAs and the escalation from that point)?
  • If a request becomes something more complex, how does your tool allow the alteration of the request (for example, a Change)

Financial & Other Approvals

  • Demonstrate a request model that includes alternative approvals (other than immediate manager)

End-to-End Co-ordination to Closure

  • We don’t expect tools to prescribe exactly how organisations manage their Request Fulfilment processes, just as we don’t follow ITIL blindly BUT during the course of the review, we want to understand how  a request can move through its lifecycle, end-to-end.
  • We want to understand the simple (out of the box), the medium and the complex (and the related additional costs that might be involved to get an organisation there).

I think it is rare that anything is utilised completely “out-of-the-box” these days, and that organisations will always have a requirement for some level of customisation. Request Fulfilment is certainly a process that could lend itself to quite intricate customisation, to the point of over-complication.


What is your view? What have we missed?

Please leave a comment below or contact us. Similarly if you are a vendor and would like to be included in our review please contact us. Thanks, Ros.

IT Service Management At VMTurbo Speed

Holonomix MD Darren Prince

Management software company VMTurbo has announced HoloSphereVMT, an operations/service desk management offering which has been developed with industry partner Holonomix.

Claiming to be able to provide “out-of-the-box” integration with service desk solutions such as ServiceNow, Zendesk and OTRS, this new offering aims to reflect real-world customer requirements in its core design

TECHNICAL NOTE: VMTurbo describes its Operations Manager as an intelligent workload management product for virtual data centres and cloud environments. Its capabilities include the ability to look at what resources applications in the data centre require, what resources these applications use and any capacity constraints there are that need to be accommodated for. For those that are not virtualisation specialists, this translates into giving applications more horsepower when they need it based on business rules and demand levels. According to VMTurbo, this integration of back-end IT and service desk management of delivery has the potential to improve how services are made available to end-users.

Holonomix MD Darren Prince contends that (in his experience) customers “love” the problem identification and recommended remedial steps that VMTurbo Operations Manager provides. “We have integrated this information directly into enterprise service desk solutions to streamline the process of logging records. This negates the need for human intervention for those incidents & change requests that require escalation in the Service Desk application,” he said.

HoloSphereVMT automates what is currently a manual process, transferring relevant data from VMTurbo Operations Manager into the service desk. Using HoloSphereVMT customers are said to be able to streamline incident & change management processes by freeing up manpower associated with data entry and ensuring consistency in data between the service desk itself and VMTurbo Operations Manager.

As VMTurbo controls how much resources these business-critical applications receive, improving the speed of getting these changes made should therefore add up to better performance overall.

“Holonomix has worked closely with our own engineering team on the development of HoloSphereVMT,” said Yuri Rabover, vice president of product strategy, VMTurbo. “The ability to automate a manual process provides increased efficiencies and cost savings and is an absolute requirement for IT organisations to maintain service level agreements.”