Od czasu do czasu spotykam się z analizami wymagań, powstałymi w dość spektakularny sposób. Jest to metoda zbierania wymagań „na procesy referencyjne” i nadal niestety ma wzięcie. Głównym powodem jest to, że nie wymaga żadnych umiejętności, może to zrobić każdy. W ostatnim roku spotkałem się z wynikami tego podejścia trzy razy. Wszystkie trzy spalone niestety… Dlaczego?

Jednym z chyba najbardziej znanych zestawów procesów referencyjnych jest APQC. Tak piszą jego promotorzy o nim:

APQC’s Process Classification Framework?(PCF) is the most used process framework in the world. It creates a common language for organizations to communicate and define work processes comprehensively and without redundancies. Organizations are using it to support benchmarking, manage content, and perform other important performance management activities. (Źródło: About APQC)

Co ciekawe nie ma tu mowy o wymaganiach. Jednak tego typu specyfikacje są używane w ciekawy sposób: nazwy tych procesów są kolejno czytane a pracownicy firmy, która jest beneficjentem tej „analizy”, siedzą na sali i w toku „warsztatów wymagań” mówią, który proces wg. nich powinien być wymagany w systemie ERP (co by to nie miało znaczyć), mimo że i tak nie rozumieją co wybierają, bo nie wiedzą jak dany proces jest realizowany (specyfikacja APQC operuje ich listą nie modelami).  W efekcie otrzymujemy nie raz kilka tysięcy (!) tak zwanych „wymagań”, z którymi nie bardzo wiadomo co zrobić. Owszem dokument, dzieło takiego „analityka”, wygląda imponująco. Rzecz w tym, że nie ma tu mowy i jakimkolwiek sprawdzeniu kompletności, niesprzeczności i spójności (brak modeli tych procesów nie pozwala na takie weryfikacje).

Podobna metoda, sensowniejsza ale tylko trochę, polega na tym, że listą bazową jest nie APQC a lista procesów biznesowych (a raczej dostępnych czynności i nazw dokumentów) dostarczona z konkretnym oprogramowaniem ERP. Tu przynajmniej wiemy, że to oprogramowanie ma te cechy, ale nadal jest to tylko ich lista. Niektóre firmy, producenci oprogramowania ERP,  dostarczają specjalne narzędzie, które panuje nad spójnością takiego wyboru. Ma np. wbudowane informacje o wzajemnych powiązaniach pomiędzy procesami i ich produktami (np. powiązanie zamówień z fakturami) co pozwala uniknąć sytuacji rezygnacji z dokumentów źródłowych i żądaniu tych, które na ich podstawie powstają. Jednak użycie tego narzędzia wymaga posiadania wiedzy o procesach biznesowych w danej firmie, bo to zestawienie procesów w systemie ERP nie służy do głosowania „chcę/nie chcę”, to zestawienie służy do wykonania tak zwanej analizy gap/fit (nie ma/jest), czyli do wykrycia procesów, których nie ma na tej liście, a w toku analizy biznesowej klienta stwierdzono, że są realizowane. Oczywiście, dla takiego porównania, bardzo istotna jest wiedza o tym jak dany proces przebiega w badanej firmie i w oferowanym (planowanym do wdrożenia) oprogramowaniu ERP. Nie zmienia to faktu, że dostawcy oprogramowania ERP, nie wiedzieć czemu, bardzo często nie stosują się do tych zaleceń, zaleceń producentów tego co oferują i wdrażają. Warto pamiętać, że

podpisanie umowy z dostawcą ERP przed wykonaniem tej analizy często rodzi poważny problem: „odkrycie” (analiza gap/fit), że to konkretne oprogramowanie nam po protu nie pasuje (wykryta w toku gap/fit luka jest duża), i skutkuje dość pokaźną listą tak zwanych „kastomizacji”. Deklaracja dostawcy ERP: „nasze oprogramowanie Wam pasuje” składane przed wykonaniem takiej analizy, to niczym nie poparte wróżenie z fusów. 

Warto też pamiętać, że

