Useimmiten tämän kokee kirjoituksien kanssa, jotka aiheuttavat voimakkaan vastareaktion. Tällä kertaa yllätin kuitenkin itseni ja muut olemalla täsmälleen samaa mieltä Hagrosin kanssa.

”Mittarimeressä uiminen on välillä turhauttavaa, mutta pinnalle pääsee takaisin kun muistaa kaksi tärkeintä asiaa: asiakastyytyväisyyden ja henkilöstötyytyväisyyden.”

Voiko asiaa tämän yksinkertaisemmin tiivistää? Väitän, että mitä tahansa palvelua ohjataan parhaiten, kun tärkeimpänä palvelunmuutoskriteerinä on jatkuva ja laajasti kerättävä

Palautteen avulla parannusta!

asiakaspalaute. Ainoastaan jatkuvassa kontaktissa asiakkaaseen oleva palveluntarjoaja pystyy reagoimaan esiin nouseviin ongelmiin riittävän nopeasti. Kerran vuodessa tehtävä asiakaskysely ei riitä!

Toisena kulmakivenä palvelun tuottamiselle on henkilöstö. Jotta palvelua voidaan ohjata asiakaspalautteen kautta oikeaan suuntaan ja pureutua sen todellisiin kipupisteisiin, on osaava, motivoitunut ja tyytyväinen työntekijä paras aseesi.

Missä vaiheessa sopimuspapereihin pienellä präntätyt palveluehdot pääsivät kuninkaan asemaan? Lakimiehet voivat istuutua, ei se ole teidän vika.

 ” Kyllähän se vähän kirpaisee sitoa bonuksensa ihmisten subjektiivisiin arvioihin, mutta ihmisille näitä it-palvelujakin tehdään. Laatua on, jos laadulta tuntuu.”

Toinen nappiosuma! Hieman kadehtien katson menoa B2C-puolella, jossa kaikki on jollain tapaa avoimempaa, eikä asioita hankaloiteta ihan vain tekemisen ilosta. Ymmärrän, että kontakti asiakkaaseen on helpompi säilyttää kun asiakkaalla on selkeät kasvot, mutta ei tämä näin vaikeaa voi olla yrityspuolellakaan.

Palveluntarjoajan muistilista:

1)    Pidä työntekijäsi tyytyväisinä.
2)    Ole kontaktissa asiakkaisiisi säännöllisesti.
3)    Säädä palveluasi kohdan kaksi mukaan.

Liian helppoa?

Tip of the Iceberg

One of the best things about visuals is that everybody has an opinion about them. This means that it is very easy to get feedback – I can ask from a colleague in the cubicle next to mine and get instant feedback. Because the nature of visuals is static, I can also show the visual proposals through website or via mail to get feedback from very large amount of people. Unfortunately, the opinions people have differ greatly from each other and asking from very large amount of people is probably not the way to go. Mainly, because more people you ask more varied opinion-base you will get. Take colors for example: if you ask enough for many people and narrow down the possible colors to use in your software, you probably end up in a situation where there are no colors to choose from. Or perhaps you will have two colors. Who hates black or white -  most probably someone? To overcome this problem, there needs to a be a despot in the organization who decides about the visuals. This despot can be a predefined document that people follow, usually called Look and Feel (LAF) document or a style guide, or the despot can be an individual in the company. I’m not saying that this despot should not ask for feedback on visuals, but this despot’s main responsibility should be to keep the visuals consistent, and according to company brand.

Overall visual consistency, brand identity and visibility are the two most important aspects of software visuals. Overall visual consistency is one of the important aspects in creating consistent user experience. Consistency in this refers to  usage of visual cues and elements in similar manner in similar contexts and reusing these same patters where applicable. Company brand visibility in the visuals is important from overall user experience perspective to ensure that the experience created outside the usage of the software, like with customer visit, website visits and other marketing efforts are also linked to the software. Consistent and uniformly presented brand identity helps in leveraging this impact through the use of the software.

