Zarządzanie procesami wobec zmian

2009/09/11 — Andrzej Góralczyk

Artykuł ukazał się w Business Dialog Bulletin w październiku 2007 r.

„Optymalizacja procesów biznesowych w instytucjach finansowych, w środowisku ciągle nowych produktów, nowych klientów, nowych kanałów sprzedaży” – podsumowanie badania w sektorze finansowym.

Iwona D. Bartczak

Aż 83% respondentów to zdecydowani zwolennicy centralizacji zarządzania. Są przekonani, że o zdolności adaptacyjnej firmy decyduje elastyczny system modyfikowania procedur w miarę potrzeb.

W świetle Pani/Pana doświadczeń które czynniki najsilniej decydują o zdolności firmy do skutecznej adaptacji do zmieniających się zadań i warunków działania?

zmiany1

Połowa respondentów uważa, że oprócz tego liczą się kompetencje kadry menedżerskiej i jej zdolność do szybkiej zmiany sposobu działania. Prawie nikt z Respondentów nie liczy w tym względzie na samodzielność pracowników na niższych szczeblach, mających kontakt z rynkiem.

Są to najważniejsze wyniki badania przeprowadzonego na przełomie sierpnia i września wśród kadry kierowniczej 50 banków i firm ubezpieczeniowych przez firmę Business Dialog i jej partnera merytorycznego w tym projekcie – Business Objects, firmę doradczą w zakresie Business Intelligence.

Bronisława Trzeszkowska, członek zarządu Banku Pocztowego, nawiązując do tego wniosku z badania, przedstawia swoją opinię: „Jednym z istotnych elementów decydujących o skuteczności, rozpatrywanej również jako szybkość reakcji organizacji na zachodzące zmiany, jest włączenie do procesu modyfikacji obowiązujących procedur pracowników szczebla wykonawczego, bezpośrednio współpracujących z klientami. Identyfikacja zmian preferencji klientów w ramach bieżącej obsługi – i potem w trakcie wdrażania zmian – istotnie wpływa na poprawę jakości procesów, modyfikację procedur, podniesienie skuteczności sprzedaży. Umiejętność wykorzystania tego potencjału organizacji to oczywiści rola struktur zarządczych.”

Zdaniem respondentów nie ma łatwych rozwiązań problemu szybkości modyfikowania procedur w odpowiedzi na zmieniające się warunki prowadzenia biznesu i nowe zadania. „Z moich doświadczeń wynika, że standaryzacja prostych, elementarnych czynności znakomicie ułatwia osiąganie elastyczności organizacji i dodatkowo sprzyja eliminowaniu błędów” – tłumaczy Romuald Kępa, do niedawna prezes Pramerica.

Pomiaru efektywności ekonomicznej działania firmy w obliczu zmieniających się produktów, rynków i kanałów sprzedaży dokonujemy następującymi zestawami mierników:

zmiany2

Przekonaniu o omnipotencji wyższych szczebli zarządzania towarzyszy tendencja do mierzenia wyników firmy własnymi, specyficznymi dla firmy miernikami i do unikania mierników bardziej uniwersalnych, jak Zrównoważona Karta Wyników. Może to być wyrazem niechęci do stosowania benchmarków. Połowa respondentów uważa, że wykorzystanie danych zgromadzonych w bazach i systemach informatycznych powinno być zadaniem scentralizowanego i wyspecjalizowanego zespołu specjalistów.

Pomiaru efektywności ekonomicznej działania firmy w obliczu zmieniających się produktów, rynków i kanałów sprzedaży dokonujemy następującymi zestawami mierników:

zmiany5

Zdaniem większości respondentów główne bariery ograniczające wykorzystanie danych zgromadzonych w zasobach firmowych mają źródło w niedoskonałości architektury i integracji rozproszonych systemów informatycznych. Połowa respondentów wskazuje ponadto na niepewność i niekompletność danych, a z komentarzy do odpowiedzi można wywnioskować, że jest to skutek kreatywności pracowników i kierowników tworzących różne mierniki, gromadzących dane według swoich pomysłów i niejasnych definicji, bądź różnie nazywających te same zjawiska. „Jakość danych jest demonizowana. Informacji jest po prostu za dużo. Większość jest gromadzona niepotrzebnie. Głównym problemem nie jest zła jakość informacji ale właściwy ich dobór uwzględniający z jednej strony rzeczywiste potrzeby, z drugiej zaś ich dostępność. Nie ma problemu jakości informacji, jest problem właściwego doboru informacji” mówi Michał Jerzy Kuchta, dyrektor kontroli ryzyka w BPH Bank Hipoteczny.

Bariery najsilniej ograniczające wykorzystanie danych z różnych źródeł w planowaniu strategicznym, planowaniu nowych produktów i w badaniach marketingowych:

zmiany3

Zdaniem Aleksandra Wyki, partnera Human Capital Partners, kluczem do rozwiązania problemu jakości i trafności danych, a zatem ich wiarygodności jest decyzja, kto jest za dane odpowiedzialny w firmie czy w banku. „Odpowiedzialność za jakość danych musi być po stronie biznesu, a nie po stronie informatyki. Tymczasem zawsze ta odpowiedzialność jest przesuwana w stronę działu IT. On jest na ogół za słabo posadowiony w strukturach i hierarchiach banku czy firmy ubezpieczeniowej, aby wymusić odpowiednią jakość danych” – mówi Aleksander Wyka.

Zdecydowanym priorytetem strategicznym respondentów jest podnoszenie wartości firmy. Być może dzieje się tak dlatego, że w zasadzie wszystkie firmy spodziewają się fuzji i przejęć.

Priorytety strategiczne naszej firmy nastawione są przede wszystkim na…

zmiany4

Wszyscy respondenci oceniają swoją firmę według wyników, a analizują w rozbiciu dyktowanym przez segmentację rynku. Dwie trzecie respondentów nie stosuje mierników efektywności procesów. Wcześniejsze badania Business Dialog zaowocowały podobną konkluzją; stwierdzono w nich, że kierownictwa naczelne postrzegają efektywność firm w kategoriach wyników, a nie w kategoriach doskonałości procesów prowadzących do tych wyników. Komentując te wyniki Rafał Grodzicki, dyrektor w PZU powiedział: „Być może dzieje się tak dlatego, że proces doskonały nie może być procesem elastycznym. Ze względu na zmienność rynku i inne czynniki procesy są modyfikowane wielokrotnie w ciągu roku.”

—

Napisane w Business Dialog Bulletin, Sprawozdania z badań, Teksty. Tagi: , , , , , , , , , , , , . 1 komentarz »

Human Interaction Management – pionierska koncepcja inżynierii usług

2009/09/07 — Andrzej Góralczyk

Artykuł ukazał się w Business Dialog Bulletin w czerwcu 2007 r.

Na konferencji we Wrocławiu Keith Harrison-Broninski przedstawił koncepcję uznawaną za przełom w metodologii opisu i modelowania współpracy ludzi tworzących usługi.

Andrzej Góralczyk

Mam zwyczaj przygotowywać się do wysłuchania ważnego wykładu, więc przed wyjazdem do Wrocławia przejrzałem literaturę. Od razu znalazłem rzecz najciekawszą – autorzy oceniający pozytywnie koncepcję Keitha jednocześnie stawiają poważne zarzuty całemu nurtowi BPM – Business Process Management. Lektura sugeruje więc, że Human Interaction Management (HIM)  rozwija się w opozycji do BPM, ale historia myśli ludzkiej uczy, że opozycja jest zarazem kontynuacją. Zapewne za jakiś czas okaże się, w wyniku studiów metodologicznych, że nie inaczej jest w omawianym przypadku. Przy okazji znalazłem odpowiedź na pytanie, na które przed laty nie odpowiedział mi prof. Scheer – co to jest BPM? Otóż BPM jest rozszerzeniem technologii workflow, czyli jest technologią informatyczną i wbrew swej nazwie nie ma wiele wspólnego z procesami biznesowymi[1]. Spostrzeżenie zdumiewające i zarazem potwierdzające moje wcześniejsze podejrzenia[2].

Krytyka BPM ma niedługą tradycję, więc siłą rzeczy jest fragmentaryczna i sporo w niej uproszczeń. Jeden z zarzutów brzmi podobnie, jak główny zarzut wobec radykalnego reengineeringu – że ignoruje ludzi uczestniczących w procesie. Bardziej precyzyjnie – że projekt procesu nie uwzględnia różnorodności rzeczywistych sytuacji i ludzkich zachowań, lecz jest wyrazem iluzji, że ludzie będą robili dokładnie to, co zaprojektowano. Ja czasem strzelam z grubszej armaty gdy narzekam, że metoda modelowania procesu biznesowego nie respektuje podstawowej zasady Inżynierii Przemysłowej, wg której punktem wyjścia do modelu ma być proces rzeczywisty, a zadaniem projektanta jest przeprojektowanie go. Zamiast tego projekty BPM biorą za podstawę wyobrażenie systemu, który wydaje się projektantowi idealny, a ludzie uczestniczący w procesie mają być perfekcyjnymi wykonawcami procedur systemowych. Co gorsza, często takie wyobrażenie jest dowolne, co widać np. na diagramach rysowanych z wykorzystaniem notacji opracowanej specjalnie dla BPM[3] (ten zarzut domaga się bardziej gruntownego omówienia, na które nie ma tu miejsca). Kolejny koronny zarzut mówi o tym, że procesy projektowane w konwencji BPM ujmują wyłącznie przemieszczanie się pracy od jednego zasobu (stanowiska pracy bądź np. komputera) do drugiego, gdy tymczasem ponoć aż 85% procesów biznesowych przebiega inaczej[4]. Na przykład wtedy, gdy ludzie współpracują.

Rozpisałem się na temat krytyki BPM nieprzypadkowo – metodologia Human Interaction Management jest pod wieloma względami zupełnie odwrotna. Przede wszystkim opisuje współdziałanie ludzi uczestniczących w procesie biznesowym, w tym także ludzi będących klientami zewnętrznymi procesu. Po drugie, nie ogranicza opisu do działań z wykorzystaniem komputerów, lecz ujmuje także „ręczną” pracę papierową i komunikowanie się ludzi. Po trzecie, opisuje pracę taką, jaką ludzie wykonują w rzeczywistości, a nie w ramach jakiegoś wymyślonego systemu. Zresztą w ogóle mało prawdopodobne, aby „nachylenie systemowe” pojawiło się w takim opisie, gdyż to sami uczestnicy projektują przebieg swojej pracy, a nie tzw. analitycy biznesowi. Toteż mogą projektować różne wersje przebiegu swego współdziałania, uwzględniając różnorodność sytuacji, ról przyjmowanych w procesie i działań. Konsekwencją owego realizmu jest piąte założenie – HIM uwzględnia fakt nieprzewidywalności ludzkich działań i „pozwala” ludziom usprawniać proces w ramach realizacji konkretnych instancji procesu.

Notację HIM opracował Keith Harrison-Broninski na podstawie wyników wieloletnich badań nad procesami tworzenia usług (wykorzystując symbole notacji Rapid Application Development). Na etapie projektowania usługi opisuje się interakcje zachodzące pomiędzy rolami, które następnie – w fazie realizacji – są przypisywane Osobom (identity). Interakcje warunkują się kolejno, tzn. dana interakcja zachodzi w odpowiedzi na poprzednią. Opis „tego co ma być zrobione” zasadniczo ujmuje aspekt komunikacyjny interakcji. Treść komunikatu (message) może należeć do jednej z 44 kategorii i przybrać jedną z 23 form. Działania natomiast są domeną ról. Działanie może należeć do jednej z pięciu kategorii – może to być badanie (Research), ocena (Evaulate), analiza (Analyze), ograniczenie (Constrain) i zadanie (Task). Sekwencja tych pięciu działań w przytoczonej kolejności (REACT) stanowi jeden z podstawowych – wykrytych w badaniach – wzorców zachowania ludzi „produkujących” usługę. W różnych kontekstach biznesowych mają zastosowanie różne wzorce, a działania podlegają regułom. Na etapie realizacji konkretne działania (sekwencję działań) podejmuje ta osoba, która przyjęła daną rolę.

Keith sam przyznaje, że w odniesieniu do usług wykonał podobną robotę, jak pierwsi przedstawiciele naukowej organizacji pracy w odniesieniu do przemysłowych procesów wytwarzania wyrobów. Myślę, że dlatego właśnie HIM uznawany jest za przełomowy moment w analizie procesów tworzenia usług opartej na naukowych podstawach. Podzielam tę opinię.

Dysponując wspomnianym powyżej słownikiem interakcji i działań można zaprojektować „to, co ma być zrobione”. Boję się pisać „proces”, gdyż taki projekt silnie eksponuje działania i interakcje zachodzące między ludźmi, ale na skutek tego „to co ma zostać przetworzone” (processing) umyka trochę z pola widzenia i wygląda czasem na nie zdefiniowane – przynajmniej w moich oczach tak wygląda. Nie zawsze jasne jest także kryterium startu, które powinno być nieodzownym elementem każdego opisu procesu. Być może Keith także w ten sposób widzi swoje dzieło, gdyż nie używa słowa „proces”, lecz „opowieść” (story).

