Pohjoisviitan toiminta on päättynyt

Pohjoisviitta Oy on lopettanut toimintansa ja tämän sivuston ylläpito on päättynyt. Kirjoitan jonkin verran blogeja edelleen ja ne löytyvät osoitteesta https://itsm.tools/author/aale-roos/

Mitä olen oppinut. Osa 2. Yksinkertaista

Yksinkertaisuus on äärimmäinen hienostuneisuus” – Leonardo Da Vinci.

Kirjoitin ensimmäisessä osassa asioiden ymmärtämisen tärkeydestä. Epäselvien käsitteiden lisäksi ymmärrystä vähentää tarpeeton monimutkaisuus. Monimutkainen näyttää hienommalta, paksu dokumentti vaikuttaa arvokkaammalta kuin ohut jne. Usein yritetään tehdä liian hienoa, varaudutaan kaikkiin mahdollisiin poikkeustapauksiin ja tuloksena on liikaa detaljeja. Yksinkertaistaminen ei ole helppoa, on kyettävä näkemään olennainen ja uskallettava karsia turhat elementit pois.

Kuka lukee 50-sivuista prosessikuvausta? Prosessikuvaus on todennäköisesti laadittu leikkaa-liimaa -tekniikalla, se on täydentynyt vuosien varrella. Konsultti on muokannut sitä asiakkaiden toivomusten mukaan, mutta ei ole poistanut mitään. Kukaan ei lue sitä ja kukaan ei toimi sen mukaan, mikä on oikeastaan hyvä, koska paksu prosessikuvaus on melko varmasti epälooginen ja sisäisesti ristiriitainen.

Hyvä prosessikuvaus on lyhyt, korkeintaan muutaman sivun mittainen ja sen kuvista näkee nopeasti, miten prosessi toimii. Käytetyt termit on määritelty selkeästi. Prosessikaaviot näyttävät olennaiset vaiheet, kuvaus ei takerru yksittäisten poikkeustapausten käsittelyyn.

Sama koskee raportteja. Hyvä raportti on lyhyt ja selkeä ja se nostaa esille tärkeimmät havainnot. Huono raportti on uuvuttavan pitkä, eikä siitä jää mitään selkeää kuvaa asioiden tilasta ja kehityksestä.

On monta asiaa, jotka vaikeuttavat yksinkertaistamista. Ryhmätyöskentelyssä on helpointa hyväksyä kaikkien ehdotukset, kuin noudattaa tiukkaa linjaa. Monimutkaisuus tuo töitä konsulteille ja kouluttajille. Tulosten laajuus luo mielikuvan tehokkuudesta ja tuottavuudesta.

Mitä olen oppinut. Osa1. Selkeät käsitteet

Mitä olen oppinut.

Olen jäämässä eläkkeelle ja päätin kirjoittaa lyhyen sarjan niistä asioista, joita olen oppinut it-palvelutoiminnasta näiden vuosien aikana. Oma urani alkoi jo 70-luvulla. Olen koodannut vähän, auttanut muita tietokoneen käyttämisessä, vetänyt asiakaspalveluyksikköä, mutta ennen kaikkea olen konsultoinut it-päättäjiä toiminnan kehittämisessä. Matkan varrelle mahtuu paljon onnistumisia, mutta toki myös epäonnistuneita hankkeita.

Osa 1.  Selkeät käsitteet

Asioiden ymmärtäminen on tärkeää ja sitä varten pitää olla selkeät käsitteet, joiden avulla asioista voi puhua ymmärrettävästi. Tämä ei ole aina kaikkien tavoite, sillä epäselvyyden avulla voi häivyttää monia asioita. Vaikeaselkoisuus luo mielikuvan osaamisesta, asiantuntija vaikuttaa pätevältä, kun hänen esitystään on vaikea ymmärtää. Joskus vaikeaselkoisuudella peitellään omia tarkoitusperiä, esimerkiksi monimutkaisten sijoitustuotteiden perimmäinen tarkoitus on tehdä rahaa niiden myyjille. Ostaja luulee hankkivansa voittoja nerokkaalla tavalla, ymmärtämättä tuotteiden riskejä.