Of course it does not hurt to make the visuals also beautiful, but when it comes to building user experience, if company brand is not built on beauty, the software created does not need to be built on it either. And as with opinions on visuals, beauty is also in the eye of the beholder.

If, however, the visuals are the only thing in a place in a piece of software, the software diminishes to a painting. If your goal was to use the software to solve some problem, the mere painting will not probably solve your problem. And of course, if your goal was to enjoy nice painting or two, there are probably more pleasant environments to do this, like Louvre or Eremitage . To make sure you are not just looking at a nice looking painting, ask for a live demo or try the piece of software yourself. You will know in minutes if you are looking at a real software or just a nice painting.

So what lies beneath the surface that really makes the difference when it comes to a truly great user experience? I’ll share some of my insights in the next post -  so stay tuned!

Excuses for postponing self-service implementations:

• No budget
• No resources to implement this
• It’s so complicated
• We need to describe all of our services and processes first

No budget

Web Self-Service

Self-service cuts down internal costs, shortens end-to-end service delivery processes, and improves end user satisfaction tremendously. If you consider how much more efficient online services are when serving customers, my question is this: how do you plan to get these benefits, if you don’t implement self-service? If your IT doesn’t have the budget now, why don’t you bring this to management?

No resources to implement this

The thing is: self-service releases time from fire-fighting. When every single service request contains the necessary information, suddenly your organization becomes much more efficient. Requests are easy to handle; they are automatically forwarded to correct delivery channels etc. We’ve had one customer case that has been postponing for 9 months now due to customer’s lack of resources. In a year, they could have saved over million euros due to improvements in the ordering processes, and they would have solved the problem. Instead, they are still fire-fighting. What a waste. A direct quote from one of our customers who implemented a self-service channel: ”After implementing this it seems so stupid that we haven’t done this before”. Self-service is a cure for not having enough resources. It just needs to prioritized high enough.

It’s so complicated

No it’s not. In our experience, it’s really not complicated at all. It may feel complicated because you haven’t done it before. But when your self-service tool has a good baseline for services that you just adjust to your organization, it’s actually very straight-forward, and if the self-service channel is implemented well, it’s also easy to maintain and develop further. We typically ship in one month, and during that month the services are defined. One of our customers was able to implement not only the self-service channel but also the backend processes in 2 months, and they immediately dropped the number of calls by over 10% and were able to move many employees to new roles due to productivity improvements.

We need to describe all of our services and processes first

Good luck. You may succeed in a year or two. In my experience, this typically leads to time spent in the internal stuff and end users don’t witness any benefits for a long time. In contrast, describing standard services for end users can be easily done during the self-service implementation. And for processes, improving them is much easier when the whole process starts right, and you have hard facts on how you perform in regard to different services. I’m not against describing processes and services. It’s just that it’s easier after self-service implementation, and you get concrete benefits faster. Again I can compare some real-life cases: implementation of self-service in one month and immediate benefits vs. over a year of defining processes and services that haven’t yet contributed to real life savings.

Just get it done

In our experience, self-service helps the organization from day one after it’s launched. The business reasons for implementing it come from cost reductions, improved service delivery, and higher customer satisfaction. Every employee wants this, and everybody talks about this. Enough talk, let’s start walking!

The expression “Experience matters” tries to refer to something new experienced using a particular software. Still, the old experiences have great effect on the new experience caused by the software. So how to limit the effects of this old experience to the new one? There is, of course, no proven way to do this limitation, but certain experiences can be neglected as having only minor effect on the experience. On the other hand, certain experiences have much stronger effect. If you consider for instance time, usually if the experience has not been very traumatizing, more recent experiences have typically more weight when considering how the new experience really feels like. Also, context of the experience has more weight the closer the experience is in context related to the new experience. For instance, usage of computers and different software has usually greater weight to the new experience felt when using an another software, when compared to the weight of for example a skiing trip to the Alps.

