Palvelut ja yhteystiedot

Olen kokenut asiantuntija ja vuoden 2012 ITSM-henkilö. Erityisalueitani ovat IT palvelunhallinta, ISO 20000, service ja help deskit, asiakastyytyväisyyden ja prosessien mittaaminen. Tarjoan konsultointia, koulutusta ja tutkimuspalveluja.

Esiintymisiä
2011: PINK 11, Las Vegas, itSMF Finland  Espoo
2012 itSMF Russia, Moscow, itSMF UK, Lontoo, itSMF Estonia, Tallinn
2013 LeadIT (itSMF Australia), Canberra, itSMF Finland, Helsinki, itSM(F) Belarus, Minsk, itSMF Estonia, Tallinn, itSMF Sweden, video panel
2014: Service Desk Forum , Stockholm,  FUSION14 (itSMF USA), Washington DC ’
2015: TiVI Service Desk, Helsinki, ISACA, TiVaKo 2015, Helsinki, Työkalupäivä, Helsinki   

Yhteystiedot

aale.roos@pohjoisviitta.fi

Pohjoisviitta Oy, Alankotie 29, 00750 Helsinki
GSM +358 (o)5o-5544733
Twitter: @aalem

Where is the customer?

Imagine that you come to a hotel and find a Service Desk where a cheerful person assures you that if there is any incident with your room, one of the service specialists will start fixing it within twenty minutes. Behind her, you can se some plumbers, electricians and carpenters ready with their tools, waiting for the next incident. Wouldn’t you want to find another hotel?

The early years of computing were difficult, technology was new and unreliable. It was understandable that incident management was important. But it is a bit silly that customer service is still missing from current ITSM or that it is so technology centric.

This technology centric view of service can be seen in graphs that describe the support processes. In most cases that I have seen, there is no customer service and actually no customer. It is far more likely to find a CMDB or a service catalog in the center of the picture than a customer. The same thinking seems to carry over from ITIL to all other frameworks, standards and methods. Customer service is seen as the restoration of service after an incident.

The technology centric thinking comes with a price. A lot of effort is lost. Incidents need to be connected to the relevant configuration items and services. Many of my customers have configuration management systems and service catalogs but the logging of incidents with service and configuration information provides no value. My major subject in university was statistics and when I started ITSM consulting I was thrilled that I could start analyzing incident data and find valuable information for my customers. That has never happened. Yes, I have analyzed incident data a few times but every time the data has proven to be rubbish. Garbage in, garbage out is a good rule in statistics.

The ITSM thinking should put the customer in the middle and ask the question how does this process or value stream produce value to the customer. I think that the customer centric framework for ITSM would look completely different.

IT4IT kiinnostaa

Tammikuu 2016 on ehkä (kuukautta on vielä jäljellä muutama päivä) kaikkien aikojen vilkkain kuukausi Pohjoisviitan sivuilla ja syynä on IT4IT. Kirjoittamani juttu on kiinnostanut lukijoita Suomessa ja maailmalla, kävijöitä on 61 maasta.

Jos haluat kuulla lisää asiasta, tule Prosessipäiville kuuntelemaan 19.-20.4.

ITIL V4 is born

Unfortunately, both the father and mother probably deny this so there will be no party.

The Open Group has published the IT4IT™ Reference Architecture, Version 2.0, an Open Group Standard. http://pubs.opengroup.org/it4it/refarch20/index.html

IT4IT is a real architecture model, it is well defined with logical elements and definitions of Functional Components and their relationships. It is based on four value streams:

  • Strategy to Portfolio (S2P)
  • Requirement to Deploy (R2D)
  • Request to Fulfill (R2F)
  • Detect to Correct (D2C)

There are also supporting functions within the value chain model such as Supplier Management, Asset Management, Human Resource Management, Legal, and IT Financial Management.

IT4IT

 

It has taken the basic structure of ITIL and made an architectural framework of it. The components are well defined, there is data model and relationship structure. It clearly at significantly higher lever of abstraction and sophistication than what the ITIL literature offers.

The architecture is independent of vendors, processes etc. The authors claims that it works as well in agile environment as the in traditional waterfall style development. It is really not meant to be the next version of ITIL but it looks like it very much. The authors say that it is not a best practice model, but it follows ITIL very closely. In some places the text looks like it has been copy pasted from ITIL (for example Incident).

