Društvo slovenskih informatikov 2012: Parabola leta softverskega podjetja

(ali kaj sva z matt-om ugotovila med dvema letališčema)

Andrej Mertelj, Matt Mayfield

Datalab d.d.

andrejm@datalab.si

Povzetek

Življenjski cikel softverskega podjetja najlažje opišemo z letom letala. Ob delovanju motorjev se pilot odloča med višino – številom uporabnikov(RGU=vrednostjo) ter hitrostjo (dobičkonosnostjo). V kolikor motorji (=novi uporabniki s sklenjeno pogodbo) ne zadoščajo več, se začne upad z določeno fineso: razmerjem med napredovanjem in zmanjševanjem višine (=vrednosti). Obstajajta dve značilni točki: maksimalna vrednost podjetja ter točka brez vrnitve. Dober inštrument za oceno stanja so »Licence pod pogodbo«.

Abstract

The software company lifecycle is best described as an airplane flight. Whilst the engine is running the pilot decides between altitude – number of revenue generaiing users – and speed (=profitability). When the engines (=users with upgrade contracts) are not sufficient enought to finance development, a decay starts. Much as a glider the plane descents from the sky with a certain angle of descent. There are two specific points in this path: maximum corporate value and the point of no return. A good instrument to show us where the company is are »Licences under contract«.

Ključne besede

Življenjski cikel, uporabniki, vrednost podjetja,

Key words

Company lifespan, users, corporate value

1.       OSNOVE SOFTVERSKE EKONOMIJE: PRIHODKI, VREDNOST,  STRUKTURA STROŠKOV

Vsako softversko podjetje se bori za uporabnike. Večje število prihodke generirajočih uporabnikov prinese ekonomijo obsega ter večje razvojne budgete, z njimi pa nenazadnje možnost gradnje dobre ekipe in uresničevanja ideje, ki je podjetje porodila.

Prihodke lahko v glavnem razdelimo na tri področja: licenčne, vzdrževalne in storitvene. Ker nas zanima izključno ekonomika razvojnega dela podjetja bomo slednjo zanemarili saj je tesno odvisna od prvih dveh. Modelov kako so porazdeljene je nešteto: vsem poznano je kupovanje licence & plačevanje letne »update« pristojbine – bodisi v obliki pogodbe bodisi v obliki »upgrade fee«.Med vzpenjajočimi je danes SaaS – derivat gornje klasike. Kjer je licenčnina porazdeljena na pričakovano dobo retencije uporabnika, ki skupaj z vzrdževalnino, opcijsko tudi datacenter in/ali SLA.

Število prihodkov generirajočih uporabnkov pa ne dviga le prihodkov ampak tudi rezidualno vrednost podjetja. Telekomi imajo npr. natančno razdelano, koliko je vredna ena stranka, en Revenue Generating Unit. Vrednost je običajno vezana na multiplo letne bruto marže na uporabnika (npr. 7x 120€ p.a. * 3000 RGU = 2,52M). Multipla zelo varira. Večja kot je rast uporabnikov in/ali potencial rasti, višja je. Bistveno pa nanjo vpliva hitrost odmiranja strank.

Stranke prihajajo in odhajajo. Nekaj jih gre, ker so nezadovoljne s storitvijo. Druge ker si je ne morejo privoščiti. Doleti jih bankrot ali pa jih nekdo kupi in integrira. Na hitrost odmiranja strank kot eksterni dejavnik vpliva gospodarska/splošna situacija, interni dejavnik pa je odvisen od kvalitete dela – beri vlaganj v boljšo kodo (izboljšave funkcionalnosti, sledenje tehnologiji, …) in boljšo storitev strankam. Na odmiranje strank vpliva tudi pričakovana bolečina menjave (stroški v podjetju, eksterni stroški-storitve & začasno povečani trasakcijski stroški) ter čas potreben za spremembe. Migracija uporabnikov iz MySpace na Facebook je bila hipna. Menjava SAP-a v korporaciji je nekajletni postopek. V kalkulaciji MySpace-a torej težko računaš multiplo z večletnim donosom, pri SAP-u zlahka.

