Marża Spada, a Nie Macie Sześciu Miesięcy, By Ustalić Dlaczego

Przeprowadźcie sześciotygodniowy sprint, który diagnozuje podstawową przyczynę od początku do końca i testuje rozwiązanie bezpośrednio w operacjach, z punktem kontrolnym go/no-go w drugim tygodniu, tak by błędny kierunek został wykryty wcześnie zamiast na końcu sześciotygodniowego zaangażowania. Tempo pochodzi z pracy wewnątrz samych operacji zamiast osobnej struktury projektowej, która musi raportować wyniki, zanim cokolwiek można zmienić.

Zacznijcie od analizy procesu od początku do końca i wywiadów z tymi, którzy wykonują pracę, prawie zawsze wiedzą, gdzie pęka, mimo że nikt nigdy formalnie ich nie zapytał. Erozja marży rzadko jest tajemnicą dla tych najbliżej procesu; zazwyczaj jest tajemnicą dla kierownictwa właśnie dlatego, że informacja nie dociera przez warstwy raportowania, które inaczej by ją wyeksponowały.

Przejrzyjcie proces etap po etapie, ze szczególną uwagą na przekazania między działami, gdzie własność często znika i nikt nie jest w pełni odpowiedzialny za to, co dzieje się w tej przestrzeni. Większość problemów wydajności, które wyglądają na złożone z dystansu, koncentruje się na jednym lub dwóch konkretnych punktach przekazania, gdy proces jest faktycznie zmapowany krok po kroku, zamiast przeglądany dział po dziale osobno.

Ograniczony czasowo cykl diagnozy-rozwiązania-realizacji-zakotwiczenia, z punktem kontrolnym go/no-go w drugim tygodniu i zdefiniowanym rozwiązaniem lub business case na końcu, ustrukturyzowany tak, by zespół wiedział w pierwszych dwóch tygodniach, czy wybrany kierunek działa. Cztery fazy są realizowane sekwencyjnie, ale pozostają ściśle ograniczone czasowo, co zapobiega temu, by sprint po cichu urósł w rodzaj wielomiesięcznego projektu, którego jest specjalnie zaprojektowany unikać.

Procesy dające się standaryzować i zepsute przekazania można w pełni rozwiązać; problemy architektury systemów czy projektu organizacyjnego zazwyczaj produkują solidny plan i business case zamiast ukończonego rozwiązania, ponieważ takie zmiany zazwyczaj wymagają inwestycji i ram czasowych, których sześciotygodniowe okno nie może odpowiedzialnie dostarczyć. Wiedza, do której kategorii należy problem, zanim się zacznie, pozwala sprintowi obiecać konkretny, uczciwy wynik zamiast otwartego.

Ograniczcie problem do tego, co sześciotygodniowy sprint faktycznie może dostarczyć, i powiedzcie od początku, który z dwóch wyników dotyczy, działające rozwiązanie lub w pełni wyceniony business case, zamiast pozwolić zakresowi projektu rosnąć w coś dłuższego i otwartego, gdy już się zacznie. Większość problemów operacyjnych tak naprawdę nie potrzebuje sześciu miesięcy analizy, by je zrozumieć; potrzebuje sześciu tygodni skupionej pracy, w operacjach.

Zmapujcie proces od początku do końca między działami, punkt przekazania często ujawnia rzeczywisty problem, nie każdy dział osobno, ponieważ narracja każdego jest często dokładna dla jego części procesu, jednocześnie pomijając, co dzieje się w luce między nimi. Żaden dział się nie myli; oboje po prostu opisują część słonia, którą faktycznie mogą zobaczyć.

Tak, najpierw rozwiążcie pilny problem operacyjny za pomocą sprintu; praca strategiczna pomaga tylko wtedy, gdy jest przestrzeń, by spojrzeć poza ten kwartał, a zespół zarządzający gaszący aktywny pożar operacyjny rzadko ma zdolność, by naprawdę zaangażować się w długoterminowe kwestie strategiczne. Postawienie sprintu przed pracą strategiczną często eksponuje rzeczywistości operacyjne, które faktycznie powinny informować strategię, która następuje.

