Iepriekšējā bloga ierakstā iesāku rakstīt par faktoriem, kas jāņem vērā plānojot biznesa sistēmu ieviešanu. Šodien vēlos turpināt un pabeigt, un ļoti priecāšos par papildinājumiem un komentāriem no auditorijas.
6. Projekta dzīves cikla stratēģija
Šī ir ļoti populāra diskusija mūsdienās. Divas pretējas projektu ieviešanas filozofijas ar evaņgelistiem un piekritējiem katrai no tām. Lai pilnvērtīgi izprastu vienu un otru, būtu jāraksta atsevišķs blogs. Gan vienai, gan otrai pieejai mēs veicam apmācības, kā arī pieejami dažādi mūsu bloga ieraksti.
| Ūdenskritums (Waterfall) | Dinamiska (Agile) | |
| Plusi | Plaša resursu pieejamība. Tradicionāla pieeja programmatūras izstrādē. | Daudz dinamiskāka un elastīgāka pieeja izstrādei. It īpaši pielāgota mazām un dinamiskām organizācijām. Var nekavējoties piegādāt rezultātu un ieguvumus biznesam. Piegādā noteiktajā budžetā un laikā vislielāko iespējamo tajā brīdī biznesam nepieciešamo vērtību. |
| Mīnusi | Dizaina fāze tipiski aizņem ilgāku laiku. Ilgs laiks līdz tiek saņemts pirmais taustāms un izmantojams rezultāts. Daļa no projekta sākumā uzstādītām prasībām nav aktuālas kad projekts ir piegādāts. | Problemātiski standartizēt un apstiprināt visus biznesa procesus pirms programmatūras izstrādes (apstiprināt kopējo bildi). Nepieciešama apmācīta projekta komanda darbā ar Agile pieeju.Lielāka cilvēkresursu iesaiste no pasūtītāja puses. |
Agile filozofija ir pierādījusi sevi visā pasaulē kā ļoti efektīva metode projektu ieviešanai. Visbiežāk tā ir vai nu piegādātāju, vai pasūtītāju domāšana un izpratnes (pierādījumu) trūkums, kas liedz šo metodi izmantot. Ir dzirdēts, ka cilvēkiem neizdevušos projektos patīk vainot tieši Agile pieeju, respektīvi, ka tieši Agile pieejas dēļ projekts izgāžas. Tomēr ir vērts paskatīties no citas perspektīvas – vai tad visi Waterfall projekti izdodas? Un kādi tad ir patiesie neizdošanās iemesli – vai metode vai tomēr projekta organizācija un cilvēku sagatavotība? Lai darbotos pēc Agile filozofijas, ir jāmaina sava domāšana un ieradumi. Latvijā ir vairākas organizācijas, kas uzņēmumiem palīdz ieviest Agile principus savos uzņēmumos. Labprāt ieteikšu atbilstošāko jūsu projektam.Waterfall pieeja, protams, ir veca un pārbaudīta. Tomēr mūsdienu dinamiskajā pasaulē lielākos projektos Waterfall pieeja, salīdzinājumā ar Agile, rada daudz riskus un nepatīkamas sekas, kā piemēram tas, ka projekta sākumā definētās prasības projekta beigās nav vairs biznesam aktuālas. Ir sastopamas situācijas, kad atslēgas cilvēkiem uzņēmuma komandā rodas personīgās barjeras pieņemt Agile projektus. Lai tās identificētu un pārvarētu, sazinieties ar mani.
7. Sistēmas instanču stratēģija
Šis punkts vairāk attiecas uz starptautiskiem uzņēmumiem un šeit pieeja svārstās no vienas centralizētas sistēmas instances (instane – konkrētās sistēmas instalācija), pie kuras slēdzas klāt visas ģeogrāfiskās un funkcionālās uzņēmuma vienības, līdz vairākām atsevišķām instancēm, kuras var tikt izvietotas, piemēram, pa reģioniem, biznesa vienībām utt.
| Viena centralizēta instance | Vairākas instances | |
| Plusi | Viena kopēja datubāze. Viena kopēja biznesa pieeja sistēmas izmantošanā. Pilnīga datu pārskatāmība, bieži iespējama reālā laikā. Viegla datu konsolidācija. Efektīva IT resursu izmantošana | Bieži vieglāk nodrošināt valsts lokālās likumdošanas un fiskālās prasības.Bieži vieglāk nodrošināt lokālo biznesa un datu uzskaites specifiku. |
| Mīnusi | Lielākas investīcijas. Sarežģītāk ieviest.Mazāka lokālā funkcionālā elastība. | Vairākas ERP datubāzes. Grūtāk nodrošināt vienotu datu struktūru. Nepieciešams ieviest datu konsolidācijas rīkus.Ierobežota globālo datu pārskatāmība.Mazāk efektīva IT resursu izmantošana. |
Iemesli izvēlēties veidot dažādas instances var būt dažādi. Savā pieredzē atminos divus gadījumus – pirmajā šāda stratēģija tika izvēlēta piespiedu kārtā, jo sistēma nespēja nodrošināt drošu un ātru datu apmaiņu, lai lietotāji varētu strādāt vienā globālā datubāzē no visām lokācijām. Otrajā – dažādu ģoegrāfisko novietojumu specifika bija tik atšķirīga, ka racionālāk nodrošināt vairākas datubāzes ar savu specifiku (sīkāk 9. punktā). Respektīvi, ir jāizvērtē, vai sistēma ir spējīga ar vienu instanci nodrošināt ērtu online darbu visām lokācijām, vai spēj nodrošināt visu ienākošo un izejošo datu apjomu vienā datubāzē, kā arī vai atmaksājas vairāku valstu lokālo specifiku apvienot vienā.
8. Biznesa sistēmas pielāgošanas stratēģija
Šeit būs runa tikai par tām sistēmām, kuras tirgū tiek piedāvātas kā gatavs produkts ar noteiktu ierobežotu funkcionalitāti. Un ko darīt, ja ar šo ierobežoto funkcionalitāti nepietiek?
| Bez pielāgošanas | Ar pielāgošanu | |
| Plusi | Zemākas sākotnējās izmaksas. Tehniski vienkāršāk. Mazākas uzturēšanas izmaksas. Vieglāka, ātrāka un lētāka pāreja uz jaunākām versijām. | Mazāka organizācijas darbinieku pretestība. Nodrošina iespēju izmantot esošos organizācijas biznesa procesus un tos mainīt atbilstoši tirgus situācijai. |
| Mīnusi | Vairāk jāpielāgo esošie biznesa procesi, lai atbilstu risinājuma funkcionalitātei. Lielāka pretestība no organizācijas darbinieku puses. Programmatūra nosaka biznesa procesus – ierobežo dinamiku un konkurētspēju. | Palielina projekta tehnisko sarežģītību. Lielākas uzturēšanas izmaksas. Sarežģītāka, ilgāka un dārgāka pāreja uz jaunākām versijām. Palielina projekta nezināmos un neizdošanās riskus. |
Šī stratēģija pārsvarā tiek izvērtēta salīdzinot pielāgošanas ieguvumus pret pielāgošanas un uzturēšanas ilgtermiņa investīcijām (un riskiem). Tas ir labā pārdomātā scenārijā. Latvijas apstākļos ir nācies redzēt, ka lēmumi tiek pieņemti tikai emocionāli, izejot no ērtības un pieraduma prizmas, kad ir vēlme, lai jaunā sistēma strādā tāpat un vēl labāk kā vecā, kas rezultējas pie jaunās sistēmas koncepcijas izmešanas miskastē un pielāgošanas pēc vecās sistēmas parauga. Ideālā pasaulē piegādātājiem būtu jāatsaka šādi projekti, tomēr “ko tik par naudu neizdarīsi”, arī ar sakostiem zobiem nepamatoti izdabās pasūtītāja darbiniekiem.
9. Sistēma dizaina stratēģija
Šis visvairāk ir aktuāls uzņēmumiem ar ģeogrāfisko novietojumu dažādās valstīs. No perspektīvas, vai ieviest sistēmu ar vienu globālu universālu funkcionalitāti, vai veikt lokālos pielāgojumus katrā lokācijā.
| Globāls dizains | Lokalizēts dizains | |
| Plusi | Zemākas ilgtermiņa IT un uzturēšanas izmaksas. Var paātrināt ieviešanas laiku. Ļauj izmantot shared services modeli. | Vieglāk iegūt lokālo lietotāju atbalstu ieviešanai. Tiek ņemtas vērā lokālas prasības (gan likumdošanas, gan vispārpieņemtās labās prakses).Lielāka lokālā elastība, kas var ļaut pielāgoties lokāliem tirgus konkurences apstākļiem. |
| Mīnusi | Lielāka lokālā pretestība pret sistēmu. Riski saskarties ar neparedzētām lokālām prasībām (gan likumdošanas, gan vispārpieņemtās labās prakses). Mazāka lokālā elastība. | Lielākas ilgtermiņa IT un uzturēšanas izmaksas.Apjomīgāki pielāgojumiTehniski un funkcionāli sarežģītak.Nav savietojams ar shared services modeli. |
Bieži tirgū ir vērojama tendence, kad lielās organizācijas vēlas ieviest vienotu sistēmu visās valstīs, aizvietojot katras valsts lokālo sistēmu ar lokālajiem pielāgojumiem. Šādi projekti ir izdevīgi mātes uzņēmumam, lai standartizētu datu uzskaiti un biznesa procesus, tomēr no lokālajām pārstāvniecībām visbiežāk izpelnās lielu pretestību lokālo ieguvumu trūkuma dēļ. Šeit ir ļoti cītīgi jāizvērtē gan riski, gan investīcijas, lai katra lokālā pārstāvniecība var efektīvi funkcionēt un no globalizācijas necieš ne uzņēmuma konkurētspēja, ne atslēgas darbinieku motivācija.
10. Integrācijas stratēģija
Katrā uzņēmumā no laika gala jau ir kāda sistēma, kura pilda atsevišķas noteiktas funkcijas. Kaut vai tas pats maģiskais un visu varenais Microsoft Excel. Šeit nu ir jautājums – cik plašā mērogā ieviest jauno biznesa sistēmu?
| Pilnībā integrēta vienota sistēma visām uzņēmuma funkcijām | Vairākas savas nozares / industrijas labākās sistēmas | |
| Plusi | Tehniski vienkāršāks risinājums. Vienota platforma, ko darbiniekiem apgūt. Ciešāka un pilnvērtīgāka funkcionalitāšu un datu integrācija. | Bieži konkrētai funkcijai var atrast atsevišķu ļoti labu sistēmu. Lielākas funkcionālās iespējas Mazākas pārmaiņas organizācijā. |
| Mīnusi | Vienota sistēma nevar būtu vienlīdz laba visām funkcijām, visām darbinieku lomām. Lielākas pārmaiņas organizācijā un procesos. Procesiem jāpiekāpjas biznesa sistēmas funkcionalitātes priekšā. Var nākties atteikties no specifiskām funkcijām vai to automatizācijas. | Lielāka tehniskā un integrāciju sarežģītība. Datu apmaiņas problēmas starp sistēmām. Lielākas investīcijas uz mazāku lietotāju skaitu. |
Lemjot par to, kurus uzņēmuma procesus apkalpot ar kādu sistēmu, vienmēr ir jāmeklē zelta vidusceļš. Pilnībā integrētas vienotas sistēmas (sauktas par Enterprise Resource Planning (ERP) vai latviski – biznesa vadības sistēma) koncepts ir lielisks, jo vienā sistēmā integrē visus uzņēmuma procesus un datus. Tomēr ne vienmēr šādas sistēmas ieguvumi atsver ieguldījumus. Te ir vismaz divi aspekti:
- ERP sistēmām ir ierobežota funkcionalitāte (kas der visam, neder nekam?). Tā var prasīt pielāgojumus, lai spētu konkrētā procesā nodrošināt tādu pašu funkciju klāstu kā atsevišķa konkrētai industrijai vai administratīvajam procesam izstrādāta sistēma. Bet tas nebūt nenozīmē, ka ieviest konkrēto industrijas sistēmu ir lētāk vai efektīvāk.
- Ir procesi, kurus nekad neatmaksāsies ieviest vienā globālā sistēmā, un ir daudz efektīvāk tos atstāt ārpus ERP un nodrošināt (vai nenodrošināt) integrāciju.
Piemēram, daļai ERP sistēmu ir vāja lietvedības un darba plūsmu funkcionalitāte. Ir nepieciešams izlemt – turpināt to darīt Excel programmā, pielāgot ERP sistēmu, vai iegādāties lietvedības risinājumu un to integrēt ar ERP. Līdzīgi ir ar e-komercijas funkcionalitāti. Lēmums ir atkarīgs no biznesa procesu specifikas konkrētā organizācijā.
11. Lietotāju apmācības stratēģija
Tāpat kā izglītības sistēmā Latvijā un citviet pasaulē, tāpat arī apmācībās ieviešot jaunu sistēmu tiek savākta cilvēku grupa ar dažādām personībām un uztveres spējām, tomēr saturs tiek pasniegts viens un vienā formātā visai grupai. Savukārt, pretēja ir individuāla pieeja ar uzsvaru uz katru konkrētu personību.
| Standarta klasiskās apmācības | Pilna pārmaiņu vadības pieeja | |
| Plusi | Viegli un ātri organizējams. Zemākas apmācību izmaksas. | Pārliecība par katra individuālā darbinieka kompetenci sistēmas izmantošanā. Pārliecība par katra individuālā darbinieka gatavību strādāt pēc jaunās pieejas un ar jaunajiem procesiem. Lielāka lietotāju iesaiste un motivācija.Lielāks lietotāju atbalsts.Mazāk kļūdas un atbalsta pieprasījumi pie sistēmas palaišanas. |
| Mīnusi | Nenodrošina pārliecību par katra lietotāja izpratni un gatavību lietot sistēmu un jaunos biznesa procesus.Riski [pārāk] lieliem lietotāju atbalsta darbiem sistēmas palaišanas brīdī. Riski kļūdām sistēmas izmantošanā. Riski neizmantot pilnu sistēmas potenciālu dēļ nezināšanas.Lielāka lietotāju pretestība. | Lielākas investīcijas pārmaiņu plāna izstrādē un realizācijā. |
Protams, ar gala lietotāju informēšanu un uzklausīšanu ir jāstrādā no paša projekta sākuma. Tomēr apmācības, sistēmas akcepttestēšana un palaišana produkcijā ir atslēgas soļi, kur ir svarīgi, lai gala lietotāji ir maksimāli ieinteresēti un motivēti strādāt pēc jaunajiem biznesa procesiem un izmantot jauno sistēmu. Pieredze rāda, ka parastas apmācības vai lietotāju instrukcijas strādā ļoti vāji, un piegādātāji labprāt noveļ dažādas palaišanas aiztures un problēmas uz pasūtītāja darbinieku nekompetenci. Tad nu lūk – ir jāparūpējas, lai darbinieki ir kompetenti un jūtas droši jaunajā vidē.
Apkopojums
Uzskaitītie punkti noteikti ir tas minimums, par ko ir jādomā, ieviešot kādu konkrētu industrijas risinājumu vai globālu ERP sistēmu. Tas palīdzēs ne tikai atlasīt pareizāko risinājumu, bet arī paredzēt riskus, kas saistās ar vienas vai otras apzinātas stratēģijas izvēli. Kā arī tas palīdzēs atrast paredzamās “slēptās” investīcijas, par kurām piegādātājs nav pastāstījis. Bonusā – pēc piegādātāja spējas komentēt šos punktus ir iespējams spriest par viņa izpratnes līmeni sistēmu ieviešanā.