sama nazwa procesu to za mało, bo np. wystawienie faktury sprzedaży na prawdę może przebiegać na wiele sposobów i uznanie, na podstawie samej tylko nazwy procesu, że „to wymaganie spełniamy” jest raczej poważnym nadużyciem. Przebieg procesów biznesowych i organizacja pracy w każdej firmie, są efektem wielu bardzo złożonych zależności, kompetencji i umiejętności ludzi oraz narzędzi pracy jakich używają.

Trzy lata temu pisałem:

Na pewnym wysokim poziomie abstrakcji można mówić o procesach referencyjnych, a raczej dobrych praktykach np. proces tworzenia nowego produktu powinien mieć następujące kroki: opis pomysłu, analiza  SWOT produktu na rynku, oszacowanie ceny sprzedaży, kosztu wytwarzania i planowanego poziomu sprzedaży, prognoza przepływów gotówkowych.  Ale to ?ogólny opis? a nie ?prototypy procesów i mapy procesów?. proces i jego mapa to najniższy, implementacyjny poziom opisu.Tak więc są na pewno pewne pryncypia, można je znaleźć np. w książce M.E.Portera ?Strategie konkurencji? (autor koncepcji rynkowego łańcucha wartości) czy P.Druckera ?Praktyka zarządzania?. Jednak jak nam ktoś oferuje system ERP z ?wbudowanymi procesami referencyjnymi? to należy rozumieć: ?szykuje się totalna rewolucja?, czy ją przeżyjemy? (Źródło: Procesy referencyjne czyli kto żyw niech ucieka | Jarosław Żeliński IT-Consulting)

