By applying granular product management to IT services, providers can more easily maintain a service portfolio while meeting customer demand for tailored services. Starbucks' offerings consist of a limited number of coffees, additives and sizes. This allows customers to order a large variety of individualized beverages while keeping the logistics behind them manageable (although my go-to Starbucks' crew is clearly composed of espresso padawans who have yet to master efficient one piece flow).
Customers want services delivered exactly the way they want. The happiest customers are the ones who are made to feel like it's the sole purpose of the service provider to make them happy. Designing for the customer entails understanding this particular customer's challenges and filling in the gaps between its own capabilities and expressed wishes. Basically, this means tailoring every offer a service provider makes, especially in tenders where the scoring system is biased in favor of meeting certain precise demands made by the customer.
Designing with a predictable margin and realistic service levels in mind demands that services delivered to customers consist of standardized, well-understood components across the board. Giving a diverse customer portfolio diverse services means losing control of the risk profile associated with delivering those services. Margins, if existent, become unpredictable and service level compliance is a game of hit and miss.
The dichotomy between what the customer wants and the service provider needs is mitigated by breaking down service components into more granular elements. This allows a service architect to finely tune a particular offering by mixing and matching an array of service components and levels.
IT service providers need to have three or four different back-end architectures ready to implement with different benefits in terms of performance, scale-ability and cost. Several flavors of workplace will be on the menu equipment to satisfy factories, office-based companies and BYOD hipster firms. Anything from once a week visits by the geek squad to 24x7 support are layered on top and sprinkled with consultancy for roadmaps, optimization projects and training.
Each service component has a separate owner, development cycle, cost structure and documentation. It's good to have a clear policy to guide their development and a strict regime for rotating services into production based on their readiness. Because the effort involved in delivering each service component is well understood and the necessary elements for the transition plan are pre-defined, the principal risks for the service provider are easy to manage
Whenever a new tender is received the service architect breaks down the requirements and groups them in such a way that existing service components can be matched to each and the provider's bid comes together like Lego and pricing is a snap.
Innovation of services and components can easily be executed as co-development with existing customers as part of continuous service improvement initiatives.
Showing posts with label Continual Service Improvement. Show all posts
Showing posts with label Continual Service Improvement. Show all posts
Tuesday, November 5, 2013
Wednesday, October 23, 2013
Lean Six Service Management
IT services and processes are highly suited for optimization using a Lean Six Sigma approach. The inherent drive towards continuous optimization in ITIL and the excellent alignment principles of MOF are very well complemented by Lean Six projects*. The frequent misunderstanding of performance metrics and effective optimization in IT departments, coupled with the abundant management information handily collected by ticketing tools makes this area of the business a prime candidate for some black belt attention.
A practical example:
A certain mature and successful service provider supplies helpdesk services, system administration and infrastructure as a service to a customer, a large and professional organization. During the tender phase certain reporting standards and KPI's were agreed upon. The service is managed by these metrics, with the provider paying a malus fine whenever average performance falls below certain levels. These levels are defined and agreed in a separate service level agreement.
After a year it is clear that the services, on average, are provided at or above the agreed service levels, but that the occasional breaches in incident resolution time are a significant source of dissatisfaction for the customer. The service provider knows the traditional method to improve service in this area is to add resources to the team that resolves incidents, but this is expensive since the customer pays a fixed fee and the margin of the provider relies on resolving incidents cheaply.
At the customer's urging, the service provider brings in a team of Lean Six Sigma experts to see if there is a better way. The team knows very little about service management, but a lot about process optimization. The service provider watches with interest as the problem is defined, large amounts of data are requested and fed into spreadsheets and some over-caffeinated sessions ensue where one variable after another is scrutinised.
A few surprising truth emerge from the project. Instead of adding resources, the service provider is better served by re-architecting their incident management process to lower the time it takes to resolve incidents by a just few minutes each. Lowering the error rate of the resolver group turns out to be very important as well. Both of these findings are meticulously researched and presented to the supplier's management team.
It turns out that lowering the error rate and the process cycle time of the incident management process correlate very strongly to performing within agreed service levels, and to lower costs per incident. Adding resources to the pool actually turns out to have little effect on resolution time, and has a negative effect on the cost per incident. In hindsight, this makes a lot of sense to the service provider. After all, once there are enough resources to handle a regular workload, adding more people means that some of them will have little to do most of the time, and the team will be bigger, more complex and more costly.
Also, the project finds that the already low error rate of the service desk is a bottleneck. Errors engender a lot of confusion and necessitate double work, greatly increasing the time it takes to resolve the incident. The project digs into the factors that affect the error rate and find it can be lowered by creating more knowledge items for the service desk. These provide technical information and checklists to ensure incidents are resolved correctly.
By using Lean Six Sigma to optimise the service, specifically the all-important incident management process, the service provider gets far more than a happy customer. It matures beyond using a standard remedy for a common problem. Instead, the issue is managed by calmly considering the facts, gathering the relevant data and improving the aspects of the service which cause a bottleneck in the process flow. In this case, decreasing the time it takes to go through the process by a few minutes and unlocking more knowledge for employees turned out to be powerful solutions which would not have been found or implemented otherwise.
This example perfectly illustrates the value of 'Lean Six' for Service Management. Service levels are dependent upon many, often indirect variables. Customer satisfaction often has little to do with 'three nines' uptime, which needs to be taken for granted. Cookie-cutter solutions really are not good enough in the highly competitive IT industry.
An outside-in view is the hallmark of a successful Lean Six Sigma project. By targeting the customer's dearest wish (resolve all incidents on time), considering supplier-side constraints (cost per incident), crunching the data on actual performance instead of agreed performance levels this project found the way to deliver the desired result, every single time. This is the sweet fruit of applying management science to the IT department.
*: Jack Probst and Gary Case published an excellent whitepaper on integrating Six Sigma and ITIL to practice continual service improvement way back in '09: http://www.best-management-practice.com/gempdf/sixsigma_itil_csi_wp_july09.pdf
A practical example:
A certain mature and successful service provider supplies helpdesk services, system administration and infrastructure as a service to a customer, a large and professional organization. During the tender phase certain reporting standards and KPI's were agreed upon. The service is managed by these metrics, with the provider paying a malus fine whenever average performance falls below certain levels. These levels are defined and agreed in a separate service level agreement.
After a year it is clear that the services, on average, are provided at or above the agreed service levels, but that the occasional breaches in incident resolution time are a significant source of dissatisfaction for the customer. The service provider knows the traditional method to improve service in this area is to add resources to the team that resolves incidents, but this is expensive since the customer pays a fixed fee and the margin of the provider relies on resolving incidents cheaply.
At the customer's urging, the service provider brings in a team of Lean Six Sigma experts to see if there is a better way. The team knows very little about service management, but a lot about process optimization. The service provider watches with interest as the problem is defined, large amounts of data are requested and fed into spreadsheets and some over-caffeinated sessions ensue where one variable after another is scrutinised.
A few surprising truth emerge from the project. Instead of adding resources, the service provider is better served by re-architecting their incident management process to lower the time it takes to resolve incidents by a just few minutes each. Lowering the error rate of the resolver group turns out to be very important as well. Both of these findings are meticulously researched and presented to the supplier's management team.
It turns out that lowering the error rate and the process cycle time of the incident management process correlate very strongly to performing within agreed service levels, and to lower costs per incident. Adding resources to the pool actually turns out to have little effect on resolution time, and has a negative effect on the cost per incident. In hindsight, this makes a lot of sense to the service provider. After all, once there are enough resources to handle a regular workload, adding more people means that some of them will have little to do most of the time, and the team will be bigger, more complex and more costly.
Also, the project finds that the already low error rate of the service desk is a bottleneck. Errors engender a lot of confusion and necessitate double work, greatly increasing the time it takes to resolve the incident. The project digs into the factors that affect the error rate and find it can be lowered by creating more knowledge items for the service desk. These provide technical information and checklists to ensure incidents are resolved correctly.
By using Lean Six Sigma to optimise the service, specifically the all-important incident management process, the service provider gets far more than a happy customer. It matures beyond using a standard remedy for a common problem. Instead, the issue is managed by calmly considering the facts, gathering the relevant data and improving the aspects of the service which cause a bottleneck in the process flow. In this case, decreasing the time it takes to go through the process by a few minutes and unlocking more knowledge for employees turned out to be powerful solutions which would not have been found or implemented otherwise.
This example perfectly illustrates the value of 'Lean Six' for Service Management. Service levels are dependent upon many, often indirect variables. Customer satisfaction often has little to do with 'three nines' uptime, which needs to be taken for granted. Cookie-cutter solutions really are not good enough in the highly competitive IT industry.
An outside-in view is the hallmark of a successful Lean Six Sigma project. By targeting the customer's dearest wish (resolve all incidents on time), considering supplier-side constraints (cost per incident), crunching the data on actual performance instead of agreed performance levels this project found the way to deliver the desired result, every single time. This is the sweet fruit of applying management science to the IT department.
*: Jack Probst and Gary Case published an excellent whitepaper on integrating Six Sigma and ITIL to practice continual service improvement way back in '09: http://www.best-management-practice.com/gempdf/sixsigma_itil_csi_wp_july09.pdf
Friday, September 9, 2011
Creeping elegance
Programmers tend to be perfectionists, and are familiar with a phenomenon known as
creeping elegance. While writing code, it becomes an obsession to write it as tersely
and elegantly as possible, which comes at the expense of time, readability and focus on
the final product.
Projects can also experience creeping elegance, in this form an insidious variety of scope creep. Say there's a process optimization going on in a very basic environment. Little documentation, lots of informal procedures, opaque and implicit knowhow ingrained in the employees, organic structure, the works. The project brief states that the goal is to document knowledge and procedures, design and roll out a standardized process, and train employees in the new and formal way of working. The allotted time is nine months, 5 internal people are put on the project for 20% of their time, and three consultants are hired.
A year later, a cold cup of coffee overhears a debate about indentation in the new documentation template, mixed with comments on the frequency of detailed status reports. The cup quietly reflects that, just like twelve months ago, neither the template nor the report are used operationally, but once the project is done they will surely be things of awesome perfection, terrible to behold and a slap in the face of any IT department who gets by with a lesser standard.
What happened? Creeping elegance. It's very hard to decide when to stop once you're improving something. At what point has enough knowledge been documented? When is a process good enough? That's undefined. It's not like a building plan where you're done at some point, when the building stands tall and happy tenants are preparing dinner inside.
Operationally, this is easy. Continual Service Improvement (CSI) is the name of the game. Steady progress. But when improvement becomes a project, it's very hard to keep the creeping elegance genie in the bottle. The only solution is strict timelines, and a project manager with enough common sense to nip creeping elegance in the bud. When the sand runs out in the hourglass, whatever is agreed on is delivered as the final product, and operational CSI takes over. Mission accomplished.
Projects can also experience creeping elegance, in this form an insidious variety of scope creep. Say there's a process optimization going on in a very basic environment. Little documentation, lots of informal procedures, opaque and implicit knowhow ingrained in the employees, organic structure, the works. The project brief states that the goal is to document knowledge and procedures, design and roll out a standardized process, and train employees in the new and formal way of working. The allotted time is nine months, 5 internal people are put on the project for 20% of their time, and three consultants are hired.
A year later, a cold cup of coffee overhears a debate about indentation in the new documentation template, mixed with comments on the frequency of detailed status reports. The cup quietly reflects that, just like twelve months ago, neither the template nor the report are used operationally, but once the project is done they will surely be things of awesome perfection, terrible to behold and a slap in the face of any IT department who gets by with a lesser standard.
What happened? Creeping elegance. It's very hard to decide when to stop once you're improving something. At what point has enough knowledge been documented? When is a process good enough? That's undefined. It's not like a building plan where you're done at some point, when the building stands tall and happy tenants are preparing dinner inside.
Operationally, this is easy. Continual Service Improvement (CSI) is the name of the game. Steady progress. But when improvement becomes a project, it's very hard to keep the creeping elegance genie in the bottle. The only solution is strict timelines, and a project manager with enough common sense to nip creeping elegance in the bud. When the sand runs out in the hourglass, whatever is agreed on is delivered as the final product, and operational CSI takes over. Mission accomplished.
Subscribe to:
Posts (Atom)