It-palveluhallinta on vaikea ala. Se on monimutkaista ja siitä on vaikea saada otetta. On aito tarve saada selkeä kuva toiminnasta, jotta sitä voi ohjata ja kehittää. Toiminnan kuvaamiseen on kehitetty erilaisia malleja, joiden tulisi auttaa ja joiden avulla voisi kuvata hyviä käytäntöjä. Valitettavasti malleilla on taipumuksena kasvaa ja monimutkaistua. Monimutkaiset mallit tekevät hallinnan vain entistä vaikeammaksi.

Hyvä esimerkki epäselvästä termistä on palvelun käsite. Palvelu on vaikeasti määriteltävä asia ja puhe palvelusta jää helposti epämääräiseksi. ITIL määrittelee palvelun lähinnä vuokraamisena tai liisaamisena. Asiakas saa haluamansa hyödyn ilman omistamiseen liittyviä erityisiä kustannuksia ja riskejä. Määritelmä on huono, se ei sovi it-palveluihin kuin aika harvinaisissa tapauksissa.

Palvelusta on helpompi puhua, jos sen jakaa keskeisiin komponentteihin: palvelulupaus, palvelujärjestelmä ja palvelutapahtuma.

  • Palvelulupaus on palvelutuote. Se kuvaa palvelun toiminnan pääpiirteissään ja korostaa asiakkaan saama hyötyä. Palvelulupaukset voivat olla asiakaskohtaisia tai tuotteistettuja.
  • Palvelujärjestelmä on tietotekniikasta, ihmisistä, prosesseista, ohjeista jne. koostuva toiminto, joka tuottaa palvelulupauksen edellyttämiä asioita.
  • Palvelutapahtuma on asiakkaan transaktio palvelujärjestelmän kanssa.

Tämä kolmijako on hyvin keskeinen asia palveluhallinnassa, jo jos sitä ei ymmärrä, on pihalla.

Huvipuisto on palvelu, joka tuottaa nimensä mukaisesti huvia asiakkailleen. Huvipuistossa on runsaasti palvelujärjestelmiä, kuten siivous, ylläpito, vartiointi, vesi- ja viemäröinti, laitehankinnat jne. Lisäksi siellä on tietysti paljon laiteita. Asiakkaan näkökulma palveluihin on aika erilainen kuin huvipuistoa pyörittävän organisaation. Asiakas näkee pinnan ja hänelle tärkeät asiat. Henkilökunta työskentelee pinnan alla.

On hämmentävää puhua vaikkapa palveluluettelosta, jos ei täsmennä puhuuko lupauksista, järjestelmistä vaiko tapahtumista. Esimerkiksi it-palvelutoimittaja voi myydä it-järjestelmiä palveluna asiakkaille, jotka ovat itsekin it-ammattilaisia. Liiketoiminta taas on vähemmän kiinnostunut teknisistä it-järjestelmistä, vaan puhuu mieluummin palvelutapahtumista.

Toinen vastaava esimerkki epäselvistä käsitteistä ovat insidentti ja ongelma. Insidentin- ja ongelmanhallinta ovat pohjimmiltaan samoja asioita ja niiden käsittely erillään luo turhaa hämmennystä. Insidentti on häiriö ja ongelma sen aiheuttaja. Joskus näitä voi käsitellä erillään, mutta usein insidentin ratkaiseminen vaatii sen syyn tunnistamista. Jos sulake laukeaa, kannattaa selvittää laukeamisen syy, ennen kuin kytkee virran uudestaan päälle.

Kun laitan leivänpaahtimen päälle, se välähtää ja keittiön valot sammuvat. Valot sammuvat koska sulake on lauennut ja syyllinen on leivänpaahdin, joka haisee palaneelta. Onko sulakkeen laukeaminen insidentti ja onko leivänpaahdin ongelma? Laitanko vain sulakkeen takaisin päälle? Viisainta olisi vain laittaa leivänpaahdin kierrätykseen ja hankkia uusi.

