Miksi hankintapyynnöstä tulee pullonkaula
Tuotantoyrityksessä hankinta alkaa harvoin yhdestä huolellisesti täytetystä asiakirjasta. Tarve syntyy työnjohtajalla, teknologilla, insinöörillä, käyttöosastolla tai suunnittelijalla. Joku lähettää sähköpostin, joku kirjoittaa yrityksen keskusteluun ja joku välittää tiedot henkilökohtaisesti esimiehelle. Tämän seurauksena sama tehtävä voi ilmestyä useissa kanavissa, ja osa pyynnöistä jää kokonaan kirjaamatta.
Ensi silmäyksellä ongelma näyttää tavalliselta hyväksynnän viivästymiseltä. Käytännössä se vaikuttaa kuitenkin koko toimitussykliin. Kun pyyntö on tarkistettavana, hankkija ei voi pyytää hintoja asianmukaisesti, toimittaja ei saa tilausta, varasto ei tiedä, milloin materiaalia odotetaan, ja tuotanto joutuu muuttamaan aikatauluaan. Mitä kriittisempi nimike on, sitä korkeampi epäselvyyden hinta.
Hakemusten hallinta on erityisen vaikeaa, kun yrityksessä on useita toimipaikkoja, yksiköitä ja vastuutasoja. Yhdelle luokalle riittää esimiehen hyväksyntä, kun taas toinen edellyttää budjetin tarkistamista, teknistä lausuntoa, turvallisuuspalvelun vahvistusta tai usean hyväksyjän päätöstä. Jos sääntöjä ei ole määritelty prosessissa, jokainen osallistuja toimii oman logiikkansa mukaan.
Mikä yleensä hidastaa tarpeen etenemistä
- ei ole yhtenäistä lomaketta, jossa olisi pakolliset tiedot nimikkeestä, määrästä, määräajasta ja käyttötarkoituksesta;
- ei ole selvää, kuka vastaa seuraavasta vaiheesta ja missä pyyntö tällä hetkellä on;
- hyväksyjät saavat ilmoituksia eri kanavissa eivätkä näe asiayhteyttä;
- pyyntöön tehdyt muutokset eivät sisällä selkeää historiaa;
- kiireelliset tarpeet sekoittuvat suunniteltuihin;
- johtajat saavat tiedon toimituksen epäonnistumisriskistä vasta ongelman ilmenemisen jälkeen.
Tällaisessa ympäristössä työntekijät korvaavat usein puuttuvan läpinäkyvyyden manuaalisella valvonnalla: he soittavat kollegoille, välittävät sähköposteja, ylläpitävät paikallisia taulukoita ja muistuttavat tehtävistä keskusteluissa. Tämä luo vaikutelman aktiivisuudesta, mutta ei muodosta toistettavaa prosessia. Työntekijän lähtiessä, esimiehen vaihtuessa tai hankintamäärien kasvaessa järjestelmä menettää nopeasti vakautensa.
Mitä seurauksia tuotannolle syntyy
Viivästynyt hyväksyntä ei aina johda linjan pysähtymiseen heti. Paljon useammin ensin ilmenee vähemmän näkyviä oireita: kiireellisiä tilauksia suunniteltujen sijaan, osatoimituksia, toistuvia kyselyitä toimittajille, ostamista epäedullisemmilla ehdoilla ja keskeneräisten pyyntöjen kertymistä. Nämä menetykset voivat jakautua useiden yksiköiden kesken ja jäädä siksi pitkäksi aikaa ilman yhtä vastuuhenkilöä.
Tuotannonsuunnittelu perustuu materiaalien, varaosien, työkalujen ja palveluiden saatavuuteen. Jos hankintaa koskevat tiedot eivät ole ajan tasalla, suunnittelija joutuu käyttämään oletuksia. Joitakin nimikkeitä tilataan liian myöhään, toisia taas liian suurella varastolla. Molemmissa tapauksissa yritys menettää käyttöpääomansa hallinnan.
Vaikutus näkyy myös organisaatiossa. Hyväksyjät alkavat pitää pyyntöjä satunnaisten pyyntöjen virtana ja hankintapalveluista tulee lähettämö, joka etsii puuttuvia tietoja manuaalisesti. Samalla kiista siitä, kuka viivästytti prosessia, korvaa analyysin siitä, missä kohtaa prosessi on rakennettu huonosti.
Miten prosessi muuttuu OpenBoxissa
OpenBoxin ”Pyyntöjen hallinta” -ratkaisu auttaa siirtämään hankintatarpeen käsittelyn hajanaisista kanavista yhteen työtilaan. Pyyntö luodaan selkeän lomakkeen avulla, se kulkee määritettyjen vaiheiden läpi, ohjataan vastuuhenkilöille ja kaikki toimet tallentuvat historiaan. Automatisointi itsessään ei ole tärkeintä, vaan mahdollisuus kuvata etukäteen säännöt, joiden mukaan yritys haluaa toimia.
Sen sijaan, että kysytään ”kenellä sähköposti on nyt?”, saatavilla on konkreettiset tiedot: kuka pyynnön loi, mihin yksikköön se liittyy, mitä tarvitaan, mihin mennessä, mikä vaihe on suoritettu, kenen on tehtävä seuraava vaihe ja mitä kommentteja on jo jätetty. Tämä vähentää tarkennusten määrää ja auttaa erottamaan nopeasti täydelliset pyynnöt niistä, joista lähtötiedot puuttuvat.
Tarpeen yhtenäinen rekisteröinti
Ensimmäisessä vaiheessa yritys määrittää kenttien sisällön. Pyyntöön kirjataan yleensä aloitteentekijä, yksikkö, kustannuslaji tai -suunta, nimikkeet, määrä, toivottu toimitusaika, toimituspaikka, perustelut ja lisäasiakirjat. Kokoonpano riippuu tuotannon erityispiirteistä: teknistä nimikettä varten voidaan tarvita teknisiä tietoja, piirustus tai yhteensopivuusvaatimus, palvelua varten taas työselostus ja odotettu tulos.
Pakolliset kentät estävät lähettämästä pyyntöä, jonka perustiedot hankkijan pitäisi selvittää uudelleen. Lomaketta ei kuitenkaan pidä kuormittaa liikaa. Jos käyttäjä näkee kymmeniä hänen tehtäväänsä liittymättömiä kenttiä, hän alkaa etsiä kiertoteitä. Siksi tiedot kannattaa jakaa yleisiin ja ehdollisiin: lisäkentät näytetään vain tietyille luokille tai hankintatyypeille.
Selkeisiin sääntöihin perustuva reititys
Rekisteröinnin jälkeen pyyntö voidaan ohjata reitille yksikön, luokan, summan, kiireellisyyden tai valitun kustannuslajin perusteella. Esimerkiksi tekniset materiaalit käyvät profiiliasiantuntijan tarkistuksessa, kun taas taloudellisia rajoituksia sisältävät pyynnöt edellyttävät budjetin lisähyväksyntää. Vakiomuotoisten hankintojen reitti voi olla lyhyempi ja poikkeavien sisältää asiantuntijatarkistuksen.
Reittiä ei pidä määrittää kerran ja jättää sen jälkeen tarkistamatta. Tuotannossa yksiköiden rakenne muuttuu, uusia luokkia syntyy ja valtuuksia jaetaan uudelleen. Siksi käyttöönotossa on tärkeää sopia paitsi vaiheiden järjestyksestä myös prosessin omistajasta, joka vastaa sen ajantasaisuudesta.
Määräaikojen ja tilojen valvonta
Jokainen pyyntö saa selkeän tilan, esimerkiksi ”luotu”, ”tarkistettavana”, ”hyväksyttävänä”, ”siirretty hankintaan”, ”odottaa tarkennusta”, ”toteutettu” tai ”hylätty”. Nimikkeiden tulee kuvata todellisia toimia, ei sisäisiä ilmauksia, jotka ovat ymmärrettäviä vain yhdelle osastolle.
Työntekijät näkevät nykyisen vaiheen ilman, että heidän tarvitsee lähettää kyselyitä hankintapalveluille. Vastuuhenkilöt saavat ilmoituksia uusista tehtävistä ja muutoksista. Johtaja voi kiinnittää huomiota pyyntöihin, jotka ovat olleet pitkään samassa vaiheessa, ja hankkija keskittyä pyyntöihin, jotka ovat valmiita jatkokäsittelyyn. Tämä lähestymistapa ei poista päätösten tekemisen tarvetta, mutta vähentää turhaa odottamista ja manuaalista etsintää.
Käyttöönoton skenaario tuotantoyritykselle
Käytännössä on parempi aloittaa yhdestä hallittavasta skenaariosta kuin yrittää automatisoida kaikki hankintatyypit kerralla. Voidaan esimerkiksi valita tuotantomateriaalien, varaosien tai korjauspalveluiden hankintapyynnöt. Tällä alueella osallistujat on helpompi määrittää, todellisia esimerkkejä kerätä ja päätöksentekoon tarvittavat tiedot tarkistaa.
- Nykyprosessin analysointi. Tiimi kirjaa, miten tarve syntyy tänään, missä se rekisteröidään, kuka tarkistaa tiedot, mitkä hyväksynnät ovat pakollisia ja missä vaiheissa palautuksia syntyy useimmin.
- Roolien määrittäminen. Määritetään aloitteentekijä, yksikön johtaja, tekninen asiantuntija, taloudellinen hyväksyjä, hankinta-asiantuntija ja muut osallistujat. Kullekin roolille kuvataan yleisen tehtävänimikkeen sijaan pyyntöön liittyvä konkreettinen toimenpide.
- Lomakkeen suunnittelu. Kentät ryhmitellään sisällön mukaan, ja niihin lisätään ohjeita sekä pakollisuussääntöjä. Erillinen päätös tehdään siitä, mitkä asiakirjat on liitettävä heti ja mitkä vain tietyntyyppisiin tarpeisiin.
- Reitin määrittäminen. Vaiheiden välisten siirtymien ehdot, hyväksyntöjen järjestys, täydennettäväksi palauttamisen säännöt ja hylkäyksen yhteydessä tehtävät toimet määritetään. Näin epäviralliset ”rinnakkaiset” hyväksynnät voidaan poistaa.
- Rajattu pilotti. Uusi prosessi testataan yhden yksikön tai luokan todellisilla pyynnöillä. Käyttäjät ilmoittavat epäselvistä kentistä, ylimääräisistä vaiheista ja tilanteista, joita ei alkuperäisessä mallissa huomioitu.
- Laajentaminen ja ohjeistus. Korjausten jälkeen skenaario laajennetaan muihin yksiköihin. Ohjeistuksessa määritetään pyyntöjen luomisen säännöt, reagointiajat, kiireellisten pyyntöjen käsittelytapa ja vastuu reitin ajantasaisuudesta.
Tämä järjestys auttaa välttämään käyttöönoton muuttumisen abstraktiksi IT-projektiksi. Keskiössä on konkreettinen tehtävä: tehdä tarpeen etenemisestä näkyvää ja ennakoitavaa kaikille, jotka osallistuvat hankintaan päivittäin.
Miten tuloksia arvioidaan ilman muodollisia raportteja
Automatisoinnin vaikutusta kannattaa arvioida havaittavien merkkien perusteella, ei pelkästään luotujen pyyntöjen määrän mukaan. Ennen käyttöönottoa on hyödyllistä kirjata lähtötilanne: kuinka monta kanavaa käytetään, mitä tietoja joudutaan useimmiten tarkentamaan, kuinka moni pyyntö palautetaan täydennettäväksi, missä ei ole vastuuhenkilöä ja mitkä viivästysten syyt toistuvat säännöllisesti.
Yhtenäiseen prosessiin siirtymisen jälkeen voidaan seurata seuraavia mittareita:
- hyväksytyn lomakkeen avulla luotujen pyyntöjen osuus;
- kussakin vaiheessa käytetty aika;
- puutteellisten tai ristiriitaisten tietojen vuoksi tehtyjen palautusten määrä;
- ilman nimettyä vastuuhenkilöä olevien pyyntöjen määrä;
- kiireellisten pyyntöjen osuus ja niiden syyt;
- myöhästyneiden tehtävien määrä yksiköittäin ja rooleittain;
- reitin muutosten ja toistuvien poikkeusten määrä.
Nämä tiedot eivät ole itsetarkoitus. Ne auttavat ymmärtämään, liittyykö ongelma lomakkeeseen, valtuuksiin vai tarpeen suunnitteluun. Esimerkiksi suuri palautusten määrä ei välttämättä kerro aloitteentekijöiden huolimattomuudesta, vaan siitä, että nimikkeen kuvaamista koskevat vaatimukset on muotoiltu liian yleisellä tasolla. Toistuvat kiireelliset pyynnöt voivat puolestaan viitata tuotantosuunnitelman ja hankintakalenterin väliseen katkokseen.
Mitä on tärkeää huomioida ennen käyttöönottoa
Automatisointi ei korvaa yksiköiden välisiä sopimuksia. Jos yrityksessä ei ole määritetty, kenellä on oikeus hyväksyä materiaalin korvaaminen, kuka vastaa teknisestä lausunnosta ja mitä perustellulla kiireellisyydellä tarkoitetaan, ohjelma vain siirtää epäselvyyden digitaaliseen käyttöliittymään. Siksi OpenBoxin määrittäminen kannattaa aloittaa toimintaperiaatteista, ei painikkeiden luettelosta.
Poikkeuksista on myös tärkeää sopia etukäteen. Tuotanto tarvitsee erityisskenaariot hätäkorjauksille, laitteiston pysäytyksille, turvallisuusvaatimuksille ja toimituksille, joilla on ehdoton määräaika. ”Kiireellinen” ei kuitenkaan saa muuttua yleiseksi tavaksi kiertää vakioreitti. On parempi määrittää erillinen pyyntötyyppi, pakollinen perustelu ja myöhempi syiden analysointi.
Käyttäjille työn aloittamisen on oltava helppoa. Aloitteentekijän on ymmärrettävä, minne kirjautua, mikä lomake valita ja mitä lähettämisen jälkeen tapahtuu. Hyväksyjä tarvitsee tehtäväjonon, jossa näkyvät prioriteetit ja asiayhteys. Hankkija tarvitsee suodattimet ja mahdollisuuden nähdä nopeasti käsittelyvalmiit pyynnöt. Johtaja tarvitsee yleiskuvan kuormituksesta ja ongelmallisista vaiheista. Kun jokainen saa vain olennaiset tiedot, muutosvastarinta vähenee.
Milloin käyttöönotosta kannattaa keskustella
Automatisointipäätös on erityisen ajankohtainen, jos pyyntöjä etsitään säännöllisesti viestinnästä, johtajat eivät pysty nopeasti saamaan ajantasaista luetteloa odottavista asioista, hankkijat käyttävät huomattavasti aikaa lähtötietojen tarkentamiseen tai tuotanto saa viivästysriskistä tiedon liian myöhään. Toinen merkki on prosessin riippuvuus yhdestä koordinaattorista, joka muistaa manuaalisesti, kenelle ja mistä on muistutettava.
OpenBox voi toimia perustana hallittuun prosessiin siirtymiselle vaiheittain: ensin yhtenäinen rekisteröinti, sitten reitit ja määräaikojen valvonta, sen jälkeen poikkeamien syiden analytiikka ja skenaarioiden kehittäminen. Määritettävä kokonaisuus riippuu yrityksen rakenteesta, hankintaluokista ja voimassa olevista hyväksyntäsäännöistä.
Jos haluatte ymmärtää, missä kohtaa prosessinne aika kuluu hukkaan, aloittakaa kuvaamalla nykyinen reitti ja muutama todellinen pyyntö. OpenBox-konsultaatiossa näitä skenaarioita voidaan tarkastella, pakolliset roolit määrittää ja ensimmäiselle vaiheelle valita järkevä laajuus. Rauhallinen pilotti tuottaa enemmän hyötyä kuin yritys siirtää kaikki poikkeukset ja sisäiset sopimukset heti järjestelmään.