Wprowadzenie do Business Process Improvement

Metodologia Business Process Improvement (BPI) została opracowana w firmie Ernst & Joung i opisana przez H. J. Harringtona [1] – Międzynarodowego Doradcę d/s Jakości piastującego m. in. funkcje prezydenta Międzynarodowej Akademii Jakości, honorowego doradcy Chińskiego Stowarzyszenia Sterowania Jakością, prezydenta i przewodniczącego Amerykańskiego Stowarzyszenia Sterowania Jakością, honorowego prezydenta Organizacji Sterowania Jakością Azji i Pacyfiku.

Podstawowe definicje

PROCES: Czynność lub grupa czynności, które rozpoczynają się od pobrania czegoś na wejściu, dodają do tego wartości (przetwarzają) a następnie dostarczają to coś (rezultat) wewnętrznemu lub zewnętrznemu klientowi. Proces zużywa zasoby organizacji aby zapewnić określone rezultaty.

PROCES PRODUKCJI: Każdy proces angażujący fizycznie hardware (przedmioty) i software (informacje, wiedzę), które podlegają przetwarzaniu z przeznaczeniem dla zewnętrznego klienta; proces produkcji dostarcza swój produkt do miejsca pakowania/załadunku. Przewóz produktów i ich dystrybucja nie należą do procesu produkcji.

Przykłady: wytwarzanie komputerów, przetwórstwo żywności dla potrzeb masowego konsumenta, rafinacja paliw płynnych, przerabianie żelaza na stal.

PROCES BIZNESOWY: Każdy proces tworzenia usług oraz każdy proces wspierający procesy produkcji. Proces biznesowy składa się z połączonych logicznie zadań, w których wykorzystuje się zasoby organizacji aby zaperwnić określony rezultat wspierający cele organizacji. Przykłady: Sporządzanie zamówień, projektowanie zmian, wynagradzanie, projektowanie procesu produkcji.

FUNKCJA: Grupa realizująca określoną część procesów biznesowych. Typowe funkcje to marketing i sprzedaż, rachunkowość, projektowanie i rozwój, zakupy i zapewnienie jakości.

SYSTEM: Punkty kontrolne stosowane w procesie aby upewnić się (sprawdzić), czy przebiega on wydajnie i skutecznie.

Podstawowe przesłanki metody BPI

  • W każdej organizacji codziennie realizuje się setki procesów biznesowych. Na ogół około 80% z nich to procesy powtarzalne, wykonywane regularnie w podobny sposób. Tego rodzaju procesami można i powinno się sterować (kontrolować) podobnie jak steruje się procesami produkcji.
  • Dzisiaj sam proces produkcji, technika i technologia wytwarzania, nie decydują o powodzeniu w biznesie. Decyduje o nim zarządzanie, nakładające punkty kontrolne i techniki sterowania (sprzężenia zwrotnego) do wszystkich działań odbywających się w firmie i biorące pod uwagę organizację jako całość, jako kompleks powiązanych ze sobą procesów.

Ogólne określenie BPI

Business Process Improvement (BPI) można określić jako metodę ulepszania procesów wspierających produkcję i świadczenia usług, wykorzystującą dorobek praktyczny z zakresu diagnostyki procesów i kierowania zmianami organizacyjnymi oraz zestaw specjalnie zmodyfikowanych narzędzi Praktycznej Inżynierii Przemysłowej.

Jedną z charakterystycznych cech BPI jako metody ulepszania zarządzania jest jej koncentracja na procesie a nie na strukturze organizacyjnej. Różnicę tę można ukazać za pomocą następującego zestawienia:

Koncentracja na organizacji Koncentracja na procesie
Problem stanowią pracownicy

Zatrudnieni

Wykonywanie mojej pracy

Rozumienie mojej pracy

Ocenianie osób

Zmienienie osób

Zawsze mogę znaleźć lepszego pracownika

Motywowanie ludzi

Kontrolowanie pracowników

Nie ufać nikomu

Kto popełnił błąd?

Korygowanie błędów

Sterowanie dół-góra (struktury organizacyjnej)

Proces stanowi problem

Ludzie

Sprawianie, aby rzeczy zostały wykonane

Wiedza o tym, w jaki sposób moja praca daje wkład do całości procesu

Mierzenie i ocenianie procesu

Zmienianie procesu

Zawsze mogę ulepszyć proces

Usuwanie barier

Rozwijanie ludzi

Jesteśmy razem w tym wszystkim

Kto pozwolił, aby pojawił się błąd?

Redukowanie wariancji

Sterowanie przez klienta

Jakość procesu i ulepszanie procesu

Procesy biznesowe wymagają ulepszania, gdyż w typowej organizacji proces pracy przebiega „w poprzek” pionowej struktury organizacyjnej, co powoduje, że w wielu miejscach pojawiają się luki, nakładanie się czynności, nadmiar czynności kontrolnych itp., zjawiska pogarszające jakość procesów.

Jakość procesu biznesowego definiuje się na dwa sposoby. Po pierwsze – jako cele procesu ulepszania:

Trzy cele (ang. objectives) BPI:

  • podnieść skuteczność procesów – aby produkowały pożądane rezultaty,
  • podnieść wydajność procesów – aby oszczędniej zużywały zasoby,
  • podnieść elastyczność procesów – aby lepiej adaptowały się do zmian wymagań klientów i biznesu.

Drugie określenie odpowiada na pytanie, czym charakteryzuje się dobrze zdefiniowany i dobrze zarządzany proces

Dobrze zdefiniowany i dobrze zarządzany proces to taki, który:

a) ma kogoś, kto jest odpowiedzialny za sprawny przebieg procesu, kto dba, aby proces był skuteczny, wydajny i elastyczny, aby produkował pożądane rezultaty; osoba taka nazywana jest właścicielem procesu (process owner),

