Posts Tagged ‘process’

ISO want to get certified

November 17th, 2010

Lately it feels like we’ve been hearing less about ITIL and more about ISO 20,000 certification.

I wasn’t completely clear on the difference between the two, but according to this very useful site:

ITIL is usually the starting point and in practice is often used by organisations wanting to address a particular “point of pain”, such as a process that is obviously failing. Once one process has been implemented successfully it soon becomes obvious that the related processes would also be worth implementing…and a service improvement journey begins.

Achieving ISO/IEC 20000 is undertaken when organizations want to test and prove they have adopted ITIL advice effectively. It is used to develop consistent, integrated processes across organisational and national boundaries. Customer organisations also use it to compare providers.

This sort of suggests, then, that if more and more people are talking about ISO 20000, it must follow that the maturity of ITSM processes is improving across the board. Right?

Except that’s not what we’re seeing. Undoubtedly, IT has been hit as hard (if not harder) by the recent economic turbulence as any area of business. And when budgets are cut, the first things to go are areas perceived as luxuries – things like systematic improvement of processes – and the areas that remain are the critical, can’t-do-without things: fighting fires as and when they appear. The irony, of course, is that proper process improvement would reduce the need to fight fires, and so an effort to reduce costs ends up costing more.

The other thing we’ve noticed as a result of the downturn is that IT departments are being asked to justify themselves to their customers – more so than ever. CIOs now have to demonstrate the value of IT, and the return on investment that the business can expect from increased IT infrastructure. It’s something that we at Westbury are very interested in, because the easiest way for a CIO to demonstrate value is through producing cold, hard metrics – and that’s where SMI Suite comes in.

So maybe this move towards ISO 20000 is nothing to do with maturity, but rather an attempt by IT departments to protect their budgets – the idea being that the certification proves the worth of the department.

If so, it’s a shame. We’d rather see real progress in maturity and real commitment to efficient, productive processes. But whether that means ITIL or ISO 20000, you won’t get anywhere without the data, and that’s when you’ll want to start talking to us.

Tom

Post to Twitter

How to improve your ITIL processes

September 14th, 2010

How to improve your ITIL processes?

Measuring is knowing, but without real understanding no use.

I just read a good article which sums it all up: “Before you can improve a process, you have to understand the current process. You have to get out from behind the desk and walk the process …”

So we are not talking about only knowing but also about understanding. “… how a process currently works is often very different from how you think it is (or should be) working.”

I want to deliver you the following takeaways as important steps you should take before you start improving processes:

  1. About processes, control and truths – The very first thing you have to do is accept that no one really knows what is going on and how people perform their work, neither workers nor managers. Regardless of what you think you know, the work really getting done, and how it gets done, is different.
  2. Workflow: what is real and what imaginary? – The only way to actually discover what is really getting done is to get up from behind the desk, walk out of the office, and literally walk around, observe, and take notes. You cannot practice ITIL from behind a desk. This sounds simple, but as in many things, the doing is not so straightforward. To practice ITIL you have to walk the process, literally. Keep in mind that your goal is to collect and model the existing process as it works today; not what you imagine it ought to be, but rather the actual tasks and workflow in place.
  3. Walk the walk – It takes time to learn the workflow with the right accuracy and detail.  You need to capture the “who, what, when and where” of the process, and should skip the “how and why” to start with.
  4. Than model the workflow – Based on the new info you will probably be surprised about the actual work and time involved. Now you are ready to map your processes with ITIL standards and to my opinion other best practices and your own experiences.

Be aware of:

  • It takes work, time and attention to detail
  • Get up and leave your office!
  • Accept that you don’t really know what is going on, but that you are heading for an exciting journey
  • It’s sometimes difficult to observe unbiased
  • During your analysis your goal is documentation, not improvement
  • Improvement in: the time it takes to do things. You should capture how long it takes to perform the work before you can answer the question “should this be changed”. That’s an important measure (consider our start-up reports on actual duration)
  • The value of an accurate process model cannot be underestimated. You cannot improve anything without understanding it first.

Read on

http://www.itsmsolutions.com/newsletters/DITYvol6iss32.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+DoITYourself+%28Do+IT+Yourself+%28DITY%29+Feed%29

Martijn

Post to Twitter

Information at your fingertips

April 26th, 2010

Do end-users really exist?

I am wondering about the definition of end-users. Regarding reporting or BI, I find it difficult to define these. Taken literally the word ‘end-user’ seems too static and out of date to get around a real description.

