Skip to main content

Posts

Showing posts with the label Service Operation

Service through Knowledge Management

I believe that a service provider can improve by choosing to follow best practices from ITIL, Lean, Agile and more.  That said I also believe that Knowledge Management will be the glue that ties in all together. Knowledge is required to deliver maximum results.  Knowledge Management ensures the right knowledge to the right people at the right time.  Think about yours or your customers service provisioning model.  How much time, money and resources is spent because of the lack of knowledge at the right time?  How frequently do we need information or access to the information and it is NOT available?  Not only is information not available when we need it, but sometimes it is replicated in many ways in many different places so that there is no real way to determine the definitive source.  It is difficult to get management control over the outcomes of an organization when the knowledge is out of control.  Knowledge Management is required throughout the Service Lifecycle.  A few exampl

Operation and DevOps

DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both   software developers   and other   information-technology   (IT) professionals while automating the process of software delivery and infrastructure changes.   It aims at establishing a culture and environment where building,   testing , and releasing software can happen rapidly, frequently, and more reliably. It’s about improving, communicating and collaboration.  From a Service Operation perspective we are already part of the way there, so maybe it won’t take as long or require as much organizational change as we think. Application management is responsible for managing applications throughout their lifecycle.  Application management covers the entire ongoing lifecycle of an application, including requirements, design, build, deploy, operate and optimize.   The application management function is performed by any department, group or team involved in managing and supporting opera

IT Services: External View vs Internal View

In every organization the one constant is change.  In operation all functions, processes, and related activities have been designed to deliver specific levels of service.  These services deliver defined and agreed levels of utility and warranty while delivering an overall value to the business.  The catch is this has to be done in an ever-changing environment where requirements, deliverables, and perceived value change over time.  Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.  One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever-changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more tow

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 servi

Failing Forward

In the introduction of her book The ITSM Process Design Guide, Donna Knapp writes “In today’s competitive business climate it’s not enough to do things right; Information Technology (IT) organizations have to do the right things right.”  Well what happens when we don’t? Remember New Coke?  Not every decision we make, every new design or redesign we engage in goes according to plan.  What happens when we fail?  One of the most important and most deeply entrenched reasons why established companies struggle to grow is fear of failure. In fact in a 2015 Boston Consulting Group survey, 31% of the respondents identified a risk adverse culture as a key obstacle to innovation. (1)  ITSM processes for strategy, design, transition, operation and CSI are all based on efficiency and effectiveness.  It’s about being in control of our IT environments and that we must do everything we can to prevent failures.  Now this may go against many of our strongly held beliefs but Pixar’s president, Ed Ca

Managing Across the Lifecycle

As the current IT organization has grown from a provider of technology to the Service Provider of choice we have had to incorporate the principles of service management to ensure that we deliver the outcomes required by our customers.  Given that, we have to ask ourselves a couple of strategic questions: What outcomes are we trying to provide? How do we as a service provider facilitate that? Delivering an outcome based definition of services will allow the IT organization to move beyond just business / IT alignment to towards business / IT integration, which really should have been the goal from the beginning.  Supporting customer / business outcomes should be the ultimate focus of the IT organization thus creating value through the delivery of services. A focus on business outcomes is both a critical and in most cases a cultural shift for IT service providers.  As customer’s preferences and perceptions change over time so does the value statement that a service provider

Service Operation and the Service Lifecycle – Yesterday and Today

ITSM Best Practice will align five main process with the lifecycle of “Service Operation”. Incident Management Problem Management Event Management Request Fulfillment Access Management  It was not too long ago that the idea of some of these processes were new to service providers. Most will find them to be common in today’s market place.  An organization may not literally follow the best practices for the service operation processes but most likely have some close facsimile when executing Incident, Problem, Request Fulfilment, and Event management processes for provisioning IT services and support.  In order to ensure identity management and authorization for access, some form of “Access Management” will also be needed to support an overall security policy in Service Operation.  I would like to focus on some thoughts for “Event Management” and early engagement of operational staff in the service lifecycle. As organizations mature they begin to realize the value

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

Balance in Service Operation IV

Previously, I have delivered several articles on the challenges that IT organizations face in trying to balance opposing goals and objectives especially in light of the fact that in every organization, the one constant is change.   The focus of those pieces described the tension between the perspective that IT is a set of technology components (Internal IT view) and that IT is a set of services (External business view).    They also spoke to the fact that, no matter how well the functionality of an IT service meets stake holder’s needs, it will be of little value if the IT infrastructure is unstable causing instances of unavailability and inconsistency in performance levels .   Of course we (IT/Service provider) must be able to do all of this at the same time as providing services that deliver acceptable levels of quality while efficiently utilizing the organizations resources. So to reiterate, this struggle can be broken down into four general imbalances so that an IT organizatio

Balance in Operation III

In every organization the one constant is change.   In service operation, all functions, processes and related activities have been designed to deliver specific level services.   These services deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.   Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation is to deal with the tension between these ever changing priorities. This struggle can be broken down into four general imbalances that provide the service provider an opportunity to develop some guidelines to resolve these conflicts: ·          Internal   IT view vs. External

Balance in Operation II

