Uzņēmuma sākuma posmā atsevišķi specializēti rīki bieži ir pilnīgi loģiska izvēle. Grāmatvedībai ir sava sistēma, pārdošanai CRM, e-komercijai sava platforma, noliktavai vai ražošanai vēl cits risinājums. Katrs no šiem rīkiem atsevišķi var savu darbu darīt ļoti labi.
Problēma sākas brīdī, kad viens biznesa process iet cauri vairākām sistēmām. Tad uzņēmums vairs nemaksā tikai par katru programmu atsevišķi, bet arī par visu, kas nepieciešams, lai šīs sistēmas savā starpā saprastos un process kopumā turpinātu darboties.
Sistēmu skaits pats par sevi nav problēma
Mērķis nav panākt, lai uzņēmumā viss obligāti notiktu vienā programmā. Mūsdienīga arhitektūra var sastāvēt no ERP, CRM, e-komercijas, noliktavas un citiem specializētiem risinājumiem. Dažos procesos specializēts risinājums tiešām būs labāks par universālu funkcionalitāti.
Svarīgāks ir cits jautājums: kurā sistēmā dzīvo katrs būtiskais biznesa fakts un kā šī informācija nonāk pārējās sistēmās? Kur glabājas pareizā klienta adrese, kur ir aktuālā cena, kurš ir patiesais noliktavas atlikums un kur tiek apstiprināts pasūtījums? Ja uz vienu no šiem jautājumiem ir vairākas atbildes, sākas neskaidrība.
Dārgākā daļa bieži ir starp sistēmām
Pieņemsim, ka pasūtījums rodas vienā sistēmā, noliktava strādā citā, bet rēķins tiek veidots trešajā. Informācijai starp šīm sistēmām kaut kā ir jāpārvietojas. To var izdarīt ar integrāciju, failu importu vai manuāli.
Katrā šādā pārejas punktā rodas izmaksas. Integrācija jāizveido, jātestē un jāuztur. Manuāla pārrakstīšana prasa cilvēka laiku un rada kļūdu risku. Ja viena sistēma mainās, jāpārbauda, vai izmaiņa nav salauzusi kādu no savienojumiem.
Tāpēc jautājums nav tikai par licenču cenu. Jāskatās, cik maksā viss process starp sistēmām un cik daudz darba vajag, lai tas katru dienu darbotos paredzami.
Datu dublēšanās rada vairākas “patiesības”
Sadrumstalotā vidē viens un tas pats fakts bieži eksistē vairākās vietās. Klienta dati ir CRM un ERP, preču dati ir ERP un e-veikalā, bet noliktavas atlikums var būt noliktavas sistēmā, ERP un reizēm vēl kādā Excel failā.
Kamēr viss sakrīt, problēmu nejūt. Tiklīdz dati sāk atšķirties, parādās ļoti praktisks jautājums: kurai sistēmai ticēt? Tad darbinieki sāk salīdzināt, pārbaudīt un labot datus, un tas jau kļūst par regulāru procesa daļu.
Bieži vien pati integrācija nav galvenā problēma. Problēma ir tajā, ka nav skaidri noteikts, kura sistēma ir konkrētā datu veida īpašnieks. Ja tas nav definēts, automatizācija var tikai ātrāk pārvietot nekonsekventus datus no vienas vietas uz otru.
Uzņēmumam augot, pieaug procesa sarežģītība
Izaugsme nozīmē ne tikai vairāk klientu un pasūtījumu. Parādās vairāk noliktavu, cenu noteikumu, apstiprinājumu, juridisko personu, piegādes scenāriju un izņēmumu. Sistēmām tad vairs nav tikai jāapmainās ar datiem – tām jāatspoguļo arī biznesa loģika.
Kurā brīdī pasūtījums ir apstiprināts? Kad drīkst rezervēt preci? Kurš drīkst mainīt cenu? Kā apstrādā atgriešanu, un kā šīs darbības nonāk finansēs? Jo vairāk šī loģika ir sadalīta pa dažādām sistēmām, jo grūtāk kļūst saprast, kur īsti atrodas pats process un kurš par to atbild.
Vai risinājums vienmēr ir ERP?
Nē. Dažkārt specializēts WMS, e-komercijas, plānošanas vai cits risinājums konkrētu darbu dara labāk nekā ERP standarta funkcionalitāte. Pareizais mērķis nav visu salikt vienā sistēmā, bet izveidot skaidru arhitektūru. Pareizais jautājums ir cits: vai uzņēmuma sistēmu kopumam ir skaidra arhitektūra?
- kura sistēma ir konkrēto datu īpašnieks;
- kurā sistēmā notiek konkrētais procesa posms;
- kā dati pārvietojas starp sistēmām;
- kas notiek, ja integrācija nenostrādā;
- kurš atbild par katru savienojumu un tā uzturēšanu.
ERP šādā modelī bieži ir procesu un transakciju kodols, ap kuru pieslēdzas vajadzīgie specializētie risinājumi. Galvenais ir nevis sistēmu skaits, bet skaidras lomas, datu īpašumtiesības un pārvaldāmi savienojumi.
Kā saprast, ka sadrumstalotība jau kļuvusi par problēmu?
Parasti to var redzēt nevis sistēmu sarakstā, bet ikdienas darbā. Pazīmes, ka problēma jau kļuvusi praktiska:
- vieni un tie paši dati tiek ievadīti vairākās sistēmās;
- darbinieki regulāri salīdzina, kurā sistēmā informācija ir pareiza;
- integrāciju kļūdas ir kļuvušas par ikdienas darbu;
- jauna biznesa izmaiņa nozīmē izmaiņas vairākās sistēmās un integrācijās;
- neviens īsti nevar ātri pateikt, kura sistēma ir konkrēto datu “patiesības avots”.
Tas nenozīmē, ka visas sistēmas jāmaina. Tas nozīmē, ka tās vairs nevar vērtēt katru atsevišķi – jāskatās uz kopējo procesu, datu plūsmu, integrācijām un atbildībām.
Kā saprast, ka sadrumstalotība jau kļuvusi par problēmu?
Arī pieci labi rīki paši par sevi vēl neveido labu biznesa sistēmu. Vērtība rodas tad, kad uzņēmums zina, kur dzīvo tā dati, kā process pārvietojas starp sistēmām un kas par katru tā posmu atbild.
Tāpēc, vērtējot sistēmu izmaksas, es neskatītos tikai uz licencēm. Jāskatās arī uz visu, kas notiek starp tām.
Sistēmu skaits nav problēma. Problēma ir tas, kas notiek starp tām.
Ja dati, procesi un integrācijas ir izkliedētas pa vairākām sistēmām, ir vērts sākt ar kopējās arhitektūras izvērtējumu. Kur rodas dublēšanās, manuāls darbs, liekas atkarības un uzturēšanas izmaksas?
