Vaaleanpunaisia omenia

Peter Benson heitti ECCMA:n kesäkuun uutiskirjeessä mielenkiintoisen esimerkin hierarkisten luokittelujen ongelmista. Vaikka yritykset orjallisesti noudattaisivat UNSPSC – luokittelua tai jotain muuta standardia, joka pohjautuu hierarkisuuteen, törmätään vääjäämättä jossain vaiheessa hankaluuksiin. Sama nimike näyttäisi yksiselitteisesti kuuluvan useampaan luokkaan.

Peterin esimerkki oli omenat – ei se puhelimiakin valmistava IT-yritys, vaan tämä ihmiskunnan historiassa merkittävää roolia näytellyt hedelmä, jota Aatami ja Eeva maistelivat ja joka Newtonin päähän pudotessaan mullisti käsityksen maailmankaikkeudesta.  Siis ruokakaupan hyllyiltä löytyvä tuote ”Pink Lady® apple”, joka on UNSPSC luokittelussa määritelty kahdeksaan (8) eri luokkaan:

Pink lady apple UNSPSC luokat

Pink lady apple UNSPSC luokat

Tuon omena-esimerkin voi käydä lukemassa originaalina täältä, hyvä tarina: ECCMA June Newsletter

Esimerkki on loistava siinä mielessä, että siinä esiintyy lähes kaikki tyypilliset nimikeluokittelussa tehtävät virheet. Ensinnäkin Pink Lady® on rekisteröity tavaramerkki – siis brandi. Sitä ei kannata sotkea esimerkiksi termiin, joista muodostuu yrityksen sanasto.

Viime aikoina olemme tehneet useampia sanastoprojekteja, joissa brandi-nimien ohella on tullut vastaan erilaisia apusanoja, kuten ylä, ala, taka, sivu, oikea, vasen. Pahimmillaan sanastossa on termejä tyyliin: ”1. vasen tukivarsi”, ”2. vasen tukivarsi”, ”3. oikea tukivarsi” … Tämä generoi tietysti kielenkääntäjälle töitä, kun kaikki variaatiot käännetään jopa kymmenille kielille.

Loputon suo

Omena-esimerkissä luokittelutekijöihin on lisäksi sotkettu viljelysmenetelmä sekä jälkiprosessointi, joka johtaa siis jäädytettyihin orgaanisesti viljeltyihin omeniin sekä jäädytettyihin muuten vaan viljeltyihin omenoihin. Koska ryhmä ei vielä kerro, onko omenat jäädytetty kokonaisina, viipaloituina vai murskattuina tarvitsemme todennäköisesti vielä lisää ryhmiä. Tällä mallilla suo on loputon. Konepajamaailmassa tyypillisin luokittelusynti on sekoittaa nimikkeen käyttökohde ja funktio – siis esim. KIINNITYSLAIPPA vs. MOOTTORIN KIINNITYSLAIPPA, KYTKIMEN KIINNTYSLAIPPA, NOSTURIN NH15 KIINNITYSLAIPPA jne

Hierarkisuus sinänsä on erittäin ymmärrettävää, koska ihmiset ja varsinkin me insinöörit olemme tottuneet jäsentämään asioita hierarkisesti. Tietojärjestelmät eivät hierarkisuutta tarvitse, joten näin tietointensiivisenä aikana olisi hyvä yhdistää nämä molemmat asiat. Tietomallin luonnissa siis pyritään välttämään kiinteitä hierarkioita, jottei synny duplikaatteja, mutta käyttäjälle pitäisi pystyä asiat tuomaan tarpeen mukaan erilaisten näkymien ja polkujen kautta.

ISO 8000 mukainen kuvaus

ISO 8000 mukainen kuvaus

Tässä hypätään nyt hieman idealistiselle puolelle. Koko nimikkeistön attributisointi kyseiseen tasoon on monelle yritykselle tekemätön paikka. Tietotekniset työkalut ja algoritmit kyllä työssä auttavat mutta puhutaan joka tapauksessa megalomaanisesta työmäärästä, jos nimikemäärä on satoja tuhansia.

