W jakich rodzajach procesów

Inwestycja w BPM może się zwrócić (i to z nadwyżką) w poniższych obszarach:

• Procesy dynamiczne - często się zmieniają (procesy statyczne rzadko ulegają zmianom). Dobrym przykładem procesów dynamicznych są te, które muszą spełniać wymogi prawne - i zmieniane są odpowiednio do zmian w prawie - np. firmy handlowe modyfikujące sposób zarządzania danymi swoich klientów z powodu zmian prawa w zakresie ochrony prywatności i wymogów firm oferujących karty kredytowe.
• Procesy obejmujące ludzi i zazwyczaj łączące jednostki biznesowe, działy, piony, grupy robocze oraz inne funkcjonalnie zorganizowane grupy.
• Złożone procesy (np. typu "order-to--payment" - od zamówienia do płatności) - wymagają zsynchronizowania różnych osób z różnych wydziałów używających różnych aplikacji i/lub danych, aby mogli spełnić swoją rolę w procesie.
• Mierzalne procesy krytyczne dla realizacji misji - tzn. ulepszenie procesu bezpośrednio przekłada się na wyższą wartość wskaźnika wydajności, który jest mierzalny i istotny dla działalności przedsiębiorstwa.
• Procesy, które nie mogą zostać zakończone bez połączenia się z więcej niż jedną aplikacją już używaną (lub procesem zapewniającym istotne dodatkowe możliwości, np. obsługiwana przez pracowników aplikacja zarządzania HR).
• Procesy z wyjątkami, które obecnie są obsługiwane ręcznie (np. zależność sprzedawcy mebli od fizycznych badań i wykrywania odchyleń od normy w zapasach).
• Procesy z wyjątkami wymagającymi wprowadzania szybkich zmian.

Obszary, w których BPM się nie sprawdza, to:

• wymiana istniejących aplikacji;
• przetwarzanie dużych ilości transakcji (np. aplikacja POS, chociaż wyjątek mogą stanowić zwroty między różnymi kanałami sprzedaży);
• procesy niewymagające lub wymagające w niewielkim stopniu interakcji użytkownika;
• procesy, które mogą zostać łatwo i tanio zautomatyzowane za pomocą innych narzędzi.

Czasami najważniejszą częścią strategii jest wiedza o tym, czego nie robić, zwłaszcza w przypadku kompleksowego systemu, jakim jest BPM. Pierwszy proces objęty BPM powinien być ważny, ale nie powinien to być proces najbardziej skomplikowany czy istotny dla firmy. Prawidłowo wprowadzone BPM jest dobrym przykładem efektu koła zamachowego: koncentracja na szczegółowych i szybko wprowadzanych rozwiązaniach w obszarach, w których ulepszenie procesu biznesowego jest od razu widoczne, tworzy warunki dla szerszego i trwalszego wdrożenia BPM.

BPM a SOA

SOA zapewnia dostęp do innych aplikacji. Dzięki SOA BPM wykorzystuje dane z różnych aplikacji w ulepszonych procesach. Jeśli SOA to drogi dla informacji krążących w przedsiębiorstwie, BPM to samochód pozwalający wykorzystać tę infrastrukturę do osiągnięcia korzyści. Krótko mówiąc, architektura usługowa pozwala tak łączyć usługi wspierające procesy, by zwiększyć sprawność biznesową firmy. W bardziej technicznym języku, SOA oznacza strukturę ściśle integrującą dotychczas luźno związane usługi i zapewniającą współoperatywność nowych i starych systemów. Umożliwia ona udostępnianie przez systemy części swojej funkcjonalności innym aplikacjom w ustandaryzowany sposób. Na przykład system rozliczeń zobowiązań przedsiębiorstwa może udostępnić interfejs pozwalający innym aplikacjom na obciążanie rachunku firmy, BPM zaś umożliwia połączenie tych udostępnionych usług różnych aplikacji w nowy, efektywny proces.

Zobacz również:

• 9 cech wielkich liderów IT
• CIO "bumerangi": liderzy IT awansują, powracając
• 6 znaków ostrzegawczych, na które CIO powinni zwrócić uwagę w 2024 roku

Czasami inicjatywa wdrożenia BPM powoduje wcześniejsze wprowadzenie SOA. Teraz, kiedy dyrektorzy oczekują bezpośrednich zysków z inwestycji IT, wprowadzenie samej SOA może być sporym wyzwaniem, ponieważ trudno jest jasno i przystępnie wytłumaczyć tworzoną przez nią wartość. Jednym ze sposobów na pokonanie tej przeszkody jest wdrożenie SOA jako podstawy do wprowadzenia BPM, ponieważ BPM jest mniej abstrakcyjne i dlatego łatwiej opisać jego wartość - dotyczy konkretnych (i istotnych) procesów biznesowych. Dzięki takiemu związkowi znaczenia tego nabiera również SOA. Stale należy jednak pamiętać o jakości usług rodzaju SOA. Jest to bardzo ważna kwestia, jeśli strona świadcząca usługę znajduje się w innej organizacji lub nawet w innej firmie. Aplikacje wykorzystujące taką usługę muszą być zaprojektowane w sposób umożliwiający płynne działanie nawet w przypadku, kiedy usługa ta jest niedostępna. Menedżerowie powinni pamiętać o zawarciu umowy o jakości świadczenia usług SOA ze swoimi partnerami. Usługi powinny regulować czas i sposób aktualizacji interfejsów. Ważne jest to dlatego, że jeśli SOA ma być podstawą BPM, to krytyczne procesy w firmie będą zależały od tej właśnie usługi. Jeśli usługa zawiedzie, wtedy także procesy w systemie BPM nie będą funkcjonować. Należy więc pamiętać, by zawsze znać, lub być w stanie kontrolować, poziom jakości wszystkich usług, na których oparte jest BPM.

Standardy BPM

Autorzy BPM chcą powtórzyć sukces innych technologii, dlatego wyznaczają standardy branżowe, które będą stanowić solidne fundamenty pod dalszy rozwój technologii i jej akceptację przez klientów. Klientom zależy na zgodności aplikacji ze standardami, ponieważ ułatwia ona zmianę dostawcy BPM, wyszukiwanie projektantów systemów, organizację współpracy z innymi systemami BPM i zewnętrznymi partnerami oraz obniża koszty działalności. Niestety, szerokie możliwości typowych pakietów BPMS i liczne grupy interesów spowodowały, że tworzone standardy obejmują jedynie części typowego cyklu zarządzania procesem (tj. projekt, wykonanie, zarządzanie).