The architecture seems to be aimed to an internal IT service provider, just like ITIL. It assumes that the service provider has a high degree of independence and can execute its own strategy. It does describe a provider/broker model where IT acts as a service broker between the business and various vendors, but it does not cover situations where either the IT is an external service provider or where the IT is just one service provider, but not a broker. When business takes more responsibility of its IT solutions, there is less need for a centralized IT department between the vendors and the business. The authors clearly oppose this development so the IT4IT model can be seen as an attempt to boost the position of the CIO. Running IT as a business seems to be the goal and I disagree with it. If you can run IT as a business, then you should become an external vendor and test your competitiveness against other vendors. It is too easy to be a business within a monopoly situation.

It is interesting to see that there seems to be a consensus within the Open Group that attempts to use ITIL generally fails. The authors write: The absence of a service-centric IT operating model in the past helps explain why all the time and money invested in best practice process frameworks like ITIL and COBIT, working with consultants to optimize IT organizational structure, and investments in IT automation have fallen short of expectations. IT4IT is offered as a new solution to this evident problem.

My estimate is that IT4IT can be quite valuable for any organization that plans to use ITIL. It is much more structured and logical. Nobody should implement any ITIL process tools without studying the IT4IT data model. In that sense IT4IT can replace ITIL if the Open Group creates trainings and certifications.

Unfortunately, IT4IT copies many of ITIL’s core problems. I have written a lot about the problems of ITIL and I will not cover all those as most of them have been entered in IT4IT but I’ll mention one. There is no customer service and support. Users can either request services or call to report incidents. Incidents fall in the same stream as events. Very technology centric. Fresh ideas from the 1980´s.

Parempi laatu, pienemmät kustannukset

Turhan työn poistaminen on avain laadun kehittämiseen kustannuksia vähentämällä. Olen koonnut tähän joukon ideoita, mistä voit löytää hyviä kohteita turhan työn vähentämiselle. Nämä ovat ideoita ja niiden soveltaminen pitää tehdä harkiten. Organisaatiosta varmaan löytyy henkilöitä, jotka vastustavat näitä ehdotuksia. Pyydä vastustajia esittämään saavutetut hyödyt ja tarkista kaikkien osapuolten näkemys. Hyvin toimivia käytäntöjä ei tietenkään kannata purkaa, jos ne toimivat hyvin kaikkien osapuolten mielestä. Asiakkaan mielipide on aina tärkeä.

  1. Unohda palveluluettelo, jos se ei tunnu toimivan. Olen nähnyt lähinnä vain huonoja ja hyödyttömiä palveluluetteloja, joita puolustavat vain niiden kehittäjät. Kaikkea IT-toimintaa ei tarvitse kuvata palveluna. Monissa tapauksissa liiketoiminta ja asiakkaat tekevät yhdessä asioita, ja IT-väen tehtävänä on tarjota asiantuntemusta, osaamista ja tekemistä yhteisten tavoitteiden eteen. Yhteistyö ja palvelu ovat eri asioita.
  2. Unohda SLAt. Keinotekoiset palvelutasot eivät takaa laadukasta palvelua, mutta työllistävät paljon. Kaikkea ei voi mitata hyvin ja huonot mittarit ovat turhia.
  3. Unohda CMDB. Sen rakentaminen ja ylläpitäminen on työlästä. Oletko varma, että siitä saadaan todellista hyötyä. On mahdollista, että CMDB:tä ylläpidetään, koska johto on niin määrännyt mutta kaikki tietävät, ettei sen tietoihin voi luottaa.
  4. Poista turhat tiketit. Automaattivalvonnan hälytyksistä on turha avata tikettejä. Asiat pitää hoitaa mahdollisimman vähillä vaiheilla. Tiketin avaaminen ja sulkeminen ovat turhia työvaiheita.
  5. Poista turhat kentät tiketeistä. Keskity olennaiseen. Palveluluettelon ja CMDB:n poistaminen auttaa, mutta vaikka et poistaisi niitä, on silti turhaa kytkeä kaikkia ongelmia johonkin tiettyyn palveluun tai konfiguraation osaan. Usein niiden määrittely on vaikeaa tai mahdotonta. Pakolliset luokittelut tuottavat roskatietoa.
  6. Unohda turhat prosessit. Prosessi on hyvä apuväline toistuvien rutiinien pyörittämiseen, mutta se ei sovellu kaikkeen tekemiseen.
  7. Unohda turhat mittarit. Prosessiajattelu luo helposti paljon prosessimittareita, joilla ei ole oikeasti mitään järjellistä käyttöä. Älä mittaa aktiviteetteja ja älä ainakaan aseta niille tavoitteita. Keskity tuloksiin, ei puuhasteluun.
  8. Rakenna asiakkaille palvelupisteitä, joissa heitä autetaan tietotekniikan kanssa. Yksi vierailu voi ratkaista monta ongelmaa ja säästää aikaa sekä asiakkailta, että asiakastuelta.
  9. Ole mukana sosiaalisessa mediassa, jos asiakkaasi ovat siellä. Yritä luoda keskusteluforumeita, joissa asiakkaat voivat keskustella palveluihin liittyvistä asioista. Yksi hyvä keskustelu voi ratkaista monen asiakkaan pulman.
  10. Kuuntele asiakkaiden mielipiteitä, mutta älä kiusaa heitä turhilla ja huonoilla kyselyillä.

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.

