IT jest z Marsa, a BPM z Wenus - pełna wersja do pobrania
A właśnie, że potrzebuję piętnastą parę butów! Jeszcze nie mam w takim kolorze!
Ach Ci nasi analitycy biznesowi (oraz lepsze połówki w życiu domowym). Ileż to razy zdarzyło nam się usłyszeć takie zdanie i odczuć jego wpływ w domowym budżecie. W przypadku projektowania oprogramowania, użytkownicy biznesowi chcieliby mieć możliwość obsługi wielu wersji tego samego procesu biznesowego. Niestety IT zapomina często, że jednym z celów wdrożenia BPM jest udostępnienie użytkownikowi końcowemu możliwości parametryzacji zaszytych procesów biznesowych i ich wersjonowania. Z pomocą przychodzi tutaj każda dobra platforma BPM (po listy odsyłam tutaj do raportów Gartnera). Dobra platforma BPM tzn. taka, która m.in. umożliwia przechowywanie dowolnej liczby wersji tego samego procesu. Bez takiej funkcjonalności, proces zarządzany przez BPM niewiele będzie się różnił od standardowej aplikacji. Niestety w świecie codziennym tak przyjemnego rozwiązania nie mamy, no chyba że jesteśmy właścicielem włoskiej fabryki obuwia, albo krezusem mogącym kupować kolejne pary bucików (czyt. aplikacji).
Bo Ty od razu odwracasz się i zasypiasz po…
Decydując się już na wdrożenie BPM, warto zwrócić uwagę na częstą bolączkę takich wdrożeń. Stanowią ją skargi użytkowników końcowych, że dział IT po wdrożeniu systemu „zasypia”. Koniec kropka, można przejść do fazy satysfakcji i odwrócić się na drugi bok. Nic jednak bardziej błędnego. Przynajmniej jeśli chodzi o oczekiwania tej drugiej połowy projektu. Planując wdrożenie rozwiązania BPM, dział IT musi pamiętać, że praca nie kończy się na podpisanym protokole odbioru. Zaplanujmy utrzymanie systemu, w tym przede wszystkim czas i zasoby do opieki nad systemem w pierwszym okresie po jego uruchomieniu. Wystarczy kilka miłych słów w pierwszych trzech miesiącach (byle często wypowiadanych), co pozwoli na wzajemną satysfakcje ze wspólnego wysiłku (oraz uśpienie partnera).
Dlaczego w sypialni zostawiłeś brudne skarpetki?
Wdrażając jakiekolwiek rozwiązanie, służby IT, czy to wewnętrzne czy zewnętrzne, nie powinny też zapomnieć, że to co dla użytkownika biznesowego jest krytycznym wymogiem lub funkcją nie zawsze jest zrozumiałe dla programisty i wdrożeniowca. Warto więc spędzić pomiędzy partnerami odpowiednią, dużą, ilość wolnego czasu na analizę i dokładne rozmowy, tak by potem nasi użytkownicy nie eskalowali do zarządu problemu źle umieszczonego przycisku, czy też innych kolorów w tabelce (Kochanie, prosiłam byś śliwkowe rzeczy nie prał razem z fioletowymi…). Nie trzeba wszak rozumieć wszystkich wymagań, by móc je zaakceptować i wdrożyć w rozwiązaniu. Trzeba jednak znać je oraz ich wagę dla drugiej strony, a to ona (czyli biznes) odpowiada za odpowiednie zakomunikowanie tego faktu.
Dlaczego wciąż oglądasz się za innymi kobietami?
A więc mamy decyzje: czas wdrożyć BPMa. Trzeba jeszcze „tylko” wybrać jakiego. Architekci z działu IT całymi godzinami studiują więc tabele porównawcze i parametry różnych platform. Wreszcie, z bólem serca, rekomendują wybór tej, która ma o 3% lepszy współczynnik na dole strony 87 załącznika 3 do aneksu zaktualizowanego tegorocznego raportu Gartnera. Podobnie jak w życiu, w projektach informatycznych, architekci zapominają, że to nie wybór lub wymiana narzędzia determinuje sukces projektu. Zamiast ciągle poszukiwać czegoś lepszego, sprawniejszego, zgrabniejszego, warto poświęcić czas i energie na prawidłowe wykorzystanie narzędzia, które już jest, mówiąc kolokwialnie, ‘pod ręką’. Bo to właśnie stopień zaangażowania w projekt, ciągła pielęgnacja i dbanie o niego, rozwiązywania codziennych konfliktów i problemów, odpowiednie wdrożenie, wpływa na efekt końcowy dużo bardziej niż początkowy wybór.
O nie mój drogi, kolacja przy świecach u Ciebie, dopiero po trzech tygodniach znajomości!
Dyrektor finansowy często już zaciera ręce licząc na oszczędności w budżecie na bazie materiałów reklamowych rozwiązań BPM. Niestety. Jak pokazują raporty powdrożeniowe, przestawienie aplikacji w przedsiębiorstwie daje efekty dopiero w drugim i trzecim roku, kiedy liczba systemów i procesów zaimplementowanych na platformie stanowi znaczący odsetek całej infrastruktury. Warto o tym pamiętać na starcie: najpierw inwestycja i cierpliwość, zyski dopiero po kolacji. Trzeciej. Przy błędnym wdrożeniu, czekać trzeba jeszcze dłużej. Jak to w życiu.
Znów zapomniałeś o moich urodzinach…
To że rozwiązania BPM są używane najczęściej wewnątrz organizacji, nie znaczy że nie musimy ich aktualizować, regularnie wgrywać poprawki i traktować na równi z systemami stojącymi frontem do klienta. Częstym grzechem działów utrzymania oprogramowania, jest po macoszemu traktowany BPM, który przecież tak jak każdy inny system musi być otoczony regularną atencją. Powiedzmy to wprost: jego opiekun biznesowy, razem z kwartalnym raportem przeglądu i wykonanych prac, powinien dostać także bukiet kwiatów. A przynajmniej bukiecik z bilecikiem. Lepiej bowiem wykonywać mniejsze przeglądy często, niż duże raz na kilka lat.
Dawniej dawałeś mi różę, a teraz sama muszę podlewać kwiatki (i kupować)!
Dział IT, lub dostawca systemu, przygotowując prezentacje dla użytkownika przed zakupem rozwiązania BPM, powinien pamiętać by nie było to typowe przedstawienie w różowych barwach, gdzie wszystko się da, wszystko działa, a użytkownik nic nie musi robić oprócz szczęśliwego poczucia zaspokojenia wszystkich jego wymagań. Z tak różową wizją przyszłości, rzeczywistość która potem nastanie może być potem dla użytkownika bardziej niż bolesna. Warto więc prezentacje produktu robić w terenie, podczas wizyty referencyjnej, lub implementując przykładowy proces wprost z organizacji klienta. Wtedy odbiorca będzie miał czytelną wizje tego, co go niedługo czeka, a i dostawca lub dział IT nie przekroczy zaplanowanego budżetu. Co go niechybnie czeka, by znaleźć w nim miejsce na cotygodniowy kosz róż wysyłany do kierownika projektu ze strony odbiorcy w celu zażegnania konfliktu.
Oczywiście rzeczywistość nigdy nie jest tak jednostronna jak przedstawiona w przykładach powyżej. Działy biznesowe korzystające, lub planujące korzystać z rozwiązań BPM powinny też pamiętać że powodzenie projektu zależy od obu stron i bacznie zwracać uwagę na potrzeby, problemy i ograniczenia zgłaszane przez IT. Przyjrzyjmy się więc żalą drugiej strony, czasami nie słusznym, czasami wartym zażegnania na starcie.
Kiedy wreszcie będziesz gotowa do wyjścia, dwie godziny przed lustrem???
Działy IT często nie potrafią zrozumieć, że analiza wymagań w projektach wdrożenia BPM zajmuje bardzo dużo czasu. Tymczasem wystarczyłoby odpowiednie zaplanowanie długiej analizy w harmonogramie. Zadaniem dla biznesu jest jednak dobre przemyślenie całości, tak by niekończącymi się spotkaniami i iteracjami pracy nad dokumentem analitycznym nie doprowadzić do załamania nerwowego wykonawcy. Wszak wspólny bal rozpoczyna się o konkretnej godzinie, i musimy zdążyć na niego we dwoje.
Kochanie, kiedy u licha wyjdziesz z łazienki?
Rozwiązania BPM są zasobochłonne. Dodatkowe serwery, bazy danych kosztują. Dlatego jeśli chcemy mieć komfort związany z elastycznością narzędzia, musimy zainwestować w odpowiedni park maszynowy. Tak samo jak w życiu codziennym. Dom z dwoma łazienkami jest droższy. Jednocześnie spokój ducha zapewniony przez to że aplikacja CRM oraz platforma BPM nie konkurują o ten sam serwer jest godny dokładnego planowania budżetu przy definiowaniu założeń projektu.
Czy musisz kupować kolejną sukienkę tego samego koloru? Masz ich już kilka!
Działy biznesowe czasami zapominają, że dbanie o koszty rozwiązania BPM to także ich obowiązek. Przykład? Większość producentów udziela licencji w oparciu o ilość procesów uruchomionych na platformie. Wystarczy że biznes dokładnie i bez nadmiaru oceni ile procesów będzie uruchamiał. Ani mniej, ani więcej. Nadmierne ‘zapasy’ na czarną godzinę doprowadzić bowiem mogą wspólny budżet na skraj bankructwa, a i okaże się pewnie że będą przeterminowane za rok, kiedy to producent wprowadzi znaczące obniżki. Oczywiście czasami nadmiar jest wskazany (wielki bal u szefa), ale czasami mocno problematyczny i ryzykowny (przekroczony budżet w roku kryzysu).
Nie gotujesz tak dobrej zupy jak moja mama!
Rozwiązania BPM są najczęściej wprowadzane w instytucjach przede wszystkim w skutek inicjatywy działów biznesowych. To one są motorem zmiany, a mając za sobą zarząd (wiadomo, generacja przychodu jest miła uchu każdego prezesa) wywierają presję na terminy wdrożeń. Warto jednak pamiętać iż przestawienie się na nowe rozwiązania, gdzie BPM może być łączony z architekturą SOA, wymaga od działów IT inwestycji w edukacje, odpowiednie przeszkolenie i zmianę sposobu działania. Warto zrozumieć że takie działanie musi zabierać czas i pozwolić swojemu wewnętrznemu partnerowi na odpowiednie przygotowanie się i przeprowadzenie zmiany.
Przytul mnie? Znowu? Nie mogę przecież co 5 minut mówić że Cię kocham!
Dlaczego nie działa formatka 21? Czemu nie dostałem powiadomienia o zmianie statusu zadania? Kiedy zainstalujecie nową wersje aplikacji? A dlaczego Zosi z księgowości wyskoczyło okienko? Liczba pytań i próśb jest często ogromna. Nie pomaga nawet najlepiej przeprowadzone szkolenie. Czasami mamy więc wrażenie jakby ciągła atencja ze strony służb IT, miała być potwierdzeniem jakości wdrożonego rozwiązania. Czy tak musi być? Warto chyba jednak pozwolić by IT mogło odnosić się do problemów nie od razu, ale w pakietach, powiedzmy gdy uzbiera się ich 10, lub gdy miną dwa dni od najstarszego. Tak by ‘wilk był syty, a owca cała’. Problemy muszą być rozwiązywane, ale odpowiednie SLA i gwarancje czasów rozwiązania, powinny być dobrane adekwatnie do okoliczności i instytucji. Warto tego typu ustalenia poczynić przed wdrożeniem (uwzględniając takie działania w budżecie) oraz zadbać by całość była spójna w obrębie kompletnej organizacji. Tak by nie okazało się poniewczasie, iż aplikacja zarządzająca zamawianiem kawy ma lepsze SLA niż system obsługi reklamacji klientów, a o tym że nasza lepsza połówka lepiej wygląda w czarnym kolorze dowiadywała się od sąsiada z parteru.
Jak widać patrząc na nasze codzienne życie, analogii jest sporo. Tak jak w życiu, świat biznesu, tu reprezentowany przez BPM, oraz świat techniki często posługują się różnym językiem i w efekcie nie mogą się porozumieć. Jeden bez drugiego nie może jednak istnieć, a od ich sprawnego dialogu zależy sukces całej organizacji. Warto więc rozmawiać, zarówno w życiu zawodowym, jak i prywatnym.