Opowieści można projektować na zwykłej kartce papieru, ale można także posłużyć się programem komputerowym HumanEdj. Spróbowałem i okazało się, że jest to trudne. Główną trudność sprawia mnogość kategorii opisu interakcji, a właściwie komunikatów. Moim zdaniem jest to sygnał, że metodologia HIM  będzie musiała przejść – podobnie jak niegdyś klasyczne narzędzia naukowej organizacji pracy – szereg uproszczeń. Druga porcja trudności wynika z niezbyt szczęśliwego doboru platformy, w której program został zrealizowany. Jest to wtyczka do Eclipse, działająca w środowisku maszyny wirtualnej Java i w związku z tym cały projekt (opowieść) ma strukturę drzewa – strukturę ewidentnie zbyt sztywną, nie pasującą do przedmiotu opisu.

Moje wątpliwości wzbudza też użycie słowa „management” w nazwie omawianej metodologii. Co prawda Keith wyróżnia dwa poziomy zarządzania działaniami, operacyjny i wykonawczy, lecz w opisach i diagramach HIM nie potrafię się tego dopatrzeć. Brakuje mi bowiem istotnego elementu zarządzania, mianowicie sprzężenia zwrotnego, dzięki któremu możliwe jest sterowanie przebiegiem działań. Moim zdaniem słowo „inżynieria” lepiej oddawałoby sens tego, czym jest HIM. Lecz skoro entuzjaści BPM mylą swoje projekty i programy z zarządzaniem, to może taka niewielka doza anarchii terminologicznej jest do zaakceptowania?