Struktura stroškov softverskega podjetja je preprosta in uravnotežena: razvoj + strošek podpore + stroški prodaje + skupni stroški + pričakovana dividenda lastnika = prihodki + zunanji viri (krediti, subvencije, vc,…). Razvoj običajno tvori večino stroškov. Razlog za vlaganja v razvoj so dvojna:

  1. ohranjanje pomembne ozimnice – beri vzdrževalne pogodbe. Uporabnik bo za percepirano vrednost storitve pripravljen plačati zakonsko skladnost, tehnološki korak, nenazadnje za izboljšano funkckionalnost.
  2. Skrbi za dotok novih uporabnikov s konkurenčno ponudbo

Razporejanje stroškov vrši običajno lastnik, ki se odloča med reinvestiranjem, izplačilom dobička ali preusmeritvijo denarnega toka na alternativne projekte (npr. borze, gradbeništvo). Kakršna že bodi odločitev je le-ta popolnoma legitimna. Vendar pa zmanjševanje reinvestiranja v branži kot je IT vedno privede do zaostajanja, padca prirastka in hitrost odmiranja.

2.       ZAKAJ NAJU TEMATIKA ZANIMA

V Datalab-u trdno verjamemo, da je pot do uspeha v združevanju pameti, instalirane baze in drugih resursov (denarja, prodajne mreže, …). Zato se pogovarjamo s konkurenčnimi podjetji o tem kako vidijo trg in kako so se razvijali.

Za oceno, kje se podjetje nahaja v življenskem ciklu sva potrebovala enostavno orodje. Kjer so vhodni podatki le nekaj bistvenih številk oz. časovnih serij. Prejšnji dan smo globoko v noč diskutirali s kolegom iz Bolgarije, ki ga prepričujemo v sodelovanje. Koristna bi bila preglednica in graf, ki bi pokazal podjetju kje je zadnjih nekaj let in kam se giblje.

Debata, kako do nje,  začeta z Mattom na letališču v Sofiji se je dopolnila na prestopanju na Dunaju. Med letom sva razvila analogijo življenskega cikla softverskega podjetja z letalom. Gorivo so prihodki. Motor (reinvestiranje) ohranja hitrost gibanja (dobičkonosnost) in nabiranje višine (oziroma novih uporabnikov).  Če motor preneha letalo ne pade isti trenutek ampak drsi proti zemlji. Finesa – koliko kilometrov bo preletel z enega kilometra višine – je odvisno od njegovih lastnosti in spretnosti pilota. Enako softverske hiše običajno ne umrejo nenadno ampak sledijo paraboli. Boljši kot je tekoči razvoj (=uporabniki imajo rešene probleme) ter večja kot je »lock in« uporabnika, večja je finesa – počasnejše je propadanje.

Parabolo življenskega cikla podjetja najbolje odslikava število licenc pod vzdrževalno pogodbo. To nam kaže kolikšen delež uporabnikov, ki smo jim prodali/aktivirali/… licence je pripravljeno plačati za nadaljevanje njihove uporabe. Izračun tega je relativno preprost ko enkrat ločimo prihodke in stroške po skupinah in vemo, koliko nam nove verzije prinašajo vzdrževalnih prihodkov in koliko nas stane »core« razvoj (torej tisti razvoj, ki ga uporabniki ne plačajo za prilagajanje programske opreme svojim specifičnih problemom).

Težava je pri manjših, manj strukturiranih podjetjih, kjer sicer vedo za skupne prihodke, težko pa jih razdelijo. Ne vedo, kolikšen del prihodkov pripisati vzdrževanju, koliko pa npr. storitvam podpore uporabnikov.

Če torej narišemo te tri parametre na graf dobimo takole sliko

Graf 1: Življenski cikel softverskega podjetja

’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 plan
Lic pod Pog (LpP) €2.000.000 €2.300.000 €2.405.000 €2.294.250 €2.100.113 €1.985.096 €1.671.796 €1.091.796
Prodaja novih licenc €600.000 €450.000 €250.000 €150.000 €200.000 €220.000 €70.000 €20.000
Vrednost pogodb €300.000 €345.000 €360.750 €344.138 €315.017 €297.764 €250.769 €163.769
Zmanjšanje LpP €300.000 €345.000 €360.750 €344.138 €315.017 €533.300 €650.000 €650.000
Obnovitev pogodbe 85% 85% 85% 85% 85% 73% 61% 40%

