Archive for the ‘Reengineering (BPR)’ Category

h1

Pytania o kroki procesu ręcznego

Październik 23, 2015

Podczas wizyty w hotelu, musiałem wypożyczyć żelazko. Udałem się do recepcji. Pytam, czy jest taka możliwość? Padła odpowiedź, że tak, ale trzeba zapłacić depozyt. Powiedziałem ok. Jak się okazało, najpierw trzeba było zapłacić, podać numer pokoju, poczekać na odnotowanie w papierach wypożyczenia żelazka, założenie oznaczenia na żelazku Potem przy zwrocie  żelazka trzeba było złożyć podpis, że nastąpił zwrot depozytu i żelazka. Natomiast przy oddawaniu klucza  sprawdzają czy nastąpiło rozliczenie pokoju. Dlaczego wypożyczenia żelazka i jego zwrotu nie odnotują w systemie? Podczas wymeldowania, można byłoby sprawdzić czy nastąpił zwrot żelazka.

Opisana zmiana to przejście od procesu w pełni ręcznego (obecnie stosowanego, tzw. as-is, oznaczonego na diagramie) do procesu wspieranego systemowo lub zautomatyzowanego (docelowego, tzw. to-be, oznaczonego na diagramie). System mógłby informować przy zwrocie klucza, że nie zostało ono zwrócone.

zelazko2

Podczas wykonywania takiej zmiany, zaczynamy od analizy bieżącego procesu, jego kroków. Można np. :

Można także zadać pytania, które sugeruje autor artykułu “Avoid Pains Converting a Manual to an Automated Process”:

  • Dlaczego dany krok jest ważny dla procesu?
    Np. na powyższym diagramie jest to powiązanie pożyczonego żelazka i numeru pokoju. Jest to wykonywane poprzez wpis do rejestru. Pozwala to zidentyfikować, gdzie są żelazka, kto jeszcze ich nie zwrócił.

  • Co się stanie jeżeli nie wykonamy danego kroku?
    Np. w powyższym procesie możemy nie pobrać depozytu. Ułatwia to obsługę klienta, nie musi mieć przygotowanej gotówki.

  • Czy miałoby sens, gdyby inny uczestnik procesu go wykonał?
    np.  zamiast ręcznego sprawdzania czy zwrócono żelazko, kontrola wykonywana przez system. na diagramie tego elementu nie oznaczono.

  • Czy istnieją procedury lub regulacje, których wymaga dany krok do wypełnienia przez tego uczestnika?
    W powyższym przypadku, gdy spytałem, dlaczego tyle formalności (ponieważ wystąpiła sytuacja, że gość hotelu nie zwrócił żelazka), odpowiedź, którą usłuszałem mogłem sobie wyobrazić – każą to robimy (czyli jest jakaś procedura).

  • Jeżeli procedury decydują o pełnym wykonaniu kroku, czy mogą zostać zmodyfikowane?
    Przenesienie działań do systemu, będzie wymagać zmiany procedury. Będą wykonywane inne kroki.

  • Jeżeli krok zostanie zautomatyzowany, co jeszcze musi zostać wykonane, aby mieć pewność, że krok jest poprawnie zakończony? Jest to uzależnione od zastosowanego rozwiązania.

Odpowiedź na pierwsze pytanie, to tak naprawdę określenie czego oczekujemy od procesu i czy obecny proces spełnia nasze oczekiwania. Wykonywanie procesu w takiej formie, bez zastanowienia się, bo tak mówią procedury, można powodować zdziwienie uczestników (=klientów) procesu. Takie zdziwienie wyraziłem.

Reklamy
h1

Zwinne modelowanie?

Listopad 24, 2012

Dzisiaj chciałbym skomentować jeden z artukułów na stronie 4PM.pl. Niestety mechanizmy dostępne na stronie nie pozwalają na komentarze i wymianę doświadczeń czytelników bezpośrednio pod artykułem. Wystarczyłoby dodać opcję – podyskutuj o artykule na forum. To tak przy okazji. Przejdźmy jednak do sedna.