Konferencję Business Process Management Forum Practices for Business Agility zorganizowała wrocławska firma AION (http://www.aion.com.pl). Na stronie http://www.process.com.pl/ można znaleźć m. in. podsumowanie obrad.

———————–
[1]    Pyke, J. Why workflow sucks, ebizQ, 2006/11/29, http://www.ebizq.net/hot topics/bpm/features/7462.html
[2]    Por dyskusja w http://www.dyrekcja.objectis.net/biblioteka/techniki/bpi/schematblokowy01 oraz http://www.dyrekcja.objectis.net/biblioteka/techniki/bpi/flowchart02
[3]    Por np. http://en.wikipedia.org/wiki/Business Process Modeling Notation.
[4]    Pyke, J., op. cit.

—

Napisane w Business Dialog Bulletin, Teksty. Tagi: , , , , , . Zostaw Komentarz »

Na czym warto się skupić?

2009/09/07 — Andrzej Góralczyk

Artykuł ukazał się w Business Dialog Bulletin w czerwcu 2007 r.

Najistotniejsze problemy, które dzisiaj nie pozwalają firmom w pełni wykorzystać okazji stwarzanych przez koniunkturę, to ułomna współpraca w ramach łańcucha dostaw oraz niedoskonałe systemy planowania, zwłaszcza produkcji. Taki jest główny wniosek z majowego badania Business Dialog.

Iwona D. Bartczak

Z badania „Mądrość firm w czasach koniunktury: upraszczanie procesów i minimalizowanie strat” przeprowadzonego w maju 2007 przez Business Dialog we współpracy z HADATAP wynika niezbicie, że największym dzisiejszym zagrożeniem firm jest zaniedbywanie doskonalenia struktur i procesów wewnętrznych (67%), koncentracja na inwestycjach w zdobywanie rynku, kosztem wewnętrznych usprawnień (47%). W trzeciej kolejności wskazano zaniechanie unowocześniania zasobów produkcyjnych (40%), a jako czwarte – lekceważenie doskonalenia kwalifikacji kadry (33% odpowiedzi). Firmy doskonale wiedzą, że warto w czasie koniunktury inwestować w usprawnianie procesów i badania. Obie te pozycje wskazało po 60% respondentów. 53% wskazało modernizację zasobów produkcyjnych.

Paradoksem jest więc, że firmy wiedzą, jak powinny się zachowywać w czasie koniunktury, jakiej hierarchii celów przestrzegać, a jednak bardzo często tak nie czynią. Co jest przyczyną tego zjawiska? Brak wiedzy wewnątrz firmy? Brak motywacji do wyznaczania długofalowych celów? Interesy grup menedżerów i pracowników, które mogłyby być zagrożone w wyniku doskonalenia? W każdej firmie odpowiedź będzie inna, jednak samo zjawisko powinno pobudzić do działania właścicieli i rady nadzorcze oraz zarządów, pilnujących długoterminowych interesów całej firmy.

W badaniu szczególnie interesowano się procesem produkcyjnym. Po czym firmy poznają, że ten proces źle funkcjonuje? Przede wszystkim sygnalizuje im to niestabilna jakość produktów (60% odpowiedzi). Następnie równorzędny procent odpowiedzi uzyskały: wąskie gardła i spiętrzenia oraz trudności w synchronizacji procesu przy zwiększonej różnorodności produktów (47%). Zwracano również uwagę na nieterminowość wysyłek do klientów i brak informacji o produkcji w toku. Większość firm posiada systemy informatyczne wspomagające zarządzanie produkcją. Czy one źle wywiązują się ze swojego zadania? „Im więcej czasu mija od wdrożenia w przedsiębiorstwie zintegrowanego systemu informatycznego, tym bardziej rozwiązania biznesowe oddalają się od tego, co można osiągnąć przy pomocy nowszych technologii IT. Postęp w tej dziedzinie jest ogromny i pracownicy w firmie, mający wiele zadań, nie są w stanie na bieżąco śledzić nowych rozwiązań” – komentuje Zenon Parol, menedżer HADATAP. Jego opinie potwierdza odpowiedź menedżerów na pytanie ankiety o rolę systemów IT. Niemal wszyscy odpowiedzieli, że są użyteczne pod warunkiem, że systematycznie unowocześnia się je lub wymienia na bardziej odpowiadające biznesowi.

Na pytanie szczegółowe, jakie są najistotniejsze przyczyny strat, opóźnień i błędów w procesie produkcyjnym aż 80% respondentów wskazało brak współpracy w łańcuchu dostaw, 73% – niedoskonałość systemu planowania produkcji, a 60% opóźnienia w pozyskiwaniu istotnych informacji. Z praktyki najlepszych firm wynika, że eliminacja strat, opóźnień i błędów powinna być pierwszym działaniem usprawniającym funkcjonowanie firmy. Przeważnie daje to od razu znakomite rezultaty, a także jest punktem wyjścia do bardziej wyrafinowanych projektów doskonalenia i podnoszenia efektywności działania firmy.

Rozkład odpowiedzi w poszczególnych pytaniach wskazuje, że prezesi i dyrektorzy generalni analizują pracę firmy, a więc pracę ludzi, w kategoriach skutku i wyniku, natomiast dyrektorzy operacyjni częściej widzą proces i jego niedoskonałości. Większy potencjał jest w podejściu procesowym, ponieważ pracownicy uczestniczący w procesie mają realną możliwość zmieniania go, doskonalenia. Muszą jednak mieć do tego motywację i akceptację zwierzchników oraz poznać techniki ulepszania procesów. Gromadzeniem wiedzy o biznesie i procesach powinni zajmować się pracownicy w firmie, ale wiedzę o metodykach, rozwiązaniach, narzędziach i trendach najlepiej kupić od zewnętrznych dostawców.

Dyrektor informatyki uczestniczący w badaniu generalnie zgadzają się w swoich opiniach z dyrektorami biznesowymi, jednak widać pewne charakterystyczne różnice. Po pierwsze, są bliżej procesów, więc widzą, że negatywne wyniki firmy, np. dotyczące zdobywania rynku czy niestabilna jakość produktów wynikają właśnie z niedoskonałości w sterowaniu procesem lub w ustawieniu procesu. Szefowie IT nie są związani z praktyką produkcyjną i w związku z tym bardziej przejmują się wyeksploatowanym parkiem maszynowych i przestarzałą technologią niż menedżerowie biznesowi nawykli do codziennych problemów z tego wynikających. Po drugie, szefowie biznesowi bardzo mocno akcentują znaczenie kwalifikacji kadry, zdobywanie utalentowanych pracowników i menedżerów. Są skłonni w to inwestować. Szefowie IT nie dostrzegają tych problemów, być może dlatego, że nie odczuwają niedoboru kompetencji wśród swoich podwładnych.

Wydaje się, że jedni drugich mogą twórczo zainspirować. Menedżerowie odpowiedzialni za wyniki powinni dostrzec, że poprawia się je umożliwiając ludziom dobrą pracę poprzez prawidłowe ustawienie procesu i sterowanie nim, a nie tylko przez presję na pracowników, aby zwiększali wysiłek. Menedżerowie IT natomiast – dobrze, jakby nabyli silniejszego nastawienia na wynik, zwłaszcza gdy podejmują wdrożenia rozwiązań wspomagających i upraszczających procesy biznesowe. Z dialogu między tymi dwiema grupami menedżerów mogą powstać bardzo skuteczne pomysły usprawniania firm.

Poniższe dwa zestawienia prezentują część wyników badania.

1. Jakie są najważniejsze zagrożenia czyhające na dobrze rozwijającą się firmę w czasach koniunktury, zagrożenia płynące z jej organizacji i systemu zarządzania?

47%    a. silna koncentracja na zdobywaniu udziałów w rynku i zwiększaniu sprzedaży, lekceważenie wewnętrznych usprawnień
13%    b. rozdźwięk między rosnącym popytem a możliwością jego zaspokojenia w terminie
27%    c. lekceważenie jakości, gdyż „rynek i tak weźmie wszystko”
67%    d. zaniedbanie doskonalenia struktur i procesów wewnętrznych
33%    e. lekceważenie doskonalenia kwalifikacji kadry
40%    f. zaniechanie inwestycji w unowocześnianie technologii produkcyjnych
7%    g. spowolnienie rozwoju systemów wsparcia biznesu
20%    h. niska motywacja do innowacyjności
13%    i. brak umiejętności lub niechęć do ujawniania strat i błędów
7%    j. wewnętrzne słabości, które nie pozwalają wykorzystać wszystkich okazji rynkowych

2. W co najlepiej inwestować podczas dobrej koniunktury?

20%    a. marketing i promocję
20%    b. infrastrukturę i kadrę handlową
20%    c. nowe produkty
53%    d. modernizację zasobów produkcyjnych
27%    e. systemy informatyczne wspierające biznes
60%    f. usprawnianie procesów biznesowych
60%    g. badania i rozwój
20%    h. pozyskanie dobrej kadry menedżerskiej i specjalistów
13%    i. szkolenie

Napisane w Business Dialog Bulletin, Sprawozdania z badań, Teksty. Tagi: , , , , , , , , , , . Zostaw Komentarz »

„Odruch stada” wobec Open Source

2009/09/06 — Andrzej Góralczyk

Artykuł ukazał się w Business Dialog Bulletin w maju 2007 r.

Będąc już jakby weteranem wdrożeń wolnego oprogramowania nie domyślałem się nawet, z jak wielką rezerwą jest ono traktowane.

Paweł Moszumański

Dopiero niedawno, podczas dyskusji o przyszłości Open Source usłyszałem, że w świadomości wielu managerów-decydentów Open Source to tylko młodzi ludzie, fascynaci, najczęściej hakerzy… Tak to jest przedstawiane przez media. W efekcie decydenci nie wiedzą, jak poważny potencjał intelektualny jest zaangażowany w Open Source. Nie wiedzą, że za Open Source stoją stoją największe światowe uczelnie, a także czołowe firmy informatyczne, gdyż to pozwala im rozwijać rozwiązania szybciej, niż konkurencja. To oznacza, że Open Source jest de facto motorem postępu.

Teraz przy wielu okazjach drążę temat i zastanawiam się, co wstrzymuje decydentów-menadżerów od podjęcia decyzji o wdrożeniu oprogramowania Open Source. Mam na wytłumaczenie tego zjawiska kilka teorii.

  1. „Lepszy stary wróg niż nowy”. Wróg czy przyjaciel – jeszcze nie wiemy ale strach przed nowym, nie znanym i tajemniczym jak cale IT paraliżuje nas… Po co następny kłopot, kupmy to co mają wszyscy… i tu przechodzimy do następnej teorii.
  2. Przypadek zbierających chrust Indian. Kiedyś był dowcip o Indianach, którzy zbierali chrust bo usłyszeli w radio że będzie sroga zima, a w radio twierdzono że będzie sroga zima bo Indianie zbierają chrust. Inaczej mówiąc „odruch stada”. Na pewno lepsze jest to, co mają wszyscy, bo przecież niemożliwe żeby wszyscy się mylili.
  3. Pewna modyfikacja teorii numer 1 to  „dwa grzyby w barszcz”. Gdy zmagamy się z biznesem, gdy walczymy o byt naszej firmy, to dorzucenie jeszcze do tego czegoś nieznanego i ogólnie źle widzianego przyprawia decydentów o ciarki, szczególnie że na horyzoncie pojawia się kolejna teoria.
  4. „Rolex vs casio”. Wszyscy pomyśleliby, że wdrażam Open Source dlatego, że nie stać mnie na inne oprogramowanie. Potencjalni klienci nabiorą przekonania, że moja firma ma marny standing.
  5. Oczywiście jest jeszcze teoria nr 5, zamykająca dyskusję.
    „Open Source nie nadaje się do prawdziwych biznesowych wdrożeń, bo przecież Gartner w raporcie napisał…”.

Prawda zapewne leży gdzieś po środku. Trochę strach, trochę zapatrzenie na innych, ale także niedojrzałość niektórych rozwiązań Open Source, niska popularność tychże, brak wystarczająco rozwiniętego rynku usług… To wszystko razem sprawia iż „biznesowa strona IT” wciąż z dużą rezerwą spogląda na Open Source.

Trzeba więcej śmiałków, którzy zdecydują się jako pierwsi na wdrożenia wolnego oprogramowania, wtedy na pewno obawy przez nim rozpłyną się, a rynek usług rozwinie się, bo rynek nie znosi próżni.

—

Napisane w Business Dialog Bulletin, Teksty. Tagi: , . Zostaw Komentarz »

Dlaczego Open Source?

2009/09/06 — Andrzej Góralczyk

Tekst ukazał się w Business Dialog Bulletin w maju 2007 r.

Powody, dla których użytkownicy komputerów wybierają oprogramowanie Open Source są różne, tak jak różne są ich doświadczenia i potrzeby.

Andrzej Góralczyk i Paweł Moszumański

Andrzej: W dotychczasowych dyskusjach o nowych trendach w IT zaniedbaliśmy trochę temat wzrastającej popularności oprogramowania wolnego – Open Source. Jednakże jest to trend bardzo nasilony w ostatnich miesiącach, więc warto poświęcić chwilę na podsumowanie naszych jakże różnych doświadczeń, w poszukiwaniu odpowiedzi na pytanie w jakich okolicznościach zastosowanie oprogramowania wolnego w firmie ma sens.

Spotkanie z Open Source

Andrzej: Może zacznę od swoich doświadczeń. Sześć lat temu, pamiętam, musiałem zatrzymać rozwijanie interfejsu do zasobów tzw. Ukrytego Internetu dlatego, że brak mi było technologii umożliwiającej udostępnianie danego materiału w różnych widokach i kontekstach. Dalsze rozwijanie mijało się z celem, gdyż nakład pracy ręcznej byłby zbyt wielki, niewspółmierny do efektów. Trzy lata temu znalazłem dobre technologie, wówczas jeszcze w zalążku, wśród aplikacji do zarządzania treścią (Content Management). Przejrzałem wszystko, co było dostępne i wybrałem Plone. Nie dlatego, że jest za darmo, lecz dlatego, że aplikacja okazała się najlepiej spełniać wymogi elastyczności i łatwej rozbudowy o nowe usługi oraz usability dla użytkownika końcowego. Później, gdy na rynku pojawiło się wiele podobnych aplikacji, kolejny mój przegląd znowu wygrała Plone. Miałem już wtedy sporo pozytywnych doświadczeń z ową elastycznością. Nie jestem programistą, ale mimo to mogłem dobudowywać proste usługi modyfikując nieco te standardowe oraz modyfikując nieco niektóre skrypty przetwarzające dane. Gdybym zdecydował się na oprogramowanie komercyjne, nie mógłbym tego robić sam, a każdą modyfikację musiałbym zamawiać u dostawcy, niekiedy płacić za dodatkowe licencje itp. I czekać miesiącami, uzależniony od możliwości dostawcy!

Paweł: Z Open Source zetknąłem się po raz pierwszy podczas pracy dla PBiWH Next, dla którego wykonywałem prace zlecone przy projekcie dla Polskich Portów Lotniczych. Osobą która rozbudziła we mnie zainteresowanie alternatywnymi rozwiązaniami był Dariusz Knociński, kilka lat starszy ode mnie wojskowy-informatyk. Pracował wtedy w WIMLu (Wojskowy Instytut Medycyny Lotniczej). On poznał Open Source gdy szukał alternatywnych narzędzi do obróbki statystycznej dużych ilości danych badawczych, a przez przypadek odkrył dla siebie i innych „Złotego Graala” informatyki.

To wtedy, jakieś 10 lat temu poznałem pierwsze instalacje Linuksa oraz KDE w wersji 0.1, QT dłuuuugo przed wersją Alfa. Część z doświadczeń Darka znalazła później zastosowanie w produktach opartych na Linuksie a służących na lotniskach naszego kraju do dziś…

Co mnie urzekło w Open Source, a właściwie na początku w Linuksie, to możliwości. Potencjał, któremu nawet wyobraźnia nie była i nie jest w stanie wyznaczyć granic. Mój pierwszy serwer pocztowy, obsługujący Hotel Jan III Sobieski, to był oczywiście sendmail na Linuksie. Potem już poszło: gateway, router, firewall, wymiana serwera plików rodem z Novella na Sambę, stacje bezdyskowe, zdalne zarządzanie zasobami z jednego miejsca itd. itd. Rzeczy, które pod znanym powszechnie systemem komercyjnym były mrzonką lub bardzo drogą usługą z górnej półki, w Linuksie okazywały się na wyciągniecie ręki. Dosłownie! Wystarczy napisać polecenie apt-get install nazwa_pakietu. A tak na marginesie – kiedyś na jednej z grup dyskusyjnych zadeklarowałem, że jeśli Microsoft w MS Windows dorobi się tak prostego w użyciu mechanizmu, jak apt-get, to „odszczekam” wszystko co złego powiedziałem o zarządzaniu instalacjami w tym systemie. Minęło już chyba 7 lat i na razie nic nie wskazuje na zmiany…

Po co informatyka w firmie

Paweł: Open Source to również sztuka zrozumienia po co jest program, komputer, system…

Znam kilka osób, które tworzą wspaniale raporty w Excelu, szalenie eleganckie, kolorowe i automatyczne. Ale problem leży w tym, że zrobiły z tego sztukę dla sztuki, że już nie pamiętają jak je interpretować albo zapomnieli po co je tworzą. Domagają się najnowszej wersji programu żeby pokazać wykres bąbelkowy, którego nie robią inne programy. Tylko nikt nie spytał, czy ktoś z audytorium umie go zinterpretować.

A firma to jest zbiór drobnych zdarzeń, czynności, które pewnego dnia łączy się w procedury a potem w procesy. W ten sam sposób trzeba podejść do oprogramowania w firmie. Jest to zbiór narzędzi które powinny wspomagać użytkownika w jego codziennych czynnościach, a z drugiej strony w efektywny kosztowo sposób dać się zarządzać.

Andrzej: Jest też kwestia rozsądku w wyborze platformy sprzętowej. W przypadku mojego wydawnictwa przykładem może być dobór narzędzi do tworzenia produktów z obrazem ruchomym. To nie są bardzo wyrafinowane rzeczy, jakich np. wymagałaby telewizja, więc bez sensu byłoby strzelanie z armat w rodzaju wyspecjalizowanych stacji roboczych, takich jak Macintosh albo Silicon Graphics. Jednak nie są aż tak proste, aby podołał mu system Windows i oprogramowanie pod nim pracujące. Dlatego optimum to zwykłe komputery PC i mocne notebooki, ale pracujące pod systemem Linux, dla którego mamy całkiem duży wybór wystarczająco mocnych aplikacji Open Source do produkcji multimedialnych. Natomiast serwery na silnych maszynach mam w trzech lokalizacjach daleko od kraju. Nie wyobrażam sobie zdalnego administrowania nimi i instalowania stale rozwijanych aplikacji, gdyby były komercyjne, z zamkniętym kodem.

Paweł: Rzeczywiście, Open Source oferuje przebogate możliwości rozwiązań, ale niektóre trzeba dopiero pokazać użytkownikowi, innych nauczyć. Ja jako menadżer swoją rolę w wdrażaniu Open Source często postrzegam jak rolę ojca, który pokazuje synowi jak się golić, do czego służy pędzel i maszynka do golenia. Często użytkownicy nowych technologii twierdzą że wiedzą o nich wszystko, a umieją jedynie korzystać z nich intuicyjnie, tak jak młody chłopak z maszynki do golenia. Wiadomo przecież jak się golić… A to, że niektórzy golą się wysoko nad policzkami albo pozacinają się – cóż, mówi się wtedy że zawiniło IT, że źle przygotowane narzędzia, że nie te programy i nie te wersje…

Nie chodzi nawet o pieniądze

Paweł: Wracając do kosztów, czyli tzw. TCO (Całkowity koszt posiadania), mam taki drobny przykład. Zawsze mnie fascynowało jak się opłaca utrzymywanie w bankach stacji roboczej z MS Windows tylko po to, aby uruchamiać aplikację bankową w telnecie. Linux daje to rozwiązanie jakby z definicji.

Andrzej: To nawet nie jest kwestia ceny, bo przecież mam kilka programów zakupionych. Ale nie chcę płacić za rzeczy, których nie potrzebuję. Na przykład Excel, wraz z kosztownym Solverem jest świetny i prawie niezastąpiony w symulacjach do optymalizacji procesów. Jednak ostatnio nie widzę w sklepach samego Excela. Sprzedawany jest w pakiecie z całą resztą MS Office, której akurat nie potrzebuję, gdyż funkcjonalność OpenOffice.org bardziej mi odpowiada – jest tu mniej automatyki. Bez Excela radzę sobie z symulacjami, ale kosztuje to więcej pracy. Innym przykładem są czcionki. W moim wydawnictwie elektronicznym potrzebuję takich, które dobrze wyglądają w publikacjach czytanych na ekranie. Wybór jest bardzo niewielki, a wymagania są zupełnie inne, niż w przypadku czcionek do druku. Więc muszę przejrzeć setki krojów czcionek, aby wybrać tych kilkanaście wyświetlanych na ekranie bez błędów. Gdybym chciał wybierać spośród komercyjnych, musiałbym zapłacić za mnóstwo niepotrzebnych mi. W gruncie rzeczy jest to skutek niespójności standardów dla tych różnych mediów.

Zawsze można sobie poradzić

Paweł: Czym jest dla Mnie Open Source? Przede wszystkim to wolność wyboru, możliwość dokonywania modyfikacji i błyskawiczna diagnoza.

Przypominam sobie zdarzenie związane z obsługą serwera pocztowego. Przy dużej ilości jednoczesnych połączeń serwer po prostu „umierał”. Po kilku godzinach badań logów zdecydowałem się włączyć funkcję strace – narzędzie śledzące wywołania i sygnały systemu – i w 15 minut znana mi już była przybliżona lokalizacja błędu. Analiza kodu źródłowego pozwoliła mi po następnych 30 minutach znaleźć w nim miejsce, gdzie była ustawiona wartość (timeout) powodująca błąd. Dodam, że była wadliwa tylko dla tej konkretnej sieci, innym to nie przeszkadzało. Po następnych 20 minutach rekompilacja… i działało! Konia z rzędem temu, kto po 2 godzinach będzie miał rozwiązany podobny problem np. z „exchangem”. A możliwe to było dlatego, że miałem kod – otwarty! Tego rodzaju zdarzeń w mojej historii współpracy z Open Source jeszcze znalazłbym wiele.

Andrzej. Ja nie natrafiam na tak poważne problemy, może dlatego że nie utrzymuję wielkiego systemu. Zresztą nie umiałbym chyba poradzić sobie w podobnej sytuacji nie będąc informatykiem. Ale mniejsze awarie oczywiście zdarzają mi się i jeśli sam nie potrafię ich opanować, dostaję zdumiewająco szybko wsparcie ze strony społeczności. Na przykład raz przesadziłem, chcąc „wycisnąć” z niewielkiej aplikacji osadzonej w jednym z moich portali znacznie więcej niż to, do czego została zaprojektowana. Po prostu po dodaniu kolejnego modułu wszystko się posypało i w dodatku zupełnie nie rozumiałem logu błędów. Szybko napisałem o tym na liście dyskusyjnej i w ciągu kilku minut znalazł się „opiekun”, który w odpowiedzi pisał mi kolejne instrukcje postępowania. Najpierw jak zapanować nad serwerem, potem po kolei co mam sprawdzać i ewentualnie wyłączać. W ten sposób serwer i aplikację podniosłem w ciągu 35 minut!

Jednakże muszę dodać, że nie każdy użytkownik może liczyć w 100% na tak szybką pomoc. Ja mogę jako „swój człowiek”, gdyż wziąłem udział w kilku projektach Open Source, przy rozwijaniu dwóch aplikacji Wiki, CMS-u i aplikacji do e-learningu. Zresztą dzisiaj już nie zdarza mi się „zajeżdżać” systemu, mam więcej doświadczenia.

Potencjał i zasięg

Andrzej: Dla kompletnego obrazu muszę dodać, że wsparcie mam zarówno ze społeczności, jak i od komercyjnego dostawcy – firmy doświadczonej w wielkich projektach Open Source, m. in. dla agend europejskich. Jest ona także dostawcą rozwiązań Open Source dla sektora obronnego i kosmicznego, a ich niezawodność i bezpieczeństwo ma najwyższą ocenę amerykańskich służb specjalnych. Dla mnie ta pomoc jest nieoceniona, ponieważ sam nie jestem w stanie zrobić rzeczy bardziej zaawansowanych, takich jak złożona wielowarstwowa konfiguracja. A oni reagują na moje pytania i prośby w niespełna godzinę!

Paweł: Bo też potencjał intelektualny i techniczny zaangażowany w wolne oprogramowanie jest niesamowity. Na co dzień dostrzegamy tylko dominację rozwiązań Open Source w Internecie, detronizację komercyjnych przeglądarek, zwłaszcza Inetrnet Explorera przez Firefoxa i Operę oraz rywalizację Linuksa z innymi serwerami. Rzadziej uświadamiamy sobie, że samo tylko oprogramowanie na klasycznych „wolnych” licencjach typu GPL (General Public License) jest wspierane przez dziesiątki największych firm software’owych na świecie, w tym IBM, Google, Adobe, Intel, Sun, Novell, Hitachi itd. Ich listę można obejrzeć pod adresem http://www.linux-foundation.org/en/Members.

Dodajmy do tego konsorcja firm i organizacji rozwijających i promujących otwarte standardy w sektorze publicznym. Na przykład standard Otwartego Dokumentu (Open Document), a także rozwiązania dla archiwizacji, digitalizacji i ochrony archiwów cyfrowych. Dodajmy oprogramowanie rozwijane pod egidą ONZ, z myślą o krajach rozwijających się i o likwidowaniu tzw. digital divide. Wreszcie wielkie ośrodki badawcze takich uniwersytetów jak Stanford czy Massachusetts Institute of Technology w USA albo CERN i kilkadziesiąt uniwersytetów w Europie. To jest jakby drugi kraniec systemów informatycznych, przeznaczonych do superkomputerów i najbardziej wymagających zadań. Nie widzimy tego na co dzień, ale wiele rozwiązań opracowanych w tych ośrodkach trafia do nas w postaci „medialnej” jak np. odczytany (i publicznie dostępny!) kod genetyczny złożony z kilku miliardów nukleotydów, bądź w postaci „konsumpcyjnej” np. jako super-wyszukiwarka Google. Do przedsiębiorstw też trafia, np. w postaci oprogramowania do symulacji, projektowania w 3 wymiarach bądź przetwarzania rozproszonego. Żadna firma komercyjna nie byłaby w stanie „uciągnąć” tak wielkich przedsięwzięć. Właśnie ta niesamowita potęga stale rozpala mi wyobraźnię.

—

Napisane w Business Dialog Bulletin, Teksty. Tagi: , . Zostaw Komentarz »

Ewolucja metod tworzenia opisu procesowego organizacji

2009/09/06 — Andrzej Góralczyk

Artykuł ukazał się w Business Dialog Bulletin w kwietniu 2007 r.

Pojęcie procesu biznesowego na dobre zadomowiło się w biznesowej rzeczywistości i nikogo nie dziwią inicjatywy, często bardzo kosztowne, mające na celu opisanie czy usprawnianie procesów biznesowych. Niestety, wraz z popularyzacją podejścia procesowego do zarządzania organizacją, pojęcie procesu biznesowego uległo rozmyciu.

Artur Kasprzyk

Procesem biznesowym nazywa się całe obszary funkcjonowania organizacji, takie jak marketing czy sprzedaż, procesem biznesowym jest zarazem dużo mniejszy obszar działania, taki jak obsługa zamówienia; równie często procesem biznesowym nazywa się opis działań realizowanych przez narzędzia informatyczne klasy BPMS. Z drugiej strony opis procesów biznesowych jest najczęściej wykonywany na poziomie „ogólnej” koncepcji działania, bardzo często z łamaniem zasad języka wykorzystywanego do utworzenia opisu. Z przykrością należy stwierdzić, iż w dużym stopniu do takiego stanu rzeczy przyczyniają się projekty związane z pozyskaniem normy ISO, w ramach których firmy audytorskie akceptują niepoprawne opisy, sankcjonując tym samym brak precyzji i niejednoznaczność. Na skutek tego  rodzi się przekonanie, iż opis procesów służy głównie pozyskaniu normy ISO oraz jakiejś wąskiej grupie ludzi, która jest za nie odpowiedzialna. Podawana jest także w wątpliwość sama idea procesowości, poprzez podniesienie prostych, ale jakże trafnych argumentów w stylu „skoro tak prosto działamy, jak nam tutaj zaprezentowano, to skąd się bierze tylu sprinterów w garniturach na korytarzach firmy?”. Codzienne życie organizacji jest niewrażliwe na wyniki certyfikacji.

Splot tych czynników powoduje, iż z uruchamianych projektów wdrażania podejścia procesowego do zarządzania organizacją niewiele kończy się sukcesem biznesowym.

Niniejszy artykuł ma na celu zaprezentowanie obecnego stanu adaptacji podejścia procesowego i zagrożeń, jakie przy tym występują oraz wskazanie tych kierunków jego rozwoju, które stwarzają nadzieję na osiągnięcie większych korzyści z  inwestycji w projekty wdrażania procesowych metod zarządzania. Z uwagi na objętość materiału, w artykule nie zostanie zaprezentowane powiązanie pomiędzy mapami strategii a modelem procesowym organizacji.

Obecny etap adaptacji podejścia procesowego

Z punktu widzenia dostępnych technik opisu procesów wydaje się, iż w Polsce1 większość projektów jest realizowana z wykorzystaniem podejścia opartego na karcie przepływu procesu (flowchart), popularnego na rynku od kilkudziesięciu lat. Omawianą technikę opisu można z powodzeniem stosować w wielu obszarach funkcjonowania organizacji, w których „liniowość” jest naturalną cechą prowadzonych działań. Typowymi przykładami są liniowe procesy produkcyjne, procesy administracyjne czy też procesy w organizacjach podlegających ścisłym rygorom prawnym (np. w bankach). Zgodnie z tym podejściem w dalszych fazach wdrażania zmian w organizacji procesy są uzupełniane procedurami postępowania uwzględniającymi reguły biznesowe zidentyfikowane podczas opisu. Podstawowym ograniczeniem tego podejścia jest konieczność opisania wszystkich dozwolonych sekwencji działań oraz zbyt skromne możliwości reprezentacji działań uruchamianych współbieżnie (w tym także innych procesów) w zależności od stanu realizacji danego procesu. Słabości te czynią metodę mało użyteczną w sytuacjach, w których nie sposób przewidzieć wszystkich możliwych konfiguracji działań. Typowa sytuacja tego rodzaju to działania sprzedażowe, w trakcie których kolejne czynności są na bieżąco wybierane – spośród  określonego dozwolonego zbioru – na podstawie stanu realizacji negocjacji handlowych.

Przykładem języka modelowania omawianego typu jest mocno już okrzepła i popularna metoda Rummlera-Brache’a. Inny przykład to notacje konstruowane ad hoc na potrzeby poszczególnych projektów w oparciu o podstawowe symbole przepływu pracy dostępne w popularnym pakiecie Visio.

W praktyce opis oparty na flowchart okazuje się często zbyt uproszczony, nie odzwierciedla złożoności i różnorodności współczesnych procesów biznesowych. Trudno jest na podstawie takiego opisu sformułować specyfikację oczekiwanego wsparcia działań organizacji technologiami informatycznymi – zestawy wymagań są bądź zbyt ogólne, by mogły stanowić podstawę do świadomego ich zatwierdzenia, bądź zawierają zbyt wielką mnogość oczekiwań, znacznie ponad rzeczywiste zapotrzebowanie. W efekcie może to prowadzić do budowy lub zakupu systemów, z których spora część funkcjonalności będzie niewykorzystana, a brakować będzie kluczowych funkcjonalności, które nie zostały zidentyfikowane z powodu zbyt ogólnego opisu zasad działania organizacji.

Informatyka skupia swoje zainteresowanie na procesach biznesowych gdyż potrzebuje precyzyjnych i kompletnych specyfikacji wymagań biznesu wobec narzędzi, które biznesowi udostępnia – narzędzi wspomagających zarządzanie procesami poprzez integrowanie działania systemów informatycznych oraz działania pracowników w ramach jednego wspólnego środowiska pracy. O wpływie tychże narzędzi na model procesowy organizacji traktuje następny rozdział.

BPMS

Wraz z falą fascynacji architekturą zorientowaną na usługi (Service Oriented Architecture, SOA) rośnie zainteresowanie tzw. systemami zarządzania procesami biznesowymi, określanymi akronimem BPMS. Są to systemy informatyczne, których zadaniem jest definiowanie procesów biznesowych oraz umożliwienie ich późniejszego nadzoru. Lecz dla potrzeb systemu informatycznego procesy muszą być opisane w sposób jednoznaczny i dokładnie odpowiadać rzeczywistości. Zestawienie tego wymogu z dotychczasową praktyką zarządzania, dopuszczającą pewien margines dowolności (jak w przypadku opisanej wyżej metodologii wykorzystującej flowcharts) rodzi zasadniczą wątpliwość. Z jednej bowiem strony narzucenie ścisłych wymogów formalnych na opis procesu daje spore szanse na usprawnienie pracy, ale z drugiej strony spore zagrożenie jej paraliżu, a co najmniej odczuwalnych niedogodności. Moim zdaniem jedynym powodem tej kontrowersji jest stale jeszcze otwarte pytanie o możliwość oddania rzeczywistości przy pomocy dostępnego języka modelowania.

Zakładając umiejętność precyzyjnego modelowania, o tym, czy ostatecznie projekt zaowocuje sukcesem czy porażką w dużej mierze zadecyduje, czy przyjęty przez narzędzie paradygmat modelowania umożliwia odzwierciedlenie rzeczywistości. Jeżeli modelujemy przy pomocy np. coraz popularniejszego języka BPMN, wówczas jesteśmy w stanie perfekcyjnie oddać wszystkie wariancje w ramach procesów przemysłowych. Aczkolwiek, istnieje ryzyko pojawienia się problemów, jeśli naszym zadaniem będzie wsparcie narzędziami do zarządzania procesami działów sprzedaży czy marketingu. Przed jeszcze trudniejszym zadaniem staniemy w przypadku firm produkujących oprogramowanie, w których jedne procesy są definiowane ad hoc w ramach realizacji innych procesów.

Rozwiązania komplementarne

W sukurs obecnym już na rynku metodom modelowania i zarządzania procesami przychodzą nowe podejścia, uzupełniające dotychczas stosowane techniki i narzędzia. Część z nich już została uznana na rynkach bardziej dojrzałych i chętniej adaptujących nowe trendy, część z nich dopiero zaczyna „nabierać rumieńców”.

Jedną z technik modelowania struktur procesowych, pozwalającą uczynić z monolitycznych konstrukcji swobodnie powiązane fragmenty działań, jest Event-Driven Architecture (EDA). Według tej koncepcji, której stosowanie jest niesłusznie zawężane jedynie do rozwiązywania problemów informatycznych, opisywany organizm (bez względu na to, czy jest to proces biznesowy, czy też działanie wewnątrz infrastruktury IT, np. opartej na SOA) składa się z wielu autonomicznych składowych, komunikujących się wzajemnie w sposób asynchroniczny poprzez wysyłanie i odbieranie zdarzeń. Koncepcja taka zbliża zdecydowanie tworzony model procesów biznesowych do realiów funkcjonowania organizacji, w której jedne działania (np. obsługa zgłoszenia reklamacyjnego) komunikują się z innymi obszarami funkcjonowania organizacji (np. obsługa usterki) poprzez przesłanie komunikatów (np. e-mail). Organizacja jest wówczas postrzegana jako zestaw „uruchomionych” drobnoziarnistych działań, które w odpowiednich momentach wysyłają do organizacyjnego uniwersum sygnały o osiągnięciu określonego stanu, w efekcie czego może dojść do uruchomienia, zakończenia czy też wybudzenia innych działań. Oczywiście, można zarzucić pomysłowi, iż miast wielkich bloków działań („na których wszystko widać”), uzyskujemy dużo większą liczbę działań drobniejszych, powiązanych wzajemnie pajęczyną niejawnych zależności. Ale czy nie tak wyglądają nasze organizacje?

Innym kierunkiem rozwoju podejścia procesowego jest koncepcja zarządzania sprawami (case management, case handling), według której w ramach obsługi sprawy (instancji procesu), zespół przypisany do jego realizacji współdzieli informacje powstające w ramach obsługi tej sprawy, a działania (ciągi akcji) są podejmowane w momencie, gdy spełnione są wymagane do tego warunki (np. informacja opisująca osiągnęła określony stan). Osoba pracująca nad sprawą decyduje (a nie „wnioskuje” z przygotowanego wcześniej opisu) o kolejnym działaniu, jakie ma zostać wykonane. W przeciwieństwie do wcześniej wymienionych technik, podejście zakłada, iż w ramach obsługi sprawy mogą się pojawić dane (dokumenty itp.), których nie przewidziano w opisie procesu (w „tradycyjnym” podejściu procesowym projektant procesu określa jakie dane będą przetwarzane). Przykładem obszarów zastosowań tego typu podejść mogą być sprawy sądowe, czy zgłoszenia szkód w firmach ubezpieczeniowych.

Kolejne podejście, nazywane zarządzaniem ludzkimi interakcjami (human interaction management, HIM) uwzględnia jeszcze większą „nieprzewidywalność” działań w ramach opisu procesów. Zgodnie z teorią HIM, ludzie wykonujący pracę umysłową pracują według określonych wzorców postępowania. Przez większą część czasu wykonywana praca, mogąca trwać tygodnie, miesiące czy lata, może nie przynosić wymiernych efektów, jakich oczekuje się od procesu, co nie oznacza, iż proces nie jest realizowany. Podejście zakłada bowiem, iż kluczową rzeczą – z punktu widzenia procesów opierających się na pracy umysłowej – jest zdefiniowanie interakcji pomiędzy rolami (rozumianymi w znaczeniu zdefiniowanym w technice RAD2) biorącymi udział w realizacji procesów oraz wskazanie warunków wejściowych pozwalających na uruchomienie danego działania i wyjściowych pozwalających uznać je za zakończone. Przy takim podejściu, realizowany proces jest postrzegany jako zbiór wykonywanych „atomowych” działań, a każda z ról biorących udział w procesie postrzega go jako zestaw działań, które powinna w danym momencie wykonywać. Kolejną, cechą charakterystyczną dla omawianego podejścia jest założenie, iż w ramach ról biorących udział w realizacji konkretnego procesu istnieje wystarczająca kompetencja oraz organizacyjne umocowanie, by móc zredefiniować proces w trakcie jego wykonywania (można uznać, iż początkowo każda instancja procesu jest uruchamiana zgodnie z ustalonym wzorcem, ale w toku realizacji prac kształt instancji procesu może ulec zmianie). Przykładem tego typu procesów są działania związane z opracowywaniem kampanii marketingowej czy budową systemów informatycznych, w których ciężko a priori przewidzieć działania, które będą wykonywane w celu doprowadzenia  przedsięwzięcia do końca.

Podsumowanie

Obserwacja działań podejmowanych w naszym kraju w obszarze modelowania procesów biznesowych nie napawa optymizmem. Spośród sporej liczby projektów, które mieliśmy okazję audytować, czy po prostu przyglądać się im, duża część (50-60%) była realizowana bez jasnego i przemyślanego pomysłu, nie mówiąc już o systematycznej metodyce. To przeraża. Szczególnie niedobrze jest w projektach, w których modele procesów biznesowych tworzone są  przez zespoły pracujące nad wdrożeniem rozwiązania informatycznego. Pomijając ewentualny wpływ kwestii etycznych (konflikt interesów: albo poprawnie albo tak, aby model procesów pasował do systemu, który akurat mamy), w wielu przypadkach powodem takiego stanu rzeczy jest najzwyczajniej w świecie brak odpowiednich kompetencji w zespole realizującym projekt. Na to nakłada się bardzo często brak wystarczającej wiedzy o sposobach modelowania procesów oraz o korzyściach z tego płynących po stronie zamawiającej. W efekcie powstają modele procesów, których nikt nie czyta, do których nikt się nie stosuje i których nikt nie utrzymuje. Opisy procesów na potrzeby norm ISO, które pracownicy „wkuwają” na dzień przed wizytą audytora, by dzień później o nich zapomnieć. Opisy procesów rozpoczęte na początku uruchomienia projektu wdrożenia systemu informatycznego i porzucone gdzieś w trakcie ich realizacji, gdyż „nie było już czasu”. I co gorsza, ogólne przekonanie, iż modelowanie procesów niewiele jest warte, bo nie ma z tego żadnych biznesowych korzyści, a za to całe mnóstwo problemów.

No ale czemu się dziwić? Żyjemy w kraju, w którym występuje chyba ewenement w skali światowej – wykładowcy na konferencjach „branżowych” muszą zapłacić za możliwość wystąpienia! Skoro tak się sprawa ma, to inwestycja musi się zwrócić. Toteż uczestniczymy w imprezie bardziej propagandowej niż merytorycznej i otrzymujemy taką wiedzę, na otrzymanie jakiej zgodziliśmy się. Kolejna obserwacja – z jakiś nieznanych powodów, jesteśmy bardzo wrażliwi na brak wdrożeń referencyjnych w Polsce. Bardzo często oceniając dojrzałość rozwiązań nie ufamy temu, iż na świecie od lat pracuje się jakimiś metodami, czy wykorzystuje określone narzędzia. A przecież dość oczywistym jest fakt, iż w gospodarkach znajdujących się na wyższym poziomie rozwoju, w których dysponuje się większymi budżetami, ale też i konkurencja jest ostrzejsza, szybciej próbuje się adaptować nowe technologie. Czekamy na sukcesy krajowych wdrożeń owych sprawdzonych już na świecie podejść i narzędzi, a tymczasem świat ucieka nam do przodu. Na własne życzenie czekamy, aż ktoś nas wyprzedzi.

Sprawdzajmy więc to, co jest dostępne w ramach szeroko pojętego podejścia procesowego. Dostępne na świecie, a nie tylko w okolicznych województwach. Oceniajmy dostępne rozwiązania i nie bójmy się eksperymentować; wybierajmy konferencje, które nie noszą znamion wydarzenia marketingowego (często marka organizatora wskazuje na charakter konferencji); czytajmy uznaną literaturę branżową i na niej starajmy się wyrabiać swoją opinię. Przy takim podejściu do wdrażania nowych myśli i technologii mamy szansę na rzeczywiste usprawnienia i czerpanie garściami korzyści, jakie daje dobrze wdrożony pomysł. A mamy z czego wybierać, co starałem się pokazać powyżej.

—

Napisane w Business Dialog Bulletin, Teksty. Tagi: , , , , . 1 komentarz »

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

2009/09/05 — Andrzej Góralczyk

Ł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

——–

Napisane w Teksty, Łasiczka z damą. Tagi: , , , , , , , , , , , , , . Zostaw Komentarz »

Mózg łańcucha dostaw

2009/09/05 — Andrzej Góralczyk

W zarządzaniu łańcuchem dostaw chodzi o to, by idealnie zgrać elementy po stronie podażowej (zaopatrzenie, planowanie produkcji i dystrybucji, alokacja mocy produkcyjnych, planowanie zapasów itp.) z tymi po stronie popytowej (napływające zamówienia i prognozy), tak, by podołać całemu popytowi przy możliwie najniższych kosztach.

Autor jest uznanym autorytetem w dziedzinie technik planowania i zarządzania produkcją i naprawdę wie, co mówi. Dlatego zdecydowałem się opublikować ten artykuł w całości mimo, że miejscami tekst brzmi dla mnie nazbyt marketingowo. Andrzej G.

Mózg łańcucha dostaw

Ashfaque Ahmed

  • 1. Nadrzędny cel zarządzania łańcuchem dostaw w biznesie
  • 2. Na czym polega APO?
  • 3. Technologia niezbędna w APO

Jaki jest nadrzędny cel zarządzania łańcuchem dostaw w biznesie?

Chodzi w nim o to, by idealnie zgrać elementy po stronie podażowej (zaopatrzenie, planowanie produkcji i dystrybucji, alokacja mocy produkcyjnych, planowanie zapasów itp.) z tymi po stronie popytowej (napływające zamówienia i prognozy), tak, by podołać całemu popytowi przy możliwie najniższych kosztach.

Czy dzisiejsze systemy planowania zasobów przedsiębiorstwa (ERP), zarządzania łańcuchem dostaw (SCM) czy relacjami z klientami (CRM) nadają się do tak wszechobejmującego zadania? Bynajmniej! Gdzie więc powinniśmy szukać rozwiązania?

Przyjrzyjmy się nieco bliżej problemowi. Tradycyjne systemy ERP pomagają w działalności biznesowej, w tym także w obszarze łańcucha dostaw, w dużej mierze dzięki ogromnej liczbie punktów zbierania informacji. Są to jednak rozwiązania pozbawione funkcji planowania pozwalających zaspokajać popyt i minimalizować koszty poprzez działania po stronie podażowej. Specjalistyczne systemy SCM natomiast (czyli te, które mają ambicje różnić od komponentu SCM w tradycyjnych systemach CRM) co prawda starają się ściślej powiązać działania po obu stronach ― podażowej i popytowej ― jednak im z kolei brakuje bądź to inteligencji, bądź to elastyczności niezbędnej do połapania się w kolosalnej masie informacji, działań i innych czynników składających się na wielki biznes dnia dzisiejszego. Systemy CRM to tylko jedna strona medalu, obsługują bowiem wyłącznie popytową stronę działalności biznesowej i nie są przydatne w zestawianiu jej ze stroną podażową w sposób kosztowo efektywny. Na szczęście istnieje narzędzie, które znakomicie potrafi spinać obie te strony biznesu, a przynajmniej nadaje się do realizacji tego ważnego zadania. Narzędzie to bywa nazywane różnie. Jedni mówią o „planowaniu wyprzedzającym”, inni o „optymalizacji łańcucha dostaw”, jeszcze inni o „harmonogramowaniu z góry”. Jak go zwał, tak go zwał, ważne, że wielu dostawców oprogramowania stara się tworzyć rozwiązania pomagające równoważyć popyt z podażą. Niektórzy mają tu już pewne osiągnięcia, inni wciąż jeszcze kombinują, jak by tu uporać się z tym problemem. Na użytek tego artykułu nazwijmy sobie omawiane tu narzędzie „zaawansowanym planowaniem i optymalizacją”, w skrócie APO (od angielskiego Advanced Planning and Optimization). APO ma służyć przedsiębiorstwom do dostosowania wszystkich swoich poczynań do wymagań klientów.

Narzędzie optymalizacyjne niesie z sobą szereg korzyści. Mówi przedsiębiorstwom, jak i kiedy realizować zamówienia oraz trzymać się prognoz w celu maksymalizacji wydajności. Przydaje przedsiębiorstwu elastyczności i pozwala wycisnąć, ile się da z zasobów materialnych. W ostatecznym rozrachunku optymalizacja prowadzi do ogromnych oszczędności w kosztach operacyjnych, a przy okazji poprawia jakość obsługi klienta i potrafi zapobiec brakom w zapasach. To właśnie z takich powodów APO stanowi potężne narzędzie w każdym przedsiębiorstwie.

Na tym jednak nie koniec zalet APO. Narzędzie to pozwala również:

1) skracać cykle harmonogramowe

