What is process design (my way) post 1(5).

This is a series of 5 posts. All posts are available. 

Process design! All ITSM professionals talk about it. It is mentioned in every project addressing ITSM, ITIL or IT processes in general in any context. But what is it? I mean in detail? How do you do it? And when you do, what are you actually doing? 

I have never written an ITIL book or published any commercial literature and I do not have any plans to do so either. What I have done though, are design, re-design and improve-design of processes for more than a decade successfully. And I will give you a peek into my world, my practitioner world, my reality, my success. 

I don't claim that I have a universal method. I don't claim that this is fully reusable in any situation. What I do claim, is more than a decade of successful design. 

Now you might think that if I have been designing processes successfully for more than a decade, what on earth have I been doing for all these years? How many processes have I designed? Well let me break it to you. It is not about quantity, it is about quality. The lifecycle of an effective process demands nurturing and care. Just like the parenting of a child. A child is not considered a failure for not being able to read or to know math at the age of three. It is considered a success for the ability to walk. It is the same with a process. In the early stages there will be results that the process cannot achieve but still be a success. It needs to evolve and mature. That takes time, effort and a lot of collaboration.

Process design is not a one time job! It is a continuous parenting based on input from a whole lot of sources, mostly human but there is a lot to pick from. Well, back to the topic. What is process design?

First of all, the most brilliant process design will still be utterly useless if it does not improve and help people to achieve the expected outcome. If this is the case, all design work is waste! So a critical factor to claim success is the ability to achieve change and to measure that output. Read more about how to improve your change ability in post 5(5)

Now there will be ITSM pundits out there that will protest and say, if the output is not consumed by a customer there is no value and still useless. I don't disagree but let's keep it simple. If we can't generate the expected output, we won't have a customer in the first place so I will address the output and then we can have the value discussion at another time. 

Next post in this series: What is process design (my way) post 2(5). The two major parts.

What is process design (my way) post 5(5). Summary.

So now you have read my example (simplified yes, but still not fiction) of the results expected from the initial process design from part one and two. As I said, this is not a "cut and paste" material. The key here is to get a solid acceptance from the participants from both parts that this is the truth and nothing but the truth. There can be no discrepancies and this requires multiple iterations from both parts to be thoroughly accepted by all. The content needs to come from them, you can still use this material to guide the workshops and discussions but it cannot be forced. It is people you’re dealing with. Respect their profession, experience and competence.

The acceptance is one factor that radically improves your ability to accomplish the necessary change and to get people onboard. The end game is to facilitate the change that is required to improve the output. If the output does not improve, your wasting everybody's time.

I left out one thing in part two. That is the detailed activity flows for each of the sub processes. It is in these activity flows you design the order of activities and any dependencies there might exist to preform them. Dependencies can be to other activities in the same process, activities in other processes, specific information, tools, access etc. All these dependencies needs to be identified and documented. 

It is very important that the sub process activities identified and defined in the activity flow fulfills the sub process objectives. Individually or collectively does not matter but they must contribute to all of the defined sub process objectives one way or the other.

It is the detailed activity flow that can act as the baseline for any tool implementation that you might be planning or that you already have in place that needs to be changed and improved.

This series of posts only cover selected content from my process design. There are much more to be done and process documents to write to get a complete picture. But don't forget. This is not a one time job. As soon as you stop managing, analyzing and improving the process and sub processes, it will deteriorate. 

Links to all posts in this series:

What is process design (my way) post 1(5).

What is process design (my way) post 2(5). The two major parts.

What is process design (my way) post 3(5). Part one.

What is process design (my way) post 4(5). Part two.

What is process design (my way) post 5(5). Summary.

What is process design (my way) post 4(5). Part two.

So let’s get deep. I will continue with the Knowledge management process and here is content for each of it's sub processes.

Knowledge management process - Part two, the sub processes.

1. Identify, record and approve knowledge

Objectives:

• To identify and process any potential knowledge

Main focus:

• Process draft knowledge articles relevant to support and maintain an application, system or IT service
• Validate and approve draft knowledge articles to enable accessibility and usability to relevant audiences

Stakeholders:

• Service Delivery Managers
• IM/PM Manager
• Change Manager
• Service Desk Manager

Measurements:

• Time between draft, creation, review and approve
• Amount of articles reviewed by Knowledge Coaches
• Amount of articles reviewed by others than Knowledge Coaches
• Amount of draft knowledge articles created from change Management
• Amount of draft knowledge articles created from support issues 

Key functions/roles:

• Knowledge Manager
• Knowledge Coaches
• 2nd & 3rd Line support
• Change Manager

2. Transfer Knowledge 

Objectives:

• Document knowledge from Change management (proactively)
• Document knowledge from support handling (reactively) 
• Ensure accessibility and availability for the knowledge target operator, group or audience

Main focus:

• Ensure accessability, findability and usability of the articles by those who are to use it

Stakeholders:

• Knowledge Manager
• Service Desk Manager

Measurements:

• Amount of knowledge articles created from Change management 
• Amount of knowledge articles created from support issues 
• Number of knowledge repositories used and maintenance of them

Key functions/roles:

• Service Desk
• 2nd & 3rd Line

3. Monitor Knowledge

Objectives:

• Monitor knowledge articles to aid in support and management of IT services
• Monitor and evaluate the quality and rating of knowledge
• Monitor and evaluate the Use and effectiveness of knowledge

Main focus:

• Monitor quality and use of knowledge articles to optimize usability of content

Stakeholders:

• Knowledge Manager
• Service Delivery Managers
• IM/PM Managers
• Service Desk Manager
• Change Manager

Measurements:

• Usage of knowledge articles
• Average reuse of knowledge articles
• Amount of knowledge searches leading to incident resolution
• Rated quality of knowledge articles
• Monitor usage trends of knowledge articles
• Monitor searches that does not provide relevant knowledge

Key functions/roles:

• Knowledge Manager
• Service Desk
• 2nd & 3rd Line

4. Review, validate and retire knowledge

Objectives:

• Review and update knowledge articles to improve their quality and level of reuse
• Ensure that only relevant knowledge is available by validating content and retire and close irrelevant content

Main focus:

• Correct and improve knowledge article content and searchability
• Fix incorrect knowledge articles or flag them for review

Stakeholders:

• Change Manager
• Service delivery managers
• Service Desk Manager

Measurements:

• Amount of articles flagged for review
• Amount of articles retired and closed

Key functions/roles:

• Service Desk
• 2nd & 3rd Line
• Knowledge Manager
• Change Manager

Next post in this series: What is process design (my way) post 5(5). Summary.

What is process design (my way) post 3(5). Part one.

So let’s get real. I will use one of my favorite processes that I feel is so often misunderstood in the ITSM community as my example. The Knowledge Management process. You might think that the following is not a complete description and it is not. It is an example and a simplified one. It’s just to show parts of the content but it is real, no fiction.

Don't forget that this is not a "cut and paste" material. You still need to do the work yourself but feel free to reuse all of this content in any way you see fit.

Knowledge management process - Part one, the process.

Mission: 

Enable reuse of knowledge to deliver faster, more accurate and consistent support to business with decreased effort for resolutions and dependence on individuals. 

Goals: 

• Reduced dependency of individuals for knowledge
• Reduced time and effort required to maintain and support IT services
• Ensure that all knowledge used and stored is consistent and readily available.
• Improve the organization’s ability to utilize relevant information.

Success factors:

• Ability for staff and vendors to find and access relevant knowledge when needed
• Ability to distribute the creation, review and update of documented knowledge among staff and vendors
• Ability to follow-up and reward the right behavior among staff and vendors to create and maintain a culture of knowledge sharing
• Ability to track the usage and quality of documented knowledge 

Key Performance Indicators:

• Increased number of times knowledge articles are being reused
• Increased level of resolution within 1st line of support
• Increased amount of knowledge searches leading to incident resolution
• Increased rating of knowledge management satisfaction surveys among staff and vendors
• Increased speed of handling recurring incidents

Output:

• Increased speed, accuracy and consistency in IT support handling
• Decreased cost of labor for IT support handling
• Faster time to proficiency for IT staff and vendors

Sub processes:

1. Identify, record and approve knowledge
2. Transfer Knowledge
3. Monitor Knowledge
4. Review, validate and retire knowledge

Next post in this series: What is process design (my way) post 4(5). Part two.

What is process design (my way) post 2(5). The two major parts.

Assuming that the ability to achieve the necessary changes exists, I divide process design in two major parts. First part is very corporate oriented and tend to include a lot of theory and logic, the second part is very operation oriented and tend to include a lot of practice and how to. I have run both parts in parallel, in sequence and backwards all with the same result. It does not matter. They will affect each other so the number of iterations is dictated by the distance between them both. I promise you there will be a distance between them and that is exactly what the process design is to identify and to close that gap. 

I have heard and read about numerous process projects where the initial process design phase has been closed in the early phases of a project and the project team has only read books and talked to management at that stage, not talked to any process performer/operator/role. That would be a shortcut to failure to me. That would only address one of the two parts of process design for me. 

Part one in process design - The Process: Define and describe the process mission, process goals, critical success factors, Key performance indicators, sub processes and expected output/benefit aligned to corporate strategy and goals. This needs to be business oriented.

Part two in process design - The sub processes: For each sub process, define and describe objectives, stakeholders, measurements, main focus, key functions/role involved and a detailed activity flow. This needs to be practice oriented.

Part one is done with the business, management and function responsibles and part two is done with stakeholders and highly qualified and experienced process operators that really know how things are done in reality. 

When the first step with both these parts are done the gap needs to be identified, analyzed and closed. The gap will be there. There will be missing measurements and activities in part two that are necessary to achieve the objectives for that sub process and there will be activities that are identified that does not contribute to the sub process objectives or should belong to, and be performed in, another sub process where it contributes to the corresponding objective. 

There will also be missing sub process objectives that needs to be identified and included to support the overall process goals and mission. Some process goals will later be identified and changed to a sub process objective and vice versa. This is the iterations that the gap between the two parts will generate.  Both of them feed each other with valuable findings, changes and content etc. They need to be addressed and designed as one but due to the difference in detail and participants they can be managed as two different work streams e.g. part one and part two, in parallel or in sequence with iterations to close the gap.

When the initial design is done, the content for the process, part one, will tend to be quite static. There will be changes over time that is identified but still, they will be few. The sub processes on the other hand, part two, will be more dynamic. This content will, and need to change to evolve the overall process and is a never ending story. As soon as you stop managing, analyzing and improving them, the process will deteriorate. 

Next post in this series: What is process design (my way) post 3(5). Part one.

New jobb

It's sentimental and melancholy at the same time as I feel excited when I tell you this. 

The day I thought would come naturally in 20 years, will come in February. The day I speak of is my last employed day at H&M Hennes & Mauritz. I have had a wonderful and fun time during my +14 years in the company and I have learned so much from my colleagues, some have even become my best friends. It has been an honor and it is sentimental to meet and work with all of you the last few days I have left in Stockholm. 

The excitement is for my new employer Närkefrakt in Örebro. In February I will face a new business, new colleagues, new customers, new challenges etc as their CIO and I'm really looking forward to it. I bring 25 years of IT experience and I have so much to give while there is a lot new to learn. I am convinced that Närkefrakt will be a thriving environment where I can use my full capacity and develop together with the business. I can hardly wait to start contributing. 

Best regards / Mika Salo

Transitioning to CIO at Närkefrakt

I don’t like IT "movements" or frameworks, but why I still use them all.

Sounds contradicting? It sure does but that’s actually true. There is a lot of information available about these IT frameworks and movements. There are ITIL, DevOps, Agile, Lean, Cobit, ISO2000, SIAM, IT4IT and so on. And trust me, there will be more, plenty more. It will never end. But there will never be the day where you have one to rule them all. People are sharing tons of material and their own experiences etc. about these movements and frameworks. There are plenty of books to read too. The good thing is that it is really easy to access this huge amount of information. The down side is that a lot of the practice out there is subject of interpretation and might even in some cases be applied and described in a wrong way.

 