Use of software can sometimes draw users’ full attention – like when teenagers play some fairly addictive game. It may seem that nothing can distract them and their full attention is drawn by the game. In this situation, the game can actually fairly well control the current experience spiced up of course with the previous experiences of the teenager. Typically there are, however, plenty of distractions present when using software. If I consider myself in the office, the list of distractions is fairly long: people come to chat fairly often, emails keep popping up, Skype and Communicator chat sing all the time, phone rings from time to time. And that’s only the internal distractions. In addition, in an open office environment there is at least the same amount of external distractions. All these distractions have an effect on the overall experience.

Different User Roles

The issues described above are something that we as a software company have no control over. But there are, however, many things that we can control. The self-service product that we are developing is meant to solve certain problems. All people do not have these problems. This starts to limit the amount of different kind of users able to use the channel. We can go further and defined user roles to categorize potential users. And in fact now that I have babbled all along about experience there is already an existing “field” and buzz-word called User experience or UX that has plenty of tools to tackle the issues related to experience of users’ using software products.

Jesse James Garrett has fairly well described the different elements related to User experience in his book. These elements from concrete to abstract include:

•   Surface (Visual appeal)
•   Skeleton (UI design)
•   Structure (Information architecture)
•   Scope (Product backlog)
•   Strategy

In the future blog entries I try to tackle each of these elements in more detail. Tell more how we face these elements? And what are biggest problems, fallacies and pitfalls related to these elements?

So stay tuned!

Onnistuimme hienosti myös haastavista henkilöstön vaihdoksista. Aina energinen ja avulias Antti Kuulas siirtyi syventämään osaamistaan korkeakoulumaailmaan ja jatkaa opiskelun ohessa Efectellä lomatuurauksissa. Antin lisäksi myös pitkän linjan Efecte-ammattilainen Katriina Passila jäi toistaiseksi pois jäätyään äitiyslomalle. Tämän lisäksi Efecte-guru Tero Matinlassi siirtyi yhteistyökumppanimme Vercon porukkaan.

Keilaniemi aamun koitteessa

Vaikka Tuija Länsisalmen kattava osaaminen riittäisi hoitamaan tuen yksinäänkin, tiimiä ei sentään yhden ihmisen varaan voi rakentaa. Onneksemme löysimme porukkaan aivan loistavat uudet tukihenkilöt. Milla Kangas omaa yli 10 vuoden kokemuksen ICT-alalta ohjelmistojen tuki- ja ylläpitotehtävistä. Olen äimistynyt siitä poikkeuksellisesta nopeudesta, jolla Milla on ottanut Efecte-tuotteita haltuun. Viimeisenä porukkaan liittyi Olli Savolainen. Ollilla on jo aiempaa kokemusta Efecte-tuoteperheestä hänen siirryttyä meille asiakkaaltamme Tieto-Tapiolalta. Jo ensimmäisen kuukauden aikana Olli on ottanut vastuuta tukitöissä ja nopea oppiminen on täydessä käynnissä.

Lisäksi teemme tukiyhteistyötä kumppanimme NotkiaIT:n kanssa, jossa kolme kovan tason Efecte-osaajaa palvelee asiakkaitamme aina tarpeen tullen.

Ollin ja Millan tuoma uusi virta yhdistettynä Tuijan syvään ammattitaitoon takaavat sen, että myös vuonna 2012 asiakkaamme voivat nauttia äärimmäisen laadukkaasta tukipalvelusta, jossa ongelmia ei siirrellä ja haudata, vaan ne ratkaistaan.

Efecten tukipalvelu toivottaa asiakkaillemme hyvää uutta vuotta 2012.

P.S. Muutimme myös vuoden vaihteessa uusiin toimitiloihin Espoon Keilaniemeen. Oheisesta kuvasta näkyy miltä näyttää maailma Efecten tukihenkilön työpisteestä käsin.

