Un COO conduce operațiunea: flux, capacitate, calitate, continuitate. Pilotările AI care ies bine într-un colț izolat al companiei spun puțin despre asta. Întrebarea care contează nu este dacă ceva funcționează într-un montaj de test, ci dacă va continua să funcționeze odată ce devine parte din operațiunea zilnică, cu toate dependențele care vin cu ea.
O operațiune care a fost odată organizată într-un anumit mod de lucru este costisitoare de inversat. Dacă o aplicație AI este implementată înainte ca procesele, datele și responsabilitățile să fie în ordine, nu apare o accelerare, ci muncă adițională: corecții, excepții, oameni care verifică totuși ce un sistem ar fi trebuit deja să facă. Acest risc îl afectează direct pe COO, pentru că operațiunea este ceea ce el trebuie să justifice. O pilotare care s-a simțit bine într-o demonstrație, și care șase luni mai târziu duce la livrare perturbată sau la gestionare adițională de erori, este o problemă care ajunge pe biroul lui.
Există și riscul opus: să aștepți prea mult cu extinderea pentru că nimeni nu poate indica dacă organizația este pregătită pentru asta. Atunci concurenții sau alte unități de afaceri continuă să avanseze, fără să existe un motiv fundamentat pentru asta. Ambele riscuri provin din același gol: nu există o imagine partajată despre unde se află organizația în realitate.
Un COO vrea o bază pe care să construiască decizii, care să nu depindă de entuziasmul unei singure echipe de pilotare. El vrea să știe dacă organizația, independent de proiecte individuale, este pregătită să susțină AI: sunt procesele descrise și repetabile, este infrastructura suficient de stabilă, sunt datele disponibile și fiabile în locul unde sunt necesare. Este un tip diferit de întrebare față de „funcționează această aplicație specifică”. Este întrebarea dacă fundația este corectă, independent de ce aplicație se va construi pe ea mai târziu.
Acea fundație este alcătuită din mai multe straturi, iar ordinea în care sunt puse întrebările nu este arbitrară. Organizația, infrastructura IT și managementul datelor determină ce este posibil; dimensiunile care depind de acestea, precum luarea deciziilor sau colaborarea în jurul AI, nu pot avansa mai mult decât permite acea bază. Un COO care știe asta își pune întrebările în ordinea corectă, în loc să înceapă cu aplicația cea mai vizibilă.
Un COO nu acceptă un răspuns care se bazează pe o singură opinie. „Echipa este pregătită” este afirmația unei singure persoane, bazată pe ce vede acea persoană din poziția sa. Un manager IT, un manager operațional și un lider de echipă văd de multe ori o organizație diferită, chiar și atunci când vorbesc despre același departament. Această dispersie este exact motivul pentru care scorul unei singure persoane nu este suficient: ascunde dezacorduri care, mai târziu, la extindere, vor apărea totuși la suprafață.
De aceea funcționează o măsurare care permite mai multor persoane să dea scoruri separat, pe cinci niveluri — de la baseline la foundation, activation, insight și în final intelligence — repartizate pe șapte dimensiuni. Nu pentru a calcula o medie, ci pentru a vedea unde diferă răspunsurile. O dispersie mare pe o dimensiune este ea însăși o informație: înseamnă că nu există o imagine partajată, iar asta este altceva decât un nivel scăzut. O organizație care obține scoruri scăzute, dar unanime, pe toate dimensiunile, măcar știe unde se află. O organizație cu dispersie mare nu știe încă asta, și trebuie să clarifice mai întâi acest lucru înainte ca un nivel să aibă vreo semnificație.
Un COO nu acceptă nici un răspuns care sugerează o garanție. O măsurare a pregătirii spune ceva despre starea organizației în acest moment, nu despre ce va produce o aplicație AI mai târziu. Această distincție nu este subtilă pentru cineva cu responsabilitate operațională: el știe că pregătirea este o condiție, nu un rezultat.
Operațiunea nu este singurul strat pe care apar astfel de întrebări. Ceea ce este continuitatea proceselor pentru COO reprezintă pentru alte roluri din companie o altă considerație: ce urmărește un CIO în privința maturității AI descrie întrebarea din perspectiva infrastructurii și arhitecturii sistemelor, în timp ce ce urmărește un CHRO în privința maturității AI abordează ce cere acest lucru de la oameni și roluri. Pentru companiile unde operațiunea este construită din proiecte și locații, în loc dintr-un proces central, se aplică alte modele, așa cum se poate citi în cât de avansată este construcția în privința maturității AI.
Măsurarea care face vizibilă această dispersie este în construcție. Cei care se înscriu pe lista de așteptare vor primi acces imediat ce instrumentul este pregătit de utilizare. În prezent nu există niciun raport de descărcat și nicio sesiune de programat; există un instrument în dezvoltare, construit pe întrebarea pe care un COO o pune efectiv, și nu pe întrebarea care este ușor de răspuns.
Măsurarea maturității răspunde dacă organizația poate susține AI: dacă fundamentele sunt puse pentru a construi ceva durabil. Odată ce acea imagine există, întrebarea se deplasează de la capacitatea de susținere către conținut: ce parte din muncă poate fi într-adevăr preluată de AI, sarcină cu sarcină, în loc de la nivelul întregii organizații. Aceasta este o altă măsurare, cu un alt tip de răspuns, și un COO o găsește în scanul de lucru al FTE TO AI.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.