Skip to main content

Posts

Showing posts with the label process design

Optimizing Value Streams and Processes

Value streams are getting a lot of attention these days for a couple of reasons. One is that value streams allow us to identify opportunities to minimize waste or bottlenecks across organizations, processes and functional silos, and to improve the flow of value. Organizations adopting DevOps , for example, are using value stream mapping as a way to improve the flow of activities during the software development lifecycle, and to improve cross-functional collaboration. Another reason is that value streams direct our attention to what customers value. For example, organizations can use value stream mapping to streamline new product development activities, improve time-based measures such as lead time and time to market, and identify ways to improve product quality. They can also use it to streamline the activities involved in integrating a new employee into the company and its culture. What these both have in common is that the focus is on optimizing the value-adding activities; with the

Process Design

I looked up “Process Design” and found: “The  activity  of determining the  workflow ,  equipment  needs and implementation  requirements  for a particular  process . Process design typically uses a number of tools including flowcharting, process  simulation   software  and  scale  models.”  Hmm… that is good but “So What”?  Why should a service provider care about process?  I have heard some say that process is secondary to automation.  Okay, sounds good, but then we have to consider, “What are we going to automate?” Every Certified Process Design Engineer knows that when it comes to process we are talking about activity.  The key is that we need just enough process and just enough governance to meet requirements.  Process design contributes to our ability to balance speed and agility with stability.   Having good process design allows for a smooth service belt that delivers value to customers and also gives a service provider the ability to meet business and customer dem

CPDE - Process Design Considerations

S o who should consider becoming a Certified Process Design Engineer (CPDE)?  Well anyone can consider it.  Is your organization engaged in some type of certification, working to reach some optimized level of maturity, trying to improve the processes you already have or create a process to meet some new customer requirement? All of these scenarios would employ the skills of a CPDE. To start with, no matter which framework or standard you are utilizing processes must be: Defined Documented Managed via performance metrics Continually improved  Undertaking this effort is not as simple as it may appear and having a staff member with the necessary skills and capabilities (a CPDE) ensures that clear and measurable improvement targets, along with a process design approach, can and will be carried out.   You first must understand the factors that are triggering a process improvement initiative.  These are just a few factors, but understanding why an initiative is needed is an ex

Process Design

I looked up “Process Design” and found: “The activity of determining the workflow , equipment needs and implementation requirements for a particular process . Process design typically uses a number of tools including flowcharting, process simulation software and scale models.”  Hmm… that is good but “So What”?  Why should a service provider care about process?  I have heard some say that process is secondary to automation.  Okay, sounds good, but then we have to consider, “What are we going to automate?” Every Certified Process Design Engineer knows that when it comes to process we are talking about activity.  The key is that we need just enough process and just enough governance to meet requirements.  Process design contributes to our ability to balance speed and agility with stability.   Having good process design allows for a smooth service belt that delivers value to customers and also gives a service provider the ability to meet business and customer demand at a

CASM and the 3 Ways

Agile Service Management ensures that ITSM processes reflect Agile values and are designed with “just enough “control and structure in order to effectively and efficiently deliver services that facilitate customer outcomes when and how they are needed.  We accomplish this by adapting Agile practices to ITSM process design.  Implement service management in small, integrated increments and ensure that ITSM processes reflect Agile values from initial design through CSI. By being able to incorporate a variety of tools from many practices, the Certified Agile Service Manager (CASM) can engage both the operations and development sides of the organization when defining and documenting processes, engaging in a major project or just move through these steps as part of an improvement project.   By incorporating these DevOps principles along with the CASM role, we can begin to incorporate the idea of process and functional integration much earlier in the development lifecycle.  It allows

Thoughts on People and Process

The “ Agile Manifesto ” states that “We value Individuals and Interactions over processes and tools”.  What? Some have taken that statement and interpreted it to mean that when it comes to design and development … “No Process” is required!  In fact if we look further in the manifesto we see clearly that the value of process and tools is indeed recognized.  The manifesto is trying to impart the importance of people and interactions.  If we have a brilliant process that is defined and documented and yet drop the ball when it comes to people and interaction we will surely miss the mark every time.  Therefore, while there is value in process and in tools service providers must value the people and interaction with them more. In her book titled “The ITSM Process Design Guide” Donna Knapp stresses the importance of “Just Enough Process”.  When designing ITSM processes such as Service Level Mgmt, Change Mgmt, Incident Mgmt and others, service providers could miss the mark and over design

Process Maturity – How can I Assess it?

A process is doomed if you ever consider it done!  Unlike an audit that examines evidence to determine compliance, a process assessment is conducted to evaluate and organizations strengths and weaknesses.  The assessor will ensure that this baseline is utilized to identify process improvement opportunities that ensure business outcomes. The ITIL Process Maturity Framework (PMF) was defined specifically for ITSM processes and consists of five levels of maturity. ·          Level One – Initial At this level there is not a defined process, there are some procedures and few results are retained. ·          Level Two – Repeatable At this level of maturity there is a recognized process but the objectives are not clear and targets are not formalized. ·          Level Three – Defined It is at this level of maturity that the process is defined and documented and there are agreed upon targets. ·          Level Four – Managed A managed process at this level is well defin

