Skip to main content

Posts

Perspective

About two years ago I wrote a blog on the four “Ps” of Service Strategy.  Today we going to expand on Perspective, the 1 st of the four “Ps” of Service Strategy.   Perspective is the vision and direction for the services you will provide, and is realized through conversations with your stakeholders.  A well-defined vision and mission statement allows a common goal to be pursued by both the business and IT. This enhances the organizations ability to focus on the customer perspective and the business outcomes that the customer desires, and to implement a continual service improvement approach so that you are regularly enhancing and differentiating the services you provide. In this way the business stays relevant to the changing business environment. The perspective describes what the organization is, what it does, who it does it for, how it works and enables this to be communicated easily to both internal and external stakeholders.  It defines the overall direction for the organiza

Why ITSM and DevOps? Ask NYSE, United Airlines, Microsoft…!

The NYSE reportedly told floor traders the exchange had to suspend trading due to an error with a systems upgrade that was rolled out before the market opened.  Early in the morning the NYSE sent out a message alerting traders that there was a reported issue with a number of the exchange’s gateways.  It appears that performance degraded from there and a few short hours later trading halted! ( http://fortune.com/2015/07/08/nyse-halt/   for full story ) How does this happen?  Other issues reported that same week included United Airlines who closed all flight bookings due to what was labeled a “Router” issue.   Microsoft GoToTraining impacted several business owners and customers due to a suspected “Citrix” upgrade.   If ever a case for why do we need Service Management processes that are aligned with business outcomes can be made, one only needs to listen to the news.  Just yesterday a computer system outage disrupted Spirit Airlines flights at Chicago O'Hare, forcing the carrie

Utility and Warranty

If you are in the position of providing IT services to customers then you know the importance of the statement: Utility plus Warranty equals Value (U+W=V).  So when we talk about value, we must consider who determines that value and what are the components that go into making up the agreements that will define how value gets created and delivered.  The value of a service is normally defined as “the level of service that meets customer expectations” and is often measured by how much the customer is willing to pay for the service. An industry trend today that may have been excluded in the past is the ability of the service provider to be able to define and document the costs involved in providing that service beyond its core value. Services being intangible and unlike products do not have much inherent value.  This value does not get realized until the service is actually utilized and enables someone to create the desired business outcome, which means that the provider of the servic

Improvement / Transformation As a Result of Disruptive Processes

I was recently asked about companies that have made improvements and/or had significant transformation as a result of disruptive processes.  The one that I am familiar with is Netflix and their philosophy of injecting failure into the production environment to ensure systems are fault-tolerant and how they continually test their ability to survive “once in a blue moon” failures. Introducing Chaos Engineering  -  Netfl ix Simian Army http://techblog.netflix.com/2014/09/introducing-chaos-engineering.html I did some additional Google searches:  “Disruptive improvements” & “Improving your IT services in a disruptive way”.  I think the following sites and resources provide more insight: Disruptive Business growth steps – Dow Corning https://www.dowcorning.com/content/publishedlit/solarticles/simple_steps.pdf IPhone success: Disruptive innovation and continuous improvement http://businesstheory.com/apple-teach-product-development/   Disruptive technolog

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

Transition Critical Success Factors (CSF’s)

IT is a large and growing slice of the overall budget for many companies. That money spent on IT is anticipated to create business value and support business growth. However in many IT organizations, a considerable percentage of this budget and IT labor is consumed on managing of incidents. First, second and third tier levels of support along with support technology and tools can become expensive to retain and maintain. In fact this is unplanned work which inhibits value creation and business growth. Many people will advocate a solid proactive problem management process to eliminate the root cause of these incidents and I am right there alongside them. However, I think we need to look even earlier in the service lifecycle. The standard statistic that I see most often quoted is that up to 80% of all incidents are cause by undocumented and unauthorized changes.  So for the sake of this argument let us take that as our baseline and discuss critical success factors facing service tran

Thoughts on People and Process

The “ Agile Manifesto ” states that “We value Individuals and Interactions over processes and tools”.  What? Some have taken that statement and interpreted it to mean that when it comes to design and development … “No Process” is required!  In fact if we look further in the manifesto we see clearly that the value of process and tools is indeed recognized.  The manifesto is trying to impart the importance of people and interactions.  If we have a brilliant process that is defined and documented and yet drop the ball when it comes to people and interaction we will surely miss the mark every time.  Therefore, while there is value in process and in tools service providers must value the people and interaction with them more. In her book titled “The ITSM Process Design Guide” Donna Knapp stresses the importance of “Just Enough Process”.  When designing ITSM processes such as Service Level Mgmt, Change Mgmt, Incident Mgmt and others, service providers could miss the mark and over design