2) zmniejszać poziomy zapasów

3) przyspieszać obroty magazynowe

4) poprawiać elastyczność w kontaktach z klientami (większe możliwości korekt zamówień)

5) działać z większą elastycznością przy opracowywaniu tańszych alternatyw oferowanych produktów

Zasady działania APO

Pierwszym krokiem w działaniu APO jest analiza zamówień i prognoz, a następnie wyłowienie i zestawienie tych, które są do siebie podobne. W razie potrzeby APO rozbija poszczególne zamówienia i potrzeby na ich elementy składowe, po czym ponownie identyfikuje i zestawia elementy podobne. Zestawione zamówienia, prognozy bądź składowe tychże są następnie scalane na potrzeby planowania produkcji czy dystrybucji, bądź też innego rodzaju planowania działalności biznesowej. APO określa ograniczenia w produkcji, dystrybucji i innych sferach, a także pokazuje moce przerobowe i dostępne zasoby. Określa także wyprzedzenia w planowaniu, priorytety w realizacji zamówień oraz inne czynniki warunkujące pomyślną realizację zadań.

Po określeniu ograniczeń, priorytetów, mocy przerobowych i innych czynników po stronie podażowej, system przygląda się zestawionym wcześniej zamówieniom i prognozom, po czym podsuwa najbardziej odpowiedni plan produkcji, dystrybucji i innych działań. Plan ten może przewidywać scalanie jednakowych zadań produkcyjnych, gdy różne wyroby wymagają tych samych operacji na produkcji. W takich przypadkach całość tych operacji, dotyczących wielu wyrobów, obejmuje się pojedynczym zamówieniem produkcyjnym. Dane z planu wygenerowanego przez APO przekazywane są następnie do odpowiednich systemów zarządzania produkcją, dystrybucją, magazynami, zapasami itp. Mówiąc obrazowo, wszystkie te systemy odpowiadają za poszczególne działania przedsiębiorstwa, zaś narzędzie optymalizujące pełni rolę mózgu zawiadującego całością działań w obrębie łańcucha dostaw.

