IT ja kuluttajansuoja

Toiminnanohjaustyökalut ovat nykyään arkipäivää elintarvikealan yrityksissä. Hankitun IT-ratkaisun tehtävänä tyypillisesti – ja odotusarvona – on automatisoida perusrutiineja, liiketoimintatiedon keräämistä ja raportointia sekä tehdä toiminnasta reaaliaikaisempaa. Sparta auttaa asiakkaitaan välttämään pahimmat sudenkuopat toiminnanohjausjärjestelmän hankintaprosessissa. Tämä juttu ja tosielämän projektiesimerkki on luettavissa myös Kehittyvä Elintarvike-lehden numerosta 1/2015.

Mihin huomio kiinnittyy hankintaprosessissa?

Elintarvikevalmistajan perusjärjestelmiin kuuluvat tyypillisesti keskenään yhteen liitetyt tai paketoidut liiketoiminnan (ERP), tuotannonohjauksen (MES) ja tuotantoautomaation/tiedonkeruun järjestelmät. Kun ERP- ja MES-tehdasjärjestelmän hankinta tai uusintatarve tulee vastaan, etsitään soveltuva ja luotettava kumppani ongelman ratkaisemiseksi. Kokeneita ja elintarvikealan prosesseja ymmärtäviä valmisohjelmistojen toimittajia ei ole Suomessa montaa. Paljon yksinkertaisempaa on etsiä toiminnanohjausratkaisu kappaletavarateollisuuteen tai sisälogistiikkaan.

Jos asiakas toimii pk-sektorilla, päähuomio kiinnittyy myyntivaiheessa usein tarjottuun kokonaishintaan, referensseihin ja toimituslaajuuden sisältöön sekä myyntimiesten antamaan vaikutelmaan. Asiakkaan käsitys toimittajan käyttöönottoprojektien osaamisesta, menetelmistä ja sopimusten selkeydestä on myös tärkeä, arvioitava asia.

Kaikkein tärkein ja vaikein asia toimitussopimuksen allekirjoitusvaiheessa on tunnistaa asiat, jotka eivät kuulu toimituslaajuuteen. Niitä ei mainita missään tuotedemonstraatiossa, sopimustekstissä tai hintaerittelyssä. Mitä ei ole kirjallisesti sovittu ja ymmärretty puolin toisin, ei toimiteta ilman lisähintaa, ellei toimittajan maine ole vaakalaudalla. Ostajalla ei ole kuluttajansuojaa, jos näitä asioita ei osata huomioida.

Tarpeet ja vaatimukset elävät käyttöönottoprojektissa

Projektiammattilaisten keskuudessa tunnustettu tosiasia on mahdottomuus laatia tarkka käyttöönottoprojektin etukäteissuunnitelma. Asiakas ei tiedä, mitä ostaa, mutta usein myyjäkään ei tiedä, mitä tuli myytyä. Kun sopimisvaiheesta on päästy käyttöönottoprojektin toteutukseen, asiakkaalle tulee ahaa-elämyksiä järjestelmätyökalun tarjoamista uusista toiminnan kehitysmahdollisuuksista. Jos hyppy vanhasta ratkaisusta uuteen on suuri, kiusaus kehittää omaa toimintaa laajentamalla järjestelmän käyttöä on iso.

Kun asiakas saa ahaa-elämyksen, on tarve ratkaista jonkin ongelma tai helpottaa jokapäiväistä työntekoa. Tarve tulee muuttaa toimittajan ymmärtämälle kielelle – eli jalostetuksi vaatimukseksi – , jotta toimittajan asiantuntijat voivat sen toteuttaa. Vasta tämän jälkeen molemmilla osapuolilla on parhaassa tapauksessa yhteinen käsitys siitä, mitä tehdään ja mitä hyötyä sillä tavoitellaan.

Projekti on kriisissä viimeistään silloin, kun budjetti karkaa käsistä. Tällöin osapuolet eivät ole miettineet tuettavia perustoimintamalleja eikä projektissa ole mukana henkilöä, joka on konkreettisesti nähnyt, miten uusi järjestelmäratkaisu vastaa asiakkaan tarpeeseen. Uutta järjestelmää ei kannata ottaa aina käyttöön heti, vaikka se olisi saatavilla. Kehittämisen varaa on järkevää jättää myös tuleville vuosille, kun oma osaaminen uudesta järjestelmätyökalusta on saavuttanut riittävän tason.

Ongelmien selvittäminen jälkikäteen työlästä. Solmujen selvittäminen jälkikäteen on huomattavan työlästä verrattuna projektin aikaiseen muutoshallintatyöhön. Kun vuorovaikutus ja projektin etenemisen raportointi on läpinäkyvää, nousevat ongelmat ja muutosasiat ajoissa esille. Näin toimimalla asiakkaalla on edes teoreettinen mahdollisuus reagoida muutostarpeisiin ja lisäkustannuksiin.