On parempi lähteä liikkeelle asiakkaasta ja kuvata asiakkaan palvelutapahtumia. Asiakas voi tarvita neuvoa, haluta tilata jotain täydennystä tai sitten asiakkaalla on ongelma. Toinen näkökulma on palvelujärjestelmän kannalta järjestelmän viat ja häiriöt, joita pitää korjata. Epäselvien käsitteiden ansiosta nämä asiat menevät helposti solmuun.

Monet konsultit rakastavat vaikeita termejä, he pyrkivät luomaan mielikuvaa ylivertaisesta osaamisestaan. Olen nähnyt liian usein, kuinka konsultit puhuvat asioista, joita he eivät itse kunnolla ymmärrä (olen tietysti syyllistynyt siihen itsekin). Tämän hetken muotisanoja ovat esim. SIAM ja DevOps.  Kannattaa kysyä ns. tyhmiä kysymyksiä. Esimerkiksi:

  • Mitä tuo sana oikeastaan tarkoittaa, voisitko avata sen lyhyesti?
  • Milloin olet itse soveltanut tätä menetelmää?
  • Mitä se merkitsee meille?

Asiansa osaava kykenee avaamaan termit, kertomaan omista kokemuksistaan ja osaa soveltaa niitä asiakkaan tilanteeseen.

There is only one customer

The concept of internal customer is an idea to increase quality by motivating people to serve other internal teams as they were their customers. In the model the various units form a chain or network of service providers who serve each other. The internal service model allows all employees to have some direct customers. Companies or organizations usually have a customer for their services or products. They work for the customer who pays the costs. Some of the work is indirectly related to the customer and in some cases the link is complicated.

IT used to have a distant connection to business. Data was entered via punched cards and input from IT to business or customers was via printouts, reports, invoices etc.  It was natural to see IT as an internal service unit. In ITSM the concept of internal customers has been adopted very thoroughly. Instead of just using the internal service model for motivating staff, the ITIL books suggest that one needs to have a service strategy for creating and managing a service portfolio, as if the internal customers were real. An IT unit which follows the ITIL model acts like it is an independent business which can decide its own strategy. If that is right, then the corporation should check whether the IT service unit is competitive. If it isn’t, the corporation can switch to an outside vendor, if it is then the corporation can spin off the IT part as an independent business.

Most large corporations have several internal support functions: finance, human resources, legal, marketing and IT. It is common that directors of finance and legal are board members and it is relatively easy to become a CEO from those positions. CIO’s are much less likely to be included in the top management team. The reason for this is that finance and legal are involved in the business while IT can be seen as just a technical service.

Stephen Mann wrote a blog about how one should not limit ITSM models just to IT. http://allthingsitsm.com/enterprise-service-management-not-just-itsm/. I agree up to a point. The concept of internal customer is not harmful if applied with sense. It is a good idea that for example the service desk staff treat the people who ask for help as customers. It is a natural model in that situation. And the service desk model can be applied to many other situations. The ITSM tools can be applied to many other business processes. I disagree with the idea that the whole internal service model should be copied to other services. It is a better idea to move to the opposite direction.

It has become quite common that outside customers have a direct connection to the IT systems. A customer may check current information about availability, delivery times etc., they can enter their orders and update their information. The role of IT has changed or should change from internal service provider to a partner of the business.

There is only one real customer and there is only one real strategy. This means that a lot of the elements of the internal customer service model are unnecessary. There is no need for a comprehensive service catalog, service strategy, service level agreements for example. Instead of IT services to the business there are business services to the customer. This means that there is very little need for IT centered best practice models, instead IT needs to apply the business models.

Service systems and services

 

IT service management is not easy and there are no magic shortcuts to success. I have been lately annoyed by the empty jargon from people who clearly do not understand much about the subject. I have seen it in blogs, consultant reports and presentations. Setting up a SMO, ’implementing’ SIAM are described as simple solutions with no understanding of the difficulty of the task.

