Jak procesy otwartej pętli zakłócają przepływ informacji w biznesie

W trakcie mojej kariery wykonałem sporo przeprojektowań procesów biznesowych, a największy pojedynczy problem, jaki napotykam, jest zawsze ten sam: procesy biznesowe w pętli otwartej. Procesy w pętli otwartej występują głównie dlatego, że odpowiedzialność jest podzielona na wiele osób i często na wiele działów. Przepływ informacji, który rozpoczyna się w R&D z prośbą o nowy sprzęt, może przejść przez dział finansów i zakupów, zanim wyjdzie poza granice organizacyjne do dostawcy (gdzie przejdzie kolejno przez kilka działów), a następnie z powrotem do działu odbioru i , przy odrobinie szczęścia grupa badawczo-rozwojowa, która zainicjowała przepływ.

Na każdym etapie istnieje możliwość, że komunikacja zostanie zakłócona, a kierownicy projektów muszą ograniczyć te zagrożenia. Jeśli przepływy informacji wbudowane w proces biznesowy nie mają jawnej struktury umożliwiającej przechwytywanie, a następnie obsługę wyjątków, awaria zostanie wykryta znacznie później lub może wcale. Podczas gdy niektóre awarie przepływu informacji powodują jedynie, że stosunkowo nieistotne elementy nie są prawidłowo zamawiane lub dostarczane, inne awarie mogą kosztować organizacje ogromne sumy pieniędzy lub powodować opóźnienia w działaniach o znaczeniu krytycznym.

Otwarte pętle mogą kosztować miliony dolarów

Aby to zilustrować, najpierw opowiem o dużej organizacji farmaceutycznej, która płaciła podatki od sprzętu o wartości setek milionów dolarów, którego nie mógł już śledzić i chciała usunąć ten niepotrzebny wydatek. Nasz projekt wykrył wiele podstawowych wad procesu, z których wszystkie stanowiły dziesiątki milionów dolarów niepotrzebnych podatków rocznie i tyle samo więcej, ile przeznaczono na wielokrotne omyłkowe zamawianie tych samych rzeczy.

Jednokierunkowa komunikacja między obszarami odpowiedzialności

Jak we wszystkich dużych organizacjach, obowiązki były w silosach. Ktoś w Produkcji potrzebuje sprzętu X, więc informuje Finanse i generowane jest zamówienie zakupu (PO). Zamówienie wysyła zamówienie do dostawcy. Do roku w przyszłości X jest dostarczany i akceptowany przez Odbiór. Odbieranie powiadamia produkcję i finanse. Finance wydaje etykietę aktywów, którą Odbiorca nakłada na X. X jest umieszczany na linii produkcyjnej i wszystko jest w porządku.

Tyle że nie wszystko jest dobrze. Po pierwsze, pracownicy przychodzą i odchodzą i łatwo jest zamówić X, nie zdając sobie sprawy, że ktoś inny w tej samej roli zamówił X dziewięć miesięcy temu. Finanse nie mają pojęcia, że ​​to zamówienie jest duplikatem: zakładają, że po prostu potrzebujesz kolejnego X, więc generowane jest kolejne zamówienie i składane jest kolejne zamówienie. Poza tym, nawet jeśli przypadkowo nie zamówisz zbyt wiele, szybko stracisz orientację, co masz.

Załóżmy, że X jest złożonym elementem wyposażenia, być może linią mety. Składa się z 20 głównych komponentów, z których wszystkie będą wielokrotnie wymieniane w okresie eksploatacji. Etykieta zasobu przyklejona przypadkowo do jednej części X zniknie z powodu zużycia. Co gorsza, tag zasobu może nawet nie zostać zastosowany, ponieważ nie dociera na czas do odbioru. Po tym nikt nie ma pojęcia, jak śledzić X, a zatem nie ma pomysłu na jego wycofanie z eksploatacji. Z perspektywy podatkowej X jest nadal funkcjonującą pozycją podlegającą opodatkowaniu.

