Kas minu äri on tegelikult objektipõhine äri? Ka hari ja labidas on tänapäeval IT!

Autorid: Liis Aljas ja Erol Kunman, BCS Itera konsultandid

Paljud ärid lähtuvad praeguseni traditsioonilisest loogikast klient → leping → teenus → arve. Parem aga on lähtuda objektist kui tegelikust äri südamest. Mis need objektid on ja miks on oluline kujundada oma protsessid nende põhjal?

Objektipõhiste äride hulka kuuluvad sisuliselt kõik turva-, puhastus-, jäätme-, heakorra-, kommunikatsiooni- jms teenuseid pakkuvad ettevõtted, kus firma osutab teenust regulaarselt kliendi juures ehk objektil. Objekt on paljudel juhtudel keskne ühik, mis on miskit, mille raames tegelikult mõeldakse ning materjale, tööjõukulu jm arvestatakse. Ühel kliendil võib olla mitu väga erinevat objekti. Näiteks võib koristusfirma pakkuda puhastusteenust hotellipidajale kuuluvas kahes väga erinevas hotellis, kus ühte tuleb koristada põhjalikult iga päev, teist aga vaid kord nädalas.

Andmed juhivad äri

Tavaliselt mõeldakse mudeli järgi klient → leping → teenus → arve. Kuid isegi sama kliendi objektid võivad olla nii erinevad, et vajavad eraldi lähenemist. Vahel on äri iseloom selline, et tegelikult tuleb andmeid vaadata hoopis kliendiüleste objektide lõikes. Praegu haldavad ettevõtted palju rohkem infot kui kliendiregister, kliendipõhine müügieelarve, märkused ja lepingud manustena. Andmed peaksid olema äri olemust arvestades objekti kaupa koondatud ja mugavalt kättesaadavad, et toetada igapäevast müügitegevust ning teha juhtimisotsuseid.

Objektide register

Andmeid aitab hallata äri toetav majandustarkvara, kus kesksel kohal on äriprotsessi südameks olevate objektide register. See omakorda koosneb objektidest, mille külge koondatakse kõik nendega seotud andmed üle kogu ettevõtte: finantsandmed, igapäevase müügi kohta käiv info, seotud vara ja personal jne. Objekt ei ole ainult tähis või dimensioon/kulukoht, mida muule infole külge panna, vaid päriselt kasutatav tööriist, mis toetab igapäevatööd ja analüüsi lähtuvalt reaalsest äriloogikast lähtuvalt.

Kujutame näiteks ette objekti, kus regulaarselt osutatakse lepingulisi heakorrateenuseid. Sõltuvalt aastaajast niidetakse näiteks muru, trimmerdatakse, hoitakse teed ja katused lumest puhtad… Sellise objekti edukaks haldamiseks (alates teenuse osutamisest kuni arvelduseni) vajaminevate  andmete komplekt saab sündida ainult eri registrite läbimõeldud koostöö tulemusena, sest vaja on hallata:

• objekti põhiinfot (aadress, paiknemine, suurus, kontaktisikud, eripärad jms);
• kliendiinfot (esindajad, juriidilised kontaktid jms);
• lepingulist infot (teenuse kriteeriumid, maksetingimused);
• teenust osutavaid isikuid (töötajad, lisaks nendega seotud töökäsud ja tööajagraafikud)
• teenuste enda infot (kus, mis ajahetkel ja ulatuses seda osutatakse);
• teenuse osutamiseks kasutavat vara (mis täpselt, kus ja kelle vastutusel);
• teenuste hinnastamist (periood, hind, ka teatud eritingimustel):
• arveldust (automatiseeritud perioodiline arvete genereerimine);
• teenuse osutamise logi (nt hoolduspäevikud);
• kliendi tagasisidet.

Lisaks on vaja teha analüüsi kõikides punktides, sh jälgida finantstulemit.

Kui süsteem võimaldab koondada infot objektide ümber, siis hõlbustab see tunduvalt igapäevatööd ja analüüsivõimalusi:

Seega on vaja päris muljetavaldavat üksteisega põimunud registrite hulka. Enamasti on olukord selline, et info paikneb osaliselt olemasolevas majandustarkvaras, Excelis, paberil ja töötajate peas. Isegi kui seda täpselt niimoodi ei sõnastata, käib mõtlemine ja tegevus tegelikult objektide lõikes. Tarkvara võiks ja peaks seega toimima ka objektidest lähtuvalt

