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.
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
Tuesday, October 8, 2013
Tools of the trade
For a company looking to take the next step in service management maturity, there are many great software solutions for IT Service Management Tooling. Many of them are cloud-based and can be used for a monthly fee instead of a large upfront investment in licences. This post explores some of the do's and don'ts in setting up new service management tooling.
A common mistake made by both small and surprisingly large IT departments (who should know better), is to merrily start implementing a shiny new tool and expect some positive effect. This without exception leads to an infamous IT project that takes way longer than planned. When it succeeds in its primary objective, the implementation itself, it fails to achieve any positive net effect on the department. Tooling vendors tend to over-emphasize the capabilities of the tool and understate the need for a thorough preparation. Preparation for new tooling involves at least prior alignment to end user expectations, proper demand and supply management within the customer's IT department meticulous process design and a lot of training.
Many IT service providers have responded defensively to this trend of ad-hoc implementations at their customers. Providers prefer to rigidly adhere to their own well-developed processes and tooling and prevent working with a variety of bad implementations across their customer base. Especially larger IT service providers are able to enforce their approach of standardized services and service levels on customers. However, enterprises are not consumer-level mobile phone customers and often respond poorly to this take-it-or-leave it treatment, leading to a low renewal rate on contracts.
The best results are obtained when customer and service provider are well-matched and can develop an approach respecting the suppliers need for consistency while enabling the customer to make large improvements in process maturity and make use of customised solutions. Tooling is very much secondary in this approach, being implemented near the end of the transition phase after services, processes, organization and accountability have been defined and aligned between customer and service provider. Once this alignment is in place, tooling can be set up in one of two ways: a shared instance or connected instances.
A common approach is to set up a single instance of the tooling that everyone, from end users to service resolver teams can use over their respective computer networks. This works well as long as customer and service provider agrees to use a common set of processes, which may well be in the case of co-development mentioned above. Rights management tends to be an issue in this kinds of setup, as it involves authenticating users and sharing protected data on two different domains.
Because by and large the available tools are based on ITIL and provide roughly the same options it's often possible to create a coupling between two instances. This allows customer and service provider to exchange ticket information between their respective ticketing systems. This way everyone can keep their own way of working while providing the requisite connectivity at a tooling level. Care must be taken to allow for data exchange in the SLA times, and reporting on the end-to-end ticket lifecycle can be challenging. If both customer and service provider are large enterprises with mature processes and able to build and maintain such a link, it is often well worth the investment. I'm still waiting for the IT service management bus which will make transitions and links between tools a much more pleasant exercise.
In short: do not skimp on preparation and try to find a good match between customer and service provider, this will greatly benefit service quality and help to defray indirect costs due to inefficient service delivery.
A common mistake made by both small and surprisingly large IT departments (who should know better), is to merrily start implementing a shiny new tool and expect some positive effect. This without exception leads to an infamous IT project that takes way longer than planned. When it succeeds in its primary objective, the implementation itself, it fails to achieve any positive net effect on the department. Tooling vendors tend to over-emphasize the capabilities of the tool and understate the need for a thorough preparation. Preparation for new tooling involves at least prior alignment to end user expectations, proper demand and supply management within the customer's IT department meticulous process design and a lot of training.
Many IT service providers have responded defensively to this trend of ad-hoc implementations at their customers. Providers prefer to rigidly adhere to their own well-developed processes and tooling and prevent working with a variety of bad implementations across their customer base. Especially larger IT service providers are able to enforce their approach of standardized services and service levels on customers. However, enterprises are not consumer-level mobile phone customers and often respond poorly to this take-it-or-leave it treatment, leading to a low renewal rate on contracts.
The best results are obtained when customer and service provider are well-matched and can develop an approach respecting the suppliers need for consistency while enabling the customer to make large improvements in process maturity and make use of customised solutions. Tooling is very much secondary in this approach, being implemented near the end of the transition phase after services, processes, organization and accountability have been defined and aligned between customer and service provider. Once this alignment is in place, tooling can be set up in one of two ways: a shared instance or connected instances.
A common approach is to set up a single instance of the tooling that everyone, from end users to service resolver teams can use over their respective computer networks. This works well as long as customer and service provider agrees to use a common set of processes, which may well be in the case of co-development mentioned above. Rights management tends to be an issue in this kinds of setup, as it involves authenticating users and sharing protected data on two different domains.
Because by and large the available tools are based on ITIL and provide roughly the same options it's often possible to create a coupling between two instances. This allows customer and service provider to exchange ticket information between their respective ticketing systems. This way everyone can keep their own way of working while providing the requisite connectivity at a tooling level. Care must be taken to allow for data exchange in the SLA times, and reporting on the end-to-end ticket lifecycle can be challenging. If both customer and service provider are large enterprises with mature processes and able to build and maintain such a link, it is often well worth the investment. I'm still waiting for the IT service management bus which will make transitions and links between tools a much more pleasant exercise.
In short: do not skimp on preparation and try to find a good match between customer and service provider, this will greatly benefit service quality and help to defray indirect costs due to inefficient service delivery.
Tuesday, October 1, 2013
Fundamentals
It's commonly said by my IT Service Management compatriots that there are too few management benefits to be fully compliant to frameworks such as ITIL and COBIT. They're held to be much like the pirate code in Disney's Pirates of the Caribbean tetralogy, more like guidelines than actual rules, yarr.
The truth is, these frameworks are not enough, or rather, they are only a small part of what the IT department needs to deliver excellent results. The frameworks and good practices have been over-emphasized as a way to 'professionally' manage an IT department at the expense of general management practices which are much more urgently needed from a business perspective.
Running an IT department is like running any other business, or part thereof. The secret sauce of a great company or a great IT department is all in having good people and managing them well. That the good people in the IT department happen to be of the geek persuasion and tend to focus more on technology than process is no reason to throw management science out of the window and solely rely on IT industry inventions like ITIL.
Many IT departments and managers tend to fall on the spectrum between total ad-hoc troubleshooters and fairly compliant best practice fanatics, but the thoroughbred business manager is a rare find. A team of cherry-picked staff in the IT part of the business is even scarcer, and that is a crying shame.
The worst cases have an under-qualified team of admins report to the facilities manager. This is the IT management equivalent of stuffing your servers in a damp broom cupboard. No disrespect to the facilities guys who may be doing an excellent job managing the facilities, but IT services are rather dissimilar to their field of excellence.
The time when IT merely supported the business is long gone. IT is the business, in the the sense that there is no business to speak of when the IT is not perfectly in order. Gartner is very clear about it, business who don't get that they cannot afford incompetence in this area are playing a loser's game. If you give CEO's the choice between going without their headquarters, their car park or their IT infrastructure for a week, I guarantee they will not choose to be without the IT. The services delivered by the IT department or outsourcing partner fall squarely within the must-have category. This means that the management of these services can be left to Petered-out sysadmins as much as the corporate finance department can be left in the hands of anyone once certified in Excel 2003.
What the IT department needs is a good manager (a great manager if you can find one), a good team and an equal status to your finance and HR clubs, preferably in a tightly run shared service center with direct access to the executive team. That is no more or less than what your business needs these days. Only when those conditions are met the IT service management frameworks become useful good practices. There's always room on the wall for one more ISO certificate, but without good general management practices it won't do much good.
When advising my customers on IT strategy I draw upon some accessible management classics such as Jim Collin's Good to Great, Mastering the Rockefeller Habits by Verne Harnish and Daniel Pink's Drive to underpin my holistic IT management proposals in line with the views presented here. Have a gander.
The truth is, these frameworks are not enough, or rather, they are only a small part of what the IT department needs to deliver excellent results. The frameworks and good practices have been over-emphasized as a way to 'professionally' manage an IT department at the expense of general management practices which are much more urgently needed from a business perspective.
Running an IT department is like running any other business, or part thereof. The secret sauce of a great company or a great IT department is all in having good people and managing them well. That the good people in the IT department happen to be of the geek persuasion and tend to focus more on technology than process is no reason to throw management science out of the window and solely rely on IT industry inventions like ITIL.
Many IT departments and managers tend to fall on the spectrum between total ad-hoc troubleshooters and fairly compliant best practice fanatics, but the thoroughbred business manager is a rare find. A team of cherry-picked staff in the IT part of the business is even scarcer, and that is a crying shame.
The worst cases have an under-qualified team of admins report to the facilities manager. This is the IT management equivalent of stuffing your servers in a damp broom cupboard. No disrespect to the facilities guys who may be doing an excellent job managing the facilities, but IT services are rather dissimilar to their field of excellence.
The time when IT merely supported the business is long gone. IT is the business, in the the sense that there is no business to speak of when the IT is not perfectly in order. Gartner is very clear about it, business who don't get that they cannot afford incompetence in this area are playing a loser's game. If you give CEO's the choice between going without their headquarters, their car park or their IT infrastructure for a week, I guarantee they will not choose to be without the IT. The services delivered by the IT department or outsourcing partner fall squarely within the must-have category. This means that the management of these services can be left to Petered-out sysadmins as much as the corporate finance department can be left in the hands of anyone once certified in Excel 2003.
What the IT department needs is a good manager (a great manager if you can find one), a good team and an equal status to your finance and HR clubs, preferably in a tightly run shared service center with direct access to the executive team. That is no more or less than what your business needs these days. Only when those conditions are met the IT service management frameworks become useful good practices. There's always room on the wall for one more ISO certificate, but without good general management practices it won't do much good.
When advising my customers on IT strategy I draw upon some accessible management classics such as Jim Collin's Good to Great, Mastering the Rockefeller Habits by Verne Harnish and Daniel Pink's Drive to underpin my holistic IT management proposals in line with the views presented here. Have a gander.
Friday, March 22, 2013
Old kids on the block
Last week I took a deep breath and then took the plunge: I'm on a Nokia Windows Phone and I'm loving it. For years the iPhone in various iterations was my constant companion. Increasingly, Apple's blatant disregard for users slowly etched away the glossy feeling of being an Apple fan boy and my disaffection grew. When a software update broke the Wi-Fi on my 4s and the fix took months, without a single word of apology from Apple, the spell was broken.
It took a while before I found my new portable brain externalizer and communications hub in a bright red Nokia Lumia 920. I feel like a guy who drove a Prius and switched to a Humvee. It's BIG, obvious, it's floor-denting solid, and it feels powerful and secure and at the same time wholly irresponsible to own and operate. The spider web that long adorned the back of my 4S is a physical impossibility with this thing, and I hope it lives up to the reputation of the Nokia's of yore. Of course, it guzzles like a Humvee too, demanding top-up charges between my long trips across the Netherlands.
Windows Phone 8 is nice, especially since I got used to live tiles already on my Windows 8 laptop. The OS makes me feel like it’s putting information at my fingertips, literally. iOS is getting stale. I still think that tiles are an interactive redux of desktop icons and not a truly revolutionary interface, but they’re a darn sight better than Apple’s icons and badges. So 2007.
Up front I was afraid of a dearth of useful apps, but it turns out most of my mobile friends are ported. Evernote, LinkedIn, facebook and Twitter have decent (if not amazing) representations. Weave turns out to be a nice news and feed app. Nokia's included navigation app HERE Drive is very good, easily beating the iPhone's maligned Maps app.
The phone itself is fast. Apps load quickly and disappear as fast when you’re through with them. The browser provides easy access to my favorite haunts. The e-mail app is decent, with swipe-able columns to hold your unreads, urgents and miscellaneous unmentionables. Sound quality is great for conversations. Music will never be great from something with the size and frequency reach of a phone speaker, so I won’t even discuss it.
The vaunted camera fails to amaze, as the automatic settings lead to over-processed images with saturation and contrast at levels that make me feel the picture is rotoscoped by Van Gogh. Sure, it takes pictures in murky conditions where the iPhone fears to tread, but that’s not where I usually hang out anyway. In plain daylight, it needs a firm hand on the exposure and white balance settings. The Lumia 920 could have done without all the feature phone fuzz about the camera, then its resolution and low light performance would have been a pleasant surprise.
Overall the Nokia is great. It exudes quality, usability and a bit of cheek. It’s a strong statement that the old stalwarts from Kägeludden and Redmond are back in the mobile game and making a difference. Me? I'm not even looking back.
It took a while before I found my new portable brain externalizer and communications hub in a bright red Nokia Lumia 920. I feel like a guy who drove a Prius and switched to a Humvee. It's BIG, obvious, it's floor-denting solid, and it feels powerful and secure and at the same time wholly irresponsible to own and operate. The spider web that long adorned the back of my 4S is a physical impossibility with this thing, and I hope it lives up to the reputation of the Nokia's of yore. Of course, it guzzles like a Humvee too, demanding top-up charges between my long trips across the Netherlands.
Windows Phone 8 is nice, especially since I got used to live tiles already on my Windows 8 laptop. The OS makes me feel like it’s putting information at my fingertips, literally. iOS is getting stale. I still think that tiles are an interactive redux of desktop icons and not a truly revolutionary interface, but they’re a darn sight better than Apple’s icons and badges. So 2007.
Up front I was afraid of a dearth of useful apps, but it turns out most of my mobile friends are ported. Evernote, LinkedIn, facebook and Twitter have decent (if not amazing) representations. Weave turns out to be a nice news and feed app. Nokia's included navigation app HERE Drive is very good, easily beating the iPhone's maligned Maps app.
The phone itself is fast. Apps load quickly and disappear as fast when you’re through with them. The browser provides easy access to my favorite haunts. The e-mail app is decent, with swipe-able columns to hold your unreads, urgents and miscellaneous unmentionables. Sound quality is great for conversations. Music will never be great from something with the size and frequency reach of a phone speaker, so I won’t even discuss it.
The vaunted camera fails to amaze, as the automatic settings lead to over-processed images with saturation and contrast at levels that make me feel the picture is rotoscoped by Van Gogh. Sure, it takes pictures in murky conditions where the iPhone fears to tread, but that’s not where I usually hang out anyway. In plain daylight, it needs a firm hand on the exposure and white balance settings. The Lumia 920 could have done without all the feature phone fuzz about the camera, then its resolution and low light performance would have been a pleasant surprise.
Overall the Nokia is great. It exudes quality, usability and a bit of cheek. It’s a strong statement that the old stalwarts from Kägeludden and Redmond are back in the mobile game and making a difference. Me? I'm not even looking back.
Subscribe to:
Posts (Atom)