Technologiczne zaplecze APO

Większość narzędzi optymalizacyjnych wykorzystuje constraint-based programming, genetic algorithm-based computing, programowanie liniowe, Taabu Search itp. Ciekawostką jest fakt, że większość wiodących dostawców systemów ERP i SCM korzysta przy tworzeniu funkcji optymalizowania w swoich rozwiązaniach z algorytmu opracowanego przez jedną i tę samą firmę.

Programowanie liniowe wystarcza w przypadku mniej rozległych i skomplikowanych zadań, nie sprawdza się jednak w sytuacjach bardziej złożonych, bowiem wraz ze wzrostem złożoności problemu liczba wymaganych obliczeń rośnie w postępie geometrycznym. W takich przypadkach najlepiej sprawdza się genetic algorithm-based computing. Użytkownik tej techniki nie musi tworzyć żadnych reguł, by wykonać potrzebne mu obliczenia. W porównaniu z innymi, technika ta wymaga mniejszej liczby obliczeń przy wykonywaniu poszczególnych operacji. Wreszcie, genetic algorithm-based computing jest techniką przejrzystą dla użytkownika, jako że nie wymaga od niego żadnego „wsadu” i sprawuje się dobrze w sytuacjach o wysokim stopniu złożoności. Nieprzypadkowo więc narzędzia optymalizacyjne wykorzystujące genetic algorithm-based computing wyróżniają się na korzyść wśród innych rozwiązań tego typu.

Wnioski

Ogromny potencjał narzędzia zaawansowanego planowania i optymalizacji pozwala przedsiębiorstwom osiągać potężne oszczędności za sprawą optymalizacji swoich procesów biznesowych. Oszczędności te mogą osiągać poziom nawet 200%, a w większości przypadków można oczekiwać wyniku w granicach co najmniej 50–60%. Już tylko z tego powodu należy uznać inwestycję w APO za propozycję wielce atrakcyjną. A jeśli wziąć pod uwagę pozostałe korzyści wskazane wyżej, a także to, że APO sprawdza się równie dobrze w dziedzinie produkcji procesowej, jak i dyskretnej, to narzędzie to zaczyna się jawić jako propozycja wręcz nie do odrzucenia.