Autor w artykule „Zwinne modelowanie procesów biznesowych w trzech krokach”  przedstawia następujące kroki zwinnego modelowania:

  • Krok 1 – Szacowanie potrzeb organizacji
  • Krok 2 – Identyfikacja procesów biznesowych
  • Krok 3 – Uszczegółowienie procesu biznesowego

Szczerze mówiąc treść artykułu nie przekonuje mnie, że jest to zwinne (agile) modelowanie. Autor wskazuje o konieczności wykonywania iteracji w analizie, pomijaniu kwestii, które nie przyczyniają się do realizacji celu analizy. Tak jak cel pierwszego kroku jest jak najbardziej zrozumiały, gdy potrzebne jest określenie obszaru zmian, podobnie jak przypadku benchmarkingu procesów czy reinżynierii procesów biznesowych, to kolejne punkty wydają mi się niekompletne.

Po pierwsze, moim zdaniem brakuje wskazania, że przy określaniu potrzeb czy identyfikacji procesów, przed podejściem do ich opisu, sprawdzamy jaki jest stan obecny organizacji i jej procesów. Warto dodać element identyfikacji dojrzałości procesowej organizacji, tego, czy procesy są opisane, czy celem jest zmiana istniejących procesów czy ich całkowita przebudowa. Od tego zależy co tak naprawdę wykonamy w kolejnych krokach.

Pod drugie, brakuje określenia od której strony patrzymy na procesy – od wewnątrz organizacji czy do zewnątrz organizacji.

Po trzecie, organizacja może dysponować już tzw. opisem organizacji, jeżeli ma wdrożone pewne praktyki dotyczące zarządzania procesowego czy standard ISO.

Po czwarte, interesariusze powinni uczestniczyć od początku procesu w analizie biznesu. Myślę, że poszczególne etapy powinny być w jakiś sposób przedstawiane interesariuszom, co często występuje w projektach zwinnych. Podobnie cząstkowe analizy, czy kierunek zmian i budowy modelu jest słuszny i akceptowalny, także powinien zostać potwierdzony z interesariuszami. Oddawanie do akceptacji na koniec wiąże się z ryzykiem braku akceptacji i poniesienia wielu nakładów na analizę, która nie sprostała oczekiwaniom.

Myślę, że dodanie kilku dodatkowych elementów do tego „zwinnego” modelowania, mogłoby być naprawdę zgodne z ideą, jak jest modelowanie zwinne rozumiane. Na powyższym diagramie do kroków wynikających z artykułu (na niebiesko) dodałem kilka dodatkowych (na zielono) wskazanych powyżej.

h1

Tempo realizacji reengineeringu

Listopad 15, 2012

Wielokrotnie we wpisach skupiałem się na tematyce reinżynierii procesów biznesowych (ang. Business Process Reengineering – BPR). Zarówno w kontekście etapów realizacji, ryzyk, problemów czy komunikacji z uczestnikami procesu jak i pracownikami zmienianej organizacji. Zmiana procesów biznesowych jest często realizacją konkretnego przedsięwzięcia projektowego. Zastanówmy się jakie cechy ma taki projekt.

Wychodząc z trójkąta ograniczeń projektowych (czas, budżet, zakres). Pierwsze kryterium to czas – tak naprawdę nie jest on miarą sukcesu dla takiego projektu. Ważniejsze niż czas realizacji jest to w jakiej formie i z jakimi skutkami taka zmiana zostanie przeprowadzona. Spiesząc się można zapomnieć o uczestnikach procesu, o tym co mają do powiedzenia i bardzo łatwo można napotkać opór przeciwko zmianie. Może także umknąć jakiś szczegół procesu. Tworzone są docelowe rozwiązania i tak naprawdę od celu i zakresu zmiany zależy w jaki sposób zostanie ona przeprowadzona i ile potrwa.

