Pojawiają się w sieci różne komentarze i artykuły na temat notacji wykorzystywanych w projektach analitycznych. Poniżej cytaty jednego z typowych tego typu tekstów i moje uwagi…

Miejsce BPMN w odniesieniu do UML

Pojawienie się BPMN, BPML i systemów BPMS nie powoduje, że projektowanie systemów za pomocą UML staje się przestarzałe. Projektowanie systemów nadal jest istotnym elementem tworzenia architektury przedsięwzięcia. UML jest językiem projektowania, specyfikacji, wizualizacji i dokumentowania systemów oprogramowania. Jest on narzędziem dla architektów systemów i projektantów oprogramowania. Został opracowany do ułatwienia i przyspieszenia produkcji oprogramowania, od projektu architektury systemu aż po implementację i jest skierowany do użytkowników o wysokich umiejętnościach technicznych. BPMN natomiast jest przeznaczony dla analityków biznesowych, architektów systemów i projektantów oprogramowania. Został opracowany do optymalizacji zarządzania cyklem życia projektu od etapu projektowania procesów i jest przeznaczony dla użytkowników biznesowych.

Sprostowanie: BPMN to system pojęciowy i notacja służące to tworzenia modeli procesów w postaci schematów blokowych (diagramów). BPML to [[Business Process Modeling Language (BPML)]] ? konkurencyjny do [[BPEL]] XMLowy język do opisu procesów. Zaś [[BPMS]] to ogólna nazwa na systemy wspomagające proces zarządzania zorientowanego na procesy, jest to cała klasa systemów. Co do tego dla kogo są adresowane notacje: każdy system pojęciowy jest adresowany do analityków i projektantów, dziedzina w jakiej zostanie zastosowana dana notacja zależy od jej użyteczności w danej dziedzinie a wybór należy do analityka. Natomiast trudno się zgodzić z twierdzeniem “BPMN […]. Został opracowany do optymalizacji zarządzania cyklem życia projektu od etapu projektowania procesów i jest przeznaczony dla użytkowników biznesowych” bo to nie prawda (choć może być także do tego wykorzystany), BPMN powstał jako spójny system pojęć, jako narzędzie-język modelowania procesów biznesowych.

UML jest obcy większości analityków biznesowych

UML definiuje rozmaite typy diagramów, które można z grubsza podzielić na trzy grupy:

1. Statyczna struktura aplikacji
2. Dynamika zachowania aplikacji
3. Zarządzanie i organizacja rozwiązań programowych

Diagramy dynamiki zachowania, głównie diagramy use-case i aktywności są często używane do modelowania procesów biznesowych. BPMN jest zbliżony do UMLa w tym, że definiuje graficzną reprezentację procesów biznesowych zbliżoną do notacji w diagramach UMLowych. Jednakowoż UML i BPMN mają zupełnie odmienne podejście do modelowania procesów biznesowych.

To, że UML jest obcy większości analityków biznesowych to przykra prawda, dzisiaj raczej źle świadcząca o tej większości ([[patrz model kompetencji analityka biznesowego IIBA]]). Używanie UML do modelowania procesów biznesowych jest ograniczaniem możliwości tych modeli gdyż UML reprezentuje [[paradygmat]] obiektowy a BPMN procesowy a to dwa odrębne światy (to, że powstały i są wykorzystywane równolegle te dwie różniące się od siebie notacje notacje także o tym świadczy).

Trudno także mówić o “podejściu” do modelowania procesów w UML bo to tak, jak by mówić że łodzie reprezentują zupełnie odmienne podejście do poruszania się po drogach publicznych”. Niestety są żeglarze, którzy nie uznają innej prawdy niż ta, że łodzią można wszędzie trzeba się tylko postarać. Faktem jest, trzeba się dobrze postarać.