b) ma dobrze zdefiniowane granice (zakres),

c) ma dobrze zdefiniowane wewnętrzne połączenia i odpowiedzialność,

d) ma udokumentowane zadania, procedury i wymagania szkoleniowe,

e) ma instrumenty pomiaru i kontroli (punkty kontrolne) umieszczone w miejscach bliskich wykonywanym działaniom,

f) ma instrumenty pomiaru zorientowane na wymagania klienta oraz wartości docelowe (określone wyniki, jakie należy uzyskać, targets),

g) ma znany czas cyklu,

h) ma sformalizowane procedury zmian,

i) ma w sobie wiedzę o tym, jak dobry może być (benchmarks).

Cel BPI

Głównym celem realizacji BPI w przedsiębiorstwie jest zapewnienie, aby w organizacji zachodziły procesy biznesowe które:

  • eliminują błędy,
  • redukują opóźnienia,
  • maksymalizują wykorzystanie aktywów,
  • promują rozumienie biznesu,
  • są łatwe do prowadzenia,
  • są przyjazne dla klienta,
  • adaptują się do zmiennych wymagań klienta,
  • wyposażają organizację w przewagę konkurencyjną,
  • redukują nadmiar pracy

C. d. n.

————————-

[1] Harrington H. J., Business Process Improvement. The Breakthrough Strategy for Toatal Quality, Productivity and Competitiveness, MaGraww-Hill, Inc. 1991

Schemat blokowy procesu biznesowego – przykład

Na początku analizy procesu biznesowego natrafiamy na trudność w zdefiniowaniu jego granic. Sporządzenie schematu blokowego jest jednym ze sposobów pokonania tej trudności, a ponadto często pozwala wykryć główne dyskusyjne punkty w organizacji procesu.

Przypadek

Fabryka produkuje wyroby na oba rynki: konsumpcyjny i profesjonalny. Odkąd klienci profesjonalni zwiększyli częstotliwość zamawiania wyrobów niekatalogowych (tzn. w wykonaniu specjalnym), fabryka odczuwa ekonomiczne i organizacyjne konsekwencje nieuporządkowanej polityki wobec takich klientów. Potwierdzanie zamówień „nietypowych” trwa zbyt długo, trudno jest także opracować politykę cenową oraz ocenić opłacalność realizacji takich zamówień (zwłaszcza składanych przez nowych, obiecujących klientów).

Wstępna analiza procesu potwierdzania zamówień miała na celu znalezienie miejsc w procesie, które wymagają przeprojektowania, aby skrócić jego czas. Została przeprowadzona przez konsultanta wewnętrznego, przy pomocy autora i pod jego nadzorem. Niniejszy opis wykracza nieco poza to, co zrobił ów konsultant.

Poniższa ilustracja pokazuje schemat blokowy procesu wykonany w ramach wspomnianej analizy.

Ilustracja

Schemat blokowy przykładowego procesu potwierdzania zamówień.

Schemat blokowy przykładowego procesu potwierdzania zamówień.

Przebieg analizy wstępnej

  1. Przy definiowaniu (identyfikowaniu) procesu biznesowego należy trzymać się zasady, że zaczynamy od identyfikacji końca procesu, pytając, co proces produkuje. Obserwacja i rozmowy z pracownikami pozwoliły stwierdzić, że proces zawsze produkuje odpowiedź kierowaną do Działu Sprzedaży, a jeśli stan negocjacji z klientem na produkt niekatalogowy pozwala, proces produkuje także zlecenie do Sekcji Harmonogramowania Produkcji.
  2. Następny krok to wyznaczenie początku procesu biznesowego, czyli zdarzenia, które „wyzwala” bądź „inicjuje” proces, czy też „mobilizuje” zasoby ludzkie. Zdarzeniem tym jest w naszym przypadku otrzymanie zamówienia od klienta.
  3. Ustalenie modelu procesu (podejścia). W naszym przypadku wchodziły w grę 2 możliwości:
    • potraktowanie procesu jako „posiadanego” i prowadzonego („pilotowanego”) przez osobę odpowiedzialną; wówczas wszelkie zasoby dodatkowe potrzebne do potwierdzenia zamówienia należałoby potraktować jako zasoby pobierane przez proces, spoza tzw. granicy górnej procesu;
    • potraktowanie procesu jako przetwarzania informacji (ang. processing – tu zbieranie odpowiedzi na pytania, stawianie pytań rutynowych i odpowiadanie na nie, wreszcie budowanie dokumentu/ów z odpowiedziami)

    Sprawdzono, że możliwość pierwsza miałaby zastosowanie do potwierdzania zamówień na wyroby katalogowe, ale w przypadku produktów niekatalogowych właściwie nie wiadomo, kto jest odpowiedzialny za opracowanie odpowiedzi klientowi (dokumentację po prostu puszcza się obiegiem). Dlatego przyjęto model processing.

  4. Prześledzono „ścieżki” przetwarzania informacji od końca do początku. Najłatwiej było stwierdzić, że odrzucenie zamówienia jest „filtrowane” przez Szefa Wydziału Produkcyjnego. To było stwierdzenie zdumiewające, a jeszcze bardziej zaskakujące było to, że bardzo rzadko zdarza się potwierdzanie zamówienia bezpośrednio po uzyskaniu pozytywnej opinii specjalistów (wykryto to dopiero analizując dokumentację z 25 ostatnich zamówień „nietypowych”). Inaczej mówiąc, w większości przypadków decyzję o przyjęciu bądź odrzuceniu zamówienia podejmował Szef Wydziału Produkcyjnego, niezależnie od opinii specjalistów. UWAGA: Na wykresie powinno być napisane „opinie negatywne i pozytywne”, a nie tylko „opinie negatywne”, ale przytaczam rysunek w wersji oryginalnej, „chroniącej skórę” menedżerów ;).
  5. Dla upewnienia się, że proces został prawidłowo przeanalizowany, prześledzono przebieg 25 ostatnich zamówień nietypowych oraz 25 zamówień typowych od początku do końca procesu.

