Põhimõtted

Mul ei ole midagi põhjaliku analüüsi vastu.

Mul on probleem analüüsiga, mis muutub otsustamise ja tegutsemise asendajaks.

Ettevõte võib kuude kaupa kaardistada protsesse, intervjueerida töötajaid, võrrelda tarkvarasid, koostada raporteid ning pidada juhtkonna koosolekuid.

Selle aja jooksul jääb tegelik probleem alles.

Veeb või rakendus ei lähe endiselt live’i.

Arendus seisab.

Käsitöö neelab inimeste aega.

Müük lubab midagi, mida teostus ei suuda pakkuda.

Tarkvarad ei tööta omavahel kokku.

Oluline otsus ootab jätkuvalt kellegi kinnitust.

Inimesed lahendavad iga päev sama probleemi uuesti.

Kuue kuu pärast võib ettevõttel olla väga põhjalik ülevaade sellest, miks ta kaotas kuus kuud.

Mina eelistan leida üles tegeliku pudelikaela, teha vajalik valik ja panna lahendus tööle.

Tavaliselt 48 tunni jooksul.

Enamik ettevõtte probleeme ei vaja rohkem analüüsi

Kui juht minuni jõuab, on ta tavaliselt probleemile juba palju mõelnud.

Ta ei vaja kedagi, kes ütleks talle, et olukord on keeruline.

Seda teab ta isegi.

Ta vajab vastust kolmele küsimusele:

1. Mis on tegelik probleem?

1. Milline otsus tuleb teha?

1. Kuidas lahendus päriselt tööle panna?

Väljast vaadates võib ettevõttel olla kümme erinevat probleemi.

Müük ei kasva.

Meeskond on ülekoormatud.

Projektid hilinevad.

Tarkvara ei toeta tööd.

Andmed on eri kohtades.

Juht peab pidevalt sekkuma.

Sageli ei ole need kümme eraldi probleemi.

Need on ühe või kahe lahendamata pudelikaela erinevad tagajärjed.

Kui hakata parandama kõiki sümptomeid eraldi, võib töö kesta kuid.

Kui leida koht, millest probleemid alguse saavad, võib suure osa segadusest eemaldada ühe õige muudatusega.

Ma ei alusta iga ettevõttega nullist

Olen tegelenud IT-ga alates 1980. aastate lõpust ja olnud ettevõtja alates 1998. aastast.

Olen asutanud üle 20 ettevõtte, juhtinud pikka aega tarkvaraarenduse äri, ehitanud süsteeme, müünud, juhtinud inimesi, nõustanud ettevõtjaid ning vaadanud ettevõtteid ka investori vaatenurgast.

Selle aja jooksul muutuvad tehnoloogiad, tööriistad ja moesõnad.

Probleemide põhiloogika kordub.

Vale klient.

Ebaselge väärtuspakkumine.

Otsustamata strateegia.

Katkine protsess.

Vastutus ilma otsustusõiguseta.

Õige inimene vales rollis.

Tarkvara, mis ei sobi tegeliku tööga.

Asutaja, kelle kaudu peab liikuma iga oluline otsus.

Kogemus ei tähenda, et ma tean enne vestlust kõiki vastuseid.

See tähendab, et ma oskan kiiresti eristada olulist ebaolulisest, põhjust tagajärjest ja päris pudelikaela lihtsalt valjust probleemist.

Ma ei pea iga kord kuus kuud õppima, kuidas ettevõte üldiselt töötab.

Mul on vaja aru saada, kuidas töötab just see ettevõte ja millises kohas tema loogika katkeb.

Olen ehitanud analüüsimiseks spetsiaalsed tööriistad

Ainult kogemusest ei piisa.

Inimese mälu on piiratud, esmamulje võib eksitada ja tugev arvamus ei ole veel tõend.

Seetõttu olen loonud endale tarkvaralised tööriistad, mis aitavad ettevõtet enne esimest sisulist vestlust kiiresti analüüsida.

Sõltuvalt probleemist saan kokku tuua ja läbi töötada näiteks:

