Temat: Poziom szczegółowości BPMN dla dokumentacji ERP
Adam C.:
Może inaczej... użyję przykładu z przykładu
Przy takim procesie zakupu występują koszty transportu, które w przypadku korzystania przez przedsiębiorstwo z cen nabycia a nie zakupu - muszą zostać doliczone w odpowiednio ustalony sposób (np. według wagi produktów z dostawy, według objętości produktu, lub według innego ustalonego sposobu)
I tutaj według mnie pojawi się słabość wymagań spisywanych z pomocą BPMN ponieważ od razu "uciekają" nam do innych "pojemników" wymagania w postaci:
1. System ma obsługiwać ceny nabycia
2. System ma obsługiwać doliczenie kwoty transportu do towarów z dostawy w sposób x lub y lub z
BPMN nie służy do definiowania wymagań a do utworzenia modelu działania firmy, upewnieniu się, że nie ma w nim żadnych luk lub ryzyk (np. nieobsłużone ścieżki działania czy nadmiarowe dokumenty). Na tym modelu dane mają znaczenie wyłącznie jako "coś co ma powstać' a nie "treść tego co ma powstać".
Punktu pierwszego ni jak nie da się zawrzeć na diagramie a zawarcie warunków (czyli bramek i dodatkowych czynności) doliczenia i sposobów rozbijania kosztu czyni z niego nie diagram procesu a procedurę i tu się całkowicie zgadzam ze stwierdzeniem, że Jarek Ż.:
Należy mieć świadomość, że organizacja ma (może mieć): zakresy obowiązków i kompetencji, procedury i tego na modelach procesów nie powinno już być.
oba te punkty to jakieś algorytmy które nie mają prawa się znaleźć na diagramie procesów biznesowych, jeżeli jakaś czynność (proces) wymaga wiedzy o "sposobie naliczenia" to tę wiedzę albo ma aktor i nie jest ona wymaganiem wobec ERP, albo chcemy żeby ten system sam to naliczał i wtedy opisujemy taki algorytm, nadajemy mu nazwę i powołujemy się na niego na modelu procesów ("wyliczenie ceny sprzedaży przebiega zgodnie z algorytmem ABC-1.2) . Takie podejście pozwala na stała kontrolę czy wszystkie czynności wymagające takiej wiedzy zostały udokumentowane.
Z takiego modelu procesu (a nie procedury) nie da się wywnioskować jakie rodzaje cen mają być stosowane ani czy system posiada odpowiednie algorytmy rozbijania kwoty transportu na pozycje dostawy tak aby nie zniekształcać docelowej kwoty towaru. Model BPMN według mnie jest swoistym tłem, który musi być w takim wypadku wzbogacany innymi formami dokumentacji.
wszelkie "kalkulacje" lub reguły decyzyjne itp. to inne diagramy (algorytmy, procedury, tablice decyzyjne itp.)
Przekładając taki wycinek analizy działań przedsiębiorstwa jakim jest taki proces zakupu na całość procesów firmy "ucieknie" bardzo dużo rzeczy, które będziemy musieli zawrzeć w innych elementach dokumentacji a nie w diagramach BPMN więc śmiem twierdzić, że SAM zapis BPMN w dokumentacji wymagań na system ERP jest BEZUŻYTECZNY.
przypomnę: modele procesów nie służa do modelowania wymagań a do ich walidacji.
Po drugie czym jest wymaganie?????
Wymaganie funkcjonalne to usługa systemu czyli jego przypadki użycia, te mapują sie jeden do jednego na czynności na modelu BPMN zaliczone do zakresu projektu (wdrożenia). mając ich dziesiątki, bez modelu procesów nie mamy możliwości stwierdzenia czy czegoś nie pominięto lub czy nie zgłoszono ich za wiele.
Wymaganie pozafunkcjonlane to wszelkie cechy jakościowe systemu,
Wymagania dziedzinowe to reguły biznesowe i decyzyjne czyli wszelkie metody i algorytmu naliczeń itp.... muszą być zamapowane na czynności w modelu procesów (lub na przypadki użycia) w celu walidacji czy sa wszystkie.
Jarek Ż.:
Moim zdaniem nie tyle problem tkwi w np. w tworzeniu modeli procesów bo to tylko narzędzie, to nigdy nie powinno być celem samym w sobie.
Podpisuje się rękami i nogami pod tym i skupiam się na ich przydatności jednak tak jak wcześniej napisałem iż same diagramy bez czegoś dodatkowego mają dla mnie jako konsultanta zerową wartość przy wdrożeniu ERPa w danym przedsiębiorstwie.
Oczywiście, sam model procesów ma sens jako model działania firmy, która przed wdrożeniem ERP powinna usunąć ewentualne wady organizacji czyli uporządkować swoje działania (słynne modele as-is i to-be). Nie wolno zapomnieć, że sam fakt pojawienia się nowego narzędzia pracy wymusi zmianę wielu procesów i procedur. Czyli reorganizacja jest niejako wpisana w proces wdrożenia systemu ERP i warto ja planować przed wdrożeniem bo później jest znacznie kosztowniejsza.
Jestem zwolennikiem prince'owej koncentracji na produktach z naciskiem iż te produktu muszą posiadać jakąś wartość.
Podobnie jak ja:
Wartość dodana modelu procesów: brak modelu procesów biznesowych powoduje, że lista wymagań (w jakiejkolwiek formie) jest tak samo nieweryfikowalna jak tekstowy opis długiej wycieczki po mieście bez planu tego miasta ... (nie znam nikogo kto by taki plan z pamięci wyrysował, więc poleganie wyłącznie na samych wywiadach z pracownikami to droga do kłopotów).
Powołując się na tytuł wątku: poziom szczegółowość modelu BPMN nie powinien schodzić poniżej atomowych par "czynność-dokument jaki ona tworzy" (czyli będzie ich raczej kilkadziesiąt niż z kilkaset!!!) . Pozostałe elementy, poza tym diagramem, jako dokumenty skojarzone to:
- lista reguł biznesowych i decyzyjnych kojarzonych (śladowanie) z odpowiednimi czynnościami w procesach (przypadkami użycia systemu)
- specyfikacja wzorów dokumentów (w tym odpowiadających im ekranów) skojarzonych z czynnościami (przypadkami użycia).
- oraz słownik pojęć dla zapewnienia jednoznaczności całej dokumentacji.
Wiele metodyk zakłada, że wybór i wdrożenie gotowego oprogramowania ERP nie powinien zawierać żadnych wymagań prowadzących do kastomizacji np. wymaganie "system ma pozwalać na wybór kontrahenta z rozwijanej listy" jest bez sensu, bo celem jest raczej ergonomia pracy a nie rozwijana lista sama w sobie. Taką pomoc np. podczas wystawiania faktury może być osiągnięta innym sposobem niż rozwijana lista i warto korzystać z tego, ze oprogramowanie jest gotowe.
Należy uznać fakt, że kupno gotowego oprogramowania to kompromis a nie szycie na miarę. Dlatego wymagania na gotowe oprogramowanie z zasady będą mniej szczegółowe niż na oprogramowanie dedykowane. Należy pamiętać, że kastomizacja jest zawsze kosztowniejsza niż napisanie "na boku" brakujących funkcjonalości w takiej postaci w jakiej jest wymagane, i integracja jej, takie podejście zalecaja producenci czołowych produktów na tym rynku: każdy daje wraz z ERP środowisko jego rozbudowy w celu rozbudowy a nie w celu prucia (czytaj psucia) gotowca...
пропозиції роботи
