Rešitev je izbrana, izvajalec jo nastavlja in v podjetju se odpre vprašanje, ali naj vsi preidejo nanjo hkrati. Pilotna uvedba na to vprašanje odgovori z resničnim delom: sistem za upravljanje dokumentov ali poslovni informacijski sistem najprej začne delati v izbranem procesu, pri ekipi, ki ta proces izvaja, in v vnaprej omejenem obdobju. Napake, ki se pri tem pokažejo, zadenejo to ekipo in ne vseh hkrati.
Pilotna uvedba programske rešitve je prva resnična raba izbranega in nastavljenega sistema. Pred začetkom so dogovorjeni obseg, merila uspeha in oseba, ki ob koncu odloči, ali rešitev uvedete v druge ekipe, jo prej prilagodite ali jo ustavite.
Pilot pokaže, česar predstavitev ponudnika ne more: ali nastavitve nosijo resnične zadeve z izjemami vred, ali proces v sistemu teče po vašem standardu, ali ljudje svoje korake zmorejo sami in ali so podatki in pravice dostopa pravilni. Kako primerjati ponudbe in kako rešitev iz ožjega izbora preizkusiti še pred podpisom, opisuje prispevek o izbiri programske rešitve. Pilotna uvedba pride na vrsto, ko je ta korak za vami.
Za pilot izberite proces, za katerega je standard že dogovorjen, da se nastavitve lahko oprejo na zapisan način dela. Proces naj bo značilen za delo, ki bo pozneje prešlo v sistem. Najpreprostejši proces pokaže premalo. Procesa, katerega zastoj bi ustavil poslovanje, za prvi preizkus ne izberite. Pomaga, če ima jasen začetek in konec, da lahko vsako zadevo spremljate do zaključka.
Ekipo sestavljajo ljudje, ki bodo z rešitvijo res delali. Koristno je, če je med njimi kdo, ki novostim ni posebej naklonjen, a je pošten: njegove pripombe pridejo na dan, ko jih je še mogoče upoštevati. Vodja ekipe mora imeti čas za pilot.
Obdobje ima zapisan začetek in konec. Trajati mora dovolj dolgo, da pilot zajame celoten proces z izjemami in z dogodki, ki se v njem ponavljajo, na primer zaključek meseca, če ga proces pozna. Pilot brez datuma konca lahko počasi preraste v delno uvedbo, o kateri ni nihče odločil.
Pred začetkom poimenujte še vloge:
Zapišite tudi, kaj v pilot ne sodi: drugi procesi, povezave, ki še niso vklopljene, in želje, ki presegajo dogovorjeni standard. Kar ni izrecno izločeno, se med pilotom rado znajde v njem.
Merila zapišite, preden pilot začne, in jih potrdita lastnik procesa in vodja pilota. Merilo, ki ga določite po koncu, se prilagodi temu, kar se je zgodilo, in zaključni pregled postane izmenjava vtisov.
Vsako merilo potrebuje izhodišče, torej podatek o tem, kako proces teče danes. Vzemite ga iz popisa procesa ali iz vzorca nedavno zaključenih zadev. Brez izhodišča lahko ob koncu rečete le, da je bilo v novem sistemu kar dobro, ne pa, ali je bolje kot prej.
Merila razdelite na obvezna, ki morajo biti izpolnjena pred uvedbo v druge ekipe, in na tista, ki jih je mogoče doseči tudi po prilagoditvi. Zadeva, ki je v sistemu ni mogoče pripeljati do konca, sodi med obvezna merila, nerodno poimenovano polje med druga.
| Merilo | Izhodišče danes | Kako merite v pilotu | Prag za nadaljevanje |
|---|---|---|---|
| Proces teče po standardu, z izjemami vred | Zapisani standard procesa | Vsaka zadeva iz pilota je zaključena v sistemu, izjeme gredo po zapisani poti | Nobena zadeva ni zaključena mimo sistema |
| Čas od prejema do zaključka zadeve | Vzorec nedavno zaključenih zadev | Datumi začetka in zaključka v sistemu | Ne daljši kot danes |
| Zadeve, vrnjene zaradi manjkajočih podatkov | Vzorec nedavno zaključenih zadev | Vrnitve, zabeležene v sistemu | Manj kot danes |
| Iskanje dokumenta | Kako danes poteka iskanje zadnje veljavne različice | Iskanje na resničnih zadevah iz pilota | Vsak pilotni uporabnik ga najde sam |
| Samostojnost uporabnikov | Izhodišča ni | Vprašanja ključnemu uporabniku, zabeležena v dnevniku | Uporabniki svoje korake opravijo brez pomoči |
| Odprte napake | Izhodišča ni | Dnevnik napak po resnosti | Nobene odprte napake, ki ustavi delo |
| Podatki in dostop | Vloge iz standarda procesa | Pregled vlog in pravic v sistemu | Vsak vidi le, kar potrebuje za svoje korake |
Kjer je izhodišče izmerjeno, zapišite prag z izmerjeno vrednostjo, da ob koncu ni treba razlagati, kaj pomeni »ne daljši kot danes«.
Pripravljeni primeri v preizkusnem okolju zadoščajo za preverjanje nastavitev in za uvajanje. Pilot sam naj teče na resničnih zadevah, saj pripravljen primer nima nepopolnih podatkov in nepričakovanih izjem, ki jih prinese resnično delo.
Z resničnimi zadevami pridejo v sistem tudi osebni podatki strank, zaposlenih ali dobaviteljev. Splošna uredba o varstvu podatkov (GDPR) zanje med drugim določa:
Določbi ne odgovorita na vprašanje, ali naj pilot teče na preizkusnih ali resničnih podatkih. Naslednja priporočila so dobra praksa in ne povzemajo besedila uredbe:
Ekipi povejte, čemu pilot služi. Preizkušajo se rešitev, njene nastavitve in zapisani proces, zato so pripombe zaželene in lahko spremenijo nastavitve ali standard.
Kaj posamezna vloga v novem procesu potrebuje in česa še ne zna, je dobro ugotoviti pred pilotom. Kako to oceniti, opisuje prispevek o oceni digitalnih kompetenc zaposlenih. Za pilot sam pripravite:
Delo v novem sistemu je lahko na začetku počasnejše. Če ekipi ne olajšate drugega dela, bodo zamude v pilotu bolj kot o rešitvi govorile o preobremenjenosti ljudi.
Napake in pripombe zbirajte v skupnem dnevniku, ki ga vidijo vodja pilota, ključni uporabnik in izvajalec. Pripomba, poslana po elektronski pošti ali povedana na hodniku, se rada izgubi.
Vsak vpis naj pove:
Vrsta vzroka pove, kdo težavo odpravi: napako sistema izvajalec, nastavitev skrbnik sistema, vrzel v standardu lastnik procesa, nejasno navodilo tisti, ki uvaja uporabnike. Če vse pripombe pristanejo pri izvajalcu, bo ta urejal tudi vprašanja, o katerih bi moralo odločiti podjetje.
Posebej zapisujte obvode. Stranska preglednica ali zadeva, poslana naprej po elektronski pošti, ker v sistemu ne gre, je ugotovitev, tudi če se nihče ne pritoži. Pokaže, kje sistem ali standard ne nosita dela.
Dnevnik redno pregledujte z izvajalcem, na primer vsak teden, in vsako spremembo nastavitev zapišite z datumom. Ob koncu boste vedeli, na katero različico nastavitev se nanaša rezultat, in prav to različico boste prenesli v druge ekipe.
Ali bo pilotna ekipa nekaj časa delala po starem in v novem sistemu hkrati, odločite pred začetkom.
Brez vzporednega dela ekipa dela samo v novem sistemu, stari ostane le še za branje. Podatki se ne podvajajo in pilot dobi pravi pritisk resničnega dela. Potrebujete pa zapisan postopek za primer, ko se novi sistem ustavi: kje ekipa takrat zabeleži zadeve in kako jih pozneje vnese.
Vzporedno delo je smiselno, kadar je napaka draga in je rezultate obeh poti mogoče primerjati, na primer pri dokumentih, ki gredo iz podjetja k strankam ali državnim organom. Plačate ga z dvojnim vnosom. Zapisa se začneta razhajati, čim kdo zadevo popravi le v starem ali le v novem sistemu.
Ne glede na izbiro zapišite, kateri sistem hrani veljavni zapis posamezne zadeve in do katerega datuma vzporedno delo traja. Vzporedno delo brez tega datuma se samo od sebe ne konča.
Kdo odloči, zapišite pred začetkom. Odloči lastnik procesa, ob njem pa vodstvo, kadar odločitev pomeni nov strošek ali zavezuje druge ekipe. Izvajalec in vodja pilota prispevata ugotovitve, odločitev pa ni njuna: izvajalec rešitev uvaja in procesa ne nosi, vodja pilota pa je preblizu vsakodnevnim težavam.
Na zaključnem pregledu so na mizi merila s pragovi in izmerjenimi vrednostmi, odprte napake po resnosti in vzroku, obvodi, pripombe uporabnikov in napor, ki ga je pilot zahteval.
Odločitev zapišite z datumom in razlogi. Na njej sloni načrt uvedbe.
Načrt uvedbe zgradite iz tega, kar je pokazal pilot: vrstni red ekip, datum prehoda za vsako, uvajanje po vlogah, prenos podatkov in okrepljena podpora na začetku. Pilotni uporabniki lahko postanejo ključni uporabniki naslednjih ekip, ker so težave novega sistema že srečali. Nastavitve, ki jih je pilot potrdil, zapišite kot izhodiščno različico in jih med uvedbo ne spreminjajte brez zapisa.
Kjer je odstopanje v pilotu razkrilo, da je standard napačen ali nepopoln, ga lastnik procesa popravi, nastavitve pa nato sledijo popravljenemu standardu. Kaj mora tak zapis vsebovati, opisuje prispevek o standardizaciji procesov.
Nekatere odločitve iz pilota veljajo širše od pilotnega procesa: kdo sme v sistemu odobriti, kako se zadeve poimenujejo in kdo odloča o dostopu. Takšne odločitve sodijo v notranja pravila podjetja, da jih naslednje ekipe ne bodo sprejemale vsaka po svoje.
V izobraževalnem programu 365°Digital so optimizirane in implementirane programske rešitve korak na poti do digitalnega poslovanja, neposredno za optimizacijo in standardizacijo procesov. Stran program priporoča tudi informatikom, ki skrbijo za informacijske sisteme upravljanja z dokumenti ali za informacijsko varnost. O tem, kako pri vas omejiti in presoditi pilot, se lahko pogovorimo na svetovanju.
Pilot z mejami, vnaprej dogovorjenimi merili in imenovanim odločevalcem se konča z odločitvijo, ki jo lahko utemeljite.
Prijavite se na naše inspiracijske e-novice in prejmite brezplačni priročnik:
»Odkrijte svojo hierarhijo vrednot«
MEDARHIV d.o.o., so.p.
Vrečerjeva ulica 14
3310 Žalec
Davčna številka: SI 98579452
Matična številka: 3955338000
Kontaktna številka: 080 48 45
365°Digital © 2026 Vse pravice pridržane.
Spletno stran vzdržuje in nadgrajuje Aithena | Originalna izdelava: Starfiniti d.o.o.