Process Maturity – Documenting the “As Is” Process

There are many challenges to defining and documenting a process for ongoing continual improvement and to ensure process maturity is in alignment with the overall business strategy and outcomes.  One such challenge is to be able to document the “As Is” process. When documenting the “As Is” process caution must be taken not to accept the existing documentation, or flowcharts provided as the true baseline of what is really being done.  What are the current activities and procedures that are being used and what is the step by step workflow that participants and stakeholders are actually performing?  The actual is what really needs to be captured.  The complexity of this challenge is exasperated by the fact that frequently when determining and “As Is” state for immature processes the assessor or process design engineer will discover that there is not one single process that is being followed but in fact many?  What then? Non adherence to process is generally due to little or

Process Maturity Requires - People, Process, and Technology… Let’s talk Process!

I recently heard an ITSM manager state… “The engineers think that it is the process that is slowing us down” then he went on to say “Of course we here all understand that the process is intended to slow us down”!  I was waiting for others in the group to comment and no one mentioned a word.   WHAT?!   Is that really ever the intention or the purpose of a process? What a process is – or should be A process is a set of activities with predefined inputs and outputs which are intended to meet the needs of the business and stakeholders!  A process has clearly defined roles, responsibilities, and workflow. When was the last time you heard a business representative say could you design a process to slow things down?  In reality we need to look at how we can design processes or activities within the organization to increase quality and speed!  The real challenge is how do we do that?  How can we get just enough process and control for consistency, automation, and speed and yet

CPDE (Design considerations)

So who should consider becoming a Certified Process Design Engineer?   Well anyone can consider it.   Is your organization engaged in some type of certification, working to reach some optimized level of maturity, trying to improve the processes you already have or create a process to meet some new customer requirement? All of these scenarios would employ the skills of a CPDE. To start with, no matter which framework or standard you are utilizing processes must be: Defined Documented Managed via performance metrics Continually improved Undertaking this effort is not as simple as it may appear and having a staff member with the necessary skills and capabilities (CPDE) ensures that clear and measurable improvement targets along with a process design approach can and will be carried out.   You first must understand the factors that are triggering a process improvement initiative.   They may include: Changing customer requirements Processes that are to complex or have

The Certified Process Design Engineer (CPDE)

There are many frameworks and standards that define best practices for achieving quality IT service management (ITSM) - ITIL, ISO/IEC 20000, COBIT, CMMI, DevOps, Knowledge-Centered Support, etc. While each describes processes and controls (what to do), none provide clear, step-by-step methods and techniques for actually designing, reengineering and improving processes (how to do it). IT organizations must not only do the right things, they must do the right things right.   The CPDE takes a practical step by step approach to developing and implementing ITSM processes across the entire lifecycle of IT services.   It ensures integration with project and program management and the application and software development processes as well.   Allowing for strategic, tactical and operational alignment across the entire organization.   The CPDE is well suited to utilize these different best practices and additionally play a significant role in the DevOps movement that is taking hold in IT organi

Process Centric Thinking

What do we mean when we say “process-centric” thinking? What we mean is that individuals, groups or teams and even an entire organization sees their work and activities being driven by or related to process first, rather than person, technology or information first. Remember that a process is a structured set of activities that take inputs and convert them to outputs that help to satisfy business, customer or user outcomes. When we look to accomplish work or produce a good or service we are going to do that in a structured way (a process). To paraphrase Dr. W. Edwards Deming, “…if you cannot describe your work or what you do as a process, you do not know what you do.” A “process-centric” approach should not imply that you should forget completely about people, technology or information. These are important factors in completing the production of goods and services. It is that these other factors make the process possible. In turn, a process relies on these elements to work most

Control Charts

In the 1920’s while working at ATT Bell labs, Dr Walter Shewhart (mentor of W Edwards Deming) sought a way to improve telephone transmission systems. Seeking to reduce variations and failures, on May 16, 1924 Dr Shewhart wrote an internal memo introducing the concept of the control chart [Wikipedia]. Today the control chart (AKA process quality control chart or Shewhart chart) has become the standard statistical tool for finding variation that lead to continual improvement. As with other continual improvement tools, the control chart can be understood in a short time, yet takes a lifetime to master as a truly powerful tool for statistical and incremental improvements. The control chart is a tool that tells us whether a process or system is in a state of statistical control. The state of statistical control is one in which a minimum or acceptable amount of variation is acceptable while still meeting the desired output of the process. Shewhart recognized that every process and sys

Process Improvement Paths

