Praktyka ciągłości działania biznesu

W piątkowe popołudnie, podczas szczytu zamówień, wypada z pracy kolega, który codziennie rano ręcznie przenosi zamówienia ze sklepu internetowego do systemu zarządzania. Magazyn nie wie dokładnie, co przygotować, obsługa klienta nie może podać wiarygodnych informacji o dostawie, a fakturowanie czeka. Ciągłość działania wiele firm wiąże jednak tylko z przerwami w dostawie prądu, pożarami lub cyberatakami. Tymczasem działanie częściej przerywa pozornie drobna, codzienna zależność.

Pytanie nie dotyczy tylko tego, czy serwery są dostępne po awarii. Ważne jest również, czy ważny proces można kontynuować, gdy brakuje jednej osoby, opóźnia się dostawca danych, integracja jest wadliwa lub po prostu napływa zbyt wiele zamówień, by rutynowe ręczne procedury mogły sobie z tym poradzić. Ciągłość jest zatem kwestią operacyjną, a nie wyłącznie informatyczną.

Co oznacza ciągłość działania w praktyce?

Ciągłość działania to zdolność firmy do utrzymania swoich krytycznych działań na określonym poziomie nawet po zakłóceniu. Nie oznacza to, że wszystko działa bez zmian. Może się zdarzyć, że realizacja jest tymczasowo wolniejsza, zakres usług węższy, lub codzienne działanie wymaga więcej decyzji kierowniczych. Celem jest, aby przestoje, utrata danych, błędna realizacja i pogorszenie doświadczeń klienta były utrzymane w zarządzalnych ramach.

W firmie zatrudniającej od 20 do 500 osób krytyczne procesy rzadko istnieją w jednym systemie. Zamówienie może rozpocząć się w sklepie internetowym lub w e-mailu sprzedawcy, przejść do arkusza kalkulacyjnego, następnie do ERP, stamtąd do magazynu, a na końcu do fakturowania i przewoźnika. Jeśli część przekazywania jest ręczna, rzeczywisty proces nie znajduje się w systemach, ale w głowach ludzi, ich skrzynkach pocztowych i osobistych listach kontrolnych.

To różnica między udokumentowaną procedurą a rzeczywistym działaniem. Wielu menedżerów uważa, że istnieje zastępstwo, ponieważ istnieje opis stanowiska pracy. W rzeczywistości tylko ten kolega wie, który plik eksportu otworzyć, które dane poprawić i kiedy należy osobno obsłużyć różne zamówienie. Dopóki jest dostępny, nie wydaje się to problemem. Jego brak lub przeciążenie natychmiast ujawnia ryzyko.

Ukryte przerwy nie zawsze są widoczne

Całkowity przestój jest łatwy do rozpoznania. System nie działa, zamówienia nie wpływają, produkcja stoi. Trudniej zauważyć stopniowe błędy, gdzie praca wydaje się postępować, ale coraz więcej jest ręcznych korekt, decyzje się opóźniają lub różne działy pracują na różnych informacjach.

Taka sytuacja ma miejsce na przykład, gdy dane o stanie magazynowym w sklepie internetowym są aktualizowane tylko raz dziennie. W normalnym ruchu różnica nie jest zauważalna. Jednak podczas kampanii lub sezonowego szczytu firma może sprzedawać produkty, które już nie są na stanie. Obsługa klienta ustala to później, magazyn obsługuje wyjątki, finanse anulują, a zarząd zauważa problem tylko po wzroście liczby reklamacji.

To samo może się zdarzyć w produkcji, jeśli statusy produkcji są w arkuszu kalkulacyjnym, zapasy w ERP, a dane maszyn w oddzielnym systemie. Każde źródło może działać samodzielnie, ale niekoniecznie oznacza to, że kierownik zmiany na czas widzi, co się opóźnia, którego surowca brakuje lub które zamówienie jest zagrożone.

Ciągłość to zatem nie tylko serwer zapasowy czy kopia zapasowa. Oznacza to również ciągłość informacji, ciągłość podejmowania decyzji i jasność odpowiedzialności.

Najpierw należy wyznaczyć krytyczne procesy biznesowe

Nie każdy proces wymaga tego samego poziomu ochrony. Opóźnienie wewnętrznego, miesięcznego raportu może być nieprzyjemne, ale ma inną wagę niż dostawa, przetwarzanie zamówień klientów, zarządzanie produkcją czy naliczanie płac. Dobrym punktem wyjścia nie jest lista dostępnych technologii, ale wyjaśnienie, co nie może się zatrzymać, na jak długo i z jakimi konsekwencjami.

Warto prześledzić każdy proces od zdarzenia wywołującego do zakończenia. Kto go inicjuje? Jakie dane są potrzebne? Skąd pochodzą dane? Kto je zatwierdza? W którym systemie odbywa się kolejny krok? Gdzie jest ręczne kopiowanie, uzgadnianie e-mailowe lub rejestracja w arkuszu kalkulacyjnym? Już to mapowanie często ujawnia, że największe ryzyko nie tkwi w błędzie aplikacji, ale w niewidocznych ludzkich połączeniach między systemami.

Podczas badania nie wystarczy zapytać, jak powinien działać proces. Trzeba zobaczyć, jak działał ostatnio przy pilnym zamówieniu, błędnej fakturze, brakującym surowcu lub awarii systemu. Wyjątki często mówią więcej o działaniu niż przypadki zgodne z zasadami.

