Aiheuttavatko hankinnat painajaisia?

Jari Kauppi

Senior Consultant


Toisinaan saamme lukea uutisia pieleen menneistä hankintaprojekteista. Hommat ovat menneet monilta osin vastoin tavoitteita ja lopputuloksena on iso aukko firman kassassa ja taistelevat juristit. Tällä kerralla keskitymme analysoimaan tyypillisiä taustatekijöitä, joiden jäljiltä jää savuavia raunioita.

Vanha sanonta “hyvin suunniteltu on puoliksi tehty” pitää paikkansa erityisesti hankinnoissa. Miksi? Siksi, että alusta lähtien hyvin suunnitellun hankinnan läpivienti on käytännössä suunnitelman johtamista alusta loppuun. Kuulostaa helpolta. Sitähän se oikeastaan onkin, kyse onkin vain siitä, miten homma laitetaan liikkeelle. Väärin rakennettuja perustuksia on vaikea korjata kun rakennusporukka viimeistelee jo kattoa.

Pohditaan seuraavaksi, miksi hankinnat menevät pieleen. Seuraavaksi yleisimpiä syitä ja varmaan monille tuttuja juttuja. Vain pintaraapaisu, mutta käsitelkää kuitenkin varoen etteivät tartu!

Kiire

Ehdottomasti yleisin syy minkä tahansa asian tekemisen huonoon lopputulokseen. Hankintojen yhteydessä kiirettä käytetään surutta perusteluna ja syynä mm. seuraavasti:

  • Hyvä syy olla käyttämättä yrityksen voimavaroja, esim. hankintayksikköä apuna hankinnassa, hankinta kuitenkin hidastaa vauhtia. Yksin olen nopeampi.
  • Erittäin hyvä syy olla tekemättä markkinakartoituksia tai muuta tarjooman selvitystä, kaikki relevantit tarjoajat ovat kuitenkin 100% varmuudella tiedossamme. Markkinahan ei koskaan muutu tai kehity.
  • Hyvä syy olla kilpailuttamatta hankintoja. Kilpailutus on hidaste ja turha vaihe ketterän ja tehokkaan tekemisen pikatiellä.
  • Tosi kiireessä kannattaa myös ohittaa tarpeettomat sopimusneuvottelut ja ryhtyä suoraan vaan toimeen. Sopimuksia voidaan kirjoitella siinä sivussa sitten. Sopimus ja todellinen tekeminenhän ovat aina kaksi eri asiaa, vai mitä?
  • Kiireen nojalla tarvemäärittelyt ja muu vastaava voidaan jättää väliin. Kyllähän me nyt hitto soikoon tiedetään mitä me halutaan! Siinä ei mitään määrittelyitä tarvita.
  • Lopputulosten validointia ja testaamista kannattaa kiiruhtaa, ajan säästämiseksi. Ne voi tarvittaessa jättää tekemättäkin kun itse itselle annetut aikataulut painaa. Tuotanto on paras testaaja.

Tämä setti on tehokkain tapa saada mikä tahansa hankinta karahtamaan tyylikkäästi kiville. Kiireen saa menemään läpi parhaiten lupaamalla yrityksen johdolle mahdollisimman epärealistisen aikataulun. Tämän jälkeen kiire toimii johtajana joka asiassa.

Epäselvät vastuut

Jos joudutaan jonkinlaiseen organisoituun hankintamenettelyyn, on asiat siitäkin huolimatta syytä pitää mahdollisimman dynaamisena ja ketteränä. Kutsutaan kokoon palaveri tai parikin, henkilöitä vähän sieltä ja täältä. Jos joku kyselee jälkikäteen asian perään, voidaan näyttää että porukkaa on kyllä palavereissa ollut (ja löytyy ainakin sopivia ehdokkaita syyllisiksi). Henkilöiden vastuiden määrittelemistä on kuitenkin syytä välttää viimeiseen saakka. Tilanteen mukaan osallistujat voivat käyttää lausetta “Olin mä jossain palaverissa.” Tässä yhteydessä voi myös vedota ”Joku”-nimiseen työkaveriin, löytyy jokaisesta firmasta. Näin kukaan ei ole oikeasti mistään vastuussa.

Minimaalinen tarvemäärittely ja kommunikointi

Todellinen ”Pro” tekee hankintaa ilman tarve- ja vaatimusmäärittelyitä eikä puhu tekemisistään muille. Argumenttina toimii helposti “Kyllähän me tiedämme mitä haluamme! Sitä paitsi, kyllä tarjoajien tulee aavistaa, mitä mahdollisesti haluamme. Jos eivät aavista, ovat vääriä tarjoajia meille, suorastaan huonoja”.

Mahdollisimman epämääräiseksi jätetty tarpeen määrittely mahdollistaa myös sen, että voimme kesken prosessin sanoa ajatelleemme jotain ihan muuta. Kätevää, kukaan ei voi vedota mihinkään kirjallisiin määrittelyihin ja ostava Asiakashan on aina oikeassa. Muutenkin liian avoin tarjoajien kanssa kommunikointi rapauttaa arvovaltaamme, miksi muutenkaan kertoisimme kenellekään suunnitelmistamme. Verkostoituminen ja tiedonvaihto on vaarallista, tietoturvaan on hyvä aina vedota.