Tłumaczenie Andrzej Lewandowski

Nota o autorze. Ashfaque Ahmed jest konsultantem w dziedzinie zaawansowanego planowania i technik optymalizacji w obszarach produkcji i dystrybucji. Odbiorcami jego usług są małe i średnie organizacje branż spożywczej, farmaceutycznej, opakowań, papierniczej, metalurgicznej, pakowanych towarów konsumpcyjnych i części samochodowych. Jest współzałożycielem spółki GoldenEmbryo Technologies (www.goldenembryo.net) oferującej programy do zarządzania łańcuchem dostaw oraz związane z nimi usługi consultingowe i wdrożeniowe.

—

Napisane w Teksty, Zarządzanie. Tagi: , , , , , , . Zostaw Komentarz »

Dynamiczne zarządzanie procesami biznesowymi – przesłanki koncepcji

2009/09/05 — Andrzej Góralczyk

Kluczem do sukcesu współczesnego przedsiębiorstwa staje się nie „optymalny proces biznesowy”, ale umiejętność dynamicznego kształtowania procesów biznesowych zgodnie z wymaganiami klienta.

Marek Szelągowski

Druga część niniejszego opracowania została opublikowana w tym samym dziale.

Szybkość zmian zachodzących w otoczeniu biznesu, ale także ich jakościowy charakter i nieprzewidywalność powodują, że nie są już wystarczające podstawowe zasady zarządzania oparte na specjalizacji ludzi i komórek organizacyjnych oraz na odgórnym lub ręcznym zarządzaniu [Po5]. Współczesne zarządzanie stanęło bowiem przed problemem: co zrobić, aby lepiej od konkurencji – szybciej i taniej – sprostać indywidualizacji potrzeb klientów, w warunkach zmiennych i w znacznej części nieprzewidywalnych? W głównym nurcie poszukiwań właściwiej odpowiedzi znajdują się rozwiązania wykorzystujące cały dynamizm, całą wiedzę i potencjał ludzki istniejący w przedsiębiorstwie. Cechy takiego nowego ładu organizacyjnego nie są jeszcze dokładnie znane, wiadomo jednak generalnie, że organizacje nowego typu będą “odchudzone”, o płaskiej strukturze, w większym stopniu oparte na pracy zespołów, elastyczne poprzez delegację uprawnień dla pracowników liniowych, nieustannie adaptujące swoje działanie do potrzeb i wymagań klientów.

W artykule zamierzam wykazać, że szanse powodzenia mają tylko koncepcje takiego przedsiębiorstwa, w którym zmiany organizacyjne czy rewolucje technologiczne są podporządkowane wykorzystaniu i rozwijaniu kapitału wiedzy istniejącego w przedsiębiorstwie. Najpierw postaram się opisać na czym polega odpowiedź na indywidualizację wymagań klienta w małej rodzinnej firmie, która akurat ten problem rozwiązuje z powodzeniem, chociaż nie osiąga szybkości procesu głównego ani oszczędności kosztów typowych dla przedsiębiorstwa dużego. Następnie spróbuję scharakteryzować główne bariery stojące na przeszkodzie elastyczności w przedsiębiorstwie dużym i zarządzanym konwencjonalnie. W dalszej części artykułu zarysuję koncepcję zarządzania w oparciu o dynamiczne procesy biznesowe, która w moim przekonaniu stanowi jedno z możliwych trafnych rozwiązań problemu indywidualizacji w dużym przedsiębiorstwie, zachowując zarazem wszystkie plusy wynikające ze skali działania i rozmiaru zasobów.

Jak funkcjonują małe, rodzinne firmy?

Problemów z adaptacją do zmieniających się coraz szybciej wymagań klienta oraz do ich coraz wyraźniejszej indywidualizacji nie mają małe, rodzinne firmy. Panuje w nich kultura pracy i odpowiedzialności podporządkowanej klientowi, z naturalną indywidualizacją działania dla znanego, konkretnego klienta. Indywidualizacja wymagań klientów, której nie może sprostać zdecydowana większość dużych firm, jest dla małych, często rodzinnych przedsiębiorstw od zawsze naturalna. Np. mały zakład krawiecki szyje każdy garnitur dokładnie na wymiar klienta, czego nie potrafi żaden z wielkich, globalnych kreatorów mody. Podobnie prywatny korepetytor dostosowuje szybkość i sposób nauki do możliwości każdego ucznia, czego nie potrafią żadne gminne szkoły zbiorcze, ani prywatne ani państwowe. Jeżeli jakieś indywidualne wymagania czy problemy tego wymagają, tworzony jest indywidualny plan nauki – proces jest dynamicznie dostosowywany do oczekiwań i możliwości klienta.

Przykład działania małego przedsiębiorstwa

Prześledzimy jak się to dzieje opierając się na przykładzie procesu, w którym mały zakład krawiecki realizuje zamówienie od indywidualnego klienta:

Proces „Pozyskania kontraktu”.
Krawiec musi umieć dowiedzieć się od klienta jakie są jego oczekiwania. Z oczywistych powodów ich przewidzenie nie jest możliwe. Czasami klient ma konkretne oczekiwania – zakupiony przez siebie materiał, czasem gotową formę albo przynajmniej fotografię oczekiwanego garnituru. Jednak zdecydowanie częściej jest to wiedza ukryta, której klient sam nie potrafi sformułować („garnitur ma być ładny”, tzn jaki?). Zadaniem wykonawcy jest więc przede wszystkim wydobycie, zweryfikowanie i potwierdzenie oczekiwań klienta. Wydobycie tej wiedzy jest możliwe tylko wtedy, gdy dostawca jest profesjonalistą, który wie o co i w jakiej kolejności pytać. Poszukując analogii z procesami znanymi gdzie indziej można powiedzieć, że potwierdzenie oczekiwań klienta jest odpowiednikiem sakramentalnego „ostatecznego potwierdzenia” w systemach internetowych. Zapisanie, obok wymiarów klienta, informacji o rodzaju klap w marynarce i o mankietach nogawek można uznać za odpowiednik kodyfikacji wiedzy ukrytej klienta i dzielenia się nią w dużych korporacjach.
Proces „Przygotowania produkcji”
często wiąże się z innowacyjnym wykorzystaniem posiadanej wiedzy fachowej. Takim wyszukaniem i dobraniem materiału, wykończeń, a nawet technologii łączenia materiałów (np. klejenia), aby spełnić oczekiwania klienta. Często angażowani są w ten proces nie tylko pracownicy zakładu, ale także zaprzyjaźnieni dostawcy, inne zakłady, a współcześnie także fachowcy „spotkani” w Internecie.
Proces „Produkcji”
zazwyczaj wymaga dostosowania do oczekiwań klienta przebiegu standardowego procesu realizacyjnego. W małej pracowni krawieckiej od złożoności zamówienia, ale także od terminu czy figury klienta, zależy sposób krojenia materiału (tzw. rozkrój), ilość przymiarek, dobór dodatków i sposób wykończenia. W przeciwieństwie do garniturów z wielkich standardowych kolekcji, w garniturze szytym przez krawca na indywidualne zamówienie, można np. ukryć nierówność ramion klienta. Mimo, że standardowy proces jest taki sam, różnice w szczegółach wynikające z uwzględnienia oczekiwań i możliwości klienta mogą być ogromne. Mimo braku formalnych procedur i modeli procesów (a może dlatego że ich nie ma?) każdy krawiec w małym zakładzie, może i potrafi dostosować swoją prace do wymagań konkretnego zamówienia. W sposób naturalny jest on odpowiedzialny za powierzony materiał oraz za sukces całego przedsięwzięcia. Równocześnie akceptuje nadzór, a w przypadku trudności prosi o wsparcie starszego pracownika czy też właściciela. W małych firmach jest niewyobrażalne, aby w odpowiedzi na taką prośbę, współpracownik czy właściciel odmówili przekazania swojej wiedzy lub wsparcia w dotarciu do potrzebnej wiedzy.
Proces „Obsługi gwarancyjnej”
jest całkowicie dostosowany do wymagań klienta i do nieprzewidywalnych zdarzeń losowych (np. rozdarcia, utraty guzików, …). Poza wynikiem finansowym, jedynym kryterium jego oceny jest podtrzymanie dobrych relacji w celu zbudowania lojalności klienta, która może znaleźć wyraz w następnym zamówieniu lub poleceniu usług kolejnym osobom.

W małej firmie wykonawca procesu (szewc, krawiec, szef małej budowy, …) widzi cały proces. Klient nie jest tak oddalony, ani anonimowy jak to zazwyczaj ma miejsce w dużym przedsiębiorstwie. Dzięki temu możliwa jest natychmiastowa, prosta weryfikacja wykonywanego procesu z oczekiwaniami klienta. Dlatego Business Process Reengineering w małych firmach nie jest potrzebny. One już są elastyczne i na bieżąco adaptują swoje procesy do wymagań klientów. Osoba lub mały zespół obsługujący klienta (wykonawcy procesu), bez ociężałości decyzyjnej wielkiej hierarchii organizacyjnej, zawsze pozyskiwały i wykorzystywały wiedzę w ramach procesów nakierowanych na indywidualnego klienta. W sposób naturalny rozwiązania sprawdzające się u jednego klienta są w małych firmach proponowane i weryfikowane oraz ulepszane w kontakcie z innymi klientami. Nie wymaga to oceny zarządów czy audytów przez sztaby doradców, bo najbardziej obiektywnym weryfikatorem jest sam klient! Nie wymaga to poprawiania i zatwierdzania zmian obowiązujących procedur, bo małe firmy funkcjonują dzięki operatywności i odpowiedzialności swoich pracowników, a nie dzięki certyfikowanym systemom. Powtórzmy to jeszcze raz: małe firmy istnieją i rozwijają się dzięki profesjonalizmowi i odpowiedzialności pracowników, dzięki umożliwieniu im samodzielnego działania i dzięki kulturze dzielenia się wiedzą.

Podstawowe problemy dużych organizacji

W przypadku małych firm, takich jak zakład krawiecki z powyższego przykładu, trudno mówić o jakichś formalnych procedurach czy systemach zarządzania wiedzą, dzięki którym wiedza zweryfikowana w kontakcie z klientem wraca do wykonawcy procesu oraz do innych pracowników przedsiębiorstwa. Pozyskiwanie i weryfikowanie wiedzy jest w nich w sposób nierozdzielny związane z podstawowymi procesami biznesowymi. Nie jako oddzielny system funkcjonujący sam dla siebie, ale jako część działań nakierowanych na spełnienie wymagań klienta. A w ilu dużych przedsiębiorstwach, posiadających nieraz bardzo rozbudowane systemy i certyfikaty, popełnia się wielokrotnie te same błędy? W ilu całymi latami funkcjonują procedury nieaktualne, błędne czy po prostu głupie? Ile razy firmy konsultingowe usprawiedliwiają dziesiątki stron raportów zadrukowanych „mądrościami” nie na temat, słowami: „taką mamy procedurę”?

Przed 5 laty w jednej z firm budowlanych wdrażano system workflow zgodny z ISO9000. Przygotowano szczegółowe procedury i taksonomie obejmujące ponad 800 możliwych sytuacji i kategorii. Celem było zestandaryzowanie jak największej części, a docelowo całej działalności przedsiębiorstwa. Lecz mimo wielkiej szczegółowości nie oddawało to konkretnych sytuacji występujących w różnych projektach budowlanych prowadzonych dla różnych inwestorów. W praktyce taksonomia okazała się nie wsparciem, lecz dodatkiem utrudniającym bieżącą pracę. W efekcie pracownicy potraktowali system jako zbędny obowiązek i większość wpisów do systemu opatrzone była kategorią „inne”. Prawie wszystkie wpisy wprowadzano po zakończeniu prac, kiedy znany był już rezultat prowadzonego procesu. W zamyśle projektantów systemu wpisy miały oddawać indywidualną specyfikę prowadzonych projektów, aby można było wykorzystać je jako źródło wiedzy przy prowadzeniu podobnych inwestycji W praktyce znacznie częściej służyły do manipulacji np. do tworzenia post factum uzasadnień dla opóźnień czy kłopotów jakościowych. Rozwiązanie wprowadzone odgórnie, bez powiązania z codzienną pracą, nie ułatwiło ani pracy ani kontroli pracy, nie zapewniło przepływu rzetelnej wiedzy o doświadczeniach wynikających z wykonanej pracy. Przykład ten pokazuje 3 podstawowe problemy dużych organizacji:

Działania nie łączą się w płynny proces
Funkcjonalna struktura współczesnych organizacji stworzona została w celu polepszenia kontroli i lepszego wykorzystania walorów specjalizacji pracy. Równocześnie jednak bardzo często prowadzi ona do zagubienia podstawowego celu działania przedsiębiorstwa, którym jest zaspokajanie potrzeb klienta. Granice funkcjonalnych jednostek organizacyjnych powodują poszatkowanie procesu podstawowego, który ma tworzyć wartość dla klienta, na nie łączące się ze sobą, odrębne części. Optymalizacja, a właściwie suboptymalizacja procesów w ramach takich struktur może łatwo prowadzić do realizacji celów poszczególnych jednostek organizacyjnych sprzecznych z celami procesu podstawowego nakierowanego na klienta. W ten sposób w jednym z obserwowanych przeze mnie przedsiębiorstw dział finansowy tak usilnie realizował swój cel, polegający na uzyskaniu jak największych zysków z lokat i innych instrumentów finansowych, że zaprzestał terminowych płatności dla dostawców, co doprowadziło do zatrzymania realizacji jednego z kluczowych kontraktów!