Wnioski

  1. Procedura analizy. Wyznaczenie końca procesu było stosunkowo łatwe, gdyż praca Działu Sprzedaży jest dobrze zbiurokratyzowana: każdy temat ma odrębną dokumentację papierową i komputerową, a większość korespondencji wewnętrznej przechodzi przez dziennik podawczy. Nawiasem mówiąc dzięki temu również analiza pracy specjalistów (konsultantów) nie nastręczała trudności.
  2. Następne kroki. Do analizy przeglądowej przepływu procesu skierowano 2 główne zagadnienia:
    • Dlaczego mimo opinii specjalistów decyzje podejmuje w większości przypadków Szef Działu Produkcyjnego oraz jakie ma to konsekwencje ekonomiczne? W rozmowach z pracownikami stwierdzono bowiem, że w przypadku opinii negatywnych przyjęcie zamówienia wiąże się z koniecznością zastosowania „obejść”, czyli projektów i technologii nieuzasadnionych z punktu widzenia inżynierskiego, ale być może uzasadnionych z punktu widzenia biznesowego (np. możliwość „złapania” dużego klienta). Dobrze opracowana analiza powinna być jedną z podstaw standardowej polityki wobec zamówień „nietypowych”.
    • Jakie są możliwości skrócenia cyklu opiniowania? Stwierdzono bowiem, że opinowanie trwa nadmiernie długo w porównaniu z benchmarkami.
  3. Następne kroki. Dodatkowo postawiono zagadnienie odbiorcy odpowiedzi. W analizowanym procesie odpowiedź jest przekazywana do Działu Sprzedaży, podczas gdy benchmark z przedsiębiorstw fińskich wskazuje, że możliwe jest na tym etapie przeniesienie kontaktów z klientem bezpośrednio w ręce wykonawców zamówienia (mistrza kierującego realizacją zlecenia) z bardzo pozytywnymi skutkami.

Dalszy ciąg analizy omawianego przypadku przedstawiono w artykule Karta przepływu procesu biznesowego – przykład.


Karta przepływu procesu biznesowego – przykład

Często schemat blokowy procesu biznesowego jest zbyt ogólny i nie sposób na jego podstawie zaproponować środków ulepszenia procesu. Potrzebny jest bardziej szczegółowy opis, którego dostarcza karta przepływu procesu.

Przypadek

Jest to dalszy ciąg analizy przypadku, dla którego sporządzono schemat blokowy procesu. Karta przepływu procesu (ang. flowchart) przedstawiona jest na rysunku poniżej.

Główny cel tej analizy to sprawdzenie możliwości skrócenia procesu konsultacji, który trwa ok. 10 dni. Dodatkowo postanowiono nieco głębiej rozpoznać przyczyny nieskuteczności opinii konsultantów, przejawiającej się w tym, że niezależnie od ich opinii ostateczną decyzję podejmował Kierownik Wydziału Produkcyjnego. Przypuszczano bowiem, że przyczyny obu wad procesu mogą być wspólne albo powiązane.

Ilustracja

Karta przepływu przykładowego procesu potwierdzania zamówień.

Karta przepływu przykładowego procesu potwierdzania zamówień.

UWAGI

  1. Proces pobiera dokument, który jest kopią zamówienia z dołączonym do niego plikiem papieru na opinie konsultantów. Nie było więc potrzeby umieszczania w obrębie procesu żadnego symbolu przedstawiającego ten dokument, który jest tylko uzupełniany opiniami.
  2. Symbole przedstawiające elementy procesu łączono liniami, a nie strzałkami, gdyż z góry wiadomo, w którym kierunku biegnie proces.
  3. Zgodnie z ustaleniami analizy wstępnej nie rozpatrywano zagadnienia KTO konkretnie emituje dokumenty produkowane przez proces. Zaznaczono to oddzielając obszar wykonawcy tych czynności liniami kropkowanymi, a nie kreskowanymi.

Wnioski:

  1. Na karcie przepływu procesu ujawniono błędy organizacji procesu. Pierwszy z nich jest widoczny na pierwszy rzut oka: linie biegnące od liter T („tak”) i N („nie”) spotykają się. Postawiono hipotezę, że kryteria profesjonalne konsultantów są niewłaściwe bądź niewystarczające, aby spowodować właściwą reakcję. Drugi błąd, to sekwencyjna praca konsultantów, która jest przyczyną nadmiernie długiego czasu procesu.
  2. Mimo, że rozwiązania obu problemów wydają się oczywiste, w praktyce wymagały eksperymentowania.

Wskaźnik operacyjny procesu biznesowego

Wskaźniki operacyjne większości procesów biznesowych są niezmiernie niskie. Nie należy jednak wyciągać z tego pochopnych wniosków.

Dwa rodzaje wskaźników operacyjnych

Wskaźnik operacyjny (ang. operation rate, operating rate) stanowi miarę wykorzystania zasobów przedsiębiorstwa. W praktyce stosowane są dwa rodzaje wskaźnika operacyjnego.

Pierwszy mierzy stopień wykorzystania zasobów z punktu widzenia pracy ludzi i urządzeń. Najczęściej jest to po prostu stopień wykorzystania zdolności produkcyjnych (tzw. factory operation rate, factory operating rate).

Drugi mierzy stopień wykorzystania zasobów z punktu widzenia przetwarzanego materiału bądź informacji (ew. dokumentu), czyli w perspektywie processing (patrz. schemat blokowy dla przykładu). Najczęściej stosowanym wskaźnikiem tego rodzaju jest stosunek czasu elementów procesu przynoszących wartość dodaną do całkowitego czasu przerobu.

