The Technical Catalog

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization. In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog. In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support. The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure. It is this second view that we will review here.

Our service catalog provides us with a central source of information on all of the IT services delivered. It ensures that all areas of the business can view an accurate and consistent picture of their IT services, the details and their status. It displays the services in use, how they are intended to be used, the business process they enable and the levels and quality that the customer can expect to be delivered for each service. In the Technical/Supporting catalog we will document and blueprint the connections between our underlying supporting services and infrastructure to those business IT services. This will enable our ITSM organization to enable proactive Service Level Management and ensure more accurate and speedier incident management and change impact analysis processes just to name a few.

By having a clear and accurate picture we can ensure that during strategy sessions appropriate and wise decisions can be made about the current and future use of resources. This will include having an accurate financial picture through financial management for IT services. The Business Relationship Management process can ensure the right services are being delivered and can be appropriately supported.

In the design stage of our service lifecycle we can design improvements, additions, transfers or retirements without negatively impacting our current resources and services and their SLAs. Appropriate levels of capacity, availability, continuity and security can be delivered to meet the dynamic demand from our customers.

In Transition accurate risk assessments can be made through the utilization of our Technical/Catalog allowing our Change Management and Release and Deployment Management processes to more swiftly assess, build and release changes into the live environment meeting rapidly changing business requirements while reducing risk and the possibility of unproductive rework.

During Operations, the technical catalog is an essential tool for the service desk and their ability to carry out accurate and prompt remediation of incidents by presenting a clear roadmap in diagnosing incidents from descriptions of symptoms from customers on which services they are having issues. Problem Management can use these diagrams to do forensic investigation or proactive Problem Management and ensuring the SIPs can be completed more quickly with more robust resolutions.

Finally, within CSI all processes and functions will be able to see those opportunities for improvement by accurately finding those areas of our environment that will benefit from a redesign, update or enhancement.

For additional information and training please see http://www.itsmacademy.com/itil-sd/ ITSM Academy's next Service Design class will be August 22 - 26 2016

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People: Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products: These are the technology managem

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group . As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. Note: Goods may not always be provided for every Service Offe

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Search