Times have changed and now part of my profession is about writing stories. You all probably heard about user stories. And if you have been involved with agile software development, you know that user stories are the building blocks of an agile software development backlog. Stories are sentences in the business language of the end user that captures what the user wants to achieve. In addition to this, user stories should also fulfill the INVEST criteria, i.e. stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Simple right? Well, not necessarily. To create stories that fulfill these criteria, product owners need to grasp the market needs, user needs and iterate over and over again with the development team. This is the bread and butter of product owners in agile projects. The only problem in these criteria is that they have been created to support the agile software development, but agile software development itself does not support creation of easy-to-use software.

So how to create stories that also support easy-to-use software?

1. As a  <Role>, … when writing the stories make sure the user role from which the story is written, has a persona defined
2. Independent: although the stories need to be independent from each other, they also need to map to at least one user workflow to create connection points to existing users’ stories that have been created. Or then, the story itself needs to create a workflow of it’s own.
3. Negotiable: to ensure also the negotiability on the ease-of-use there needs to be sketches the users and product managers can comment and negotiate. Same kind of negotiability needs to be achieved through usability testing of the prototypes and ready-made software.
4. Valuable: stories need to be valuable for the market, and for the buyer, but the most important part in creating easy-to-use software is to make sure the stories are valuable to the real users of the software. The users needs to have a real problem that the software solves – and solves it well thus creating value.

Just as with children’s books the ones that are on the top of the pile are the one read most often – in product backlog the stories with most value are also on the top of the pile. And actually the same applies for the UI design for stories: the stories used the most in the software should be on top of the pile, that is, visible in the first view of the software. Biggest problems in creating the pile arise from the fact that just as most of us had a different favorite story as a child, so do users have different problems that they need to solve.

By creation simple stories that at the same time fulfill all the criteria define above, we are one step closer in creating also simple and easy-to-use software. Impossible could my physicist buddies say. But I assure that we will do this and ride the bathtub side-by-side with Pablo towards the warmth of the south!

Site-note: Actually Pablo is probably riding north, because he is from the south-pole, but I prefer south especially at the moment.

Katalogin ylläpito ja kehitys

Laitemallit ja versiot muuttuvat jatkuvasti. Miten katalogi suhtautuu tähän?

Loppukäyttäjää harvoin kiinnostaa laitteeseen liittyvät yksityiskohdat. Katalogi kannattaa rakentaa standardoitujen laitekategorioiden ympärille. Sen sijaan että katalogissa on valittavana teknisiä laitemalleja, kuten Dell Latitude E6410, siellä tulee olla ”Kannettava”, ”Kevytkannettava”, ”Tehokannettava” jne. Itse kuvaukseen voidaan haluttaessa lisätä esim. linkki laitemallin kuvaukseen. Näin toimittaessa katalogin rakenne ei muutu ja käyttäjien on helppo löytää haluamansa palvelut.

Puhelimet koetaan henkilökohtaisemmin, ja niiden merkistä ja mallista ollaan kiinnostuneempia. Puhelinten tapauksessa usein on päädytty mallikohtaiseen katalogiin kategorioinnin sijaan:

Esimerkki palvelukatalogin puhelinvaihtoehdoista

”Nokia E9”, ”Apple iPhone”, ”Samsung Galaxy S (Android)”.

Ohjelmistoissa joidenkin ohjelmien versioinnilla on myös merkitystä. Siinä missä Skypen versio ei ole käyttäjän kannalta kiinnostava, Adobe Photoshopin tai Windowsin versio voi olla hyvinkin merkityksellinen. Peukalosääntönä kannattaa välttää versioiden korostamista ja ainoastaan niiden sovellusten osalta joissa sillä todella on merkitystä, se kannattaa ottaa huomioon. Joistakin ohjelmistoista täytyy tarjota useampia vaihtoehtoisia versioita samaan aikaan.

Mitä katalogiin kannattaa sisällyttää pitkällä aikavälillä?

