Thursday, November 27, 2008
A Generic Process Model - Part 1
In a previous entry in this blog I discussed the difference between overall process activities and specific process activites. I would like to continue this discussion by looking at the generic process model introduced in the Service Design book (figure 3.11, page 43). This process model is not exclusive to IT Service Management. It sohould be woven into the Business Process management stream (BPM). ITSM is only one of the may components of BPM.
There are three main sections in this diagram: process control, the process itself and the process enablers.
Let us start with the process control section. This section is comprised of five components: process owner; process policy; process objectives; process documentation; and process feedback.
OK, so a process owner is appointed, a process policy is developped and the process objectives are set. What about documentation? Basically, all the documents required for the proper management and execution of the process are identified. Some examples of documents include but are not limited to role descriptions, process flows, procedures, authority matrices, report templates, etc. What does this “process control” section has to do with the overall process activities? Everything! In order to properly manage a process, we need to ba able to plan, execute, verify and improve said process. Looks very familiar to the Deming’s cycle. Actually it is the Deming cycle.
Planning for a process is not limited to the “project” aspect. There is a need to plan the correct execution, the verification and the improvements as well. But what really needs to be managed? Actually the process enablers must be managed as part of the process control section. The process enablers are the resources and the capabilities of the process. These two concepts are described in depth in the Service Strategy book section 3.2.
Let us have a look at the resources first. They are financial capital, infrastructure, applications, information and people. Resources are “things” that a process either consumes or produces. It seems easy enough to say that we utilize people’s skills, knowledge and aptitudes throughout the lifecycle of a process. It also seems evident that in order to achieve this we need touse some capital to pay for the people involved. But what about the other three elements? We need to utilize the existing infrastrure, applications and the information at our disposal to execute a process. By doing so we may be modififying these three elements by adding and/or removing components. We produce resources as well. These may be considered outputs, but I would argue that these outputs is very likely to be the results of many processes working together to achive a result.
How can we say that we are utilizing/consuming or producing resources in an effective and efficient manner? We can establish this by looking at the capabilities. As there are five categories of resources, there are five categories of capabilities as well. They are management, organization, processes, knowledge and people. What is meant by management capabilities? We are not simply talking about the abilities and capabilities of the managers (actually this would be looking at the people resource), but rather about the ability to make sound business decisions. The decisions must be in line with the organization’s objectives and ethical at the same time. For this we need both delegation and empowerment. We need to trust the people to make the right decisions. But for this we need people with the right skills, aptitudes, attitudes and experience. These people also possess knowledge, but to make the right decisions, the people need to have access to information (a resource) and translate it into knowledge. There is a process called Knowledge Management but not everything can be entered into a database or documented. All the capabilities are interrelated. The organization, its structure and its culture influence the ability of the people to make decisions, as do processes; a bureaucratic process would stifle decision making while the lack of processes and knowlledge may result in inefficiencies.
Let us go back to the process control section. The five types of capabilities will greatly influence the way the process owner can affect change in a process. The selection of a process owner will be a reflection of the organization’s capabilities. The capabilites will also influence the process objectives and related policies. The same is true for documentation and for feedback. Telling a superior what he or she wants to hear, or not providing feedback in fear of reprisal is not conducive to good management. Not having the appropriate resources will also be detrimental to running an effective and efficient process.
So before you start designing a process flow or “improving” a process, have alook at the resources and capabilities at your dispocal. Look to the culture of the organization. I am not saying that a authoritive approach is worse or better than a “laissez-faire” attitude. It is simply important to know what’s around you.
Let us try to map the overall process activites (described in an earlier entry in this blog) to the process enablers. I am not mentioning people as they are both a resource and a capability and people are actually involved in all activities in the first place. Additionally I am not including financial capital since without it not much could be done. I know, budget cuts, do more with less, do it anyway but you have no budget. Believe me, “been there”, “done that”. And the economic downtrun we currently live in certinly does not make things any easier.
Capabilities for…
Planning and controlling deliverables - All
Scheduling deliverables - K
Communication - All
Authorization - O
Ensuring there are remediation plans - M, K
Measurement and control - M, O
Management reporting - M, P, K
Understanding deliverable impact - K
Continual improvement - M, K
Resources for…P
Planning and controlling deliverables - Info
Scheduling deliverables - Info
Communication - Info, infra
Authorization - Info
Ensuring there are remediation plans - Infra, App
Measurement and control - All
Management reporting - All
Understanding deliverable impact - Info
Continual improvement - Info
Legend
M = management, O = organization, K = knowledge, P = processes
Infra = infrastructure, App = application, Info = information
In an upcoming entry, I will map the overall process activites to the process elements. These elements are process activities, procedures, work instructions, metrics (that I expand to include CSFs and KPIs) roles and improvements.
Thursday, November 06, 2008
Process: Generic vs. Specific Activities
I would like to clarify something a common misunderstanding about processes and they way they are described in ITIL V3.
Early in my career I was privileged to be corrected by a wise manager who took me aside to explain to me the difference between management and control. She then went on to show me that managing looks at the whole picture, including such things as identifying skills and knowledge required, hiring, evaluating and motivating staff. She then explained that she had to understand the other departments (we did not use the word ‘process’ back then) and their deliverables. She had to understand the business goals and how to align the activities of her department and staff towards those goals. She had to ensure good communication, provide timely and accurate reports and plan on how to handle unusual situations (we used to call them problems back in those days).
Next, she went on to explain that my role as one of her staff was to control each of my assigned deliverables for which I was responsible. By the way, I was not in IT at the time but working as kitchen staff in a restaurant. My deliverables at the time were to wash the dishes. Hey, I was 19 and trying to pay for my education!
But, this lesson has always remained with me. Many years later, as I was delivering one of my first Service Manager courses, I came across a question that asked the difference between Change Management and change control. I was extremely surprised to discover that only one of the dozen or so delegates, all experienced IT professionals and managers, were not able to explain the difference.
Today, talking to many IT professionals I still find the same difficulty. People look at the ITIL literature and believe that the sample process flow provided in a section is the (only) way to go and is what the process is all about.
When we introduce people to the sample process model in the Service Design book (Figure 3.11 on page 43) people are surprised there are so many elements to a process.
When we point people to the Change Management section in the Service Transition book (section 4.6 pages 48-49) and show them the suggested list of overall process activities and specific process activities, again they are surprised. Of course, by now, many are confused. This is but a basic business concept. One of the issues is that too few IT people attend a basic introductory set of business courses top learn these concepts. There is hope as many IT programs in colleges and universities do now include business courses as part of their curriculum.
Going back to the Change Management section in question, we see that there are two sets of activities: overall and specific activities. This should have been included for most, if not all, of the processes, or at least those in the Service Transition and Service Operation phases.
I took the liberty to render the Change Management overall activities more generic.
Overall Process Management Activities:
• Planning and controlling deliverables
• Scheduling deliverables
• Communication
• Authorization
• Ensuring there are remediation plans
• Measurement and control
• Management reporting
• Understanding deliverable impact
• Continual improvement
Of course, there are other generic activities such as staff management, attending required meetings, education, providing feedback, etc. For more details, consult a good introductory management book.
On the other hand, there are the specific process management activities. These activities are handled by the department staff. For more on this, please consult the appropriate ITIL literature. To me, the specific activities center on one thing - handling the lifecycle of a deliverable. In essence, we are talking about the activities designed to control and manage the lifecycle from cradle to grave of a single:
• Event (notification, warning, alert)
• Request
• Incident
• Problem
• Access
• Transition
• Configuration item
• Change
• Release
• Test
• Evaluation
• Data and information
• Agreement (SLA / OLA)
• Contract
• Availability plan
• Capacity plan
• ITSC plan
• Security requirement
• Service
• Budget
• Improvement effort
In conclusion, when you need to design or develop a process, start with the above list of overall process activities and use the generic process model to ensure all elements are defined. Designing a process flow for most processes is quite simple and there are many good “pre-packaged” process products out there.
In an upcoming entry in this blog, I will discuss the generic process model.