Cyfrowa transformacja czy cyfrowa katastrofa?

Wstęp

Widziałem ten scenariusz wielokrotnie: Zarząd podejmuje decyzję o głębokiej cyfryzacji przedsiębiorstwa. Jest zabezpieczony budżet, określony harmonogram i wybrany renomowany dostawca oprogramowania. Dwa lata później organizacja zostaje z systemem, który robi PRAWIE to, co zakładano, ale którego użytkownicy boją się dotykać, do jego obsługi potrzeba kompetencji rodem z MIT, a interfejs jest przeładowany funkcjami, z których realnie potrzebnych jest zaledwie kilka.

Zarząd nie kryje irytacji bo “miało być tak pięknie” a wyszło na to, że budżet został przepalony, a efektów właściwie brak. Gdzie popełniono błąd? Odpowiedź jest zazwyczaj ta sama: zawiodła komunikacja pomiędzy dostawcą rozwiązania, działem IT, OT a biznesem. Niby wszyscy mówili o tym samym, ale każdy zrozumiał inaczej.

Wojna światów

W spółkach dystrybucyjnych (i nie tylko w nich) od lat trwa ciche starcie dwóch odmiennych kultur inżynierskich, których priorytety rzadko się pokrywają:

• Świat IT (Information Technology): To domena systemów zarządczych, analityki, chmury obliczeniowej i zwinnych metodyk. Tu priorytetem jest poufność danych, a błędy naprawia się „łatkami” podczas planowych przerw serwisowych.
• Świat OT (Operational Technology): To rzeczywistość stacji transformatorowych, sterowników obiektowych i automatyki. Tu priorytetem jest nieprzerwana dostępność i bezpieczeństwo techniczne. Błąd w tym świecie nie kończy się tylko komunikatem o usterce, lecz ryzykiem pożaru, porażenia, zniszczenia infrastruktury lub – w skrajnym przypadku – blackoutu.

IT nie zawsze rozumie czym jest automatyka zabezpieczeniowa, protokół DLMS czy IEC61850, albo czym różni się energia bierna pojemnościowa od indukcyjnej.

Programista, czy analityk myśli w kategoriach procesów, algorytmów i struktur danych, często pomijając ograniczenia fizyczne, komunikacyjne i prawne.

OT niekoniecznie musi rozumieć czym jest serverless, orkiestracja kontenerów, czy lepszy jest AWS, czy Azure. Czy lepiej w chmurze, czy on premise? Czy transformator już się zamortyzował, czy nie?

Biznes nie zawsze rozumie technologię. Technologia nie zawsze rozumie biznes. Język stosowany np. w branży programistycznej tego nie ułatwia:
„Słuchajcie, musimy spriorytetyzować ten task z backlogu, bo mamy blockera na API, więc zrobimy szybki refaktoring w bieżącym sprincie, żeby dowieźć scope przed deployem na proda.”.
Śmieszne? Śmieszne! Przejaskrawione? Może troszeczkę.

Trzy różne dziedziny, trzy różne języki. To co jest oczywiste dla jednych, drudzy niekoniecznie wiedzą. Co gorsze, czasami to samo pojęcie w każdym ze światów oznacza co innego.

Prosty przykład - serwer.

• Dla IT: hardware - urządzenie/komputer przeznaczony do pracy ciągłej, montowany w szafie rackowej, parametry: procesor, RAM, dyski, macierz, system operacyjny, sieć LAN. Bądź software - serwer aplikacji, serwer plików, serwer bazy danych. I pozostałe podziały: serwer zwirtualizowany, serwer w chmurze, dedykowany, vps. itd. itp.
• Dla OT: hardware - urządzenie zainstalowane w szafie sterowniczej, parametry: odporność na temperaturę od -20 do 75 stopni Celsjusza, IP67, backup danych na przemysłową kartę SD, komunikacja po LTE i przez RS485.
• Dla biznesu: abstrakcyjny byt na który można wrzucić pliki, albo skorzystać z aplikacji. I Teamsy są na jakimś serwerze.

Żeby budować dobre rozwiązania informatyczne, które zaspokoją potrzeby wszystkich interesariuszy w obrębie organizacji, potrzebny jest tłumacz, który mówi zarówno językiem biznesu, jak i technologii. Ktoś, kto będzie po Państwa stronie w procesie wdrażania nowych technologii.

Jak budować dobre rozwiązania?

Moje podejście odwraca tradycyjny proces cyfryzacji. Zamiast zaczynać od zakupu drogiego narzędzia, które narzuca swoje ograniczenia, skupiam się na architekturze dopasowanej do realnej skali Państwa biznesu.

1. DIAGNOZA (Zrozum)

Moja praca zaczyna się od identyfikacji realnych problemów technicznych lub biznesowych organizacji. Łączę perspektywy inżynierów ruchu, informatyków, prawników i biznesu.

Identyfikacja skali: Rozumiem, że OSDny przemysłowe czy operatorzy w galeriach handlowych mają identyczne obowiązki regulacyjne co „Wielka Piątka", ale dysponują ułamkiem ich zasobów.

2. ARCHITEKTURA (Zaprojektuj)

Tworzę kompletny projekt rozwiązania, dobieram technologię, weryfikuję jego zgodność z wymaganiami. Kluczowym filarem jest tutaj zasada Security by Design.

3. PROTOTYP (Udowodnij)

W energetyce nie ma miejsca na metodę „pędź i naprawiaj błędy w locie". Dlatego dostarczam działający prototyp (PoC).

Dowód zgodności: Zanim podejmiesz decyzję o pełnym wdrożeniu, udowadniam skuteczność rozwiązania.

4. TRANSFER (Przekaż)

Przekazuję Ci zweryfikowany „plan budowy" oraz kod prototypu. Nie uzależniam Cię od siebie jako jedynego dostawcy.

Elastyczność wykonawcza: Dokumentację i kod możesz powierzyć własnemu zespołowi IT lub wybranemu wykonawcy zewnętrznemu.

Nadzór autorski: Moja rola zmienia się w nadzór merytoryczny – dbam o to, by finalne rozwiązanie było wierne założeniom projektowym.

Efekt: Otrzymujesz rozwiązanie „szyte na miarę", przy zachowaniu pełnej kontroli nad kosztami i wyborem wykonawcy.