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.
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
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
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 13, 2008
What about the OSA course?
Here is a question submitted by Curious about OSA.
Hello Dr. Jim,
It sounds like you have been very busy with v3F, both in its development and in obtaining certifications. So, congratulations on that! Now that you are certified in OSA, what advice do you have for others for taking the course and for taking the exam? —Curious about OSA.
Dr. Jim’s answer:
Well Curious, thanks for asking. Operational Support and Analysis (OSA) is a new version 3 course just launched by Pink Elephant. It will replace a version 2 course called IPSR (ITIL Practitioner Support and Restore). IPSR focused on the Service Desk, Incident Management and Problem Management.
The new OSA course, like the IPRC course is 5 days long. It focuses on the processes and functions of the Service Operation phase of the service lifecycle. The course covers the processes: Event Management, Incident Management, Request Fulfillment, Problem Management, and Access Management. It also covers 4 functions: Service Desk, Technical Management, Application Management and IT Operations Management. In addition it covers an introduction to Service Management and an introduction to the Service Operation phase of the service lifecycle.
The prerequisite for the OSA course is the v3 ITIL Foundations Certificate course or the v2 ITIL IT Service Management Essentials plus the ITIL v2-v3 Foundations Bridging Course. This means a basic understanding of the v3 Service Management Lifecycle is necessary for successful completion of the OSA Certification.
This course is especially useful for those that are involved in the OSA processes or functions listed above or those that may be involved in an ongoing service improvement program in an organization that has adopted ITIL.
But there is something new for the v3 intermediate courses like this one! The exam! The exams are eight multiple-choice, scenario-based gradient-scored questions. Whoa, what does that mean? The v2 Practitioner courses had 40 multiple-choice questions with one correct answer worth 1 point each. The passing score was 65% or higher. With the v3 intermediate courses, there are 8 scenario-based questions. Each question will have 4 possible choices:
• The best answer 5 points
• The second best answer 3 points
• The third best answer 1 point
• The distracter 0 points
The passing score will be 28 out of 40 points or 70% or higher. The best advice I can give you is to read the ITIL v3 Service Operation book (it’s exciting reading!) and choose Pink Elephant for delivering the course!
It’s a great course and can be found in a venue near you! Check the Pink Elephant website for more information. http://www.pinkelephant.com
Tuesday, November 11, 2008
Renowned UCLA Professor & Provocative IT Author Join Keynote Lineup For 13th Annual Conference
TORONTO, ON – Pink Elephant today announced the keynote speaker lineup for the 13th Annual International IT Service Management Conference and Exhibition, taking place February 22-25, 2009 at the Bellagio Hotel in Las Vegas.
Moshe F. Rubinstein, Professor Emeritus, UCLA
Bring The Future To The Present: Conquer Uncertainty
Named one of the Top 20 Professors of the Century at UCLA, Moshe F. Rubinstein is highly esteemed for his insights, expertise, and ability to infuse organizations with tools for decision making and innovation. He is a consultant to major corporations, a celebrated author of eight bestselling problem solving books, and has been invited to lecture all over the world.
In this keynote session, he will use his very engaging and passionate style to highlight how and why people and their social networks are the most important assets in organizations. In the past, capital and labor were critical for success; today it is human creativity, innovation, and collaboration that lead people to achieve the extraordinary. Using the power of a storyhe will show how great leaders bring the future to the present and conquer uncertainty; inspire people with a compelling noble purpose; create an environment for collaborative value; and evoke passion to permit the human spirit to soar!
The Big Switch
Nicholas Carr is a renowned author and IT expert whose 2004 book, Does IT Matter?, ignited a global quarrel about the strategic importance of IT in business. One of the highest rated keynotes from Pink’s 2005 conference, Nick is back with The Big Switch, a sweeping, and some say, often disturbing look at how a new computer revolution is reshaping business, society and culture. Telling his story in a lucid, engaging style, Nicholas weaves together history, economics and technology to describe how and why computers are changing – and what it means for all of us. From the software business to the newspaper business, from job creation to community formation, from national defense to personal identity, The Big Switch provides a panoramic view of the new world being conjured from the circuits of the “World Wide Computer“.
The conference will also welcome back entertaining keynotes Craig Ferguson, with “The Early Pink Show”, and Wayne Cotter, comedian and roving ITSM reporter. View entire keynote speaker lineup.
View the conference program, including tracks, sessions and speaker previews.
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
• 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)
• Configuration item
• Data and information
• Agreement (SLA / OLA)
• Availability plan
• Capacity plan
• ITSC plan
• Security requirement
• 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.