UML koncentruje się na obiektach, podczas gdy BPMN na procesach. Większość narzędzi UMLowych wymaga najpierw zdefiniowania statycznych obiektów w diagramach struktur, a dopiero później pozwala określić dynamikę interakcji między tymi obiektami za pomocą diagramów zachowań. Taka ścieżka rozumowania jest obca większości analityków biznesowych.

Co do wymagań samych narzędzi UML nie podejmuję się dyskusji bo narzędzia są rożne i każdy sam sobie je dobiera. Co do samej ścieżki analizy to raczej w pierwszej kolejności modelujemy biznes (modele BPMN) a potem dopiero zastanawiamy się i projektujemy narzędzie, oprogramowanie dla tego biznesu czyli pora na UML. Odwrotną kolejność sugerują dostawcy gotowego oprogramowania ale ten wątek był na tym blogu już nie raz poruszany.

BPMN oferuje podejście skoncentrowane na procesach, które jest bardziej naturalne i intuicyjne dla analityków biznesowych. W notacji BPMN najpierw modelowane są przepływy wiadomości i sterowania procesów.

Poprawka: proces opisuje przepływ pracy oraz to jakie dane (obiekt danych w BPMN) są wymagane i jakie powstają. Komunikaty to nośniki danych.

Model obiektowy procesu w trakcie normalnego modelowania nie jest definiowany wprost.

Prawdę mówią nie mam pojęcia co to jest “model obiektowy procesu”…

Niemniej jednak BPMN dostarcza również możliwoś zdefiniowania obiektowego modelu procesu explicite, na wypadek gdyby istniało zagrożenie, że zostanie on ujawniony przez usługi biznesowe w przebiegu procesu.

To także chciał bym zobaczyć, w specyfikacji BPMN niczego takiego nie znalazłem.

(źr.cytatów:  Zarządzanie Projektami – Artykuły)

Mam nadzieję, że powyższe uczuli Państwa na weryfikowanie tego co publikują autorzy tekstów w sieci (ze mną włącznie), niestety mam wrażenie rośnie ilość tak zwane pseudowiedzy.

[2015] Od wersji 2.5 UML formalnie UML nie służy do modelowanie procesów biznesowych, nie można zastąpić notacji BPMN notacją UML.

Z badania przeprowadzonego przez IBM na grupie ponad 3000 dyrektorów działów IT wynika, że w ciągu najbliższych pięciu lat, 60% organizacji zamierza wprowadzić rozwiązania opartych na chmurze. W opinii respondentów doprowadzi to do dalszego rozwoju ich firm i pozwali osiągnąć przewagę konkurencyjną. W stosunku do badania przeprowadzonego w 2009 roku podwoiła się liczba CIO, którzy chcą wprowadzić rozwiązania cloud computing, co świadczy o tym, że sprawdzają się one w wielu firmach na całym świecie. (źr.  Chmura wg badania IBM CIO Study).

Prognoza wydaje się realna. Odreagowanie kłopotliwych, kosztownych i mało przewidywalnych  wdrożeń systemów ERP, CRM powoduje odchodzenie od “twardej” integracji (niepodzielne zintegrowane systemy ERP) na rzecz [[architektury systemów federacyjnych]] takich jak właśnie [[Cloud Computing]].

 

Wygląda na to, że przyszłość to opisana powyżej architektura federacji quasiniezależnych systemów świadczących usługi. Zależność między nimi będzie polegała na standaryzacji słowników pojęć dziedzinowych (co już się dzieje).

W tej postaci np. nazwa: system ERP czy CRM, traci sens jako monolityczny pakiet a stanowi sobą pakiet usług z jakiego korzysta dane organizacja. drugorzędne znaczenie ma to czy użytkownik jest ich właścicielem, dzierżawca czy chwilowym użytkownikiem. Analiza Biznesowa tu polega na analizie i stworzeniu modelu organizacji, wskazaniu gdzie jakich usług wspierających działania się w niej oczekuje, wyszukaniu dostawców usług lub ich stworzeniu, integracji.