Realizacja takiego projektu wymaga stopniowych kroków, najpierw diagnoza organizacji (identyfikacja procesów, analiza as-is na diagramie), potem przystąpienie do określania zmian (Propozycja to-be na diagramie) i ich impementacji (Implementacja). Konieczne jest dokładne analizowanie wszystkich sygnałów o problemach. Są to projekty drogie. Jeżeli natomiast chodzi o zakres projektu, to jest to najważniejszy element – konieczne jest dokładne określenie co i jak chcemy zmienić, zarówno w zakresie obszaru zmian, rodzaju procesów (główne, pomocnicze), .dostosowania struktury organizacyjnej, jednostek funkcjonalnej oraz obecnego działania organizacji. Realia w skrócony sposób poszczególnych części procesu obrazuje powyższy diagram.

Zgodnie z metodologią podejścia do projektów, zaproponowaną przez Aaron J. Shenhar , Dvir Dov, wyróżniamy projekty zwykłe, szybkie/konkurencyjne, krytyczne w czasie oraz błyskawiczne. Wg autorów projekt reinżynierii procesów biznesowych jest projektem zwykłym, którego głównym celem jest osiągnięcie celów długoterminowych bez presji czasowych.

h1

Rózwój procesu jako likwidacja jego luk

Grudzień 18, 2011

W literaturze można się spotkać z przyczynowym podejściem do rozwoju przedsiębiorstwa, które skupia się na identyfikacji i rozwoju luk. Mogą to być takie luki jak na przykład:

  • luka między stanem pożądanym a rzeczywistym, patrząc całościowo na organizację;
  • luka między stanem możliwości a stanem potrzeb przykładowo w zakresie zasobów o określonym doświadczeniu, zaangażowaniu, umiejętnościach;
  • luka między posiadanymi lub pozyskanymi w przeszłości możliwościami a rzeczywistymi/realizowanymi osiągnięciami, efektami działalności, która najlepiej pokazuje, czy przedsiębiorstwo idzie w oczekiwanym kierunku, czy jego osiągnięcia sprzedażowe, inwestycyjne, w zakresie polityki społecznej itp. odpowiadają posiadanym zasobom oraz zrealizowanym przedsięwzięciom.

Spojrzenie to jest właściwe dla poziomu całej organizacji, jednakże czy nie można tego przełożyć na niższy poziom? Pojedynczego procesu? Odpowiedź jest prosta – tak, w szczególności stosując zasady benchmarkingu lub reinżynierii procesów biznesowych.

Załóżmy, że mamy fragment procesu, gdzie po zakończeniu zadania przez jednego z uczestników procesu, efekt jest „konsumowany” przez innego uczestnika w kolejnym kroku. Diagram (w BPMN) prezentuje „oficjalny” i rzeczywisty przebieg procesu z zaznaczeniem luki.

W procesie konieczna byłaby modyfikacja luki między wyjściem „X” a wejściem „Y”. Różnica wynika z założenia, że każdy z uczestników chce wykonać jak najlepiej swoją pracę, jednakże oczekiwania uczestnika o Roli Y co wejścia do swojego zadania, są różne od rzeczywistego wejścia, produkowanego na wyjściu przez uczestnika o Roli X. W procesie konieczne jest wtedy przeznaczenie czasu na wyjaśnienia lub poprawki. W ramach benchmarkingu możliwe byłoby poprawienie tego procesu – na przykład poprzez zderzenie oczekiwań obydwu stron – Roli X i Roli Y. Może efekt pracy Roli X jest spowodowany przez jakość materiału, który otrzymuje z wcześniejszych etapów procesu. Całościowa analiza pozwoli na zidentyfikowanie większości luk i określenie ich przyczyn.

h1

Założenia procesu – warstwa reinżynierii

