Pokaz rzeczywistości

Pierwszym krokiem w budowie programu reengineeringu organizacji jest identyfikacja, co jest wartością z punktu widzenia klienta? Za co klient jest skłonny zapłacić? W przypadku firmy informatycznej na pewno nie jest nią kontrakt handlowy. Rzadko wartością są same „skrzynki” technologiczne albo przedsięwzięcie wdrożeniowe. Z reguły z punktu widzenia klienta wartością jest sprawnie działające i przynoszące pożytki jego organizacji rozwiązanie informatyczne, dobrze zintegrowane z jego strukturą organizacyjną. Jeszcze lepiej i trafniej można opisać jako infrastrukturę informatyczną wspierającą proces lub grupę procesów biznesowych klienta.

Trzeba się następnie zastanowić: Jakie procesy składają się na dostarczenie owej wartości klientowi? Najlepiej zaczynając od końca, od klienta. Dobrze do takiego ćwiczenia wziąć nie menedżerów, a praktyków. Jeszcze lepiej zaś, jeśli to tylko możliwe, prześledzić proces w rzeczywistym środowisku konkretnego kontraktu. Szybko wyjdą na jaw dwa zjawiska. Pierwsze to zderzenie z rzeczywistością: percepcja menedżerów różni się od realnych działań. Drugie, że w rzeczywistym procesie następuje mnóstwo odgałęzień i nawrotów, w których poprawia się coś zrobionego wcześniej, ktoś na kogoś czeka, ktoś robi coś dwa razy albo dwóch uczestników przerzuca się e-mailami, uzgadniając jakieś szczegóły, które powinny być znane od początku. To bolesny moment dla firmy, w szczególności dla rynkowego lidera, przyzwyczajonego, by myśleć i mówić o sobie w samych superlatywach. Ale trzeba go przejść, w myśl zasady, że nie tłucze się termometru, jeśli chce się zbić temperaturę.

Drugi krok to przyporządkowanie ról w procesie, czyli określenie, kto co wykonuje i za który produkt jest odpowiedzialny. I tutaj także czekają niespodzianki. Na przykład stwierdzenia uczestników procesu, że obaj robią ten sam krok i są jednakowo odpowiedzialni. Albo, co jeszcze bardziej prawdopodobne, że odpowiedzialność nie jest jasno rozdzielona i czynność wykonuje ten, komu akurat bardziej zależy. Produkt takiego ćwiczenia – mapy rzeczywistych procesów wraz z przydziałem ról oraz identyfikacją produktów poszczególnych kroków oraz określenie, co stanowi wartość z punktu widzenia klienta, a co nie (bo np. jest tylko korektą wcześniej wykonanych działań) – pozwala spojrzeć na firmę z zupełnie nowej perspektywy. Obnażenie skali marnotrawstwa czasu i wysiłku (w firmach, w których nie pracuje się systematycznie nad rozwojem procesów, takie marnotrawstwo na pewno ma miejsce) buduje dobry grunt pod przebudowę procesów w organizacji.

Program rozwoju procesów

Program rozwoju procesów w organizacji trzeba zacząć od determinacji zarządu oraz powołania niezależnego pełnomocnika ds. procesów. „Niezależnego”, gdyż musi przede wszystkim kierować się dobrem organizacji jako całości, nawet gdyby miało to naruszyć interesy poszczególnych uczestników.

Drugi element to zasilenie się wiedzą. Przede wszystkim na temat najlepszych praktyk, doświadczeń rynkowych, metod i standardów. W wielu dziedzinach zarządzania ugruntowana praktyka jest ważniejsza od teorii, ale akurat w inżynierii procesów jest inaczej. Nawet najbogatsze doświadczenie nie zastąpi porządnego przygotowania metodologicznego. To oczywiście nie znaczy, że pełnomocnik może być świeżym absolwentem uczelni; powinien mieć spore doświadczenie. Nie wolno jednak zapomnieć o zasileniu go duża ilością wiedzy.

