Tuesday, March 31, 2009
Service Management Systems & Tools
In my last blog entry, I discussed the first of five aspects of Service Design, namely the design of the service solutions. In this entry, I will discuss the Service Management systems and tools. At this point, I will not really cover the Service Portfolio for the management and control of services through their lifecycle.
I have already covered the Service Portfolio in an earlier blog entry on February 07, 2008.
Section 3.6.2 Designing supporting systems, especially the Service Portfolio pages 33 to 35 (inclusive) provides insight into the service management tools required supporting the services provided by the organization.
So what are these tools? Section 3.6.2 provides a short list of tools. They are:
• Service Knowledge Management System (SKMS)
• Configuration Management System (CMS)
• Service Desk system
• Capacity Management Information System (CMIS)
• Availability Management Information System (AMIS)
• Security Management Information System (SMIS)
• Supplier and Contracts Database (SCD).
Organizations already have many if not all of the above tools, or at least their components. Why do I say components? Organizations have made huge investments in tools over the years and they provide various functionalities. There are so many tools on the market today ranging for ITSM suites to very specialized ones. I will not name any for fear of missing one or giving readers the wrong impression if I name one tool ahead of another even if the list was in alphabetical order.
I will not discuss the compatibility of the tools to ITIL either. For this, please look at the PinkVERIFY section on our website for the requirements and for a list of tools currently certified compatible with ITIL.
Instead, let us have a closer look at the tools mentioned above.
• Service Desk system
• Capacity Management Information System (CMIS)
• Availability Management Information System (AMIS)
• Security Management Information System (SMIS)
• Supplier and Contracts Database (SCD)
Although these systems are extremely valuable, I consider them part of the larger view of the CMS and the SKMS. However, we should not ignore them or treat them as second-class citizens. What the book and I are suggesting is that these tools should be integrated, which I know from painful personal experience to be easier said then done.
The above tools will be used not only in Service Design, but also in Service Transition to plan, build, validate, deploy, and evaluate new or modified services. Of course, many of these tools will assist the Service Operation functions personnel involved in Service Operation processes such as Event Management, Incident Management, Problem Management, Access Management, and Request Fulfillment.
As part of the Service Desk tool set, I include the ITSM suite as well as the phone system and email, as they are the primary communication tools used.
As part of the capacity, availability, and security systems, I also include all of the monitoring tools that may assist theses three tools.
Let us not forget that all of these tools will provide valuable data and information to the CSI phase.
Service Knowledge Management System (SKMS) and Configuration Management System (CMS)
All processes, functions, and management levels will use these two logical central repositories of data and information. What is important to look at here are the top two layers: knowledge processing and presentation.
If we compare the SKMS (Service Transition book, figure 4.39 page 151) and the CMS (Service Transition book, figure 4.8 page 68) we can see that the data and information layers are basically the same. Yes, there are differences for the names of the various databases, but the concept is the same. The knowledge processing layers are the same.
The most significant difference is at the presentation layer. The SMKS suggests the following views IT Governance: Quality Management View; Services View; Asset and Configuration View; Service Desk and Support View; and Self Service View amongst many others of course. What we have here is a list of views for the management of services and processes from strategic and tactical perspectives.
The CMS view on the other hand proposes a more tactical and operational view of services and processes. The views proposed by the CMS are the Change and Release View; Asset Management View; Configuration Lifecycle View; Technical Configuration View; Quality Management View; and Service Desk View amongst many others again.
So, all these tools are there to assist us through the lifecycle of our services; but, how do we set them up?
I do not have a technical solution; I will leave that to the tool experts. However, we can look at this from a conceptual perspective.
Imagine the home page of your intranet as your Service Portfolio. From there and based on their user profiles, people can view the three main sections of the Portfolio, the Pipeline, the Service Catalog (made up of the business service catalog and the technical service catalog) and the retired services.
Within each of these sections, people can select the service that interest them and have access to a wealth of data and information. This information is stored in the SKMS, in one of the many data sources. People have access to these data sources through the various interfaces provided, the tools mentioned above, as well as many other sources such as the various ITSM tool modules.
Monday, March 23, 2009
Aspects of Dervice Design: Service solutions
Over the next five entries, I will explore the five aspects of Service Design. They are from the Service Design book, section 3.6 on page 30:
1. Service solutions, including all of the functional requirements, resources and capabilities needed and agreed
2. Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle
3. Technology architectures and management architectures and tools required to provide the services
4. Processes needed to design, transition, operate and improve the services
5. Measurement systems, methods, and metrics for the services, the architectures and their constituent components and the processes
Service Solutions
Section 3.6.1 of the Service Design, pages 31 to 33 (inclusive) provides some very good explanation of what this aspect is. However, Let us look at linking of service solutions to the other concepts introduced so far. These concepts are utility and warranty, capabilities and resources and the Four Ps of Service Design.
Let us first look again at the definition of a service, which is “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks”.
We have seen so far that value is delivered to the customer through of combination of utility and warranty.
Utility is about
a. Maintaining or improving performance or
b. Removing constraints
Warranty is about having enough availability, capacity, continuity, and security.
Bullet number “1.” above on service solutions talks about functional requirements, resources, and capabilities.
Can functionality address utility? I believe the answer is yes. Adding functionality is about removing constraints.
Adding functionalities can be about improving performance. For example, business tasks can be accomplished faster and with more ease through automation.
When discussing functionality requirements with the customers, we often hear comments such as:
I want the application to do… This is about removing a constraint
I want the application to process so many… this is about performance
Can functionality address warranty? Again, the answer is yea. A function of a service is to be “available” when the customer needs it. The capacity of a service is influenced by the demand that in turn affects the performance. There needs to be sufficient capacity to meet the performance requirements. The continuity of a service is about the ability to continue to provide the service during a crisis. The design of the countermeasures must take into consideration, the utility, and warranty aspects that need to be delivered during a crisis. The security of a service affects the availability of that service, definitely the continuity as an organization need to establish security measures during a crisis and security will affect capacity; too many security measures will impede the performance.
So designing a service solution requires the organization properly identifying the business requirements, from a utility and warranty perspective. So what’s next?
IT must now look at the resources and capabilities it requires and compare them to the existing resources and capabilities at its disposal; easier said than done. Let us look at resources first.
- Do we have the financial capital?
- Do we have the infrastructure?
- Do we have the applications?
- Do we have the information?
- Do we have the people?
So where can we turn to, to answer these questions? In an ideal world, the answer would be to consult the following information systems; capacity management (CMIS), availability management (AMIS), information security (ISMS). The following management systems would provide valuable information, configuration (CMS) and service knowledge (SKMS) among others.
However, reality being what it is, these systems may not be in place. Wrong! They are in place. Except they often reside in the desktops and laptops of the IT personnel in multiple file format and with various digress of completeness and accuracy. It will be difficult to sift through this information but there is a way around it. Ask the IT personnel. They have a wealth of knowledge, experience, and skills.
We know our people, their skills, and knowledge. We know what applications we have. We know what our infrastructure is made of. It may not be 100% but it is much better than having nothing or moping around claiming the glass is half-empty already.
It should be relatively easy to find out what the resources are within a certain degree of accuracy. Start somewhere.
Now that we can find a way to identify our resources, we need to shift our attention to our capabilities.
- What are the capabilities of our management team?
- What are the capabilities of our organization?
- What are the capabilities of our processes?
- What are capabilities of our knowledge?
- What are the capabilities of our people?
There is a way to start answering these questions. Use a simple SWOT analysis concentrating of the five topics above.
- What are our strengths?
- What are our weaknesses?
- What are our opportunities?
- What threats are we facing?
Of course nothing is linear and everything is iterative and dependant on each other. For example, of the utility component is about performance. The capacity Management is very useful to design the appropriate infrastructure for optimum performance. However, we need to understand what the demand it. All this depends on when the service must be available. We also need to understand about the appropriate performance levels. We cannot ignore the fact that we have partners assisting us. Two more things, we need to plan for a crisis and we need financial capital to do all this.
Please do not forget there are four other phases to this picture.
In the next blog entry, I will be taking a closer look at the Service Management systems and tools.
Until next time.
Friday, March 20, 2009
THE FOUR PS OF SERVICE DESIGN
In this blog, I covered resources and capabilities, utility and warranty and service definition. I have shown that all are connected in an intricate pattern. Before I start discussing the various aspects of Service Design (there are five but that is the topic of an upcoming series of blog entries) I want to explore the Four Ps of Service Design.
“Fail to plan, plan to fail” – source unknown
Most, if not all, of us have been involved in situation where the lack of preparation and management caused the designs, the plans, and/or projects to fail.
The Service Design book, section 2.4.2 on page 16 has this to say about the four Ps.
“The implementation of Service Management as a practice is about preparing and planning the effective and efficient use of the four Ps: the People, the Processes, the Products (services, technology, and tools) and the Partners (suppliers, manufacturers and vendors)”
Let us go back to the capabilities and resources for a moment. As we have already seen, the resources are
1. Financial capital: you need money to pay for the people so they can design, build, implement, use, and improve the processes. You need money to pay for the products and the partners.
2. Information: the people and the partners, require access to information about the products so that they can execute the processes effectively and efficiently.
3. Applications: To me a product is the physical manifestation of a service. The end-user recognized the application not necessarily the service. People and partners need to use processes to manage the lifecycle of the product, in this case the application
4. Infrastructures: To me a product is the physical manifestation of a service. The end-user recognized the infrastructure not necessarily the service. People and partners need to use processes to manage the lifecycle of the product, in this case the infrastructure
5. People: The right skills, the right knowledge, the right level of experience kept current. The people will deploy and use the resources, liaise with partners, use processes within the limits of the allocated financial capital.
Here is a quote from the Service Design book, section 3.6.3.1 on page 40 about taking people for granted.
However, IT faces a big challenge in developing and maintaining the soft skills required to perform these management roles and processes effectively. In the truly efficient organizations, these roles and processes are aligned to those of the business. This ensures that the business and IT Management processes and information have similar targets and goals. However, all too often, organizations devote insufficient time and effort to the development of the soft skills (for example, interpersonal skills, communication skills, and meeting skills) necessary for the processes and the business alignment to be effectively achieved.
Let us go back to the capabilities and resources for a moment. As we have already seen, the capabilities are:
1. Management: we are taking here about the ability to make sound business decisions using various business processes. This requires the use of applications, infrastructure, and information. Managers also need the right set of skills and possess the right level of knowledge. Managers may also make use of partners as well.
2. Organization: As a whole, an organization requires not only resources but also it must make effective and efficient use of the Four Ps in order to be successful. An organization is more than the sum of its parts. The culture of the organization is critical in ensuring the success of the organization.
3. Processes: We must include business and management decision processes, as they are key elements of a successful organization. This is after all one of the Four Ps.
4. Knowledge: We need to consider the knowledge that people bring to an organization through their experience and the information gathered by the organization and make sense of it. Tools can do amazing things with data and information but only people are able to translate into knowledge that will help management make the required business decisions. Knowledge will be hampered by the lack of, and having too much, information. Knowledge management as a process has been around for a while but people, and partners but
5. People: What are people capable of doing? The current organizational situation will have a profound effect on people’s capabilities. A lot could be said about the lack of financial capital, obsolete infrastructure, the inability of applications to integrate, questionable data and lack of personnel. However, I do strongly believe that one of the biggest obstacles to all the capabilities is a lack of communication. This includes a communication plan, credible sources and messengers as well as a severe lack of a real feedback mechanism.
A good way to look at the relationships and integration points between the Four Ps and the capabilities and resources would be approach it using a three-dimensional concept.
The x-axis is the Four Ps.
The y-axis is the resources
The z-axis is the capabilities
Of course, a simple two-dimensional diagram with the x-axis for the Four Ps and the y-axis for the resources and capabilities would be useful as well.
In The next blog entry, I will start to explore the five aspects of Service Design. They are from the Service Design book, section 3.6 on page 30:
- Service solutions, including all of the functional requirements, resources and capabilities needed and agreed
- Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle
- Technology architectures and management architectures and tools required to provide the services
- Processes needed to design, transition, operate and improve the services
- Measurement systems, methods, and metrics for the services, the architectures and their constituent components and the processes
Monday, March 16, 2009
Let’s start with Service Design
Let’s start with Service Design
People seem to make a big deal about the Service Design Phase. Not only the processes within that phase are rarely officially “implemented” but also people look at Service Design as if it were a mythical beast from Greek tragedies.
The Service Design book introduces the five aspects of Service Design in section 3.6 on page 30. They are:
■ Service solutions, including all of the functional requirements, resources and capabilities needed and agreed
■ Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle
■ Technology architectures and management architectures and tools required to provide the services
■ Processes needed to design, transition, operate and improve the services
■ Measurement systems, methods, and metrics for the services, the architectures and their constituent components and the processes
The above is quoted directly from the book. However, what are those aspects really about. Let us have a look.
Service solution: Define your services in non-technical language not in techno-babble-jargon. That would be the Business Service Catalog part. The next step (Technical Service Catalog anyone?) is to describe the services based on business requirements (what a concept!), identify the resources (financial capital, infrastructure, applications, information, and people) and your capabilities (management, organization, processes, knowledge, and people).
Service Management systems and tools: this would be to identify the Service Management Systems such as the ITSM suite. If you already have one, there is not much more to do here except perhaps to confirm it is compatible with ITIL. The Service Portfolio appears to be this huge mountain to climb. Well, it is not. Start by identifying the live services and the ones you no longer offer. Then look at what is being built (i.e.: in transition) as well as the one being planned such as the ones you are compiling business, technical and functional requirements (to name but a few). Identify the ones that people are considering but not been formally approved at this time. The services at the concept and design stages represent your service pipeline. The services in transition and live represent your service catalog and the service no longer offered are the retired services. Together, the pipeline, the catalog, and the retired list make up your portfolio.
Technology architectures and tools required Most, if not all of this is already in place. You already have an IT architecture and, someone, somewhere, has it pretty well documented. If you have a CMDB, well you are ahead of the pack here. You have tools to code and program. You have a network. You have monitoring tools. You have distribution tools. etc. Once the tools have been inventoried, map them to the lifecycle phases. They may be used for one or maybe all phases.
Processes needed: There are 24 processes in ITIL. I will argue that your organization is performing the activities of all the processes. You may not call them the same as ITIL. The activities may not be documented and are probably done with various degrees of success throughout the organization. However, they are there. Identify them and put structure and governance around them. Formalize the most visible ones and the ones that would put a stop to the “hero” mentality of the organization.
Measurement systems: Look to the CSI book for more details but you should know by now there are three types of metrics, technology, process, and service. The vision of the organization will drive the goals that in turn define the objectives. The objectives are supported by Critical Success Factors that are proven by Key Performance Indicators. In order to measure the KPIs, you need to identify the required metrics before you can start measuring and monitoring things.
In my next entry I will tie in the five aspects to the four P’s of service Design.