Kaikki edellä mainitut toimivat myös yhdessä. Esimerkiksi kiirettä voi käyttää myös perusteluna huolellisen tarvemäärittelyn tai hankintacasen organisoinnin tekemättä jättämiseen.

Mikä sitten avuksi?

Hankinnoissa onnistumiseen on myös välineitä. Nekin ovat yksinkertaisia. Yksi tärkeimmistä on organisaation sisäinen yhteistyö ja avoin kommunikaatio. Kommunikaation on suositeltavaa olla avointa myös yhteistyökumppanien suuntaan. Ei nimittäin ole oletettavaa, että kumppanit tuntevat liiketoimintasi perimmäiset syyt jonkin hankinnan tekemiselle. Hankinnoilla kun on suora yhteys bisnekseen.

Yhteistyön tulee käynnistyä jo toiminnan suunnittelusta. Sehän on käytännössä ensimmäinen hetki, kun hankintatarpeita alkaa nousta esiin. Prosessi voi kulkea karkeasti ottaen seuraavasti:

  1. Strategiatyö ja toiminnan suunnittelu liiketoiminnoissa
  2. Karkean tason hankintasuunnitelmat, priorisointi ja mahdolliset hankintastrategiat
  3. Organisointi ja vastuuttaminen (hankinta-, kategoriatiimit tai vastaavat)
  4. Hankintasuunnitelmien ja -strategioiden tarkentaminen
  5. Hankintojen tavoitteellinen läpivienti ja johtaminen

Edellä mainittu ei siis ole “Hankinta”-nimisen tukiyksikön yksintyöskentelynä tapahtuvaa räpiköintiä vaan koko yrityksen läpileikkaavaa suunnitelmallista tekemistä. Vieläpä niin, että kyseessä on jatkuva prosessi.

Jotkut puhuvat kategoriatyöskentelystä ja kategoriastrategioista, toisaalla termit voivat olla jotain muuta. Yhtä kaikki, jokaisessa tausta ja tavoite on sama: Johdettu tavoitteellinen yhteistyö läpi organisaation.

Joku voi todeta että “Ei noilla kuuhun mennä!” Väitän, että kuuhun mentiin nimen omaan tavoitteellisella ja määrätietoisella johtamisella. Suosittelen siis kaikille kuun tavoittelemista taivaalta!

Tutustu SC Sourcing Suiteen

Tarina kehittäjästä, josta tuli yhdessä yössä kertaluokkaa tuottavampi

Jarno Leikas

CTO


Kun minua pyydettiin SoulCorelle (nyk. SC Software) pääarkkitehdiksi lokakuussa 2014, en meinannut pysyä tuolillani. Tiimi oli vanhastaan tuttu, ja olin ollut kiinnostunut sovellustuotannon automatisoinnista jo opiskeluajoistani lähtien. Olinkin siihen mennessä harmitellut, että automatisoitu sovellustuotanto oli aina ollut eräänlainen ”ikuinen lupaus”, joka ei koskaan oikein ollut realisoitunut. Nyt sain mahdollisuuden selvittää mihin asti ajatus lentää.

Ja lentäähän se. Pitkälle.

Mitä automatisoidulla sovellustuotannolla sitten tarkoitetaan?

Lyhyesti, automatisoimme sovelluskoodin tuotantoa, tavoitteenamme nostaa sovelluskehityksen tuottavuutta nykyisin käytössä olevia keinoja paremmalla tavalla.

Heti alkuun on tärkeää ymmärtää, että korkean tuottavuuden sovelluskehityksen lopputuloksena on aivan tavallinen järjestelmä. Siis sellainen, jonka olisi voinut koodata käsinkin (ei tosin läheskään samassa ajassa). Olennaisena erona on se, että meillä kerrosarkkitehtuurin eri kerrosten lähdekoodi syntyy automaattisesti sovellusmallin perusteella. Tästä saatava tehokkuuden lisäys on niin suuri, että sen kerrannaisvaikutukset koko projektin elinkaareen ovat jopa laadullisia, eivät pelkästään määrällisiä.

Korkean tuottavuuden kehityksessä ei siis ole ”mustana laatikkona” toimivaa monimutkaista ajoalustaa, tai toimialakohtaista valmislogiikkaa, jota pyritään parhaan mukaan taivuttamaan asiakastarpeisiin (eikä muuten näihin liittyviä lisenssimaksujakaan). Kuten tavanomaisessa web-pohjaisessa tietokantasovelluksessa, automaation avulla tuotettu sovellus tarvitsee ajoalustaksi tavanomaisen sovelluspalvelimen ja tietokantapalvelimen. Käyttäjät tarvitsevat päätteekseen esimerkiksi tabletin tai työpöytäselaimen. Mielestäni tämä on aika yksinkertainen juttu.

Myöskään generoidun sovelluksen integrointitarinassa ei ole magiaa: koska ratkaisu vastaa rakenteeltaan tavanomaista monikerrosarkkitehtuuria noudattavaa sovellusta, voidaan sitä vasten toteuttaa juuri ne integraatiot mitä tarvitaan – niillä tekniikoilla joita tarvitaan.

Miten korkean tuottavuuden sovelluskehitys eroaa muista menetelmistä?

Olen urani aikana toiminut sovelluskehityksessä useissa eri rooleissa ja monenlaisissa ympäristöissä: perinteisessä tuotekehityksessä, täysin räätälöidyissä projekteissa, sekä toteuttamassa ns. ”low-code” –ratkaisuja kolmannen osapuolen tuotteilla. Kaikille edellisille on olemassa paikkansa, mutta omat kokemukseni niistä eivät ole olleet täysin positiivisia:

  • Toimialakohtainen, perinteinen tuotekehitys ei läheskään aina lunasta sille asetettuja lupauksia, koska tuotteet ovat usein liian jäykkiä, tai niiden räätälöinti on kallista
  • Räätälöidyissä projekteissa, huolimatta ketteristä menetelmistä ja moderneista kehitystyökaluista, on edelleen liikaa käsityötä. Puhumattakaan perinteisten vesiputousprojektien ongelmista.
  • Kustannusongelmia on ratkottu ulkoistamalla työtä matalan kustannuksen maihin, mutta kokemukset kustannuksista ja lopputuloksesta eivät usein vastaa asiakkaan tavoitteita
  • Low-code –tyyppiset työkalut, joiden tavoitteena on ”helppo” sovelluskehitys, ovat yleensä ei-triviaaleissa toteutuksissa liian rajoittuneita ja/tai epäkäytännöllisiä. Usein todetaan, että homma olisikin ollut tehokkaampaa koodata käsin.

Korkean tuottavuuden kehittämisen parissa työskenneltyäni olen löytänyt mm. seuraavia etuja:

  • Mallinnusmenetelmässämme ei ole toimialakohtaisia toimintoja, joita on pakko yrittää taivuttaa puoliväkisin eri käyttötarkoituksiin sopivaksi
  • Korkean tuottavuuden kehitysalusta mahdollistaa sen, että ihmistyötä käytetään vain lisäarvon tuottamiseen, ei matalan jalostusasteen koodin tuottamiseen (me ulkoistamme tätä työtä siis tietokoneelle, emme meren taa)
  • Lisäarvoa asiakkaillemme koodaamme standardeilla ohjelmistokehitysvälineillä, joissa ei ole tyypillisiä low code –ratkaisuiden rajoitteita.

Malli on paitsi asiakkaillemme, myös meille hyvin innostava. On hieno tunne saada aikaan asiakkaalle näytettäviä ratkaisuja nopeasti, ja saada myös välitöntä palautetta toteutuksesta, koska voimme esitellä ratkaisua paljon entistä nopeammin. Minun onkin helppo yhtyä uusimman kehittäjämme spontaaniin kommenttiin: ”paluu vanhaan tapaan tuntuu aika vieraalta”.

Pilvi on kehittäjän ja käyttäjän paras ystävä

Olemme iloksemme huomanneet, että asiakkaamme ovat ottaneet käyttöön Microsoft Azure –pilvipalveluita, ja itsekin hyödynnämme niiden vaivattomuutta ja kustannustehokkuutta jatkuvasti. Omia suosikkejamme ovat SaaS-palveluiden, kuten Office 365, lisäksi Microsoft Azuren PaaS-palvelut, jotka ovat yksinkertaisia ja nopeita ottaa käyttöön. Samalla ne ovat tarvittaessa skaalautuvia ja varmistettuja.

Vaikka itse työskentelemmekin päät ja jalat pilvissä, ratkaisumme toimivat yhtä lailla paikalisillakin palvelimilla. Esimerkiksi Microsoft-pohjaisessa toteutuksessa paikallinen IIS-palvelin ja Microsoft SQL Server –palvelin ovat ihan yhtä tuettuja, kuin Azure Web Application ja Azure SQL.

Miksi kaikki eivät tee näin?

Totta puhuen, en oikein ymmärrä miksi; nimittäin meillä kuulee usein lauseen ”eikös tänkin voisi generoida” – ja hyvin usein vastaus on myönteinen. On toki selvää, että räätälintyölle ja valmistuotteille on paikkansa – kaikkea kun ei kannata automatisoida. Toisinaan on tehokkainta koodata, mutta mielestämme olennaista on, ettei koodaajan tarvitsee toteuttaa sellaista koodia, jonka voi jättää koneelle. Järki siis mukana kaikessa.

Kaiken kaikkiaan, kokemusteni perusteella alamme tulevaisuus on korkean tuottavuuden ohjelmistotuotannossa. Onneksi se on meillä jo nyt arkipäivää.