72 procentai IT projektų viršija biudžetą. Trečdalis jų užsitęsia ilgiau nei planuota. Maždaug 20 procentų baigiasi visišku nepasisekimu, kai sistema tiesiog neįdiegiama arba nebenaudojama per pirmus metus.
Šie skaičiai nėra naujiena IT industrijoje, bet jie vis dar stebina vadovus, kurie tikėjosi, kad nauja sistema pakeis kasdienybę per kelias savaites. Realybė paprastai sudėtingesnė.
Gera žinia yra ta, kad dauguma šių nesėkmių kyla iš tų pačių, kartojančių klaidų. Jas žinant, galima jų išvengti. Šiame straipsnyje išsamiai aptarsime 12 dažniausių IT diegimo klaidų, jų priežastis, pasekmes ir konkrečius būdus, kaip jų išvengti.
1. IT sprendimo pirkimas be aiškaus verslo tikslo
Tai bene dažniausia ir brangiausiai kainuojanti klaida. Įmonė nusprendžia diegti naują sistemą ne todėl, kad turi konkretų verslo poreikį, o todėl, kad „konkurentai jau naudoja”, „pardavėjas pasiūlė nuolaidą” arba „tai madinga technologija”.
Kaip tai atrodo praktikoje
Vadovas grįžta iš konferencijos sužavėtas nauja platforma. Per savaitę pasirašoma sutartis. Po trijų mėnesių komanda vis dar bando suprasti, kam ji reikalinga. Po šešių mėnesių sistema tampa brangiu apleistu kampu, kuriuo niekas nesinaudoja.
Kodėl tai kenkia
- Biudžetas išleidžiamas sprendimui, kuris neatitinka realių poreikių.
- Komanda praranda pasitikėjimą naujomis technologijomis (kitas diegimas bus sutiktas su dar didesniu pasipriešinimu).
- Laikas, skirtas diegimui, buvo galima investuoti į sprendimą, kuris tikrai reikalingas.
Kaip išvengti
Prieš bet kokį IT sprendimo pirkimą atsakykite į tris klausimus:
- Kokį konkretų verslo iššūkį sprendžiame? Ne „norime būti inovatyvesni”, o „mūsų užsakymų apdorojimas trunka 4 valandas, o turi trukti 30 minučių”.
- Kaip matuosime sėkmę? Apibrėžkite konkrečius rodiklius: laikas, kaina, klaidų skaičius, klientų pasitenkinimas.
- Kas nutiks, jei nieko nedarysime? Kartais atsakymas būna „nieko baisaus”, ir tai reiškia, kad investicija dar ne pačiu geriausiu laiku.
2. Darbuotojų neįtraukimas į sprendimo pasirinkimą
Sprendimą priima vadovai. Diegia IT komanda. O naudoja eiliniai darbuotojai, kurių niekas nepaklausė. Tai klasikinė schema, vedanti į pasipriešinimą ir žemą sistemos įsisavinimą.
Realus scenarijus
Įmonė diegia naują CRM sistemą. Pardavimų komanda sužino apie tai pirmąją mokymo dieną. Sistema reikalauja pildyti 15 laukų prie kiekvieno kontakto, nors senas procesas reikalavo tik 5. Pardavėjai pradeda reikšti nepasitenkinimą, veda duomenis atsainiai arba toliau naudoja seną Excel lentelę „šalia” naujos sistemos.
Priežastys
- Vadovai mano, kad darbuotojai „prisitaikys”.
- IT komanda renkasi sprendimą pagal techninius kriterijus, ne pagal kasdienį naudojamumą.
- Baiminamasi, kad per daug nuomonių sulėtins procesą.
Sprendimas
- Sudarykite darbo grupę iš skirtingų padalinių atstovų dar prieš renkantis sistemą.
- Surinkite reikalavimus iš tų, kas naudos sistemą kasdien. Klauskite: ką darote dabar? Kas atima daugiausiai laiko? Ko trūksta?
- Leiskite darbuotojams išbandyti 2–3 sistemas bandomuoju režimu ir pateikti atsiliepimus.
- Paskirkite „ambasadorius” kiekvienoje komandoje, kurie padės kolegoms įsisavinti naują įrankį.
3. Neaiškiai apibrėžta projekto apimtis
Projektas prasideda su vienais tikslais, o baigiasi su visiškai kitais. Funkciniai reikalavimai keičiasi kas savaitę. Kiekvienas posėdis prideda naują „mažą papildymą”, kuris iš tikrųjų reiškia papildomas savaites darbo ir tūkstančius eurų biudžeto.
„Apimties šliaužimas” (scope creep) veikia taip
- Pradinis planas: įdiegti naują apskaitos sistemą su bazine funkcionalumu.
- Antra savaitė: „O gal galėtume pridėti ir sandėlio valdymą?”
- Ketvirta savaitė: „Mums reikia ir CRM modulio.”
- Aštunta savaitė: „Klientai nori matyti sąskaitas per mobilią programėlę.”
- Rezultatas: biudžetas viršytas dvigubai, terminai praleisti, komanda perdegusi.
Prevencinės priemonės
- Parašykite techninę specifikaciją (SOW) su konkrečiais darbų sąrašais, terminais ir kainomis. Abu pusės turi ją pasirašyti.
- Sukurkite pakeitimų valdymo procesą. Kiekvienas naujas prašymas turi būti įvertintas pagal kaštus ir poveikį terminams. Tik tuomet priimamas sprendimas: daryti dabar, atidėti kitam etapui ar atmesti.
- Padalinkite projektą į fazes. Pirma fazė: bazinė sistema. Antra fazė: papildomi moduliai. Trečia fazė: integracija su kitomis sistemomis. Kiekviena fazė turi savo biudžetą ir terminus.
4. Nerealistiškas biudžeto planavimas
„Kiek kainuoja sistema?” yra tik pirmas klausimas. Tikroji kaina apima daugybę dalykų, kurių pradinė kainoraščio eilutė neparodo.
Paslėpti kaštai, kurių dažnai nepaskaičiuojama
| Kaštų kategorija | Ką apima | Tipinis dydis vs. licencijos kaina |
|---|---|---|
| Licencijos ir prenumerata | Programinės įrangos kaina | Bazinė suma |
| Diegimas ir konfigūracija | Sistemos pritaikymas, nustatymai | 50–150 % licencijos kainos |
| Duomenų migracija | Perkėlimas iš senos sistemos | 10–30 % projekto vertės |
| Mokymai | Darbuotojų apmokymas | 10–20 % projekto vertės |
| Integracijos | Susiejimas su kitomis sistemomis | 15–40 % projekto vertės |
| Palaikymas ir atnaujinimai | Kasmetinės išlaidos | 15–25 % licencijos kainos per metus |
| Prarastas produktyvumas | Mokymosi kreivės laikotarpis | Sunku apskaičiuoti, bet realus |
Kaip planuoti realiai
- Taikykite „x2″ taisyklę. Pardavėjo nurodytą kainą padauginkite iš dviejų. Tai bus artimesnė realybei suma, apimanti visus papildomus kaštus.
- Numatykite nenumatytų išlaidų fondą (15–20 % viso biudžeto). Kažkas tikrai nepavyks pagal planą, ir turėsite finansinį buferį.
- Skaičiuokite visą nuosavybės kainą (TCO) 3–5 metų perspektyvoje, ne tik pirmųjų metų investiciją.
5. Duomenų migracijos nuvertinimas
„Tiesiog perkelsime duomenis iš senos sistemos į naują.” Ši frazė skamba paprastai, bet duomenų migracija yra viena sudėtingiausių IT diegimo dalių, kuri dažniausiai sukelia vėlavimus ir problemas.
Kodėl migracija sudėtingesnė nei atrodo
Duomenų kokybė. Senoje sistemoje per metus susikaupę:
- Dubliuoti įrašai (tas pats klientas su 3 skirtingais rašybos variantais).
- Tuščios reikšmės privalomuose laukuose.
- Pasenę duomenys (kontaktai, kurie nebeaktualūs).
- Nestandartizuoti formatai (data rašoma ir kaip „2024-01-15″, ir kaip „15/01/2024″, ir kaip „sausis 15″).
Struktūrų neatitikimas. Sena sistema saugo klientų adresą viename lauke, nauja reikalauja atskirų laukų gatvei, miestui, pašto kodui ir šaliai. Reikia transformuoti duomenis, o tai reiškia papildomą darbą ir klaidų riziką.
Istorinių duomenų klausimas. Ar perkeliate visą istoriją? Ar tik paskutinių 2 metų duomenis? Ar senieji duomenys bus pasiekiami kitoje sistemoje? Šie sprendimai turi didelę įtaką ir migracijos trukmei, ir verslo tęstinumui.
Migracijos planas, kuris veikia
- Inventorizuokite duomenis. Kokie duomenys kur saugomi? Koks jų formatas? Kiek įrašų?
- Išvalykite duomenis prieš migraciją. Pašalinkite dublikatus, užpildykite tuščias reikšmes, standartizuokite formatus. Tai daryti senoje sistemoje, ne naujoje.
- Sukurkite migracijos žemėlapį. Koks laukas senoje sistemoje atitinka kokį lauką naujoje? Ar reikia transformacijų?
- Atlikite bandomąją migraciją. Perkelkite dalį duomenų (pvz., 10 %) ir patikrinkite, ar viskas suveikė teisingai.
- Numatykite atsarginį planą. Jei migracija nepavyksta, kaip grįžtate atgal?
6. Per trumpi terminai ir nerealistiški lūkesčiai
„Mums reikia, kad sistema veiktų iki mėnesio pabaigos.” Šis sakinys nuskamba daugelyje vadovų posėdžių. Realybėje vidutinis ERP diegimas trunka 6–12 mėnesių, CRM diegimas 2–6 mėnesius, o net paprastesnio įrankio įsisavinimas užima 4–8 savaites.
Kodėl terminai viršijami
- Pardavėjai žada per daug. „Įdiegsime per 4 savaites” skamba patraukliai pardavimo prezentacijoje, bet retai atitinka tikrovę, kai susiduriama su realiais įmonės procesais.
- Neįvertinamas mokymosi laikotarpis. Sistema gali būti techniškai veikianti, bet jei komanda nemoka ja naudotis, projektas nėra „baigtas”.
- Priklausomybės nuo trečiųjų šalių. Integracija su kita sistema vėluoja, nes kitas tiekėjas turi savo terminus ir prioritetus.
Realistiškas požiūris
- Planuokite etapais. Pirmas etapas (bazinis funkcionalumas) per 2–3 mėnesius. Antras etapas (papildomi moduliai) dar per 2–3 mėnesius. Ir taip toliau.
- Pridėkite buferį. Prie kiekvieno termino pridėkite 25–30 % papildomo laiko. Jei planuojate 8 savaites, skaičiuokite 10–11 savaičių.
- Atskirkite „techninį diegimą” nuo „verslo paruoštumo”. Sistema gali būti įdiegta techniškai, bet verslas bus pasiruošęs ja naudoti tik tada, kai darbuotojai apmokyti, duomenys perkelti ir procesai pritaikyti.
7. Nepakankamas mokymas ir pokyčių valdymas
Galite nusipirkti geriausią sistemą rinkoje, bet jei žmonės nemoka arba nenori ja naudoti, investicija neatsipirks. Mokymas ir pokyčių valdymas dažnai lieka biudžeto „likučiuose”, nors turėtų būti viena didžiausių investicijų.
Kuo skiriasi mokymas nuo pokyčių valdymo
Mokymas atsako į klausimą „kaip naudoti?”. Tai techniniai įgūdžiai: kur spausti, kaip sukurti ataskaitą, kaip įvesti duomenis.
Pokyčių valdymas atsako į klausimą „kodėl naudoti?”. Tai komunikacija apie priežastis, naudą ir lūkesčius. Žmonės priešinasi ne technologijai, o pokyčiui, kurio nepriėmė emociškai.
Dažnos mokymo klaidos
- Vienas mokymas ir tiek. Viena keturių valandų sesija prieš sistemos paleidimą neišmokys žmonių dirbti kasdien. Po savaitės 80 % informacijos bus pamiršta.
- Bendras mokymas visiems. Pardavimų komandai ir buhalterams reikia skirtingų žinių. Vienas „bendras” mokymas nepatenkina nei vienų, nei kitų.
- Tik teorija, be praktikos. Žmonės mokosi darydami, ne klausydami. Mokymai turi apimti realius scenarijus su realiais (ar panašiais į realius) duomenimis.
Efektyvus mokymo planas
- Iki paleidimo: pagrindinis mokymas su svarbiausiais procesais (2–3 sesijos per savaitę).
- Paleidimo savaitė: intensyvus palaikymas, kai mokytojais ar konsultantai sėdi šalia darbuotojų ir padeda realiu laiku.
- Pirmas mėnuo po paleidimo: savaitinės „klausimų ir atsakymų” sesijos, kur komanda gali dalintis problemomis.
- Nuolatiniai mokymai: kas ketvirtį trumpos atnaujinimo sesijos apie naujas funkcijas ir geriausius darbo metodus.
8. Senos sistemos palaikymo plano nebuvimas
Nauja sistema pakeičia seną. Bet kas nutinka su sena sistema? Ar ją iškart išjungiate? Ar paliekate lygiagrečiai veikti? Ar darbuotojai gali grįžti prie seno įrankio, jei naujasis neveikia?
Tipiniai scenarijai ir jų rizikos
Staigus perėjimas (Big Bang). Vieną dieną sena sistema išjungiama, nauja įjungiama. Pigu ir greita, bet labai rizikinga. Jei nauja sistema turi problemų, nėra kur grįžti.
Lygiagretus veikimas. Abi sistemos veikia vienu metu tam tikrą laikotarpį. Saugu, bet brangu, nes darbuotojai turi dirbti dviejose sistemose ir dubliuoti darbą.
Etapinis perėjimas. Skirtingi padaliniai ar procesai perkeliami po vieną. Balansuoja tarp rizikos ir kaštų.
Rekomendacijos
- Mažoms įmonėms su nekritinėmis sistemomis gali tikti staigus perėjimas, bet tik su patikrintu atsarginiu planu ir galimybe grįžti per 24 valandas.
- Vidutinėms ir didelėms įmonėms rekomenduojamas etapinis perėjimas arba trumpas lygiagretaus veikimo laikotarpis (2–4 savaitės).
- Visais atvejais palikite prieigą prie senų duomenų bent 6–12 mėnesių po perėjimo. Kažkas tikrai paklaus „o kur yra ta sena ataskaita iš 2023 metų?”
9. IT saugumo aspektų apleidimas diegimo metu
Kai komanda susikoncentravusi į funkcionalumą ir terminus, saugumas dažnai nustumiamas į šoną. „Pirmiausia paleiskime, o saugumu pasirūpinsime vėliau.” Tai receptas problemoms.
Dažniausios saugumo spragos diegimo metu
- Administratoriaus prieiga visiems. Diegimo metu „patogumui” visiems suteikiama pilna prieiga. Po diegimo šie leidimai lieka nepakeisti.
- Testiniai duomenys gamybinėje aplinkoje. Testavimui naudojami realūs klientų duomenys, kurie vėliau lieka neapsaugoti.
- Neužšifruoti duomenų perdavimai. Sistemos bendrauja tarpusavyje be šifravimo, nes „tai vidinis tinklas”.
- Nesukonfigūruotas audito žurnalas. Niekas nefiksuoja, kas ką daro sistemoje. Jei kažkas nutinka, neįmanoma atsekti priežasties.
Saugumo kontrolinis sąrašas diegimui
- [ ] Apibrėžtos vartotojų rolės ir prieigos teisės pagal „mažiausių privilegijų” principą
- [ ] Įjungtas dviejų faktorių autentifikavimas (2FA) administraciniams prisijungimams
- [ ] Duomenų perdavimas tarp sistemų šifruotas (TLS/SSL)
- [ ] Testavimui naudojami anonimizuoti, ne realūs duomenys
- [ ] Sukonfigūruotas audito žurnalas ir pranešimai apie įtartiną veiklą
- [ ] Atliktas saugumo testavimas (penetration testing) prieš paleidimą
- [ ] Parengtas incidentų reagavimo planas
10. Integracijos su esamomis sistemomis ignoravimas
Nauja sistema retai veikia vakuume. Ji turi „kalbėtis” su kitomis sistemomis: apskaita, CRM, el. parduotuve, sandėlio valdymu, el. paštu. Jei integracija neplanuojama nuo pat pradžios, vėliau ji tampa skausmingai brangia ir sudėtinga.
Kas nutinka, kai integracija apmąstoma per vėlai
- Duomenų silosai. Nauja sistema veikia atskirai, ir darbuotojai vis tiek turi rankiniu būdu perkėlinėti duomenis tarp senų ir naujos sistemos.
- Dvigubas darbas. Ta pati informacija vedama dviejose sistemose, nes jos nesinchronizuoja.
- Nesuderinamumo problemos. Paaiškėja, kad nauja sistema nepalaiko reikiamų API, arba sena sistema per daug pasenusi, kad ją būtų galima integruoti.
Kaip planuoti integracijas nuo pradžios
- Dar prieš renkantis naują sistemą, patikrinkite, ar ji turi API ir ar palaiko integracijas su jūsų esamomis sistemomis.
- Sudarykite integracijos žemėlapį: kokios sistemos turi keistis duomenimis ir kokia kryptimi (vienpusė ar dvipusė sinchronizacija).
- Įtraukite integracijos kaštus į biudžetą. Tai ne „gal vėliau”, o pirmo etapo dalis.
- Testuokite integracijas atskirai prieš paleidžiant visą sistemą. Viena neveikianti integracija gali sustabdyti visą darbą.
11. Pardavėjo pasirinkimas vien pagal kainą
Pigiausia pasiūlymas dažnai kainuoja daugiausiai. Tai nėra klišė, tai statistika. Pardavėjai, kurie siūlo žemiausią kainą, dažnai tai pasiekia mažindami tai, kas nematoma: patirtį, palaikymo kokybę, dokumentaciją, testavimo apimtį.
Ženklai, kad pardavėjas gali sukelti problemų
- Per daug žada. „Taip, galime viską, ką norite, per pusę kainos.” Jei kažkas skamba per gerai, greičiausiai taip ir yra.
- Neturi referencijų jūsų industrijoje. Pardavėjas, kuris diegė sistemas tik mažmeninėje prekyboje, gali nesuprasti gamybos įmonės procesų specifikos.
- Neaiški palaikymo struktūra. Kas nutiks po diegimo? Ar yra palaikymo komanda? Koks reakcijos laikas? Ar palaikymas įeina į kainą, ar mokamas atskirai?
- Didelis darbuotojų keitimasis. Jei pardavėjo komanda keičiasi kas kelis mėnesius, kiekvieną kartą nauji žmonės turės iš naujo suprasti jūsų projektą.
Kaip vertinti pardavėją protingai
- Prašykite ne mažiausios kainos, o geriausios vertės. Vertė = rezultatas, kurį gausite, padalintas iš visos investicijos (pinigų ir laiko).
- Kalbėkite su esamais klientais. Prašykite 3–5 kontaktų ir klauskite: ar projektas tilpo į biudžetą? Ar terminai buvo laikomasi? Kaip veikia palaikymas po diegimo?
- Vertinkite ilgalaikę partnerystę. Diegimas trunka mėnesius, bet palaikymas ir plėtra, metus. Rinkitės partnerį, su kuriuo norėtumėte dirbti 3–5 metus.
12. „Paleidome ir pamiršome” mentalitetas
Paskutinė, bet ne mažiau svarbi klaida: manyti, kad diegimas baigiasi sistemos paleidimo dieną. Realybėje paleidimas yra tik pradžia.
Kas vyksta po paleidimo
Pirmos 2 savaitės: darbuotojai susiduria su situacijomis, kurių mokymuose nebuvo. Atsiranda klausimų, klaidų, nusiskundimų. Tai normalu, bet reikia greitos reakcijos.
Pirmi 3 mėnesiai: sistema „nusistovi”. Paaiškėja, kurie procesai veikia gerai, o kurie reikalauja koregavimo. Renkama grįžtamoji informacija, taisomi trūkumai.
6–12 mėnesiai: laikas vertinti, ar sistema pasiekė numatytus tikslus. Ar greitis padidėjo? Ar klaidų sumažėjo? Ar klientų pasitenkinimas pakilo?
Nuolatiniai darbai: reguliarūs atnaujinimai, saugumo pataisos, naujų darbuotojų mokymas, procesų optimizavimas, naujų funkcijų diegimas.
Po diegimo palaikymo struktūra
| Laikotarpis | Palaikymo intensyvumas | Pagrindiniai darbai |
|---|---|---|
| 1–2 savaitės po paleidimo | Intensyvus (kasdien) | Klaidų taisymas, skubus darbuotojų palaikymas |
| 1–3 mėnesiai | Aktyvus (kelis kartus per savaitę) | Procesų koregavimas, papildomi mokymai |
| 3–12 mėnesiai | Reguliarus (kas savaitę) | Optimizavimas, ataskaitų tobulinimas |
| Po 12 mėnesių | Planinis (kas mėnesį) | Atnaujinimai, saugumo pataisos, naujų funkcijų vertinimas |
Kiek iš tikrųjų kainuoja IT diegimo klaidos
Klaidos IT diegimuose turi tiesioginę finansinę kainą, bet prarastos galimybės ir netiesioginiai nuostoliai dažnai kainuoja dar brangiau.
Tiesioginiai nuostoliai
- Biudžeto viršijimas. Vidutiniškai IT projektai viršija pradinį biudžetą 45 procentais.
- Terminų prailginimas. Kiekviena papildoma savaitė reiškia darbuotojų laiką, kuris galėjo būti skirtas kitiems darbams.
- Pakartotinis diegimas. Kai pirmas bandymas nepavyksta ir reikia pradėti iš naujo (su kitu pardavėju ar kitu sprendimu), ankstesnė investicija tampa nuostoliu.
Netiesioginiai nuostoliai
- Darbuotojų motyvacija. Po nesėkmingo diegimo komanda tampa skeptiška bet kokiems pokyčiams. Kitas projektas susidurs su dar didesniu pasipriešinimu.
- Kliento patirtis. Jei sistema veikia su trikdžiais, klientai tai pajunta. Lėtesnis aptarnavimas, klaidos sąskaitose, prarastos užsakymų detalės, visa tai kenkia kliento pasitikėjimui.
- Konkurencinis pranašumas. Kol jūs sprendžiate diegimo problemas, konkurentai, kurie sėkmingai įdiegė panašią sistemą, jau naudojasi jos privalumais.
Sėkmingo IT diegimo kontrolinis sąrašas
Prieš pradedant bet kokį IT diegimo projektą, peržiūrėkite šį sąrašą. Kiekvienas punktas atspindi vieną iš aptartų klaidų ir padeda jos išvengti.
Pasiruošimo fazė
- [ ] Aiškiai apibrėžtas verslo tikslas su konkrečiais matavimo rodikliais
- [ ] Sudaryta darbo grupė iš skirtingų padalinių atstovų
- [ ] Parengta detali techninė specifikacija su funkcijų sąrašu
- [ ] Apskaičiuota visa nuosavybės kaina (TCO), ne tik licencijos
- [ ] Numatytas nenumatytų išlaidų fondas (15–20 %)
- [ ] Įvertinti ir pasirinkti 2–3 galimi pardavėjai
- [ ] Patikrintos integracijos galimybės su esamomis sistemomis
Diegimo fazė
- [ ] Projektas padalintas į aiškias fazes su tarpiniais tikslais
- [ ] Sukurtas duomenų migracijos planas ir atliktas duomenų valymas
- [ ] Nustatytas pakeitimų valdymo procesas
- [ ] Paruošta testavimo aplinka su anonimizuotais duomenimis
- [ ] Atliktas saugumo auditas ir nustatytos prieigos teisės
- [ ] Parengtas mokymo planas su skirtingomis programomis skirtingoms komandoms
Po diegimo
- [ ] Veikia intensyvaus palaikymo režimas (pirmos 2 savaitės)
- [ ] Surinkta grįžtamoji informacija iš darbuotojų po pirmo mėnesio
- [ ] Suplanuoti reguliarūs papildomi mokymai
- [ ] Nustatytas sistemos veikimo stebėjimo procesas
- [ ] Palikta prieiga prie senosios sistemos duomenų
- [ ] Suplanuotas sėkmės vertinimas po 3, 6 ir 12 mėnesių
Ką daryti, jei diegimas jau įstrigo
Jei skaitote šį straipsnį ir atpažįstate savo situaciją, dar ne vėlu koreguoti kursą. Štai trys žingsniai, kurie padeda išjudinti sustojusį projektą:
1. Sustokite ir įvertinkite. Neskubėkite pirmyn, kai matote, kad kryptis neteisinga. Surinkite komandą, aptarkite, kas veikia ir kas ne. Identifikuokite 3 didžiausias problemas.
2. Perprioritizuokite. Galbūt bandote padaryti per daug vienu metu. Sumažinkite apimtį iki minimumo, kuris duotų verslo vertę. Paleiskite tą minimumą ir tik tuomet plėskite.
3. Įtraukite nepriklausomą vertintojį. Kartais vidinė komanda per giliai įklimpusi, kad matytų situaciją objektyviai. Nepriklausomas IT konsultantas gali per kelias dienas identifikuoti pagrindines problemas ir pasiūlyti sprendimus.
Pabaigai
IT diegimas nėra technologinis projektas. Tai verslo pokytis, kuriame technologija yra tik vienas iš komponentų. Sėkmė priklauso ne nuo to, kokią sistemą pasirinkote, o nuo to, kaip ją planuojate, diegiate ir įsisavinate.
Kiekviena iš 12 aptartų klaidų turi bendrą bruožą: jos kyla ne iš technologinių problemų, o iš planavimo, komunikacijos ir lūkesčių valdymo spragų. Gera žinia ta, kad šias spragas galima užpildyti be papildomų technologinių investicijų, reikia tik disciplinos, aiškumo ir pasiryžimo padaryti dalykus teisingai nuo pat pradžios.
Pradėkite nuo vieno klausimo: kurios iš šių klaidų yra aktualiausios jūsų dabartiniam ar planuojamam IT projektui? Atsakymas į šį klausimą jau yra pirmas žingsnis teisinga kryptimi.