Jest to problem dostrzegany od dawna. Obecnie powszechnie podejmowane są próby jego rozwiązania poprzez wdrażanie zarządzania procesowego.

Nienadążanie z adaptacją do zmian wymagań klientów i otoczenia
Przedsiębiorstwo zorganizowane hierarchicznie nie jest w stanie zidentyfikować wiedzy posiadanej oraz pozyskiwanej z kontaktów z klientami, czy szerzej – z rynku. Spowodowane jest to dążeniem kierownictw przedsiębiorstw do rozciągnięcia na zarządzanie wiedzą ścisłej kontroli, analogicznej jak np. na zarządzanie finansami. W efekcie zamiast wiedza przepływa przez hierarchiczne meandry przedsiębiorstwa ulegając zniekształceniu lub w ogóle zagubieniu! Skutkiem jest znaczące spowolnienie reakcji przedsiębiorstwa na zmiany otoczenia. Nagminnie powtarza się te same błędy, forsując działania i rozwiązania zgodne z poglądami kierownictwa, wielokrotnie ponosi się trud i koszty na wypracowywanie rozwiązań już istniejących, lecz nie znajdujących uznania w oczach decydentów. Równocześnie nie dostrzega się albo ignoruje istotne szanse na wyprzedzenie konkurencji tylko dlatego, że nie przewidywały ich procedury lub formalnie zatwierdzone strategie, a wykonawcy procesów nie mieli dostatecznej samodzielności aby spróbować wykorzystać wyłaniające się szanse. W ten sposób zarząd jednej z nieistniejących już firm budowlanych zlekceważył 10 lat temu zgłaszaną przez kierowników kontraktów szansę specjalizacji w dającej doskonałe wyniki finansowe budowie małych basenów pływackich. Kiedy po 2 latach bardzo wyraźnie wzrosła liczba budowanych basenów, próbowano poprawić strategię i powrócić do tego pomysłu, lecz okazało się że szansa przepadła i jest już inna firma powszechnie uważana za specjalizującą się w takich inwestycjach.

Jest to problem, który został dostrzeżony w ostatnich latach. Próbą jego rozwiązania jest m. in. wdrażanie zarządzania wiedzą przez wspólnoty praktyków (community of practice).

Niezdolność do indywidualizacji procesów
Duże organizacje wdrażają procedury, instrukcje, przepisy wewnętrzne, uzyskują certyfikaty ISO zapewniające pełną i stale kontrolowaną powtarzalność procesów. Jednak na skutek tego tracą zdolność do szybkich zmian, nie mówiąc nawet o reakcji na indywidualne potrzeby klientów! Przecież każda zmian szczegółowej procedury wymaga decyzji Zarządu lub co najmniej grupy kluczowych dyrektorów. Nietrudno wyobrazić sobie, co dzieje się w sytuacji, gdy w związku z oczekiwaniami klientów niezbędne jest dokonanie zmian wzajemnie się wykluczających! Szczegółowe procedury czy modele procesów biznesowych standaryzujące działanie przedsiębiorstwa w zasadzie uniemożliwiają dostosowanie procesów do wymagań klienta, niezbędne w takich branżach jak budownictwo, konsulting, przemysł stoczniowy, a coraz częściej także w handlu, telekomunikacji, informatyce itp. A przecież już teraz np. współczesne banki internetowe są zmuszone do konkurencji na rynku indywidualnego klienta, podobnie jak dostawcy przeglądarek internetowych. Przykłady można mnożyć.

Jest to nowy problem, coraz wyraźniej występujący w ostatnich latach. Próbą jego rozwiązania jest dynamiczne zarządzanie procesami biznesowymi, które zostanie przedstawione w dalszej części artykułu.

Dynamiczne zarządzanie procesami biznesowymi

W normie ISO 9000:2000 procesowe podejście do zarządzania przedsiębiorstwem osiągnęło status unormowanych działań podlegających certyfikacji. Stało się tak dzięki dostrzeżeniu i docenieniu procesowej natury związku przedsiębiorstwa z klientem. Dlatego już teraz każda organizacja, która ma ambicję prosperować w XXI wieku, musi przejść swoistą terapię, której istotą jest koncentrowanie się na procesach widzianych z perspektywy klienta i partnerów biznesowych, a nie z perspektywy tradycyjnej hierarchii organizacyjnej [H99]. W praktyce oznacza to m. in. konieczność przełamania barier między jednostkami organizacyjnymi.

Skąd więc problemy przedsiębiorstw, nawet tych które wdrożyły zarządzanie procesowe zgodnie z normą ISO9000:2000 i uzyskały potwierdzający to certyfikat? Skąd liczne żarty z procedur i instrukcji „opisujących wszystko, w tym także sposób użycia papieru toaletowego i włączania wtyczek do kontaktu”? Może problemem jest właśnie dążenie do skrupulatnego wypełniania procedur? Do opisania i ciągłej „optymalizacji przez standaryzację” jak największej liczby procesów? Według zasady, że im więcej procedur tym lepiej, bo od strony formalnej pozwalają one uwolnić przedsiębiorstwo od ryzyka, a kierowników i wykonawców procesów od myślenia i odpowiedzialności! Takie podejście prowadzi do dwóch zagrożeń zabójczych dla przedsiębiorstwa: do zahamowania innowacyjności na skutek ograniczeń narzucanych przez procedury; odgrywają przy tym rolę 2 wzmacniające się czynniki:

  • opóźnienia wprowadzane przez biurokratyczne procedowanie zmian w zatwierdzonych mapach procesów oraz ograniczenia poglądami decydentów zazwyczaj nie mających bezpośredniego kontaktu z realizacją pracy;
  • do „uśrednienia” procesów, przybierających postać modelową, zaprojektowaną z myślą o spełnianiu wymagań średniego statystycznego klienta, czyli nikogo.

Korzyści z wdrożenia tradycyjnego zarządzania procesowego będą niweczone przez omawiane zagrożenia tym szybciej, im większe będzie tempo zmian otoczenia konkurencyjnego i technologii. W czasach kiedy konkurencję dzieli od nas tylko „jedno kliknięcie”[So4], liczy się szybkość, z jaką jesteśmy w stanie wykorzystać informację i zastosować wiedzę w celu dostosowania kluczowych procesów biznesowych do wymagań indywidualnych klientów. Indywidualizacja wymagań klientów wymaga indywidualizacji procesów biznesowych przedsiębiorstwa. Przewaga innowacyjności i szybkości adaptacji małych firm nad dużymi, nawet międzynarodowymi koncernami wyraźnie pokazuje, że kluczem do sukcesu staje się nie „optymalny proces biznesowy”, ale umiejętność dynamicznego kształtowania procesów biznesowych zgodnie z wymaganiami klienta.

Przypisy

[P05] Piotr Płoszajski, „Wstęp:10 lat w wieku nieciągłości” w: „Przerażony kameleon. Eseje o przyszłości zarządzania”, Płoszajski P. (red.), Fundacja Rozwoju Edukacji Menedżerskiej SGH, Warszawa 2005, www.e-mentor.edu.pl/biblioteka/kameleon.pdf, dnia 31.03.2007, s. 10.

[H99] Michael Hammer, „Reinżynieria i jej następstwa – jak organizacje skoncentrowane na procesach zmieniają naszą pracę i nasze życie” („Beyond Reengineering. How the Process-Centered Organization is Changing our Work and our Lives”), Wydawnictwo Naukowe PWN, Warszawa 1999, s. 11.

[S04] Hubert Salik, „Google zadebiutowało na giełdzie”, Gazeta Wyborcza, 20.08.2004, serwisy.gazeta.pl/wyborcza/1,34513,2238826.html, dnia 20.08.2004. („Z wyszukiwarkami jest tak, że wystarczy jedno kliknięcie, by skorzystać z innej. A jednak ludzie wybierają naszą. Bo chcą – powiedzieli Page i Brin”).

—

Napisane w Teksty, Zarządzanie. Tagi: , , , , , , , , , , , , , , , , , . Zostaw Komentarz »

Dynamiczne zarządzanie procesami biznesowymi – koncepcja

2009/09/05 — Andrzej Góralczyk

Klasyczny cykl doskonalenia procesów jest już zbyt powolny i nie wystarczający.

Marek Szelągowski

Jest to druga część opracowania opublikowanego w tym samym dziale.

Duże firmy przeznaczają ogromne środki na wdrożenia nowych metod zarządzania i skomplikowane systemy informatyczne, lecz nie są w stanie osiągnąć elastyczności działania naturalnej dla małych, rodzinnych firm! Być może dlatego, że na wysokich szczeblach organizacji wykorzystują tylko kapitał wiedzy kierownictwa nie dostrzegając, że to nie wystarcza w dobie gospodarki opartej na wiedzy. To zarząd czy kolegium dyrektorów akceptuje i zmienia procedury. To „wysocy szefowie” oceniają wyniki codziennej pracy a więc m. in. wykorzystania i dystrybucji starej oraz pozyskiwania nowej wiedzy. To oni bardzo często rezerwują dla siebie monopol na decydowanie o przydatności i rozpowszechnianiu wiedzy. A jeżeli się przy tym mylą? Satyryk powiedziałby „tym gorzej dla wiedzy”. W praktyce oznacza to jednak przegraną przedsiębiorstwa, spowolnienie jego rozwoju lub co najmniej utratę konkretnych szans rynkowych. Paradoksalnie, jest to efekt zaangażowania i ciężkiej pracy zarządów, które tak jak zawsze wykorzystują tylko swoją wiedzę i doświadczenie, starając się minimalizować ryzyka poprzez tworzenie procedur określających jak inni mają pracować.

Charakterystyka dynamicznego zarządzania procesami biznesowymi

