Dlaczego szybsze skalowanie nie zastępuje podstaw

Pułapka

Był udany pilotaż. Zarząd chce tempa. Zapada decyzja: wdrożyć w całej resztcie organizacji, w innych zespołach, w innych działach. To, co zadziałało w jednym zakątku, musi teraz działać wszędzie.

To nie zawsze się udaje. Nie dlatego, że technologia zaczyna działać inaczej, ale dlatego, że otoczenie, w którym musi funkcjonować, jest wszędzie inaczej zorganizowane. Zespół, w którym pilotaż się powiódł, miał przypadkiem infrastrukturę IT, która była w stanie obsłużyć to, co było potrzebne, zarządzanie danymi, które było na porządku, oraz strukturę organizacyjną, w której ktoś brał odpowiedzialność. W innych częściach organizacji jedna lub więcej z tych rzeczy wygląda inaczej. Rezultat: ten sam wysiłek gdzieś przynosi efekt, a gdzie indziej nic, albo, co gorsza, dodatkową pracę potrzebną do naprawienia błędów.

Dlaczego to wydaje się logiczne

Skalowanie wydaje się kolejnym krokiem, bo pilotaż coś dowiódł. Jest wynik, jest entuzjazm, jest presja, by zwiększyć zwrot. Kto raz doprowadził coś do działania, nie chce ograniczać tego do jednego zespołu. Poza tym skalowanie jest widoczne: więcej użytkowników, więcej zespołów, więcej linii procesów, które przejmują nowy sposób pracy. To wydaje się postępem, nawet gdy fundamentalne wymiary — organizacja, infrastruktura IT, zarządzanie danymi — nie są jeszcze wszędzie na poziomie, na którym może działać wymiar od nich zależny.

Kolejność, w jakiej to działa, nie jest opcjonalna. Jeśli warstwa fundamentalna nie jest gotowa, warstwa zależna nie ma na czym się oprzeć. To nie jest kwestia preferencji ani poświęcenia więcej czasu; to sposób, w jaki wymiary się wzajemnie podpierają. Skalowanie ignoruje tę kolejność i zakłada, że powtórzenie sposobu pracy wystarczy, nawet bez podłoża, które przy pierwszej próbie było obecne przypadkiem.

Po czym rozpoznać, że w tym tkwimy

Kilka sygnałów powtarza się często. Zespoły przejmujące nowy sposób pracy zgłaszają zmienne wyniki i nikt nie jest w stanie dobrze wyjaśnić, dlaczego w jednym zespole to działa, a w innym nie. Pojawia się prośba o więcej szkoleń lub więcej komunikacji, choć problem leży gdzie indziej: w systemach, które nie są ze sobą zintegrowane, w danych o różnej jakości, w strukturze, w której nikt nie jest właścicielem wyniku przekraczającego granice zespołów.

Rozpoznawalna jest też sytuacja, w której technologia zostaje wdrożona w strukturze, która sama się nie zmieniła: nowy sposób pracy zostaje udostępniony technicznie, ale role, odpowiedzialności i linie decyzyjne pozostają takie same jak przed pilotażem. Podobny jest wzorzec, w którym pilotaż dobrze funkcjonuje w swoim zakątku, ale nie łączy się z resztą organizacji: skalowanie kopiuje sposób pracy, a nie warunki, w jakich ten sposób pracy powstał.

Trzeci sygnał jest mniej widoczny, ale równie decydujący: dwoje entuzjastów ciągnie cały projekt, a nikt inny nie czuje się odpowiedzialny. Dopóki inicjatywa zależy od kilku osób, które przypadkiem są zmotywowane, nie istnieje organizacyjna podstawa do skalowania — jest tylko entuzjazm, który nie mnoży się, gdy zespół się powiększa.

Kto rozpoznaje te sygnały, powinien zapytać, czy rozproszenie między zespołami jest efektem realizacji, czy różnicy w gotowości, która była obecna już przed skalowaniem. To rozróżnienie jest właśnie tym, na co patrzy pomiar dojrzałości hybridresourcing: nie na jeden wynik dla całej organizacji, ale na pięć poziomów w siedmiu wymiarach, mierzonych w ten sposób, że kilka osób ocenia sytuację niezależnie od siebie, dzięki czemu widoczne staje się rozproszenie między ich odpowiedziami. To rozproszenie mówi często więcej niż średnia: jeśli ocena CEO fundamentalnie różni się od oceny CIO, to właśnie tam leży część wyjaśnienia, dlaczego skalowanie gdzieś się przyjmuje, a gdzieś nie. To, co CEO pokazuje w tym pomiarze o własnej organizacji i to, co COO rozpoznaje w tym samym pomiarze z perspektywy codziennej realizacji, rzadko dają ten sam obraz, a ta różnica jest właśnie tym, na czym zbudowano ten pomiar.

Most do kolejnego pytania

Ta strona dotyczy pytania, czy organizacja jest w stanie unieść AI: czy struktura, infrastruktura i zarządzanie danymi są na poziomie, na którym skalowanie ma sens. To inne pytanie niż to, która część samej pracy jest odpowiednia do przekazania AI. Na to drugie pytanie odpowiada skan pracy FTE TO AI: wylicza on dla każdego zadania, jaką część pracy można przekazać AI, niezależnie od tego, czy organizacja jest na to już gotowa. Oba pytania są ze sobą powiązane, ale kolejność nie jest dowolna — wiedza o tym, co jest przekazywalne, ma niewielką wartość, dopóki nie jest ustalone, czy podstawa jest w stanie to przekazanie unieść.

Narzędzie jest w budowie