Mis saab peale teenusplaani loomist: juhend edasisteks sammudeks, kuidas liikuda ideaalsest teenusest tehnilise kirjelduseni.

Kujutleme, et meil on traditsiooniline kaubandusettevõtte, näiteks tegeleme lukkude müügiga peamiselt ehitusettevõtetele ja vähemal määral ka eraklientidele.

 

Oma klientide ning nendega kokkupuute punktide paremaks mõistmiseks oleme teinud teenusplaani. Majanduskeskkonna muutuse tõttu oleme sunnitud oma äri kriitiliselt üle vaatama ning oleme visandanud ka uue teenusplaani, selliselt nagu me tulevikus sooviksime oma äri teha. 

 

Teenusplaanis on kirjeldatud kliendi tegevused ja kokkupuutepunktid teenuse raames. Lisaks on nimetatud kliendiga seotud toetavad tagatoa protsessid.

 

Seega meil on olemas hetkeolukorda kirjeldav teenusplaan ja esmane tuleviku visioon, kuid tekib küsimus, kuidas edasi liikuda? Järgnevalt vaatame edasisi tegevusi, mille najal edasi liikuda.

 

 

Ärianalüüs

Ärianalüüsi läbiviimiseks on erinevaid metoodikaid, millele selles artiklis ei keskendu – vaatleme edasisi tegevusi pigem üldiste mõttemustrite kontekstis.

 

Üks ärijuhtimise gurusid E.M. Goldratt on välja töötanud piirangute teooria, millest ka edasises tekstis lähtun. Piirangute teoorias on omakorda paar olulisemat põhipostulaati, millele soovin tähelepanu juhtida ja siinkohal välja toon:

 

• keskendu ärieesmärgile – iga muutus peaks lähtuma organisatsiooni kui terviku eesmärkidest. Erasektori puhul on peamine küsimus, kas muutus aitab suurendada kasumit. See väga agregeeritult jaguneb kaheks alamteemaks: tulude suurendamine või kulude vähendamine. Avaliku sektori puhul seostub eesmärk organisatsioonile seatud eesmärgi täitmisega. Avaliku hüve pakkumise eesmärgiga seoses saab keskenduda näitaks mahu suurendamisele või kvaliteedi parandamisele. 

 

• ära keskendu lokaalsetele optimumidele – teenuskaart on kõikehõlmav töövahend. See katab kliendi kontaktpunkte, tagatoa protsesse jne. Samas seda tuleb vaadata organisatsiooni kui terviku kontekstis. Realiseerimaks äärmiselt optimeeritud teenuskaart, peaks allutama kõik teenuse poolt vajalikud ressursid ja protsessid sellele teenuskaardile. Näiteks kui Bolt (Taxify) alustas ainult takso vahendamise teenuse pakkumisega, oli võimalik allutada kogu tegevus selle teenuse osutamisele ning teha seda nii hästi kui võimalik. Nüüd, kus Bolti äri on laienenud ja hõlmab toidukulleri teenust, elektritõukeratta renti, lühiajalist autorenti, tuleb teha mööndusi ühe teenuse osutamisel. 

 

Ühe teenuse jaoks organisatsiooni optimeerimine tähendab lokaalse optimumi loomist, mis sageli tähendab ebaefektiivsust teistes teenustes. Seega on oluline optimeerida terviku vajadustest lähtudes.

 

Teenuskaardiga edasi töötades on vaja anda hinnang muutusest tekkivale ärilisele kasule. Analüüsi käigus tehakse kindlaks, kas soovitud kasu saabub ja millisel määral. Teenusplaani tuleb analüüsida ka vaatenurgast, kas saavutatavad ärilised kasud on piisavad, näiteks kui uus teenus tingib tulude kasvu 1-2% siis kas see on piisav.

 

Hinnates seda ebapiisavaks võib kaaluda alternatiivseid tegevusi, mis kasumit suurendavad. Ärilist mõju vaadates võib tekkida ka otsus realiseerida teenusplaan osaliselt, saavutamaks piisavat mõju tulude kasvule, kuid loomata liigset ebaefektiivsust mujal.

 

Sisuliselt ärianalüüsiga peaks jõudma selguseni, kas ja millises ulatuses liikuda edasi teenusplaani realiseerimisega. Ideeliselt on tehtud enne teenusplaani väljatöötamist näiteks konkurentsi ja turu analüüs, mistõttu ei ole teenusplaan tehtud perspektiivitule valdkonnale.

 

Joonis 1: ärianalüüsi etapid

 

Igal juhul ärianalüüs annab teenusplaanile rahalise dimensiooni. Edasised sammud keskenduvad juba teenusplaani kontaktpunktide viimisele üheks või mitmeks infosüsteemiks.

 