Przykład

Poniższy przykład ilustruje metodę pomiaru wskaźnika operacyjnego drugiego rodzaju. Pomiar przeprowadzono w celu oceny opłacalności uwolnienia części wydatków NIEPLANOWANYCH, ponoszonych przez kierowników wydziałów spod kontroli kontrolera budżetu.

Pomysł był prosty: skoro zatwierdzanie nieplanowanych wydatków angażuje pracę biurową oraz dramatycznie opóźnia zaopatrzenie w rzeczy niezbędne, choć nieprzewidziane, to może wyposażyć kierowników w rezerwę, którą dysponowaliby samodzielnie, bez potrzeby zgłaszania wydatków kontrolerowi.

Pomiar

Ilustracja

Zestawienie czasu elementów procesu zatwierdzania dokumentu.

Zestawienie czasu elementów procesu zatwierdzania dokumentu.

UWAGI

  1. W powyższym przykładzie operacja kontrolera trwa 1 minutę, natomiast cały proces trwa 3424 minuty. Wskaźnik operacyjny wynosi więc 1/3424=0,043%. Jest to typowy rząd wielkości wskaźnika dla procesów biznesowych. W procesach produkcyjnych wskaźnik ten jest znacznie wyższy, w typowych przypadkach waha się w szerokich granicach 0,1% – 70%.
  2. Niska wartość wskaźnika operacyjnego sama w sobie nie może być wystarczającym powodem dla wprowadzania radykalnych zmian w procesie. Należy bowiem zwrócić uwagę na to, że przez prawie każde stanowisko pracy biurowej przechodzi wiele procesów. Długie czasy oczekiwania spraw w toku mają głębszą przyczynę, a zazwyczaj wskaźnik operacyjny pierwszego rodzaju (tzn. wskaźnik wykorzystania czasu pracy przez pracowników) nie jest niski.

Dalszy ciąg przykładu

Mimo ewidentnej potrzeby upoważnienia kierowników do samodzielnego dokonywania drobnych zakupów nieplanowanych pomysł nie został zrealizowany. Odmówili kierownicy, którzy nie chcieli wziąć na siebie odpowiedzialności za samodzielne zatwierdzane takich zakupów, chociaż nie wymagano od nich nawet uzasadniania – wystarczyć miało oświadczenie (konieczne z uwagi na spójność systemu księgowania), że zakupów dokonali zgodnie z potrzebami oraz ze swoją najlepszą wolą i wiedzą.


Ocena procesu biznesowego pod kątem wartości dodanej

Nie istnieje metoda bezpośredniego pomiaru wartości dodanej przez procesy biznesowe. Można jednak zastosować ocenę jakościową.

Zasada oceny

Ocena jakościowa wartości dodanej przez poszczególne procesy biznesowe polega po prostu na ich klasyfikacji. Harrington proponuje 3 kategorie takiej klasyfikacji, wyróżniając:

  • procesy dodające rzeczywistej wartości klientowi,
  • procesy nie dodające bezpośrednio wartości klientowi, ale niezbędne dla funkcjonowania biznesu,
  • procesy bez wartości dodanej.

Klasyfikacji dokonuje się, wg Harringtona, w kilku krokach przedstawionych na poniższym schemacie.

Ilustracja

Schemat klasyfikacji procesów biznesowych ze względu na wartość dodaną.

Schemat klasyfikacji procesów biznesowych ze względu na wartość dodaną.

UWAGI

Najtrudniej jest ustalić, jakiego rodzaju proces daje biznesową wartość dodaną. Pomocną wskazówką może być stwierdzenie, że do tej kategorii zaliczmy procesy:

  • zapewnienia zasobów niezbędnych dla funkcjonowania procesów dających rzeczywistą wartość dodaną,
  • te, które wypełniają wymagania innych, niż klient, kontrahentów społecznych.

Analiza koszt-cykl procesu biznesowego – przykład zastosowania

Połączenie oceny wartości dodanej z analizą koszt-cykl procesu biznesowego pozwala wyznaczyć priorytety programu usprawnień.

Zestawienie elementów procesu biznesowego, takie jak w przykładzie jest punktem wyjścia do analizy cykl-koszt. Prowadząc tę analizę często posiłkujemy się wykresem, na którym w kierunku pionowym nanosimy koszt procesu narastająco (skumulowany), a w kierunku poziomym nanosimy czas trwania poszczególnych elementów cyklu.

Poniższy przykład pokazuje taki właśnie wykres, ale uzupełniony o wyniki oceny procesu pod kątem wartości dodanej w taki sposób, że każde działanie ujęto z uwzględnieniem towarzyszących mu elementów z biznesową wartością dodaną oraz elementów bez wartości dodanej.

Rys. 1. przedstawia wyniki takiej analizy przed usprawnieniem procesu.

Rys. 1.

Wykres koszt-czas cyklu przed ulepszeniem.

Wykres koszt-czas cyklu przed ulepszeniem.

Oznaczenia w legendzie rysunku:

  • RVA – elementy dające rzeczywistą wartość dodaną (ang. Real Value Added)
  • BVA – elementy dające biznesową wartość dodaną (ang. Business Value Added)
  • NVA – elementy bez wartości dodanej (ang. No Value Added)

Należy zwrócić uwagę na to, że elementy BVA zostały zakreskowane lekko, elementy NVA zacienione mocniej. W ten sposób największe pola powierzchni wskazują ewentualne priorytety usprawnień, a wśród tych priorytetów pola zacienione, a w dalszej kolejności zakreskowane, sugerują rangę priorytetów.

Rys. 2.

Wykres koszt-czas cyklu po ulepszeniu.

Wykres koszt-czas cyklu po ulepszeniu.