W ciągu ponad 20 lat zaczęłoby to negatywnie wpływać na wyniki finansowe w znaczący sposób. Co więcej, dział finansowy używa jednej części swojego systemu ERP z jednym zestawem desygnatorów aktywów, podczas gdy produkcja używa całkowicie oddzielnego modułu ERP z innym zestawem desygnatorów aktywów. Pod koniec roku nikt nie jest w stanie pogodzić tych dwóch zestawów liczb, a audytorzy zastanawiają się, dlaczego istnieją dziesiątki lub setki milionów dolarów rozbieżności w zakresie wyposażenia kapitałowego.

Są to klasyczne problemy wynikające z zestawu otwartych procesów biznesowych. Otwarta pętla ma miejsce, gdy nie budujesz wyraźnych punktów potwierdzenia wzdłuż linii przepływu procesu. W powyższym przykładzie było tak wiele procesów w pętli otwartej, że awaria była gwarantowana.

Tworzenie dwukierunkowych przepływów informacji

Oto jak rozwiązaliśmy ten problem. Od początku do końca modelowaliśmy każdy istotny przebieg procesu. Zidentyfikowaliśmy wszystkie otwarte pętle. Następnie opracowaliśmy proste sposoby zamykania tych pętli, pojedynczo, zaczynając od samego początku.

Krok pierwszy

Produkcja potrzebuje X, więc proszą działy finansowe o otwarcie zamówienia zakupu. Dział finansowy sprawdza teraz z działem produkcyjnym, aby potwierdzić, podając szczegóły poprzednich zamówień dla X z 24 miesięcy wstecz. Unika się przypadkowego powielania zamówień.

Krok drugi

Produkcja dostarcza działowi Finance zestawienie komponentów X, które zostaną wymienione w okresie eksploatacji. Dział finansowy tworzy znaczniki aktywów dla każdego komponentu i potwierdza w dziale produkcyjnym. Oba moduły ERP są wypełnione pasującymi znacznikami aktywów dla każdego komponentu, co umożliwia śledzenie w całym cyklu życia aktywów.

Krok trzeci

Odbiorca powiadamia finanse, które powiadamiają produkcję. Umieszczanie znaczników aktywów jest wykonywane przez stronę odpowiedzialną z działu produkcyjnego, aby upewnić się, że każda etykieta jest umieszczona na właściwym elemencie. Wszystkie tagi/komponenty są następnie ponownie potwierdzane dla dwóch modułów ERP.

Krok czwarty

Za każdym razem, gdy składnik jest wymieniany, dział produkcji informuje dział finansowy, a nowy znacznik zasobu dla tego składnika jest generowany i umieszczany na nowym składniku przez dział produkcji, a następnie potwierdzany w obu modułach ERP. Finanse następnie rozpoczynają proces usuwania starego komponentu z ksiąg, podczas gdy produkcja przechodzi proces likwidacji według Przewodnika Dobrych Praktyk (GMP). Pod koniec likwidacji dział produkcji informuje dział finansowy, aby można było usunąć zasób z ksiąg.

Szczegóły są nieco bardziej złożone niż ten uproszczony przykład, ale kwestia jest jasna: na każdym etapie drogi istnieją wyraźne kontrole i potwierdzenia.

Zapewnienie działań awaryjnych

W innym projekcie poproszono mnie o pomoc firmie usługowej w poprawie wskaźników zadowolenia klientów. Ich działalność polegała wyłącznie na przetwarzaniu roszczeń i obawiali się, że nie wygrywają przetargów. Co więcej, w zwycięskich ofertach późniejsze niezadowolenie klientów powodowało, że wskaźnik utraconych rachunków był zbyt wysoki.

