Skip to main content

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

Comments

Popular posts from this blog

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 policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…