Suunta kyllä kannattaa pitää mielessä ja aloittaa esimerkiksi myytävistä omista tuotteista, toimittajat nimittäin vastaavat ostokomponenttien jalostamisesta, mikäli haluavat niitä myydä 😉

PS: En siis mitenkään halua kyseenalaistaa UNSPCS-luokittelun käyttämistä – päinvastoin, mutta sitä kannattaa käyttää omiin tarpeisiin järkevästi soveltaen.

Tässä kesäkuun saarna. Eiköhän lähdetä nauttimaan kotimaisista, UNSPSC-vapaista, kirkkaan punaisista mansikoista.

-PDM Preacher

Mainokset

Vastine edelliseen! Onko Big data enää isoa?

Joko tuo ”Big” etuliite voidaan poistaa? Datamassat paisuvat jatkuvasti, se on selvää. Siksi tuo ”Big” viittaa tänä vuonna eri suuruusluokan datamassaan kuin esimerkiksi viime vuonna. Puhutaan vaikka datatulvasta tai keksitään joku muu kuvaavampi termi.

Mietin datateemojen marssijärjestystä: Kumpi tulee ensin Big vai Master? Koska fuusioidaan tästä Big Master Data? No tulin siihen tulokseen, että Master Data on fokus numero yksi, jonka jälkeen katseet voidaan kääntää Big Dataan. Master Data ongelmia on kaikilla yrityksillä ja niiden rooli turhina kustannuserinä nousee taas tänä vuonna esille, kun monessa paikassa etsitään optimointikohteita. Suuria, jäsentymättömiä datamassoja ei vielä kovin moni organisaatio kaivele muutenkaan. Master Datan hallinta myös pakottaa miettimään datanhallintaprosessit ja vastuut valmiiksi, mikä helpottaa kaikenlaisten tulevien datahankkeiden onnistumista.

”Big Poppa Mastah Datanator”

Big Master Data –heittoni tuolla alussa ei ollut täysin tuulesta temmattu vitsi. Viime marraskuun Asiakaspäivässämme vieraillut ja tässä blogissakin aikaisemmin mainittu Peter R. Benson ennusti, että tulevaisuudessa ihmisen antama datasyöteDatan validointi nousee avainasemaan vähenee, ja järjestelmät synnyttävät ja vaihtavat dataa keskenään. Kuinka paljon esim. asiakasdatasta, siis siitä metadatasta, on oikeastaan kenenkään omistuksessa?

Vuodet vierii, tietomassat kasvaa. Joka vuosi massan kasvaessa sen oman asiakastiedon ja nimikemassan järkevöittäminen hankaloituu. Ehkä vuosi 2013 on hyvä vuosi nostaa data puheista tekoihin?

The data is already out there!

– Kalle –

Data is Truth

ECCMA:n puheenjohtaja Peter Benson totesi keynote-puheessaan asiakaspäivillämme, että noin neljä vuotta sitten alkoi maailma kääntyä. Todennäköisesti triggerinä ei ollut Obaman valinta ensimmäistä kertaa USA:n presidentiksi, vaan Lehman Brothersin romahdus, joka havahdutti miettimään montaa asiaa uudelleen. Siihen saakka DATA tyypillisesti edusti dokumentaatiota olemassa olevasta tilanteesta, ja nyt DATA on todellisuus – Information is Power, Data is Truth.

Datan merkitys totuutena näkyy monessa paikassa. Joskus – yleensä useimmin – myös negatiivisena ja koomisena. Koska samaa dataa käsitellään ja ylläpidetään useissa järjestelmissä, on suuri todennäköisyys sille, että datan hyödyntäjä saa käsiinsä aina väärää tietoa. Monella on varmasti omakohtaisia kokemuksia esimerkiksi terveydenhuollon alalta, koska meiltä puuttuu keskitetty potilasrekisteri. Onneksi kuitenkin verottaja tietää kaiken sinusta. Business-maailmassa törmätään yhä useammin kuvan kaltaisiin tilanteisiin.

