Wywiady

BPMstandard.pl używa cookies.

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

Zrozumiałem
01Gru2015

Tomasz Burczyński o specyfice projektów wdrożeniowych BPM

tomasz burczynskiO cechach, które charakteryzują projekty wdrożeniowe rozwiązań klasy Business Process Management, rozmawiamy z Tomaszem Burczyńskim, Prezesem Zarządu FABRITY K2 odpowiedzialnym za sprzedaż do nowych klientów i ekspansję spółki FABRITY, pasjonatem nowych technologii IT w zastosowaniach komercyjnych, asolwentem Szkoły Głównej Handlowej w Warszawie i do 2004 roku pracownikiem Katedry Informatyki Gospodarczej SGH.

BPMstandard.pl: 

Panie Prezesie, jakie są charakterystyczne cechy projektów polegających na wdrożeniu rozwiązań BPM, na co należy zwrócić szczególnie uwagę w planowaniu i realizacji?

Tomasz Burczyński:

Mówiąc o BPM, powinniśmy postawić znak równości pomiędzy tym pojęciem a słowem strategia. Mam na myśli to, że o przedsięwzięciach związanych z wdrażaniem zarządzania procesowego należy myśleć w szerszych kategoriach tj. traktować BPM jako element strategii firmy. Stopień szczegółowości tych założeń nie jest jednak wysoki, a główne decyzje na tym poziomie powinny ograniczyć się do takich aspektów jak wybór kluczowych obszarów i procesów biznesowych wymagających optymalizacji, analiza spodziewanych korzyści oraz wybór partnerów biznesowych, doradczych i technologicznych dla poszczególnych obszarów. Natomiast skuteczną realizację strategii procesowej w poszczególnych obszarach widzę przede wszystkim, jako ciąg mniejszych inicjatyw i projektów biznesowych, z których każdy z osobna trwa maksymalnie kilka miesięcy i nie pochłania gigantycznego budżetu. Dzięki temu wartość dla organizacji dostarczana jest w „mniejszych paczkach”, ale częściej i przez to jest bardziej zauważalna. Z drugiej strony, skrajnie różne podejście kojarzy mi się z myśleniem bardzo etapowym, sekwencyjnym, np. „a teraz przez rok będziemy mapować procesy AS-IS”. W takim przypadku czas podejmowania pojedynczych decyzji o średnio większej wadze jest istotnie dłuższy, wiele innych czynników związanych z wydłużeniem czasu do dostarczenia pierwszej realnej wartości dla firmy wpływa negatywnie na sukces tego rodzaju przedsięwzięcia.

BPMstandard.pl:

Na podstawie Pana doświadczeń, czy organizacje, w których wdrażane są rozwiązania klasy BPM określają wskaźniki optymalizacji i dokonują ich pomiaru?

Tomasz Burczyński:

Tak, przynajmniej powinny…Chyba, że „utraciły kontakt” z celem projektu, o czym wspominałem wcześniej. Możemy wyjaśnić potrzebę takiego podejścia w prosty i logiczny sposób. O projektach powinniśmy myśleć w kategoriach celów biznesowych zatem cele, zarówno ilościowe jak i jakościowe, powinny być SMART (Specific, Measurable, Achievable, Realistic, Time-bound). Dobrą praktyką powinno być zatem powiązanie celów projektu z wskaźnikami, zmierzenie lub oszacowanie ich wartości na etapie początkowym tj. przed przystąpieniem do prac optymalizacyjnych i możliwie najdokładniejsze zmierzenie ich wartości po wdrożeniu właściwego rozwiązania. Bez takiego podejścia po prostu trudno mówić o ocenie wartości biznesowej projektu, realizacji celów projektu czy zwrocie z inwestycji. Wskaźniki te mogą dotyczyć zagadnień ilościowych jak i jakościowych. W przypadku celów jakościowych mogą to być wartości dobrze mierzalne w dużych próbach danych np. średni czas obsługi klienta przy uruchomieniu nowego produktu finansowego. Jeśli chodzi  natomiast o cele jakościowe  można wręcz oprzeć się  na subiektywnych ocenach wynikających z ankiet np. satysfakcja pracowników, ułatwienia im realizacji czynności administracyjnych, które pozornie nie generują wartości dla firmy. Staramy się wspierać naszych klientów w realizacji takiego właśnie podejścia. Ważne jest jednak, aby taka koncepcja była uwzględniona w pierwotnym planie projektu i były na tego rodzaju działania przewidziane środki i zasoby ludzkie.