Aby przełamać ten coraz wyraźniej widoczny paradoks, konieczne jest wykroczenie poza klasyczne zarządzanie procesami biznesowymi, w którym wykonawcy procesów realizują je zgodnie ze standardem, a komitet procesowy czy lider procesu powinien mierzyć i okresowo dokonywać zmian procesu standardowego. Z uwagi na konieczność zapewnienia oczekiwanej przez klienta szybkości działań oraz z uwagi na liczbę równolegle biegnących procesów nie ma możliwości, aby lider procesu analizował, decydował i wprowadzał do niego zmiany na bieżąco. Duże firmy budowlane w Polsce prowadzą równocześnie 50, 100 i więcej inwestycji, firmy konsultingowe prowadzą rocznie kilkadziesiąt – kilkaset projektów i ekspertyz, a firmy prawnicze setki różnych spraw. Przebieg każdego z wymienionych procesów bardzo mocno zależy od rodzaju projektu a także od indywidualnych wymagań czy nawet życzeń klientów. Niezbędne jest – tak jak w małych firmach – przekazanie bezpośrednim wykonawcom procesów możliwości ich dynamicznej modyfikacji w czasie wykonywania. Tylko w ten sposób można przywrócić szybkość i zwinność działania charakterystyczną dla małych firm firmom średnim, a nawet dużym przedsiębiorstwom. Jest to istotna jakościowa zmiana całej koncepcji organizacji zarządzanej procesowo, idąca wyraźnie w kierunku organizacji uczącej się. Propozycją realizacji ww postulatów jest koncepcja dynamicznego zarządzania procesami biznesowymi (dynamic business process management -DBPM). Opiera się ona na rozszerzeniu klasycznego (statycznego) zarządzania procesami poprzez nadanie mu 3 kluczowych cech:

  1. Kompleksowość i ciągłość

    Wdrożenie zarządzania procesowego powinno obejmować procesy składające się co najmniej na całą działalność podstawową przedsiębiorstwa. Nie ma żadnego sensu wdrożenie obejmujące tylko jedną jednostkę organizacyjną czy jeden proces elementarny bądź funkcję np. akwizycję czy produkcję. Wdrożenie DBPM powinno obejmować cały proces podstawowy, w tym także dostawców czy podwykonawców np. pracujących w jednej organizacji sieciowej. Celem nie jest minimalizowanie kosztów czy czasu pracy poszczególnych podwykonawców czy nawet przedsiębiorstwa będącego generalnym wykonawcą. Celem jest minimalizacja całkowitych kosztów i całkowitych zapasów, przy jednoczesnym zmniejszaniu całkowitego czasu realizacji [H99]. Już obecnie, zgodnie z przewidywaniami Druckera, wśród przedsiębiorstw budowlanych w Polsce obserwuje się przechodzenie od monitorowania kosztów działalności tylko w ramach swojej organizacji, do monitorowania kosztów całego procesu inwestycyjnego, w którym nawet duży generalny wykonawca stanowi jedynie pojedyncze ogniwo [PD]. Znacznie rozszerza to obszar poszukiwania możliwości podniesienia efektywności, a często także skrócenia czasu realizacji przedsięwzięcia, poprzez optymalizację biorącą pod uwagę działania przekraczające granice pojedynczego przedsiębiorstwa (np. dostawy, obsługę gwarancyjną) w ramach całego procesu tworzącego wartość, a także określającego koszt i czas realizacji dla klienta [JC].Obecnie Budimex przygotowuje się do włączenia kwalifikowanych podwykonawców w swój proces podstawowy, poczynając od procesu pozyskania kontraktu. Pozwoli to znacznie skrócić czas między podpisaniem kontraktu, a rzeczywistym rozpoczęciem prac. Jednak ważniejszą korzyścią jest możliwość przepracowania planowanego projektu z klientem (inwestorem) i kompetentnymi podwykonawcami jeszcze przed podpisaniem umowy. Często pozwala to na przeprojektowanie planowanej inwestycji (value engineering) i wygranie kontraktu właśnie dzięki uzyskanym oszczędnościom, czy skróceniu planowanego czasu realizacji. Równocześnie pozwala na przekazanie wiedzy i innowacji z procesu pozyskania kontraktu do procesu realizacji, w którym dokonuje się ich praktyczna weryfikacja. Informację o wyniku tej weryfikacji, tzn. potwierdzenie słuszności przyjętej koncepcji lub ostrzeżenie przed błędem, którego nie należy powielać otrzymują natychmiast handlowcy, podwykonawcy, kierownicy biegnących kontraktów o podobnym charakterze, a także wykonawcy procesu obsługi gwarancyjnej (jako wskazówkę na co należy zwrócić uwagę). Mówimy więc nie tylko o ciągłości procesu biznesowego ale także o ciągłości tworzenia, pozyskiwania i weryfikacji wiedzy.

  2. Ewolucyjna zmienność w czasie wykonywania

    Pracownicy realizują proces zaprojektowany według obecnej najlepszej wiedzy przedsiębiorstwa. Jest to proces standardowy „na dzisiaj”, gdyż standard pod wpływem wymagań klientów, zmian technologii czy też nowych doświadczeń przedsiębiorstwa może się zmieniać. Co więcej – w praktyce nie ma dwóch takich samych warunków wykonania procesu, np. dwóch takich samych projektów konsultingowych czy inwestycji budowlanych. Zatem procesy standardowe „na dzisiaj” muszą być dynamicznie dostosowywane przez wykonawców do wymogów realizacyjnych. Klasyczny cykl doskonalenia procesów, wykorzystywany przez liderów, składający się z modelowania procesów, obserwacji realizacji, wyciągania wniosków a następnie wykorzystywania tak zdobytej wiedzy do ulepszenia procesu, jest zbyt powolny i nie wystarczający. Dodatkowo w przypadku przeciwstawnych oczekiwań klientów (inwestorów) może się okazać, że nie jest możliwe zbudowanie procesu „uniwersalnego”, akceptowanego przez wszystkich klientów, z którymi aktualnie współpracuje przedsiębiorstwo. Procesy muszą być definiowane i wdrażane w taki sposób, aby ich bezpośredni wykonawcy (np. szefowie projektów, kierownicy kontraktów) mieli możliwość uzupełnienia, a nawet zmiany przebiegu działań i czynności w każdym kroku procesu. Zgodnie z posiadanymi uprawnieniami to oni, a nie jak dotychczas, tylko liderzy procesów, muszą mieć możliwość wprowadzania na bieżąco zmian do realizowanego procesu. Równocześnie lider danego procesu obserwując rzeczywiste wielokrotne wykonania procesu oraz ich efekt końcowy, musi mieć możliwość uzupełniania i przemodelowania procesu standardowego zgodnie z najnowszą posiadaną wiedzą, dodając do niego dobre praktyki biznesowe (good practices), rozumiane jako te, które przy kolejnych wykonaniach procesu doprowadziły do sukcesu.

  3. Wykonanie procesu jest równoznaczne z udokumentowaniem wykonania

    Wprowadzanie zmian przez liderów do procesu standardowego w sposób tradycyjny znacznie ogranicza szybkość przekazywania wiedzy w organizacji. Na przykład procedury i procesy wg normy ISO 9000:2000 są audytowane i zmieniane co rok, niekiedy co pół roku. W przypadku organizacji, w której biegnie jednocześnie wiele procesów mogłoby to prowadzić do zaprzepaszczania pojawiających się szans lub wielokrotnego powtarzania tych samych błędów. Wdrożenie drugiej cechy DBPM – ewolucyjnj zmienności procesów w trakcie wykonania – może być dobrym sposobem na pokonanie omawianej ociężałości. Lecz bez możliwości bieżącej kontroli kierownictwo prędzej czy później przestałoby panować nad ową zmiennością i pojawiłyby się nowe ryzyka w efekcie narastającego rozprzężenia w organizacji. Dla przyspieszenia obiegu wiedzy oraz budowy normalnych ścieżek kontroli wykonywanych procesów niezbędne jest wykorzystanie technologii teleinformatycznych. Wdrożenie DBPM musi być dokonane w taki sposób aby definicja procesu była równoznaczna z przebiegiem procesu w wykonawczym systemie informatycznym oraz żeby wykonanie procesu było równoznaczne z udokumentowaniem wykonania. Tylko wtedy będzie możliwe porównanie definicji procesu („proces standardowy na dzisiaj”) z jego wykonaniem. I tylko wtedy będzie możliwe uzyskiwanie na bieżąco – z analizy takiego porównania – informacji o wszelkich innowacjach wprowadzonych przez wykonawców procesów oraz o skutkach tych innowacji. Wtedy można mówić nie o zarządzaniu ex post, ale o dynamicznym bieżącym zarządzaniu, w oparciu o stale napływające do kierownictwa przedsiębiorstwa dane.

Dynamiczne zarządzanie procesami biznesowymi nie jest tym samym, co nadzorowanie procesów w czasie rzeczywistym, które w istocie sprowadza się do natychmiastowego powiadamiania o zakończeniu działania oraz alarmowania o przekroczeniu wartości dopuszczalnych, lecz nie zezwala na bieżące wprowadzanie zmian. W procesach nadzorowanych w czasie rzeczywistym wykonawca nadal pełni rolę „robota na bieżąco kontrolowanego przez kierownika”. W dynamicznym zarządzaniu procesami wykonawca ma możliwość kreatywnego kształtowania swojej pracy, a przez to współuczestniczenia w zarządzaniu i tworzeniu wiedzy przedsiębiorstwa.

Dynamiczne zarządzanie procesami umożliwia natychmiastowe dołączanie praktyk i rozwiązań, które przynoszą najlepsze rezultaty do zbiorowej wiedzy organizacji. Jest to realne, codzienne udoskonalanie i adaptowanie procesów biznesowych w oparciu o wiedzę szerokiego kręgu pracowników zweryfikowaną przez klienta. Dynamiczne zarządzanie procesami umożliwia realne, praktyczne przeniesienie zarządzania wykonaniem pracy tam, gdzie ta praca jest wykonywana. Jeżeli kierownictwo uznaje, że powodzenie realizowanego procesu (inwestycyjnego, konsultingowego, logistycznego itd.), zależy od tego jak wykonawca procesu na bieżąco odpowiada na wymagania klienta, to DBPM odpowiada na pytanie w jaki sposób wyciągnąć korzyści z tego faktu. W jaki sposób bez ryzyka chaosu przekazać pracownikom realne uprawnienia decyzyjne i przez to wyeliminować ciągłe zbyt długotrwałe oczekiwanie na decyzje z góry. Inaczej mówiąc: w sytuacjach, gdy wykonawcy procesów są posiadaczami istotnej wiedzy stanowiącej podstawę kapitału intelektualnego przedsiębiorstwa, dynamiczne zarządzanie procesami biznesowymi pozwala aby ten kapitał pracował.

Należy podkreślić, że wiedza jest tworzona i weryfikowana w ramach podstawowej działalności, a nie w jakimś odrębnym, odseparowanym systemie. Nie ma więc niebezpieczeństwa jej niespójności czy niepełności na skutek oderwania od rzeczywistej działalności. Ta zdolność do ciągłego tworzenia i weryfikacji wiedzy wraz z możliwością swobodnego poszukiwania rozwiązań (kontrolowanego eksperymentowania) jest podstawą umiejętnością pozwalającą przedsiębiorstwu, zachować stałą zdolność do zmian, do reakcji na zmiany. Codzienna praktyczna weryfikacja wiedzy ma podstawowe znaczenie. Bez niej, w dobie szybkich i często nie przewidywalnych zmian wymagań i potrzeb klientów, bardzo łatwo mogłoby się okazać, że przedsiębiorstwo posługuje się starą i już zdezaktualizowaną wiedzą, która powinna już być odrzucona tworząc coś co można nazwać „wrong practices”.

Zakończenie

Indywidualizacja wymagań klientów prowadzi do konieczności indywidualizacji procesów biznesowych przedsiębiorstwa. Oznacza to konieczność codziennej równoległej realizacji trzech różnych podejść do zmian procesów biznesowych: optymalizacji, adaptacji i indywidualizacji. Klasyczne, statyczne zarządzanie procesowe dobrze działa wykorzystując systemy informatyczne klasy BPM gdy istnieje potrzeba optymalizacji procesów. Napotyka ono jednak na dwa poważne problemy w przypadku nieprzewidywalnych zmian adaptacyjnych. Pierwszy problem to konieczność podjęcia decyzji przez lidera procesu, która opóźnia wprowadzanie koniecznych zmian. Drugi to brak możliwości systemowego, instytucjonalnego powiązania działalności podstawowej przedsiębiorstwa z zarządzaniem wiedzą poprzez system procesowy. Te dwa problemy sprawiają, że zarządy, dyrekcje, kierownictwa czy liderzy procesów mają trudności z nadążaniem ze zmianami adaptacyjnymi. Konieczność indywidualizacji procesów jeszcze bardziej wyostrza problem szybkości zmian. Przecież nie można już dziś pozwolić sobie na oczekiwanie przez kwartał, miesiąc czy nawet tydzień na decyzje dotyczące biegnącego kontraktu! Który inwestor, który klient banku będzie chciał czekać choćby tylko tydzień na zmianę procedury umożliwiającą dalsze prowadzenie inwestycji czy stworzenie indywidualnego planu oszczędzania? Kierownictwa przedsiębiorstw nie mają żadnych możliwości, aby zarządzając tradycyjnie podołać wymaganiom indywidualizacji procesów.

Główną korzyścią z wdrożenia dynamicznego zarządzania procesami biznesowymi jest przywrócenie dużym przedsiębiorstwom szybkości i zwinności niezbędnych do działania i konkurowania w zmieniającej się sytuacji rynkowej. Umożliwiając rzeczywiste przekazanie wykonawcom procesów uprawnień i odpowiedzialności za kształtowanie pracy, bez niebezpieczeństwa utraty kontroli nad biegnącymi procesami, DBPM pozwala dużym przedsiębiorstwom na zarządzanie wiedzą w codziennej działalności w oparciu o:

  • twórcze, aktywne eksperymentowanie we wprowadzaniu ciągłych niewielkich zmian przez szeroki krąg wykonawców procesów, prowadzące do stopniowego gromadzenia i upowszechniania wiedzy,
  • codzienną weryfikację posiadanej wiedzy i eliminowanie wiedzy przestarzałej, nie odpowiadającej już wymaganiom klientów ani wyzwaniom konkurencji [BM].

Koncepcja dynamicznego zarządzania procesami biznesowymi jest rozwinięciem koncepcji klasycznego zarządzania procesowego i próbą zbliżenia jej do koncepcji organizacji uczącej się.

Podstawą DBPM nie jest technologia, chociaż bez niej byłoby ono praktycznie nie możliwe. To przykład pokazujący, że Nicholas Carr nie ma racji, że IT jest niezbędne do budowy i podtrzymywania przewag konkurencyjnych przedsiębiorstwa. Lecz technologia jest tylko narzędziem umożliwiającym i stymulującym zmiany zarządzania. Może to się wydać paradoksem, ale dynamiczne zarządzanie procesami biznesowymi, którego praktyczna implementacja jest możliwa tylko dzięki wykorzystaniu informatyki, pozwala tak naprawdę na uzyskiwanie przewagi konkurencyjnej nie dzięki IT, ale poprzez przywrócenie wykonawcom procesów możliwości kształtowania swojej pracy. Tak jak to było od zawsze w małych rodzinnych firmach.

Przypisy

[H99] Michael Hammer, „Reinżynieria i jej następstwa – jak organizacje skoncentrowane na procesach zmieniają naszą pracę i nasze życie” („Beyond Reengineering. How the Process-Centered Organization is Changing our Work and our Lives”), Wydawnictwo Naukowe PWN, Warszawa 1999, s. 136.

[PD] Peter Drucker, „Zarządzanie w XXI wieku” („Managements Challenges for the 21st Century”), Muza S.A., Warszawa 2000, s. 117.

[JC] James A. Champy, “X-engineering przedsiębiorstwa. Przemyśl swój biznes w erze cyfrowej” (X-Engineering the Corporation. Reinventing Your Business in the Digital Age), Placet, Warszawa 2003, s. 152.

[BM] Bogusz Mikuła, „W kierunku organizacji inteligentnych”; Antykwa 2001, s. 29 – 35.

Napisane w Teksty, Zarządzanie. Tagi: , , , , , , , , , , , , , , , , , . 1 komentarz »
« Starsze wpisy