A existat un pilot de succes. Managementul dorește ritm. Se ia decizia: se extinde către restul organizației, alte echipe, alte departamente. Ce a funcționat într-un colț trebuie acum să funcționeze pretutindeni.
Acest lucru nu se întâmplă întotdeauna bine. Nu pentru că tehnologia reacționează brusc diferit, ci pentru că mediul în care trebuie să funcționeze este organizat diferit pretutindeni. Echipa în care pilotul a avut succes avea, din întâmplare, o infrastructură IT care putea susține ceea ce se cerea, un management al datelor care era în ordine și o structură organizatorică în care cineva își asuma responsabilitatea. În altă parte a organizației, unul sau mai multe dintre aceste aspecte stau altfel. Rezultatul: același efort produce ceva într-un loc și nimic în altul, sau, mai rău, muncă suplimentară pentru a repara erorile.
Scalarea se simte ca pasul următor pentru că pilotul a dovedit ceva. Există un rezultat, există entuziasm, există presiune pentru a crește randamentul. Cine a reușit odată să facă ceva să funcționeze nu dorește să-l limiteze la o singură echipă. Mai mult, scalarea este vizibilă: mai mulți utilizatori, mai multe echipe, mai multe linii de proces care adoptă noul mod de lucru. Acest lucru se simte ca un progres, chiar și atunci când dimensiunile fundamentale — organizația, infrastructura IT, managementul datelor — nu se află încă pretutindeni la nivelul la care dimensiunea care depinde de ele poate, de fapt, funcționa.
Ordinea în care acest lucru funcționează nu este opțională. Dacă stratul fundamental nu este solid, stratul dependent nu are pe ce să se construiască. Nu este o chestiune de preferință sau de a-și lua mai mult timp; este modul în care dimensiunile se susțin reciproc. Scalarea ignoră această ordine și se așteaptă ca repetarea unui mod de lucru să fie suficientă, chiar și fără fundația care, prima dată, s-a întâmplat să fie prezentă.
Apar frecvent câteva semnale. Echipele care adoptă noul mod de lucru raportează rezultate inconsecvente, și nimeni nu poate explica bine de ce funcționează la o echipă și nu la alta. Se cere mai multă formare sau mai multă comunicare, în timp ce problema se află în altă parte: în sisteme care nu se conectează între ele, în date care nu au aceeași calitate, într-o structură în care nimeni nu este proprietarul rezultatului dincolo de limitele echipei.
De asemenea, este ușor de recunoscut situația în care tehnologia este implementată peste o structură care nu s-a schimbat ea însăși: noul mod de lucru este pus la dispoziție din punct de vedere tehnic, dar rolurile, responsabilitățile și liniile de decizie au rămas aceleași ca înainte de pilot. Similar este modelul în care un pilot funcționează bine în colțul propriu, dar nu se conectează la restul organizației: scalarea copiază modul de lucru, nu condițiile în care acel mod de lucru a apărut.
Un al treilea semnal este mai puțin vizibil, dar la fel de determinant: doi entuziaști duc povara, iar restul nu se simte deloc responsabil. Atâta timp cât inițiativa depinde de câteva persoane care se întâmplă să fie motivate, nu există o bază organizatorică pentru scalare — există doar entuziasm care nu se multiplică în momentul în care echipa devine mai mare.
Cei care recunosc aceste semnale ar face bine să se întrebe dacă dispersia dintre echipe este o consecință a execuției sau a unei diferențe de pregătire care era deja prezentă mult înainte de scalare. Această distincție este exact ceea ce urmărește măsurarea maturității hybridresourcing: nu un singur scor pentru întreaga organizație, ci cinci niveluri pe șapte dimensiuni, măsurate prin faptul că mai multe persoane evaluează separat, iar dispersia dintre răspunsurile lor devine vizibilă. Această dispersie spune deseori mai mult decât media: dacă evaluarea CEO-ului diferă fundamental de cea a CIO-ului, acolo se află o parte din explicația de ce scalarea are succes într-un loc și nu în altul. Ceea ce arată un CEO în această măsurare despre propria organizație și ceea ce recunoaște un COO din execuția zilnică rareori produc aceeași imagine, și această diferență este exact ceea ce fundamentează măsurarea.
Această pagină tratează întrebarea dacă organizația poate susține AI: sunt structura, infrastructura, managementul datelor la un nivel la care scalarea are sens. Aceasta este o întrebare diferită de cea privind ce parte a muncii propriu-zise este potrivită pentru a fi transferată către AI. Această din urmă întrebare este răspunsă de scanul de lucru al FTE TO AI: acesta calculează, pe sarcină, ce parte a muncii poate fi preluată de AI, independent de faptul că organizația este deja pregătită pentru asta. Ambele întrebări sunt legate între ele, dar ordinea nu este opțională — a ști ce este transferabil are puțină valoare atâta timp cât nu este clar dacă baza poate susține acel transfer.
Măsurarea maturității hybridresourcing este încă în construcție. Cei care doresc să folosească măsurarea imediat ce va fi disponibilă se pot înscrie pe lista de așteptare.
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.