IT:stä tulee itsepalvelua. Itsepalvelu on ylivoimainen tapa tuottaa korkeatasoista peruspalvelua kustannustehokkaasti. Mitä enemmän katalogiin voidaan viedä asioita, joita käyttäjät tarvitsevat, sen parempi. Kaikki mahdollinen kannattaa tuoda katalogiin ainakin saataville. Se, että tapahtuuko varsinainen tilaaminen kaikissa tapauksissa kyseisestä järjestelmästä, on toinen kysymys.

Tuodaanko katalogiin kaikki palvelut kaikilta yksiköiltä ja toimittajilta?

Tähän kysymykseen ei ole yksiselitteistä vastausta. Oleellisia kysymyksiä jokaisen eri tilauskanavan kohdalla ovat:

• Käytetäänkö kanavaa oikeasti, vai menevätkö tilaukset service deskin tai jonkin muun tahon kautta?
• Kuinka tyytyväisiä käyttäjät ovat kyseiseen tilauskanavaan?
• Kuinka paljon aikaa organisaatio käyttää tilaamiseen kanavan kautta?
• Voidaanko kanava korvata helposti katalogin toiminnallisuuksilla?

Katalogin kautta tulee päästä käsiksi palveluihin mahdollisimman laajalti, mutta itse tilaamista ei tarvitse kaikissa tapauksissa tehdä katalogista, jos perusteet muiden kanavien käyttöön ovat olemassa.

Kuka vastaa päivittämisestä?

Tässä on kaksi vaihtoehtoista mallia: yksi keskitetty henkilö/funktio hoitaa kaikki muutokset, tai palveluista vastaavat hoitavat itse myös katalogia. Molemmat mallit voivat toimia, mutta aluksi suosittelen käyttämään keskitettyä henkilöä / tiimiä, jotta kuvauksista tulee yhdenmukaisia ja hyvät käytännöt palveluiden kuvaamiseksi saadaan luotua.

Katalogin luonti ja käyttöönotto

Mitä katalogiin kannattaa sisällyttää ensimmäisessä vaiheessa?

Kaksi tärkeintä näkökulmaa tähän ovat:

1. Käyttäjien tarpeet. Ensimmäisessä vaiheessa pitää olla riittävästi palveluita, joita käyttäjät tilaavat ja kokevat tärkeiksi. Organisaatiokohtaista vaihtelua on jonkin verran,

tässä tyypillisimpiä IT-palveluita:

Type of Service Catalog

• Ongelmien raportointi
• Ohjelmistojen tilaukset
• Käyttöoikeuksien tilaukset
• Lisälaitteiden ja -tarvikkeiden tilaukset
• Puhelin- ja liittymätilaukset
• Työasematilaukset
• Etäyhteyksien tilaukset
• Uuden työntekijän aloitus
• Työntekijän poistuminen

2. Mitä saadaan nopeasti ulos. Pitkät projektit näivettävät porukan, ja katalogin kulmia on ylipäätään turha hinkata loputtomiin. Arvoa pitää kuitenkin olla tarpeeksi, joten käytännössä esimerkiksi yllämainitun listan ensimmäiset viisi palvelua voi riittää lanseeraukseen. Tällöin käyttäjät saavat katalogista nopeasti arvoa, ja palveluorganisaatio oppii palautteen perusteella.

Mitä kaikkea tulisi integroida?

Ensimmäisessä vaiheessa mahdollisimman vähän, ja pidemmän päälle mahdollisimman paljon. Alussa tärkeintä on ratkaista käyttäjien ongelma ja päästä nopeasti tuotantoon. Kun käyttäjillä on helppo kanava palveluiden tilaamiseen, seuraavassa vaiheessa voidaan integraatioilla automatisoida toimitusprosesseja, ja nostaa tuottavuutta vielä lisää. Se, että käyttäjiltä tulee jatkuvasti määrämuotoisia palvelupyyntöjä tehostaa toimintaa jo valtavasti. Tämän jälkeen myös raportoinnin avulla ymmärretään paremmin, mitä todella kannattaa automatisoida. Tyypillisiä kohteita ovat mm. palveluntarjoajien Service Desk -järjestelmät.