Rys. 2. przedstawia wykres koszt-cykl tego samego procesu po usprawnieniu, narysowany na tle konturu procesu przed usprawnieniem. W ten sposób na pierwszy rzut oka można ocenić wielkość postępu w ulepszaniu procesu.

Oznaczenia legendy takie same, jak w Rys. 1.


Business Process Improvement – etapy BPI

Metodologia BPI została opracowana z myślą o przedsiębiorstwach dużych. Przeprowadzenie zmiany kulturowej w dużej organizacji jest szczególnie złożonym zadaniem, wymaga zarządzania projektowego. W dobrze zorganizowanym przedsiębiorstwie musi trwać przynajmniej około 2 lat. Szanse na sukces są duże, jeśli przeprowadzamy zmianę według właściwego scenariusza.

Początek

W praktyce istnieją 2 standardowe scenariusze zapoczątkowania przedsięwzięcia Business Process Improvement, a wybór jednego bądź drugiego zależy od zastanej kultury zarządzania organizacją.

W krajach europejskich przeważnie jest tak, że menedżerowie nie przywiązują bardzo dużej wagi do posiadania drobiazgowej kontroli nad wszystkim, co dzieje się w firmie oraz niechętnie podejmują odpowiedzialność, a propozycje zmian napotykają na stosunkowo silny opór społeczny. Najmniej „bolesnym” postępowaniem w takiej sytuacji jest zaangażowanie zewnętrznego konsultanta, który „bierze na siebie” trud pokonywania barier. Jednakże problemem jest wówczas tendencja do „spychania” na niego całości odpowiedzialności. Jeśli w tej grze przeważy postawa, że „to sprawa konsultanta, nie nasza”, szanse na sukces są bliskie zeru. Najczęściej pokonuje się tę przeszkodę umiejscawiając konsultanta bardzo wysoko w hierarchii organizacji, np. powierzając mu stanowisko zastępcy Prezesa (nie pełnomocnika – to za mało) i wyposażając w uprawnienia umożliwiające mu dyscyplinowanie kadry. Konsultant ze swej strony tak „ustawia” tryb swojej pracy, aby zapewnić kierownictwu naczelnemu panowanie nad przebiegiem zmian.

W opisanym przypadku zapoczątkowanie programu BPI należy do konsultanta, który wykonuje wstępną fazę („Etap 0″).

Etap 0. Diagnoza wstępna

  1. Diagnoza wstępna CAŁEJ firmy: jej produktów, sposobu działania, systemu informacyjnego.
  2. Sformułowanie kluczowych zagadnień menedżerskich.
  3. Określenie obszarów, których usprawnienie potencjalnie da największe korzyści z punktu widzenia całości firmy.
  4. Zaproponowanie jednego-dwóch tzw. podejść do rozwiązania wybranych zagadnień.
  5. Na podstawie powyższych materiałów zaproponowanie programu usprawnień.
  6. Prezentacja i uzyskanie zatwierdzenia programu przez Prezesa/Zarząd

W innych ważnych regionach (Azja i USA) menedżerowie na ogół entuzjastycznie podejmują odpowiedzialność, natomiast kwestia kontroli nad biegiem wydarzeń traktowana jest odmiennie: w USA jak najpełniejsza kontrola jest często przedmiotem ambicji technokratycznie nastawionych menedżerów, w Japonii jest przeważnie decentralizowana i delegowana na niskie szczeble. Przedstawiony poniżej scenariusz proponowany przez Harringtona jest przeznaczony dla firm prowadzonych w „stylu” amerykańskim. Dla potrzeb niniejszego materiału nazywamy go scenariuszem zmiany kontrolowanej

Scenariusz zmiany kontrolowanej

Etap 1. Organizowanie dla ulepszania

Cel: Zapewnić sukces poprzez budowanie przywództwa, zrozumienia i poczucia obowiązku.

Działania:

  1. Utworzenie Komitetu Wykonawczego
  2. Zaangażowanie (wybranie) lidera BPI
  3. Szkolenie wykonawców
  4. Opracowanie modelu ulepszania
  5. Zakomunikowanie celów pracownikom
  6. Przegląd strategii biznesu i wymagań klienta
  7. Wybranie procesów krytycznych
  8. Wyznaczenie właścicieli procesów
  9. Wybranie członków Zespołu Roboczego

Etap 2. Rozumienie procesu

Cel: Zrozumieć wszystkie wymiary obecnego procesu biznesowego

Działania:

  1. Zdefiniowanie zakresu i misji procesu
  2. Zdefiniowanie granic procesu
  3. Szkolenie dla członków zespołu
  4. Opracowanie ogólnego opisu (ang. overview) procesu
  5. Zdefiniowanie miar wymagań klienta i biznesu oraz oczekiwań wobec procesu
  6. Sporządzenie diagramu przepływu procesu
  7. Zebranie danych o kosztach, czasie i wartości
  8. Przeprowadzenie badania terenowego (wzdłuż procesu)
  9. Uchwycenie i wyjaśnienie różnic
  10. Uaktualnienie dokumentacji procesu

Etap 3. Sreamlining – poprawa płynności przepływu procesu

Cel: Poprawienie wydajności, skuteczności i adaptacyjności procesu biznesowego

Działania:

  1. Szkolenie zespołu
  2. Identyfikacja możliwości ulepszeń:
    • Błędy i poprawki
    • Wysokie koszty
    • Niska jakość
    • Duże opóźnienia
    • Zaległości
  3. Zastosowanie technik ulepszania, na przykład:a) Eliminowanie biurokracjib) Eliminowanie działań nie przynoszących wartości dodanejc) Upraszczanie procesów

    d) Redukcja czasu procesu

    e) Założenie procedury sprawdzania poprawności procesu (ang. errorproof)

    f) Modernizacja sprzętu

    g) Standaryzacja

    h) Automatyzacja

  4. Dokumentacja procesu
  5. Dobór pracowników do ulepszonego procesu
  6. Szkolenie pracowników

