U mnogim rastućim tvrtkama operativni problemi se u ranoj fazi ne uočavaju kao budući izazovi. Procesi i dalje funkcioniraju, timovi isporučuju rezultate, a rast često prikriva operativnu napetost koja se postupno ugrađuje kao dio sustava.
Ono što najčešće ostaje nevidljivo jest način na koji softver i operativni sustavi počinju oblikovati svakodnevno izvršavanje posla unutar organizacije. Kako se broj pomoćnih alata povećava, i procesi postaju sve više raspršeni, male neefikasnosti počinju se akumulirati prolazeći ispod radara. One u početku ne narušavaju sustav, ali s vremenom utječu na njegovu brzinu, konzistentnost i pouzdanost.
Ti se obrasci pojavljuju u različitim oblicima. Ono što na prvi pogled izgleda kao posljedica brzog rasta često je zapravo rezultat načina na koji su softverski sustavi oblikovani i kako informacije putuju između odjela. Problem je što se takve neefikasnosti rijetko povezuju sa softverom. Češće se pripisuju ljudima, rastu poslovanja ili povećanom opsegu posla, dok pravi uzrok ostaje skriven u svakodnevnim procesima.
Takvu smo situaciju susreli tijekom razvoja platforme Officium WasteManager. Na početku su operativni procesi izgledali dovoljno jednostavno da ih podrži jedinstveni sustav. Tek kroz suradnju s korisnicima postalo je jasno da različiti odjeli isti posao obavljaju na različite načine, koriste dodatne provjere i primjenjuju lokalna pravila koja nisu bila dio početne dokumentacije. Da su ti procesi ostali neotkriveni, zaposlenici bi ih nakon implementacije nastavili rješavati kroz Excel tablice, telefonske pozive ili interne poruke, čime bi nastao upravo onaj oblik operativne neefikasnosti koji je najteže uočiti.
U nastavku članka prolazimo kroz najčešće obrasce takvih situacija, od svakodnevnih operativnih neefikasnosti i problema sa skaliranjem do nekonzistentnosti podataka, zastoja sustava i dugoročnih troškova njihove ponovne izgradnje.
U mnogim rastućim tvrtkama operativne neefikasnosti rijetko se pojavljuju kao jedinstven jasno vidljiv problem. Najčešće nastaju postupno kroz svakodnevne poslovne procese. Timovi s vremenom prestanu propitivati, i neefikasnosti se ugrade u radne obrasce. Zaposlenici počinju ponavljati iste administrativne zadatke kroz više sustava. Podaci se ručno prebacuju između odjela ili koriste tablice i interne poruke kako bi se nadoknadila ograničenja softvera koji ne prati stvarni tempo poslovanja.
Takve situacije u početku djeluju beznačajno. Tim skladišta ručno usklađuje narudžbe između ERP sustava i dostavnih platformi, korisnička podrška provjerava status kupca kroz nekoliko različitih aplikacija prije nego što odgovori na jednostavan upit, dok financije izvoze podatke u Excel kako bi provjerile jesu li izvještaji međusobno usklađeni. Svaka od tih aktivnosti traje svega nekoliko minuta, ali kada ih svakodnevno ponavljaju deseci zaposlenika, privremeni zaobilazni proces postaje standardni način rada. Operativna neefikasnost tada više nije iznimka, već sastavni dio poslovnog procesa.
Takve situacije nastaju kada poslovanje raste brže nego što rastu njegovi operativni procesi i sustavi. Svaki odjel pokušava riješiti vlastiti problem što je moguće brže. Prodaja uvodi jedan alat, korisnička podrška drugi, financije treći, a operativni timovi razvijaju vlastite tablice i interne procedure. Svako od tih rješenja pojedinačno ima smisla, ali zajedno stvaraju poslovni sustav u kojem informacije više ne putuju jednim standardiziranim putem.
Upravo zato management rijetko vidi jedan veliki trošak. Umjesto toga pojavljuju se deseci malih zastoja tijekom svakodnevnog rada. Zaposlenici čekaju informacije iz drugih odjela, ručno uspoređuju podatke ili ponavljaju iste radnje u više različitih sustava. Stvarni trošak više nije cijena softvera, nego vrijeme koje organizacija svakodnevno gubi kako bi održala procese usklađenima.
U tvrtkama koje brzo povećavaju broj klijenata ili internih operacija, ovaj obrazac se najčešće počinje jasno osjećati unutar prvih 6 do 12 mjeseci rasta. Efekt se pojačava kada fokus ostane na brzini širenja umjesto na stabilizaciji operativne strukture. U ovoj fazi fragmentacija operativnih procesa više nije nuspojava. Ona postaje stvarna struktura kroz koju se rad koordinira, izvršava i validira unutar organizacije.
U mnogim tvrtkama tehnički dug se ne pojavljuje kao svjesna poslovna odluka, nego kao rezultat niza malih poslovnih kompromisa, donesenih pod pritiskom rasta. Kada se nova funkcionalnost mora isporučiti brzo, sustavi se proširuju postojećim rješenjima.
S vremenom uvođenje promjena teče sve sporije te je veći operativni napor potreban da bi sustavi ostali stabilni. Timovi sve češće rade oko sustava, umjesto unutar njega. Održavanje postaje stalni dio rada, a ne zasebna tehnička funkcija.
Više o tome kako tehnički dug nastaje kroz razvojne odluke i zašto se akumulira kroz vrijeme može se pročitati na našem blogu razvoj softvera: skriveni trošak jeftinih odluka.
U mnogim tvrtkama problemi sa skalabilnošću nisu vidljivi u ranoj fazi poslovanja, već tek kada volumen operacija počne rasti brže nego što ga sustavi mogu pratiti. Ono što je ranije funkcioniralo počinje pokazivati ograničenja u svakodnevnim procesima. Oni postaju sporiji i znatno zahtjevniji za koordinaciju. U tom trenutku sustavi koji su podržavali manji opseg poslovanja više ne mogu održati isti tempo rada bez dodatnih intervencija.
Kako se poslovanje širi, postojeći softverski sustavi često ne prate način na koji se operacije odvijaju. Timovi počinju uvoditi dodatne korake i zaobilazna rješenja kako bi održali kontinuitet u radu. Informacije se sve češće prenose između odjela izvan centralnih tokova. Koordinacija postaje složenija, operacije se više ne odvijaju u jednom usklađenom sustavu. Rast više ne donosi samo povećanje poslovnih aktivnosti, nego i proporcionalno povećanje operativne kompleksnosti koja usporava daljnji rad.
U rastućim tvrtkama podaci prestaju biti jedinstven izvor istine onog trenutka kada se poslovanje počne oslanjati na više paralelnih sustava koji nisu u potpunosti povezani. Informacije o klijentima i narudžbama počinju se nalaziti na različitim mjestima, s različitim skupovima informacija. U početku te razlike nisu vidljive jer se odluke i dalje donose brzo, međutim kako volumen poslovanja raste, postaje sve teže uskladiti informacije koje dolaze iz različitih izvora.
Korisnik radi narudžbu i status se ažurira u CRM sustavu. Istodobno, narudžba se vodi u ERP sustavu s drugačijim podacima. Korisnička podrška pak provjerava status narudžbe kroz zaseban alat prije odgovora klijentu. Rezultat svega je da nijedan sustav ne pokazuje u potpunosti točne podatke.
Sustavi se dalje razvijaju bez jedinstvene strukture, a reporting postaje sve manje pouzdan. Timovi počinju ručno uspoređivati podatke iz različitih alata izvan centralnog sistema kako bi dobili sliku stvarnog stanja poslovanja, što troši dodatno vrijeme i povećava složenost procesa odlučivanja.
Management tada više ne donosi odluke na temelju jednog jasnog seta podataka, nego na temelju više interpretacija koje ovise o tome iz kojeg sustava informacije dolaze. To postupno smanjuje kredibilitet podataka. Odluke se počinju donositi sporije, i s većim stupnjem opreza. U skalirajućoj fazi poslovanja to dovodi do situacija da različiti dijelovi organizacije imaju različitu sliku iste realnosti. Rizik od pogrešnih poslovnih poteza se povećava, dok se brzina operativne reakcije tvrtke smanjuje. Situacija više nije izolirani problem konzistentnosti podataka, već postaje strukturni problem u poslovanju. Različiti dijelovi organizacije počinju operirati na temelju različitih interpretacija iste poslovne realnosti.
U nekim tvrtkama downtime se ne doživljava kao tehnički incident, nego kao iznenadni prekid poslovanja. Sustavi koji su inače neprimjetan dio rada odjednom prestaju funkcionirati. Timovi time gube pristup ključnim informacijama potrebnim za izvršavanje osnovnih zadataka. U tom trenutku poslovanje se jednostavno prekida, dok se sustavi ponovno ne stabiliziraju.
Takve situacije najčešće nastaju zbog pojedinačnih točaka ovisnosti unutar softverskog sustava. Kada jedan od elemenata prestane raditi, cijeli lanac poslovnih procesa može stati. Posljedica nije samo tehnički prekid, nego direktan utjecaj na prihode i operativnu izvedbu. Također, korisnička podrška je pod povećanim opterećenjem u kratkom vremenu zbog nagomilanih zahtjeva koji se eksponencijalno povećavaju.
U fazi rasta ovakvi događaji dolaze nepredvidivo. Relacija između brzine razvoja sustava i njihove otpornosti postaje ključni trade-off koji dugoročno određuje stabilnost poslovanja. Način na koji je postavljena softverska arhitektura, gdje jedan dio sustava može zaustaviti cijeli poslovni tok, postaje ključan faktor stabilnosti poslovanja.
U nekim tvrtkama potreba za ponovnim pisanjem sustava posljedica je dugotrajnog akumuliranja problema koji se više ne mogu rješavati pojedinačnim intervencijama. Sustavi koji su godinama održavani kroz manja prilagođavanja i privremena rješenja s vremenom dolaze do točke pucanja u kojoj svaka nova promjena postaje nesrazmjerno kompleksna. U tom trenutku poslovanje se više ne može nastaviti na istim temeljima.
Kako se tehnički dug akumulirao kroz vrijeme, postojeći sustavi gube sposobnost daljnjeg stabilnog razvoja. Poduzeća tada dolaze do odluke o ponovnoj izgradnji ključnih dijelova sustava. Takve odluke najčešće dolaze nakon razdoblja u kojem su se problemi pokušavali rješavati kroz parcijalne intervencije. Rezultat svega su veliki kapitalni troškovi, gubitak kontinuiteta i značajno usporavanje poslovnih procesa u fazi tranzicije. U praksi se to najčešće događa kada razlika između kratkoročnih ušteda i dugoročne održivosti sustava postane prevelika da bi se i dalje ignorirala. Tada odluka o rekonstrukciji više nije pitanje optimizacije, vec nadolazeća realnost.
Pročitajte više o tome kako izbor softverskih partnera i loša vendor iskustva mogu postati jedan od izvora ovih problema na našem blogu pogreške pri odabiru softver partnera.
Većina troškova koji su opisani u ovom članku rijetko se pojavljuje kao izolirani incident. Oni se ugrađuju postupno kroz svakodnevne operacije, kroz male odluke koje u trenutku djeluju opravdano, ali s vremenom stvaraju strukturne neefikasnosti.
Ono što se u praksi često vidi kao sporiji procesi, nekonzistentni podaci, problemi sa skaliranjem ili operativna nestabilnost rijetko je skup odvojenih problema. To je posljedica načina na koji softverski sustavi oblikuju svakodnevni rad organizacije.
Budući da se ovi učinci razvijaju postupno, često se pogrešno interpretiraju. Timovi ih najčešće pripisuju ljudima ili pritisku rasta, ne prepoznaju da proizlaze iz načina na koji su kreairani softverski sustavi.
Softver nije samo alat koji podržava operacije. On postaje dio operativne infrastrukture. Zato njegova kvaliteta izravno utječe na učinkovitost izvršavanja standardnih procesa rada, skaliranja i donošenja odluka.
Ako se ova tema odnosi na projekt koji planirate, možete nam se javiti izravno ili proći kroz project estimation flow za strukturiranu prvu procjenu.