ITSM can provide services which fulfill all SLA requirements but do not satisfy customer needs. The business decision makers have tried to solve this problem in many ways. IT has been centralized, decentralized, outsourced etc. IT people have tried implementing processes, metrics, frameworks, standards etc. Usually all these approaches have had mixed results.

The best solution is to have good management and governance of IT, which requires good understanding and cooperation by the business and IT management. Unfortunately, this is not always possible. Business management has other issues and if IT people had really deep understanding of the business issues, they would most likely be working within business. In real life, people do not understand both deep IT and deep business at the same time.

ITSM is really about managing service systems, not services. It is a popular misconception that the ITSM processes can manage services. Service systems are important element in service business but they are not the whole picture.

A service is many things; it is a promise or proposal, it contains often many systems and it may result in acts. A complex service requires many service systems to provide the acts that fulfill the service promise.

Simple services can be separate from the customer’s core systems. For example, physical security, cleaning, plumbing, cafeteria etc. are services which are a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

Here is a simple test of understanding ITSM. Does the definition above apply to IT services? The correct answer is NO.

IT services in general are different. IT service systems are integrated in the business service systems and it is not possible for the business to avoid the ownership of the specific risks and costs of the IT service systems. Business needs IT but it cannot outsource it as easily as it can outsource many other services.

From the business perspective, IT service systems are expensive and carry high risks. They are hard to manage as the business decision makers do not understand the systems and the specialists understand only their own technological area. Very few people have sufficient understanding of both the business and the technology.

In many cases the economies of scale drive to outsourcing and most systems can be bought from various vendors. Usually no single vendor can provide the optimal solution. The only solution for most businesses is to use many service providers. 

Generally, the service providers can only offer the management of their own service systems. The IT service systems are embedded in the business services which are outside the control of IT. IT provides service systems which are critical components of business. There are no Service Lifecycles, IT does not design services, it designs service systems and service acts. There is a deep misunderstanding in the ITSM field about this.

An amusement park is an analogy for IT services. The service proposal is enjoyment and excitement. The rides are a key element of the amusement park and there needs to be effective and efficient technical management for the equipment. Incidents in the rides may hurt business. ITSM processes might well be useful for improving reliability and availability of the rides. At the same time, it is clear that the technical management does not run the amusement park. It cannot create sensible service strategy as that is a business decision. The Park management may decide to remove a popular and profitable ride because it needs a new magnet to fight the competition. The lifecycle of the rides is generally not a technical decision.

The technical management must understand that it manages the service systems, not the park services. If the technical management does not understand this, the Park management may well decide to outsource the technical management of the rides.

Understanding this helps a little but it does not solve the dilemma of not fulfilling customer needs by managing service systems and processes. There must be a higher level of managing, which covers all IT service systems and their interactions. It is called Service Integration and Management SIAM.

The need for new management models like DevOps and SIAM comes from the lack of integration in current ITSM thinking. The ITSM processes have no mechanism for inter-process coordination. The ITSM frameworks are very activity and process oriented, value is not really understood, which can be easily seen when one looks at a list of recommended metrics for ITSM.

DevOps tries to bring better cooperation between development and production. Current ITSM models can be seen as an obstacle course designed to prevent any development. If you doubt this, calculate how many processes there are between a customer requirement and its implementation. DevOps can be very useful if the business requires agile development of business systems.

SIAM should not be seen as a new framework or an extension of any current frameworks. It is not a component of ITSM, which is about managing the service systems. SIAM can provide the missing element of management of the whole system, including internal, outsourced and business components. This can be internal management or it can be also outsourced. Some Indian outsourcing companies have driven this model very successfully, but it is likely that there are also many internal success stories, where IT and Business management have found a working governance model. SIAM is a management capability which ITSM often lacks.

For all important things in IT service management there is a simple metric which is wrong.

Management by facts sounds fair and numbers look like facts. Unfortunately it is hard to get right numbers. IT services are complex and difficult to measure but the processes are fairly easy to measure. Modern tools produce a wealth of reports based on tickets, phone statistics, web clicks and visits etc. It is quite easy to fall in the trap of believing the numbers. Measuring things tend to be more difficult than we assume and therefore it is easy to misunderstand the results. There are a lot of important things that cannot be measured accurately and it is a major mistake to try to manage by numbers only.