Osobiście uważam, że kończą się czasy gdy sprzedawcy “atakują” rynek, wybierają sobie klientów  i sprzedają im oprogramowanie. Zaczyna się era gdy to klient wybiera usługę i jej dostawcę. Sprzedaż oprogramowania będzie wyglądała podobnie jak sprzedaż w pasażu butików: dostawcy usług wystawią swoje usługi, a klient (projektant systemu) będzie się przechadzał i wybierał najlepiej mu pasujące. Podobnie jak teraz: budując dom, remontując mieszkanie zapraszamy projektanta wnętrz, ten znając oferty marketów budowlanych dobierze najlepsze wyposażenie, materiały i kolorystykę i kupi. Nadchodzi powoli koniec ery napastliwych sprzedawców i ich firm, koniec dyktatury developerów. Nadchodzi, powoli, era rynku usług.

Informacja prasowa

17 Czerwca odbyło się seminarium na temat metodologii modelowania procesów w organizacjach i korzyści jakie dają sformalizowane metody modelowania. Seminarium zbudziło bardzo duże zainteresowanie. Wśród gości, osób zainteresowanych tą tematyką znaleźli się przedstawiciele operatorów telefonii komórkowej, instytucji finansowych i  największych urzędów. Po zakończeniu zgodnie stwierdzili, że poznane na seminarium zagadnienia tłumaczą wiele niepowodzeń związanych z reorganizacją i projektami IT i bardzo pomogą w planowanych przedsięwzięciach. Organizatorem seminarium była firma IT-Consulting Jarosław Żeliński.

Uczestnicy w ankietach podkreślali, że problemy na jakie napotykali w swoich projektach bardzo często zaliczano do obiektywnych trudności. Byli zaskoczeni tym, że problemy te w większości przypadków były efektem stosowanych nieformalnych metod modelowania a nawet zaniechania budowania jakichkolwiek modeli organizacji, na rzecz sprawozdań ze spotkań warsztatowych czy burz mózgów.

Prowadzący seminarium (Jarosław Żeliński, założyciel firmy) prezentował metody formalizacji opisów działania firm, zasady stosowania standardów w tworzeniu modeli procesów biznesowych. Największe zainteresowanie zgromadzonych wzbudziły przykłady jak unikać niejednoznaczności w opisach działania firm oraz jak można, z pomocą poprawnie wykonanych modeli procesów i modeli logiki biznesowej, opracować spójne i bezpieczne dla projektu IT specyfikacje wymagań.

Największym zaskoczeniem było dla mnie to, że model jaki zaprezentowano, w logiczny sposób łączy w sobie perspektywę procesów biznesowych, strategię firmy,  kompetencje pracowników oraz informacje jakie przetwarzają. Faktycznie pracując metodami zaprezentowanymi na seminarium można wyeliminować przypadkowość z analiz przedwdrożeniowych. Dużym zaskoczeniem było dla mnie także to, że zaprezentowane metody zarządzania złożonością modeli prowadzą raczej do powstania kilkudziesięciu diagramów powiązanych z posiadanymi w firmie danymi o pracownikach (kadry) i regułach pracy (normy ISO, zarządzenia wewnętrzne itp.) a nie do setek diagramów dublujących w niespójny sposób informacje i tak przechowywane w firmie.

W trakcie prezentacji pokazane zostały: metody analizy, identyfikowania i modelowania procesów biznesowych, metody zarządzania regułami biznesowymi oraz zasady doboru szczegółowości tworzenia map procesów biznesowych. Zaprezentowano notacje BPMN oraz elementy notacji Business Motivation Model a także manifest organizacji Business Rules Group i metody ujmowania na modelach reguł biznesowych.

Uczestnicy w trakcie dyskusji przyznali, że jednym z powodów zainteresowania i obecności na seminarium jest różnorodność metod z jakimi spotykają się w swoich projektach. Jeden z nich przyznał wręcz:

Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że “tego nie można”, “to należy uprościć” albo “tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy prezentowane metody mogą nam tym razem pomóc?