When it comes to processes, W. Edwards Deming stated that there are only two choices: execute the process or improve the process. When it comes to improving a process we have three basic paths we can follow: develop the process (if it does not exist), redesign the process (if it is sore need of fixing) or improve the process (tweaking it in incremental ways). So let’s explore each of these paths in a little more depth. Develop the Process: This path occurs when you really do not have a process. You might have some loosely followed procedures or perhaps steps that people follow in their heads. There is no formally defined, developed or documented process. This path allows you to start from the beginning by gathering requirements for the process, creating a process definition document and then implementing the process. This path takes the longest time and in some ways the most work. Redesign the Process: This path occurs when the process you have in place just does not provid

Designing and Documenting a Process

Designing and documenting a process enables an organization to move from the initial level of the ITIL Process maturity Framework (PMF) through the repeatable level to the defined level.   To undertake this task without adequate resources can be quite daunting especially given the fact that it must I dentify needed changes to job descriptions Develop and document work procedures Identify work requirements Establish the data to be collected and the format to report accomplishments D ocument the necessary vocabulary to be utilized within the process The following ten process design and improvement steps can be used to create an easy to use and repeatable approach to help move your organization from one level to the next.   The ten steps are grouped into four phases.   Each phase will produce a deliverable that serves as an input to the follow phase. Phase: Requirements Definition.    Output: Requirements Definition Document. 1.     Determine the management’s vision and level

The Beginning of Good Process Implementation

Many organizations that I meet with often are struggling to implement best practice processes into their environments.   They sound completely overwhelmed and often I hear “Where do we begin?”   I smile and usually respond with “At the beginning of course”.   The beginning of good process implementation of course is “defining and analyzing your customer’s requirements”.   I once read that to provide good services a service provider must have good customers.   I think this statement also holds true for processes as well.   Good customers / employees must: Understand the process Understand the expected results of the process Know where they fit into the process Understand how they and others contribute to produce the expected results When your employees understand the processes within your environment they can easily identify new customer requirements and positively respond to rapidly changing customer needs.   This is the basis for making it part of the service culture within you

The Components of a Process

I often get asked what goes into a Process Definition Document (PDD).  Certified Process Design Engineers (CPDE) learn that PDDs should  include: Policies A process overview Roles and Responsibilities Process Maps Activities Vocabulary Policies Policies specific to a process should be included in the Process Definition Document.  A policy is a formal document that describes the overall intentions and direction of a service provider, as expressed by senior management. Company policies are used to guide actions toward a specific outcome. They must be specific, measurable and underpinned by the process.  Overview The overview section contains the process description, objectives, goals, owner boundaries, triggers, supplier data, inputs, high level activities, outputs, customers and metrics. Roles and Responsibilities Roles and responsibilities define and describe the active participants in the process, including the process owner, process manager, suppliers, customers and sta

Why Use a RACI Matrix?

Not too long ago, I was involved in a post implementation meeting for a change that was not very successful. During the meeting there was a very heated discussion, some of the comments I heard were:  ‘I thought you were going to do that’ ‘That is not my responsibility” ‘Why wasn’t I informed that this was occurring’ 'I have the responsibility, but not the authority to get the job done' ‘I knew how to fix the issue, but no one ever asked me’   It occurred to me that having a RACI chart would address these comments. The RACI model is a straight forward tool used for identifying activities and relating them to roles and responsibilities, thus avoiding confusion over who does what and how people are involved. The acronym RACI stands for:  Responsible : This role is responsible for the correct execution of process and activities. This person or persons do the work to achieve the task. Accountable : This role has ownership of the quality and the end result o

Collecting and Analyzing Requirements

Every ITSM framework and standard references the need to meet "customer requirements". Unfortunately, there is less attention paid to the process of collecting and managing those requirements. I am happy to report that the ITIL Service Design book contains some good high level guidance on "Requirements Engineering" (Section 5.1). Requirements Engineering is defined as "the approach by which sufficient rigor is introduced into the process of understanding and documenting business and user requirements and ensuring traceability of changes to each requirement." The section goes on to to describe a Requirements Catalog for documenting and managing changes to requirements. It also describes techniques and tools for gathering, analyzing and validating requirements with customers. ITIL defines three levels of requirements: Functional, Management and Operational and Usability. The Service Design book is particularly good for those who do not have a background in

Celebrating National Customer Service Week (Part 2)

It’s National Customer Service Week (NCSW). Held every year during the first week in October, NCSW provides an excellent opportunity to explore ways to better serve your customers. A great starting point is ensuring your policies, processes and procedures are customer friendly. What does that mean? Be a customer for a moment. What are the things that drive you crazy? Here is my list of pet peeves, along with a few suggestions. Limited options – Every process begins with a trigger. For IT organizations, a common trigger is a call to the Service Desk to report an incident or submit a service request. Times have changed. Increasingly customers want the ability to use other channels such as email, self-help via the internet, chat, and in many cases, all of the above. There are currently four generations in the work place, all who have very different expectations and desires in terms of how they obtain support. Are your processes keeping up with the times? Surveys, focus groups and needs a