Czerwiec 29, 2010

Załóżmy, że:

  • mamy wdrożyć rozwiązanie informatyczne do obsługi dla procesu sprzedaży produktu przez internet;
  • w przedsiębiorstwie istnieją systemy zarządzania relacjami z klientem, zarządzania łańcuchem dostaw
  • proponowane rozwiązanie ma zintegrować różne systemy występuje w przedsiębiorstwie

W takiej sytuacji analizę można rozpocząć od odpowiedzi na następujące kategorie pytań:

  • Jakie udogodnienia oferowane są dla klienta?
  • W jaki sposób firma chce wspomagać decyzje klienta?
  • Jaki są cele firmy oraz procesu?
  • Z jakich źródeł danych proces może, ma, musi korzystać?
  • Jakie systemy informatyczne będą wykorzystywane w procesie?
  • Jakie informacje firma posiada o rynku, o klientach, jakie informacje potrafi zdobyć?
  • Jakie znaczenie ma dany proces wśród procesów przedsiębiorstwa?

Można zadawać kolejne pytania. Celem ich jest ustalenie tzw. kontekstu procesu (który docelowo przyczynia się do stworzenia tzw. słownika procesu). Uzasadnieniem tego faktu jest to, iż odpowiedzi na powyższe pytania są uzależnione od gałęzi/dziedziny gospodarki, w którym ma miejsce dana sprzedaż, czy obsługa klienta. Innego typu zależności będą występować w przypadku sprzedaży elementów wyposażenia mieszkania, a inne w przypadku przemysłu spożywczego.

Prowadząc taką analizę, poruszamy kwestie dotyczące dwóch warstw procesu. W przypadku założonego procesu, warstwa reinżynierii mogłaby w skrócie przebiegać następująco:

  1. Zapoznanie się z ofertą/produktami
  2. Wybranie produktu i złożenie zamówienia
  3. Przekazanie oraz przetworzenie zamówienia
  4. Sprawdzenie możliwości realizacji zapłaty
  5. Sprawdzenie możliwości dostarczenia produktu
  6. Ustalenie sposobu/miejsca dostarczenia
  7. Realizacja zamówienia
  8. Obsługa posprzedażna oraz transakcje powiązane
h1

Warstwy procesu

Czerwiec 29, 2010

A. Tsalgatidou oraz S. Junginger w „Modelling in the Re-engineering Process” wskazują dwie warstwy procesu. Są to: warstwa reinżynierii i warstwa implementacyjna.

Pierwsza z nich – warstwa reinżynierii – określa tzw. charakter wykonania procesu. Proces jest postrzegany jako element codziennej działalności przedsiębiorstwa. Element ten jest oceniany w kategoriach kosztów (ang. costs), czasu (ang. time), przydzielonych praw (ang. laws), odpowiedzialności, wykonywanych zadań.

Druga z nich – warstwa implementacyjna – powiązana jest z takimi kwestiami jak IT, środowisko pracy. Warstwa ta zawiera w sobie zbiór elementów, które dotyczą integracji procesów z systemami przedsiębiorstwa, procedurami oraz środowiskiem pracy, siłą roboczą, posiadanymi kompetencjami do wykonywania określonych zadań.

h1

Kryteria wyboru procesu

Czerwiec 5, 2010

W ramach etapu 2 reengineeringu następuje wybór procesu. Podmiot gospodarczy może wybrać proces wg wielu kryteriów. A. Węgrzyn w książce pt. „Benchmarking. Nowoczesna metoda doskonalenia przedsiębiorstwa.” wskazuje takie kryteria:

  • kryterium skali problemów powodowanych przez dany proces,
  • kryterium znaczenia danego procesu dla prawidłowego funkcjonowania firmy,
  • kryterium kosztu,
  • kryterium terminowości,
  • kryterium tego, jak prawdopodobne są korzystne efekty rekonstrukcji danego procesu.