Po seminarium, osoba ta przyznała, że gdyby zastosowano zaprezentowane metody, zapewne większości kłopotów i kosztów udało by się uniknąć.

Seminarium było bezpłatne, uczestnicy uznali, że taka idea promowania dobrych praktyk bardzo im się spodobała, i że planują uczestnictwo w następnych prezentacjach.

O organizatorze seminarium:

IT-Consulting Jarosław  Żeliński ? firma istnieje jako samodzielny podmiot od 2004 roku, jej właściciel od 1991 roku pracuje w branży IT jako analityk wymagań, projektant systemów, zajmuje się także projektami blisko powiązanymi z wdrożeniami oprogramowania to jest analizami procesów biznesowych i ich optymalizacją. Z usług firmy korzystały duże banki, spółki giełdowe praz mniejsze firmy a także urzędu państwowe. Obecnie firma prowadzi działalność ekspercką a jej właściciel jest uznawany za autorytet w dziedzinie modelowania biznesowego, w tym procesów biznesowych, modeli biznesowych oraz logiki oprogramowania wspomagającego zarządzanie. Znany jest ze stosowania standardów i sformalizowanych metod modelowania i notacji.  Dodatkowe informacje i kontakt z organizatorem: http://IT-Consulting.pl

17 Czerwca 2011 odbyło się seminarium na temat metodologii modelowania procesów w organizacjach i korzyści jakie dają sformalizowane metody modelowania. Seminarium zbudziło bardzo duże zainteresowanie. Wśród gości, osób zainteresowanych tą tematyką znaleźli się przedstawiciele operatorów telefonii komórkowej, instytucji finansowych i  największych urzędów. Po zakończeniu zgodnie stwierdzili, że poznane na seminarium zagadnienia tłumaczą wiele niepowodzeń związanych z reorganizacją i projektami IT i bardzo pomogą w planowanych przedsięwzięciach. Organizatorem seminarium była firma IT-Consulting Jarosław Żeliński.

Uczestnicy w ankietach podkreślali, że problemy na jakie napotykali w swoich projektach bardzo często zaliczano do obiektywnych trudności. Byli zaskoczeni tym, że problemy te w większości przypadków były efektem stosowanych nieformalnych metod modelowania a nawet zaniechania budowania jakichkolwiek modeli organizacji, na rzecz sprawozdań ze spotkań warsztatowych czy burz mózgów.

Prowadzący seminarium (Jarosław Żeliński, założyciel firmy) prezentował metody formalizacji opisów działania firm, zasady stosowania standardów w tworzeniu modeli procesów biznesowych. Największe zainteresowanie zgromadzonych wzbudziły przykłady jak unikać niejednoznaczności w opisach działania firm oraz jak można, z pomocą poprawnie wykonanych modeli procesów i modeli logiki biznesowej, opracować spójne i bezpieczne dla projektu IT specyfikacje wymagań.

Największym zaskoczeniem było dla mnie to, że model jaki zaprezentowano, w logiczny sposób łączy w sobie perspektywę procesów biznesowych, strategię firmy,  kompetencje pracowników oraz informacje jakie przetwarzają. Faktycznie pracując metodami zaprezentowanymi na seminarium można wyeliminować przypadkowość z analiz przedwdrożeniowych. Dużym zaskoczeniem było dla mnie także to, że zaprezentowane metody zarządzania złożonością modeli prowadzą raczej do powstania kilkudziesięciu diagramów powiązanych z posiadanymi w firmie danymi o pracownikach (kadry) i regułach pracy (normy ISO, zarządzenia wewnętrzne itp.) a nie do setek diagramów dublujących w niespójny sposób informacje i tak przechowywane w firmie.

