Kodėl DI projektą reikia valdyti kaip projektą, o ne kaip eksperimentą?
DI projektas nėra vien technologinis bandymas. Jam reikia verslo savininko, apibrėžtos apimties, biudžeto, KPI, rizikų ir sprendimo vartų, kurie leidžia pagrįstai tęsti, keisti arba stabdyti.
Greita santrauka
Eksperimentas gali padėti patikrinti prielaidą, tačiau verslo rezultatą pasiekia tik valdomas projektas su aiškia atsakomybe, ribomis ir sprendimu, ką daryti po piloto.
Kodėl DI projektą reikia valdyti kaip projektą, o ne kaip eksperimentą?
Gamybinėse įmonėse DI iniciatyvos dažnai prasideda nuo įdomaus tiekėjo pristatymo, jutiklių duomenų ar bandomojo modelio. Toks bandymas gali būti naudingas mokymuisi, tačiau savaime jis dar nėra verslo projektas: gali nebūti proceso savininko, aiškaus naudotojo, patvirtinto biudžeto ar susitarimo, kaip rezultatas pakeis gamybos sprendimą. Tuomet komanda sėkmingai pademonstruoja, kad modelis veikia su atrinktais duomenimis, bet niekas neįsipareigoja jį integruoti, prižiūrėti ar panaudoti kasdieniame darbe.
Projektas prasideda nuo business case ir sprendimo, kurį reikia pagerinti. Projekto užsakyme įrašykite verslo problemą, pradinį veiklos rodiklį, siekiamą pokytį, pagrindines prielaidas, apimtį ir tai, kas aiškiai neįeina į pirmą etapą. Pavyzdžiui, kokybės piloto apimtis gali būti viena linija, vienas defektų tipas ir operatoriui pateikiama rekomendacija, o ne autonominis visos gamyklos sustabdymas. Paskirkite vykdomąjį rėmėją, verslo proceso savininką, projekto vadovą, IT / duomenų atsakingą asmenį ir galutinį naudotoją. Rėmėjas pašalina organizacines kliūtis, savininkas atsako už rezultatą, o projekto vadovas koordinuoja apimtį, grafiką, rizikas ir sprendimus.
DI projektams reikia papildomų patikros taškų, nes modelio kokybė, duomenų parengtis ir naudotojų pasitikėjimas paaiškėja darbo eigoje. Plane numatykite duomenų prieinamumo įvertinimą, bazinio KPI fiksavimą, prototipo patikrą atskiroje aplinkoje, realistišką piloto testą ir gamybinės parengties vertinimą. Kiekviename etape užrašykite, kokius įrodymus reikia pateikti, kas juos tvirtina ir koks sprendimas galimas: tęsti, siaurinti ar keisti apimtį, spręsti duomenų problemą, grįžti prie paprastesnės automatizacijos ar stabdyti.
KPI turi apimti ir modelio rodiklį, ir veiklos rezultatą. Pavyzdžiui, defektų aptikimo jautrumas svarbus, tačiau vadovui taip pat reikia žinoti, kiek broko iš tikrųjų išvengta, kiek klaidingų perspėjimų tenka operatoriui ir kaip pasikeitė proceso trukmė. Biudžete numatykite ne tik kūrimą, bet ir duomenų paruošimą, integracijas, įrangą, licencijas ar naudojimo kreditus, mokymus, kibernetinę peržiūrą, palaikymą bei tolesnį modelio tikrinimą. Rizikų registre įvertinkite saugą, kokybę, prastovas, privatumą, intelektinę nuosavybę, tiekėjo priklausomybę ir atsakomybę už sprendimą. Iš anksto susitarkite, kokiomis sąlygomis pilotas stabdomas: trūksta reprezentatyvių duomenų, klaidos viršija priimtiną ribą, verslo savininkas nebegali skirti išteklių arba konservatyviu scenarijumi nauda nepadengia kainos. Tai nėra nesėkmė, o kontroliuojamas sprendimas apsaugoti laiką ir investicijas.
Kaip pradėti ir įgyvendinti
-
Patvirtinkite projekto užsakymą
Nurodykite problemą, naudotoją, proceso ribas, naudą, KPI, prielaidas ir aiškiai neįtrauktus darbus. Patikrinkite, kad visi sutartų dėl pirmojo etapo apimties.
-
Paskirkite sprendimų savininkus
Įvardykite rėmėją, verslo savininką, projekto vadovą, duomenų / IT atsakingus ir naudotojų atstovą. Sutarkite, kas turi teisę keisti apimtį ir priimti go/no-go sprendimą.
-
Suplanuokite etapus ir vartus
Atskirkite problemos patikrą, duomenų vertinimą, prototipą, pilotą ir gamybinį diegimą. Kiekvienam etapui nustatykite rezultatą, terminą, atsakingą asmenį ir patvirtinimo kriterijus.
-
Valdykite rizikas ir pokyčius
Stebėkite duomenų kokybę, saugą, integracijas, tiekėjus, mokymus ir darbuotojų įsitraukimą. Pakeitus prielaidas, atnaujinkite biudžetą, grafiką bei business case.
-
Priimkite aiškų tęsti ar stabdyti sprendimą
Nustatytuose etapuose palyginkite KPI, kainą, riziką ir naudotojų atsiliepimus. Tęskite tik turėdami savininką ir resursus, reikalingus kitam etapui.
Į ką atkreipti dėmesį
- Ar projektas turi verslo savininką, o ne vien techninį entuziastą?
- Ar apimtis ir piloto ribos apsaugo gamybą nuo nekontroliuojamo bandymo?
- Ar yra sprendimo kriterijai, kada pilotą tęsti, keisti ar stabdyti?
- Ar po piloto numatytas biudžetas ir atsakomybė už palaikymą?
Dažniausiai užduodami klausimai
Kuo DI eksperimentas skiriasi nuo DI projekto?
Eksperimentas tikrina prielaidą ribotoje aplinkoje. Projektas turi patvirtintą tikslą, savininką, apimtį, biudžetą, grafiką, rizikų valdymą, priėmimo kriterijus ir planą, kaip rezultatą įtraukti į veiklą.
Kas turėtų būti DI projekto savininkas?
Verslo arba proceso vadovas, kuris atsako už norimą veiklos rezultatą ir gali pakeisti procesą. IT ar duomenų komanda atsako už techninį sprendimą, tačiau viena pati negali garantuoti, kad įmonė panaudos jo naudą.
Kada DI pilotą reikėtų stabdyti?
Kai patikrinus prielaidas nėra pasiekiamų duomenų, priimtino tikslumo ar saugaus darbo scenarijaus, nėra proceso savininko, arba atnaujintas konservatyvus business case nebepriimtinas. Sprendimą ir išmoktą pamoką užfiksuokite.
Reikia įvertinti DI galimybę gamyboje?
Padedu įmonėms įvertinti DI scenarijus, pagrįsti verslo vertę ir suplanuoti atsakingą įgyvendinimą.
Susisiekti