Säästäminen ei ole seksikästä

Kaikesta huolimatta motiivi nimikedatan standardisointiin on lähtenyt alun perin jenkkien puolustusteollisuuden kustannussäästötarpeista. Kun saadaan parempi läpinäkyvyys sille mitä ollaan ostamassa, voidaan ostokustannuksissa säästää yksinkertaisesti vertailemalla eri tuotteita todellisten ja käyttötarpeeseen liittyvien ominaisuuksien suhteen. Säästäminen Cut Costs ei ole ainakaan jenkeissä koskaan ollut seksikästä, mutta ostotransaktiolla on aina toinenkin puoli. Jos tuote erottautuu hyvin erilaisissa Google-hauissa informaatiosisällöllään, sitä todennäköisesti myydään enemmän – More Sales.

Tuotteiden valmistajien on hyvä muistaa, että lain mukaan heillä on velvollisuus toimittaa asiakkaille tai asiakkaiden asiakkaille kaikki riittävä tieto tuotteesta, jotta sitä voidaan käyttää turvallisesti. Jos tiedon tuottaminen asiakkaiden kyselyihin on hankalaa ja aikaa vievää, palaa valmistajalla tiedon keräämiseen aivan turhaan resursseja – Save Resources.

Nimike yhteinen kieli

Bensonin mukaan sähköiset kyselyt tuotteiden tiedoista ovat lisääntyneet merkittävästi aivan viime aikoina ja vauhti vain kiihtyy. ISO 8000 ja ISO 22745 määrittelevät kuinka kysely tehdään ja kuinka siihen pitää vastata. Periaate on yksinkertaisuudessaan se, että sinun pitää tietää tarkasti mitä tietoa haluat. Jos saat asiakkaalta pyynnön: ”Lähetä minulle kaikki tuotetieto”, siihen ei tarvitse reagoida mitenkään. Mutta jos kysymys tulee muodossa: ”Kerro toimittamasi hydrauliventtiilin käyttölämpötila-alue”, siihen on parempi vastata. Kyseiset kysymykset alkavat jatkossa tulla XML-muodossa ja nyt on oiva aika alkaa kehittää valmiuksia myös sähköisiin vastauksiin.

Datan merkitys liiketoiminnalle saa johdon huomion vasta kun vaatimukset tulevat viranomaisilta. No hyvä uutinen data-evankelistoille yrityksissä on se, että viranomaisvaatimukset eivät ainakaan tulevaisuudessa vähene. Euroopassa tullaan vielä hieman perässä esimerkiksi SOX-vaatimuksia, jotka jenkeissä talous-datan osalta vievät talousjohtajat suoraan linnaan, mikäli tiedot eivät ole oikein. Ympäristön suojelun nimissä on jo tänään tuotteissa raportoitava vaarallisten aineiden osuudet, jotka luonnollisesti kuuluvat nimikkeen perustietoihin. Datan merkityksen tärkeyttä liiketoiminnalle kuvastaa se, että jenkeissä on alkanut yleistyä johtoryhmätason vastuu; CDO, Chief Data Officer, joka siis ei ole funktio tietohallinnossa, joka hienosta nimestään huolimatta keskittyy informaatiotekniikkaan.

Älä pelkää

Peter Benson on toiminut nimikedatan standardisoinnin puolesta 30 vuotta. Kun häneltä kysyttiin mikä on suurin syy siihen, että data on edelleen kuralla lähes joka yrityksessä, eikä siihen puututa vaikka kaikki sen myöntää, vastaus oli PELKO. Ihmiset pelkäävät, mitä kaikkea sieltä paljastuu, kun dataa aletaan penkoa ja siivota. Syyllistetäänkö heitä siitä, että tiedot ovat väärin tai puutteellisia? Saavatko he kenkää, tai joutuvatko maksamaan korvauksia siitä, että ovat olleet vastuussa legacy datan tuottamisesta? Ammutaanko viestintuoja?