Iga teenusplaani kontaktpunkt võib kasutada erinevat infosüsteemi või tegu võib olla ka ühe mahukama süsteemiga. Edaspidi räägime küll infosüsteemi eelanalüüsist, kuid seda võib rakendada nii ühele kui mitmele süsteemile. 

 

 

Protsessianalüüs ja eelanalüüs

Protsessianalüüs on teenuskaardil märgitud tegevuste organiseerimine loogilisteks skeemideks, kus on välja toodud erinevad sündmused, tegevused, otsustuskohad ja rollid.

 

Protsessianalüüs on visualiseeritud skeemidena ja sageli Eestis kasutatakse selleks BPMN-i märgistuskeelt. Skeemid võivad olla erineva detailsusastmega, kuid laias laastus on äripoolele mõeldud skeemid agregeeritumad ja lihtsamad ning IT-le mõeldud skeemid detailsemad (ning äri jaoks raskemini loetavad).

 

Protsessianalüüs aitab valideerida ja detailiseerida teenuskaardil olnud loogikat ja tuvastada erandjuhte. Näiteks hiljutises analüüsiprojektis pidi üks taotlus läbima kaks taotlejat ja protsessiskeemilt lisandus kaks erijuhtu:

 

1. mis juhtub kui teine taotleja vastab taotlusele eitavalt;
2. mis juhtub, kui teine taotleja jätab taotluse kinnitamata.

 

Selle lihtsa näite puhul saab täiendusi teha nii teenusplaani kui ka neid adresseerida protsessianalüüsis. 

 

Protsessianalüüsi käigus vaadatakse sageli üle ka täiendavad piirangud, mis tekivad muudest valdkondadest. Teenuskaarti luues on parem lasta kujutlusel lennata ja teha innovatsiooni.

 

Paraku eksisteerib alati meie kontrolli all olevaid tingimusi ja meie kontrolli alt väljas tingimusi. Meie kontrolli all olevad tingimused saame kohandada teenuskaardile ja saavutada soovitud tulemuse.

 

Meie kontrolli alt väljas olevad tingimused on sellised, mida peame arvestama ja ennast kohandama neile. Tüüpiline näide siinkohal on Finantsinspektsiooni juhendid krediidiasutustele.

 

Soovides turule tulla täiesti uue finantsteenusega, võime seda kujundada vägagi loominguliselt. Paraku selleks, et saada krediidiasutuse tegevusluba, peab teenus ning seda toetavad süsteemid jääma Finantsinspektsiooni tingimuste piiresse.

 

Hiljuti ühe avaliku sektori analüüsi käigus oli teenuskaardil terve rida funktsionaalsusi, mis oleksid mõjunud klientidele väga positiivselt. Protsessianalüüsi käigus selgus eriliigiliste isikuandmete töötlemise asjaolu ja neid ei või soovitud eesmärgil kasutada, mistõttu jäid need funktsionaalsused realiseerimata.

 

Teiseks aitab protsessianalüüs tuvastada n-ö pudelikaelu - selle all mõistame ressurssi, kelle tegevusest sõltub protsessi üldine kiirus ja kui see ressurss on üle koormatud, tekib viivitusi kõigi teenusjuhtumite korral.

 

Joonis 2: protsessianalüüsi visuaalne kirjeldus

 

Pudelikaelte tuvastamine on ka üks varasemalt mainitud piirangute teooria keskseid aspekte. Protsessianalüüsist võib selguda ühe ressurssi pudelikaelaks olemine, sellisel juhul tuleb teostada optimeerimised pudelikaelale surve vähendamiseks.

 

See võib tähendada teatud tegevustest loobumist, nende üleandmist teisele ressursile, täiendavate vahendite/ abivahendite pakkumist pudelikaela tegevuse efektiivsuse tõstmiseks.

 

Siinkohal tuletan meelde, et liigseid lokaalseid optimume tuleb vältida, sest kui pudelikael täiesti kaotada, liigub see teise kohta. Pudelikael ei pruugi paikneda teenuse põhiprotsessis vaid võib paikneda ka mõnes tugiprotsessis.

 

Protsessianalüüs on aluseks tulevase infosüsteemi funktsionaalsuste kirjeldamiseks. Sageli nimetatakse seda ka eelanalüüsiks, mis sisaldab endas protsessianalüüsi.

 

Eelanalüüsi eesmärk on kirjeldada infosüsteemi tehnilisest vaatenurgast – seal sisalduvad funktsionaalsed nõuded, mittefunktsionaalsed nõuded, äriinfo mudel (sisaldab peamisi olemeid, mida süsteemis hallatakse), üksikutel juhtudel ka olekudiagrammid jne.

 