However based on our extended experiences of more than 12 years of report building, BI implementations and end-user training I feel the following types are close to what we experience in day to day’s engagements.

  1. Light users – The users who need static and reoccurring overviews. Real time information is not required and exploring data sets or ad hoc in-depth analyses neither. How? Static, free-of-charge pdf or html overviews. For managers and to support fixed and predefined arrangements on information sharing.
  2. Dynamic users – Those who need real time refreshable information. For example they want a real time status of the performance of department during a specific period. How? Reports which could be refreshed and prompt you for the data set you would like to see. For example the report will prompt you for department, region, classification, period … before it refreshes. Process owners, workgroup managers, team leads, business users …
  3. Explorers – Users who need to explore, navigate and visualize data themselves (googling your data). There are certain questions to be answered which need low profile data mining. How? Use a BI tool which provides you exploring data sources, the capability to define your data set by pointing/clicking and easily sharing your results (by iPhone)? It should be powerful, simple, intuitive and fast. Process owners, workgroup managers, team leads and your business for low profile data mining. But are you up for it? Mature enough yet to provide these access and responsibilities?
  4. Power users - The users which need slicing and dicing data for specific answers. To empower route cause analysis when dashboards are telling you, you are under performing as a group or at your process. So not for answering questions on how we are doing it, but why this is happening. How? Use easy to use slice and dice functionalities together with application configuration knowledge to get there. By the way these are your colleagues which provide you also the above 3 information sources.

Do you agree?

Step in the future and enjoy it now at:

http://westbury-it.com/media/product-demos/part-1-introduction-to-report-building

http://www.sap.com/netherlands/solutions/sapbusinessobjects/large/business-intelligence/search-navigation/explorer/index.epx

Martijn

Post to Twitter

Carlsberg don’t make customers… part three: the budget guy

February 24th, 2010

Well, it’s been a few weeks, but I’m back to continue this series on our ideal customer profiles. We’ve already had the Process Guy and the Tech Guy, now it’s time for the budget guy.

If you remember, the way it generally works is that the Process Guy is the alpha – he’s the one with a problem to solve that is related to process. Often the organization wants to get a handle on some real qualitative data about IT performance – either for budgetary reasons or for lofty ambitions like ITIL and continuous improvement. The Process Guy brings the Tech Guy in to establish a) that trying to get that data out of ServiceCenter or Service Manager is going to be like divorcing Cheryl Cole - painful, drawn-out and expensive, and b) that SMI Suite will remove all the pain, time and some of the money.

At some point in this sales cycle, the Budget Guy shows up, because despite the very low cost of SMI Suite, neither the Process Guy or Tech Guy has any spending power – it simply isn’t a function of their role to sign off on more than a few bucks worth of software.

In some ways the Budget Guy is interesting because he’s the first person we’ve met in the organization whom we don’t have to convince – the Process Guy and the Tech Guy’s advocacy and belief in SMI Suite does far far more to convince the Budget Guy than anything we could say to him. But still, the introduction of the Budget Guy into the proceedings is far from a gimme.

After all, he wouldn’t be doing his job – and wouldn’t be entrusted with signoff on budget – if he didn’t at least do some due diligence. Sometimes this takes the form of fact-checking and re-checking everything that has already been discussed and agreed upon with the Process and Tech guys, but more often than not, the Budget Guy wants to look at the bigger picture.

He’s usually happy to take at face value that SMI Suite can, technologically, do what it promises if the Tech Guy says so, and he also understands, with the Process Guy’s advocacy, that SMI Suite will unlock the door to satisfying certain business needs – like the need to have accurate data about ITSM activities.

But he will almost always question the business benefit of all this. To use a rather labored metaphor, identifying a new type of spot welder that allows workers to weld three times as many bits of steel together as they could before, and is five times safer, and costs half as much to run as the old type, is all well and good… but not much use if you run a day-care facility.

Luckily for us, the business benefits of SMI Suite are pretty universal, so long as the organization in question runs an IT helpdesk and uses HP ITSM software. And, of course, each company we deal with is individual, so the benefits that are applicable change from organization to organization, but when we start to talk about improving helpdesk efficiency by accurately benchmarking and constantly remeasuring response times, or we talk about cutting costs based on accurate workload metrics, the Budget Guy usually takes an interest.

Next time: the Department Head

Tom

Post to Twitter

Carlsberg don’t make customers… part two: the tech guy

