Analiza biznesowa transformacji cyfrowej: od AS-IS do wdrożenia
Od czego zaczynałem
Mała firma edukacyjna prowadziła zajęcia w wielu miejscach i korzystała z floty komputerów. Kiedy rozpisałem stan obecny, wyszły cztery rzeczy, i to powiązane ze sobą:
- materiały i wiedza o tym, jak się pracuje, leżały w mailach, na dyskach i w głowach pracowników;
- przygotowanie komputera do zajęć wymagało długiej serii ręcznych czynności;
- strona stała na zamkniętej platformie, więc firma miała niewielki wpływ na koszty, szybkość i rozwój;
- część pracy z formularzami i danymi robiono ręcznie, przy czym każdy trochę inaczej.
Sama lista niczego nie załatwiła. Musiałem zobaczyć te procesy w ruchu: pogadać z ludźmi, którzy korzystają z materiałów i sprzętu, obejrzeć miejsca, w których odbywają się zajęcia, popatrzeć na pracę na żywo i oddzielić kłopoty jednorazowe od tych, które wracają co tydzień.
Od potrzeby do wymagania
Każde wymaganie opisywałem przez to, czego potrzebuje użytkownik, co go ogranicza i jak sprawdzę, że wyszło. Dzięki temu o technologii decydowałem dopiero wtedy, gdy rozumiałem problem.
| Potrzeba | Wymaganie rozwiązania | Sposób sprawdzenia |
|---|---|---|
| Instruktor ma samodzielnie znaleźć aktualną odpowiedź | Jedno źródło wiedzy, przewidywalna struktura i instrukcje zorientowane na zadania | Nowa osoba wykonuje procedurę bez pomocy autora |
| Komputer ma być gotowy do zajęć w powtarzalnym stanie | Standaryzacja konfiguracji i automatyzacja czynności możliwych do powtórzenia | Test aplikacji, kont, sieci i usług po wdrożeniu |
| Organizacja ma kontrolować stronę i koszty | Otwarty stos, historia zmian, szybkie ładowanie i możliwość dalszego rozwoju | Testy funkcjonalne, wydajnościowe i dostępności przed przełączeniem |
| Materiały mają działać bez autora | Spójny format, kontekst dla prowadzącego i jasno określony efekt zajęć | Prowadzenie zajęć przez innych instruktorów w wielu grupach |
Taki podział oddziela to, czego firma potrzebuje, od tego, czym to zrobię. Krótsze przygotowanie stanowiska było celem. Linux, skrypt provisioningowy i sposób dostarczenia plików to już tylko środki, które do niego dobrałem.
Jak miało wyglądać docelowo
Stan TO-BE nie był jednym systemem, tylko kilkoma rzeczami, które się zazębiają:
- baza wiedzy jako wspólne miejsce na procedury i materiały;
- jednakowo ustawione komputery używane na zajęciach;
- automat konfigurujący i aktualizujący to, co się powtarza;
- własna strona na otwartym stosie, z historią zmian;
- dokumentacja, szkolenia i wskazanie, kto się tym zajmie później.
Każdy element miał właściciela, odbiorców i warunek, po którym poznam, że się przydaje. Ważne było też rozrysowanie zależności: zmiana programów na komputerach wymuszała poprawkę w automacie i w instrukcji, a zmiana przebiegu zajęć pociągała za sobą materiały dla instruktorów i informację dla rodziców.
Testy, wdrożenie i zmiana planu
Najpierw sprawdzałem wszystko na małej skali i na prawdziwym sprzęcie. Testy pokazywały nie tylko błędy, ale i to, że część moich założeń była błędna. Planowałem na przykład w pełni automatyczną instalację systemu, dopóki test nie pokazał, że instalator nie obsługuje mechanizmu, na którym to oparłem. Zamiast udawać, że wszystko poszło zgodnie z planem, rozbiłem proces na krótki etap ręczny i provisioning, który można bezpiecznie powtarzać.
Poza uruchomieniem samej technologii wdrożenie objęło:
- instrukcje wykonania i diagnostyki;
- testy akceptacyjne najważniejszych funkcji;
- szkolenia pracowników z narzędzi i sprzętu;
- możliwość ponownego uruchomienia automatu bez kasowania istniejących danych;
- procedury utrzymania, aktualizacji i obsługi zgłoszeń.
Co z tego wyszło
- przygotowanie sprzętu wymagało mniej ręcznych kroków i dawało się powtarzać według tego samego procesu;
- baza wiedzy zdjęła zależność od pamięci kilku osób i ułatwiła wdrażanie nowych pracowników;
- firma dostała własną stronę, historię zmian i mniejszą zależność od jednego dostawcy;
- instruktorzy zaczęli pracować na wspólnych materiałach i takim samym sprzęcie;
- wszystko zostało opisane na tyle dokładnie, żeby dało się to utrzymywać i rozwijać dalej.
Czego ten opis nie pokazuje
Nie prowadziłem niezależnego badania czasu ani porównania z grupą kontrolną lub inną firmą. Opis pokazuje przebieg decyzji, testy i artefakty, ale nie pozwala obiecać takiego samego wyniku w innym środowisku.
Najbardziej przenośna część metody to rozdzielenie potrzeby, wymagania i testu. Narzędzia oraz wynik zależą już od konkretnego procesu.