Skip to Content

Odoo diegimo partnerio keitimas – ką reikia žinoti



Santrauka:

Straipsnyje paaiškinama, kada įmonei iš tikrųjų reikia keisti savo „Odoo“ diegimo partnerį. Jame aptariami įspėjamieji ženklai, rodantys, kad pokytis gali būti būtinas, su partnerio keitimu susijusios rizikos, kaip kuo sklandžiau įgyvendinti perėjimą, į ką atkreipti dėmesį renkantis naują partnerįį.

Odoo ERP diegimas nėra programinės įrangos įdiegimas – tai strateginė verslo transformacija. Kai ši transformacija sustoja, natūralu kaltinti pačią platformą ir jos tiekėją. Tačiau iš tikrųjų problema beveik visada slypi netinkamai valdytame diegimo procese – tiek iš partnerio, tiek iš vidinio planavimo pusės, o kartais ir abiejose. Partnerio keitimas projekto viduryje dažniausiai yra skausmingas ir neretai politiškai jautrus sprendimas, kuris dažnai priimamas impulsyviai, kylant emocijoms ir „lekiančioms galvoms“, o tai situaciją tik dar labiau pablogina.


Šiame straipsnyje apžvelgiami įspėjamieji ženklai, padedantys išvengti to impulsyvaus „lūžio momento“, kai santykiai pradeda blogėti, taip pat aptariamos keitimo rizikos ir procesas bei pateikiamos gairės, kaip pasirinkti naują komandą, galinčią pasiekti tai, ko nepavyko ankstesniajai. Šios rekomendacijos grindžiamos pripažintomis ERP diegimo metodikomis, pritaikytomis būtent Odoo ekosistemai.



Kada metas keisti?

Ne kiekvienas nusivylimas yra pakankama priežastis keisti partnerį. Techniniai nesklandumai ar nesusikalbėjimas yra natūrali trintis bet kuriame sudėtingame projekte. Sprendimą keisti partnerį turėtų lemti nuolatinės, sisteminės problemos, o ne pavieniai incidentai. 

  • Terminai nuolat praleidžiami, nepateikiant nei atnaujinto grafiko, nei paaiškinimų. Nuolatinis vėlavimas rodo projekto valdymo drausmės stoką arba sąmoningą atsakomybės vengimą.
  • Komunikacija nutrūkusi. Savaitinės projekto eigos ataskaitos neberengiamos arba tapo beprasmės. Į el. laiškus neatsakoma, o jūsų komanda priversta spėlioti apie projekto būklę.
  • Jūsų verslo procesai neteisingai suprantami arba ignoruojami. Partneris sprendimus kuria remdamasis tuo, ką pats išmano, o ne tuo, ko reikia jums. Individualūs pritaikymai nuolat kaupiasi, nes pagrindiniai procesai nebuvo tinkamai išanalizuoti, juo labiau pertvarkyti.
  • Sistema nestabili. Klaidos kartojasi, o problemos, kurios buvo laikomos išspręstomis, nuolat pasikartoja.
  • Projektas visiškai sustojęs. Darbai „vykdomi“ jau kelis mėnesius, tačiau nematyti jokios realios pažangos ir nėra aiškaus eskalavimo mechanizmo.

Kuo ilgiau probleminis projektas tęsiasi su netinkamu partneriu, tuo sunkiau išspręsti kylančias technines problemas ir galiausiai jį išgelbėti.


Kodėl Odoo projektai apskritai žlunga?

Nors visi minėti sisteminiai trūkumai yra gana akivaizdūs ir juos nesunku rasti kituose šaltiniuose, pateikiančiuose ERP diegimo patarimus, vienas aspektas dažniausiai nėra aiškiai pabrėžtas: sisteminė analizė. Prieš keičiant partnerį, būtina suprasti tikrąsias priežastis, dėl kurių stringa jūsų ERP projektas, o ne versti kaltę partneriui. Priešingu atveju tie patys klaidų modeliai greičiausiai pasikartos su nauja komanda.

Jūsų ERP diegimo konsultantas gali paprasčiausiai atsidurti sudėtingoje padėtyje dėl neaiškių reikalavimų, nerealių lūkesčių arba nepakankamai įtrauktų projekto resursų. Tačiau tai nėra pateisinimas konsultantui „pasimesti“ – geras ERP diegimo partneris turėtų iš anksto tinkamai patarti, kad tokių situacijų išvengtų. Be kruopščios analizės, kodėl jūsų „Odoo“ diegimas stringa, vien kaltinti nesėkmes nepadės judėti į priekį.

Dažniausios klaidos „Odoo“ diegimuose nėra unikalios „Odoo“ – jos atspindi gerai dokumentuotus modelius visoje ERP industrijoje.

Nėra tinkamai atliktos analizės ar planavimo etapo. Organizacijos pradeda ERP diegimą neapibrėžus esamų procesų, nesukūrus sėkmės rodiklių ir nenustatytų realistiškų terminų. Čia slypi didžiausia rizika: jei projektas neturi aiškių sėkmės kriterijų, jis niekada negalės tapti sėkmingu.

Perdėtas individualizavimas be pagrįstų priežasčių. „Odoo“ lankstumas gali būti tiek privalumas, tiek problema. Partneriai, kurie sutinka su kiekvienu individualizavimo prašymu – nesvarbu, ar nebūtų pakakę standartinės konfigūracijos su tam tikra procesų pertvarka – kuria techninę skolą, kuri didėja su kiekvienu atnaujinimu. Geras partneris kelia klausimus ir kruopščiai vertina poreikius; prastas partneris tiesiog skaičiuoja daugiau darbo valandų.

Nėra paskirto projekto vadovo ar atsakomybės struktūros (projekto valdymo mechanizmo). Projekto vadovas nėra tik ryšininkas tarp komandų. Jis atsako už terminus, valdo užduočių apimtį ir eskaluoja rizikas. Be tokio vadovo sprendimai vėluoja, biudžetai auga, o atsakomybė už rezultatus lieka neaiški. Net geriausias projekto vadovas negalės daug nuveikti be aiškiai nustatytos ir įgyvendintos atsakomybės struktūros.

Kūrėjai be ERP patirties. Vien tik techninių įgūdžių nepakanka sėkmingam ERP diegimui. Kūrėjas, kuris moka tik programuoti, bet nesupranta verslo procesų, neišvengiamai sukurs sprendimus, kurie automatizuoja netinkamai suprojektuotus procesus, taip tik dar labiau pablogindamas tai, ką norėta išspręsti.

Trūksta dokumentacijos ir testavimo aprėpties. Tai galbūt pats pavojingiausias trūkumas ruošiantis partnerio keitimui. Kai išeinanti komanda nepateikia dokumentacijos apie tai, kas buvo sukurta, kodėl tai buvo sukurta ir kaip buvo ištestuota, atėjusi komanda praktiškai pradeda darbą aklai.


Odoo partnerio keitimo rizikos


​Partnerio keitimas be aiškaus plano gali pakenkti labiau nei problemos, kurias šis veiksmas turėjo išspręsti. Pagrindinės rizikos turi būti identifikuotos ir aktyviai valdomos dar prieš pradedant perėjimą:

  • Prarandamas prieigos prie kodo, serverių ar prisijungimų valdymas. Jei išeinantis partneris kontroliuoja talpinimą ar prieigą prie saugyklų ir nesutinka bendradarbiauti, kritiniai ištekliai gali tapti neprieinami.
  • Nėra perdavimo dokumentacijos. Be įrašų, kas buvo sukonfigūruota, individualizuota ar integruota, naujasis partneris priverstas rekonstruoti sistemą iš naujo – tai užima daug laiko ir padidina klaidų riziką.
  • Neaiški intelektinės nuosavybės teisė. Jei sutartys aiškiai nepriskyrė nuosavybės teisės į individualius modulius ar kodą jūsų organizacijai, teisminiai ginčai gali vėlinti ar net sutrikdyti perėjimą.
  • Naujos komandos įsisavinimo laikas. Net patyrusiems partneriams reikia laiko suprasti jūsų sistemą, duomenis ir verslo kontekstą. Skubėjimas šioje fazėje gali lemti gerai nuoširdžias, bet klaidingas užduotis.


Kaip užtikrinti sklandų perėjimą


Kai priimamas sprendimas keisti partnerį, šie veiksmai padeda pasiruošti, kad naujasis konsultantas galėtų sklandžiai perimti projektą:

  • Iškart užtikrinkite prieigą prie visų sistemos išteklių. Paprašykite pilnų duomenų bazių atsarginių kopijų, visų individualių kodo saugyklų, prieigos duomenų į talpinimą ir visų integracijos konfigūracijos failų. Šio proceso nepradėkite laukti, kol išeinantis partneris oficialiai bus atjungtas.
  • Dokumentuokite viską. Sudarykite katalogą su kiekvienu aktyviu moduliu, kiekvienu individualizuotu elementu, visomis atviromis problemomis ir laukiančiais pristatymais. Tai bus jūsų pradinė bazė – be jos negalėsite tiksliai nustatyti, ką reikia taisyti.
  • Peržiūrėkite sutartis ir intelektinės nuosavybės teises. Jei reikia, pasikonsultuokite su teisininku. Patikrinkite, kad visas individualus kūrimas priklausytų jūsų organizacijai ir nebūtų jokių sutartinių kliūčių įtraukti naują partnerį.
  • Organizuokite naujos komandos įsisavinimą su techniniu ir verslo kontekstu. Naujoji komanda turi suprasti ne tik kodą, bet ir verslo procesus, kuriuos jis aptarnauja. Suteikite suinteresuotųjų šalių prieigą, procesų dokumentaciją ir skirkite laiko išsamiai analizės fazei.
  • Atvirai bendraukite su visomis suinteresuotosiomis šalimis. Vidinės komandos, skyrių vadovai ir galutiniai naudotojai turi suprasti, kad vyksta pokytis, kodėl jis vyksta ir ko tikėtis perėjimo laikotarpiu.


Į ką atkreipti dėmesį renkantis naują partnerį

Partnerio pasirinkimas yra bent jau toks pat svarbus kaip ir technologijos pasirinkimas – ir, galima teigti, net svarbesnis. Straipsnis „Choosing the Right Odoo Consultant: A Comprehensive Guide“ išsamiai nagrinėja šią temą, tačiau čia pateikiama ištrauka, skirta gelbėjimo ar perėjimo situacijai:

  • Gilios techninės ir funkcinių procesų žinios – ne vien tik viena arba kita. Turi būti derinamos techninės kompetencijos ir gebėjimas suprasti verslo procesus.
  • Projektų valdymo suvokimas kaip disciplina. Projektų valdymas nėra tas pats, kas resursų koordinavimas ar santykių valdymas. Projektų vadovas – tai asmuo, pageidautina neutralioje pozicijoje, kuris atsako už terminus, valdo užduočių apimtį ir nedelsiant eskaluoja rizikas.
  • Skaidri komunikacija ir reguliarios ataskaitos. Reguliarūs statuso atnaujinimai, aiškiai apibrėžti etapai ir sąžininga vertinimo praktika, kas veikia, o kas ne. Skaidrumas nėra „malonus priedas“ – tai pats stipriausias sveikos partnerystės rodiklis.
  • Dėmesys problemų sprendimui, o ne kaltinimams. Naujas partneris perima sudėtingą situaciją. Komanda, kuri energiją skiria ankstesnio partnerio darbo kritikai, nėra susitelkusi į jūsų projekto rezultatą.
  • Įrodyta gelbėjimo ir perėjimo patirtis. Ne kiekvienas partneris yra įsitraukęs į stringantį projektą jo eigoje. Tai yra kitokie įgūdžiai nei įprastas diegimas. Straipsnyje, minėtame aukščiau, pateikiamas paprastas „10 klausimų, kuriuos užduoti prieš pasirašant sutartį su nauju partneriu“ sąrašas. Vienas klausimas, kurį verta pridėti kaip #11: „Kaip valdysite perėjimą nuo ankstesnio partnerio?“ Paprašykite konkrečių pavyzdžių.


Kaip mes gelbėjame sudėtingus projektus

Mūsų požiūriu yra konkretus atsakymas į klausimą #11:

  • Atlikti pradinį auditą, apimantį tiek kodą, tiek verslo logiką. Prieš atliekant bet kokius pakeitimus, „mes atliekame išsamų techninį ir funkcionalų esamos sistemos vertinimą – nuo kodo kokybės ir infrastruktūros iki verslo procesų ir ERP biudžetų. Prieš rašant bent vieną kodo eilutę, tikslas yra suprasti ne tik tai, kas neveikia, bet ir kodėl tai įvyko, taip užkertant kelią naujos komandos pakartotinėms klaidoms.
  • Peržiūrėti tikslus ir KPI. Daugiau nei 50 % organizacijų negali tiksliai įvertinti sąnaudų atsipirkimo ERP projektuose, o pagrindinė priežastis – tinkamai nebuvo nustatyti sėkmės rodikliai. Mes patariame šį perėjimo laikotarpį išnaudoti apibrėžiant, ką reiškia „užbaigta“ – nustatant matuojamus, laiku ribotus tikslus, už kuriuos atsakingi tiek jūs, tiek naujasis partneris.
  • Parengti individualų veiksmų planą, skirtą taisymams, procesų tobulinimui ar pilnam projekto paleidimui iš naujo. Ne kiekvienas gelbėjimo projektas reikalauja visko kurti nuo nulio. Veiksmų plane aiškiai skiriama, kas gali būti stabilizuota greitai, kas reikalauja procesų lygio optimizavimo, o kas – retais atvejais – yra ekonomiškiau perkurti nei taisyti.
  • Nustatyti valdymo modelį. Apibrėžkite vaidmenis, sprendimų teises, eskalavimo kelius ir peržiūrų tvarkaraščius dar prieš pradedant darbus. Valdymo chartija nėra biurokratija – tai struktūra, kuri padeda sudėtingam projektui išlikti kelyje ir užkerta kelią atsakomybės pasiskirstymui, sukėlusiam pradinę nesėkmę. Sustingęs gamybos diegimas kelia visiškai kitokius iššūkius nei sutrikęs didmeninės prekybos ar e. komercijos projektas. Mes turime patirties gelbėjant projektus įvairiose srityse – gamyboje, didmeninėje ir mažmeninėje prekyboje, sveikatos priežiūroje bei farmacijos sektoriuje, todėl mūsų profesionali komanda mažiau tikėtina bus nustebinta radinių.

Mūsų ataskaitose nurodoma 100 % projektų sėkmė paleidžiant atnaujintus projektus ir jokių gedimų gamyboje po paleidimo, dažniausiai pirmųjų 2–4 savaičių metu išsprendžiant iki 80 % pagrindinių problemų mūsų projektų portfelyje. Tai rezultatais pagrįsti rodikliai, kurių rimta gelbėjimo projekto vertinimo analizė turėtų reikalauti.




Susisiekite su mumis, kad jūsų Odoo projektas būtų sėkmingai atnaujintas 


Susisiekite



Baigiamosios mintys

ERP sistema turėtų būti jūsų verslo veiklos stuburas. Kai partneris, atsakingas už šio stuburo kūrimą, neveikia tinkamai, teisingas sprendimas nėra laukti ir tikėtis stebuklo, o pasirinkti efektyvią komandą, kuri specializuojasi taisant tai, ko kiti negalėjo įgyvendinti. Odoo diegimo partnerio keitimas yra strateginis sprendimas. Kuo anksčiau įvyksta perėjimas, tuo mažiau prarandama. Tačiau greitis turi būti derinamas su disciplina – skubotas perėjimas pas netinkamą partnerį reiškia tik tų pačių problemų kartojimą. Kompetentingas partneris gali padėti suplanuoti ir užtikrinti, kad jūsų perėjimas vestų prie sėkmingos verslo veiklos rezultato.


Teksto autorius:

Gleb Lisikh


Tyrimų ir konsultacijų skyriaus direktorius, Info-Tech Research Group