A car’s dashboard shows the speed, engine revolutions, engine heat, gas gauge, outside temperature and the odometer which can be replaced by some other information. None of these metrics are enough to make any other management decisions expect when it is time to fill the gas tank.

1.    Measuring service

Service consists of a service proposal, service system and service events. It is important to understand what element of the service we are measuring. A lot of typical measurements are based on discrete service events.

IT service metrics can be based on

  • direct observations of events,
  • documented performed activities and
  • measured value of the service.

service metrics

 

For example a customer call is an observed event. A ticket based on the answered call is an activity.

 

Customer satisfaction is based on customers comparing received service to what they expected. Expectations are based on many things but the service proposal is one of them.

 

2.    Different metrics

Measuring means labeling the observations with some sort of scale.

There are four scales that can be used: nominal, ordinal, interval and ratio.

  • Nominal scales only label objects, a change request can be
    • approved
    • rejected
  • Ordinal scales but things in order but the distances between the values are not known, for example in the progress of an approved change the steps may represent minutes or months, depending on the type of change
    • approved
    • under planning
    • under execution
    • under review
    • closed

Another example is customer satisfaction where the distances between steps can mean quite different things

  • very dissatisfied
  • dissatisfied
  • neutral
  • satisfied
  • very satisfied
  •  Interval scales have a meaningful difference between numbers but there is no zero which means one cannot calculate ratios. A classical example is temperature. 11 C is 10 degrees warmer than 1 C or 51.8 F is 18 degrees warmer than 33.8 F. The result will hold at any starting temperature. The ratio of temperatures is meaningless. In Celcius it would be 11 times warmer and in Farenheit the ratio would be 1.5.
  • Ratio scales is a true scales, number of units, length, weight are examples.

 

2.1.                      Events

Event based metrics tell us for example how often something happened and there can be also other event based data like time, volume, money etc. Some customer actions can be measured directly, for example web analytics measures clicks and telephone system records calls. Many systems collect logs and some of them report the events continuously. A telephone system can record queue times, abandoned calls, answered calls, call lengths etc.

Measuring direct customer events can be very useful. For example a game developer can see how many times players do some specific action in the game. If some stage is too difficult, it may cause players to abandon the game. In-game sales is a very specific activity which measures the value directly.

Unfortunately event metrics can be misleading. For example many people may try to open some system and fail at it, or abandon the system after a brief visit. In that case the number of hits would be a bad indicator for the value of the object.

It is not possible to measure the success of IT service management based on events only but event data can be valuable when available. Events can often be measured in ratio scales.

 

2.2.                      Activities

Activity means doing some task or procedure. Replacing a broken component or updating software are activities.

Often activities need to be measured indirectly. The process models we use in ITSM, try to turn everything we do into measurable activities by using tickets. A ticket records each activity. This makes activities quite easy to measure. Opening and closing incidents are measurable activities. Changes can be measured by counting change records. However the number of records tell little about the reality. For example one change can mean five minutes or five days of work.

Almost all process metrics measure activities, usually these are measure indirectly, via the ticketing system. The simple logic equates value with the activities. Activities are work which is done for the customer. More activities lead to more value.

In some cases this is true. Doing something is better than doing nothing. A lot depends on the way how the service organization is working. Some organizations desperately need more control and for them the activities are a good indicator.

Some organizations live in a continuous disaster. Services fail often, and people fight to keep them running. Customers can be used to the situation and are happy if really bad disasters are avoided. This is typical with new services in prototype mode.

When the organization achieves control the chaos has been tamed and services work. One key ingredient in beating the chaos is usually a rigid control of changes. The down side can be that there is no flexibility in the services. Customers need to accept the service as it is delivered but are happy about the stability if they still remember the chaotic stage.

The next phase is when the services are stable and at the same time are able to adjust to changing requirements and situations. The service can handle continuous change and is able to understand the customers’ needs. Processes and process metrics seem to be less important.

