torsdag 4 februari 2016

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. 

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



  1. 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



  1. 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



  1. 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

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

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.