Artykuły

BPMstandard.pl używa cookies.

Brak zmiany ustawienia przeglądarki oznacza Twoją zgodę.

Zrozumiałem
15Mar2016

Modelowanie procesów biznesowych AS IS i TO BE

asis tobe bpmstandardTechniki modelowania procesów są bardzo ogólne. Posługują się pojęciem „zadania” lub „czynności”, lecz nie precyzują, jak złożona lub jak prosta ta czynność powinna być. Dobre będą więc zarówno czynności tak złożone, jak „Przeprowadzenie przetargu”, jak i proste, takie jak „Wprowadzenie numeru NIP”. Dlatego przed przystąpieniem do modelowania niezwykle ważne jest określenie poziomu szczegółowości modeli, jakie zamierzamy opracować. A ten poziom szczegółowości powinien wynikać z celu, dla którego opracowujemy modele.

Najczęstszymi przyczynami, dla których modelujemy procesy biznesowe są:

  • udokumentowanie procesów wykonywanych w organizacji np. w celu precyzyjnego określenia odpowiedzialności pracowników i opracowania kart stanowisk pracy,
  • optymalizacja procesów biznesowych,
  • wdrożenie systemu informatycznego wspierającego lub automatyzującego procesy biznesowe w organizacji.

Jeśli naszym celem jest wyłącznie udokumentowanie procesów na wewnętrzne potrzeby organizacji, nasz model będzie opisywał procesy rzeczywiste, tak jak one faktycznie przebiegają, ze wszystkimi elementami nadmiarowymi, nieefektywnymi, itp. Taki model procesów nazywa się zwykle „as-is”, czyli „takie jakie są”.

W pozostałych przypadkach (optymalizacja, wdrożenie systemu) model procesów „as-is” jest jedynie punktem wyjścia do opracowania docelowego modelu procesów, zwanego „to-be”. W przypadku optymalizacji, docelowy model będzie opisywał procesy zoptymalizowane, a więc pozbawione czynności nadmiarowych, „wąskich gardeł”, itp. W przypadku wdrożenia systemu informatycznego, docelowy model pokaże proces realizowany przy wykorzystaniu tego systemu. W większości przypadków będzie on inny niż proces „as-is”, bo przecież system ma wyeliminować pewne czynności ręczne i usprawnić cały proces. Jest to szczególnie widoczne w procesach związanych z obiegiem korespondencji, gdzie w ramach wdrożenia rezygnujemy z korespondencji papierowej na rzecz elektronicznej.

Przykład

Na Rys. 1 jest przedstawiony proces obsługi zgłoszeń problemów, kierowanych przez klientów do firmy produkującej oprogramowanie. Klienci nie korzystają z żadnego systemu do obsługi zgłoszeń, lecz kontaktują się ze swoimi opiekunami telefonicznie lub poczta elektroniczną. Dopiero opiekun klienta – jeśli nie jest w stanie pomóc samemu – przekazuje zgłoszenie do help desku. Jeśli druga linia wsparcia nie jest w stanie rozwiązać problemu, może skonsultować się z produkcją oprogramowania. Jeśli rozwiązanie problemu wymaga poprawienia oprogramowania, 2. linia wsparcia zamawia odpowiednią poprawkę. Cały proces może być realizowany bez wsparcia systemu informatycznego, np. przy pomocy poczty elektronicznej.

proces obslugi zgloszen asis

Rys. 1. Proces  obsługi zgłoszeń "as-is"

Jeśli producent oprogramowania planuje wdrożenie systemu do obsługi zgłoszeń klientów, powinien rozważyć jednocześnie pewną optymalizację tego procesu. Załóżmy, że system umożliwi przekazywanie zgłoszeń przez pocztę elektroniczną wysyłaną na specjalny adres e-mail, obsługiwany przez system. Zgłoszenie wysłane przez klienta na ten adres może więc trafić bezpośrednio do 1. linii wsparcia, co pozwoli na rezygnację z pośrednictwa opiekuna klienta. Dzięki temu zmniejszy się obciążenie opiekunów klienta. Jednocześnie zwiększy sie obciążenie 1. linii wsparcia, ponieważ będzie musiała ona rozwiązywać także proste zgłoszenia, dotychczas rozwiązywane samodzielnie przez opiekunów. Organizacyjnie można to rozwiązać np. przenosząc jednego lub kilku opiekunów klienta do obsługi 1. linii wsparcia.

Na Rys. 2 jest przedstawiony proces „to-be”, obejmujący opisaną optymalizację.

proces obslugi zgloszen tobe

Rys. 2. Proces obsługi zgłoszeń  – „to-be”

 

Szymon Zioło – główny konsultant w RedPill

szymon zioloKierownik projektów i analityk systemów IT z 15-letnim doświadczeniem. Specjalizuje się we wdrażaniu systemów przepływu pracy i obiegu dokumentów. Opracowuje specyfikacje wymagań i opisy przedmiotu zamówienia. Doradza w projektach IT zarówno po stronie zamawiającego, jak i po stronie wykonawcy. Prowadzi szkolenia z modelowania procesów w notacji BPMN, modelowania w języku UML oraz XML-a i technologii pokrewnych.

 

logo red pill