No todellisuudessa ei ammuta. Kaikilla on data kuralla. Se joka saa sen ensimmäisenä kuntoon, on voittaja.

Kisa alkakoon.

– PDM Preacher

Missä se kura syntyy ja kuka siitä on vastuussa?

Kallekin jo aiemmassa kirjoituksessa viittasi otsikossa mainittuun aiheeseen, joka oli tänä vuonna Talentum Eventsin järjestämän Master Data Management 2012 -seminaarin esitekstinä. Seminaarissa moni puhuja korosti ihmisen merkitystä hyvälaatuisen tiedon hallinnassa, eikä varmasti turhaan. Yksittäisen tiedon laatuhan syntyy sitä syötettäessä.

Seminaarissa nähtiin esimerkkejä hyvistä käytännöistä. Niissä kaikissa oli jotain yhteistä. Master datan vastuu oli nimetyllä tiimillä, joka myös hallitsi dataa. Globaalin tason tiimi ylläpitää nimikedataa, ja tiimiltä pyydetään uutta nimikettä sitä tarvittaessa. Koska tiedon laatu on tiimin vastuulla, perustettava nimike tulee syötettyä tarkasti: oikeassa muodossa ja oikeat tiedot oikeissa kentissä, mahdollisen datastandardin mukaisesti. Luonnollisesti tiimi huolehtii myös siitä, ettei duplikaatteja pääse syntymään. Eräs toimija kertoi heidän sisäisen SLA:nsa uuden nimikkeen luonnille olevan 48 tuntia. Äkkiseltään ajateltuna tuon kuvittelisi aiheuttavan käyttäjäkunnassa nurinaa, mutta kokemukset ovatkin päinvastaisia. Ehkä suuri osa aiemmin nimikkeitä luoneista käyttäjistä on omakohtaisesti kokenut tuskaa miettiessään, mitä mihinkin kenttään pitää syöttää, missä muodossa syöte on, mitä yksiköitä käytetään missäkin, onkohan nimike jo olemassa –  tarvittavista kieliversioista puhumattakaan. Nimiketiimin palvelu ei siis ainoastaan paranna nimikedatan laatua, vaan poistaa myös peruskäyttäjiltä työtä, josta he eivät välttämättä pidä.

Vaikka nimiketiimin sisäinen prosessi on yksinkertainen, huolehtii se systemaattisesti ja jatkuvasti tiedon laadusta.

Ihmistyön tärkeyden ohella pitää työkalujen olla kunnossa siten, että ne tukevat mahdollisimman hyvin laadukkaan nimiketiedon tuottamista, ja että laadukas tieto saadaan luotettavasti yrityksen muihin järjestelmiin.

Sponsori

Toinen seminaarin esityksissä esiin tullut yhteinen piirre hyvissä ja huonoissa käytännöissä oli sponsori. Hyvissä käytännöissä master datan käytännöillä oli korkean tason, usein ylimmän johdon, ”tukija” yrityksessä. Huonoissa käytännöissä tuo niin sanottu sponsori puuttui. Ilman korkeimman johdon ymmärrystä ja sitä kautta tukea ei hommaan satsata tarpeeksi resursseja. Tai se joutuu jopa säästötoimien alle, vaikka jotain hyvää olisi saatu aluilleen. Viimeksi eilen kuulin asiakkaamme kertovan, että resursseista on joutunut alkuvaiheessa hieman tappelemaan. Onkohan kyse ollut juurikin riittävän korkean tason sponsorin puutteesta?

Mistä alkuun?