According to popular maturity models the ideal stage is where the management is able to measure, control and improve processes, i.e. the control stage. It is a major mistake to think that processes are a goal; a process system is a tool. Excess focus on process metrics can be the main reason why many IT organizations fail. Processes are a useful tool to transform a service organization from chaos to control but less useful when trying to reach the adaptive stage.

The problem with activity based measuring is that it is quite difficult to separate useful activities from busywork. Bureaucratic organizations are ingenious at creating useless activities to keep themselves busy. Having an efficient and effective process in support doesn’t tell anything about the quality of the service it provides. For example a bad service desk might handle 50 incidents per person per day, solve 80 % at first contact and close 98 % within SLA limits while a good service desk might handle 20 incidents per person per day, solve 60 % at first contact and close 70 % within SLA limits. The trick would be that the good service desk has been able to eliminate 60% of the causes for the incidents and is continuously improving service, not the process.

2.3.                      Value

Value is a complex concept. Robert Falkowitcz has written an interesting analysis of it in  http://www.3cs.ch/is_service_value_really_delivered/

In business world, value is usually money but often in an indirect way. Direct profit comes usually from new innovations in system design. A new information system may increase sales, cut costs or even do both. IT service management does not create new systems but can save money by preventing outages and other disruptions; it can also diminish lost work time by restoring service as fast as possible.

Service value is usually the result of the outcomes of service events; it is the reason why people use the service. IT value typically comes from automating and simplifying tasks. In most cases IT systems are a must, manual operation is not a viable option. In these cases the automation alone does not create any added value.  There can be extra value in lack of friction, i.e. the system is easy to use but powerful and flexible but reliable. By friction I mean all overhead which is caused by using the system.

One important source of friction comes from the complexity of IT systems and services. The users do not know how to do things, they make mistakes and they do not use the systems in an optimal manner.

It is quite hard to measure the value of different components. A meal can be a fantastic experience but it is impossible to pinpoint the exact value of each component of the service. In the same way, the IT must be working ok if the company is a success but it is not easy to measure IT’s contribution exactly.

Bill from sales is visiting an important potential customer and learns that the customer has an emergency situation and that they will buy 1000 units for 10 M$ if Bill can promise delivery next week. Bill needs to make sure that there are enough units available so he tries to get in the ERP system to check the status. Unfortunately he is not able to get in the system. He calls the service desk.

Scenario A. The service desk answers in 20 seconds. The agent asks Bill to give the laptop’s CI id and creates a ticket. The agent checks that the ERP system is up and that there are no networking problems, which means that the incident is about a single laptop which gives it a low priority. Then the agent instructs Bill to boot the laptop but this does not work as the laptop has crashed and does not respond to any command. Finally after consulting the knowledge base, the agent instructs Bill to remove the battery from the laptop to cause a restart. This works and now Bill needs to log in, set up the VPN connection and then start the ERP application. The incident is resolved, the agent closes the ticket and notices that the low priority laptop incident was solved on 14 minutes which was within SLA target.

Meanwhile the customer watched Bill’s struggle with the laptop for awhile but then checked the situation with another supplier and ordered the units from them.

Scenario B. The service desk answers in 20 seconds. The agent listens to Bill and asks what information he needs. Bill explains that he needs to know are there 1000 units available in the warehouse. The agent checks and reports that there are exactly 1250 available right now. Bill informs the customer who decides to buy all the available units for 12.5 M$. Bill asks the agent to mark the units as reserved.

Now scenario A is perfect from the process metric point of view. Everything goes as planned and the incident is solved fast. Scenario B is far from perfect. There is no incident ticket. But in scenario B, the company makes 12.5 M$ by selling unsold units which were clogging the warehouse.

If it were this easy to measure the value of IT activities, running IT services would be far less complicated. Of course in real life things are not so clear. Value is very difficult to measure.

IT is an enabler and a cost at the same time. The value comes from the ratio of saving vs. cost. The best source for this information is the user. If the users have a choice, they will not use a system which does not create value for them. User behavior and opinions are the best ways to measure the value of an IT service.

 