Riittävällä yhteistyöllä alkaa muodostua yhteinen kieli asiakkaan ja toimittajan välille, sillä ”IT-kieli” on erilaista kuin liiketoiminnan kieli. Pk-yrityksen käyttöönottoprojektin kriisiytyessä sopimisen motiivi voi olla asiakkaalle hengissä pysyminen. Toimittajalle asia voi olla taloudellisesti yhdentekevä hanke, valitettava epäonnistuminen muiden joukossa ja pienehkö kolhu maineeseen. Jos asia menee lakimiesten selvitettäväksi, ainoita voittajia ovat lakimiehet.

Mikä projektissa maksaa?

Toiminnanohjauksen ostaminen valmisohjelmiston pakettiratkaisuna vaatii sekä kokemusta että ammattitaitoa. Toimitussopimusta tai pahimmassa tapauksessa toimitussopimuksia allekirjoitettaessa kannattaa muistaa, että valmisohjelmisto sovitetaan aina asiakkaan tarpeisiin ja ruokahalu tuppaa kasvamaan oppimisen ja projektin edetessä.

Toimittaja huomaa asiakkaan oppimisen uusina tarpeina ja valitettavan tyypillisesti lisäliiketoimintamahdollisuutena eli lisäkustannuksina. Toimittaja tulkitsee asiakkaan uudet tarpeet ja vaatimukset sopimuksen allekirjoitushetkellä dokumentoidun toimituslaajuuden ulkopuolisina asioina. Hintalappu toimitussopimuksessa ei ole toimitusprojektin hintalappu.

Tosielämän projektiesimerkki – odotusten ja tulosten välillä iso ero

Projektiesimerkissä asiakas oli päättänyt hankkia kokonaisvaltaisen toiminnanohjausratkaisun, joka kattaa myös tuotannon tiedonkeruun omavalvontavelvoitteiden täyttämiseksi. Sopivia ratkaisutoimittajia etsittiin omin voimin ja neuvotteluja käytiin eri tarjoajien kanssa. Tarpeita esitettiin myyntivaiheen neuvotteluissa, ja toimittaja selvitti asiakkaan tahtotilaa toimintamallin suhteen.

Toimitussopimuksia allekirjoitettaessa toimittaja esitti sopimusliitteissä toiminnanohjauksen toimituslaajuuden kuvauksen järjestelmämoduulien hintaerittelyn arviona, koska toimitettava valmisratkaisu oli modulaarinen. Lisäksi tehtiin erillinen toimitussopimus tuotannon ohjaamiseen, mistä esitettiin samantyyppinen toimituslaajuuden kuvaus arviohintoineen.

Koko toimituskokonaisuuden kattavaa projektisuunnitelmaa ei koskaan tehty, vaan suunnitelmat jäivät osittain alustaviksi yleiskuvauksiksi. Myös sopimuskokonaisuus oli erittäin vaativa hahmottaa, eikä reklamointipykäliin kiinnitetty juurikaan huomiota. Asiakas luotti tässä vaiheessa toimittajan kokemukseen ja referensseihin elintarviketoimialalta: Asiakas sai mielikuvan, että toimituskokonaisuus vastaa todellisia tarpeita. Myös arvioidun kokonaisbudjetin suuruusluokan pitävyydessä luotettiin myynnin lupauksiin. Projektin alussa keskinäinen vuorovaikutustyö, etenemän ja poikkeamien viestittäminen, toimi ohjausryhmässä suhteellisen hyvin. Projektin edetessä ohjausryhmätyöskentely jäi hoitamatta kunnolla. Pimentoon jäi se, mitä tulosta kohti oltiin menossa ja mitä poikkeamia sopimushetken toimituskokonaisuuteen oli tulossa. Asian todellinen tila paljastui asiakkaalle vasta lähellä käyttöönottohetkeä, kun sopimuksissa arvioitu budjetti lähti ylittymään ja myöhemmin lähes kaksinkertaistui. Käyttöönotto tapahtui ilman muodollista ja dokumentoitua asiakkaan toimitushyväksyntää, kun keskeneräinen ratkaisu otettiin tuotantokäyttöön kiireellä.

Projektin edetessä molemmat osapuolet tekivät virheitä. Pahin oli ehkä muutoshallinnan systemaattinen puuttuminen ohjausryhmätyöskentelystä. Ohjausvastuu tästä oli toimittajan projektiammattilaisilla, sillä asiakkaalla ei ollut käytössään ammattilaista johtamaan projektia tai oikeammin projekteja. Asiakkaalla ei ollut tällaista kokemusta ja ammattilaista käytössään, vaan hän luotti toimittajan osaamiseen. Samalla projektin ohjausvalta oli toimittajalle. Asiakkaalla ei ollut näkyvyyttä toimituskokonaisuuteen työn aikana, mistä seurasi merkittävä ero odotusten ja tulosten välillä.