Jak w każdym przedsięwzięciu, trzeba jasno określić cel, przy czym powinien on być zdefiniowany wg kryteriów biznesowych i ilościowych. Na przykład „chcemy za rok realizować nie mniej niż 10 wdrożeń w roku przy 20-proc. marży oraz zespole nie większym niż 6 osób na projekt. Liczba zgłoszeń błędów powdrożeniowych nie powinna przekraczać czterech miesięcznie”. Można odnieść się do któregoś modelu lub metodyki, ale sformułowanie celu w kategoriach samego standardu („chcemy wdrożyć TSP do końca roku”) zostanie odebrany jako jeszcze jedna droga zabawka w rękach zarządu.

Zmiana będzie albo ignorowana, albo wręcz sabotowana, świadomość jej znaczenia dla firmy będzie nikła, a skuteczność działania pełnomocnika i jego zespołu – znikoma albo żadna.

Przygotowanie gruntu pod przebudowę procesów można zakończyć krótkim wprowadzeniem dla wszystkich zaangażowanych, czyli z reguły dla całej firmy. Nie trzeba omawiać szczegółów i wchodzić w metodologiczne subtelności, ale przede wszystkim zdefiniować cel, środki, odpowiedzialność i przygotować wszystkich na zmianę i pokazać determinację zarządu w jej przeprowadzeniu.

I wreszcie, w ramach programu rozwoju procesów trzeba stopniowo podnosić procesy na nowy poziom dojrzałości. Przypomnijmy kolejne cechy charakterystyczne dla dobrego procesu, w kolejności ich prawdopodobnego pojawiania się w organizacji:

• realnie wykonywany,
• zarządzany, tj. wskazany jest właściciel i uczestnicy,
• kontrolowany jakościowow istotnych punktach,
• opisany przez mapy, instrukcje, procedury,
• zintegrowany z otoczeniem, tj. innymi procesami w tej samej organizacji,
• opisany ilościowo i opomiarowany,
• z określonymi limitami ilościowymi, po przekroczeniu których rutynowo uruchamiane są działania kontrolno-naprawcze,
• regularnie przeglądany z udziałem wyższego kierownictwa,
• stale doskonalony.

Rzecz w tym, że każdy z wyżej wymienionych elementów wprowadza nowe elementy i tworzy pola potencjalnych konfliktów. Pojawienie się kryteriów kontroli jakości – np. „dobry kontrakt z klientem musi obejmować umowę serwisową nie krótszą niż rok” – oznacza, że ktoś gdzieś wykona taką kontrolę i zgłosi zastrzeżenia do konkretnego przypadku i konkretnej osoby. Argument account managera w rodzaju „mój kontrakt jest specyficzny i umowa serwisowa będzie później” zderzy się z równie racjonalnym argumentem „zdecydowano, że umowa serwisowa ma być kompletna, a mi za to płacą, żebym wskazywał braki w kontraktach”. Jeśli zaczniemy zarządzać ilościowo, nagle powstanie pole do obiektywnego porównywania wydajności osób, zespołów itd. – a to kolejne spodziewane konflikty. W programie rozwoju procesów nie obędzie się więc bez umiejętnego zarządzania relacjami międzyludzkimi oraz konfliktami.

Zyski w długim okresie

W programie rozwoju procesów ważny jest odpowiedni rytm. Firma zarabia na swojej podstawowej działalności, a nie na doskonaleniu swoich procesów. Poza tym każdy człowiek ma swoją graniczną odporność na zmianę. Czasami trzeba po prostu przyhamować lub zrobić krok wstecz, po to by w długim okresie zyskać jeszcze więcej.

Program poprawy procesów to zamierzenie długofalowe, które – jeśli zostanie mądrze przeprowadzone – bardzo się opłaca. Z pewnością zaś powinny je przeprowadzić polskie przedsiębiorstwa informatyczne, bo w nowej sytuacji jest to dla nich jeden z warunków dalszej egzystencji.