3.    Setting goals

Somebody wrote that any metric can be destroyed by using it as a goal. I agree with that. (Sorry, I don’t remember who wrote it and also not the exact words so I cannot find the source).

It is good to have measurable goals, the problem lies in finding the right way to measure the goals. The problem with activity metrics is that they measure activities not outcomes or value.

One specific class of goals is the service level agreement, which state measurable limits or target values for various metrics. For example availability must exceed some limit and incidents must be solved within some set time. Both are useful metrics in the sense that any adverse trend or change is worth investigating. It is important to understand the causes for the changes.

For example, availability SLA might

  • fail because there have been maintenance work done over weekends and the impact for business has been nonexistent.
  • be ok while there was a short break at peak time which caused a major business loss

Incidents SLA limits

  • may fail because the IT staff is temporarily overwhelmed with work
  • be ok because the IT staff deflects incidents by asking for a lot of unrelated information from the customer and keeps the ticket on hold as long as every piece of information has been received

The problem with SLA targets is that they are difficult to define. The term availability is not clear and neither is the solution time. All metrics can be defined in many ways and as the IT is responsible for defining these, it usually leads to complicated definitions which favor IT and result to meaningless values from the customer’s point of view.

There are real life examples where the service provider has prioritized the SLA targets over the real customer needs. The service analysts might spend their time in handling non critical issues because their arbitrary SLA limit is due while there is an active top priority incident on but which still has a few hours left in the SLA clock.

Activity targets can lead to unwanted results as the staff can control their activities. Old saying states: “You get what you measure”. The organization may start gaming the system by trying to produce excellent results while ignoring other factors.  One way to prevent this is the use of several metrics. For example increased speed may lead to lower accuracy and vice versa. Setting goals in both directs people to find a preferred balance but it can be also confusing for the staff who doesn’t know how to act.

 

4.    The problem with some common metrics

Here is a list of typical metrics for a service desk. My comments analyze the value of the metric.

Metric Comment
 Percentage of phone calls to service desk answered within XX seconds Old, telephone era metric, limited value. Can be harmful if leads to over-emphasis on telephone communications.
 Percentage of phone calls to service desk abandoned before they are answered Same as previous. Abandon rate has also limited value as it depends on user behavior.
 Percentage of incidents where user contacted the service desk to ask for an update Useful, this is a measure of waste in the operation. People should not need to chase their requests.
 Percentage of incidents that were reopened by the user after being closed by the service desk Questionable because the SD can open a new ticket instead of reopening the old one. Or if the users are allowed to reopen old tickets, they will do it even if the issue is different.
 Percentage of incidents resolved within agreed SLA targets SLA targets have limited value as they are hard to define. SLA goals can lead to unwanted behavior when the service provider tries to reach the targets and ignores customer needs.
 Percentage of incidents resolved using web-based self-help Difficult to measure. The use of the self help tool does not prove that it solved the case. For example a user might try to use the tool unsuccessfully five times before getting help from the colleague.
 Percentage of incidents resolved during the initial customer contact This is an old, telephone era metric and it has limited value. A customer may try to use self help, try to contact with chat, open a ticket and finally call.
 Percentage of service requests fulfilled within agreed SLA targets Can be valuable as SLA targets are more meaningful with simple orders.
 Percentage of service requests fulfilled using automation with no manual steps from IT staff How do you measure fulfillment. People may try to use automation but fail many times.
 Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey Never use measures like this, they destroy valuable information. All changes in the relative numbers of grades are meaningful.
 Increased satisfaction with service desk on annual customer satisfaction survey This has limited value. Customer satisfaction is measured on an ordinal scale where intervals are meaningless.

 

 

5.    How to use metrics

The key to successful use of metrics is the understanding of the mechanics of a metric. One has to know what things affect the metric and often this understanding can be gained by following several metrics at the same time.