Cztery pytania, które szybko ujawniają zależności

W przeglądzie kierowniczym cztery pytania są szczególnie przydatne:

• Co się stanie, jeśli dany system, źródło danych lub kolega nie będzie dostępny przez cały dzień pracy?
• Jakie ręczne kroki są potrzebne, aby proces mógł być kontynuowany?
• Skąd wiadomo, że w międzyczasie wystąpił błąd, duplikacja lub utrata danych?
• Kto jest uprawniony do podejmowania decyzji w przypadkach odstępstw i czy ma dostęp do wszystkich niezbędnych informacji?

Odpowiedzi na te pytania często nie są jednoznaczne. To nie jest porażka, ale sygnał: działanie prawdopodobnie opiera się na nieformalnej wiedzy, która nie została jeszcze przekształcona w powtarzalne, kontrolowalne działanie.

Zastępstwo samo w sobie nie wystarczy

Wiele firm radzi sobie z ryzykiem kluczowych pracowników poprzez zastępstwo. Jest to konieczne, ale nie zawsze wystarczające. Jeśli zastępca może wykonać zadanie tylko dlatego, że może skontaktować się telefonicznie z oryginalnym odpowiedzialnym, zależność nie została wyeliminowana. Jeśli trzygodzinny raport ręczny mogą przygotować dwie osoby, raport nadal jest powolny, podatny na błędy i trudny do audytu.

Celem nie jest zastąpienie każdego pracownika technologią. Dobre usprawnienie operacyjne oddziela to, co wymaga ludzkiej decyzji, od tego, co jest powtarzalnym przenoszeniem danych lub kontrolą opartą na regułach. Dochodzenie w sprawie reklamacji klienta może wymagać profesjonalnej oceny. Czwarte przeniesienie danych zamówienia nie jest jednak pracą tworzącą wartość.

Dokumentacja nie jest tu również administracyjnym produktem ubocznym. Z użytecznej dokumentacji wynika cel procesu, odpowiedzialny, wejście i wyjście, zarządzanie odstępstwami oraz to, gdzie znajdują się aktualne dane. Jeśli to zna tylko stara wspólna mapa i kilku doświadczonych kolegów, ciągłość pozostaje krucha.

Rola technologii: tylko tam, gdzie rzeczywiście zmniejsza ryzyko

Po mapowaniu procesu często okazuje się, że najpierw nie potrzeba nowego systemu. Może się okazać, że krok zatwierdzania jest zbędny, dwa działy przechowują te same dane, lub trzeba wyjaśnić zasadę obsługi wyjątków. Te zmiany mogą poprawić przejrzystość i odporność działania przy niewielkich kosztach.

W innych przypadkach interwencja techniczna jest uzasadniona. Integracja systemów może wyeliminować powtarzające się wprowadzanie danych. Odpowiednio zaprojektowana aplikacja wewnętrzna może ujednolicić obsługę wyjątków. Zarządzanie uprawnieniami, logowanie, kopie zapasowe, monitorowanie i przetestowane odzyskiwanie mogą zmniejszyć ryzyko, że błąd pozostanie niezauważony lub będzie trwał zbyt długo.

Zakres rozwiązania musi być proporcjonalny do konsekwencji. Dla wewnętrznego rejestru o niskim wpływie biznesowym kosztowna architektura o wysokiej dostępności może być przesadą. Natomiast w przypadku systemu, który zarządza codzienną wysyłką, produkcją lub fakturowaniem, ryzykowne może być opieranie się na przypuszczeniach dotyczących kopii zapasowych i odpowiedzialności za odzyskiwanie.

Kluczowe jest potwierdzenie. Kopia zapasowa nie jest dowodem na jej użyteczność tylko dlatego, że została wykonana. Plan zastępstwa nie działa tylko dlatego, że jest w dokumencie. Proces należy czasami przetestować w warunkach zbliżonych do rzeczywistych: kto ma dostęp, skąd pracuje, jakie dane są dostępne i ile czasu zajmuje przywrócenie działania do akceptowalnego poziomu.

Ciągłość to także odpowiedzialność kierownicza

Większość ryzyk operacyjnych powstaje na styku różnych obszarów. Sprzedaż szybko składa obietnicę, magazyn widzi inne dane o stanie, finanse fakturują według innych zasad, a IT obsługuje system, którego priorytety biznesowe nie zostały jasno określone. W takich przypadkach nie popełnia błędu jeden dział. Firma nie ma wspólnego obrazu krytycznego działania.

Dlatego nie zaleca się delegowania ciągłości wyłącznie do IT. Menedżerowie biznesowi mogą określić, jakie straty, ryzyko umowne lub wpływ na klientów powoduje utrata usługi. IT i operacje mogą ocenić, jakie techniczne zależności, możliwości odzyskiwania i ograniczenia są z tym związane. Oba punkty widzenia razem dają użyteczny priorytet.

Najlepszym pierwszym krokiem zazwyczaj nie jest duży projekt zakupowy. Wybierz proces, który codziennie zawiera wiele ręcznych przekazań, bezpośrednio dotyczy klienta lub przychodu i wyraźnie opiera się na wiedzy jednej osoby. Jeśli ten proces zostanie dokładnie zrozumiany, uproszczony, udokumentowany i przetestowany, firma nie tylko lepiej przygotuje się na awarię. Tworzy podstawę bardziej przewidywalnego działania.