• ettevõtte avaliku taustainfo;
• majandusnäitajate muutused;
• ettevõtte positsioneeringu;
• pakutavad tooted ja teenused;
• sihtrühmad ning ostupõhjused;
• kasvule või probleemidele viitavad signaalid;
• ettevõtte tööprotsessid;
• kasutusel olevad tarkvarad;
• süsteemidevahelised sõltuvused;
• rollid, vastutused ja võimalikud pudelikaelad;
• kliendi antud tehnilise või ärilise info.

Tarkvara ei tee minu eest lõplikku otsust.

Ta teeb suure osa aeglasest eeltööst, koondab killustunud info ja aitab püstitada tõenäolised hüpoteesid.

Seetõttu ei alga kliendikohtumine üldisest küsimusest: „Rääkige mulle, millega teie ettevõte tegeleb.”

Ma olen juba teinud kodutöö.

Kohtumisel saan kontrollida, kas nähtav pilt vastab tegelikkusele, ning minna kiiresti sinna, kus probleem tõenäoliselt asub.

Kiirus tuleb mustrite äratundmisest, mitte kiirustamisest

48 tunni lubadus võib tunduda liiga kiire.

Aga kiirus ei tähenda, et jätan olulised küsimused küsimata.

Kiirus tähendab, et ma ei kuluta aega tegevustele, mis otsust ei muuda.

Kogenud inimene ei pea läbi vaatama kõiki võimalikke probleeme võrdse põhjalikkusega. Ta oskab küsida küsimusi, mis välistavad korraga suure hulga valesid seletusi.

Näiteks kui müük ei kasva, ei alusta ma automaatselt müügimeeskonna hindamisest.

Kõigepealt tuleb kontrollida:

• kas ettevõte lahendab piisavalt olulist probleemi;
• kas valitud klient on õige;
• kas väärtuspakkumine on arusaadav;
• kas ostuotsuse teeb inimene, kellega ettevõte suhtleb;
• kas hind, müügikanal ja teeninduskulu sobivad omavahel;
• kas teostus suudab müügi antud lubaduse täita.

Kui veeb või infosüsteem ei lähe live’i, ei ole alati vaja tervet projekti uuesti analüüsida.

Vaja on leida konkreetne koht, kus tervik katkeb:

• frontend;
• backend;
• andmebaas;
• API;
• keskkonnaseadistus;
• autentimine;
• ehitusprotsess;
• deploy;
• puuduv otsus;
• erinevate osapoolte ebaselge vastutus.

Kiirus tekib sellest, et ma otsin piirangut, mitte ei dokumenteeri võrdselt kogu ettevõtet.

Ma ei lahuta äriprobleemi ja tehnilist probleemi

Paljud tehnilised probleemid pole tegelikult ainult tehnilised.

Arendus võib seista, sest keegi pole otsustanud, milline tulemus peab tekkima.

Tarkvarad ei sobi kokku, sest eri osakonnad on optimeerinud enda tööd ning keegi pole vaadanud kliendi või info terviklikku liikumist.

Automatiseerimine ei õnnestu, sest protsess ise pole selge.

Veeb ei konverteeri, sest väärtuspakkumine on ebaselge.

Projekt läheb korduvalt ümbertegemisele, sest müügi lubadus, kliendi vajadus ja arenduse sisend ei ole omavahel seotud.

Kui vaadata ainult koodi, võib parandada sümptomi.

Kui vaadata ainult äri, võib kirjutada soovituse, mida tehniliselt ei saa mõistliku hinnaga ellu viia.

Minu eelis on see, et ma saan vaadata korraga mõlemat poolt.

Mis peaks äriliselt muutuma?

Milline protsess seda tulemust loob?

Milline tarkvara seda protsessi toetab või takistab?

Kas probleemi saab lahendada seadistuse, integratsiooni, väikese arenduse, automatiseerimise, vastutuse muutmise või mõne tegevuse täieliku lõpetamisega?

Ma ei eelda, et iga probleemi lahendus on uus tarkvara.

Mõnikord tuleb olemasolev süsteem õigesti seadistada.

