Eelmises artiklis Tegevuspõhise kuluarvestuse praktiline juurutamine ja kasutamine kirjeldasin kuluobjekte nii: “Kuluobjektid määratletakse tulenevalt otsustustoetusele seatud eesmärgist - kuluobjektide struktuur vastab suures osas tulude struktuurile s.t. ettevõtte teenuste/toodete osutamise keerukusele Traditsiooniliselt sisaldab kulumudel vähemalt kahte tüüpi kuluobjekte – tooteid/teenuseid ja kliente. Sõltuvalt tegevusvaldkonnast võib nendele kahele lisanduda ka näiteks kanal vms.. Nagu eespool toodust selgub , ei ole kuluobjekt kõikide organisatsioonide jaoks üheselt defineeritav nagu näiteks ressurss või konto, kuluobjektide struktuur ja hulk tuleneb otseselt otsustustoetuse eesmärgist. " Seega vast võiks kuluobjekti definitsioon olla umbes midagi sellist – kuluobjekt on objekt, mis kirjeldatakse lähtudes otsustustoetuse eesmärgist ning millele koondatakse tegevuspõhise kulumudeli kaudu põhjus-tagajärg seost kasutades kulud. Ilmselgelt ei ole tegemist just keeleliselt nõtke konstruktsiooniga ja sellepärast on kõik asjalikumad variandid ettepanekutena oodatud. Aga läheme asja juurde. Peamiseks eesmärgiks ABC kasutamisel on kasumlikkuse mõõtmine ning selles vallas otsustustoetuse pakkumine, sellepärast vaatlemegi kuluobjektide kirjeldamist just selle näite alusel. Esimese sammuna jagame kuluobjektide kirjeldamise kaheks, vaatleme organisatsioonist väljapoole jäävaid ehk lisaväärtust loovaid tegevusi ja organisatsiooni sisemisi tegevusi eraldi.
Tavapäraselt on organisatsioonist väljapoole ulatuvate tegevuste eesmärgiks toodete ja teenuste müümine klientidele. Selleks, et see õnnestuks, eksisteerib enamasti kaks tegevusvaldkonda – müük ja turundus, esimese eesmärgiks siis kliendisuhte loomine, hoidmine ja arendamine koos konkreetsete toodete müügitehingute läbiviimisega ning teise puhul toodete/brändide arendamine, tutvustamine jms. Kasumlikkuse vaatenurgast võib asja vaadata nii, et müük vastutab kliendikasumlikkuse ning turundus toote/brändikasumlikkuse eest. Kuidas seda täpsemalt hinnata selleni jõuame käesoleva kirjatüki lõpus.
Vaatame siis lähemalt müüki, mis oma olemuselt on lihtne protsess (mitte segi ajada sellega, et müüa on lihtne, lihtsalt müügiprotsessis ei ole väga palju kulukäitumiselt erinevaid osi) . Müügiprotsessi võib jagada põhimõtteliselt kaheks – klientidega seotud tegevused (uute klientide otsimine, olemasolevate haldamine) ning konkreetsete müügitehingute, s.t. mingi toote või teenuse kliendile müümine, läbiviimine. Meie eesmärgiks on leida kuluobjektid, mis peaksid siis olema kulude jagamise lõpp-punktid tagades samas kulude jaotumisel ja kasumlikkuse hindamisel põhjus-tagajärg loogika järgimise. Ei ole just väga keeruline mõista, et kaks põhimõtteliselt erinevat müügitegevuse valdkonda peaks omama ka erinevat tüüpi kuluobjekte – konkreetsete müügitehingute juures on peamiseks kuluobjektiks toode (selleomahind), millele lisandub tehingu (kanali)kuluobjekt. Klientide leidmise ja haldamise protsessis ei saa me kuidagi kasutada toodet kuluobjektina, sest toode lihtsalt ei puutu asjasse, mitmetes valdkondades võib kliendihaldus, mis ei ole seotud konkreetse müügitegevusega moodustada väga suure osa kogu müügimeeskonna tegevusest ning sellega seotud kulude sidumine konkreetese toodetega ei oma mingit põhjus-tagajärg seost. Müügist saame seega vähemalt kaks kuluobjektide liiki – toode (omahind) ja klient.
Turundus (sh ka tootearendus) on oma olemuselt väga selgelt tootevaatele orienteeritud, kuid natuke lisab keerukust asjadele see, et vähemalt osaliselt ei ole tegevused seostatavad ühe konkreetese tootega, vaid pigem mingi tooterühmaga - olgu siis selleks ühe brändi või tooterühma alla kuuluvad tooted. Peamiseks küsimuseks turunduskuludele kuluobjekti leidmisel on küsimus, kas need kulud peaksid sisalduma toote omahinnas, milleks meil on ju kuluobjekt juba olemas? Minu kindel seisukoht on see, et nö omahinna ja turundus-arenduskulude kuluobjektid peavad lahus olema, sest kõikide kulude koondamisel omahinna kuluobjekti alla läheme vastuollu otsustustoetuse tagamise printsiibiga – me ei saa enam aru, kas ja kui kasumlik on meie kliendisuhe (vt täpsemalt lõpus toodud näiteid erinevate kasumlikkuse vaadete osas). Turundusest seega kuluobjektid – Toode (arendus-turundus) ja vajadusel ka tooterühm/bränd, mis on sisuliselt mingite toodete koond.
Lisaks selgelt väärtust loovatele ehk siis kliendile suunatud tegevustele on igas organisatsioonis rida tegevusi, mis seotud organisatsiooni endaga ehk see nö tõeline üldkulu. Laias laastus võib need tegevused jagada kaheks – ühelt poolt haldustegevused ja teiselt poolt arendustegevused (suunatud organisatsiooni enda arendamisele, mitte toodete/kliendisuhte arendamisele). Taas peame küsima endalt küsimuse, miks ei sobi neid kulusid jagada juba leitud kuluobjektidele – olgu siis selleks toode, klient või kanal? Vastu on lihtne, nendel kuluobjektidel puudub põhjuslik seos organisatsiooni arendus- ja haldustegevusega ning otsustoetuse tagamiseks ei ole meil vaja muuta kunstlikult toote või teenuse omahinda, vaid mõista hinnastamisel kasumlikkuse nõuet, et tagada ka organisatsiooniga seotud tegevuste finantseerimise järgselt nõutud kasumlikkus. Organisatsioonist piisab ühest kuluobjektist organisatsiooni haldamine, oluline on ainult nende kulude eristamine väärtust loovatest kuludest.
Eelmised teemad käsitlesid kulude jagamiseks kasutatavaid kuluobjekte, kuid eeldusel , et meie kulumudel on ehitatud ‚pull˙ meetodit kasutades, on meil ka hulk kulusid, mis mudelis jagamata võivad jääda – kulud, mis on põhjustatud kasutamata ressurssidest. Juhul, kui soovime tagada võrdlusmomendi traditsioonilise finantsarvestusega (kasumiaruandega), siis peaksime ka need kulud kasumlikkuse hindamisel kaasama ning selleks kirjeldama nö pseudo-kuluobjekti – kasutamata ressurss. Kokku oleme saanud siis nelja liiki kuluobjekte:
Vaatame ühe näite varal, kuidas me neid erinevaid kuluobjekte kasumlikkuse analüüsimisel kasutame. Olgu meil tegemist lihtsa olukorraga, kus meil on kolm toodet, kaks klienti ja kaks kanalit, mõlemad kliendid on ostnud kõiki tooteid mõlemas kanalis ja meie eesmärgiks on hinnata nii toote-, kui kliendi- ja kanalikasumlikkust. Meie kasumlikkuse analüüsimiseks koostatud andmehulk võiks välja näha siis järgmine:
Tootekasumlikkuse vaates summeerime klientidele müüdud toodetest saadud tulu, millest lahutame toodete kulu omahinnas (toode/omahind kuluobjekt), mille tulemusel saame nö toote brutokasumlikkuse. Lahutades sellest toote turundamiseks ja arendamiseks tehtud kulud (Toode/arendus-turundus kuluobjekt, joonisel Toode1-(blank)), saame toote netokasumlikkuse. Siit peaks olema mõistatav ka omahinna ja arenduse-turunduse kuluobjektide lahususe vajadus, sest arenduse-turunduse kulud on oma iseloomult väga volatiilsed ning sageli vajab seisukoht nende põhjendatusest täpsemat analüüsi ning ümbervaatamise, mis aga ei mõjuta toote nö tootmisomahinda.
Kliendikasumlikkuse vaates summeerime klientidele müüdud toodetest saadud tulu, millest lahutame toodete kulu omahinnas (toode/omahind kuluobjekt), mille tulemusel saame nö kliendi brutokasumlikkuse. Lahutades sellest kliendi haldamiseks tehtud kulud (Klient kuluobjekt, joonisel Klient1-(blank)), saame toote netokasumlikkuse.
Sarnaselt toote- ja kliendikasumlikkusele saame hinnata kanalikasumlikkust. Kõikide kasumlikkuse vaadete juures on oluline mõista, et Toodete netokasum ≠ klientide netokasum ≠ kanalite netokasum, sest erinevad vaated koondavad kulud läbi erinevate kuluobjektide, kasutades just konkreetsele vaatele omast põhjus-tagajärg seost kulude tekkimisel. Samas tagab selline lähenemine meile põhilise eesmärgi saavutamise s.t. toe ostusteks ,millistega hinnastame tooteid klientidele (vajadusel erinevates kanalites), mõistes kulude tekkimist ning võimalusi efektiivsuse tõstmiseks (kasutamata ressursi kulude vähendamine).
Excel on hea töövahend, aga mitte ettevõtte planeerimisplatvormiks. Kaasaegne planeerimisprotsess peab olema kiire, paindlik ja võimeline muutustele kiiresti reageerima. Covid’i kriis ja Ukraina …
Juhtimisinfosüsteemi loomisel tekib sageli küsimus - kas lahendada iga ülesanne eraldi sobiva rakendusega, näiteks vajaliku aruande loome Power BI /Qlikview/Tableau abil otse algallikast, …