Miks TI-piloodid tehases surevad demo ja tootmise vahel
Pilootprojekti näidati juhatuse koosolekul, kõik plaksutasid, eraldati eelarve „skaleerimiseks". Pool aastat hiljem tabab arvutinägemine, mis demol tuvastas 98% defektidest, parimal juhul poole, kvaliteedikontrollörid on lõpetanud selle usaldamise ja projekt on vaikselt kolinud „edasi lükatud algatuste" hulka. See pole haruldane rike ega konkreetse integraatori süü. RANDi andmetel lõpeb nii üle 80% ettevõtete TI-projektidest – ja peaaegu alati põhjustel, mis olid nähtavad juba enne alustamist.
Kõige ebameeldivam selles statistikas pole mitte läbikukkumise protsent ise, vaid see, et süüdi on peaaegu kunagi mitte tehnoloogia. RAND uuris 2024. aasta uuringus 65 andmeteadlast ja inseneri, kelle kogemus ulatus 5-st kuni 30 aastani, ning selgitas välja põhjused, miks TI-projektid ei jõua tootmisse. Järeldus kõlab peaaegu solvavalt: kõige levinum läbikukkumise põhjus on see, et juhid ja tehnilised spetsialistid mõistsid erinevalt, millist ülesannet üldse on vaja lahendada. Mitte andmed, mitte mudel, mitte GPU. Ülesandepüstitus.
Tööstuse juhi jaoks on see hea uudis. Kui asi oleks tehnoloogias, jääks vaid oodata mudelite järgmist põlvkonda. Aga kuna asi on juhtimisotsustes – tähendab see, et tulemust saab mõjutada. Allpool on seitse tunnust, et piloot on hukule määratud, mis on kogutud RANDi, McKinsey ja autotööstuse läbikukkumiste analüüsidest. Iga tunnus on küsimus, mida tasub meeskonnale esitada enne, kui kirjutate alla skaleerimise eelarvele.
Kõigepealt mastaabist: miks „piloot õnnestus" ei tähenda midagi
Pilootprojekti käivitamine pole tänapäeval keeruline. Keeruline on viia see seisu, kus seda kasutatakse igapäev kolmes vahetuses ja see mõjutab numbreid kasumiaruandes. Lõhe nende kahe punkti vahel on peamine lõks.
McKinsey toob 2025. aasta aruandes TI skaleerimisest tootmises numbri, mis annab mõelda: vaid 2% tootjatest usub, et TI on täielikult integreeritud nende operatsioonidesse. Umbes kaks kolmandikku on kinni jäänud uuringu- ja üksikute juurutamiste faasi – ehk lõputute pilootprojektide juurde. Sarnase pildi joonistab MIT aruanne, millest kirjutasime eraldi: 95% ettevõtetel pole generatiivne TI andnud mõõdetavat mõju kasumile.
Autotööstuses on see puhtal kujul nähtav. Tööstusharu väljaande Automotive Manufacturing Solutions analüüside järgi ei jõua enamik arvutinägemisel põhinevatest kvaliteedikontrolli projektidest testraku piiridest väljapoole – mitte sellepärast, et need demol defekte halvasti tuvastavad, vaid sellepärast, et demo ja tegelik tootmistsehh on kaks erinevat keskkonda.
Edasi – tunnuste kaupa.
Tunnus 1. Keegi ei suuda nimetada probleemi hinda eurodes
RAND seab ülesandest arusaamatuse läbikukkumise põhjuste hulgas esimesele kohale ja tootmises avaldub see spetsiifiliselt. Pilootprojekt käivitub, sest „tuleb TI-d juurutada" või sest konkurent kiitles konverentsil. Formuleerida, millist konkreetset rahalist kahju projekt katab, ei suuda keegi.
McKinsey fikseerib sama probleemi kvantitatiivselt: enamikel tootjatel puudub TI-algatuste sidumine konkreetsete väärtuse sihtnäitajatega. Projekti ilma probleemi hinnata on võimatu prioriseerida, sulgeda ega edukaks tunnistada – sellel puudub lihtsalt kriteerium. Kuidas sellist ärijuhtumit reaalsete andmetega ehitada, oleme eraldi käsitlenud.
Enne piloodi käivitamist proovige täita üks rida: „see ülesanne maksab meile N eurot kuus, sest …". Kui N-i ei õnnestu välja arvutada – see ei tähenda, et ülesanne on halb. See tähendab, et te ei mõista seda veel piisavalt, et kulutada sellele TI-eelarvet. Võtke see, kus N on ilmne: liini seisak, praagi ümbertöötlus, tarne hilinemise trahv.
Probleemi hinda on keerulisem arvutada, kui tundub. Proovige TI-d 9 reaalsel juhi ulesandel – andmeanaluusist tarnija pretensioonini – tasuta ja ilma registreerimata.
Makset ei nõuta • Teavitus käivitumisel
Tunnus 2. Andmeid selle ülesande jaoks tegelikult pole
Teine levinum põhjus RANDi loetelus – organisatsioonil puuduvad vajalikud andmed. Tehases kõlab see eriti tuttavalt. Andmed justkui on olemas: SCADA kirjutab telemeetriat, MES hoiab töökäske, kvaliteedikontroll peab päevaraamatuid. Aga kui jõutakse mudeli õpetamiseni või promptimiseni, selgub, et pool päevaraamatutest on paberil, SCADA-s pole märgistatud rikete ajalugu ja defektide kirjeldusi kirjutab iga kontrollör omal viisil.
See on seesama andmete killustatus, mille üle autotööstuses kurdetakse: andmed on olemas, kuid laiali paisatud süsteemide vahel, märgistamata ja ühtse formaadi alla viimata. Mudel, mida õpetati demo jaoks puhtal valimil, kohtab tootmises reaalsust – ja langeb.
Enne piloodi tellimist tasub teha aus audit: kus asuvad ülesande andmed, millises formaadis need on, kes neid sisestab ja kui ühtlaselt. Kui selles etapis muutub ebamugavaks – parem korrasta kõigepealt andmed ja alles siis käivita TI. Paberikiht, millest soovitasime alustada, on hea just sellepärast, et see ei nõua puhast ajaloolist valimit – mudel töötab sellega, mida annate talle praegu.
Tunnus 3. Meeskond on armunud tehnoloogiasse, mitte probleemi
Kolmas põhjus RANDis on sõnaselgelt formuleeritud: projekt on rohkem huvitatud uusima tehnoloogia rakendamisest kui reaalse probleemi lahendamisest. Tootmises näeb see välja nii, et kohe hakatakse ehitama arvutinägemisel põhinevat lahendust närvivõrgustiku täiendõppega seal, kus ülesannet lahendaks lihtne teksti-assistent nädala jooksul.
MIT märgib oma aruandes sugulast kalduvust: üle poole generatiivse TI eelarvetest läheb efektsetesse vitriinidesse – müük ja turundus –, samas kui suurimat tasuvust annab igav back-office. Tehases on vitriini analoog „nutikas tsehh" investorite ekskursioonideks; back-office’i analoog – vahetusaruandluse ja pretensiooni töö automatiseerimine, mis juhatuse koosolekul kedagi ei muljet avalda, aga reaalselt säästab tunde.
Üks kontrollküsimus piloodi algatajale: „Kui seda tehnoloogiat poleks olemas, kuidas me seda probleemi lahendaksime?" Kui selget vastust pole – lahendus mõeldi välja enne probleemi. Keerake vestlus mudeli juurest tagasi ülesande juurde.
Tunnus 4. Ülesanne on praegusele TI-le liiga keeruline
Viies põhjus RANDi loetelus – TI-d rakendatakse ülesannetele, mis on selle jaoks liiga keerulised. See pole tehnoloogia surmaotsus, vaid piiride küsimus. TI struktureerib hästi teksti, tuvastab tüüpilisi defekte, valib detailide analooge. Ta tuleb halvasti toime seal, kus on vaja haruldasi sündmusi ilma ajaloota, füüsikalisi arutlusi tundmatu seadmestiku kohta või otsuseid, kus vea hind on inimelu ilma kindlustava kontuurita.
Kasulik on jagada ülesanded kolme korvi: „TI teeb ise", „TI valmistab mustandi, inimene kinnitab", „TI-d praegu ei puutu". Enamik tööstuslikke ülesandeid langeb ausalt keskmisse korvi – ja see on normaalne. Probleemid algavad siis, kui ülesannet kolmandast korvist proovitakse tähtaegade survel esimesse tirida.
Kus TI aitab ja kus vargsi eksib – seda on nahtav ainult praktikas. Avatud moodulis 9 juhi ulesannet tuupiliste vigade analuusiga, tasuta.
Makset ei nõuta • Teavitus käivitumisel
Tunnus 5. Triiv, mis ununeb poole aasta pärast
See on spetsiifiliselt tööstuslik lõks, mida kontoris praktiliselt ei kohta. Arvutinägemisel põhinev mudel, mis käivitamisel suurepäraselt töötas, hakkab mõne kuu pärast vigu tegema – ja mitte sellepärast, et see lõhuti. Muutus valgustus tsehhis, tarnija vahetas terasemarki veidi teistsuguse heledusega, kaamera kulus, aastaeg muutis niiskust. Mudel jäi samaks, aga maailm selle ümbert läks ära.
Selle efekti analüüs autotööstuses näitab seaduspärasust: inspekteerimissüsteemid degradeeruvad mitte kohe, vaid kuid pärast edukat pilooti, kui juurutamismeeskond on juba laiali saadetud ja mudeli ümberõpetamisele pole keegi mõelnud. Piloot, millel pole plaani eluks pärast käivitamist, on hukule määratud sõltumata stardi kvaliteedist.
Projekti tasub sisse arvestada mitte ainult käivitamine, vaid ka ekspluatatsioon: kes ja kui sageli kontrollib täpsust, millise künnise juures käivitub ümberõpetamine, kes selle eest vastutab. Kui vastus on „juurutamismeeskond lahkub ja siis vaatame", siis makstate piloodi eest, mis sureb graafiku järgi.
Tunnus 6. Kõik hoiab koos kaks-kolm spetsialisti
Neljas põhjus RANDis – puudulik infrastruktuur andmete haldamiseks ja mudelite juurutamiseks. Praktikas maskeerub see sageli kadrisõltuvuse taha: piloot töötab, sest seda hoiavad põlvedel koos kaks innukat inseneritori. Nad läksid puhkusele, vahetasid tööd või lülitusid teisele projektile – ja süsteem seiskus, sest infrastruktuuri, mis elaks ilma nendeta, pole.
Kontrollige, kas projekt elaks üle ükskõik millise ühe inimese lahkumise. Kui vastus on „ei" – teil pole juurutatud süsteem, vaid demo, mis juhuslikult elas tootmiseni. Enne skaleerimist on vaja minimaalset infrastruktuuri: dokumenteeritud protsess, ligipääsud, monitooring, värskendamisreglement.
Tunnus 7. Projektil pole äripoole omanikku
See on läbivaiv põhjus, mis seob kõik eelmised. RAND ja BCG on ühel nõul: edukatel projektidel on äripoole tooteomanik – inimene, kes vastutab tulemuse eest rahas, mitte selle eest, et „mudel on õpetatud". IT- ja tootejuhtide jaoks, kes ehitavad samasugust protsessi meeskonna sees, kehtib sama seaduspärasus. Kui piloot on täielikult IT või välise integraatori käes, pole kedagi, kes paneks ülesande tsehhi terminites, võtaks vastu otsuse peatamiseks ega tagaks, et tsehh tegelikult kasutab süsteemi.
BCG kirjeldab juurutamise pingutuste tööproportsiooni 70/20/10: seitsekümmend protsenti jõust läheb inimestele, protsessidele ja tsehhi töö muutmisele, kakskümmend – tehnoloogiatele ja andmetele ning vaid kümme – algoritmidele. Kui teie projektis on kõik vastupidi ja 90% eelarvest on litsentsid ja integratsioon, on kalduvus kohe nähtav.
Tootmispoolne omanik tuleb määrata enne alustamist, mitte pärast. Tal peavad olema volitused projekt peatada – ja motivatsioon viia see igapäevasesse kasutusse.
Kuidas seda üheks kontroll-loendiks koondada
Enne kui kirjutate alla piloodi skaleerimise eelarvele, läbige seitse küsimust. Iga „ei" pole põhjus TI-st loobuda, vaid koht, kus projekt laguneb, kui seda ette ei paranda.
- Kas me suudame nimetada probleemi hinda eurodes?
- Kas meil on andmed selle ülesande jaoks sobivas vormis?
- Kas me lahendame probleemi, mitte imetle tehnoloogiat?
- Kas see ülesanne on praegusele TI-le jõukohane?
- Kas on plaan süsteemi eluks pärast käivitamist, arvestades triivi?
- Kas projekt elaks üle ükskõik millise ühe inimese lahkumise?
- Kas on äripoole omanik õigusega projekt peatada?
RANDi seaduspärasus on selle loendi ridade vahel loetav: kuus seitsmest küsimusest on juhtimise kohta ja ainult üks – tehnoloogia kohta. Tehas, mis oskab juhtimisküsimustele vastata „jah", viib tsehhini ka tagasihoidliku mudeli. Tehas, mis loodab, et kõike veab välja tehnoloogia, kukub läbi ka kõige võimsama mudeliga.
Ja siin on see, mis mures statistika taustal julgustab. Oskus formuleerida ülesannet, arvutada selle hinda ja eristada „TI-le jõukohane" ja „TI-le mitte jõukohane" – see pole kaasasündinud talent ega kallite konsultantide haruldane oskus. See on treenitav juhtimisdistsipliin. Kõige lihtsamalt kujuneb see mitte kallis läbikukkunud piloodis, vaid ohututel õppeülesannetel, kus viga on kohe nähtav ja ei maksa midagi.
Kontroll-loendist susteemse oskuseni
mysummit.school avatud moodul: 9 praktilist ulesannet, milles on nahtav, kus TI reaalselt aitab ja kus vargsi eksib. Kursuse alus annab oskused ulesannete formuleerimiseks, tulemuste hindamiseks ja TI riskide juhtimiseks. Tasuta, registreerimata.
Часто задаваемые вопросы
Miks enamik TI-piloote ei jõua testrakust kaugemale?
Mis on mudeli triiv ja miks see tapab TI-juurutamisi tootmises?
Kuidas mõista, kas TI-ülesanne on praegustele mudelitele jõukohane?
Miks soovitab BCG kulutada 70% TI-projekti pingutustest inimestele, mitte tehnoloogiale?
Kes peaks olema TI-projekti omanik tootmises?
Stanislav Belyaev
Engineering Leader Microsoftis18 aastat insenerimeeskondade juhtimist. mysummit.school asutaja. 700+ lopetajat Yandex Practicumis ja Stratoplanis.