Yrityksissä on huomattava määrä tietoa, johon olisi hyödyllistä soveltaa MDM-käytäntöjä. Nimiketieto on asiakastietojen ohella tyypillisesti eniten ongelmia aiheuttava osa-alue, kun mietitään millaisiin raportteihin asiakastiedoilla tai nimiketiedoilla on vaikutusta. Puhumattakaan raporteista, joissa molemmat ovat vaikuttavia tekijöitä. Ja vielä kun mietitään, mitä esimerkiksi ryvettynyt nimikedata tarkoittaa raporttien luotettavuudelle, voi vain arvailla miten hyviä päätöksiä raporttien perusteella tehdään. Nimiketieto ei ole siis lainkaan hullumpi kohde aloittaa Master Data -käytäntöjen hyödyntäminen. Toki tuon ”aloittamisen” usein kuvitellaan olevan helppo ja kokonaisuutenakin kohtuullisen pieni juttu. Järjestelmän suhteen kyseessä ei ole järisyttävän valtava hanke, mutta toimintamallien muuttaminen keskitettyyn datan hallintaan on usein se, mikä vaikuttaa läpi organisaation enemmän tai vähemmän. Toki jos MDM-käytännöt otetaan käyttöön esimerkiksi ERP-hankkeen yhteydessä, on se tietysti osa massiivista kokonaisuutta. Tärkeää on luonnollisesti miettiä hyvin tarkkaan kunkin organisaation tavoiteltu prosessimalli, mahdollinen tiedon standardointi, välineet ja integraatiot, sekä tietysti tarvittava harmonisointityö olemassa olevan datan laadun saattamiseksi oikealle tasolle. Ja menestykseen tarvitaan vielä se sponsori.

Kura syntyy loppukäyttäjän ja päätten välilläAlkuperäiseen kysymykseen: Missä se paljon puhuttu kura syntyy ja kuka viime kädessä on vastuussa? Suurin osa kurasta syntyy suuren porukan näppäimistön ja selkänojan välissä. Vastuuseen siitä ei oikein tahdo saada ketään.

Kannattaisiko keskittää nimikedatan luomisen ja ylläpitämisen vastuu rajatulle porukalle, jolla on käytössä hyvät työkalut, yksinkertainen mutta kuvattu prosessi, ja se sponsori. Kuraa ei enää synnykään ja tarpeet massiivisille datan harmonisoinneille poistuvat tulevaisuudessa.

– Jani –

Mestarillista Datan Hallintaa

MDMää sarvista

Tämäkin artikkeli ratsastaa suositulla terminologialla.

Master Data Management on ollut trendikäs aihe jo useamman vuoden, joskin sen kovin hypehuippu taitaa olla jo takanapäin.  Hypetysvuodet ovat karsineet isoimmat kuonat ja trendillä ratsastajat pois kyydistä. Nykyään Master Data Management ymmärretään liiketoiminnan kehityshankkeeksi, eikä pelkäksi konsulttihypeksi. Hanke on sinällään harhaan johtava sana, sillä kyse on jatkuvasta toimintatavasta. Keskustelu on herättänyt yritykset kiinnittämään enemmän huomiota informaation laadukkuuteen jatkuvan teknologiapalvonnan sijasta.

Talentum Events järjestää aiheesta seminaarin nyt toista kertaa 18.- 19.9.2012. Tapahtuman esiteksti esittää hyvän kysymyksen:

” Missä se paljon puhuttu kura syntyy ja kuka siitä on viime kädessä vastuussa?”

Etenkin tuo vastuukysymys on mielenkiintoinen. Kuraa syntyy yleensä jo tiedon alkulähteellä, eli loppukäyttäjän päässä. Onko vastuu laadukkaasta tiedosta meillä kaikilla? Itse en valitettavasti pääse osallistumaan tuohon seminaariin, mutta meiltä on oma delegaatio tulossa paikalle. Vaikka emme laske itseämme varsinaiseksi master data -toimijaksi, on nimikedata – meidän leipälajimme – yksi merkittävä osa master dataa.

