Kiekviena verslo sistema turi gyvavimo ciklą. Tą dieną, kai ji buvo įdiegta, ji sprendė realias problemas, pagreitino procesus ir leido įmonei dirbti efektyviau. Bet verslas nėra statiškas. Jis auga, keičiasi, prisitaiko prie rinkos. Ir kažkuriuo momentu ta pati sistema, kuri kadaise buvo varomoji jėga, tampa stabdžiu.
Problema ta, kad šis pokytis nevyksta per vieną dieną. Tai lėtas, palaipsnis procesas, kaip varlė, lėtai šildoma vandenyje. Darbuotojai pripranta prie nepatogumų. Vadovai priima tai kaip „normalų darbo ritmą”. Ir tik kai konkurentas aplenkia, stambus klientas išeina arba verslo plėtra sustoja, ateina suvokimas: sistema seniai nebetarnauja verslui, verslas tarnauja sistemai.
Šiame straipsnyje aptarsime 12 konkrečių signalų, rodančių, kad jūsų dabartinė sistema tapo augimo kliūtimi, paaiškinsime, kodėl įmonės dažnai reaguoja per vėlai, ir pateiksime praktinį veiksmų planą.
Kodėl sistemos „sensta” greičiau nei tikimasi?
Prieš gilindamiesi į simptomus, verta suprasti priežastis. Verslo sistema gali tapti nebeaktuali dėl kelių veiksnių, ir dažniausiai jie veikia vienu metu:
Verslas augo, sistema ne. Kai įmonė turėjo 10 darbuotojų ir 200 užsakymų per mėnesį, Excel lentelė arba paprasta programa puikiai atliko savo darbą. Dabar darbuotojų 80, užsakymų 5 000, o sistema ta pati. Ji nebuvo suprojektuota tokiam krūviui, tokiam sudėtingumui, tokiam greičiui.
Rinka pasikeitė. Atsirado naujų kanalų (e. komercija, socialiniai tinklai, savitarnos portalai), naujų reguliacinių reikalavimų (BDAR, e. sąskaitos), naujų klientų lūkesčių (realaus laiko sekimas, personalizacija). Senoji sistema apie tai nieko nežino.
Technologijos pažengė. Debesų kompiuterija, dirbtinis intelektas, automatizacija, mobiliosios platformos, tai nebe ateities vizijos, o kasdieniai įrankiai. Jei jūsų sistema nesuderinama su šiomis technologijomis, jūs praleidžiate galimybes, kurias jūsų konkurentai jau naudoja.
Technologinė skola kaupėsi. Kiekvienas „laikinas” sprendimas, kiekvienas „greitas taisymas”, kiekvienas atidėtas atnaujinimas pridėjo sluoksnį techninės skolos. Po penkerių ar dešimties metų sistema primena namą, kuriame kiekvienas kambarys pristatytas skirtingu metu, skirtingo architekto, iš skirtingų medžiagų.
1 signalas: darbuotojai dubliuoja darbą keliose sistemose
Tai vienas ankstyviausių ir ryškiausių signalų. Darbuotojas įveda kliento užsakymą į vieną sistemą, paskui rankiniu būdu perkelia duomenis į apskaitos programą, tada atnaujina sandėlio lentelę, o galiausiai nusiunčia informaciją kolegai el. paštu.
Tas pats duomuo vedamas 2, 3, kartais 4 kartus į skirtingas vietas.
Ką tai kainuoja:
- Laikas. Jei darbuotojas skiria 45 minutes per dieną dubliuotam darbui, per metus tai yra beveik 200 darbo valandų. Padauginkite iš darbuotojų skaičiaus ir valandinio įkainio.
- Klaidos. Kiekvienas rankinis perkėlimas yra galimybė suklysti. Skaičius nukopijuotas neteisingai, laukas pamirštas, versija nesutampa. Šios klaidos plinta per visas sistemas ir jas surasti tampa vis sunkiau.
- Motyvacija. Niekas nenori daryti darbo, kuris akivaizdžiai turėtų būti automatizuotas. Darbuotojai jaučiasi kaip „žmogiškoji integracija” tarp sistemų, o tai kelia frustraciją ir mažina įsitraukimą.
Realaus verslo scena: logistikos įmonės vadybininkė kiekvieną rytą praleidžia pusantros valandos perkeldama naktinių užsakymų duomenis iš el. pašto į valdymo sistemą, paskui į vairuotojų grafiką, paskui į apskaitos programą. Ji daro tai penkerius metus. Kai kas nors paklausia, kodėl, ji atsako: „Nes sistemos tarpusavyje nekalba.”
2 signalas: ataskaitos reikalauja herojiškų pastangų
Vadovas nori žinoti, koks mėnesio pelningumas pagal produktų kategorijas. Paprastas klausimas, bet atsakymui gauti reikia:
- Eksportuoti pardavimų duomenis iš vienos sistemos
- Eksportuoti savikainų duomenis iš kitos
- Sujungti juos Excel lentelėje
- Rankiniu būdu patikslinti duomenis, nes kategorijų pavadinimai nesutampa
- Sukurti diagramą
- Nusiųsti vadovui, kuris gauna ataskaitą kitą dieną (o ne tada, kai jam reikia)
Jei ataskaitai gauti reikia daugiau nei kelių paspaudimų, tai signalas. Šiuolaikiniame versle sprendimai priimami greitai, ir informacija turi būti prieinama realiu laiku, o ne po dviejų dienų rankinio darbo.
Ko tai stoka verslui:
- Vadovai priima sprendimus remiantis pasenusia arba netikslia informacija
- Galimybės praleidžiamos, nes reakcijos laikas per ilgas
- Analitikos kokybė priklauso nuo vieno žmogaus, kuris „žino, kaip sutvarkyti tą Excel failą”
- Kai tas žmogus atostogauja arba išeina, ataskaitos proceso niekas negali pakartoti
3 signalas: nauji darbuotojai mokosi mėnesiais, ne savaitėmis
Kai naujam darbuotojui prireikia trijų mėnesių, kol jis pradeda savarankiškai dirbti su sistema, problema ne darbuotojuje. Problema sistemoje.
Sudėtingos, neintuityvios, laikui bėgant „užlopinėtos” sistemos reikalauja institucinio žinojimo, kuris neužrašytas jokiame vadove. „Šitą mygtuką spausti nereikia, nors jis ten yra.” „Šitą lauką visada pildyk taip, nors sistema leidžia kitaip.” „Šitos ataskaitos skaičiai neteisingi, visada pridėk 3 %.”
Kas nuo to nukenčia:
- Naujų darbuotojų produktyvumas smarkiai vėluoja
- Mokymai kainuoja: ir tiesiogiai (mokytojų laikas), ir netiesiogiai (naujokas daro klaidas)
- Darbuotojų kaita tampa skaudesnė, nes kiekvienas išėjęs žmogus nusineša „paslėptas žinias”
- Įmonė tampa priklausoma nuo kelių „sistemos veteranų”, be kurių darbas stoja
4 signalas: klientai gauna lėtesnį aptarnavimą nei tikisi
Šiandieninis klientas yra pripratęs prie greičio. Jis nori matyti užsakymo statusą realiu laiku. Jis tikisi, kad klientų aptarnavimo specialistas iškart matys visą jo istoriją. Jis nori gauti sąskaitą per sekundes, ne per dienas.
Jei jūsų sistema to neleidžia, klientas to nejaus kaip „IT problemą”. Jis jaus kaip prastą aptarnavimą. Ir eis ten, kur aptarnauja greičiau.
Signalai iš klientų pusės:
- „Kodėl negaliu matyti savo užsakymo statuso internetu?”
- „Aš jau skambinau vakar ir paaiškinau situaciją. Kodėl turiu aiškinti iš naujo?”
- „Sąskaitą gavau po savaitės. Pas konkurentus gaunu iškart.”
- „Jūsų svetainėje rodo, kad prekė yra, bet kai užsakiau, paaiškėjo, kad nėra.”
Kiekvienas toks komentaras yra ne šiaip nusiskundimas. Tai simptomas, kad jūsų vidinės sistemos nebesuteikia darbuotojams galimybės aptarnauti klientus taip, kaip rinka reikalauja.
5 signalas: sistema neišlaiko apkrovos piko metu
Verslas turi natūralius piko laikotarpius. Mažmeninei prekybai tai gruodis. Turizmo verslui, vasara. B2B paslaugoms, ketvirčio pabaiga.
Jei sistema lėtėja, stringa arba tiesiog nebeatlaikys apkrovos būtent tuo metu, kai pardavimai turėtų būti didžiausi, nuostoliai yra tiesioginiai ir lengvai apskaičiuojami.
Tipiniai simptomai:
- Sistema „pakimba” piko valandomis, darbuotojai laukia po 30–60 sekundžių, kol įkraunamas puslapis
- Užsakymų apdorojimas sulėtėja, susidarys eilė
- Sistema pati nutraukia sesiją dėl perpildymo
- IT komanda turi „rankinio reguliavimo” ritualus: „prieš piko savaitę išjunkite visas ataskaitas, kad sistema neapkrautų”
Kai verslas praranda pardavimus dėl techninių apribojimų, tai jau ne IT problema. Tai verslo problema.
6 signalas: integracija su naujais įrankiais neįmanoma arba kainuoja turtus
Šiuolaikinis verslas naudoja dešimtis skirtingų įrankių: el. pašto rinkodaros platformas, e. komercijos sistemas, mokėjimų tarpininkus, siuntų tarnybų API, analitikos įrankius, klientų aptarnavimo platformas.
Jei jūsų dabartinė sistema neturi atviros API, naudoja pasenusius duomenų mainų formatus arba kiekviena integracija reikalauja individualaus programavimo už tūkstančius eurų, tai rimtas stabdys.
Konkretūs pavyzdžiai:
- Norite prijungti naują mokėjimo būdą (pvz., „Apple Pay” ar „Buy Now Pay Later”), bet sistema nepalaiko reikalingo protokolo
- Rinkodaros komanda nori automatiškai perkelti kontaktus iš CRM į el. pašto platformą, bet vienintelis būdas yra rankinis CSV eksportas kas savaitę
- Naujas sandėlio partneris naudoja EDI standartą, kurio jūsų sistema nesupranta, todėl kiekvienas užsakymas perduodamas telefonu
- Norite prijungti chatbot’ą ar savitarnos portalą, bet sistema neturi galimybės dalintis duomenimis su išorinėmis aplikacijomis
Kiekviena tokia „neįmanoma integracija” yra prarasta galimybė automatizuoti, pagreitinti ar pagerinti procesą.
7 signalas: IT komanda tik „gaisrus gesina”
Pažvelkite, ką daro jūsų IT žmonės (arba IT partneris). Jei 80 % jų laiko skiriama esamų problemų taisymui, o tik 20 % (ar mažiau) naujų galimybių kūrimui, sistema jau seniai perėjo savo geriausią laikotarpį.
Kaip tai atrodo praktikoje:
- Kiekvieną pirmadienį IT komanda gauna sąrašą dalykų, kurie „sugedo per savaitgalį”
- Tos pačios klaidos kartojasi kas kelias savaites, bet niekada nėra galutinai ištaisomos, nes sistemos architektūra neleidžia
- IT specialistai bijo liesti tam tikras sistemos dalis, nes „jei ką nors pakeisi, sugriūna kažkas kitas”
- Atnaujinimai atidėliojami, nes rizika, kad kas nors nustos veikti, per didelė
- Naujo funkcionalumo prašymai stovi eilėje mėnesiais, nes visa energija eina į palaikymą
Kai IT komanda tampa „gaisrine”, o ne inovacijų varikliu, tai reiškia, kad technologinė skola pasiekė kritinį lygį.
8 signalas: verslo procesai pritaikomi prie sistemos, o ne atvirkščiai
Šis signalas dažnai yra pats klastingiausias, nes jis maskuojasi kaip „normalus darbas”.
Verslo logika turėtų diktuoti, kaip sistema veikia. Bet kai sistema pasensta, vyksta atvirkštinis procesas: žmonės keičia savo darbo būdą, kad tilptų į sistemos apribojimus.
Atpažinimo ženklai:
- „Mes nedarome to taip, nes sistema neleidžia” (nors tai būtų geresnis būdas)
- „Šitą procesą atliekame ne per sistemą, o per Excel/el. paštą/popierių” (nes sistema to nepalaiko)
- „Mes negalime pasiūlyti klientams tokios paslaugos, nes sistema neapdoros” (prarastos pajamos)
- „Turime specialų žmogų, kuris tai tvarko rankiniu būdu” (papildomas etat, kurio neturėtų reikėti)
- „Žinome, kad tai neefektyvu, bet kitaip sistema neveikia” (rezignacija)
Kai įmonė pradeda riboti savo galimybes dėl sistemos apribojimų, augimas sustoja. Ne todėl, kad rinkoje nėra galimybių, o todėl, kad sistema neleidžia jomis pasinaudoti.
9 signalas: saugumo spragai kelia vis didesnę riziką
Senesnės sistemos dažnai neatitinka šiandieninių saugumo standartų. Tai ne tik techninė problema, tai verslo rizika, kuri gali kainuoti ne tik pinigus, bet ir reputaciją.
Konkretūs pavojaus signalai:
- Sistema veikia ant operacinės sistemos ar duomenų bazės versijos, kuri nebegauna saugumo atnaujinimų
- Nėra dviejų faktorių autentifikacijos galimybės
- Naudotojų prieigos teisės valdomos primityviai (visi mato viską arba prieigos valdymas reikalauja IT specialisto įsikišimo kiekvieną kartą)
- Duomenys saugomi nešifruotu formatu
- Nėra automatinio audito žurnalo, kas ką darė sistemoje
- Sistema neatitinka BDAR ar kitų reguliacinių reikalavimų, ir pritaikyti ją yra per brangu arba techniškai neįmanoma
BDAR pažeidimo baudos gali siekti iki 20 mln. eurų arba 4 % metinės apyvartos. Kibernetinės atakos vidutinė kaina smulkiam ir vidutiniam verslui Europoje siekia dešimtis tūkstančių eurų, neįskaitant reputacijos žalos. Senoji sistema, kurios niekas nebeatnaujina, yra atviros durys šioms rizikoms.
10 signalas: tiekėjas nebepalaiko jūsų sistemos versijos
Ši situacija turi aiškų ir nedviprasmišką poveikį: jei sistemos tiekėjas paskelbė, kad jūsų naudojama versija nebegaus atnaujinimų (End of Life), jūs stovite ant laikrodžio.
Ką reiškia nutrauktas palaikymas:
- Saugumo spragos nebus taisomos, net jei bus aptiktos
- Naujų operacinių sistemų, naršyklių ar trečiųjų šalių įrankių suderinamumas nebegarantuojamas
- Techninė pagalba nebeteikiama arba teikiama už ženkliai didesnę kainą
- Jei sistema sugrius, taisyti ją gali tekti samdant rinkoje vis rečiau randamus specialistus
Realaus verslo pasekmės: įmonė naudoja ERP sistemą, kurios versija nebeatnaujinama nuo 2019 metų. Kai nauja Windows versija sukėlė suderinamumo problemą, sprendimo nebuvo. Įmonė turėjo laikyti senus kompiuterius su sena operacine sistema vien tam, kad sistema veiktų. Kai vienas iš tų kompiuterių sugedo, dviejų dienų darbas buvo paralyžiuotas.
11 signalas: talentai atsisako dirbti su pasenusia technologija
Šis signalas dažnai ignoruojamas, nes jis atrodo „minkštas” ir sunkiai išmatuojamas. Bet jo poveikis yra labai konkretus.
IT specialistai ir technologijas naudojantys darbuotojai renkasi darbdavius pagal tai, su kokiais įrankiais dirbs. Pasenusios, nepatogios sistemos yra atgrasymas:
- Programuotojai nenori prižiūrėti kodo, parašyto technologijomis, kurios jau senokai yra „mirusios”
- Pardavimų vadybininkai, pripratę prie modernių CRM su mobiliąja versija, nenori grįžti prie darbalaukio sistemos iš 2010-ųjų
- Jauni specialistai, kurie augo su šiuolaikiniais įrankiais, nesupranta, kodėl turi dirbti su sąsaja, primenančia praėjusio dešimtmečio programinę įrangą
Jei pokalbių su kandidatais metu vis girdite „o su kokia sistema dirbsite?”, o po atsakymo matote entuziazmą blėstant, tai signalas, kad technologijos trukdo ne tik procesams, bet ir žmonių pritraukimui.
12 signalas: pokyčiai užtrunka neproporcingai ilgai
Paskutinis, bet galbūt svarbiausias signalas. Verslo aplinka keičiasi greitai: nauji reguliaciniai reikalavimai, nauji klientų segmentai, nauji pardavimo kanalai, nauji partneriai, sezoninės akcijos, naujų produktų linijos.
Kiekvienas toks pokytis reikalauja sistemos pritaikymo. Ir jei „pridėti naują mokėjimo būdą” užtrunka 3 mėnesius, „sukurti naują ataskaitą” reikalauja IT specialisto darbo savaitei, o „prijungti naują sandėlį” yra pusės metų projektas, jūsų sistema tapo grandine, prie kurios prikaustytas verslas.
Kaip įvertinti:
Užduokite sau klausimą: jei rytoj atsirastų galimybė pradėti pardavimus naujoje rinkoje arba pasiūlyti naują paslaugą, ar jūsų sistema leistų tai padaryti per savaites? Ar tai reikštų mėnesius darbo ir papildomą biudžetą?
Jei atsakymas yra antrasis variantas, sistema yra augimo stabdys.
Kodėl įmonės reaguoja per vėlai?
Nors signalai aiškūs, daugelis įmonių atidėlioja sprendimą. Tam yra kelios psichologinės ir organizacinės priežastys:
„Veikia, nekeisk” mentalitetas. Kol sistema formaliai veikia (t. y. neužlūžta visiškai), žmonės vengia pokyčių. „Turime svarbesnių reikalų” arba „ne dabar, gal kitais metais” yra frazės, kurios kartojamos, kol situacija tampa kritiška.
Prigimtinis pasipriešinimas pokyčiams. Keitimas reiškia mokymąsi iš naujo, laikinus nepatogumus, riziką. Ir vadovai, ir darbuotojai instinktyviai renkasi žinomą nepatogumą, o ne nežinomą pokyti.
Sąnaudų klaidingas vertinimas. Žmonės mato naujos sistemos kainą (dešimtys tūkstančių eurų), bet nemato dabartinės sistemos kainoš: prarastas laikas, prarastos galimybės, prarasti klientai, darbuotojų frustracija. Šios paslėptos išlaidos dažnai viršija bet kokią diegimo investiciją.
„Mes jau tiek investavome” efektas. Psichologinis šališkumas, vadinamas „negrąžintinų kaštų klaida” (sunk cost fallacy). „Mes jau investavome 100 000 eurų į šią sistemą, negalime jos tiesiog pakeisti.” Bet pradinė investicija jau padaryta ir negrąžinama, nepriklausomai nuo to, ar sistema keičiama, ar ne. Sprendimas turėtų remtis ateities verte, ne praeities išlaidomis.
Trūksta „savininko”. IT sistemos keitimas nepriklauso nė vienam skyriui. Tai per didelis sprendimas pardavimų vadovui, per „netechniškas” finansų direktoriui ir per „neverslo” IT komandai. Rezultatas: niekas neprisiima iniciatyvos.
Paslėptos senos sistemos išlaidos: kur dingsta pinigai
Dauguma įmonių mato tik tiesiogines IT išlaidas: licencijas, palaikymo mokesčius, IT komandos atlyginimus. Bet tikroji pasenusios sistemos kaina slypi kitur.
Prarastas darbuotojų produktyvumas
Jei 50 darbuotojų kiekvienas praranda 30 minučių per dieną dėl neefektyvios sistemos (dubliavimas, laukimas, apeiginiai procesai), tai yra 25 darbuotojų valandų per dieną. Per metus (250 darbo dienų) tai sudaro 6 250 valandų. Skaičiuojant 25 EUR valandiniu įkainiu, prarandama 156 250 EUR per metus, vien dėl produktyvumo nuostolių.
Prarasti klientai
Kiek klientų per metus prarandate dėl lėto aptarnavimo, klaidingos informacijos ar paslaugų, kurių negalite pasiūlyti? Net jei tai tik 5 % klientų bazės, ilgainiui šie praradimai kaupiasi geometrine progresija, nes su kiekvienu prarastu klientu prarandamos ir būsimos pajamos, ir rekomendacijos.
Prarastos verslo galimybės
Naujas klientų segmentas, kurio negalite aptarnauti. Naujas pardavimo kanalas, kurio negalite prijungti. Naujas partneris, su kurio sistema negalite integruotis. Kiekviena tokia prarasta galimybė turi kainą, nors ji ir neatsispindi buhalterinėse knygose.
Darbuotojų kaita
Frustruoti darbuotojai išeina. Naujo darbuotojo paieška ir apmokymas kainuoja 50–200 % metinio atlyginimo, priklausomai nuo pozicijos. Jei sistema prisideda prie didesnės darbuotojų kaitos (o tyrimai rodo, kad netinkami darbo įrankiai yra viena iš pagrindinių nepasitenkinimo priežasčių), tai tiesioginė finansinė žala.
Technologinė skola
Kiekvienas mėnuo su sena sistema prideda dar vieną sluoksnį techninės skolos: dar vieną apeigą, dar vieną „laikiną” sprendimą, dar vieną Excel lentelę. Kuo ilgiau laukiate, tuo brangesnė ir sudėtingesnė bus migravimas.
Savidiagnostikos testas: ar jūsų sistema jau stabdo augimą?
Atsakykite „taip” arba „ne” į kiekvieną teiginį:
- Darbuotojai reguliariai perkelia duomenis tarp sistemų rankiniu būdu
- Ataskaitai gauti reikia daugiau nei 5 minučių arba specialisto pagalbos
- Naujo darbuotojo apmokymas su sistema trunka ilgiau nei 4 savaites
- Klientai skundžiasi aptarnavimo greičiu ar informacijos tikslumu
- Sistema sulėtėja ar stringa piko laikotarpiais
- Integracija su nauju įrankiu reikalauja daugiau nei 2 savaičių darbo
- IT komanda daugiau laiko skiria problemų sprendimui nei naujų galimybių kūrimui
- Darbuotojai naudoja Excel, Google Sheets ar kitus įrankius „šalia” sistemos
- Per pastaruosius 2 metus atsisakėte verslo galimybės dėl sistemos apribojimų
- Sistemos tiekėjas paskelbė apie jūsų versijos palaikymo nutraukimą arba nebeteikia atnaujinimų
- Kandidatai pokalbių metu reaguoja neigiamai sužinoję apie naudojamą technologiją
- Paprastas pokytis sistemoje (nauja ataskaita, naujas laukas, nauja taisyklė) užtrunka savaites ar mėnesius
Rezultatų interpretacija:
- 0–2 „taip”: Jūsų sistema dar funkcionali. Stebėkite situaciją ir planuokite ateitį, bet skubos nėra.
- 3–5 „taip”: Signalai aiškūs. Pradėkite tyrimą: kokios alternatyvos egzistuoja, kiek kainuotų perėjimas, koks tvarkaraštis realistiškas.
- 6–8 „taip”: Sistemos keitimas turėtų būti tarp artimiausių verslo prioritetų. Kuo ilgiau lauksite, tuo brangiau kainuos perėjimas ir tuo daugiau galimybių prarasite.
- 9–12 „taip”: Situacija yra kritiška. Sistema aktyviai stabdo jūsų verslą. Kiekvienas mėnuo delsimo kainuoja konkrečius pinigus, klientus ir darbuotojus.
Ką daryti, kai signalai patvirtina: veiksmų planas
Jei atpažinote kelis signalus savo organizacijoje, štai konkretūs pirmieji žingsniai:
1. Suskaičiuokite tikrąją dabartinės sistemos kainą
Ne tik licencijos ir palaikymo mokesčius. Suskaičiuokite: kiek valandų darbuotojai praranda dėl neefektyvumo? Kiek klientų praradote? Kokias galimybes praleidote? Šis skaičius bus jūsų argumentas vadovybei ir investicijos palyginimo atskaitos taškas.
2. Dokumentuokite skausmo taškus konkrečiais pavyzdžiais
Ne „sistema nepatogi”, o „pardavimų vadybininkas per dieną sugaišta 40 minučių duomenų dubliavimui, kas per metus sudaro X eurų.” Konkretūs skaičiai ir pavyzdžiai yra daug stipresni nei bendros nuojautos.
3. Identifikuokite, kas turi pasikeisti pirma
Ne viskas turi keistis vienu metu. Raskite 2–3 didžiausius skausmo taškus, kuriuos išsprendus pajustumėte didžiausią pokytį. Tai padės priimti sprendimą, kokios apimties projektas reikalingas: ar pakaks atnaujinti vieną modulį, ar reikia keisti visą sistemą.
4. Ištirkite alternatyvas
Susipažinkite su dabartinėmis rinkos galimybėmis. Gali paaiškėti, kad tai, kas prieš 5 metus buvo neįmanoma ar pernelyg brangu, šiandien yra prieinamas standartinis sprendimas. Kalbėkite su 3–5 tiekėjais, dalyvaukite demonstracijose, klauskite rekomendacijų iš panašaus dydžio ir sektoriaus įmonių.
5. Sudarykite verslo atvejį (business case)
Parenkite aiškų dokumentą vadovybei: kokia problema, kiek ji kainuoja, kokios alternatyvos, kokia investicija reikalinga, kokia grąža tikimasi. Sprendimas keisti sistemą yra strateginis verslo sprendimas, ne IT projektas.
6. Nepulkite keisti visko iš karto
Apsvarstykite etapinį požiūrį. Galbūt pirmas žingsnis yra integracijos sluoksnis, kuris sujungia esamas sistemas ir pašalina rankinį dubliavimą. Galbūt pirmiausia keičiama labiausiai skausmo kelianti dalis. Palaipsnis perėjimas sumažina riziką ir leidžia mokytis iš pirmųjų etapų.
Senos sistemos gyvavimo ciklas: nuo efektyvumo iki stabdžio
graph TD
A["Diegimas: sistema sprendžia problemas"] --> B["Augimas: sistema veikia gerai, verslas plečiasi"]
B --> C["Stabilumas: sistema atlieka savo funkciją"]
C --> D["Pirmi signalai: atsiranda nepatogumų ir apeiginių procesų"]
D --> E["Lėtėjimas: sistema riboja galimybes, darbuotojai frustruoti"]
E --> F["Kritinis taškas: sistema aktyviai stabdo verslo augimą"]
F --> G["Sprendimas: keisti, modernizuoti ar integruoti"]Daugelis įmonių per ilgai lieka D ir E etapuose, tikėdamosi, kad problema išsispręs pati. Ji neišsisprendžia. Ji tik gilėja.
Kelios dažnos situacijos ir ką jose daryti
Situacija A: „Sistema veikia, bet nepatogi”
Tai ankstyva stadija. Sistema atlieka pagrindines funkcijas, bet darbuotojai skundžiasi ergonomika, trūksta automatizacijos, ataskaitos ribotos. Šiuo etapu dažnai pakanka: papildomų integracijų, automatizacijos įrankių (pvz., Zapier, Make) arba papildomų modulių. Sistemos keitimas gali būti neproporcingas atsakas.
Situacija B: „Sistema neauga kartu su mumis”
Įmonė plečiasi, bet sistema nepalaiko naujo masto: daugiau naudotojų, daugiau duomenų, daugiau procesų. Sprendimas priklauso nuo sistemos tipo: jei tai SaaS, gal pakaks persikelti į aukštesnį planą; jei tai vietinė sistema, gali tekti migruoti į debesų sprendimą arba keisti platformą.
Situacija C: „Sistema yra silosai”
Įmonė naudoja kelias atskiras sistemas, kurios tarpusavyje nesikalbina. Duomenys izoliuoti, darbuotojai dubliuoja darbą, vientiso vaizdo nėra. Sprendimas: centralizuota platforma (ERP) arba integracinis sluoksnis (middleware, iPaaS), kuris sujungia esamas sistemas. Pasirinkimas priklauso nuo to, kiek dabartinės sistemos yra gyvybingos.
Situacija D: „Sistema yra pasenusi ir nebepalaikoma”
Tai aiškiausias atvejis. Kai tiekėjas nebeatsako, atnaujinimai nevyksta, o saugumo spragos auga, keitimas yra ne pasirinkimas, o būtinybė. Klausimas tik „kada” ir „į ką”. Šioje situacijoje svarbu pradėti veikti nedelsiant, nes kiekvienas mėnuo didina riziką.
Ko šis pokytis reikalauja iš vadovybės
Sistemos keitimo sprendimas nėra IT komandos reikalas. Tai strateginis verslo sprendimas, kuris reikalauja vadovybės įsitraukimo keliose srityse:
Aiški vizija. Vadovybė turi artikuliuoti, kodėl keičiamasi ir kokį rezultatą tikimasi pasiekti. Ne „mums reikia naujos sistemos”, o „per 12 mėnesių norime sumažinti užsakymo apdorojimo laiką 60 % ir pašalinti rankinį duomenų perkėlimą tarp sistemų.”
Biudžeto ir resursų paskyrimas. Sistemos keitimas reikalauja ne tik pinigų, bet ir žmonių laiko. Darbuotojai, kurie dalyvaus projekte, turės skirti tam dalį savo darbo laiko. Vadovybė turi tai suprasti ir atitinkamai planuoti.
Kantrybė ir realistiški lūkesčiai. Sistemos keitimas neduoda rezultatų per savaitę. Pirmieji mėnesiai po perėjimo gali būti net sunkesni nei prieš jį, nes darbuotojai mokosi, procesai derinami, duomenys tikslinami. Vadovybė turi tai žinoti ir nepanikuoti.
Asmeninis pavyzdys. Jei vadovai patys naudoja naują sistemą, siunčia žinutę visai organizacijai: „tai svarbu, mes visi tai darome.” Jei vadovai toliau prašo „senojo Excel failo”, darbuotojai irgi nepereis.
Paskutinis žodis
Jūsų verslo sistema yra kaip batas. Kai jis tinka, apie jį negalvojate. Bet kai jis tampa per mažas, kiekvienas žingsnis primena apie problemą.
Skirtumas tas, kad batus pakeisti lengva. O verslo sistemą, ne. Todėl daugelis įmonių eina su per mažu batu kur kas ilgiau, nei turėtų, tikėdamosi, kad koja nustos augti.
Ji neliaus augti. Klausimas tik tas, ar leisite jai augti laisvai, ar toliau spausite į seną batą.
Peržvelkite dvylika signalų. Atlikite savidiagnostikos testą. Ir jei skaičiai rodo, kad laikas keistis, pradėkite nuo pirmojo žingsnio: suskaičiuokite, kiek dabartinė sistema jums iš tikrųjų kainuoja. Atsakymas gali nustebinti.