Zidentyfikowanie sedna problemu, którym po raz kolejny były procesy w pętli otwartej, zajęło zaledwie kilka dni. Gdy potencjalny klient poprosił o ofertę, opiekun klienta używał swojego wewnętrznego systemu do wysłania zarysu wymagań klienta do osoby odpowiedzialnej za złożenie oferty. Twórca oferty tworzył wówczas ofertę i przesyłał ją klientowi. Miejmy nadzieję, że klient w końcu zareaguje, zwykle z pożądanymi modyfikacjami, które twórca oferty wbuduje w następną wersję. W pewnym momencie klient zaakceptowałby ofertę, a księgowość utworzyła nowe konto klienta, wystawił fakturę i poinformował zespół wprowadzający.

Pierwszy problem polegał na tym, że nie było wyraźnego potwierdzenia od twórcy oferty dla opiekuna klienta, więc czasami oferty nie były tworzone i wysyłane na czas i nikt o tym nie wiedział. Było to możliwe, ponieważ w systemie wewnętrznym nie było pola do wskazania terminu składania ofert, a twórca oferty był wiecznie przepracowany, co prowadziło do zbyt późnego składania ofert. Ze względu na słaby przepływ informacji w firmie, takie sytuacje nigdy się nie pojawiły.

Następnie zmiany w ofercie nie były przekazywane do menedżera konta. Miało to znaczenie, ponieważ to opiekun klienta poinformował zespół wprowadzający, gdy klient w końcu zapisał się na linii przerywanej. Często brief opierał się na wstępnym zrozumieniu opiekuna klienta, a nie na faktycznie zaakceptowanej przez klienta ofercie.

Po rozpoczęciu zaangażowania dokumenty klienta będą dostarczane i przekazywane do dowolnego członka zespołu z puli przetwarzania, który został przydzielony w danym tygodniu do ich obsługi. Ponieważ nie było jednoznacznego potwierdzenia odbioru, możliwe było zaginięcie dokumentów bez świadomości tego faktu, dopóki klient nie zaczął pytać, dlaczego nie otrzymuje wyników prac obróbkowych.

Kiedy przetworzone dokumenty były odsyłane do klienta, nie było potwierdzenia przy ich odbiorze, więc wszelkie brakujące dokumenty były tracone do wglądu, dopóki ktoś gdzieś nie zaczął narzekać na ich nieobecność.

Potwierdź kluczowe wydarzenia

Na każdym etapie procesu licytacji wbudowaliśmy wyraźne potwierdzenia. Stworzyliśmy obejścia niedociągnięć systemu, tak aby wszystkie krytyczne informacje zostały przechwycone, w tym data wymagana przez i kolejne modyfikacje oferty. Wdrożyliśmy jednoznaczne kontrole i potwierdzenia dla wszystkich przepływów informacji w biznesie wewnątrz firmy oraz pomiędzy firmą a klientem.

Na przykład, gdy klient wysłał paczkę dokumentów, wysłałby teraz wiadomość e-mail do menedżera konta klienta, informując go o tym. Opiekun klienta przekaże to stronie odpowiedzialnej za przetwarzanie roszczeń. Jeśli dokumenty nie wpłyną w ciągu trzech dni, zostanie podniesiony alarm. Po otrzymaniu dokumentów do klienta trafił e-mail z potwierdzeniem odbioru. Odwrotna sytuacja miała również miejsce, gdy firma odsyłała przetworzone dokumenty z powrotem do klienta.

Ponieważ większość klientów korzystała z poczty amerykańskiej do przetasowania dokumentów papierowych w tę i z powrotem, procesy w pętli zamkniętej wykorzystujące jawne kontrole na każdym etapie oznaczały, że wszelkie utracone dokumenty można było szybko zidentyfikować i podjąć kroki w celu naprawienia sytuacji.

Procedury obsługi wyjątków projektowych

Aby zobaczyć, jak można skonstruować procedury obsługi wyjątków w dość lekki, ale skuteczny sposób, przyjrzymy się kolejnemu przykładowi z życia wziętego, z jakim spotkałem się w swojej karierze, kiedy byłem dyrektorem ds. informatyki w organizacji naukowej zajmującej się badaniem przyczyn starzenie się i wyzwalacze chorób związanych z wiekiem.