W trakcie prezentacji pokazane zostały: metody analizy, identyfikowania i modelowania procesów biznesowych, metody zarządzania regułami biznesowymi oraz zasady doboru szczegółowości tworzenia map procesów biznesowych. Zaprezentowano notacje BPMN oraz elementy notacji Business Motivation Model a także manifest organizacji Business Rules Group i metody ujmowania na modelach reguł biznesowych.

Uczestnicy w trakcie dyskusji przyznali, że jednym z powodów zainteresowania i obecności na seminarium jest różnorodność metod z jakimi spotykają się w swoich projektach. Jeden z nich przyznał wręcz:

Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że “tego nie można”, “to należy uprościć” albo “tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy prezentowane metody mogą nam tym razem pomóc?

Po seminarium, osoba ta przyznała, że gdyby zastosowano zaprezentowane metody, zapewne większości kłopotów i kosztów udało by się uniknąć.

Seminarium było bezpłatne, uczestnicy uznali, że taka idea promowania dobrych praktyk bardzo im się spodobała, i że planują uczestnictwo w następnych prezentacjach.

Wczoraj byłem na zajmującym spotkaniu dotyczącym strategii i jej narzędzi jakimi są reklama i PR  (zarządzanie wizerunkiem). Organizator podsumował:

Skoro PR jest narzędziem marketingu, to rzeczywiście szukanie między nimi granicy wydaje się być utopią lub podstawowym błędem logicznym. Intuicyjnie (tylko) wyczuwamy wciąż jakąś różnicę. Tylko nie umiemy jej zdefiniować.

Z pomocą przyszedł, przynajmniej dla mnie, jeden z uczestników, który powiedział: ?dla mnie to jest tak, że jak ktoś chce mnie nakłonić do jakiegoś działania, np. zakupu, to jest to reklama, kiedy zaś pod wpływem działań, często przeze mnie nie uświadomionych, odczuwam potrzebę takiego działania, np. zakupu, to jest to PR?. (źr. Granica między marketingiem a PR-em | Filozofia marketingu.)

Zgodnie stwierdzono, że marketing to działania służące budowaniu zysku ze sprzedaży. Przetestujmy to. Ale zanim to kilka słów o powodach mojego zainteresowania tym tematem.

Paradoksalnie, większość projektów z gatunku Analizy Biznesowej polega w pierwszym rzędzie na zrozumieniu biznesu klienta. Bardzo wiele działań, nie raz sam zakup i wdrożenie jakiegoś oprogramowania, to element strategii marketingowej wprost (system wspomagający sprzedaż, kampanie reklamowe, promocyjne, projekty PRowe itp.).

Tworząc modele (taksonomie, klasyfikację kolekcjonowanych danych, słowniki pojęć  i wiele innych) podejmuje się modelowania tego co robi mój klient. Po co? Modelując procesy należy je zaklasyfikować,miedzy innymi do tego, jakie działania w strategii marketingowej wspierają. bez tego trudno określić, może to być wręcz nie możliwe, do czego się dany proces biznesowy przyczynia (i czy w ogóle).

Zacznijmy od kluczowej tu definicji:

Komunikacja marketingowa jest procesem przekazywania informacji innym podmiotom i wymaga występowania sześciu elementów: źródła, komunikatu, kanału komunikacji, odbiorcy oraz procesu kodowania i dekodowania. Źródło informacji stanowi podmiot, który ma do przekazania jakąś informację, może to być na przykład jakaś firma. Komunikatem, będzie informacja wychodząca ze źródła, na przykład informacją o obniżkach cen, która będzie przekazywana przez kanały komunikacji (np. reklamę prasową). Odbiorcą będzie osoba, do której dotrze komunikat. (źr. ?Marketing? K. Przybyłowski, S.W. Hartley, R.A. Keriu, W. Rudelius).

Celem jest tu zdefiniowanie przestrzeni nazw dla komunikacji marketingowej. Walczymy (usiłujemy określić  semantykę) z pojęciami [[Reklama]] i [[Public Relation]] (PR).