Puheista tekoihin

 MDM:n jalkauttamisesta käytäntöön löytyy nopeallakin googlauksella liuta erilaisia malleja ja toimintakehyksiä. Jotkin varmasti toimivampia kuin toiset. Omaan organisaatioon soveltuvaa mallia ei välttämättä suoraan löydy, mutta hyödyntämällä erilaisia toimintakehyksiä soveltuvilta osin päästään varmasti hyvään alkuun.

Tarve master datan hallinnalle on monessa yrityksessä jo tunnistettu ja tietoa, asiantuntijoita sekä ymmärrystä on enemmän kuin aikaisemmin, niin miksi kovin moni velloo silti nykytilassa? Onko kyse uskalluksen puutteesta vai johtamisongelmasta, viitaten Stephen Porterin kiteytykseen johtamisen merkityksestä PLM-artikkelissaan:

” Effective Management is putting first things first. While leadership decides what first things are, it is management that puts these first, day by day, moment by moment. Management is discipline, carrying it out.”

– Kalle –

Kuolema koodiavaimille!

Peter Benson, ECCMA:n puheenjohtaja, kirjoittaa juuri ilmestyneen uutiskirjeen pääkirjoituksessa jotain tähän suuntaan:

”Katalogien manuaalinen tuottaminen on tulossa nopeasti tiensä päähän. Katalogit korvautuvat ymmärryksellä, että tuotteiden toimittajat ovat vastuussa oikean ja riittävän informaation toimittamisesta asiakkailleen. Katalogisteista (en lähtenyt kääntämään) on tulossa data quality managereita, jotka auttavat käyttäjiä määrittelemään tarpeensa ja hoitavat prosessia, jolla tietoa pyydetään toimittajilta ja valmistajilta.”


Mystinen koodiavainOlen asiasta aivan samaa mieltä. Tyyppikoodiavaimet, joiden tulkinta on ollut tuotepäälliköiden, tarjousinsinöörien, komponentti-insinöörien ym. teknisten asiantuntijoiden vastuulla, ja joiden avulla on pystytty visualisoimaan erittäinkin laaja tuotetarjooma yhdellä A4-sivulla, on toimitusketjun automaation kannalta mahdoton malli. On ihan mielenkiintoista, että lähes kaikissa ERP-järjestelmissä on nykyään MYYNTI-konfiguraattori mutta prosessin vastinparia ei ole – eli siis mikään järjestelmä ei osaa OSTAA konfiguroitavia tuotteita. Ennen kuin tämä toiminnallisuus kehittyy ja standardoituu (mikä voi olla toimivaa 2020-luvulla) on pakko palata takaisin yksiselitteisiin nimikkeisiin.

Kuva on napattu Agilentin komponenttikatalogista

ATK:ta

Hankintatoimelle alkaa olla paljonkin tarjontaa ostoprosessin automatisointiin katalogien pohjalta, mutta se edellyttää, että yksi kataloginimike on yksiselitteinen ja sillä on hinta. Tämä palauttaa ongelman taas ytimeen – miten ostaja tai pidemmälle vietynä järjestelmä osaa tunnistaa oikean nimikkeen. IT-järjestelmät osaavat hoitaa jo sen, että kun toimittaja lähettää laskun, voidaan todentaa automaattisesti onko hinta sitä mitä on sovittu. Kun toimittaja lähettää tuotteen, vastaanottavassa päässä osataan tunnistaa erilaisilla tekniikoilla, että kyseessä on juuri tilattu tuote. Mutta onko tuote OIKEA? Se voidaan päätellä vain, mikäli siitä on osattu kysyä oikeat ja riittävät tiedot ja toimittaja on ne toimittanut.