BPMstandard.pl:

Klienci przed opracowaniem modelu TO-BE procesów wymagają opracowania wcześniej modelu AS-IS?

Tomasz Burczyński:

Zależy to od takich kwestii, jak wielkość organizacji i jej doświadczenie, dojrzałość w zarządzaniu procesowym, do tego czy dany obszar dzielności firmy ma swoją długą historię, czy jest to nowy element działalności. Przede wszystkim zależy to jednak od  głębokości zmian o jakich mówimy w odczuciu właścicieli biznesowych: czy są to znaczne zmiany organizacyjne dotyczące formy i organizacji procesów w ich wielu aspektach, czy jedynie wybiórcze elementy procesów, które powinny ulec optymalizacji np. przez automatyzację działań. Szczerze mówiąc, z uwagi na to, że tematyka zarządzania procesowego nie jest czymś nowym, myślę, że przynamniej wśród dużych przedsiębiorstw najczęściej istnieje jakiegoś rodzaju dokumentacja typu „AS-IS” , która jest najczęściej aktualizowana czy uzupełniana przez firmę samodzielnie, na etapie opracowywania założeń projektu czy też przygotowywania „business case”. Forma i poziom szczegółowości mogą być lepsze lub gorsze, ale nie jest to najważniejsze ponieważ jednym z pierwszych celów konsultantów zewnętrznych jest i tak poznanie i zrozumienie biznesu klienta. 

BPMstandard.pl:

Pana praktyka wdrożeniowa wskazuje na potrzebę przeprowadzania symulacji procesów przed ich implementacją i wdrożeniem?

Tomasz Burczyński:

Warto stosować ten element, o ile firma dysponuje odpowiednimi narzędziami technicznymi lub gdy te narzędzia są dostarczane w ramach projektu, którego przedmiotem jest zarówno dostarczenie technologii i opracowanie określonych rozwiązań procesowych, jak to zazwyczaj ma miejsce w przypadku naszych projektów. Według mnie symulacja procesów jest najmniej znanym i najmniej zauważanym obszarem zarządzania procesowego, w związku z tym firmy rzadko wymagają wsparcia w tym obszarze, czy oczekują narzędzi realizujących te funkcje. Należy jednak wziąć pod uwagę, że procesy w wielu obszarach biznesowych mogą nie wymagać skomplikowanych narzędzi wyspecjalizowanych w symulacji, gdyż wyniki takich symulacji są łatwe do przewidzenia czy wyliczenie poprzez arkusz kalkulacyjny. Zdecydowanie warto robić formalne symulacje przy pomocy narzędzi BPMS, przed wdrożeniem właściwych rozwiązań w kluczowych obszarach biznesowych, które wymagać będą znacznych inwestycji, w celu potwierdzenia założeń „business case”. Mam tu choćby na myśli symulowanie istotnych zmian w procesach sprzedaży czy obsługi klienta, dzięki którym możliwe jest dokładniejsze określnie parametrów takich jak średni czas realizacji poszczególnych czynności, alokacja zasobów i koszt instancji procesu. Na tym etapie można finalnie potwierdzić lub odrzucić „business case”. Natomiast jeśli, organizacja nie ma wątpliwości na takim poziomie, zamiast polegać na symulacji statycznej, warto pomyśleć raczej o organizacji projektu zgodnie z metodyką „zwinną”, zarządzać backlog’iem rozwoju, uruchamiać pilotaże, obserwować rzeczywiste dane i planować iteracje rozwojowe na podstawie wniosków z ich analizy.

BPMstandard.pl:

Czy w procesie produkcji i wdrożenia rozwiązań klasy BPM zastosowanie mają takie artefakty jak model przypadków użycia, model dziedziny, model klas...?

Tomasz Burczyński:

Zależy to od wyboru narzędzi i technologii IT, ale w największym stopniu od samego przedmiotu projektu i przyjętej metodyki jego prowadzenia. Dobrą praktyką w projektach budowy rozwiązań procesowych jest ich tworzenie na podstawie biznesowych schematów procesów. Schematy te obrazują tzw. BPA (Business Proces Automation) tj. czynności faktycznego procesu biznesowego realizowane przez rozwiązanie IT, które tenże proces wspiera, zakres realizacji oraz wykorzystane do tego celu zasoby. Drugi element to jakaś forma zarządzania wymaganiami powiązanymi z ustaloną skalą automatyzacji procesu i zgodna z obraną metodyką – może być to backlog funkcji, przypadki użycia, czy „user stories”. Istotnym elementem jest również projekt UX, który w formie makiet lub już prototypowanego rozwiązania docelowego, obrazuje wygląd funkcjonalności GUI rozwiązania. To plan minimum, który sprawdza się przy mniejszych i mniej krytycznych przedsięwzięciach, gdzie taka dokumentacja projektowa wystarcza do dobrego zrozumienia działania i wyglądu docelowego rozwiązania. Im projekt jest większy i bardziej skomplikowany, im bardziej krytycznych obszarów biznesowych dotyczy, tym bardziej rośnie konieczność stworzenia dodatkowej dokumentacji projektowej. Zwykle jest to związane z integracją w tworzonym rozwiązaniu innych systemów IT, definiowaniem kontraktów wymiany danych, analizą wykonalności prac integracyjnych, projektowania wyseparowanych usług i elementów algorytmicznych itp.  

BPMstandard.pl:

Jakie znaczenie przed rozpoczęciem projektu lub w jego trakcie ma edukacja klienta w zakresie BPM?

Tomasz Burczyński:

Myślę, że ma duże znaczenie, ale dotyczy to wybranych aspektów. Mam na myśli to, że w momencie, w którym rozpoczyna się projekt, zespół po stronie klienta jest w dużym stopniu już wyedukowany. Trudo mi sobie wyobrazić sytuację, w której startuje projekt, który wcześniej nie został poprawienie zaplanowany pod kątem zrozumienia potrzeb, oczekiwanych korzyści, choćby ogólnej wizji rozwiązania, które będzie powstawać, rodzaju zmian organizacyjnych, z jakimi projekt się wiążę itp. A powstanie takiego planu wiąże się z wcześniejszą samoedukacją, przynajmniej w ogólnych obszarach. To czego może brakować to elementy bardziej powiązane z doświadczaniem projektowym i dobrymi praktykami. Jako najważniejsze elementy wymienię realne planowanie zasobów ludzkich w projekcie, właściwe zdefiniowanie celu wraz z miernikami i ich wartościami referencyjnymi, ustalenia dotyczące sposobu monitoringu procesów lub czynności i plan wdrożenia, szczególnie w obszarze tzw. „miękkich aspektów”. 

BPMstandard.pl:

Jak długo średnio trwa projekt BPM-owy? 

Tomasz Burczyński:

Jeśli jako projekt rozumiemy pojedynczy obszar, inicjatywę czy rozwiązanie, to myślę, że powinny działać tu dobre, nowoczesne wzorce z metodyk zwinnych. Mam na myśli rozumowanie w kategoriach iteracyjnej budowy rozwiązania, w sprinatach nie dłuższych niż 4 tygodnie, tak aby co najwyżej w 8-10 iteracjach można było osiągnąć produkt nadający się do uruchomienia, co nie wyklucza oczywiście dalszej iteracyjnej pracy na jego rozwojem. Znaczne przekroczenie tych założeń to spore zagrożenie, że w międzyczasie wystąpiły czynniki rzutujące na zmianę założeń dotyczących produktu. Natomiast BPM w szerokim znaczeniu, rozumiany jako program, czy element strategii powinien być procesem ciągłym, przynajmniej w aspektach dotyczących monitoringu efektywności procesów, zarządzania wzorcami i dobrymi praktykami, pozwalającymi utrzymać aktualność tej strategii.

BPMstandard.pl:

Podziękowania za rozmowę.


Więcej wywiadów

Monika Perendyk o procesach biznesowych i inżynierii wymagań

monika perendyk

Marek Szelągowski o dynamicznym zarządzaniu procesami biznesowymi

marek szelagowski

Grzegorz Bliźniuk o dojrzałości procesowej organizacji medycznych w Polsce

gblizniuk