Tabela 1: Podatki k gornjem grafu[1]

Analizirajmo tale fantazijski primer:

Med leti ’06 in ’10 je bila povprečna stopnja umiranja 15%. Prodajni peak novih licenc je sicer bil ’06 vendar je podjetje zadrževalo dovolj uporabnikov, da je bila rast neto pozitivna. Zato podjetje doseže največjo vrednost v letu 2088 četudi proda bistveno manj novih licenc in vrednost pogodb precej konstantna.  Podjetje kljub padajočim prihodkov nezmanjšano vlaga v razvoj. Uporabniki so zadovoljni, zato večinoma še vedno podaljšujejo pogodbe.

Od leta ’09 prirast ne pokriva naravne atrofije inttalirane baze tako da le-ta (in z njo absolutna vrednost Licenc pod Pogodbo)  ter vrednost podjetja manjšata. V podjetju se običajno zbudi samozaščitniški refleks in začne pospešeno vlagati v prodajo.

Med letom ’09 in ’10 je potrebno zmanjšati stroške razvoja in zaradi tega naraste procent atrofiranja strank oz. se zmanjša število obnovljenih pogodb (renewal rate). V letu 10 in ’11 se to skoraj ne opazi, saj zaradi lokalnega maksimuma prodaje novim (posledica marketing aktivnosti) podjetje razpolaga z dovoljšnjo likvidnostjo ki zakrije take bistvene podakte.

Med točko najvišje vrednosti in točko brez vrnitve je obdobje, ko so potrebne spremembe. Opcije so tri:

  1. zagotovitev povečanih razvojnih budgetov za restart procesa, ki naj spet napolni gorivo in požene motor. Za razvoj lahko porabimo bodisi preteklo akumulacijo, »prijaznega« novega kupca ki razvoj financira ali pa zunanje vire (dolžniški ali lastniški kapital)
  2. prodaja dejavnosti ali dela dejavnosti. Če sredstev za nadaljni razvoj ni mogoče zagotoviti potem je najbolj pametno zmanjševati lastniško izgubo. Ker je podjetje še zdravo in uporabniki lojalni (pri njih ima podjetje še vedno spoštovanje in željo po sodelovanju) je rezidualna vrednost podjetja precejšnja in s tem multipli višji. Bolj ko se odmikamo od točke maksimalne vrednosti, manj je uporabnikov, so manj vredni (=bolj jih bo potrebno prepričevati da storitve kupujejo od prevzemnika) in posledično je jasno tudi nižja vrednost podjetja oziroma multipli.
  3. Lemming reakcija: ni reakcije, korakamo naprej, poslovodstvo dela sporadične in pogosto škodljive aktivnosti (na primer diskontiranje novih licenc za dvig števila uporabnikov ob hkratnem zmanjšanju hitrosti/dobičkonosnosti). Podjetje koraka po svoji poti do točke brez povratka.

Strmoglavljenje prihodkov od novih uporabnikov s hkratnim povečanjem strank, ki se za podljšanje softvera ne odločijo, tvori zoprno komnbinacicjo dvojnega pritiska zmanjšanja prihodkov in  s tem tudi pokrivanja stroškov razvoja. To je točka brez vrnitve, ko vemo da bo dotik zemlje neizbežen. Od te točke naprej se lahko pilot odloča le, ali nadaljuje z letenjem in poiskuša zasilni pristanek ali  skoči s padalom. Vsekakor pa letalo ne bo nepoškodovano in vzročno je cena podjetja ki jo lastniki lahko pričakujejo zanemarljiva.

 

VIRI IN LITERATURA

  • Ni uporabljenih virov in literature.

 

[1]  Zeleno obarvani podatki so zajeti z anketo, zadnji dve vrstici preračunani

1 thought on “Društvo slovenskih informatikov 2012: Parabola leta softverskega podjetja”

Leave a Comment