Jotta nimikkeet perustettaisiin järjestelmiin oikein, on aika monessa yrityksissä siirrytty keskittämään nimikkeiden perustaminen erityiselle asiantuntijatiimille. Loppukäyttäjille annetaan lomake, jossa he kertovat mitä nimikettä tarvitaan ja workflow ohjaa pyynnön asiantuntijoille, jotka lähtevät selvittämään lisätietoa nimikkeestä. Koska toiminta globaaleissa yrityksissä on hektistä ja kaikki toimii IT-järjestelmien varassa, ovat nimiketiimit yleensä jatkuvassa back logien puristuksissa, nimikkeitä ei saada perustettua niin nopeasti kuin liiketoiminta odottaa.

Nimikehallintatiimi eturiviin

Minun mielestäni nämä kaikki esitetyt ongelmat voidaan poistaa kun katsotaan koko kokonaisuutta hieman eri lailla. Nimikehallintatiimi voisi pro-aktiivisesti luoda tarjoomaa niin ostoon (mikäli tavarantoimittajat eivät sitä tee jo valmiiksi) kuin myyntiinkin esivalmistelemalla nimikeinformaatiota ja tallentamalla niitä virtuaalisiin nimikevarastoihin. Toisin sanoen puretaan niitä toimittajien koodiavaimeen pohjautuvia katalogeja portfolioiksi ja kehitetään tiedonkeruulogiikkaa. Osto / ja myynti voisivat käydä nimikevarastosta tutkimassa mitä nimikkeitä olisi tarjolla helposti ja pyytää niitä operatiivisiin järjestelmiin tarvittaessa. Nimikehallintatiimin rooli nousisi huimasti pelkästä reaktiivisesta käsikassarasta tarjooman kehittäjäksi ja konsultiksi, ostotoiminta voidaan automatisoida, tarjoussuunnittelu nopeutuu, tehokkuus nousee ja kaikki voittavat.

Tässä taas kuukauden saarna.

Jukka

PS. insinöörit jäivät varmaan miettimään mikä tuo koodisarja oli – no se on ihan oikea pneumatiikkaventtiili (ASCO).

Seitsemän kuolemansyntiä

Hyllystä tarttui käteen vanha kirja ”Anti-patterns: Refactoring Software, Architectures, and Projects in Crisis”. Varsinkin ohjelmistokehityksen parissa työskentelevän kannattaa tähän perusteokseen tutustua, sieltä saattaa löytyä syitä kävellä tuijottamaan itseään vessan peilistä.

Kirjassa esitellään ongelmien perimäisiksi aiheuttajiksi seitsemän kuolemansyntiä. Voisiko näistä perisynneistä johtaa myös järjestelmähankkeiden ongelmien syitä?

7 sins

1. Kiire

Kiirehän on aina, deadline jyskyttää päälle koko ajan. Tietysti hyvin suunniteltu aikataulutus tuo projektille tarvittavaa ryhtiä. Synniksi kiire muuttuu siinä vaiheessa, kun tehtäville ei anneta niiden vaatimaa aikaa ja puristetaan hatusta vedettyyn aikatauluun taskit kohdalleen luottaen tekijöiden sankarillisiin yksilösuorituksiin. Tälläinen toimii kerran ja kaksi, ehkä kolmekin jos tekijää oikein kehutaan, mutta sitten se on siinä.

2. Välinpitämättömyys

Välinpitämättömyys voi ilmetä monellakin tavalla. Esiintuleva ongelma siirretään syrjään analysoimatta sen kriittisyyttä, koska se ei oikein tunnu osuvan kenenkään osapuolen vastuualueelle. Toimintatavoissa on ongelmakohtia, mutta muutosta ei saada aikaan , koska ’aina on tehty näin’.

3. Ahdaskatseisuus

Ahdaskatseisuus ja näköalattomuus johtuu pitkälti muutoksen pelosta. Järjestelmähankkeet, yllättäen, aiheuttavat usein muutoksia. Muutoksen pelko aiheuttaa usein tunnepohjaista vastustusta, pelkoon reagoidaan vihamielisesti. Jos jättää muutosvastarinnan huomioimatta, se potkaisee vähintään nilkkaan myöhemmin.

4. Laiskuus 