Etap 4. Instrumenty pomiaru i kontroli

Cel: Wdrożenie systemu sterowania procesem dla bieżących ulepszeń

Działania:

  1. Opracowanie miar dla przebiegu procesu i wartości docelowych
  2. Utworzenie systemu sprzężenia zwrotnego
  3. Okresowy audyt procesu
  4. Utworzenie systemu oceny kosztów złej jakości

Etap 5. Ciągłe ulepszanie

Cel: Wdrożenie procesu ciągłego ulepszania

Działania:

  1. Kwalifikacja procesu
  2. Prowadzenie okresowych przeglądów kwalifikacyjnych
  3. Definiowanie i eliminacja problemów w procesie
  4. Ocena wpływu wprowadzonych zmian na biznes i na klientów
  5. Benchmarking procesu
  6. Zaawansowane szkolenie zespołu

UWAGI

W praktyce europejskiej organizacja zespołów realizujących program jest bardziej zróżnicowana, gdyż duża część zadań nie wymaga zaawansowanych technik zarządzania projektowego. Na przykład w jednym z przedsięwzięć autor jako konsultant inicjował organizację i pracę 4 projektów dużego rozmiaru oraz nadzorował pracę 10 zadań wykonywanych przez zespoły zadaniowe (task forces). Oprócz tego na bieżąco szkolił uczestników zespołów projektowych i zadaniowych oraz pomagał im w stosowaniu narzędzi analizy problemów i procesów. Inny konsultant, w przedsięwzięciu trwającym kilka lat, podobnie organizował i wspomagał pracę zespołów projektowych, zespołów zadaniowych, grup roboczych (funkcjonalnych), małych grup oraz osób indywidualnych.

Postawa „spychologii” przejawia się często niechęcią kierownictwa do powołania Komitetu Wykonawczego. Jednak powołanie go, na wysokim szczeblu (najczęściej na szczeblu wiceprezesa), jest konieczne, aby zapewnić programowi odpowiednio silne wsparcie. W wielkich organizacjach powołuje się Komitet Sterujący i Komitet Wykonawczy, ale w praktyce często lepiej pracuje się z jednym zespołem wysokiej rangi (można mu od początku nadać rangę Komitetu Sterującego, jeśli organizacja rzeczywiście jest wielka).

Królewska droga

Metodologia wielkich programów zmiany organizacyjnej opracowana przez konsultanta niemieckiego.

Metodologię zwaną „Królewską Drogą” opracował i sprawdził w praktyce w wielu programach Karl-Adolf Scholz. Jest to metodologia uniwersalna prowadzenia wielkich programów zmiany organizacyjnej, chociaż Autor konstruował ją z myślą o programach poprawy produktywności (PPP). Poniżej rysunki przedstawiające 3 fazy programu oraz Królewską Drogę, którą należy podążać, aby sukces programu był prawie pewny.

Rys. 1

Fazy dużego programu zmiany organizacyjnej.

Fazy dużego programu zmiany organizacyjnej.

Rys. 2

Królewska Droga dla faz 1 i 2.

Królewska Droga dla faz 1 i 2.

Rys. 3

Królewska Droga dla fazy 3 (realizacji).

Królewska Droga dla fazy 3 (realizacji).

UWAGI

  1. Królewska Droga jest właściwie rozbudowaną wskazówką, w jaki sposób należy rozłożyć działania i punkty kontrolne, aby zapewnić maksymalne szanse przeprowadzenia zmiany organizacyjnej mimo na ogół obojętnych lub niesprzyjających postaw menedżmentu i pracowników, które zawsze stanowią poważną przeszkodę przy większych przedsięwzięciach.
  2. Uniwersalność metodologii proponowanej przez Scholza objawia się tym, że jest ona skuteczna przy wszelkich tzw. podejściach (modelach czy koncepcjach zmiany) oraz że można w nią wmontować inne klasyczne metodologie, jak schemat Inżynierii Przemysłowej, zarządzanie projektami, BPI itp.

Najlepsze praktyki przemysłowe w projektowaniu oprogramowania i w usługach IT

Łasiczka z damą, czyli inny punkt widzenia

Przemysłowe podejścia i techniki organizacji pracy warto zastosować w IT.

Referat przygotowany na konferencję użykowników Oracle.
Prezentacja z tego wykładu znajduje się tutaj.


Najlepsze praktyki przemysłowe w projektowaniu oprogramowania i w usługach IT

Iwona D. Bartczak
Business Dialog

Andrzej Góralczyk
Dyrekcja.pl

Abstrakt. W referacie przedstawiono propozycje zastosowania wybranych najlepszych praktyk przemysłowych do zapewnienia jakości i produktywności w procesach projektowania sotware’u i świadczenia usług IT w przedsiębiorstwach. Sektor IT dopracował się szeregu specyficznych dla siebie rozwiązań w obu omawianych dziedzinach. Mimo to jakość oprogramowania w wielu obszarach zastosowań nadal wzbudza poważne zastrzeżenia użytkowników, a efektywność pracy działów IT w przedsiębiorstwach nadal pozostaje problemem. Wnioski i postulaty podnoszone przez uczestników projektów realizowanych przez Business Dialog i portal Dyrekcja.pl wskazują, że świadomość tych faktów jest powszechna w wśród kadry kierowniczej IT i niekiedy towarzyszy jej poszukiwanie lepszych rozwiązań w obu dziedzinach. Rośnie zainteresowanie najlepszymi praktykami wypracowanymi w przemyśle przetwórczym. Pojawiają się wycinkowe rozwiązania przeniesione wprost z przemysłu, jak np. podział pracy i ról w zespołach programistów, statystyczne sterowanie procesami przez jakość, czy Robust Engineering. Propozycje przedstawione w referacie idą dalej – ujmują te doświadczenia w sposób systematyczny, w ramach filozofii KAIZEN oraz pokazują przykłady przystosowania przemysłowych podejść i technik do zapewnienia jakości w projektowaniu software’u i do organizacji pracy działów IT.