Reklama jest to sposób prezentowania oferty sprzedaży przez określonego przedsiębiorące- sprzedawcę, które odbywa się w formie masowej, odpłatnej i bezosobowej. Klasyfikację reklamy możemy dokonać w zależności od kryterium. Z punktu widzenia przedmiotu reklamę podzielimy na:

• reklamę produktu
• reklamę firmy

Kolejna definicja:

Public Relations to instrument komunikacji marketingowej, który zmierza do kreowania, podtrzymywania i utrwalania wzajemnie korzystnych stosunków pomiędzy przedsiębiorstwem lub określoną instytucją oraz daną grupą odbiorców (tzw. publics).

Celem public relations jest odpowiednie oddziaływanie na odczucia lub przekonania klientów, kształtowanie ich przychylnych opinii, tworzenie korzystnego wizerunku firmy (umożliwiającego stopniowe i perspektywiczne rozszerzanie jej rynku) oraz odpowiednie reagowanie na niekorzystne informacje.

Przy uwzględnianiu klientów istotną rolę odgrywają nie tylko ci obecni, ale także potencjalni oraz akcjonariusze, dostawcy, pracownicy i inne grupy docelowe, ważne ze strategicznego punktu widzenia dla firmy. (źródła definicji: http://mfiles.pl)

Nie wiem czy źródło definicji ma najwyższy autorytet w tej kwestii ale wygląda dość wiarygodnie :). Podejmijmy próbę narysowania tego (jak ja lubię rysować ;)):

Tak więc mamy po lewej jakąś fikcyjną firmę o nazwie ACME (chyba najbardziej znana firma na świecie :)). Po prawej mamy potencjalnego Kupującego (klienta). Typowe spotykane komunikaty to: o firmie (1), o produkcie (2), o kimś (3), o Kupującym (4).

Jeżeli Reklama to prezentacja Produktu lub Firmy to 2. jest klasyczną prostą reklamą. Komunikat 1. to klasyczny PR.

Zaczynają się schody dla 3. i 4. Oba przekazy maja za cel skłonienie Klienta do zakupu właśnie tego Produktu. Komunikat 3. bazuje na założeniu, że Klient ma tę potrzebę (szuka tego Produktu) , komunikat 4. to wzbudzenie potrzeby i wskazanie, ze ten Produkt ja zaspokoi.

Pierwsza hipoteza: k0munikat 1. to budowa wizerunku, pozostałe to reklama gdyż nakłaniają bezpośrednio do kupna Produktu. Jednak pojawia się utrudnienie. Typowym jest to, że Klient łączy Produkt z jego Producentem. Wtedy coś co ma konkretne cechy i cenę jest uwiarygadniane (jakość Produkt) źródłem pochodzenia. Co jeśli to źródło pochodzenia nie jest znane? Nazwa produktu musi zastąpić nazwę Producenta (marka). Pojawi się więc pojęcie wizerunku Produktu (PR Produktu).

Druga hipoteza: 1. i 3. to PR bu celem jest wzbudzenie zaufania, 2. i 4. to reklama bo celem jest bezpośrednie nakłonienie do zakupu.

Każdy sam musi teraz podjąć decyzje, który model jest użyty w jego firmie.

A teraz wrzucamy to do oprogramowania

Oprogramowanie związane z powyższymi działaniami to systemy mające w nazwie CRM ([[Customer Relationship Management]]). Pomijając spory na temat tego, co ten skrót oznacza, bardzo często pomaga zarządzać: strategią marketingową, reklamą, działaniami PRowymi itp. Mając powyższe modele, łatwiej zbudować system nadzoru (kontroling) nad procesami powiązanymi z marketingiem, gdyż daje szansę na jednoznaczną klasyfikację konkretnych działań (także wydatków) do Reklamy lub PR.

Dziękuję Maciejowi Tesławskiemu za zaproszenie na spotkanie Klubu Strategów Marketingu za inspirującą dyskusję.