Kā izvairīties no procesu degradācijas Odoo pēc ieviešanas

Ievads

ERP klases sistēmas, piemēram, Odoo, nodrošina uzņēmumiem jaudīgus rīkus uzskaites, ražošanas, loģistikas un analītikas automatizācijai. Taču pat ideāli ieviesta sistēma var sākt “sabrukt”, ja pēc palaišanas netiek nodrošināts kvalitatīvs atbalsts un datu kvalitātes kontrole.

Šajā rakstā mēs aplūkosim, kāpēc pat veiksmīgas Odoo ieviešanas laika gaitā var zaudēt efektivitāti un kādi rīki var palīdzēt no tā izvairīties. Balstoties uz pieredzi, strādājot ar lieliem ieviešanas projektiem, mēs parādīsim pieejas, kas palīdzēs uzturēt kārtību datos un saglabāt automatizācijas efektivitāti ilgtermiņā. 

Iemesli bieži vien nav pašā sistēmā, bet gan tajā, ka trūkst:

• nepārtrauktas datu kvalitātes kontroles,
• aktuālu instrukciju un apmācību,
• iekšējā IT dienesta iesaistes,
• tehnisko mehānismu “aizsardzībai pret kļūdām”.

Tālāk mēs aplūkosim, kā Odoo ļauj izveidot kontroles un atbalsta infrastruktūru, nepārrakstot pusi no koda.

 Palaišanas posmā — izmēģinājuma ekspluatācijā — sistēma joprojām darbojas ieviesēju uzraudzībā. Taču pēc projekta nodošanas iekšējam IT dienestam sākas īstais arhitektūras stresa tests.

Kāpēc šo posmu nevajadzētu izslēgt no tehniskās specifikācijas / ieviešanas procesa

Odoo projektos ir sastopamas dažādas pieejas ieviešanai. Ne visi integratori ir gatavi iesaistīties produktīvās ekspluatācijas posmā. Daži aprobežojas tikai ar iestatītas sistēmas nodošanu “kā ir”, nepiedaloties tās reālajā palaišanā un pielāgošanā uzņēmuma ikdienai.

Taču piekrist šādiem nosacījumiem nav vēlams. Reālā  ekspluatācija ir viens no svarīgākajiem posmiem. Tieši šajā brīdī sistēma saskaras ar reālo dzīvi: ar īstiem datiem, lietotājiem un biznesa procesiem. Tas, kas teorētiski vai testos izskatījās labi, praksē var nedarboties vai prasīt pielāgojumus.

Neatkarīgi no tā, cik rūpīgi ir notikusi projektēšana un konfigurēšana, gala modelis reti atspoguļo realitāti par 100%. Kādus procesus mēdz aizmirst, citi scenāriji “uzpeld” jau reālās lietošanas laikā. Un tas ir pilnīgi normāli — tā nav kļūda, bet dabisks adaptācijas posms.

Piemēram, jūs ieviešat Odoo iepirkumu moduli ar automātisku plāna pārskatīšanu katru nedēļu. Pēc pāris nedēļām lietotāji saprot, ka šāds ritms viņus pārāk noslogo — trūkst laika, process kļūst apgrūtinošs. Komanda pieņem lēmumu pāriet uz mēneša pārskatīšanu — un sistēma sāk strādāt reālajā uzņēmuma tempā.

Svarīgi saprast: pēc pieredzes ekspluatācijas posma sistēmas darbs gandrīz vienmēr atšķirsies no sākotnēji aprakstītā modeļa. Parādīsies korekcijas, jaunas prasības, precizējumi. Tas ir normāli — tieši šis posms pārvērš “konfigurētu produktu” par patiešām strādājošu instrumentu.

Parasti šis posms aizņem līdz pat 60% no kopējā stundu apjoma, kas tiek iztērēts programmēšanai, konfigurēšanai un procesu pielāgošanai.

Ja IT speciālisti nav bijuši iesaistīti projektā jau no paša sākuma, viņi visbiežāk nesaprot, kā sistēma ir uzbūvēta, kāpēc daži lauki ir obligāti un kādas sekas var radīt lietotāju pieļautās kļūdas. 

Ja IT speciālisti iesaistās tikai projekta beigās — kad viss jau gandrīz gatavs un ieviesēji taisās prom — nekas labs no tā nesanāks. Tipiska situācija: projekts jānoslēdz aprīlī, bet IT komanda parādās nedēļu pirms termiņa ar jautājumu: “Kā jums te viss darbojas?”

Atbilde, protams, būs šāda: “Te ir funkcionālais modelis, viss aprakstīts. Lasiet. Ja kas — ir arī instrukcija.” Formāli viss pareizi. Bet realitātē — pilnīgs haoss.

Laba IT komanda saprot: ar šo sistēmu viņiem būs jāstrādā ilgtermiņā. Tāpēc viņi iesaistās jau no paša sākuma — vēl projektēšanas posmā. Viņiem ir svarīgi saprast ne tikai ko darīt Odoo, bet arī kāpēc. Citādi jebkāda sistēmas uzturēšana pārvēršas par minēšanas spēli.

Lielākā problēma — IT cilvēkiem jau tā ir pilnas rokas ar darbu: zvani, pieprasījumi, serveri, ārkārtas atjauninājumi. Un tagad vēl klāt jauna sistēma. Šādā noslodzē nav iespējas pilnvērtīgi iedziļināties Odoo loģikā.

Vislabāk, ja projektā tiek iesaistīti 1–2 speciālisti, kuri uz laiku tiek atbrīvoti no citām lietām. Viņi var iedziļināties procesos, saprast, kāpēc nepieciešami konkrētie iestatījumi, un kļūt par īstiem iekšējiem ekspertiem.

Jo viena lieta ir “zināt, kur jānospiež”, bet pavisam cita — saprast, kāpēc tas jādara.

Ja IT komanda ir iesaistīta no paša sākuma — sistēma turpina veiksmīgi darboties arī pēc projekta beigām.

Ja nav — ieviesēji spiesti ilgi palikt “dežūrā”. Bet mūsu mērķis taču ir panākt, lai sistēma strādā arī bez mums.

Ja iekšējais IT dienests nav bijis iesaistīts projektā jau no paša sākuma un nav paspējis izprast sistēmas darbības loģiku, tad atbalsts bieži pārvēršas par ilgstošu “dežūrēšanu” no ārējās ieviešanas komandas puses. Katrs jautājums — pie mums. Katra kļūda — pie mums. Jebkura nestandarta situācija vai jauns lietotājs — atkal pie mums. Būtībā, tā vietā, lai projektu pabeigtu un nodotu pašvadītā lietošanā, mēs paliekam “ēnā”, aizvietojot uzņēmuma pašu IT funkciju.

Šāda shēma kādu laiku var darboties, īpaši, ja uzņēmumam tiešām trūkst resursu vai kompetenču. Taču praksē tas rada atkarību. Un, augot sistēmai un komandai, pieaug arī pārslodze. Pat ja klients ir gatavs par to maksāt, tas neatrisina galveno uzdevumu: ieviestajai sistēmai ir jādzīvo un jāattīstās uzņēmuma iekšienē, nevis jāeksistē tikai pateicoties ārējam atbalstam.

Mēs, kā ieviesēji, nevēlamies un nedrīkstam kļūt par “ kruķiem” uzņēmumam. Mūsu īstā misija — izveidot tādu sistēmu un procesus, kas spēj darboties bez mums. Jā, ar konsultācijām, retu atjauninājumu palīdzību, ar atbalstu paplašināšanās brīžos — bet ne ar ikdienas “ugunsgrēku dzēšanu” un pamata darbību pamācībām.

Pareiza ieviešana — tas nav tad, kad ieviesējs ir vienmēr uz līnijas, bet gan tad, kad pēc pusgada uzņēmumam vairs nav vajadzības pēc viņa palīdzības. Jo viss ir saprotams, viss strādā, un iekšējā komanda zina, ko un kāpēc dara.

Šis ir īstais projekta brieduma rādītājs. Un tieši uz to mēs tiecamies.

 Obligātie lauki (required=True) un modeļa līmeņa ierobežojumi (piemēram, SQL constraints, @api.constrains).

• Automātiska aizpildīšana un aprēķinātie lauki (computed fields) ar aizsardzību pret rediģēšanu.
• Dinamiskie domēna filtri interfeisā.
• Piekļuves tiesību ierobežošana (record rules, groups).
• Ierobežojumu izmantošana caur Odoo Studio vai pielāgotiem moduļiem.

• Iebūvēta dokumentācija tieši formās vai uznirstošajos padomos.
• Vienkārša pieteikumu iesniegšana tehniskajam atbalstam — piemēram, caur Helpdesk moduli, logrīku vai pogu “Ziņot par kļūdu” formās.
• Analītika par pieprasījumiem: kādi jautājumi atkārtojas, kuri paliek neatbildēti.
• Atbalsts ar čatbotu vai asistentu sākotnējai reakcijai.
• Instrukciju aktualizēšana atbilstoši biznesa procesu izmaiņām.

 Ja lietotājs vienkārši mehāniski spiež pogas un aizpilda laukus “kā teica”, nesaprotot, kāpēc tas jādara un kā tas ietekmē biznesa procesus — agrāk vai vēlāk sistēma sāks “jsabrukt”. Kļūdas sāks krāties, dati kļūs sagrozīti, atskaites zaudēs ticamību. Un IT vai ieviesēji būs spiesti tērēt laiku nevis sistēmas attīstīšanai, bet pastāvīgai problēmu seku novēršanai.

Ir svarīgi, lai katrs lietotājs saprastu:

• Kāpēc viņš ievada datus — kas notiks, ja kāds lauks tiks izlaists vai izvēlēts nepareizs dokumenta veids;
• Kas tālāk izmantos ievadīto informāciju — grāmatvedība, loģistika, analītiķi;
• Kuras kļūdas ir kritiskas un kuras — tikai formālas;
• Kad vērsties pēc palīdzības, bet kad var atrisināt pats.

Lietotājs nav pasīvs operators, bet pilntiesīgs biznesa procesa dalībnieks. Jo īpaši Odoo vidē, kur gandrīz viss ir “uz virsmas”, un katra darbība ietekmē saistītus moduļus: pārdošanu, noliktavu, finanses, atskaites. Tāpēc ieradums domāt, pārbaudīt un uzņemties atbildību ir kritiski svarīgs.

Reālos projektos šo atšķirību var skaidri redzēt. Tur, kur lietotāji ir iesaistīti, apmācīti un saprot, ko dara — sistēma darbojas stabili, caurspīdīgi un attīstās kopā ar biznesu. Tur, kur darbinieki strādā pēc principa “man teica spiest — es nospiedu”, pat vislabāk ieviestā sistēma ar laiku sāk buksēt.

Mūsu, kā ieviesēju, uzdevums nav tikai konfigurēt procesus, bet arī veidot datu atbildības kultūru. Savukārt uzņēmuma uzdevums — uzturēt šo kultūru savā komandā. Tieši šī kultūra kļūst par īsto “sistēmu” — daudz svarīgāku par jebkuru ERP.

•  Scheduled actions izveide, kas katru dienu vai nedēļu pārbauda galveno lauku aizpildījumu.
• Informācijas paneļu (dashboards) izmantošana (piemēram, spreadsheet modelī vai caur Odoo BI).
• Pogas “Pārbaudīt aizpildījumu” pievienošana dokumenta formai.
• Nekorektu ierakstu izcelšana, izmantojot krāsu tagus (kanban color, smart buttons).
• Automātiskās aizpildīšanas un automātiskās noraidīšanas loģika, ja netiek izpildīti noteikti nosacījumi.

Tipiskās pārbaudes, kuras ir vērts ieviest

Lūk, konkrēts pārbaužu saraksts, ko var ieviest Odoo 17/18 un palaist automātiski vai manuāli:

• Visiem rēķiniem  ir aizpildīti analitiskie konti / grāmatvedības konti / projekti / struktūrvienības.
• Nav partnetu dublikātu (pēc reģistrācijas numura, PVN numura vai e-pasta).
• Precēm, kas piedalās aprēķinos, ir aizpildītas cenas un uzskaites kategorijas.
• ·         Visiem aktīvajiem lietotājiem ir norādīts e-pasts un laika zona.
• ·         Preču atlikumu atskaitēs nav negatīvu vērtību.
• ·         Dokumenti ar nokavētiem parakstiem vai statusiem tiek rādīti atsevišķā filtrā.

 Odoo ieviešana nav beigu punkts — tā ir sākums. Moduļu uzstādīšana, direktoriju konfigurēšana un lietotāju apmācība ir svarīgi soļi, taču pēc tiem sākas daudz ilgāks un prasīgāks posms: ekspluatācija, izaugsme, attīstība un pielāgošana reālajām uzņēmuma vajadzībām.

ERP sistēma nedarbojas “pati no sevis”. Pat tik elastīga platforma kā Odoo ar laiku var zaudēt efektivitāti, ja par to nerūpējas. Tas, kas sākumā bija skaidri uzbūvēta sistēma, viegli var pārvērsties par haosu ar dublētiem datiem, nepārskatāmiem procesiem un lietotājiem, kuri “kaut ko dara”, bet neviens īsti nezina — kāpēc.

Lai tas nenotiktu, noturība jāveido jau no paša sākuma. Tas nozīmē:

• IT speciālistu iesaistīšanu jau projektēšanas posmā, nevis pēdējā brīdī.
• Lietotāju ieradumu saprast, ko viņi dara, nevis tikai sekot norādēm.
• Atbalsta automatizāciju: iekšējās palīdzības pogas, Helpdesk, ātrās kļūdu ziņošanas formas.
• Regulāras datu kvalitātes pārbaudes un obligāto lauku kontrole.
• Sistēmas loģikas dokumentēšanu un zināšanu saglabāšanu komandā.

Odoo ļauj realizēt šos principus bez sarežģītām izstrādēm — izmantojot iebūvētos rīkus, plānotas darbības, piekļuves tiesības un modulāro uzbūvi. Galvenais ir vēlme veidot procesu sistemātiski un ilgtermiņā.

Ja izmantosiet kontroles mehānismus, ierobežojumus un regulāras pārbaudes — jūs saglabāsiet datu tīrību, izvairīsieties no kļūdu lavīnām un samazināsiet slodzi uz atbalsta komandu. Un pats galvenais — sistēma darbosies stabili, caurspīdīgi un prognozējami.

Laba ieviešana ir tāda, kas pēc gada joprojām dod ieguvumu. Un pēc pieciem gadiem darbojas ne sliktāk kā pirmajā dienā. Tieši uz to mēs tiecamies.