Wszystkie instytuty badawcze finansowane przez NIH zawierają wiele indywidualnych laboratoriów, z których każde jest prowadzone przez głównego badacza (PI) i obsadzone przez różnych podległych naukowców i doktorów. W pewnym momencie PI potrzebuje nowej wielokomorowej tacki na odczynniki, więc proszą jednego z doktorów o stworzenie niezbędnego wniosku. Post-doc tworzy żądanie i wysyła je do działu Finance z prośbą o zgłoszenie zamówienia zakupu, pobierając PI, aby upewnić się, że PI jest świadomy, że żądanie zostało wysłane. Tymczasem PI ma ustawione automatyczne powiadomienie kalendarza, które przypomina im o sprawdzeniu statusu żądania, jeśli nie otrzyma potwierdzenia w określonym terminie. Zapewnia to mechanizm odporny na awarie w przypadku, gdy post-doc zapomni utworzyć lub wysłać niezbędne żądanie.

Teraz post-doc również ma automatyczne powiadomienie kalendarza, aby skontaktować się z działem finansów, jeśli nie otrzyma potwierdzenia zgłoszenia zamówienia w określonym czasie. Gdy Finance zgłosi zamówienie, post-doc otrzymuje wiadomość e-mail z potwierdzeniem, że zostało wysłane do dostawcy, a post-doc przekazuje to potwierdzenie do PI.

Na tym etapie kierownik informacji lub post-doc ustawia kolejne automatyczne powiadomienie w kalendarzu, aby upewnić się, że jeśli w określonym czasie dostawca nie otrzyma odpowiedzi, ktoś skontaktuje się z dostawcą, aby upewnić się, że otrzyma zamówienie i wyśle ​​zamówienie. zamówionego sprzętu.

Zakładając, że sprzedawca potwierdzi odbiór zamówienia zakupu i wyśle ​​przedmiot wraz z powiadomieniem o wysyłce, zostanie on przekierowany do PI lub post-doc. Następnie ustawiają ostateczne powiadomienie w kalendarzu na trzy dni po zaplanowanej dacie odbioru, aby upewnić się, że jeśli przedmiot się nie pojawi, wiedzą, że muszą skontaktować się ze sprzedawcą, aby śledzić, co się stało, i prawidłowo dostarczyć przedmiot. Jeśli pozycja dotrze zgodnie z planem, post-doc powiadamia dział finansowy, a jeśli organizacja stosuje znaczniki aktywów, można zainicjować ten zestaw procesów.

Na każdym etapie wymagane jest wyraźne potwierdzenie i dostępny jest podproces, aby zapewnić podjęcie działań naprawczych w przypadku przerwania głównego przepływu procesu. Nic nie jest zawieszone, niepotwierdzone ani niepodparte. Nie są wymagane żadne doraźne działania, ponieważ każdy wie, co jest wymagane i co zrobić, jeśli coś pójdzie nie tak.

Nauka tworzenia procesów zamkniętej pętli z SQL

Istota dobrego procesu jest bardzo podobna do sposobu, w jaki zaprojektowano relacyjne bazy danych oparte na SQL, aby zapewnić spójność transakcyjną. Każde działanie musi zostać potwierdzone, aby można było uznać je za zakończone. Cała komunikacja dwustronna wymaga wbudowanego wyraźnego potwierdzenia w ramach procesu, a procesy podrzędne opracowane w celu zapewnienia, że ​​jeśli potwierdzenie nie zostanie odebrane, podjęte zostaną właściwe działania. Odnoszący sukcesy kierownicy projektów powinni tworzyć procesy zamknięte w pętli, aby usprawnić przepływ informacji w firmie i oszczędzić organizacjom dużo czasu i pieniędzy.