Laiskuudesta löytyy varmasti esimerkkejä. Jos projektipalaverissa joku sanoo, että ”en usko että sitä XXX tarvitsee tehdä”, ja tuo XXX asia on sinun vastuualueellasi, niin herätys! Jollain tavalla joudut tämän asian hoitamaan myöhemmin ja yleensä alkuperäistä suuremmin kustannuksin. Tässä kohdassa tuntuisi avainsanoja olevan QA, muutoksen hallinta ja lisensointikysymykset.

Usein törmää myös siihen, että jätetään ratkaisu puolitiehen. Ajatellaan, että tehdään ensi vaiheessa vain välttämätön ja loput joskus myöhemmin. Sitä myöhemmin ei koskaan tule. Samalla on kuitenkin tiedostettava, että tie helvettiin on päällystetty hyvillä aikomuksilla, kuten täydellisyyden tavoittelulla (ks 5. Ahneus).

5. Ahneus

Ahneudessa mikään ei tunnu riittävän. Ahne haluaa vain lisää, vaikka sitä ei muillakaan olisi, eikä missään nimessä luovu omastaan toisen tai yhteiseksi hyväksi.  Järjestelmähankkeiden kohdalla ahneus esiintyy keskittyminä. Toimintoja ja prosesseja keskittyy kokonaisarkkitehtuurissa järjestelmäkartassa yhteen paikkaan. Ydinprosessien ja -toimintojen kohdalla tämä saattaa olla mielekästä ja tietoinen valinta, mutta seuraukset on syytä tiedostaa.

6. Tietämättömyys

Tietämättömyys tuntuu tulevan vastaan päivittäin. Nykymaailman informaatiotulvassa ja muutosten määrässä on oma haasteensa pitää osaaminen ajan tasalla. Kerran hyväksi koettu ratkaisu saattaa olla vanhentunut ja parempaa olla jo tarjolla. Toisaalta uusin teknologia ja innovaatio ei välttämättä ole aina alkumetreillään ihan paras ratkaisu. Oman ajantasaisen ratkaisupakin hallinta on tänä päivänä onnistumisen edellytys.

7  Ylpeys

Tästä löytyy varmasti esimerkkijä ja sudenkuoppia. Kuvitellaan perusteettomasti, että kyllä osaamista löytyy, uskotaan sokeasti omiin kykyihin, kuvitellaan datan laadun ja tietomallien olevan täydellisiä ja aukottomia. On eri asia luulla tietävänsä kuin tietää tietävänsä.

Teologiassa yhtenä synnin tunnusmerkkinä pidetään tietoisuutta väärin tekemisestä. Tässä yhteydessä tiedon puute on kuitenkin nähtävä yhtenä syntinä. Toisaalta tiedon haalimisen riivaamana ajautuu helposti ahneuden syntiin, johtaa kiireen kautta välinpitämättömyyteen ja ahdaskatseisuuteen. Samoin käy jos osaamisen kehittäminen laiminlyödään kiireen välttämiseksi ja laiskuuden vuoksi – päädytään helposti ahdaskatseisuuden ja ylpeyden synteihin, joissa oma osaaminen ja toiminta nähdään ainoana olemassa olevana  ratkaisuna ja palvotaan sitä kultaisena vasarana ja kaikki ongelmat ovat nauloja.

Näiden seitsemän kuolemansynnin välttäminen näyttäisi tarkoittavan yleisesti kohtuullisuutta ja kokonaisuuden huomioimista. Osa-optimointi ja yhteen asiaan keskittyminen johtaa syntiin ja kadotukseen, näin mahtipontisesti sanottuna. Jos esimerkiksi Six-Sigma yleensä pyrkii estämään osa-optimointia, niin missähän on tapahtunut virhe, jos kuudella koitetaan korjata seitsemää. Puuttuuko Six-Sigmasta jotain vai onko seitsemässä kuolemansynnissä jotain liikaa. Palataan tähän numerologiaan tuonnempana

– Software Samurai –