New view on service catalogs

I have been thinking about the practical implications of breaking down the concept of service. One obvious case is the re-thinking of the service catalog. Writing a good service catalog is not easy. There are books and training about it but good examples are rare. I have come to the conclusion that talking about service in general in ITSM is actually a waste of time.

A service promise or proposal is about the outcomes the customer want. These may be specific or general, all depends on the customer needs. There is a major difference between internal IT and external IT. External IT must sell its services and there is usually competition. It is not easy to make good service proposal, it is a business skill and I will not cover it in detail. Internal IT is in a different position; it has a monopoly position which it should use wisely or it will lose it. It needs to be able to deliver the IT services the business wants. The business owns it and can decide what the IT does. Internal IT needs to make and keep a service promise which satisfies the customer.

A service system is a combination of people, processes, hardware, software etc. Usually there is a collection of service systems to fulfill the service promise. Typical service systems are: an application, network, servers, service desk etc. Service systems can be outsourced or internal. Some service systems are visible and recognizable to the customer; other systems are hidden or uninteresting from the customer’s point of view.

When service systems operate, they may perform service acts. Service acts are touch points between the service system and the customer and the service promise is fulfilled by the service acts.

This model leads to three different ”service catalogs”, which are much easier to design than the current model:

  • A list of service promises contains the promises IT has made to the customer. They need not be very detailed but the customer may require exact details of some important service systems.
  • A list of service systems describes all the components of the whole service system. This is just a breakdown of the whole machinery to smaller components. The customer may be interested in some elements of it but not at all interested in some other elements. The list would be identical with the list of higher level configuration items.
  • A list of service acts describes in detail what the customer can get from the service provider.

The discussions with the customers should concentrate on the list of promises and the list of acts. It is possible that the customer is interested in the details of some specific service system but hardly ever interested in all of them.

Consider an amusement park. It has a simple service proposal: you and your family will have fun. It may add information about the number of rides, restaurants etc. It may describe some technical details about selected rides like maximum speeds but there will not be exact details of all rides. The service proposal will contain exact information of the available price options and their benefits.

 All the rides and restaurants are service systems, but there are other systems like security, cleaning, maintenance etc.

 There will be a detailed list and map of all the rides and other service facilities and that is the most interesting list for the users.

 There are usually no SLAs.

A service promise might ideally look like this:

The IT departments supports business units by providing the business with up to date tools and ensuring that the IT systems work well. The goal is to have no events that cause business losses and to make sure that the staff will lose very little time due to IT technical problems.

The list of available services would be on the support portal and would include things like:

  • order a computer
  • order an application
  • new employee
  • etc.

Stuart Rance wrote recently a blog about why one should not define applications as services. I agree with that, but you could have customers who want to specify some important IT application and require an SLA for it. The problem with this is that the IT and the customer won’t mean the same thing. The application can be outsourced from vendor A and it runs on platforms provided by vendor B. It needs data from other applications. In worst case different business units own the contracts or the applications. The application might be running 100 % ok but some other system might not be providing the necessary data.

The solution this would to make a service promise about the application. This can be a problem if there is no overall responsibility for it. Then there are two options: 1) the customer negotiates SLAs with each vendor via the business unit which owns the contract. 2) some party takes the role of a service integrator.

The second option is most likely much better for all parties, which explains the current popularity of SIAM.

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.

Seuraa

Get every new post delivered to your Inbox.

Liity 1 750 muun seuraajan joukkoon

%d bloggers like this: