Skip to main content

Posts

The Different Types of Service

In the Strategy stage of the Service Lifecycle there are several questions an IT service provider must ask in order to determine the services they should be delivering, whom they should be delivering them to and is value creation and capture possible.  They are:  What is our business? Who is our customer? What does the customer value? Who depends on our services? How do they use our services Why are they valuable to them?  Given the answer to those questions, the service provider can then determine the types of services to be delivered, resources needed and what risks and constraints need to be identified and managed.   There are three types of services the provider will have to consider, supporting services, internal customer facing and external customer facing services.  Services whether internal or external are further broken down as core, enabling or enhancing.   Here we will be looking at supporting, internal and external facing services. Supporting Services:   A serv

The Evolution of a Definition

The definition of an IT service has certainly evolved: IT Service   (ITILv1) :     A set of related functions provided by IT systems in support of one or more business areas, which in turn may be made up of software, hardware and communications facilities, perceived by the customer as a coherent and self-contained entity. An IT service may range from access to a single application, such as a general ledger system, to a complex set of facilities including many applications, as well as office automation, which might be spread across a number of hardware and software platforms. IT Service   (ITILv2) :     A set of related components provided in support of one or more business processes. The service will comprise a range of   Configuration Item   ( CI ) types but will be perceived by   Customers   and   Users as a self-contained, single, coherent entity. IT Service   (ITILv3) :   A   Service   provided to one or more   Customers , by an   IT Service Provider . An IT Service is base

Process Maturity – How can I Assess it?

A process is doomed if you ever consider it done!  Unlike an audit that examines evidence to determine compliance, a process assessment is conducted to evaluate and organizations strengths and weaknesses.  The assessor will ensure that this baseline is utilized to identify process improvement opportunities that ensure business outcomes. The ITIL Process Maturity Framework (PMF) was defined specifically for ITSM processes and consists of five levels of maturity. ·          Level One – Initial At this level there is not a defined process, there are some procedures and few results are retained. ·          Level Two – Repeatable At this level of maturity there is a recognized process but the objectives are not clear and targets are not formalized. ·          Level Three – Defined It is at this level of maturity that the process is defined and documented and there are agreed upon targets. ·          Level Four – Managed A managed process at this level is well defin

Process Maturity – Documenting the “As Is” Process

There are many challenges to defining and documenting a process for ongoing continual improvement and to ensure process maturity is in alignment with the overall business strategy and outcomes.  One such challenge is to be able to document the “As Is” process. When documenting the “As Is” process caution must be taken not to accept the existing documentation, or flowcharts provided as the true baseline of what is really being done.  What are the current activities and procedures that are being used and what is the step by step workflow that participants and stakeholders are actually performing?  The actual is what really needs to be captured.  The complexity of this challenge is exasperated by the fact that frequently when determining and “As Is” state for immature processes the assessor or process design engineer will discover that there is not one single process that is being followed but in fact many?  What then? Non adherence to process is generally due to little or

Process Maturity – How do I measure it?

In order to manage and control processes and services, they have to be monitored and measured. The design of the measurement methods and metrics used to measure process are critical to success and might even be the most crucial element.  In practice we tend to see Critical Success Factors and Key Performance Indicators defined in the process documentation but is anything being done with those? We not only need to define the metrics for measuring the process but also must ensure that the design and implementation of the process also includes a system for ongoing monitoring, reporting and most important action for continual improvement of the process. Without it the process is destined to fail. Process designers must assert caution and use wisdom when defining the metrics and measurements for the process.  Careful consideration must be given to how these measurements are going to affect and change the behavior of the practitioners and stakeholders that produce or receive value

Process Maturity Requires - People, Process, and Technology… Let’s talk Process!

I recently heard an ITSM manager state… “The engineers think that it is the process that is slowing us down” then he went on to say “Of course we here all understand that the process is intended to slow us down”!  I was waiting for others in the group to comment and no one mentioned a word.   WHAT?!   Is that really ever the intention or the purpose of a process? What a process is – or should be A process is a set of activities with predefined inputs and outputs which are intended to meet the needs of the business and stakeholders!  A process has clearly defined roles, responsibilities, and workflow. When was the last time you heard a business representative say could you design a process to slow things down?  In reality we need to look at how we can design processes or activities within the organization to increase quality and speed!  The real challenge is how do we do that?  How can we get just enough process and control for consistency, automation, and speed and yet

Happy Birthday ITIL!

ITIL is turning 25 this year.  In honor of this milestone, AXELOS commissioned a study ( The Importance of ITIL® – A Global View – 2014 and Beyond ) to provide a global and independent assessment of the current perception of ITIL, engaging nearly 400 C-Level and medium tier service managers in key international regions across a range of industries. One of the stated reasons that the study was commissioned is because ITIL’s benefits are being questioned in light of factors such as cloud computing, more advanced automation, and agile. The results of the study reaffirm ITIL’s value, particularly in the eyes of IT executives. In fact, according to the study, just under 70% of executives indicated that ITIL is becoming more important in light of these trends. Some interesting results include: 71% of those surveyed view ITIL as playing a tangible role in supporting the move to DevOps and Agile  ITIL 2011 adopters are more likely to see ITIL as growing in importance   40%

Service Strategy and the Service Portfolio

Service Portfolio Management is a process that ensures that an organization has the right mix of services to meet business and customer requirements.  Strategists can use the service portfolio to evaluate offerings that are under consideration for investment and also to determine which services should be retired!  A complete history of people, process, technology and information from concept to end of life could be tracked via the service portfolio.  This investment framework is a valuable asset to every service provider.  The Service Portfolio and the activities performed in service portfolio management process serve as an overall basis for making strategic decisions regarding service offerings.  Major changes (those requiring executive approval) will be processed through the service portfolio management pipeline.  It is here that a proposal is defined, analyzed, approved and chartered before moving into service design and more importantly before moving to project management.  

SACM (Configuration Management)

Service Asset & Configuration Management (SACM) is genuinely the one process that touches all of the other ITIL processes. SACM delivers accurate and up-to-date data and information to every other process across the lifecycle.   What is really cool about SACM is that in many cases it depends on those other processes through their defined, documented and agreed to activities, to help insure that the data and information about those assets is up to date , accurate and properly recorded through the Configuration Management System (CMS),    No organization can be truly efficient and effective without having a configuration management process to insure we understand how and where that infrastructure, application, tools, documentation and sometimes even people are being utilized in delivering business outcomes and creating value. Service Asset & Configuration management ensures that CIs (configuration items) are properly identified; baselined and that changes made to them are pr

ITSM - The A B C’s of Financial Management

At the core of IT Service Management is the ability of the service provider to align capabilities to meet business requirements.  Not only is it expected that the service provider does this but today’s market requires that we provision faster than ever before for the least amount of cost. This requires a shift from looking at costing models that focus primarily on components such as HW, SW, or other infrastructure costs to a model that looks at what is it costing us to provision the end-to-end service.  When we think of Financial Management most will immediately think of number crunching, bean counters, and all those mathematical formulas that go along with that.  It is all of that.  We need to be able to create business cases and to justify the cost of new or changed services in our environment. Financial Management for IT services will certainly include calculations for Return on Investment and Internal Rate of Return as well as assistance in assessing the overall Value on Investmen

CPDE (Design considerations)

So who should consider becoming a Certified Process Design Engineer?   Well anyone can consider it.   Is your organization engaged in some type of certification, working to reach some optimized level of maturity, trying to improve the processes you already have or create a process to meet some new customer requirement? All of these scenarios would employ the skills of a CPDE. To start with, no matter which framework or standard you are utilizing processes must be: Defined Documented Managed via performance metrics Continually improved Undertaking this effort is not as simple as it may appear and having a staff member with the necessary skills and capabilities (CPDE) ensures that clear and measurable improvement targets along with a process design approach can and will be carried out.   You first must understand the factors that are triggering a process improvement initiative.   They may include: Changing customer requirements Processes that are to complex or have

The Certified Process Design Engineer (CPDE)

There are many frameworks and standards that define best practices for achieving quality IT service management (ITSM) - ITIL, ISO/IEC 20000, COBIT, CMMI, DevOps, Knowledge-Centered Support, etc. While each describes processes and controls (what to do), none provide clear, step-by-step methods and techniques for actually designing, reengineering and improving processes (how to do it). IT organizations must not only do the right things, they must do the right things right.   The CPDE takes a practical step by step approach to developing and implementing ITSM processes across the entire lifecycle of IT services.   It ensures integration with project and program management and the application and software development processes as well.   Allowing for strategic, tactical and operational alignment across the entire organization.   The CPDE is well suited to utilize these different best practices and additionally play a significant role in the DevOps movement that is taking hold in IT organi

Why become an ITIL Expert?

Are you a manager or practitioner in the IT Service Management Profession?   Would you like to advance in your IT career?   Perhaps you have many years’ experience in IT and service management and would like to increase your credibility.   According to information on ITIL-officialsite, ”The ITIL Expert level of qualification is aimed at those individuals who are interested in demonstrating a superior level of knowledge of the ITIL Scheme in its entirety.  Achieving this level of ITIL qualification will benefit a candidate in both their personal and professional development, by aiding career advancement and progression within the IT Service Management field.  Candidates who achieve ITIL Expert level will also satisfy the prerequisite entry criteria for the ITIL Master Level; the highest level qualification within the ITIL scheme.” The ITIL qualifications scheme offers a modular approach to the ITIL framework. In this scheme, candidates are free to select from a variety of qualifi

Cloud Services and Warranty Processes

