CDO.lt

Dažniausios skaitmeninimo projektų klaidos ir kaip jų išvengti

Skaitmeninimo projektai dažniausiai stringa ne dėl technologijų, o dėl vadybos klaidų: neaiškių tikslų, nesutvarkytų procesų, atsakomybės stokos ir darbuotojų neįtraukimo. Štai klaidos, kurias galima numatyti iš anksto.

Atnaujinta: 7 min.

Dažniausios skaitmeninimo projektų klaidos yra vadybinės, ne techninės. Technologija pasirenkama anksčiau, nei aprašomas procesas, projektas neturi savininko, atstovaujančio verslui, nenustatomas naudos rodiklis, darbuotojai neįtraukiami, o duomenų kokybės klausimas paliekamas „vėlesniam etapui“. Daugumos šių klaidų galima išvengti dar prieš pasirašant sutartį su tiekėju, jei projektas pradedamas nuo tikslų nustatymo, procesų aprašymo ir atsakomybės paskirstymo.

1. Technologija pasirenkama prieš aprašant procesą

Įmonė nusprendžia „įsidiegti naują sistemą“ ar „pradėti naudoti DI“, o tik tada bando suprasti, kokias užduotis pasirinkta technologija turi atlikti. Todėl sistema atkartoja seną netvarką arba tiek pritaikoma, kad jos priežiūra tampa brangi.

Kaip išvengti. Prieš rinkdamiesi sprendimą, aprašykite, kaip procesas vyksta dabar ir kaip turėtų vykti. Užtenka paprastos schemos ir problemų sąrašo. Tada tiekėjų pasiūlymus vertinkite pagal tai, kaip siūlomi sprendimai padeda spręsti jūsų problemas.

2. Nėra verslui atstovaujančio projekto savininko

Projektas priskiriamas IT skyriui arba tiekėjui, o verslo vadovai dalyvauja tik pradžioje ir pabaigoje. Kai kyla klausimų dėl procesų, nėra kam priimti sprendimų, ir projektas sustoja.

Kaip išvengti. Kiekvienas projektas turi turėti verslui atstovaujantį savininką, kuris turi laiko ir įgaliojimų priimti sprendimus. Jei reikia koordinuoti kelių projektų savininkų darbą, tam reikalingas etatinis arba pagal poreikį dirbantis skaitmeninimo vadovas.

3. Nenustatytas naudos rodiklis

„Norime efektyvumo“ nėra tikslas. Be rodiklio ir jo pradinės reikšmės užbaigus projektą neįmanoma pasakyti, ar investicija atsipirko.

Kaip išvengti. Prieš projektą užrašykite 1–3 rodiklius, pavyzdžiui, rankinio darbo valandų per mėnesį skaičių, dienų nuo užsakymo iki išsiuntimo skaičių, klaidų sąskaitose dalį. Užfiksuokite pradines reikšmes ir sutarkite, kada tikrinsite rodiklius. Šabloną rasite puslapyje „Skaitmeninimo strategija“.

4. Per didelė apimtis iš karto

Bandoma vienu projektu pakeisti viską: visus procesus, visas sistemas, visus padalinius. Toks projektas užtrunka ilgiau, kainuoja daugiau, o pirmoji nauda pasirodo per vėlai, kad vadovybė toliau jį remtų.

Kaip išvengti. Skaidykite projektą etapais, kurių kiekvienas duoda išmatuojamą naudą. Pirmąjį etapą turėtų būti įmanoma įgyvendinti per kelis mėnesius.

5. Duomenys paliekami „vėlesniam etapui“

Perkeliant duomenis į naują sistemą aptinkama dublikatų, tuščių laukų ir skirtingų formatų. Jei duomenų valymas nesuplanuotas, jis užima laiko paskutinėmis savaitėmis prieš paleidimą arba į naują sistemą perkeliama netvarka.

Kaip išvengti. Duomenų inventorizaciją ir valymą įtraukite į projektą nuo pradžių, paskirkite atsakingą asmenį ir numatykite bandomąjį duomenų perkėlimą prieš galutinį.

6. Darbuotojai neįtraukiami

Sistema suprojektuojama neįtraukiant žmonių, kurie ja dirbs kasdien. Paleidus sistemą, jie toliau naudoja senas skaičiuokles, nes naujas darbo būdas atrodo lėtesnis ar nesuprantamas.

Kaip išvengti. Įtraukite pagrindinius naudotojus į reikalavimų aprašymą ir testavimą, paaiškinkite pokyčių priežastis, numatykite praktinius mokymus ir vidinius ambasadorius. Paleidę sistemą, kelias savaites rinkite naudotojų atsiliepimus ir greitai šalinkite trukdžius.

7. Per daug pritaikymų

Kiekvienas padalinys nori, kad sistema veiktų tiksliai pagal senąjį procesą. Pritaikymų daugėja, diegimas brangsta, o atnaujinimai tampa sudėtingi.

Kaip išvengti. Standartinius procesus derinkite prie standartinių sistemos galimybių, o pritaikymus palikite tik ten, kur procesas tikrai išskirtinis ir kuria vertę. Prie kiekvieno pritaikymo užrašykite, kokią problemą jis sprendžia.

8. Nekontroliuojama priklausomybė nuo vieno tiekėjo

Įmonė neturi prieigos prie savo sistemų administravimo priemonių, dokumentacijos ar duomenų eksporto funkcijos, o visas žinias turi tiekėjas. Pasikeitus tiekėjui ar jo komandai, kyla rizika įmonės veiklai.

Kaip išvengti. Sutartyje numatykite dokumentacijos pateikimą, administratoriaus prieigos teises, duomenų eksporto galimybę ir žinių perdavimą. Įmonėje turėkite žmogų, kuris bent iš esmės supranta sistemos konfigūraciją.

9. DI naudojamas be taisyklių

Darbuotojai savo iniciatyva naudoja DI pokalbių įrankius ir įkelia į juos klientų duomenis ar sutartis. Vadovybė apie tai sužino tik kilus problemai.

Kaip išvengti. Parenkite trumpas DI naudojimo taisykles ir mokykite darbuotojus. ES dirbtinio intelekto akto 4 straipsnis įpareigoja DI naudojančias organizacijas imtis priemonių darbuotojų DI raštingumui stiprinti (Europos Komisija). Išsamiau skaitykite puslapyje „DI diegimas įmonėje“.

10. Paleidimas be atsarginio plano

Nauja sistema paleidžiama mėnesio pabaigoje ar sezono įkarštyje, neatlikus bandomojo duomenų perkėlimo ir neparengus plano, ką daryti, jei kas nors neveiks. Pirmosiomis savaitėmis kyla krizė, o pasitikėjimas sistema mažėja.

Kaip išvengti. Paleidimą planuokite ramesniu laikotarpiu, atlikite bandomąjį duomenų perkėlimą, aprašykite grįžimo prie ankstesnės sistemos planą ir numatykite sustiprintą pagalbą naudotojams pirmosiomis savaitėmis.

Kontrolinis sąrašas prieš pradedant projektą

Tikslai ir atsakomybė

  • Užrašytas verslo tikslas ir 1–3 rodikliai su pradinėmis reikšmėmis.
  • Paskirtas verslui atstovaujantis projekto savininkas, turintis laiko ir įgaliojimų.
  • Projektas susietas su skaitmeninimo strategija.

Procesai ir duomenys

  • Aprašyta, kaip procesas vyksta dabar ir kaip turėtų vykti.
  • Įvertinta duomenų kokybė, suplanuotas valymas.
  • Pritaikymai pagrįsti ir aprašyti.

Žmonės

  • Pagrindiniai naudotojai įtraukti į reikalavimų aprašymą ir testavimą.
  • Suplanuoti mokymai ir pagalba paleidus sistemą.
  • Numatyti vidiniai ambasadoriai.

Tiekėjas ir rizikos

  • Sutartyje numatyta pateikti dokumentaciją, suteikti prieigos teises ir galimybę eksportuoti duomenis.
  • Numatyti etapai su aiškiais priėmimo kriterijais.
  • Įvertintos saugumo ir asmens duomenų apsaugos rizikos.

Jei norite pradėti nuo bendro vaizdo, atlikite skaitmeninės brandos savitikrą. Ji parodys, kurios jūsų įmonės sritys kelia daugiausia rizikos.

Reikia skaitmeninimo vadovo pagal poreikį?

Trumpai aprašykite situaciją. Atsakysime el. paštu.

Dažniausi klausimai

Kodėl skaitmeninimo projektai vėluoja?

Projektai dažniausiai vėluoja, nes jų pradžioje neaprašomi procesai, vėliau keičiami reikalavimai, projekte turintys dalyvauti darbuotojai neatleidžiami nuo kasdienių darbų ir nėra vieno žmogaus, kuris greitai priimtų sprendimus. Šias rizikas galima sumažinti dar prieš pasirašant sutartį su tiekėju.

Kas turi būti skaitmeninimo projekto savininkas?

Verslo vadovas, už kurio valdomą procesą projektas atsakingas, o ne IT specialistas ar tiekėjas. IT specialistai ir tiekėjai atsako už techninį įgyvendinimą, bet sprendimus dėl procesų, prioritetų ir projekto rezultatų priėmimo turi priimti verslo atstovai. Didesnius projektus koordinuoja skaitmeninimo vadovas.

Ar verta keisti procesus pagal sistemą, ar sistemą pagal procesus?

Dažniausiai verta derinti abu būdus. Standartinius procesus, pavyzdžiui, apskaitą ar pirkimus, pritaikykite prie standartinių sistemos galimybių, o sistemą pritaikykite prie išskirtinių procesų, kurie kuria konkurencinį pranašumą. Kiekvienas pritaikymas didina diegimo ir priežiūros sąnaudas.

Kaip žinoti, ar projektas pavyko?

Tik palyginus iš anksto užrašyto rodiklio reikšmę po projekto su pradine reikšme. Jei rodiklio nebuvo, sėkmė vertinama pagal įspūdį, o tai dažnai reiškia, kad sistema įdiegta, bet nauda neaiški. Rodiklį nustatykite prieš projektą ir patikrinkite jo reikšmę praėjus 3–6 mėnesiams po diegimo.