Wprowadzenie

W rozwoju informatyki jako dziedziny działalności gospodarczej coraz wyraźniej widoczne jest poszukiwanie rozwiązań wypracowanych w innych sektorach. Obserwujemy ów trend na co dzień w toku projektów realizowanych z udziałem szefów informatyki przez Business Dialog i portal Dyrekcja.pl. Wśród postulatów podnoszonych przez uczestników tych projektów najwyraźniejsze dotyczą metod zapewnienia jakości oprogramowania oraz przebudowy roli informatyki w przedsiębiorstwach. Być może ważnym źródłem omawianego trendu jest niezadowolenie z poziomu jakości i produktywności osiąganych dotychczas technikami opracowywanymi samodzielnie przez informatyków.

Podobne zjawisko można było obserwować w historii bardziej dojrzałych sektorów, więc można przypuszczać, że dalsza ewolucja sposobów działania informatyki będzie w znacznym stopniu powtórką historii rozwoju przemysłu przetwórczego, najbardziej zaawansowanego pod względem zarządzania i organizacji pracy. Przypuszczenie to stanowi przesłankę zarysowanej poniżej propozycji przeniesienia najlepszych praktyk zarządzania z tradycyjnych dziedzin przemysłu do informatyki.

Inżynieria wartości i punkt widzenia Użytkownika

W tradycyjnych sektorach gospodarki ogólne ramy dla inżynierii projektowania, produkcji i procesów eksploatacji tworzy Inżynieria Wartości, która rozmaitymi metodami i technikami bada i ustala wymagania Klienta i Użytkownika, a następnie przekształca je w produkt – wyrób bądź usługę. Niektóre praktyki w projektowaniu i w obsłudze produktów informatyki mieszczą się w ogólnych ramach Inżynierii Wartości. Można je więc traktować jako punkt wyjścia do systematycznej, krok po kroku implementacji najlepszych praktyk przemysłowych do IT. Poniżej przedstawiamy systematykę podejść i metod Inżynierii Wartości ujętą w taki sposób, aby łatwo było w niej umiejscowić wybrane typowe praktyki projektowania oprogramowania oraz utrzymania infrastruktury informatycznej.

Projektowanie zintegrowane – wyższy stopień rozwoju projektowania równoległego (Concurrent Engineering), w którym poszczególne etapy procesu projektowania nakładają się na siebie i są wykonywane równolegle. Projektowanie zintegrowane jest możliwe pod dwoma warunkami: standard podstawowy produktu musi być dobrze określony (wiadomo co jest rowerem, a co samochodem), a komunikacja z Użytkownikiem i w łonie zespołu tworzącego nowy produkt musi być intensywna, pozbawiona barier.

W informatyce znany jest problem nadmiernie wydłużonego cyklu projektowania wg tradycyjnej metodologii „wodospadu” (waterfall model). Elementy projektowania równoległego pojawiają się w większych projektach budowy software’u, w szczególności w strefie otwartych standardów oprogramowania. Jednakże typowe dla współczesnej inżynierii oprogramowania rozwiązanie problemu wodospadu, mianowicie programowanie iteracyjne (szczupłe i ekstremalne) nie jest rozwiązaniem optymalnym. Zrodziło się zapewne dlatego, że nie są spełnione dwa wspomniane warunki – nie wiadomo do końca, czym jest projektowany produkt, a zespół projektantów pracuje „pod kloszem”. Wykorzystanie najlepszych praktyk projektowania zintegrowanego wymaga rozwiązania tych dwóch problemów.

Analiza wartości – ma na celu określenie minimalnego zestawu wymagań, które powinien spełniać produkt oraz znalezienie optymalnej pod względem ekonomicznym wielkości zasobów niezbędnych dla spełnienia tych wymagań (materiału, pracy, czasu, technologii, wyposażenia itd.). W sektorze informatyki postępuje się odwrotnie, z wiadomymi skutkami. Ocenia się na przykład, że aplikacje dla biznesu średnio mają 40% nadmiaru funkcjonalności, nigdy nie wykorzystywanego przez Użytkownika i są nadmiernie złożone jak na jego wymagania. Rozmiary infrastruktury także są zbyt wielkie na każdym szczeblu, od pojedynczego stanowiska pracy po wielkie systemy, a przez to jest ona nadmiernie kosztowna w całym jej cyklu życia. Przed informatyką stoi wyzwanie – rewolucja mentalna umożliwiająca uznanie punktu widzenia Klienta i Użytkownika jako JEDYNEJ podstawy dla definicji produktu i jego jakości.

Ekonomika cyklu życia produktu – odgrywa zasadniczą rolę w organizacji procesów projektowania, eksploatacji i wymiany produktu. W typowych przypadkach ok. 70% kosztów cyklu życia wyrobów takich, jak maszyny i urządzenia określanych jest na etapie projektowania. Należy przypuszczać, że podobnie jest z oprogramowaniem dla biznesu. Wśród najlepszych praktyk projektowania zapewniających ekonomiczność cyklu życia jest zasada formułowania założeń „od tyłu”: najpierw założenia dotyczące sposobu zakończenia okresu eksploatacji, następnie kolejno założenia określające plany obsługi (utrzymania infrastruktury), założenia użytkowe, założenia dotyczące rozruchu (uruchomienia eksploatacji), założenia określające sposób produkcji wyrobu i wreszcie założenia dotyczące organizacji procesów przedprodukcyjnych (produkcja próbna, testowanie, wykonanie prototypów). W metodologii projektowania software’u istnieją zaczątki podobnego podejścia, np. tzw. projektowanie kierowane testowaniem. Wydaje się zatem, że pełne wprowadzenie omawianej zasady dałoby się wprowadzić bez większych trudności.