Too many metrics can confuse and misleading metrics are harmful. All reports create non-productive work in creating, gathering, analyzing and reporting the data. Some research firms create high quality reports based on worthless data or bad analysis. Do not trust any metric which you do not fully understand. Beware of complicated “indexes”. Avoid activity goals.

Discussions with relevant stakeholders and a careful analysis of current situation should reveal improvement targets and critical elements in the current service. These may offer some measurable goals. Some of the goals may require change and some goals may require keeping up current levels. Goals should be directly related to value and based on reliable metrics. In many cases it is just not possible to measure the contribution of a single part to the overall result of a large organization. Generally it is better to use shared goals instead of individual goals.

A car dashboard has one value metric: the odometer measures the diminishing value of the car. When buying a car one should not trust it blindly, it can be manipulated like most metrics. The real value of the old car is what somebody is willing to pay for it.

 

 

 

Arvon mittaaminen service deskissä

Arvon mittaaminen on periaatteessa helppoa. Teemme joka päivä arvomittauksia kun päätämme ostaa jotain tai käyttää jotain palvelua. Yleensä päätöksemme perustuvat aikaisempiin kokemuksiin, valitsemme tuotteita ja palveluja, jotka ovat hintansa tai vaivansa arvoisia. Arvoa lisää kohteen antama hyöty ja mielihyvä. Arvoa vähentävät kohteen hinta, mahdolliset laatuongelmat, siihen liittyvä vaiva ja epävarmuus. Avoimilla markkinoilla kilpailu pitää yleensä huolen siitä, että tuotteet ja palvelut tuottavat arvoa. IT palvelu ja service desk eivät toimi avoimilla markkinoilla. Palvelun vaihtaminen on vaikeaa tai mahdotonta. Asiakkaat ovan yhden palvelutoimittajan vankeja.

IT palvelun tai service deskin toimintaa mitataan yleensä aktiviteettien perusteella eli SLA-mittareilla: palvelujen päälläoloaika, vastausaika, tikettien käsittely jne.  SLA mittarit ovat vain harvoin kytköksissä arvoon. Jos katko estää työnteon kokonaan, niin silloin katkon pituus voi olla suoraan verrannollinen menetettyyn arvoon. Valitettavasti useimmat näistä tavallisista mittareista ei mittaa todellista arvoa. Otetaan pari esimerkkiä.

Jos sähköpostipalvelin on nurin 15 minuuttia keskellä työpäivää, mitä arvoa menetetään? Toki voi laskea että kaikki 10.000 käyttäjää menettivät 15 minuuttia, ja näin saadaan kova hinta, pari miestyövuotta, mutta se on älytöntä. Ei taatusti kannata maksaa edes yhden miestyövuoden hintaa siitä että varmistetaan 100% käytettävyys. Todennäköisesti palvelukatkosta ei ole juuri mitään haittaa. 

Käyttäjällä on ongelma. Sen sijaan että service desk hakisi ratkaisun ongelmaan, tukihenkilö opettaa asiakkaalle helpomman tavan tehdä asia. Puhelu kestää puoli tuntia ja varsinaista vikaa ei ratkaista, mutta käyttäjä hyötyy neuvosta joka päivä 15 min.

On helppoa mitata katkon kesto ja on helppoa mitata puhelun kesto. Kumpikaan ei kerro juuri mitään arvosta. Lähes kaikki mittarit, joita olemme tottuneet käyttämään Service Deskeissä, mittaavat aktiviteetteja. Vastaaminen on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Tiketin käsittely on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Asiakkaan tyytyväisyys puhelinkeskusteluun on aktiviteetin ominaisuus. Kaikki prosessimittarit keskittyvät prosessin toiminnan mittaamiseen, mutta toimiva prosessi ei välttämättä tuota arvoa.

Oma käsitykseni on, että service deskin arvo voidaan jakaa kahteen osaan:

1) tietotekniikasta johtuvan menetetyn työajan vähentäminen

2) työn tehostaminen tai helpottaminen tietotekniikan avulla

Nämä molemmat vaikuttavat asiakkaiden saamaan arvoon. Niiden mittaaminen ei ole ihan yksinkertaista.

%d bloggers like this: