Teidänkin organisaatiossanne on ihan varmasti jokin prosessi, joka ärsyttää kaikkia? Tai jos ei ihan kaikkia, niin ainakin isoa osaa suorittavaa työtä tekevistä?
Ehkä tehty tarjous pitää syöttää moneen eri järjestelmään, jotta kaikki asiaankuuluvat osastot saavat siitä tarvitsemansa tiedon? Tai jokin kuukausiraportti koostetaan yhä käsin, vaikka data on olemassa jossakin (todennäköisesti useammassa paikassa hajallaan)? Esimerkkejä on valtavasti.
Järki sanoo, että kyllähän näihin takkuaviin prosesseihin varmaan ratkaisujakin tällä digitalisaation ja AI-pöhinän aikakaudella olisi, mutta silti ratkaisun valitseminen ja päätöksen tekeminen odottaa. Miksi?
Tässä artikkelissa kerromme, miten ketterästi työarjen kitkaisia tehtäviä on oikeasti mahdollista ratkoa.
Miksi pienenkin ohjelmistohankkeen käynnistäminen odottaa aina jotain muuta?
Olemme huomanneet, että työelämässä vallitsee erikoinen paradoksi: kaikilla on kiire samalla, kun jotain tärkeää odotetaan tapahtuvaksi.
Tyypillistä on odottaa jonkin ison hankkeen aloittamista, sen etenemistä tai valmistumista. ERP-uudistusta, joka on pakko tehdä viiden vuoden aikajänteellä? Tuoteportfolion päivitys on juuri nyt kesken? Jonkin ison, toimintaa vahvasti määrittävän järjestelmän viimeisin versio tulisi jossain kohtaa ottaa käyttöön?
Kuulemme toistuvasti, kuinka organisaatiot olisivat periaatteessa valmiita korjaamaan rikkinäisiä, virheherkkiä ja hitaita prosessejaan, mutta silti valtaosa päätyy jatkamaan odottamista, koska aina jokin muu on tärkeämpää, eikä mitään muutoksia uskalleta tehdä ennen kuin joku tietty asia muuttuu ensin.
On helpompaa jatkaa vanhaan malliin kuin valita muutos, vaikka muutoksen tekeminen on juuri se mitä tuloksellisempi, sujuvampi ja tehokkaampi työarki edellyttäisi. Tarvitseeko muutoksen tekemisen kuitenkaan olla niin pelottavaa?
Ohjelmistohankkeen vaatimusmäärittely on ongelma – parempi siis vannoa käytännön tekemisen nimeen
Perinteisesti ohjelmistoprojektit on aloitettu vaatimusmäärittelyllä, jossa käytetään paljon aikaa tarpeen määrittelemiseksi paperille. Määrittelyn pohjalta kilpailutetaan toimittajat ja kuukausien työn jälkeen lopulta päästään ehkä sopimaan paras arvaus halutusta toimitussisällöstä.
Kuulostaa ihan järkevältä etenemistavalta, mutta tämä prosessi on kuitenkin yksi suurimmista syistä siihen, miksi budjetit aina paukkuvat ja aikataulut venyvät. Kukaan ei pysty täysin määrittelemään tarvettaan etukäteen. Ei vaan pysty. Tämä aiheuttaa projektin loppupäässä odottamattomia muutostarpeita ja kallista jatkokehitystä, jotta ratkaisu saadaan toimimaan siten, että se palvelee tarkoitustaan.
Perinteisen tavan vaihtoehtona me Steve the Clerkillä tarjoamme prosessin, jossa ratkaisua lähdetään mahdollisimman nopeasti ja matalalla kynnyksellä rakentamaan ja testaamaan.
Tämä on mahdollista, koska rakennamme ratkaisua valmiille, monenlaiseen käyttöön taipuvalle alustallemme, joka ei ainakaan alkuvaiheessa edellytä uuden koodin kirjoittamista. Tällöin ostajan on mahdollista päästä näkemään ja testaamaan konkreettista työkalua hyvin pienellä ajallisella panostuksella.
Pilottia testatessa havaitaan aina asioita, joita kukaan ei osannut ajatellakaan siinä vaiheessa, kun yritti luonnostella vaatimusmäärittelyä paperille. Aina löydetään uusia tarpeita, reunaehtoja, mahdollisuuksia ja ideoita, mutta kenellekään ei iske paniikki, koska kaikki on helposti muokattavissa. Hinta ei hyppää uusiin sfääreihin eikä aikataulu leviä mihinkään.
Mistä ohjelmistohanke sitten oikeasti kannattaa aloittaa?
Vaatimusmäärittelyyn jumiutumisen lisäksi toinen keskeinen virhe uuden ohjelmiston hankinnassa tai minkä tahansa järjestelmäpilotin käynnistämisessä on se, että keskustelu lähtee heti sivuraiteille. Tyypillisesti lähdetään pohtimaan ominaisuuksia, tarvittavia kenttiä ja niiden yhdistelmiä, integraatioita ja muita toiminnallisuuksia.
Ei näistä kannata puhua, ennen kuin kaikille on selvää, mitä uudella työkalulla, ohjelmistolla tai järjestelmällä oikeasti halutaan ratkaista. Vasta sitten, kun koko ongelman juurisyy on kirkas, kaikki muu rakentuu sen ympärille – siis myös toiminnallisuudet ja integraatiot. Ominaisuudet itsessään eivät siis ole mikään tavoite, vaan ennemminkin väline.
Ohjelmistohanke kannattaa siis ehdottomasti aloittaa organisaatiosi kokemasta tuskasta. Mikä on se yksi asia, joka hidastaa tai hankaloittaa tekemistä eniten juuri nyt?
Vastauksen ei missään nimessä tarvitse olla täydellinen ja kaiken kattava vaatimusmäärittely, kuten äsken totesimme. Riittää, kun tunnistaa missä kohtaa työ pysähtyy, hidastuu tai menee pieleen, mitä tietoa ei nyt saada ja miksi?
Tutustu referenssitarinaan:Jyki Oy myynnin haasteet ratkesivat konfiguraattorilla – ”Tyytyväisemmät asiakkaat, virheettömämmin sujuva tuotanto ja parempi kannattavuus”
Vain oikea henkilö organisaatiossa saa ohjelmistohankkeen etenemään
Vaikka sisäisen tarpeen tai teknisen ratkaisun toimivuuden suhteen ei olisi mitään epäselvyyksiä, tyssäävät monet kehityshankkeet siihen, että oikea henkilö organisaatiossa ei ole kiinnostunut asian ratkaisemisesta.
Me Steve the Clerkillä ratkaisemme lukuisia käytännön työn tekemiseen liittyviä ongelmia, jonka vuoksi erityisesti suorittavaa työtä tekevät henkilöt yleensä innostuvat ratkaisuistamme helposti. Heidän on helppo ymmärtää meidän tarjoamiemme työkalujen vaikutus arjen työn sujuvuuteen ja virheettömyyteen, mutta samaan aikaan heillä ei ole valtuuksia edistää mitään kehityshankkeita.
Toimitusjohtaja on tyypillisesti liian kiireinen ja liian kaukana suorittavan työn yksityiskohdista. It-osastolle on tyypillistä takertua riskeihin, muutoksiin ja integraatioihin, eikä työntekijöiden arkea helpottava ratkaisu ole yleensä heille kiinnostava. Tehokkain edistäjä on siis henkilö, joka tuntee käytännön työn tuskan omakohtaisesti mutta jolla on silti riittävä asema viedä asia eteenpäin.
Kuka tämä avainhenkilö teidän organisaatiossanne on? Hänet pitää saada haluamaan muutosta.
Kiinnostuitko? Tutustu Steve the Clerk HUBiin
”Aloitetaan sitten kun isompi hanke on ensin maalissa, ettei tarvitse muuttaa myöhemmin.”
Tämä on ymmärrettävä pelko, mutta se kuitenkin perustuu oletukseen, että muutos on ongelma. Me näemme asian toisin: maailma muuttuu, liiketoiminta muuttuu ja tarpeet muuttuvat. Järjestelmän pitää siis aina pystyä muuttumaan mukana – jatkuvasti.
Ainoa, mitä voit pilotissa oikeasti hävitä, on aika. Me kyllä pyrimme minimoimaan senkin, sillä selvitämme ja teemme asioita proaktiivisesti itse, sekä kysymme hyviä kysymyksiä, jotta teidän aikanne säästyy.
Jos kokeilu ei johda mihinkään, olette oppineet jotain tärkeää.
Toisaalta jos se toimii, olette jo hyvää vauhtia matkalla.
Haluatko nähdä, miltä ensimmäinen, kevyt ja helposti läpivietävät pilotti voisi teidän organisaatiossanne näyttää?
Tutustu referenssitarinaan: SKAL loi kuljetusalaa palvelevan konfiguraattoriperheen: ”Yritysten ei pidä kuluttaa energiaansa sääntöviidakon selvittämiseen”
Anna meidän näyttää, miten ratkaisisimme jonkin teille merkityksellisen – vaikka ihan pienenkin – ongelman
Ongelma voi olla sellainenkin, että pärjäilette sen kanssa arjessa, mutta se kuitenkin koko ajan ärsyttää ja hukkaa resursseja.
Rakennamme pilotin lyhyessä ajassa, jotta pääset näkemään, miltä HUB ja teille suunniteltu ensimmäinen työkalu näyttää käytännössä. Takaamme, että saat nopeasti konkreettisia hyötyjä. Varaa tapaaminen kanssamme!