Käyttöönotto

Jos palvelua ei kukaan käytä, se lienee aika hyödytön? Julkaise siis kunnolla. Parhaat tulokset on saatu seuraavin toimenpitein:

1. Teaser koko organisaatioon pari viikkoa ennen julkaisua
2. Käydään tehotilaajien (sihteerit, IT-vastaavat, palvelupäälliköt yms.) kanssa palvelu läpi
3. Käyttöönottopäivänä tiedote ja kilpailu, johon voi osallistua tilaamalla erityisen ”kilpailutuotteen”. Tämä kannustaa kokeilemaan, jolloin palvelu jää paremmin mieleen.
4. Ensimmäisten päivien aikana aktiivinen seuranta ja tuki

Kun katalogin käyttöönotto onnistuu hyvin, ylläpidosta ja jatkokehityksestä tulee huomattavasti helpompaa. Jatkoa käsittelemme Q&A -sarjan seuraavassa osassa.

Mikä on palvelukatalogin suhde muihin järjestelmiin?

Intranetin suhde palvelukatalogiin

Intranet on tiedonvälitys-, ryhmätyö- ja kommunikaatiokanava. Intranetistä käyttäjät löytävät ajankohtaista  ja ajantasaista tietoa yrityksestä, käyvät keskusteluja aiheiden

tai projektien ympärillä ja etsivät tietoa. Loppukäyttäjien palvelukatalogi puolestaan on sisäinen palveluiden tilauskanava. Sitä käytetään, kun IT:ltä tai muilta sisäisiltä

Loppukäyttäjän palvelukatalogi monitoimittajaympäristössä

yksiköiltä tarvitaan palveluita. Intranetissä tulisi olla etusivulla näkyvästi esillä linkki palvelukatalogiin, jotta käyttäjien olisi helppo päästä tilaamaan tarvitsemansa palvelut. Intranetin kehittäminen tilausjärjestelmäksi on kallista, ja toteutus on aina asiakaskohtainen räätäliratkaisu. Käytettävyydessä intranet-ratkaisut harvoin pääsevät riittävälle tasolle, ja palvelukatalogin kehittäminen ja ylläpitäminen vaatii aina lisätyötä.

Hankintajärjestelmät ja palvelukatalogi

Hankintajärjestelmät on luotu ulkoiseen hankintaan. Palvelukatalogi on luotu sisäiseksi palvelukanavaksi. Hankintajärjestelmistä ei löydy ongelmanraportointia, käyttöoikeuspyyntöjä, uuden työntekijän aloitusta tai muita palveluita, jotka eivät ole lähtökohtaisesti hankintoja. Hankintajärjestelmissä palvelut kuvataan tyypillisesti tuotteiden näkökulmasta: mitä tämä tuote sisältää ja mitä se tekee. Loppukäyttäjien palvelukatalogissa palvelut on kuvattu käyttäjän näkökulmasta: keille tämä on tarkoitettu ja millaiseen käyttöön.

Palvelukatalogin suhde Service Desk -järjestelmiin

Palvelukatalogi toimii ensimmäisenä kanavana loppukäyttäjiin päin, ja sen taustalla voi toimia useita Service Desk -järjestelmiä tai tukikanavia. Palvelukatalogin kautta käyttäjät tilaavat palvelunsa tai raportoivat ongelmista. Palvelukatalogi ohjaa pyynnöt automaattisesti oikeisiin kanaviin, joista osa on Service Desk -järjestelmiä, ja osa mahdollisesti tavallisia sähköpostiosoitteita. Pyyntöjen tarkkaa seurantaa varten tieto pyynnön tilasta saadaan Service Desk -järjestelmistä.

Ulkoisten toimittajien katalogit