Kui süsteemis on võimalus koondada info objektide ümber, siis hõlbustab see tunduvalt igapäevatööd ja analüüsivõimalusi. Ühtlasi võimaldab see tuua üha rohkem infot Exceli tabelitest ja inimeste peast ühtsesse süsteemi kokku, sest on olemas keskne ühendav lüli, mida on mugav kasutada.

Objekti kaart

Objekti kaart on tõhus tööriist. Juba müügifaasis on mugav koondada kokku kogu objekti puudutav info ja selle põhjal pakkumine ning hiljem leping koostada.

Ka ettevõtte inimesed, kes on objektiga ühel või teisel moel seotud, saab objektile märkida. Objekti kaardil on näha nendega seotud info, tööajagraafik või töökäskude ahel. Kaardile on mõistlik linkida ka vara, mida kasutatakse teenuse osutamiseks, ja seadmed, mis on objektile renditud. Lisaks saab manustena liita sinna kõik dokumendid, näiteks joonised, juhendid vms – nii on kogu info konkreetses kohas olemas.

Regulaarse teenuse puhul on lihtne objekti kaardile müügiridadele tuua kaubad või teenused, mille põhjal saab arveldamise automaatseks muuta. Kui märkida müügireale veel kehtivusaeg, on võimalik automaatsesse arveldusse kaasata ka ühekordsed või ebaregulaarsed müügid.

Igale objektile saab määrata oma hinnakirja ja seda ka kliendi- või lepingupõhiselt. Hindadele võib määrata kindlad kehtivusajad, allahindlused või näiteks koguse alampiirid, mille puhul hakkab kehtima madalam hind. Hinnad saab määrata ka keskselt, nii et objekti eest vastutavatele inimestele  jääb ainult tellitud teenuste ja selleks vajalike kaupade kinnitamise vaev ilma kehtivate hindade otsimiseta, sest tarkvara teeb õige hinna otsimise töö ära.

Objektipõhist hinnakirja funktsionaalsust võiks kasutada ka sellise iseloomuga äri puhul, kus objekt ei ole üks kliendipõhine teenindusobjekt, vaid eri kliente teenindav üksus, mille pakutavatele teenustele on vaja teha oma konkreetne hinnakiri.

Juba müügifaasist alates saab koondada kokku kogu objekti puudutava info:

Ei pusletamisele

Kuid objekti ei pea vaatama ainult müügi vaatenurgast. Kui ostuprotsess on selline, mille puhul on teada, mida ühe või teise objekti jaoks hangitakse, saab objekti juba ostuarve esmase sisestamise juures ära märkida. Regulaarse hankija korral on siis vaja omavahel objekti tähised kokku leppida, nii et tema arvel oleks see tähis olemas, ja e-arve sissetõmbamisega on ostuinfo juba objektiga seotud.

Tegelikult võib juba planeerimise ja eelarvestamise objektipõhiseks muuta. Sellisel juhul on loogiline koostada iga objekti eelarve juba objekti kaardil, et programm saaks need hiljem üheks suureks eelarveks kokku liita. Nii jääb ära palju klassikalist exceldamist, kus eri valdkondade inimesed annavad sisendi finantsinimestele, kes hakkavad nendest tükkidest puslet kokku panema. Las süsteem paneb selle ise kokku, inimestele jääb ainult analüüsimise ja timmimise vaev.

Võimalusi ja vajadusi, mis peaks olema objektile määratud, on kindlasti väga palju. Nii nagu iga ema meelest on tema laps eriline, tundub see ka igale ettevõtjale: minu äri on ikkagi väga spetsiifiline ja omamoodi. Aga nagu lastel üldjuhul on ikkagi kaks kõrva, kaks silma ja talvel nohune nina, on ka erinevate äride puhul peamised hallatavad infokogumid sarnased.  Kõigil on kliendid, lepingud, hinnad, vara või seadmed, töötajad ja nende haldamine jne. Spetsiifilised on hoopis seosed eri osade vahel. Kui võtta kasutusele äriliselt loogiline objekt kui infot koondav keskne üksus, on neid seoseid palju lihtsam süsteemi jaoks defineerida. Nii on võimalik luua hästi funktsioneeriva rätsepatarkvara, mis vastab just nendele protsessidele ja vajadustele, mida konkreetse äri puhul vaja on.

Kindlasti on võimalik näidisena toodud teenuseid mõnda aega edukalt osutada ka lihtsalt kliendiregistri, kalendri, mobiiltelefoni ja Exceli abil. Ent kui räägime tuhandetest objektidest, sadadest lepingutest ja klientidest, siis konkurentsis saavad püsida vaid sellised ärid, kes kasutavad tarkvara, mis paneb kesksele kohale äri tegeliku südame – objekti.