Volt egy sikeres pilot. A vezetés tempót akar. Meghozzák a döntést: ki kell terjeszteni a szervezet többi részére, más csapatokra, más osztályokra. Amit egy sarokban működött, most mindenhol kell működnie.
Ez messze nem mindig sikerül. Nem azért, mert a technológia hirtelen másképp reagál, hanem azért, mert a környezet, amelyben működnie kell, mindenhol másképp van berendezve. Az a csapat, ahol a pilot sikeres volt, éppen olyan IT-infrastruktúrával rendelkezett, amely elbírta azt, amit kértek tőle, olyan adatkezeléssel, amely rendben volt, és olyan szervezeti struktúrával, amelyben valaki felelősséget vállalt. A szervezet más pontjain ezek közül egy vagy több dolog másképp áll. Az eredmény: ugyanaz az erőfeszítés egy helyen eredményt hoz, máshol semmit, vagy ami rosszabb, extra munkát a hibák helyreállítására.
A skálázás a következő lépésnek érződik, mert a pilot bebizonyított valamit. Van eredmény, van lelkesedés, van nyomás a megtérülés növelésére. Aki egyszer működésre bírt valamit, nem akarja azt egy csapatra korlátozni. Ráadásul a skálázás látható: több felhasználó, több csapat, több folyamatvonal, amely átveszi az új munkamódot. Ez előrehaladásnak érződik, még akkor is, ha az alapvető dimenziók — a szervezet, az IT-infrastruktúra, az adatkezelés — még nem állnak mindenhol azon a szinten, amelyre a tőlük függő dimenzió épülhetne.
Az a sorrend, amelyben ez működik, nem opcionális. Ha az alapvető réteg nem áll rendben, a tőle függő rétegnek nincs mire épülnie. Ez nem preferencia vagy több idő kérdése; ez az a mód, ahogyan a dimenziók egymást hordozzák. A skálázás ezt a sorrendet figyelmen kívül hagyja, és azt várja, hogy egy munkamód megismétlése elegendő legyen, akkor is, ha hiányzik az az alap, amely az első alkalommal véletlenül jelen volt.
Több jel gyakran visszatér. Az új munkamódot átvevő csapatok eltérő eredményekről számolnak be, és senki nem tudja jól megmagyarázni, miért működik ez az egyik csapatnál, és miért nem a másiknál. Több képzést vagy több kommunikációt kérnek, míg a probléma máshol rejlik: olyan rendszerekben, amelyek nem kapcsolódnak egymáshoz, olyan adatokban, amelyek nem ugyanolyan minőségűek, olyan struktúrában, amelyben senki nem tulajdonosa az eredménynek a csapathatárokon átívelően.
Hasonlóan felismerhető az a helyzet, amikor technológiát vezetnek be egy olyan struktúrára, amely maga nem változott vele: az új munkamódot technikailag elérhetővé teszik, de a szerepek, felelősségek és döntési vonalak ugyanazok maradnak, mint a pilot előtt. Hasonló mintázat az, amikor egy pilot jól működik a saját sarkában, de nem kapcsolódik a szervezet többi részéhez: a skálázás a munkamódot másolja, nem azokat a feltételeket, amelyek között az a munkamód létrejött.
Egy harmadik jel kevésbé látható, de éppolyan meghatározó: két lelkes ember húzza a szekeret, és senki más nem érzi felelősnek magát. Amíg a kezdeményezés attól függ, hogy néhány ember véletlenül motivált, nincs olyan szervezeti alap, amelyre skálázni lehetne — csak lelkesedés van, amely nem sokszorozódik meg, amint a csapat nagyobbá válik.
Akinek ezek a jelek ismerősek, jól teszi, ha megkérdezi magától, hogy a csapatok közötti szórás a végrehajtás következménye, vagy egy készenléti szintbeli különbség, amely már régen jelen volt, mielőtt elkezdték a skálázást. Ez pontosan az a megkülönböztetés, amelyre a hybridresourcing érettségi mérése irányul: nem egyetlen pontszámra a teljes szervezet számára, hanem öt szintre, hét dimenzión keresztül, úgy mérve, hogy több ember egymástól függetlenül pontoz, és a válaszaik közötti szórás láthatóvá lesz. Ez a szórás gyakran többet mond el, mint az átlag: ha a vezérigazgató becslése alapvetően eltér a CIO-étól, ott rejlik a magyarázat egy része arra, hogy a skálázás miért működik egy helyen, és miért nem másutt. Amit egy vezérigazgató lát meg ebben a mérésben a saját szervezetéről, és amit egy operatív igazgató (COO) ebben felismer a napi működés felől nézve, ritkán ad ugyanolyan képet, és éppen ez a különbség az, amire a mérés épül.
Ez az oldal arról a kérdésről szól, hogy a szervezet elbírja-e az AI-t: rendben áll-e a struktúra, rendben áll-e az infrastruktúra, rendben áll-e az adatkezelés olyan szinten, amelyen a skálázás érdemes. Ez más kérdés, mint hogy a munka melyik része alkalmas magára arra, hogy AI-ra bízzák. Ez utóbbi kérdésre a FTE TO AI munkafelmérése ad választ: az feladatonként kiszámítja, hogy a munka mekkora része vehető át AI által, függetlenül attól, hogy a szervezet erre már felkészült-e. A két kérdés összetartozik, de a sorrend nem szabadon választható — annak ismerete, hogy mi átadható, kevés értékkel bír, amíg nem áll fenn, hogy az alap el bírja-e hordozni azt az átadást.
A hybridresourcing érettségi mérése még épül. Aki a mérést szeretné használni, amint elérhetővé válik, feliratkozhat a várólistára.
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.