As business organizations opt for support from the cloud to provision Software, Platform, or Infrastructure services the need for warranty through the service value chain becomes paramount. Service warranty is gained by achieving specified levels of availability, capacity, continuity, and security.  The dynamic, nature of the business and varied demand from multiple customers and user profiles must be considered when defining and investing in cloud architectures.  Each customer will expect that only their application or service will be delivered to users when in fact multiple customer and user communities could be leverage from the scalability and shared resources in the cloud. Availability/Capacity and the Cloud Service providers must gain assurance that multiple instances of the same application are delivered in a scalable manner.  In order to ensure availability and leverage capacity on demand additional tools and technologies such as load balancing, server virtualization

Velocity

Velocity , it’s just such a cool word!  When I type it, it just has to be italicized .   When I say it, I think of a speeding red Ferrari, a fighter jet or Superman zooming through the air to save Louis Lane from certain doom.  It’s one of my favorite TV channels.  In the world of Dev-Ops, Scrum and Agile it’s the rate at which a team converts items to “DONE” in a single Sprint, usually calculated in Story Points and is really one of the pillars of the DevOps. DevOps is a response to the symbiotic relationship of software development and IT Service Management and the historical disconnect that has usually separated these two very critical and interdependent functions.  This divide has often manifested itself as conflict and inefficiency . The purpose being to help an organization rapidly produce software   products and services while ensuring communication, collaboration and integration between these diverse professional groups. Development is usually of the mindset where ch

The Value of Release Models

To understand the concept of “Release Models” one must first understand the clear distinction between the Change Management process and the process of Release and Deployment Management.   At a high level you could say that the Change Management process activities assess, authorizes and control the change and that Release and Deployment Process will actually execute or implement the change. This helps to understand the difference between change and release but also to understand that there will be different skillsets and activities involved for each area.    Although Change and Release management processes in and of themselves do have clearly defined objectives, roles and responsibilities these processes do not stand alone and must consistently work together for seamless integration with all of the Service Transition processes including Service Asset and Configuration Management and Validate and Testing processes.   This is especially true when you set out to define “Release Models”

The Value of Problem Models

If a problem is the unknown cause of one or more incidents then how can I design a repeatable model for something that is unknown? The purpose of Problem Management is to manage the problems throughout their lifecycle. Problem Management seeks to not only to minimize the adverse effect of incidents by providing work arounds, but also seeks to eliminate outages, and prevent them from recurring again. In Incident Management ITIL defines an Incident Model as a predefined set of procedures based on type of incident.   So then what is a “Problem Model”?   Problem Models Not all problems are the same.   There are many different types of problems and each type will require unique roles and responsibilities, varied skill sets and different timelines and policies based on the complexity of the problem.   When considering how to design problem models consider the workflow required once the “problem” or is identified. Approach to Defining Problem Models One approach is to classify

The Value of Incident Models

An “incident” is defined as an unplanned interruption to an IT service, the reduction in the quality of an IT service or the failure of a CI that has not yet impacted an IT service.  The purpose of incident management is to restore a service to normal operations as quickly as possible by minimizing the impact of incidents on IT services.  Incident Management is the process responsible for managing the lifecycle of all incidents by ensuring, that standardized methods and procedures are utilized to record, respond and report on all incidents.  Additionally this process should increase the visibility and communication of incidents to the business and the IT support staff and thereby allowing greater alignment of incident management to the overall IT and business strategies.  In a normal IT environment the IT organization may be dealing with a large number of incidents and many of these are repeatable, something that has happened before and very well may happen again in the future.  I

The Value of Change Models

In ITSM as in life change is inevitable.   In order for us to continually deliver services that are meaningful and bring value to our customers, we must frequently update and upgrade not only the services we deliver but also the underlying infrastructure, technology and applications that are utilized and managed to deliver these services.   The ITIL definition of a change is “the addition, modification or removal of anything that could have an effect on the delivery of an IT service. The purpose of the change management process is to control the lifecycle of all changes, allowing us to make beneficial changes with minimal disruption to our current IT services.   The objective is to be able to respond to these changing requirements while safeguarding value and reducing rework.    Additionally ITSM must ensure that services continue to align to overall business strategy and that we have the processes and mechanisms in place to guarantee that all changes and the configuration items (C

Incidents and Problems

  An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service and is strictly a reactive process. A problem on the other hand represents a different perspective of an incident by diagnosing its underlying root cause, which might also be the cause of multiple other incidents. Incidents however do not always grow up to become problems.  While Incident Management activities focus on restoring services to normal operations as quickly as possible, Problem Management activities determine the root cause, find the most effective and efficient permanent resolution and ultimately prevent the incident from happening again.    Problem Management can be both reactive and proactive. Proactive Problem Management identifies weaknesses in the environment before actual incidents occur.  These can then be exploited as improvement opportunities.   Reactive Problem Management addresses problems that were identified from one or more incidents.      The pol