Najpierw rozwiążcie wąskie gardło procesu i błędy przekazania, często rzeczywiste ograniczenie, nie personel, ponieważ wiele problemów produktywności wyglądających jak niedobór kadr jest w rzeczywistości procesem działającym przeciwko tym, którzy próbują go zrealizować. Dodanie personelu do zepsutego procesu zazwyczaj tylko produkuje więcej pracy przechodzącej przez to samo wąskie gardło, nie rozwiązując naprawdę podstawowego ograniczenia.

Przejdźcie przez cały łańcuch krok po kroku, w tym każde przekazanie, zamiast przeglądać działy osobno, ponieważ wąskie gardło ma nieproporcjonalnie wysokie prawdopodobieństwo leżeć dokładnie tam, gdzie odpowiedzialność przechodzi z jednego zespołu do drugiego. Przegląd dział po dziale osobno zazwyczaj ustala, że każdy działa stosunkowo dobrze według własnych warunków, dokładnie dlatego często pomija rzeczywiste ograniczenie.

Dla problemów zbyt strukturalnych na sześć tygodni sam sprint produkuje w pełni opracowany business case jako wynik, z wysiłkiem, zasobami, ryzykiem i zdefiniowaną datą rozpoczęcia, zamiast pozostawiać tę pracę komuś innemu później z mniejszą bezpośrednią wiedzą o problemie. Tak sześć tygodni nadal produkuje coś natychmiast użytecznego, nawet jeśli samo rozwiązanie wymaga więcej czasu na realizację.

Zakończcie planem zakotwiczenia nazywającym osobę odpowiedzialną, metodę pomiaru i odpowiedź, jeśli wydajność spadnie, ponieważ poprawa utrzymująca się tylko dopóki istnieje zewnętrzna uwaga na nią, nie jest naprawdę poprawą, to stan tymczasowy. Plan zakotwiczenia zamienia sześciotygodniowe rozwiązanie w trwałą zmianę, zamiast wyniku, który po cichu cofa się kilka miesięcy później, gdy uwaga wszystkich przesuwa się gdzie indziej.

Krótkie, intensywne sesje natychmiast testujące wykonalność kierunków rozwiązań, z eksperymentami na małą skalę przed pełnym wdrożeniem, zamiast długiej fazy analitycznej, po której następuje jedno duże wdrożenie bez możliwości korekty kursu. Testowanie kierunków na małą skalę najpierw oznacza, że wadliwe podejście jest wykrywane, gdy jest jeszcze tanie do zmiany, zamiast po wdrożeniu w całych operacjach.

Najpierw zdiagnozujcie rzeczywistą podstawową przyczynę, ściganie objawów na wielu frontach jednocześnie często sprowadza się do jednej lub dwóch rzeczywistych przyczyn, co oznacza, że długa lista tego, co wygląda na zepsute, często ukrywa znacznie krótszą listę rzeczywistych problemów. Rozwiązanie podstawowej przyczyny zazwyczaj rozwiązuje wiele pozornie osobnych objawów jednocześnie, znacznie lepsze wykorzystanie ograniczonej zdolności niż traktowanie każdego objawu jako niezależnego problemu.

Zdefiniujcie metodę pomiaru jako część planu zakotwiczenia na koniec sprintu, powiązaną z pierwotnym problemem, tak by sukces był osądzany względem tego, co było konkretnie zepsute, nie ogólnym poczuciem, że sprawy idą lepiej. Metoda pomiaru zdecydowana wcześniej, zanim rozwiązanie zostanie zrealizowane, usuwa też pokusę wybrania po fakcie metryki, która okazuje się najkorzystniejsza.