CSDM toimii muuallakin kuin IT-palveluissa

Aamukahviwebinaarissamme 8.12. Aleksi kertoi omista käytännön kokemuksistaan ServiceNow CSDM:n hyödyntämiseen liittyen. Tähän blogiin on koottu webinaarista tärkeimmät nostot. Sen lisäksi kannattaa katsoa webinaaritallenne – erityisesti esityksen jälkeen tuleva keskustelu- ja kysymysosio!

Usein kysytty kysymys on, pitääkö CMDB olla jo olemassa, jotta CSDM:ia voi hyödyntää. Vastaus lyhyesti ja ytimekkäästi kuuluu: Ei tarvitse.

Palveluiden mallintaminen luo CMDB:n palveluista. Jos palveluihin liittyy rakennuspalikoita, kuten muita palveluita, laitteita, lisenssejä tai softaa, malli sisältää mahdollisuuden näiden riippuvuuksien luomiseen. Voitaisiinko siis CSDM:ia hyödyntää muuhunkin kuin IT-palveluiden mallintamiseen? Kyllä voidaan.

CSDM ja mitä se on

CSDM, Common Service Data Model, on referenssimalli. Se ei ole prosessi eikä työn tekemisen malli. Se on ’best practice’ CMDB-datan luomiseen ja antaa ohjeistusta, miten mallintaminen voidaan tehdä. Se ei ole mitään, missä tarvitaan edes ServiceNowta, taikka mitään, josta pitäisi erikseen maksaa. Referenssimallia voi mainiosti soveltaa ilman ServiceNowtakin, vaikka se sisältääkin paljon ServiceNow:n terminologiaa. Siitä näkökulmasta ServiceNow:n toimintalogiikan ymmärrys on hyödyksi.

CSDM jakaa datan neljään osa-alueeseen:

1. arkkitehtuurillinen suunnittelu
2. liiketoiminnan palvelut ja palvelukatalogit
3. tekniset palvelut ja palvelukatalogit sekä (klassinen) operatiivinen CMDB
4. yleinen taustadata.

 Viides datan osa-alue on sovelluskehitys/devops-komponentit, jonka käyttö ja toiminnallisuudet ovat vielä ServiceNow:lla kehityksessä.

Tiedä, kuka asiakkaasi on

Koko CSDM:n kannalta yksi kriittisistä kysymyksistä palveluiden mallintamisessa on ymmärtää, kuka on se asiakas, kenen palveluita ollaan mallintamassa. Kaikilla organisaatioilla on palveluita, joita organisaatio tarjoaa omille asiakkailleen. Kaikilla organisaatioilla on myös palveluita, joita ne saavat omilta palveluntarjoajiltaan ja kumppaneiltaan. Puhutaan teknisistä palveluista ja liiketoimintapalveluista.

Ydinkysymys on, kenelle ne minun palveluni oikeasti menevät. Erityisesti kysymys tule esiin IT-palvelumaailmassa, mutta yhtä lailla myös yhtiön HR-, taloushallinto- ym. palveluissa.

Usein ajatellaan, että liiketoimintapalvelut ovat niitä palveluita, jotka organisaatiosta tai yksiköstä tuotetaan ulos. Tekniset palvelut saadaan kumppanilta. Mutta IT- yksikkönä asiakkaasi onkin loppuorganisaatiosi. Kysymys kuuluukin, tarjoatko liiketoimintapalveluita vai teknisiä palveluita. Tarjotaanko tuottamiasi teknisiä palveluita kenties osana koko organisaation liiketoimintapalveluja ’ulos’ asiakkaille asti?

ServiceNow-työkalunäkökulmasta on kuitenkin lopulta suhteellisen vähän merkitystä, mitä mallinnetaan teknisiin palveluihin ja mitä liiketoimintapalveluihin. Linja täytyy vain päättää, ja sitä pitää tarvittaessa muistaa myös uudelleenarvioida. Peruuttamattomia virheitä on vaikeaa tehdä.

Asiakkaalle tuottamasi liiketoimintapalvelu muuttuu jonkun toisen tekniseksi palveluksi

IT-maailmassa eniten törmätty ongelma ja hahmotusvaikeus on se, että sinun tarjoamasi liiketoimintapalvelu onkin asiakkaallesi tekninen palvelu.

Asiakas haluaa nähdä vaikutusanalyysejä, muutoksenhallintaa ja tikettiraportteja suhteessa omiin liiketoimintapalveluihinsa. Jotta voit palveluntarjoajana kohdistaa vaikutukset asiakkaan liiketoimintapalveluihin, asiakkaan pitää kyetä tekemään oma osansa ja kertomaan, mitkä hänen liiketoimintapalvelunsa ovat ja mitä palveluntarjoajana tuottamistasi palveluista hän käyttää minkäkin oman liiketoimintapalvelunsa rakennuspalikkana.