„Druga noga” ekonomiki cyklu życia to organizacja utrzymania infrastruktury. Trzeba powiedzieć, że najlepsze plany obsługi, takie jak utrzymanie prewencyjne (zapobiegawcze) oraz produktywne (nastawione na maksimum efektu ekonomicznego w cyklu życia) należą do rzadkości zarówno w odniesieniu do wyposażenia tradycyjnego, jak i informatycznego. Jednakże w obszarze tradycyjnym najlepsze praktyki są kompletnymi systemami utrzymania i kompletnymi metodologiami, gotowymi do wykorzystania. Wykorzystanie ich wymaga m. in. modyfikacji miernika, jakim jest poziom obsługi (service level) oraz podejść do organizacji pracy działów IT uwarunkowanych wymogiem maksymalizacji tego wskaźnika.

Sterowanie przez jakość – według najlepszych praktyk jakość jest określana WYŁĄCZNIE przez Klienta, ale klientem jest zarówno Użytkownik urządzenia w firmie, jak i właściciel biznesu. Użytkownik wymaga określonego minimalnego, ale niezbędnego zestawu funkcji i cech produktu, a właściciel wymaga określonej progowej ekonomiczności procesów, w których system służy jako narzędzie. W ten sposób zostają określone granice, w których muszą mieścić się parametry rezultatu procesu. U podstaw sterowania przez jakość leży zasada, że utrzymanie rezultatu procesu w określonych granicach dokonuje się poprzez doskonalenie procesu, a nie np. poprzez selekcję rezultatów dobrych i odrzucanie niedobrych. Z drugiej strony wiadomo, że najlepszą strategią sterowania procesem jest redukowanie jego wariancji. W tradycyjnym przemyśle istnieją metodologie sterowania przez jakość właściwie każdym procesem.

W odniesieniu do procesów projektowania najbardziej rozpowszechnione metodologie to projektowanie eksperymentalne i projektowanie solidne (Robust Engineering). Znane są próby zastosowania obu metodologii do projektowania software’u, lecz doświadczenia te są fragmentaryczne i nie zostały upowszechnione.

W odniesieniu do procesów eksploatacji i obsługi stosowanych jest kilka metodologii sterowania przez jakość, z których najbardziej znane to SPC czyli Statystyczne Sterowanie Procesami oraz Sześć Sigma. Elementy obu podejść sprawdzają się ze znakomitymi wynikami w projektowaniu wielkich systemów informatycznych i aplikacji krytycznych w sektorze kosmicznym i obronnym i warte są upowszechnienia.

Inżynieria procesów – w jej ramach dwie metodologie nadają się do implementacji w ulepszaniu procesów projektowania i eksploatacji wyrobów i usług informatycznych – te same, które najpowszechniej stosowane są w przemyśle przetwórczym. Praktyczna Inżynieria Przemysłowa to metodologia ulepszania dokonywanego na niskich szczeblach organizacyjnych, najczęściej na szczeblu zespołu. Natomiast BPI czyli Przeprojektowanie Procesów Biznesowych, które można nazwać „łagodnym reengineeringiem” organizowane jest zazwyczaj i zarządzane ze szczebla przedsiębiorstwa.

Elementy pierwszej ze wspomnianych metodologii zaczynają pojawiać się w dziedzinie projektowania software’u w postaci podziału pracy pomiędzy osoby pełniące różne role w tym procesie np. analityka/architekta biznesowego, architekta systemów i aplikacji, programistów i testerów. Najlepsze praktyki przemysłowe nasuwają przypuszczenie, że właściwym kierunkiem ewolucji tego podziału pracy będzie łączenie dwóch pierwszych ról, jednakże dopiero wtedy, gdy pojawią się specjaliści o wysokich kompetencjach zarówno w dziedzinie użytkowania, jak i projektowania architektury produktów informatycznych.

Z punktu widzenia inżynierii procesów dziedzina utrzymania infrastruktury IT w przedsiębiorstwach wydaje się najbardziej zaniedbana, mimo upowszechniania najlepszych praktyk w rodzaju ITIL. Wydaje się, że u źródła tej słabości leży niedostateczne jeszcze rozumienie tych procesów biznesowych z punktu widzenia Klienta oraz zignorowanie najlepszych praktyk przemysłowych na rzecz podejść i technik wywodzących się z samej IT.

Podsumowując ten punkt można stwierdzić, że w zarządzaniu informatyką nieobecne są do tej pory zagadnienia ciągłości i płynności procesów, dystrybucji pracy, zdolności procesów itd.

KAIZEN sposobem na uprzemysłowienie informatyki

KAIZEN jest ogólną metodologią przejścia danej dziedziny gospodarki z rzemieślniczego do przemysłowego stadium rozwoju. Wiadomo, że zmiana o tak szerokim i głębokim zasięgu nie może dokonać się z dnia na dzień, wymaga nie tylko czasu, ale także systematycznego podejścia. Wśród wielu sprawdzonych w praktyce zalet KAIZEN jest to, że początek tej przemiany dokonywany jest z zastosowaniem technik organizatorskich wywodzących się z rzemiosła, które stopniowo uzupełniane są technikami profesjonalnej inżynierii i organizacji pracy.

Cele dalekosiężne programu KAIZEN dla IT mogą i chyba powinny być te same, co w przemyśle przetwórczym – rozwój ludzi, osiągnięcie radykalnej poprawy jakości produktów informatycznych i kilkunastokrotny wzrost produktywności w sektorze.

——–

Prezentacja z tego wykładu

——–

Patrz także KAIZEN dla IT

——–