Wszystkie te trzy spotkane przypadki tak wykonanej analizy, niestety skończyły klęską: w jednym na szczęście od razu odrzucono wyniki analizy więc strata była relatywnie mała.  Więc jeżeli ktoś Państwu oferuje „prosty sposób na wykonanie analizy wymagań” na, bądź co bądź, bardzo złożony system informatyczny, to zastanówcie się nad ryzykiem jakie podejmujecie…

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 6 komentarzy

  1. analityk

    Jarosław,
    APQC służy jedynie do klasyfikacji procesów biznesowych, które następnie i tak należy zamodelować (wywiady, konsultacje, dużo pracy analitycznej). To nie jest wyjście na 'wymagania’.
    Jeśli w kolejnym kroku biznes kładzie dokumentację procesową jako wymagania, nie jest to ruch, który powinien obciążać analityka.

    Potwierdzam, położenie modeli procesów jako wymagań na system jest błędem.
    Pozdrawiam

    1. Jaroslaw Zelinski

      Do czego służy APQC napisałem, a raczej zacytowałem. Co do modeli procesów jako wymagań to nie do końca jest to błąd, podobnie ja nie jest błędem opisanie procesów logistycznych i transportowanych produktów, by w firmie transportowej wybrać właściwy samochód. Procesy biznesowe to nic innego jak dane wejściowe i wyjściowe, dodanie do tego opisu logiki biznesowej i „podanie” jako wymagania jest znacznie lepszym pomysłem, niż lista wybranych przypadkowo w toku burzy mózgów 2 tys. szczegółów na temat „potrzebnego hipotetycznego oprogramowana”.

      I zapytam: kim tu jest (jaki produkt tworzy) „analityk”?

  2. analityk

    Jarosław,
    Wziąłem udział w analizie procesów biznesowych, których struktura została dostosowana do APQC – stąd moje zainteresowanie tym tematem.
    Tyle, że my oprócz osadzenia diagramów zgodnie z kategoryzacją APQC – zamodelowaliśmy b. szczegółowo procesy. To o czym piszesz jest czymś innym – ktoś wziął po prostu framework i wypisał, że ERP ma być zgodny z tymi a tymi procesami APQC? To faktycznie całkowicie bezsensu. Wręcz trudno mi uwierzyć, by ktoś poszedł aż tak na skróty – to musiało być jakieś godne pożałowania nieporozumienie. I zgodzę się, że coś takiego to nie analiza.

    APQC zaś jest sens stosować chyba wtedy tylko, gdy zakładamy, że nasza organizacja będzie blisko współpracować z inną organizacją, której procesy są już sklasyfikowane w zgodzie z tym frameworkiem. Wówczas poprawia to komunikację.

    Używanie zaś 'APQC’ jedynie 'bo tak’ to słaby pomysł. Dla analityka stanie się to jedynie 'ograniczeniem projektowym’ z którym będzie musiał żyć przez cały projekt.

    1. Jaroslaw Zelinski

      Pomiędzy firmami wymieniane są dokumenty, np. faktury, WZ czy zamówienia, procesy tworzenia tych dokumentów w danej firmie nie mają na to (współpraca) żadnego przełożenia.

  3. Trudna Sprawa

    Dzień dobry,

    mam taki problem właśnie z APQC, bo staram się uporządkować procesy w firmie IT i przyjęłam sobie najpierw, że każdy z tych procesów przypiszę do określonej kategorii, a później będę tworzyć procedury. Niestety nie skończyłam studiów w zakresie modelowania, ani też nigdy się z nim nie spotkałam w pracy (ogólnie działam w marketingu, ale zostałam oddelegowana do utworzenia procesów i nie wiem totalnie, jak się za to zabrać).

    Czy poza stroną organizacji APQC, z której można pobrać listę tych kategorii po angielsku, jest jakieś miejsce w sieci, gdzie ktoś tłumaczy, jak modelować poszczególne elementy? Ja wciąż jestem na etapie pierwszej kategorii, staram się ustalić jakoś procesowo sam model budowania wizji i strategii, ale nie wiem, w jaki sposób można to zrobić…

    Zapewne jako laik nie powinnam brać się za modelowanie. Naprawdę podziwiam osoby, którym to wychodzi. Od ponad miesiąca zbieram się, żeby jakoś to skonstruować. Dwa tygodnie temu prosiłam szefa o zdjęcie tego ze mnie i zlecenie na zewnątrz, ale podobno nie ma na to już czasu, żeby kogoś szukać.

    Jeśli APQC jest wadliwe, to od czego ewentualnie zacząć, żeby takie procesy zidentyfikować, żeby ustalić co trzeba zmienić, a co jest dobre w firmie?

    Pozdrawiam serdecznie!

    1. Jaroslaw Zelinski

      Niestety, dość często opisywana w literaturze kategoryzacja procesów nie działa bo procesy w firmach nie są hierarchiczne, one się przenikają i są „poziome”. APQC ma nadal wielu zwolenników, ale głownie na początku projektów, szybko się okazuje, że drzewiasta struktura detalicznych czynności i funkcji nie koresponduje z rzeczywistością. Co do literatury najnowsza jest chyba książka Controlling procesów. Jak wdrożyć? Magdaleny Chomuszko. Jednak jest ona pisana z perspektywy wdrożeń systemów ERP, a te nie obsługują żadnych procesów tylko dokumenty księgowe i ich statusy. Orędowników APQC jets wielu ja jednak nigdy nie widziałem sukcesu tej metody.

      Co zrobić? Sugeruję zrezygnować z podejścia bazującego na listach referencyjnych i hierarchii, a zacząć patrzeć na firmę jak na zdarzenia, które należy obsłużyć. Po pierwsze kluczowych procesów w firmach jest mało, po drugie trzeba bardzo się pilnować by nie mieszać: modeli procesów, treści procedur i reguł dotyczących dokumentów i ich wypełniania. Jako osoba początkująca narażona jest Pani na popełnienie wielu błędów :), co do tego czy macie jako firma czas na szukanie wykonawcy… a macie czas na naukę na własnej skórze? ;). Więcej mógł bym napisać, gdybym znał Państwa problem ale dalsza rozmowa zapewne wymaga detali na temat Państwa firmy. Jeżeli ma Pani ogólne pytania proszę pisać tu, jeżeli potrzebne są jakieś detale, zapraszam do kontaktu bezpośredniego. Tu mogę napisać, że takie projekty realizuję zdalnie, mam narzędzia do bezpiecznej zdalnej pracy. W takich projektach osoba taka jak Pani jest koordynatorem i dużo się uczy przy okazji pracy ze mną ;).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.