Anyone know anything about SMPM ? I've heard it speeds up the process definition phase but is the product really only effective if you are going the full hog and implementing the whole suite of ITIL processes. What if you are just looking at Incident and Change. Is it over the top ?

Sandy - I see it's been awhile since you posted this. You may already have your answers. However, I do know a bit about SMPM. The company that developed it was recently acquired by BMC. There are two flavors of SMPM, one is designed to align with BMC ITSM V7 (Remedy). The other is (or was) designed for HP OpenView ServiceDesk. Both are very similar in look and feel. The differences are in the low level work instructions and form references. SMPM is sold as two modules, Service Support and Service Delivery. You can buy them independently so you can just buy Service Support (which includes all the Service Support processes). The Service Delivery module can be deferred until you need it. The documentation that comes with SMPM is very complete and includes a Customization Manual. SMPM is written entirely with HTML and Visio Diagrams. Easy to modify - if you know HTML and Visio.

SMPM is simply a documentation repository for your ITIL-based processes. It provides a GUI interface that allows you to drill down on any process, procedure, and work instruction. Its main benefits are: 1. it gives you some good, field proven, templates for each ITIL process, greatly shortening the time required to design your own from scratch; 2. the GUI interface encourages staff (and management) to actually refer to the documentation when doing their jobs (RTFM). You can find a brochure here: [Edited by Admin: Please do not post links]
Hope this helps.

I'm new to this forum but what I have been seeing a lot here is that too many people see every company as being special and having their own specific situations : reality is that all IT departments are "service organisations" that all (should ) work in similar ways.

SMPM is a process model that covers the gap between the theory ( itil ) and reality ( a tool )

SMPM are indeed best practises : processes, procedures and work instructions that have proven to work for more than 100 companies

when following this approach, first activy consist of a so called "gap analysis" : what and where is the difference between the processes of the "best practise" model and the processes of the company : turns out that max 20 % is different.

Real advantage is that one does not need extensive tool customisation any more, since this is already done. SMSP used to be mapped on HP tools, since BMC bought it, it comes "mapped on BMC Service Desk Express and they are working on a Remedy version as well

If this is anything like the tool I used a while back which documented processes and mapped them to HP Openview, it was a disaster - unless you have a very simple st-up, it did not work, changing it took away the point of having it (which was to save time/money/customisation). Some of interpretations of ITIL into processes was odd to say the least. There was nothing there that could not have been knocked up quickly once the proceses were defined. If you want a simple tool, buy a simple tool. Do not buy a customisable heavyweight tool then buy another tool to make it simple!!
(The one I used may be a different one - butI think the general advice still applies. I will run a mile if anyone ever suggests it again!).

The difficulties with processes are NOT the documenting of processes (pretty straightforward) or the customisation of the tool (If you want to get full value of the features, then invest some time in training one of your own, or bringing in someone for a few weeks). It is the PEOPLE/Cultural change, or whatever you want to call it. I have conducted many workshops, where I had a very good idea of the desired processs outcome beforehand, but time was needed for people to work it through themselves, wit guidance, so they ended up wanting it, not feeling it was imposed. If there is a tool to do that, I would like to hear about it!!_________________Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance

I'm new to this forum but what I have been seeing a lot here is that too many people see every company as being special and having their own specific situations : reality is that all IT departments are "service organisations" that all (should ) work in similar ways.

I could agree, they might work in similar ways, but doesn't mean should be.
There are many, many kind of IT Department or IT Service Companies, each has its own (unique) characteristic.

In my view, the ITIL framework has given the most flexibility, and most important is that the it doesn't regulate.
I'm afraid trying to make a "pre-customized" framework would cause it lose flexibility and hence not easy to assimilate new things

Once you have generalized your documentation tool to suit all, does it suit any?

Will it not then be a straitjacket dictating how you do things and constraining improvement initiatives?

Will it not isolate IT service processes from other business processes? Would it not be better to have document management for the whole business?

I don't mean to suggest that such tools are useless, but most of the cost savings are short term and may be much less than are expected._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

I can understand the arguement made to use such tools to get organisations started with something rather that try to do it all themselves.

However my experience shows that the organisation then relies on the output of these proces builders and frameworks as the cost of then updating them to reality and to custom fit the organisation is a cost not accounted for. Therefore the quick win becomes a stranglehold and you are left with the output of a generic process builder / framework.

"ITIL in a can" has is place but I feel is limited and not fully understood by organisations as to what they need to do going forward - indeed any process should be reviewed at least once a year to assertain if it is still fit for purpose._________________Mark O'Loughlin
ITSM / ITIL Consultant

Agree with Mark et al; prescriptive solutions are dangerous and are the service management equivalent of the fateful project management logic that project managers are the only ones really accountable for project success or failure.

What I mean by that is if you start trying to a rigid structure in an unsuitable environment then everyone starts thinking the IT managers are not up to the job, whereas the reality is they may be working with the wrong (process) tools. For a long time Project Managers have suffered from Directorial staff washing their hands of accountability for badly structured and badly managed/assured PM processes. I can see the same arguement being applied in Service too: "Well we given you the 'best practice' you were asking for, so why can't you make it work?'

Implementation is just a project so do the business analysis thoroughly and establish your requirements first.

The difficulties with processes are NOT the documenting of processes (pretty straightforward) or the customisation of the tool (If you want to get full value of the features, then invest some time in training one of your own, or bringing in someone for a few weeks). It is the PEOPLE/Cultural change, or whatever you want to call it. I have conducted many workshops, where I had a very good idea of the desired processs outcome beforehand, but time was needed for people to work it through themselves, wit guidance, so they ended up wanting it, not feeling it was imposed. If there is a tool to do that, I would like to hear about it!!

I 100 % agree with the fact that it should not be difficult documenting processes or customising a tool.

However, in many "itil projects" the biggest part of the budget is spent on this....
Next to this, I know many IT'ers ( people on the floor ) who hate it to be in these workshops => they just want to do their (technical ) jobs

Following this "best practise model" there remains sufficiant budget to spend indeed on what is most important : the cultural change : people will be explained why it is important to fill out a certain field in a tool

[quote="asrilrm
I could agree, they might work in similar ways, but doesn't mean should be.
There are many, many kind of IT Department or IT Service Companies, each has its own (unique) characteristic.

In my view, the ITIL framework has given the most flexibility, and most important is that the it doesn't regulate.
I'm afraid trying to make a "pre-customized" framework would cause it lose flexibility and hence not easy to assimilate new things[/quote]

The key of succes here is "daring to admit" that you , as an organisation, are not so special, so unique.

Obviously the "back office " will be different , but the "general priciples" will always be very similar : a client calls with a problem , his problem needs to be solved asap, obviously taken into account priority and impact....

other example : a change, depending on the "impact" it can have two different "routes" , going via something called CAB or not necessary

other example : a tecnical person has a solution for a problem : it is up to someone to determine if this info is "usable" for the knowledge base, ....

all these steps are "common sense", no need to "invent" these together during workshops and then building this into a tool

That is why ITIL is guidance and not prescription and why ISO20000 - and ISO9001 for that matter - define what is required for a Quality system but not how it should be achieved._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718