Last year I delivered an article on the challenges that IT organizations face in trying to balance opposing goal and objectives especially in light of the fact that in every organization the one constant is change.   The focus of that piece was the tension between the perspective that IT is a set of technology components (Internal IT view) and that IT is a set of services (External business view).    All process and functions in Design, Transition and Operation have been design to meet the changing needs delivered by Strategy and CSI.   Insuring that the resulting services continue to deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation together with design and transition is to deal with this tension between these ever changing priorities. S

The Best of Service Operation, Part 4

Event Management Activities Originally Published on November 9, 2010 In an earlier blog I was asked how to move from a reactive organization to a proactive one. My answer was through the use of Event Management, along with good design and proactive Problem Management. In this installment I would like to speak to the activities within Event Management and the impact they play in our ability to deliver a consistent level of services and a stable infrastructure to deliver them across. By definition an event is any detectable or discernible occurrence that has significance for the management of the IT infrastructure or the delivery of IT services. Event Management is the process that monitors all events that occur through the IT infrastructure to allow for normal operation and to detect and evaluate the impact any deviation might cause to the IT infrastructure or delivery of IT services. Event Management has several activities that we engage when implementing this process.  Event No

Stability vs Responsiveness

In an earlier blog I spoke to the conflicts that all operational organizations face.   This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more towards one extreme or the other.   At a high level it can provide the service provider with the opportunity to develop some guidelines on how to resolve these conflicts and move towards a best practice approach in resolving discrepancies.   We talked to the first and most common which was the Internal IT view vs. the External Business view.   Today I would like to speak to the dilemma of Stability vs. Responsiveness. IT operations must ensure that the IT infrastructure is stable, performs at an agreed and defined levels on a consistent basis and is available with the correct amount of capacity to meet the demands of ever changing patterns of business activity. These changes can be evolutionary.   Needed changes in functionality, performance

Balance in Service Operation

In every organization the one constant is change.   In operation all functions, processes and related activities have been design to deliver specific level services.   These services deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.   Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more to

Reasoning for Problem Management

When it comes to Problem Management two things should come to mind: Root Cause Analysis (RCA) and finding a permanent resolution. How often have you thought about what it takes to conduct these aspects of Problem Management? An important underlying aspect of conducting a Root Cause Analysis and finding the permanent resolution are the reasoning approaches used. Three types of basic reasoning approaches are: Inductive: Reasoning from specific examples to general rules Deductive: Reasoning from general rules to specific examples Abductive: Reasoning to the most likely answer Each has its own uses and can be applied to problem solving and Problem Management at different times and for different reasons. However, when performing the Problem Management process we should be open to using all three reasoning approaches. They all complement each other with Inductive and Deductive reasoning forming two ends of a spectrum while Abductive thought looks for the balance between the other two a

Enterprise Monitoring and the Service Lifecycle

I was recently asked where an entity such as Enterprise Monitoring resides in an organization. Should it be equivalent to the Operations, Engineering and Security areas rather than reporting to one those areas? Yes in some ways it does make sense to have Enterprise Monitoring at the same level. However, we must remember that there is a clear distinction and separation between the functions as proposed in ITIL and the activities that they perform. “Monitoring” is an activity related to a process (including but not limited to Event Management, Availability, Capacity, Service Level, etc.) So this work gets performed across an enterprise and not by a single, particular group. Anyone who needs to “monitor” something should use the associated processes to do so. Someone doing “monitoring” does not need to be located in any specific part of an organization. Functions are organization, location and structure agnostic. A function is not a place or management structure rather an abstract groupin

Event Management Reactive to Proactive

I have been asked by many students, how do you move from that role as the fire fighter resolving incidents to the role of being able to prevent them from occurring in the first place? Much of this has to do with good design and a strong proactive problem management process, but a solid event management process is an excellent offensive weapon in the prevention of impacting incidents in your environment. Event Management is the process that gives IT the ability to detect events, make sense of them and determine the appropriate control action. It is the basis for our operational monitoring and control. This gives us a way to compare actual performance against what was designed and written in SLAs. What is perfect about event management is that we can apply it to any aspect of our environment from delivery of a service, monitoring an individual CI, environmental conditions to software license usage. In conjunction with the other Service Management processes, along with both passive an

Examples of Major Incident Criteria

The Professor was recently asked for real life examples or best practices for the criteria that organizations have used to define major incidents. ITIL defines a major incident as an incident that results in significant disruption to the business and so real world examples are going to vary from one business to the next. For a financial services company, for example, a major incident could be an incident affecting live money transactions. For a retail company, a major incident could be an incident affecting its point of sale service. For a manufacturing company, a major incident could be an incident that affects the production line. Simply put… real dollars are being lost. A major incident could also be a service outage that affects are large number of users. Those users could be your company’s external customers, or it could be your internal employees. So for many organizations, outages affecting the company’s web site, or its email or customer relationship management (CRM) service

Application Management

When I teach ITIL V3 Foundation classes I often have to make the distinction between Application Management which is one of the “Service Operation Functions” and Application Development. I often begin my discussion by explaining that Application Development is responsible for the actual development and building of applications by the developers. Application Management is responsible for managing applications throughout their lifecycle and is performed by any department, group or team that is involved in managing and supporting operational applications. Additionally the function also plays a role in the design, testing and improvement of applications that form part of IT services. Application Management plays a key role in all applications whether purchased from a third party manufacturer or developed by in-house staff. During the design stage of the ITIL Lifecycle one of the key decisions made by Application Development is whether to buy or build. After that decision is made Applic