Czy wdrożenie systemu ERP powinno zaczynać się od analizy finansów, sprzedaży i magazynu? Przez lata właśnie tak wyglądała większość projektów. Organizacje dzielono na obszary funkcjonalne, a warsztaty prowadzono osobno dla każdego działu. Chociaż takie podejście wydaje się naturalne z punktu widzenia struktury systemu ERP, niekoniecznie odzwierciedla sposób działania przedsiębiorstwa.
W praktyce w organizacjach funkcjonują złożone i wzajemnie powiązane procesy biznesowe przebiegające przez wiele działów jednocześnie.
W odpowiedzi na konieczność zmiany podejścia we wdrożeniach Microsoft stworzył Business Process Catalog – referencyjny katalog procesów biznesowych dla wdrożeń rozwiązań aplikacji biznesowych z rodziny Dynamics 365. Wspiera implementacje oparte na procesach biznesowych, a w połączeniu z narzędziami takimi jak Azure DevOps umożliwia budowanie pełnej ścieżki traceability: od procesu biznesowego, przez wymagania i backlog projektu, aż po implementację oraz testy.
W artykule zaprezentuję, jak takie podejście zmienia sposób realizacji wdrożeń ERP na przykładzie projektów Dynamics 365 Business Central oraz jakie korzyści przynosi zarówno klientom, jak i zespołom projektowym.
Tradycyjne podejście do wdrożeń ERP – skąd biorą się problemy?
Przez wiele lat projekty wdrożeniowe systemów ERP realizowano przede wszystkim w oparciu o strukturę organizacyjną firmy oraz odpowiadające jej moduły funkcjonalne systemu. Analiza rozpoczynała się od podziału przedsiębiorstwa na obszary takie jak finanse, sprzedaż, zakupy, magazyn czy produkcja. Następnie dla każdego z nich organizowano osobne warsztaty, identyfikowano wymagania i projektowano rozwiązania.
Takie podejście ma swoje uzasadnienie. Struktura większości systemów ERP, w tym tych z rodziny Microsoft Dynamics 365, jest w naturalny sposób podzielona na obszary funkcjonalne. Również po stronie klienta za poszczególne procesy często odpowiadają różne działy, których przedstawiciele uczestniczą w odrębnych warsztatach projektowych.
Problem pojawia się jednak wtedy, gdy próbujemy odwzorować rzeczywiste funkcjonowanie organizacji. Firmy nie działają w izolowanych silosach odpowiadających poszczególnym modułom systemu. W praktyce niemal każda kluczowa aktywność biznesowa przebiega przez wiele działów jednocześnie i wymaga współpracy różnych zespołów.
Gdy proces znika pomiędzy warsztatami
Dobrym przykładem jest proces realizacji zamówienia klienta. Na pierwszy rzut oka wydaje się prosty, jednak w rzeczywistości obejmuje wiele obszarów organizacji:
- dział sprzedaży przyjmuje zamówienie,
- magazyn weryfikuje dostępność towaru,
- logistyka organizuje dostawę,
- dział finansowy odpowiada za fakturowanie i rozliczenie transakcji.
Czasami dochodzi do tego jeszcze dział zaopatrzenia lub produkcja, gdy dostępność towaru w magazynie jest niewystarczająca.
W tradycyjnym projekcie każdy z tych etapów jest omawiany podczas osobnych warsztatów, prowadzonych przez różnych konsultantów i z udziałem różnych przedstawicieli klienta. W rezultacie poszczególne fragmenty procesu są analizowane niezależnie od siebie, a pełny obraz przepływu biznesowego często nie jest omawiany jako całość.
Typowe konsekwencje podejścia obszarowego
Taki sposób prowadzenia analizy bardzo często prowadzi do problemów, które ujawniają się dopiero w kolejnych etapach projektu.
- Silosy informacyjne: Każdy zespół koncentruje się przede wszystkim na własnym obszarze odpowiedzialności. Powoduje to powstawanie lokalnych optymalizacji, które nie zawsze wspierają cały proces biznesowy.
- Wielokrotne omawianie tych samych zagadnień: Tematy dotyczące kilku obszarów organizacji wracają podczas kolejnych warsztatów. Te same wymagania bywają analizowane wielokrotnie, często z różnych perspektyw i przy użyciu odmiennej terminologii.
- Niespójne wymagania: Różne zespoły mogą zgłaszać oczekiwania, które wzajemnie się wykluczają lub powodują niezamierzone skutki w innych częściach organizacji. Brak wspólnego kontekstu procesowego utrudnia szybkie wykrycie takich zależności.
- Luki pomiędzy obszarami: Najwięcej problemów zwykle pojawia się na styku działów i modułów systemu. To właśnie tam znajdują się przekazania odpowiedzialności, wyjątki procesowe i integracje, które najłatwiej przeoczyć podczas analizy prowadzonej w silosach.
- Trudności w analizie wpływu zmian: Jeżeli wymagania są dokumentowane wyłącznie w podziale na moduły, bardzo trudno odpowiedzieć na pytanie, które procesy biznesowe zostaną dotknięte przez planowaną zmianę. W konsekwencji rośnie koszt analizy, testów oraz zarządzania zakresem projektu.
Od modułów do procesów
Wraz ze wzrostem złożoności organizacji coraz więcej firm dostrzega, że rzeczywistym przedmiotem wdrożenia nie są moduły systemu ERP, lecz procesy biznesowe, które system ma wspierać. To właśnie one łączą działania różnych działów, tworzą wartość dla klienta i stanowią naturalny sposób opisywania funkcjonowania przedsiębiorstwa.
Dlatego coraz większą popularność zyskuje podejście procesowe, w którym punktem wyjścia analizy nie są finanse, sprzedaż czy magazyn rozpatrywane oddzielnie, lecz pełne procesy end-to-end przebiegające przez całą organizację. To właśnie ono staje się fundamentem nowoczesnych wdrożeń Dynamics 365 i punktem wyjścia do wykorzystania Microsoft Business Process Catalog.
Dlaczego organizacje myślą procesami, a nie modułami?
Jednym z największych paradoksów projektów ERP jest fakt, że wielu partnerów wdrożeniowych nadal organizuje projekty wokół modułów funkcjonalnych systemu, który chcą wdrożyć, podczas gdy ich klienci działają w oparciu o procesy biznesowe. To właśnie procesy decydują o tym, jak firma tworzy wartość dla swoich klientów, realizuje swoje cele operacyjne i osiąga przewagę konkurencyjną.
Rzadko kiedy przedstawiciel biznesu rozpoczyna rozmowę od stwierdzenia:
Chcę usprawnić moduł magazynowy.
Znacznie częściej słyszymy natomiast:
Chcę szybciej realizować zamówienia klientów.
Chcę skrócić czas zakupu materiałów.
Chcę szybciej zamykać miesiąc finansowy.
Chcę zwiększyć terminowość dostaw.
Takie cele nie dotyczą żadnego pojedynczego modułu systemu ERP. Dotyczą całych procesów biznesowych przebiegających przez wiele działów organizacji i angażujących różne funkcjonalności systemu.
Procesy przekraczają granice działów i systemów
Spójrzmy ponownie na proces realizacji zamówienia klienta (w jego podstawowym wariancie). Chociaż w systemie ERP korzystamy podczas jego realizacji z funkcji sprzedaży, magazynu, logistyki czy księgowości, biznes postrzega go jako jeden ciągły proces prowadzący do osiągnięcia konkretnego celu: dostarczenia produktu klientowi i rozliczenia transakcji.
Podobnie wygląda większość kluczowych procesów przedsiębiorstwa:
- Order-to-Cash (O2C) – od przyjęcia zamówienia klienta do otrzymania płatności,
- Source-to-Pay (S2P) – od identyfikacji potrzeby zakupu do rozliczenia dostawcy,
- Plan-to-Produce (P2P) – od planowania produkcji do wytworzenia gotowego produktu,
- Case-to-Resolution (C2R) – od przyjęcia zgłoszenia do rozwiązania problemu,
- Project-to-Profit (P2P) – od planowania i rozpoczęcia projektu do rozliczenia zysku,
- Prospect-to-Quote (P2Q) – od pozyskania szansy sprzedaży do wygenerowania oferty,
- Service-to-Deliver (S2D) – od otrzymania zlecenia serwisowego do realizacji usługi,
A także procesów wspierających pracę, tj.:
- Hire-to-Retire (H2R) – od rekrutacji pracownika do zakończenia współpracy,
- Inventory-to-Deliver (I2D) – od zarządzania zapasem do realizacji wydania i dostawy,
- Record-to-Report (R2R) – od rejestracji zdarzeń gospodarczych do przygotowania sprawozdawczości finansowej,
A na procesach zarządzających pracą kończąc.
Każdy z tych procesów end-to-end obejmuje wiele obszarów organizacji, wielu uczestników oraz szereg funkcji systemowych. Próba ich analizy wyłącznie z perspektywy poszczególnych modułów prowadzi do utraty najważniejszego kontekstu: celu biznesowego, któremu mają służyć.
Proces jako wspólny język biznesu i IT
Podejście procesowe pozwala spojrzeć na organizację w sposób bliższy rzeczywistości biznesowej. Zamiast skupiać się na tym, jak zbudowany jest system, koncentruje się na tym, jak firma działa i jakie rezultaty chce osiągnąć.
To szczególnie istotne podczas wdrożeń ERP, gdzie w jednym projekcie spotykają się przedstawiciele wielu działów biznesowych, konsultanci funkcjonalni, architekci rozwiązań, deweloperzy oraz testerzy. Każda z tych grup posługuje się innym słownictwem i inną perspektywą. Proces biznesowy staje się natomiast wspólnym punktem odniesienia zrozumiałym dla wszystkich uczestników projektu.
Dzięki temu możliwe jest prowadzenie rozmów nie o funkcjach systemu, lecz o rzeczywistych potrzebach organizacji, miernikach efektywności i sposobach osiągania wartości biznesowej.
System ERP jest narzędziem, a nie celem
To właśnie tutaj pojawia się fundamentalna zmiana perspektywy. W podejściu procesowym system ERP przestaje być centralnym elementem projektu. Staje się narzędziem wykorzystywanym w projekcie do realizacji procesów biznesowych.
Oznacza to, że pytanie:
Jakich funkcji potrzebuje dział sprzedaży?
zostaje zastąpione pytaniem:
Jak przebiega proces realizacji zamówienia klienta i w jaki sposób możemy go usprawnić?
Może wydawać się to subtelną różnicą, ale w praktyce zmienia sposób prowadzenia warsztatów, definiowania wymagań, budowania backlogu projektu oraz testowania rozwiązania.
Aby jednak skutecznie wdrożyć takie podejście, potrzebny jest wspólny model referencyjny procesów biznesowych realizowanych w przedsiębiorstwach. W ekosystemie Microsoft Dynamics 365 taką rolę pełni wspomniany już Microsoft Business Process Catalog, który stanowi fundament procesowo zarządzanych projektów ERP.
Microsoft Business Process Catalog – wspólny język projektu
Skoro organizacje działają w oparciu o procesy biznesowe, a nie moduły systemu, pojawia się naturalne pytanie: od czego rozpocząć analizę procesową? Jak upewnić się, że podczas projektu nie pominiemy istotnych obszarów działalności przedsiębiorstwa? W jaki sposób zapewnić, że konsultanci, analitycy, deweloperzy i przedstawiciele biznesu będą posługiwali się tym samym językiem?
Przez wiele lat odpowiedź na te pytania zależała głównie od doświadczenia zespołu wdrożeniowego. Każdy partner wypracowywał własne metody prowadzenia warsztatów, własne wzorce dokumentacji oraz własne listy procesów wykorzystywane podczas analizy. W efekcie jakość i kompletność analizy często zależały od wiedzy konkretnych osób uczestniczących w projekcie.
Microsoft postanowił uporządkować ten obszar, tworząc Microsoft Business Process Catalog (BPC) – referencyjny katalog procesów biznesowych dla aplikacji z rodziny Dynamics 365.
Struktura odzwierciedlająca rzeczywistość biznesową
Business Process Catalog nie jest kolejnym podręcznikiem użytkownika ani dokumentacją funkcjonalności systemu. Jego celem nie jest opisanie poszczególnych ekranów, konfiguracji ani modułów aplikacji. Katalog został zbudowany wokół procesów biznesowych realizowanych przez organizacje. To właśnie proces, a nie funkcjonalność systemu, stanowi podstawową jednostkę organizacji wiedzy.
Business Process Catalog porządkuje wiedzę w sposób odpowiadający funkcjonowaniu przedsiębiorstwa. Poszczególne procesy zostały zgrupowane w logiczne obszary biznesowe i procesy end-to-end, a następnie rozbite na bardziej szczegółowe scenariusze i działania.
Uproszczony model można przedstawić następująco:
Proces end-to-end
↓
Obszar procesowy
↓
Proces biznesowy
↓
Scenariusz biznesowy
Przykładowo, proces Order-to-Cash (O2C) może zostać podzielony na scenariusze związane z rejestracją zamówienia, rezerwacją towaru, kompletacją, wysyłką czy fakturowaniem. Dzięki temu zespół projektowy może analizować zarówno cały proces end-to-end, jak i jego poszczególne elementy.
Przykład rozwinięcia procesu end-to-end Order-to-Cash w obszarze procesowym Manage sales order odpowiedzialnym za zarządzanie zamówieniami sprzedaży:
Gotowy punkt startowy dla warsztatów
Jedną z największych zalet katalogu jest możliwość wykorzystania go jako listy referencyjnej podczas analizy przedwdrożeniowej.
Zamiast rozpoczynać projekt od „czystej kartki”, konsultanci wykorzystują gotowy zbiór procesów i scenariuszy przygotowanych przez Microsoft, ewentualnie rozszerzony i dostosowany do charakterystyki danego klienta oraz zakresu projektu. Pozwala to uporządkować warsztaty i znacząco zmniejsza ryzyko pominięcia ważnych obszarów działalności klienta.
W praktyce analiza przestaje polegać na odkrywaniu procesów od podstaw. Zamiast tego koncentruje się na znalezieniu odpowiedzi na pytania:
- które procesy są realizowane przez organizację,
- które z nich odpowiadają standardowi systemu,
- gdzie występują odstępstwa od modelu referencyjnego,
- jakie wymagania wynikają ze specyfiki przedsiębiorstwa.
Takie podejście znacząco usprawnia analizę fit-gap oraz pozwala szybciej identyfikować obszary wymagające konfiguracji lub rozbudowy rozwiązania. W projektach Dynamics 365 Business Central umożliwia to szybsze określenie, które scenariusze mogą zostać pokryte standardową funkcjonalnością systemu, a które będą wymagały konfiguracji, rozszerzeń AL lub dodatkowych aplikacji ISV.
Wspólna baza wiedzy dla całego projektu
Korzyści nie kończą się jednak na etapie analizy.
Największa wartość Business Process Catalog ujawnia się wtedy, gdy procesy stają się wspólnym punktem odniesienia dla wszystkich uczestników projektu. Zarówno biznes, konsultanci, architekci, deweloperzy, jak i testerzy mogą odwoływać się do tych samych procesów i scenariuszy biznesowych.
Proces przestaje być jedynie elementem dokumentacji. Staje się podstawową jednostką organizacji wiedzy o projekcie.
To właśnie w tym miejscu pojawia się możliwość zbudowania pełnej ścieżki traceability pomiędzy procesem biznesowym, wymaganiem, zadaniem implementacyjnym w systemie i testem. Business Process Catalog dostarcza fundament takiego podejścia, a narzędzia takie jak Azure DevOps pozwalają przenieść je na codzienną praktykę zarządzania projektem.
Od procesu biznesowego do wdrożonej funkcjonalności – pełna traceability projektu
Samo zidentyfikowanie procesów biznesowych nie gwarantuje jeszcze sukcesu projektu. W wielu organizacjach po zakończeniu analizy powstaje obszerna dokumentacja procesowa, podczas gdy backlog projektu jest rozwijany niezależnie w narzędziach do zarządzania pracą. Z czasem związek między jednym a drugim staje się coraz słabszy.
W efekcie uczestnicy projektu zaczynają zadawać pytania, na które trudno szybko znaleźć odpowiedź:
Dlaczego realizujemy tę zmianę?
Którego procesu biznesowego dotyczy to wymaganie?
Czy wszystkie wymagania dotyczące procesu zostały już zaimplementowane?
Czy przetestowaliśmy cały proces biznesowy? Jaki będzie wpływ planowanej zmiany na funkcjonowanie organizacji?
Problemy te zwykle nie wynikają z braku dokumentacji ani narzędzi. Źródłem jest brak spójnego powiązania między procesami biznesowymi, wymaganiami, backlogiem projektu i testami.
Właśnie tutaj ujawnia się największa wartość połączenia Microsoft Business Process Catalog i Azure DevOps.
Proces jako fundament projektu
W podejściu procesowym proces biznesowy nie kończy swojego życia po warsztatach analitycznych. Staje się podstawową jednostką organizacyjną całego projektu.
Business Process Catalog dostarcza gotową strukturę procesów i scenariuszy biznesowych, natomiast Azure DevOps pozwala wykorzystać ją do budowy backlogu wdrożenia. W projektach Dynamics 365 Business Central backlog taki obejmuje zarówno konfigurację standardowych funkcjonalności systemu jak i rozwój rozszerzeń tworzonych w języku AL. Zamiast organizować projekt wokół modułów systemu lub list funkcjonalności, można organizować go wokół procesów realizowanych w organizacji.
Przykładowo, proces Order-to-Cash może stać się punktem wyjścia do identyfikacji wszystkich wymagań związanych z obsługą zamówień, gospodarką magazynową, wysyłką i fakturowaniem. Każde wymaganie zostaje automatycznie osadzone w kontekście konkretnego procesu biznesowego.
Struktura procesowa staje się fundamentem budowy całego projektu w Azure DevOps, a nie tylko dokumentacją, która miałaby trafić „do szuflady” zaraz po zakończeniu analizy. Dzięki temu zarówno biznes, jak i zespół projektowy cały czas pracują na wspólnym modelu organizującym wiedzę o projekcie.
Czym jest traceability?
Wykorzystanie Business Process Catalog i Azure DevOps pozwala budować pełną ścieżkę traceability, czyli możliwość prześledzenia każdego elementu rozwiązania od jego biznesowego uzasadnienia aż po wdrożoną funkcjonalność.
Dla każdej zmiany w systemie można odpowiedzieć na pytanie:
Który proces biznesowy wymagał jej realizacji?
Jednocześnie dla każdego procesu można łatwo zweryfikować:
Jakie wymagania zostały zdefiniowane, jakie prace wykonano i czy cały proces został przetestowany?
Proces biznesowy staje się więc swoistym „wątkiem przewodnim”, który łączy wszystkie etapy realizacji projektu.
Od procesu do testu
Połączenie Business Process Catalog i Azure DevOps pozwala utrzymać relacje pomiędzy wszystkimi elementami projektu:
Proces biznesowy
↓
Scenariusz biznesowy
↓
Wymaganie biznesowe
↓
User Story
↓
Task
↓
Implementacja
↓
Przypadek testowy
↓
Akceptacja biznesowa
Takie powiązania tworzą pełną ścieżkę traceability, utrzymywaną przez cały cykl życia rozwiązania.
W przypadku Dynamics 365 Business Central poszczególne elementy ścieżki mogą być następnie powiązane z konfiguracją systemu, rozszerzeniami AL, przypadkami testowymi oraz artefaktami zarządzanymi w Azure DevOps.
Proces jako „cyfrowy wątek” projektu
W nowoczesnych organizacjach coraz częściej mówi się o koncepcji digital thread – cyfrowego wątku łączącego wszystkie informacje związane z produktem, usługą lub procesem.
W przypadku projektów ERP takim cyfrowym wątkiem może stać się właśnie proces biznesowy. Łączy potrzeby biznesowe, analizę, wymagania, backlog, konfigurację systemu, development, testy oraz późniejsze utrzymanie rozwiązania.
Microsoft Business Process Catalog dostarcza strukturę umożliwiającą budowę takiego modelu, a Azure DevOps pozwala utrzymać te powiązania przez cały cykl życia projektu.
W efekcie wdrożenie ERP przestaje być zbiorem niezależnych zadań realizowanych przez różne zespoły. Staje się spójnym przedsięwzięciem skoncentrowanym na usprawnianiu procesów biznesowych oraz dostarczaniu organizacji mierzalnej wartości.
Praktyczny przykład: proces Order-to-Cash w projekcie Dynamics 365 Business Central
Teoretyczne założenia podejścia procesowego najlepiej zrozumieć na konkretnym przykładzie. Za przykład ponownie weźmy proces Order-to-Cash, czyli jeden z najważniejszych procesów realizowanych przez większość organizacji handlowych i produkcyjnych.
Proces ten obejmuje wszystkie działania od momentu złożenia zamówienia przez klienta aż do otrzymania płatności za dostarczony towar lub usługę. W zależności od specyfiki przedsiębiorstwa może angażować sprzedaż, magazyn, logistykę, obsługę klienta oraz dział finansowy. A w najbardziej złożonych przypadkach, gdy stan zapasów jest niewystarczający do wydania, Order-to-Cash jest źródłem uruchomienia procesów zakupowych – działu zaopatrzenia lub produkcji. Zostańmy jednak przy podstawowym zakresie procesu end-to-end.
W tradycyjnym projekcie ERP poszczególne elementy procesu byłyby analizowane podczas wielu różnych warsztatów:
- sprzedaż omawiałaby obsługę zamówień,
- magazyn zarządzanie zapasami i kompletację,
- logistyka proces wysyłki,
- finanse fakturowanie i rozliczenia.
Każdy obszar byłby dokumentowany osobno, a zależności między nimi często pozostawałyby ukryte.
W podejściu procesowym punktem wyjścia staje się cały proces Order-to-Cash, a nie jego poszczególne fragmenty.
Krok 1. Identyfikacja procesu w Business Process Catalog
Projekt rozpoczyna się od wyboru odpowiednich procesów i scenariuszy z Microsoft Business Process Catalog.
Dla procesu Order-to-Cash mogą zostać zidentyfikowane między innymi następujące scenariusze:
- rejestracja zamówienia klienta,
- weryfikacja dostępności towaru,
- rezerwacja zapasu,
- kompletacja zamówienia,
- wysyłka towaru,
- fakturowanie klienta,
- rozliczenie płatności.
Już na tym etapie zespół projektowy dysponuje pełnym obrazem procesu biznesowego, który będzie wspierany przez system.
Krok 2. Analiza fit-gap
Podczas warsztatów z klientem każdy scenariusz jest analizowany pod kątem zgodności ze standardem systemu, który jest wdrażany. W przypadku Dynamics 365 Business Central analiza fit-gap pozwala określić, które scenariusze mogą zostać obsłużone przez standardowe funkcjonalności aplikacji, które wymagają odpowiedniej konfiguracji, a które będą wymagały rozbudowy systemu w postaci rozszerzeń AL lub wykorzystania rozwiązań partnerskich dostępnych na AppSource.
Przykładowo może się okazać, że:
- standardowa obsługa zamówień spełnia wymagania klienta,
- proces fakturowania nie wymaga zmian,
- konieczne jest rozszerzenie logiki automatycznej rezerwacji zapasu.
W efekcie analiza nie koncentruje się na poszczególnych modułach systemu, lecz na scenariuszach biznesowych, które składają się na proces Order-to-Cash.
Krok 3. Budowa backlogu projektu
Zidentyfikowane wymagania trafiają następnie do Azure DevOps.
Dzięki zachowaniu powiązania z procesem biznesowym struktura backlogu może wyglądać następująco:
End-to-end
└── Order-to-cash
Process area
└── Manage sales orders
Process
└── Allocate inventory to sales orders
User Story
└── Automatically allocate inventory to orders in Dynamics 365 Business Central
Tasks
├── Configure item reservation policies
├── Develop AL extension
└── Prepare test scenarios
Każdy element backlogu posiada jednoznaczne powiązanie z procesem biznesowym, z którego wynika.
Krok 4. Realizacja i testowanie
W trakcie implementacji zespół może łatwo prześledzić, które wymagania wspierają konkretny proces.
Testerzy nie weryfikują wyłącznie działania pojedynczej funkcji systemu. Zamiast tego przygotowują scenariusze odzwierciedlające rzeczywisty przebieg procesu biznesowego uwzględniając po drodze wszystkie zidentyfikowane wymagania i wprowadzone zmiany:
- utworzenie zamówienia,
- automatyczna rezerwacja zapasu wraz ze zmianami,
- kompletacja,
- wysyłka,
- fakturowanie,
- rozliczenie płatności.
Dzięki temu testowany jest cały proces end-to-end, a nie jedynie poszczególne funkcjonalności Business Central z osobna.
Krok 5. Zarządzanie zmianą po uruchomieniu systemu
Ogromna wartość podejścia procesowego ujawnia się często dopiero po wdrożeniu systemu.
Załóżmy, że po kilku miesiącach klient zgłasza potrzebę zmiany sposobu rezerwacji zapasu. W tradycyjnym projekcie konieczne byłoby przeanalizowanie dokumentacji, backlogu oraz istniejących modyfikacji w celu ustalenia, czego dotyczy zmiana i jakie może mieć konsekwencje.
Przy zachowaniu pełnej traceability można natychmiast określić:
- którego procesu dotyczy zmiana,
- które wymagania biznesowe zostaną zmodyfikowane,
- jakie rozszerzenia systemu wymagają aktualizacji,
- które przypadki testowe należy ponownie wykonać.
Znacząco ogranicza to ryzyko oraz koszt dalszego rozwoju rozwiązania.
Nie tylko Order-to-Cash
Order-to-Cash to tylko jeden z wielu procesów opisanych w Business Process Catalog. Dokładnie takie samo podejście można zastosować dla pozostałych procesów end-to-end: kluczowych, wspierających czy zarządzających.
Niezależnie od obszaru biznesowego logika pozostaje taka sama: proces biznesowy staje się podstawową jednostką organizacji projektu, a Business Process Catalog i Azure DevOps tworzą wspólnie mechanizm pozwalający zachować pełną traceability od warsztatu analitycznego, aż po wdrożoną funkcjonalność i testy akceptacyjne.
Czy Microsoft Business Process Catalog jest tylko dla Business Central?
Choć w tym artykule posłużyłem się przykładami z projektów Microsoft Dynamics 365 Business Central, sam Microsoft Business Process Catalog nie został stworzony wyłącznie z myślą o jednym rozwiązaniu ERP.
Katalog jest częścią szerszego podejścia Microsoft do modelowania procesów biznesowych w całym ekosystemie Dynamics 365. Obejmuje procesy realizowane w obszarach finansów, sprzedaży, zakupów, produkcji, logistyki, obsługi klienta czy zarządzania zasobami ludzkimi. Dzięki temu może wspierać zarówno wdrożenia systemów ERP, jak i rozwiązań CRM.
Możliwość wykorzystania jednego modelu procesowego w różnych obszarach organizacji staje się szczególnie istotna w przedsiębiorstwach realizujących szerszą transformację cyfrową. Proces obsługi klienta może rozpoczynać się w systemie CRM, być kontynuowany w rozwiązaniu ERP, a następnie wykorzystywać usługi Power Platform czy rozwiązania analityczne Microsoft Fabric. Z perspektywy biznesu nadal pozostaje jednak jednym procesem.
To właśnie dlatego procesowe podejście do zarządzania projektami zyskuje coraz większe znaczenie. Pozwala ono oderwać się od myślenia kategoriami aplikacji i skupić na tym, jak organizacja funkcjonuje jako całość.
Jednocześnie to właśnie projekty ERP oferują zwykle największy potencjał wykorzystania Business Process Catalog. Procesy kluczowe end-to-end obejmują wiele działów, dużą liczbę użytkowników oraz skomplikowane zależności biznesowe. W takich środowiskach korzyści wynikające z procesowego zarządzania wymaganiami i zachowania pełnej traceability są szczególnie widoczne.
Niezależnie jednak od tego, czy organizacja wdraża Business Central, Dynamics 365 Finance, Supply Chain Management czy rozwiązania Customer Engagement, podstawowa zasada pozostaje taka sama: proces biznesowy powinien być punktem odniesienia dla całego projektu, a system informatyczny jedynie narzędziem wspierającym jego realizację.
Korzyści podejścia procesowego dla klienta i zespołu projektowego
Podejście procesowe nie jest jedynie innym sposobem organizacji warsztatów czy dokumentacji projektowej. Jego największą wartością jest stworzenie wspólnego modelu pracy, który obejmuje cały cykl życia wdrożenia ERP – od pierwszych warsztatów analitycznych aż po rozwój rozwiązania po uruchomieniu produkcyjnym.
W praktyce oznacza to odejście od myślenia przez pryzmat modułów systemu na rzecz koncentracji na procesach, które tworzą rzeczywistą wartość biznesową dla organizacji.
Korzyści dla klienta
Z perspektywy klienta największą zaletą podejścia procesowego jest lepsze powiązanie projektu z rzeczywistymi celami biznesowymi. Warsztaty, wymagania i backlog projektu są organizowane wokół procesów realizowanych przez przedsiębiorstwo, dzięki czemu łatwiej zachować koncentrację na efektach biznesowych, a nie wyłącznie na funkcjonalnościach systemu.
Klienci zyskują również większą przejrzystość projektu. Mogą łatwo odpowiedzieć na pytania:
- które procesy są objęte zakresem wdrożenia,
- jaki jest poziom zaawansowania prac dla konkretnych procesów,
- które wymagania zostały już zrealizowane,
- jakie procesy zostaną objęte planowanymi zmianami.
Dzięki zachowaniu pełnej traceability znacznie łatwiejsza staje się także ocena wpływu nowych wymagań na harmonogram, zakres i budżet projektu. Istotną korzyścią jest również ograniczenie ryzyka pominięcia istotnych scenariuszy biznesowych. Wykorzystanie Microsoft Business Process Catalog jako punktu wyjścia do analizy pozwala oprzeć projekt na sprawdzonym modelu referencyjnym zamiast budować całą strukturę procesową od podstaw.
Korzyści dla zespołu wdrożeniowego
Podejście procesowe przynosi równie duże korzyści zespołowi realizującemu projekt.
Konsultanci funkcjonalni zyskują uporządkowaną strukturę prowadzenia warsztatów i dokumentowania wymagań. Architekci mogą łatwiej analizować wpływ zmian na całe procesy biznesowe, a nie wyłącznie na pojedyncze moduły systemu.
Dla deweloperów szczególnie istotne staje się zachowanie kontekstu biznesowego. Każda realizowana zmiana ma uzasadnienie wynikające z konkretnego procesu i wymagań biznesowych. Znacznie ułatwia to projektowanie rozwiązań oraz późniejsze utrzymanie systemu.
Testerzy natomiast mogą budować przypadki testowe oparte na rzeczywistych scenariuszach biznesowych. W rezultacie testowany jest cały proces end-to-end, a nie wyłącznie poprawność działania pojedynczej funkcji systemowej.
Korzyści w perspektywie długoterminowej
Warto pamiętać, że wdrożenie ERP rzadko kończy się w momencie uruchomienia produkcyjnego. Większość organizacji rozwija swoje rozwiązania przez wiele lat, dostosowując je do nowych wymagań biznesowych, zmian organizacyjnych oraz rosnącej skali działalności.
W takich sytuacjach szczególnego znaczenia nabiera możliwość szybkiego zrozumienia, dlaczego dana funkcjonalność została wdrożona i jaki proces biznesowy wspiera.
Jeżeli projekt został zrealizowany z zachowaniem pełnej traceability, analiza wpływu zmian staje się znacznie prostsza. Można szybko określić:
- które procesy zostaną objęte zmianą,
- jakie wymagania należy zaktualizować,
- które rozszerzenia systemu wymagają modyfikacji,
- jakie testy należy ponownie przeprowadzić.
W efekcie organizacja nie tylko skuteczniej realizuje samo wdrożenie, ale również ogranicza koszty późniejszego utrzymania i rozwoju rozwiązania.
Porównanie podejścia tradycyjnego i procesowego
| Obszar | Podejście tradycyjne (modułowe) | Podejście procesowe |
| Punkt wyjścia analizy | Moduły i obszary funkcjonalne | Procesy biznesowe end-to-end |
| Organizacja warsztatów | Według działów i modułów systemu | Według procesów biznesowych |
| Perspektywa biznesowa | Lokalna dla poszczególnych działów | Całościowa dla organizacji |
| Dokumentacja | Rozproszona pomiędzy obszarami | Oparta na wspólnym modelu procesów |
| Identyfikacja wymagań | Skupiona na funkcjonalnościach | Skupiona na rezultatach biznesowych |
| Zarządzanie zakresem | Trudniejsza analiza wpływu zmian | Łatwiejsza analiza wpływu na procesy |
| Testowanie | Weryfikacja funkcji systemu | Weryfikacja procesów end-to-end |
| Traceability | Ograniczona lub częściowa | Pełna od procesu do testów |
| Zarządzanie zmianą | Wysoki koszt analizy zależności | Szybka identyfikacja wpływu zmian |
| Rozwój po Go-Live | Wiedza rozproszona w dokumentach | Powiązanie zmian z procesami biznesowymi |
| Wartość dla klienta | Koncentracja na systemie | Koncentracja na realizacji celów biznesowych |
Proces jako fundament nowoczesnych projektów ERP
Rosnąca złożoność organizacji sprawia, że coraz trudniej skutecznie realizować projekty ERP wyłącznie w oparciu o strukturę systemu. Procesy biznesowe stają się naturalnym sposobem organizacji wiedzy, zarządzania wymaganiami oraz monitorowania postępu wdrożenia.
Połączenie Microsoft Business Process Catalog i Azure DevOps pozwala wykorzystać ten sposób myślenia nie tylko podczas warsztatów analitycznych, ale przez cały cykl życia projektu. Dzięki temu proces biznesowy staje się wspólnym punktem odniesienia dla biznesu, konsultantów, deweloperów i testerów, a wdrożenie ERP przestaje być projektem konfiguracji modułów systemu i staje się projektem transformacji procesów biznesowych.
Microsoft Dynamics 365 CRM
Twórz spersonalizowane doświadczenia dla swoich klientów dzięki zaawansowanym funkcjom Dynamics 365 Customer Engagement
Oferta M365Podsumowanie: od wdrażania systemów do usprawniania procesów
Przez wiele lat projekty ERP były prowadzone przede wszystkim w oparciu o strukturę systemu. Analiza wymagań, dokumentacja, backlog projektu i testy organizowane były wokół modułów oraz obszarów funkcjonalnych. Takie podejście sprawdzało się w czasach mniej złożonych organizacji, jednak coraz częściej okazuje się niewystarczające w środowisku, w którym procesy biznesowe przekraczają granice działów, systemów i zespołów.
Podejście procesowe odwraca tę perspektywę. Punktem wyjścia staje się nie moduł systemu, lecz sposób działania przedsiębiorstwa. W centrum projektu znajdują się procesy biznesowe realizujące konkretne cele organizacji, takie jak obsługa klientów, realizacja zakupów, produkcja czy raportowanie finansowe.
Microsoft Business Process Catalog dostarcza wspólny model referencyjny umożliwiający identyfikację i analizę tych procesów. Z kolei Azure DevOps pozwala powiązać procesy z wymaganiami, backlogiem projektu, pracami deweloperskimi oraz testami. Efektem jest pełna traceability, dzięki której możliwe staje się prześledzenie każdej funkcjonalności od potrzeby biznesowej aż po wdrożone rozwiązanie.
Korzyści takiego podejścia wykraczają daleko poza sam etap analizy. Lepsza kontrola nad zakresem projektu, łatwiejsze zarządzanie zmianą, bardziej efektywne testowanie oraz zachowanie wiedzy o procesach biznesowych po uruchomieniu systemu sprawiają, że proces staje się naturalnym „kręgosłupem” całego wdrożenia.
Największą wartością Microsoft Business Process Catalog nie jest więc sam katalog procesów. Jest nią zmiana sposobu myślenia o projektach Dynamics 365 oraz wdrożeniach ERP w ogóle. Zmiana, w której celem przestaje być uruchomienie kolejnych modułów systemu, a staje się usprawnienie procesów biznesowych tworzących wartość dla organizacji.
Bo ostatecznie sukces projektu ERP nie polega na tym, że działają sprzedaż, magazyn czy księgowość. Sukces polega na tym, że firma szybciej obsługuje klientów, sprawniej realizuje zamówienia i skuteczniej osiąga swoje cele biznesowe. A to już język procesów, a nie modułów.
Zostaw komentarz