Analiza wymagań metodą „na gotowca”
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…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Tak więc są na pewno pewne pryncypia, można je znaleźć np. w książce M.E.Portera 