Ulkoisten toimittajien katalogit vaihtelevat. Usein katalogi sisältää vain kyseisen toimittajan palvelut. Tällöin loppukäyttäjän näkökulmasta kaikkia palveluita ei saada yhdestä kanavasta. Esimerkiksi uuden työntekijän aloitukseen liittyy useita erilaisia pyyntöjä, jotka jakaantuvat eri kanaviin: työasema, käyntikortit, ID-kortti, avaimet jne. Loppukäyttäjäkatalogi voidaan integroida suoraan toimittajien järjestelmiin, tai vaihtoehtoisesti ohjata käyttäjät automaattisesti tilaamaan tietyt palvelut ulkoisesta katalogista. Loppukäyttäjäkatalogin kehityksen tulisi olla helppoa ja siihen olisi tärkeää voida lisätä uusia palveluita ja muuttaa olemassa olevaa palveluvalikoimaa, riippumatta siitä kuka katalogin toimittaa.

Mikä on loppukäyttäjän IT-palvelukatalogi?

ICT WebShop

IT-palvelukatalogia kannattaa ajatella yrityksen sisäisenä IT:n verkkokauppana, IT:n itsepalvelukanavana. Kyseessä ei ole lista asioista tai kuvauksia palveluista yleisesti, vaan konkreettisia tilattavia palveluita ja tuotteita, joita työntekijät IT:ltä tarvitsevat. Näitä ovat laitetilaukset (puhelimet, tietokoneet, lisälaitteet, tulostimet jne), käyttöoikeustilaukset, ongelmien raportointi oikeisiin kanaviin, uuden työntekijän aloitus jne. Helppo, konkreettinen palveluiden tilauskanava.

Voiko katalogia laajentaa IT:n ulkopuolelle?

Voi. Tyypillisiä laajennuksia ovat muut tilattavat asiat kuten käyntikortit, avaimet, ID-tunnukset sekä mm. työntekijän aloitusprosessissa hoidettavat IT:hen liittymättömät tilaukset. Kaikkia palvelutilauksia ei yleensä ole mahdollista tai mielekästä siirtää palvelukatalogiin. Tällöin tärkeintä on huolehtia palveluiden löydettävyydestä. Hyvä käytännön tapa on sisällyttää palvelut katalogiin, ja ohjata käyttäjä sieltä varsinaiseen tilausjärjestelmään. Näin kannattaa toimia mm. tapauksissa, joissa toinen tilausjärjestelmä on jo saanut vahvan roolin, ja automaatioita on rakennettu järjestelmän ympärille. Tällainen järjestelmä voi olla esim. pitkälle viety käyttöoikeuksien tilaamiseen tarkoitettu järjestelmä.

Kuka omistaa katalogin?

Parhaiten vaikuttaisi toimivan malli, jossa koko katalogin omistaa henkilö (palvelupäällikkö), jolla on näkemys katalogista kokonaisuutena, ja jonka tavoitteena on huolehtia, että loppukäyttäjien näkökulmasta palvelut ovat ymmärrettäviä ja hyvin rakennettuja. Tämä henkilö työskentelee muiden palvelupäälliköiden kanssa ja auttaa heittä tuotteistamaan palvelunsa helposti tilattavaan muotoon. ITIL-terminologiassa puhutaan Service Catalog Managerista. Pienissä ja keskisuurissa organisaatioissa rooli ei ole kokopäiväinen, mutta käynnistysvaiheessa tälle pitää varata aikaa.

Ketkä saavat päivittää katalogia?

Tämä vaihtelee organisaatioittain. Sekä keskitetty että hajautettu malli voi toimia. Keskitetyssä mallissa yksi henkilö ylläpitää katalogia, huolehtii katalogin yhdenmukaisuudesta ja tekee kaikki muutokset katalogiin. Hajautetussa mallissa palvelupäälliköt saavat tehdä muutoksia omiin palveluihinsa suoraan. Tällöin muutosten teko on helppoa ja vastuu on siellä missä palvelun omistajuus on, mutta yhdenmukaisuus kärsii.