January 5th, 2010

Well, we’re back after a festive period of eating, drinking and crying like a big old girl at the end of It’s a Wonderful Life (“Zuzu’s petals! Zuzu’s petals!”… gets me every time).

Before the break we gave you part one of our “ideal customer” profile pieces, the Process Guy, who is usually our first point of contact within a company.BEAUTY AND THE GEEK

The Tech Guy is usually our second point of contact, although we sometimes find that the Process Guy and the Tech Guy are one and the same. It’s not as unusual as you might think for one individual to have the broad abilities and knowledge required to be both process and technology oriented. Indeed, even when the Tech Guy is a new individual, there is as much crossover as we generally see with the Process Guy; that is to say that our Tech Guy is as well versed in process matters as our Process Guy is technically aware.

Whenever we’re getting into a sales cycle with a new customer, it’s always the Tech Guy that first poses the really tricky questions. Where the Process Guy wants to know the broad strokes of what SMI Suite does, our Tech Guy is often more cynical, less ready to believe and, above all, concerned with the minutiae of how SMI Suite does what it does. He wants to know every last detail about every piece of functionality that SMI Suite offers. Often the Tech Guy takes some convincing because he hears from the Process Guy about what SMI Suite claims to do, and flat out doesn’t believe that it’s possible.

The flipside of that challenge is that once we have convinced the Tech Guy that our methods are sound (an hour spent with our extremely knowledgeable and passionate pre-sales consultants usually does the trick), he becomes a powerful advocate for SMI Suite within his own organization. In most cases, of our four Guys, it’s only the Tech Guy who is in a position to truly understand the power of what SMI Suite does as well as the technical mountains that we have had to climb in order to bring SMI Suite to market.

Next time: the Budget Guy

Tom

Post to Twitter

Carlsberg don’t make customers… part one: the process guy

December 11th, 2009

weirdscience28Naturally we spend a lot of time thinking about our customers, past, present and future. And naturally all our customers are eternal delights to deal with and we never have any problems with them whatsoever. Not never.

But we do tend to find that certain implementations go more smoothly than others and we’ve done a little soulsearching about why that is. The conclusion we came to was that, for whatever reason, we – and our customers – walk away from the implementation with the most satisfaction when there is a certain make-up of people on the customer side. In fact, if we were to build our model customer from scratch (say, by putting bras on our heads, hacking into a secret government computer and feeding it pictures of customers we admired) then there would be, at the very least, four key individuals in key positions.

We thought it might be interesting to share with you each of these four archetypes – the Process Guy, the Tech Guy, the Budget Guy and the Department Head – and see if they ring any bells. We’ll start with the Process Guy and get to the others in the coming weeks.

*disclaimer: while I’m referring to all these people as “guy” and will use masculine pronouns, it should not be inferred that there is any gender bias to our depictions of the ideal customer. I’m just not prepared to write “he or she” every time, and – rightly or wrongly – the accepted workaround is to default to the masculine.

————————————————————————————————————————————————————–

The Process Guy

The Process Guy is usually our first point of contact at any given customer. He’s the one who has a problem to solve – either he’s not able to get any reporting out of his ITSM platform at all, or, if he is, it’s a laborious process that usually means he has to ask someone on the BI team to generate a report, and wait a significant amount of time to get the report back.
Process Guy has a fire in his belly! He’s interested in process improvement, he’s familiar with ITIL and he is desperate to drive forward solid initiatives that will make a real difference to the way the IT department is run.

Interestingly – and perhaps surprisingly – the Process Guy often knows a lot more about the tech side of things than you might give him credit for. Maybe he used to be a ServiceCenter admin, maybe his background is in IT and he’s come latterly to the process side of things. He may well understand the problems with the ServiceCenter / Service Manager database with regard to reporting. He probably understands what an ETL layer does, and have experience with BI tools. In the instances when he doesn’t have all the technological details himself, you can guarantee that he’s buddies with the Tech Guy (who we’ll come to in part two) and makes sure that between them they know everything there is to know.

The Process Guy is the visionary. He can see not only the problem at hand and the potential solutions to it, but also the bigger picture and the reasons to want to improve the performance of the IT department.

He wants to take control, not rely on a BI team to generate his reports when he knows that (with the right tool) he could do it himself. And while he’s technically savvy, the thing that drives him is the end-game: the ultimate benefit to the business of process improvement.

Next time: the Tech Guy

Tom

Post to Twitter