Kun asiakas haluaa ymmärtää sinun palveluittesi vaikutuksen omiin palveluihinsa, on hänen siis ensin tunnistettava omat liiketoimintapalvelunsa. Tässä ketjussa sinun liiketoimintapalvelusi asiakkaalle muuttuu jonkin toisen tekniseksi palveluksi. Tähän oivallukseen nojaa paljon CSDM:n hyöty ja logiikka.

Sudenkuopat kaksi ja kolme: terminologia ja liiketoimintasovellukset

Toinen yleinen sudenkuoppa on terminologia. Esimerkiksi termi Service offering on ServiceNowssa se ilmentymä palvelusta, jota aktiivisesti toimitetaan asiakkaalle. Yleisessä kielessä taas puhutaan toimituksessa olevasta palveluversiosta. Myös palveluportfolion käsite on syytä hahmottaa. CSDM sisältääkin paljon ServiceNow:n terminologiaa, joka eroaa jonkin verran yleisestä palvelunhallinnan terminologiasta, erityisesti suomennettuna.

Viimeinen keskeinen ymmärrysasia CSDM:ssä on se, mitä liiketoimintasovellukset ovat. Palvelut lähtevät paljolti liikkeelle järjestelmästä tai liiketoimintasovelluksesta, joka on liiketoiminnan kannalta keskeinen (esim. SAP). Isolle järjestelmälle tyypillistä on, että siitä on käytössä eritasoisia ympäristöjä eli Application servicejä  (joka ei tarkoita sovelluspalvelua, vaan stackia tai instanssia).

CSDM on palvelukeskeinen konsepti, kuten nimestä voi arvata. Liiketoimintasovelluksista puhuttaessa palvelumallinnuksen voi silti hyvin tehdä ilman sovelluksen mallinnusta, mutta käytännössä kaikessa on takana ATK:ta. Miksi et siis samalla mallintaisi näitä riippuvuuksia työkaluusi?

Lopulta voi olla vain yksi

Seuraava hankaluus on se, että omistajia on hirvittävän paljon.  Sitä ei pääse millään karkuun, sillä laadukas tiedonhallinta vaatii tiedolle omistajia. Näitä omistettavia asioita on paljon: on osa-alueet, tietomallin omistajat, tiedon omistajat, palveluiden omistajat, ServiceNow-omistajat (työkalun ja sen toiminnallisuuksien omistajat) sekä liiketoimintasovellusten omistajat (yksittäisen sovelluksen omistajat).

Laadukas tekeminen on kaikkien näiden yhteistyötä. Sama ihminen voi omistaa useamman kuin yhden näistä osa-alueista, mutta äärimmäisen harvoin yksi voi kuitenkaan omistaa kaikkea. Jos kyseessä on yhtään isompi organisaatio ja enemmän tietoa, se tarkoittaa käytännössä sitä, että omistajia tarvitaan enemmän. Ja kaikkien tekemistä tarvitaan, jotta malli voi onnistua.

Omistaja voi myös jakaa osa-alueensa operatiivista työtä managereille, joita voi puolestaan olla useita. Tällöin managerilla tai manageriryhmällä on operatiivinen vastuu tiedon käytöstä ja ylläpidosta, mutta omistaja on edelleen RACI-matriisin mukaan Accountable, tiedosta ja osa-alueesta vastaava henkilö. Näitä voi olla vain yksi.

Useimmin huomatut CSDM:n puutteet

Hyödyistään huolimatta CSDM ei ole täydellinen. Kolme yleisimmin vastaan tullutta puutetta CSDM-mallissa ovat seuraavat:

1. Loppukäyttäjäpalveluille ei ole kunnollista mallia. Näiden mallintaminen vaatii luovaa soveltamista.
2. Integraatioiden mallinnusta ei mallissa käytännössä ole olemassa.
3. CSDM:n mallin out-of-the-box -logiikka on paikoin sisäisesti epäkonsistentti.  Esimerkkinä tästä voisi nostaa relaatiot application servicen ja sitä tukevien technical service offeringien (TSO) välillä verrattuna palvelinten (tai muiden infrakomponenttien) ja niitä tukevien TSO:ien välillä.

CSDM toimii muuallakin kuin IT:ssä

Kaikkea edellä mainittua voidaan hyödyntää myös muihinkin kuin IT-palveluihin. Olennaisinta on

• ymmärtää tarjottavat palvelut
• tunnistaa asiakkaat
• varmistaa omistajuudet.

Tiketit ovat kuitenkin vain tikettejä. Loppu onkin niiden käsittelyprosessia, kun palvelulla on tukiryhmä ja vastuuhenkilö.

Webinaaritallenteen ja sitä seuraavan mielenkiintoisen keskustelu- ja kysymysosion pääset katsomaan tästä.

Lataa Justinin ilmainen PDMC-tietomallipohja täältä: The PDMC 1.0 – JustinShop

Julkaistu 20.12.2023