Tegevustest ja otsustuskohtadest kujunevad peamised funktsionaalsused. Protsessi sisenditest ja väljunditest hakkavad kujunema tulevase andmemudeli peamised olemid (detailanalüüsis lisatakse neile atribuudid ja need muutuvad andmebaasi tabeliteks) ja nende vahelised seosed.

Joonis 3: eelanalüüsi visuaalne kirjeldus

 

Lisaks on võimalik teha otsus jätta teatud tegevused infosüsteemist välja ja teostada manuaalselt ning seeläbi hoida kokku süsteemi arendamiselt. Eelanalüüsis on funktsionaalsuste kirjeldamiseks erinevaid metoodikaid.

 

Eelanalüüs peab andma edasi visiooni infosüsteemist. Eelanalüüs jääb siiski visiooni tasemele ja tehniliselt spetsifitseeritakse funktsionaalsused detailanalüüsis.

 

Protsessianalüüs ja eelanalüüs on olulised sammud teenuse tehnilise kirjelduse täpsustamise suunas, mille käigus tuleb välja uusi aspekte, mida arvesse võtta.

 

Tungivalt soovitav on eelanalüüsi täiendamine üldise wireframe prototüübiga ja vastupidi. Prototüüpimisest on meie blogis varasemalt kirjutatud suur hulk artikleid - soovitan lugeda kaheosalist artiklite seeriat „Kuidas prototüübid täiendavad analüüsi?“

 

 

Edasi arenduse poole 

„Teenuskaardist tuleneb äriline visioon edasi liikumiseks. Ärianalüüsist tuleneb selgus, et soovime selles suunas liikuda. Protsessianalüüsist tekib selgus, milline äritegevus hakkab välja nägema. Eelanalüüsist on selged nõuded, mida tulevane infosüsteem peab tegema hakkama ning prototüübist on teada ka selle üldine wireframe tasemel väljanägemine.“

 

Kuidas teada saada, palju see asi mulle maksma läheb? Enne sellele vastamist peab rääkima määramatusest. Nimelt kui tegu on innovaatilise teenusega, kus kasutatakse uusi tehnoloogiaid, on meil tegu suurema määramatusega olukorraga.

 

Sellisel juhul on eelanalüüsis kirjeldatud funktsionaalsus agregeeritum ja loob pigem üldise raamistiku. Madalam määramatus on keskkonnas, kus protsessid ja tehnoloogiad on tuttavad. Igatahes on oluline, et eelanalüüsi ja esialgse prototüübi põhjal on võimalik anda indikatiivne mahuhinnang. 

 

Täpse mahuhinnangu jaoks on vaja detailanalüüsi, mis on nõuete ja funktsionaalsuste täpsustamine tehnilisest seisukohast. Näiteks peamised äriolemid kirjutatakse lahti atribuutide tasemel, olemite vahel täpsustatakse erinevad vahetabelid, mis võimaldavad seoseid hallata.

 

Kasutuslugude puhul kirjeldatakse alternatiivsed vood. Liidestuste puhul kirjeldatakse vahetatavate andmete formaat ja liidese poole pöördumise nõuded. Täpsustatakse rollid ja nende privileegid. Nimekirjas on ainult mõned näited.

 

Fakt on see, et arenduse jaoks on vajalik detailanalüüs. Detailanalüüs võib olla eraldi projekt, kuid selle võib viia läbi ka arenduse raames.

 

Arendusprojekti raames tehakse detailanalüüs enne süsteemi mingi osa arendama hakkamist, tavaliselt on selline olukord inkrementaalse arendusmetoodika puhul.

 

Detailanalüüsi puhul, mis on tehtud enne arendamist, saab anda palju täpsemad mahuhinnangud. Teisalt tuleb arvestada, et detailanalüüs võtab aega ja sageli selguvad arenduse käigus uued asjaolud, mistõttu tuleb tagasi pöörduda detailanalüüsi juurde ja seda uuendama hakata. Detailanalüüsist võib pääseda ainult äärmiselt traditsiooniliste lahenduste puhul (nt lihtne veebileht ja e-pood). 

 

Joonis 4: detailanalüüsi visuaalne kirjeldus

 

Kokkuvõttes teenuskaardist, protsessianalüüsist, eelanalüüsist ja wireframe prototüübist piisab, et anda arenduse indikatiivne mahuhinnang, kuid sellisel juhul tuleb arvestada, et enne arendama hakkamist on vaja kindlasti detailanalüüsi.

 

Detailanalüüsi olemasolul on arenduse mahuhinnang täpsem, kuid see ei kaota vajadust detailanalüüsi kohandada ja uue info valguses täpsustusi teha.