Its not deliberate, no. The use of selections of a particular framework applied for a specific situation/challenge at a company is a common approach. It might even succeed and increase or decrease whatever the target was. Is this wrong? Of course not. Could you brag about it? Of course. Could you even say that framework used works? Yes you can.

 

So how come everybody that have a success story claim that the particular framework or movement they used works, when there is example of every framework succeeding in some specific case? There are horror stories as well of course but let’s focus on the ones that actually claim that their specific religion, ops sorry for that, I mean framework or movement works.

 

First of all, and here is my theory, all of the frameworks and movements address  IT service management (ITSM) in some way. More or less but they all do in some way. That means that there are fundamental parts of ITSM found in each and every one of these frameworks and movements. They might have different focus, but parts of the fundamentals are there in each and every one. In practice this would mean that if a framework or movement is used in a way that actually enables a company to reach their target or goals, you have a success story. BUT. That does not mean you would have failed if your reference had been another framework or movement. In practice again, the same approach applied and use in another situation and another company might not give the same results.

 

2 + 2 is not 4 every time in ITSM! Situations are not the same, targets are different, conditions and resources are different. There is not one single framework or movement that only has success stories. All the failures are blamed on wrong application or wrong use of the framework, if you are a believer. If you are not a believer the blame is that the wrong framework was used. 

 

So here we are. We are all looking at the same thing but from different views, with different knowledge, experiences and condition etc. There are no right or wrong as long as you apply parts from whatever framework or movement and succeed to deliver value. 

 

That was a short term perspective. So what happens when the years go by and this way of using and applying bits and pieces, simplified way of working, cutting corners etc. are continued? Hey come on, it has been working so no hard feelings here. 

 

In the long time perspective a new challenge emerge. Specific applications or situations with a specific focus with engaged people always seem to do well and deliver great results. But slowly things start breaking apart. Changes made to way of working do not seem to give any obvious positive affect. We run out of quick fixes and things start to get complicated. More and more seems nestled and optimization of a single process or procedure does not work anymore. Now it seems like there is a need for orchestration of multiple procedures or processes. The introduction of a new process or adaptions of and existing might give increased value in a completely different part of the process landscape. It all seems to be interlinked. The way we used to adapt with bits and pieces, simplified way of working, cutting corners etc. no longer works.

 

I guess you already know where this is heading. ITSM is not about one process, one procedure, one function, one role etc. ITSM is about the whole picture. There is not one thing that makes it all work. In the beginning one can get a lot of value by introducing small isolated parts which seem to have an immediate and positive effect. But along the road the effort and complexity increases while the benefits are decreasing, or in some cases, are absent. 

 

It’s now where the going gets tough. The sherry picking times are over. It’s not sufficient to address isolated parts any more. We need to look at the whole picture and understand how it all comes together and works as a system. Every adaption we intend to make must be design from a holistic perspective. It’s a complete machinery that needs to work where every single adaption is analyzed, design and changed based on improving the system as whole.

 

So where is that framework or movement that can accomplish this complete system? I'm sorry to say, but there is none that covers the width and depth of everything. This is why every framework and movement comes in to play. Every company has their challenges and obstacles, and depending on them, different strategies are relevant based on what they want to accomplish. It cannot be read in a book. It cannot be thought in a class. What you need are experienced professionals that are capable of doing the analysis required to understand how these frameworks can be used in a combined and valuable way to achieve the goals ahead. 

 

It is hard work and demands a lot of effort. The only way to achieve this kind of change is to treat it as a business change and admit the fact that it is people you deal with, not technology. Treat your change as a people change initiative with enabling business goals as your target. 

 

Start designing your ITSM puzzle and try not to be religious about a specific framework. See all the frameworks as collections of knowledge and try to see how they can benefit you in your specific needs to achieve your goals and targets. Don't try to do it all at once. Introduce small changes but never forget that "every small change you do, is designed to improve the system as whole". Small changes are good. They are not perceived as a threat. But be clear about the benefits, even if it is not visible where the change is made. Always explain why!

 

This is why I don't like frameworks and movements. They are too often described as a prescription or solution for everything but they are not. So I use them all. And I think you should too.

 

Happy New Year to everyone and I hope your 2016 will prosper.