Mõnikord tuleb kaks süsteemi omavahel tööle panna.

Mõnikord tuleb üks katkine samm eemaldada.

Mõnikord tuleb lõpetada tarkvara kasutamine, mis tekitab rohkem tööd, kui ta ära võtab.

Analüüs ei ole minu lõpptulemus

Traditsioonilise analüüsi tulemus on sageli dokument.

Seal on hetkeolukord, probleemid, soovitused, prioriteedid ja järgmised sammud.

Seejärel peab ettevõte leidma kellegi, kes otsustab, mida raportiga teha.

Siis tuleb leida inimene või partner, kes lahenduse ellu viib.

Uus partner peab ettevõttest uuesti aru saama.

Tekib uus lähteülesanne, uus hinnapakkumine, uus ajakava ja uus üleandmine.

Iga üleandmisega kaob osa kontekstist.

Mina ei pea analüüsi lõpptulemuseks.

Analüüs on piisav siis, kui selle põhjal saab teha õige otsuse ja lahenduse tööle panna.

Klient ei vaja minult tõestust, et ma tegin palju analüüsi.

Ta vajab, et probleem kaoks.

48 tunni sisse mahub rohkem, kui probleem on õigesti piiratud

Ma ei väida, et kogu ettevõtte strateegia, organisatsioon ja tehnoloogia muutuvad 48 tunniga täiuslikuks.

Seda pole tavaliselt vajagi.

Ettevõtte tulemust võib piirata üks konkreetne pudelikael:

• puuduv integratsioon;
• katkine funktsioon;
• lõpetamata arendus;
• valesti seadistatud töövoog;
• käsitsi tehtav korduv tegevus;
• puuduv otsustusõigus;
• ebaselge protsessietapp;
• info, mis ei liigu ühest süsteemist teise;
• tegevus, mida keegi pole julgenud lõpetada.

Kui pudelikael täpselt määratleda, saab selle ümber ehitada väikseima toimiva lahenduse.

Mitte kogu ettevõtet korraga ümber kujundada.

Mitte kirjutada ideaalset tulevikuvisiooni.

Lahendada esimene piirang, mis takistab tööl liikuda.

Seejärel on näha, kas ettevõtte tulemus paranes ja milline järgmine piirang nähtavale tuli.

Väikseim toimiv lahendus on parem kui suur ideaalne projekt

Ettevõtted kipuvad tegema lihtsast probleemist suure projekti.

Vajatakse uut funktsiooni ja jõutakse kogu süsteemi väljavahetamiseni.

Vajatakse ühte integratsiooni ja alustatakse suure digitransformatsiooniga.

Vajatakse selget vastutust ning ehitatakse ümber terve organisatsioon.

Suur projekt tundub põhjalik.

Aga mida suurem projekt, seda rohkem:

• oletusi;
• inimesi;
• sõltuvusi;
• kooskõlastusi;
• aega;
• eelarvet;
• võimalusi valesti aru saada.

Mina otsin väikseimat muudatust, mis eemaldab tegeliku piirangu.

See võib olla üks otsus.

Üks parandatud protsessietapp.

Üks liidestus.

Üks väike tarkvaralahendus.

Üks automaatika.

Üks katkise funktsiooni parandus.

Üks vastutus, mis viiakse õigesse kohta.

Kui väike lahendus annab soovitud tulemuse, pole vaja ehitada suuremat.

Kui ei anna, oleme saanud kiiresti uut infot ilma kuut kuud ja suurt eelarvet kulutamata.

Miks kuus kuud analüüsi võib ettevõttele ohtlik olla?

Analüüsi ajal ei seisa probleem paigal.

Katkine protsess toodab jätkuvalt vigu.

Inimesed ehitavad selle ümber uusi käsitsi lahendusi.

Kliendid kogevad sama probleemi.

Töötajad harjuvad ebaefektiivse tööviisiga.

Juhtkond lükkab otsuseid edasi, sest analüüs pole veel valmis.

Mida kauem probleem eksisteerib, seda rohkem tekib selle ümber:

• erandeid;
• ajutisi parandusi;
• tabeleid;
• kontrolle;
• rolle;
• tarkvarasid;
• vaikivaid kokkuleppeid.

Kuue kuu pärast pole algne probleem lihtsalt alles.

Ta on sügavamalt ettevõtte sisse ehitatud.

Mõnikord on pikk analüüs vajalik. Suured investeeringud, keerulised regulatiivsed riskid ja pöördumatud otsused vajavad põhjalikkust.

Aga väga suur osa ettevõtete igapäevastest pudelikaeltest ei vaja kuut kuud uurimist.

Nad vajavad inimest, kes oskab kiiresti näha, milline osa probleemist on päris, ja suudab lahenduse kohe teostada.

Minu 48 tunni tööloogika

Minu töö ei alga esimesest kohtumisest.

1. Teen ettevõtte kohta eeltöö

Kasutan enda loodud analüüsitööriistu, et saada enne vestlust nähtavaks ettevõtte taust, äriloogika, võimalikud signaalid ja probleemi kontekst.

2. Kontrollin hüpoteese juhiga

Vestluse eesmärk ei ole kogu ettevõtte ajaloo ümberjutustamine. Kontrollime, kus nähtav sümptom tekib ja milline mõju sellel on.

3. Jälgin probleemi alguseni

Vaatan läbi protsessi, tarkvara, andmed, vastutuse ja otsused, millest tulemus sõltub.

4. Eraldan pudelikaela kõrvalmürast

Kõiki probleeme ei lahendata korraga. Valime piirangu, mille eemaldamine muudab ettevõtte tulemust kõige rohkem.

5. Teen vajaliku strateegilise või tehnilise valiku

Kas muuta protsessi, vastutust, süsteemi, integratsiooni, automatiseerimist või lõpetada ebavajalik tegevus?

6. Panen lahenduse tööle

Ma ei piirdu soovitusega. Tavaliselt annan toimiva lahenduse 48 tunni jooksul.

Mida klient 48 tunni järel saab?

Mitte sajaleheküljelist raportit.

Mitte nimekirja kõikidest asjadest, mida ettevõte võiks kunagi paremini teha.

Klient saab võimalikult konkreetse tulemuse:

• tegelik pudelikael on tuvastatud;
• vajalik valik on tehtud;
• probleem on parandatud või väikseim toimiv lahendus töötab;
• mõju saab kontrollida;
• järgmine otsus on selge.

Mõnikord on tulemuseks töötav tehniline lahendus.

Mõnikord parandatud protsess.

Mõnikord automatiseeritud käsitöö.

Mõnikord selge otsus lõpetada tegevus, mis ei loo väärtust.

Mõnikord saab 48 tunniga eemaldada probleemi, mille ümber ettevõte on kuid rääkinud.

Mitte sellepärast, et probleem oli tühine.

Sellepärast, et keegi polnud varem vaadanud korraga äriloogikat, protsessi ja tehnilist teostust.

Ma müün lahendatud probleemi, mitte analüüsitunde

Minu eesmärk ei ole hoida klienti kuus kuud analüüsiprojektis.

Minu eesmärk on saada ta võimalikult kiiresti uuesti liikuma.

Kui probleem on lahendatud 48 tunniga, ei muutu tehtud töö vähem väärtuslikuks.

Vastupidi.

Kliendile jääb alles aeg, raha ja juhtide tähelepanu, mis oleks kulunud probleemi ümber elamisele.

Pikk töö ei ole automaatselt põhjalik.

Kiire töö ei ole automaatselt pealiskaudne.

Oluline on, kas leiti õige probleem ja kas lahendus töötab.

Kui sinu ettevõttes on probleem, millest on juba liiga kaua räägitud, ei ole sul võib-olla vaja veel ühte analüüsi.

Võib-olla on sul vaja kedagi, kes teeb kiiresti selgeks, kus töö tegelikult katkeb, ja parandab selle ära.

Saada mulle probleem kolme lausega.

Ma ütlen, kas see on asi, millele saan tavaliselt 48 tunni jooksul toimiva lahenduse anda.

Mikk Orglaan

Challeng.ist