Jak nie trudno się domyślić mam dużo do powiedzenia po konferencji o procesach biznesowych 🙂

Tym razem będzie to zestaw “dygresji”, postaram się by stanowiły spójną całość. Nie zastąpi to co prawda Państwu obecności na takich konferencjach ale pozwoli za to uzupełnić wiedzę, o rzeczy, których na nich nie powiedziano wprost lub w ogóle.

Nie było mowy o procesach biznesowych w kontekście biznesu, tylko firma Andersen Business Consulting zauważyła, że są jeszcze na świecie nasi klienci i dostawcy. Otóż generalne moje spostrzeżenie: prelegenci mówili o procesach biznesowych w kontekście narzędzi informatycznych (programów) do ich modelowania, symulacji, optymalizacji. Nie znalazłem żadnej prezentacji na temat stylistyki modelowania, kontekstu biznesowego i otoczenia.  Ku mojemu zaskoczeniu byłem chyba jedyną osobą, która w kwestii modelowania zauważyła istnienie nadrzędnego łańcucha wartości. Po drugie modelowanie to sztuka osoby modelującej a nie stopień skomplikowania programu wspierającego modelowanie. To tak jak by na kongresie malarstwa nowożytnego mówiono tylko o farbkach i pędzelkach.

Okazuje się, że użytkownikami narzędzi do modelowania są głównie konsultanci a nie pracownicy firm. Dlaczego?  Hm.. to jest dla mnie tajemnica ale jako zwolennik godzenia się z faktami uważam, że czas jest taki, że konsultanci mają do spełnienia także misje edukacyjną. I to nie dlatego, że biznes się nie uczy ale dlatego, że biznes musi mieć najpierw od kogo się uczyć. Jako konsultant zrobię więc co w mojej mocy by i tej roli sprostać. Po drugie narzędzia tego rodzaju są często narzędziami do wyprodukowania setek stron schematów. Jak zauważył to jeden z prelegentów, przedstawiciel biznesu, prawie nikt tego i tak nie rozumie i nie czyta. Dlatego nie taki model jest dobry, który jest szczegółowy aż do bólu. Dobry model to taki, który jest czytany przez kadrę i  rozumiany przez nią. Dlatego nie 500 stron a 50 poprosimy. Ale proszę Państwa, to wcale nie znaczy że wykonanie takiego modelu trwa krócej!

Mam dziwne przeczucie, że w ciągu kilku najbliższych lat na rynku zostaną narzędzia do wspomagania modelowania na poziomie biznesowym oraz dojrzałe systemy bazujące na procesowych fundamentach.  Systemy typu BPMS  (Business Process Management System) produkujące dziesiątki stron diagramów znikną. Jednym z głównych problemów wskazywanych na salach był obecny brak kompatybilności pomiędzy systemami do modelowania procesów a aplikacjami o strukturze procesowej. Czy tu pojawią się jakieś standardy? Nie sadzę, gdyż właśnie różnice między producentami tych systemów budują ich przewagę konkurencyjną (jestem lepszy bo odróżniam się od konkurencji czymś dobrym). Konsolidacja na tym rynku moim zdaniem nie będzie polegała na wzajemnym przejmowaniu się firm oferujących produkty typu BPMS a na przejmowaniu  dostawców BPMS przez dostawców systemów ERP, SCM, CRM, WfM (Workflow Management) itp. i tworzeniu kompletnych środowisk do modelowania i implementacji procesów biznesowych w postaci zintegrowanych systemów np. ERPII.

Problem z wdrożeniami BPM i systemów zintegrowanych np. typu ERP polega na próbie wmuszenia w organizacji nowego zwyczaju (procesowego podejścia) bez wcześniejszego procesu edukacji tych pracowników. Oni (pracownicy) przy całej swojej dobrej woli często nie widzą kontekstu swojej pracy na tle reszty  firmy dlatego nie przyjmują działań, których nie rozumieją. Rozpoczęcie wdrożenia systemu ERP bez przeprowadzenia edukacji wśród kadry i ewentualnie reorganizacji na ich własna prośbę (a to się udaje) z góry skazane jest na klęskę lub poważne trudności. Sposobem uniknięcia tego jest wdrożenie metod zarządzania zorientowanych na procesy a dopiero potem wdrażanie jakiegokolwiek systemu bazującego na procesach biznesowych. Proponuje zacząć od zdefiniowania i wdrożenia śledzenia mierników pracy w każdym punkcie współpracy (wymiany efektów pracy) pomiędzy komórkami organizacyjnymi w firmie. To się sprawdza!

Moja metoda modelowania i wdrażania systemu zorientowanego na procesy:

• skupić się na metodzie top-down (od ogółu do szczegółu, z góry w dół firmy): modelować firmę od góry, w trakcie modelowania przyporządkowywać zasoby do każdego procesu, po zakończeniu modelowania sprawdzić czy i jakie zasoby (komórki organizacyjne) nam “zostały”,
• Jeżeli cos “zostało” należy zidentyfikować przyczynę i doprowadzić do sytuacji gdzie nie ma “niepotrzebnych zasobów”,
• Otrzymany model zoptymalizować
• Zdefiniować “produkty” i “zamówienia” na wejściach i wyjściach procesów, zdefiniować ich miary,
• Wprowadzić etapami w życie tak opisany model,

Teraz można zacząć wdrażać procesowo zorientowane systemy IT bez ryzyka, że nikt ich tak na prawdę nie chce.

Wstęp

Podpis elektroniczny ma sens i jest przydatny wszędzie tam, gdzie wnosi dodatkową wartość w proces, który wspiera. Warunek tej przydatności: cykl życia technologii użytej do obsługi (używania) podpisu elektronicznego musi być istotnie dłuższy w porównaniu z cyklem życia produktu procesu, który wspiera.?

Na początku Października wywiązała się na liście dyskusyjnej PTI ([[Polskie Towarzystwo Informatyczne]]) dyskusja na temat bezpieczeństwa podpisu elektronicznego.

Dyskusja zapoczątkowana została notatką prasową na temat odkrycia przez jedną z firm informatycznych możliwości zmiany treści tak podpisanego dokumentu bez ?pozostawiania śladów?. Z uwagi na trudność administracyjną w przytaczaniu cudzych wypowiedzi (zebranie zgody na publikację od kilkunastu osób graniczy z cudem) postanowiłem utworzyć ten artykuł tylko z moich wypowiedzi na forum. Mam nadzieję, że ta postać także będzie dla Państwa czytelna.

Cytaty z moich wypowiedzi

Ja zadam takie pytanie: jakiej trzeba wiedzy i jakich narzędzi żeby sfałszować podpis elektroniczny a jakiej żeby podrobić “pisany”? Jaki odsetek ludzi potrafi i ma możliwość (zasoby) żeby sfałszować podpis elektroniczny a jaki odsetek ludzi ma możliwości, zasoby (długopis…?) fałszuje odręczne podpisy (i robi to nagminnie)?

Prawda, że jest to groźne jednak podrabia się nie wiszące w powietrzu podpisy a podpisy na dokumentach, trzeba je najpierw pozyskać… Zresztą na tej samej zasadzie bardzo łatwo podsłuchać i podrobić list (treść) e-mail i jakoś nie jest to zjawisko masowe……. Nie neguję konieczności ochrony dokumentów jednak zwróciłem tylko uwagę na to, że podpis powinien być wystarczająco dobry a nie najlepszy bo im lepszy tym droższy.

Jaki ma Pan zamek w drzwiach wejściowych? Czy wie Pan, że przeciętny włamywacz otworzy go po cichu prawdopodobnie w maksimum 15 minut? To są oficjalne dane z opisu zamka drzwiowego klasy C (być może ma Pan nawet zamek klasy niższej). I jak Pana spokojny sen??

Tak właśnie się kreuje niektóre produkty rynkowe: należy potencjalnego klienta dobrze wystraszyć a potem sprzedać mu stosowne dobre zabezpieczenie za stosowną dobra cenę. Dlatego między innymi sprzedają się stalowe drzwi do domków jednorodzinnych ze zwykłymi szybami w oknach (tak na jedna mała cegiełkę). Prawdopodobieństwo zdarzenia, którym jesteśmy straszeni jest znikome aczkolwiek nikt przy zdrowych zmysłach nie powie że niemożliwe i na tym polega tu sprzedaż.

Pytanie: kto zyska na sfałszowanej fakturze? Dlaczego jakiś czas temu uznano, że faktur (papierowych) nie trzeba podpisywać? Po co więc elektroniczne mają być podpisywane?

Domyślam się, że sprzęt i oprogramowanie służące do używania podpisu to niezły towar z fajną marżą (przypomina mi to czasy boomu internetowego).  Jakoś banki radzą sobie przez Internet doskonale bez elektronicznego podpisu (w wersji opisanej ustawą). Od lat producenci samochodów z użyciem EDI także radzą sobie doskonale. Nie dziwię się, że ustawowo dozwolony podpis elektroniczny jest jak na razie martwym prawem a kilka firm, które na tym zbudowały swój biznesplan już wiatr historii rozwiewa po pustymi.

Nie jestem sceptykiem co do samej technologii podpisu elektronicznego ale jak sobie zrobiłem model w którym ludzie i firmy “obracają” dokumentami elektronicznymi to jakoś ten model działa i nigdzie nie ma potrzeby użycia podpisu kwalifikowanego tj. jego użycie niczego nowego nie wnosi (wręcz przeciwnie), więc po co?. Jeżeli padnie pytane “a co z notariuszami” odpowiem: prawda tu spokojnie można użyć elektronicznego podpisu i załatwić spadek z pomocą e-mail’a ale…. gdzie wartość dodana skoro nośnik z treścią spadku podpisaną elektronicznie najprawdopodobniej będzie nie do odczytania za 10 lat więc trzeba go będzie przechowywać wraz z kompletnym komputerem z napędem i czytnikiem podpisów niezbędnych do jego odczytania. Wyobraźmy sobie, że ustawę uchwalono 4 lata temu i mamy w szafach faktury na dyskietkach 3,5″.

Moim zdaniem podpis doskonale sprawdza się jako narzędzie np. do uwierzytelniania łączy VPN bieżącej wymiany dokumentów ale nie mam przekonania do elektronicznego podpisywania dokumentów, których czas przechowania z definicji jest dłuższy od czasu starzenia się technologii użytej do podpisania.

Ktoś mógłby zapytać co to ma wspólnego z tematem postu. Ma i to bardzo dużo: podpisywanie dziś dokumentów w ten sposób jest bardzo niebezpieczne dla żywotności podpisywanych dokumentów. I nikt nie potrafi oszacować kosztów wieloletniego utrzymania takiego archiwum jednak wiadomo, że będzie musiało być okresowo w 100% przenoszone na nośniki nowej generacji. Ale biznes.

Ciekawe, że za najtrwalszy sposób zapisu nadal jest uważany papier……… po krótkiej fascynacji znowu wzrasta sprzedaż papieru fotograficznego…….

Wiec mamy coś w rodzaju początku wypracowywania stanowiska: podpis elektroniczny na największy sens i szanse zdobycia popularności nie w działalności gospodarczej a przede wszystkim w czynnościach cywilnoprawnych jednak zawsze równolegle będzie można załatwić wszystko na papierze (kompatybilność wstecz) np. dlatego, że nie każdego będzie stać na tę technologię a Państwo nie może się zobowiązać do jej bezpłatnego dostarczenia. 🙂

Swego czasu zaginęła mi karta kredytowa, wykonano nią kilka zakupów zanim zastrzegłem. Okazało się, że podpis służy tylko do ułatwienia (bez 100% gwarancji poprawności) weryfikacji przez sprzedawcę, który nie jest grafologiem. Po jego akceptacji i stwierdzeniu, że miał prawo nie odróżnić fałszywki od mojego podpisu obciążono mnie tymi kosztami (odrzucono reklamację).  Nie sądzę, by jakikolwiek sprzedawca przy każdej płatności karta wypukła angażował grafologa, nic by nie sprzedał. To pokazuje między innymi, że rynek i tak wymusza równowagę pomiędzy kosztem wprowadzenia rozwiązania (jakością skuteczności podpisu) i jego jakością a stratami wynikającymi z zaakceptowanego poziomu jakości.

Wydaje mi się, że ktoś wpadł na skądinąd dobry pomysł (podpis elektroniczny) jednak z narzędzia, które ma bardzo wąskie zastosowanie próbuje się zrobić produkt masowy. Zresztą widzę, że rysuje się coś co ja nazywam materialną i niematerialną potrzebą. Potrzeby materialne to dokument, który może być złożony w jakimkolwiek archiwum na lata. Tu konieczna jest możliwość użycia archiwum bez pomocy technologii. Potrzeby niematerialne to być może wszystkie pozostałe, szczególnie doraźne.

Tu po raz kolejny przytoczę, doskonały moim zdaniem przykład fotografii. Niezależnie od postępu technologicznego i możliwości zapisu zdjęć na coraz pojemniejszych nośnikach nadal niezastąpiony jest album fotograficzny działający zawsze i “bez prądu”. Nie ima się go czas ani postęp technologiczny (nie mówię tu o postępie w produkcji materiałów fotograficznych). Postęp technologii na razie wyeliminował w procesie powstawania zdjęcia zbędny etap jakim okazało się w większości przypadków naświetlanie i wywołanie filmu. Oczywiście w pewnych wąskich zastosowaniach, gdzie nośnik cyfrowy nie dorównuje kliszy ma ona zastosowanie jednak jest to już obecnie nisza.

Analiza łańcucha wartości jasno pokazuje, że jedną z istotnych wartości archiwum jest jego łatwa i powszechna dostępność, użycie tu technologii powoduje tylko dodatkowe problemy. W przypadku gdy wartością jest krótki czas dokonania transakcji, jej wiarygodność  i pokonanie dużej odległości podpis elektroniczny ma sens. Kolejny przykład: pamiętam jak swego czasu prześcigano się w prognozach kiedy to systemy wideokonferencyjne doprowadzą do zaniku podróży służbowych i co mamy?

Dla mnie wniosek jest jeden z tej dyskusji:

Wszyscy mają rację (ale to idiotycznie brzmi), każdy ze swojego punktu widzenia wydał najlepszą ekspercką opinię.

Efekt? Po zebraniu dotychczasowych opinii taki:

Podpis elektroniczny ma sens i jest przydatny wszędzie tam, gdzie wnosi dodatkową wartość w proces, który wspiera. Warunek tej przydatności: cykl życia technologii użytej do obsługi (używania) podpisu elektronicznego musi być istotnie dłuższy w porównaniu z cyklem życia procesu, który wspiera.

Na razie widzę, że klarują się dwa podejścia:

– IDEF0 lub ICOM i pochodne (w tym EPC i eEPC)

– inne idą w kierunku UML

IDEF0 to kompletny model logiczny uwzględniający zasoby i cele biznesowe (które niestety często zatraca się w procesie modelowania!). UML to droga do zaprojektowania aplikacji. Myślę, że tą drogą w środku spotkają się analitycy i programiści. W miejscu gdzie mamy model procesowy i procedury (workflow) na najniższym poziomie dekompozycji programista obiektowy ma wszystkie informacje by z pomocą UML zaprojektować i napisać kod aplikacji. Każdy prosty ?bloczek? modelu oraz interfejsy (formatki dokumentów) mogą teraz zostać zaimplementowane w systemie. Być może od strony modelowania BPMN (Business Process Modeling Notation) a od strony kodowania BPEL wniosą ułatwienie polegające na umożliwieniu pewnej automatyzacji tworzenia programów jednak w moim przekonaniu ważniejsze jest by precyzyjnie wskazać granice kompetencji pomiędzy analitykiem a inżynierem i dokładnie na tej granicy umieścić styk narzędzi analitycznych i inżynierskich.

Modelowanie to dziedzina prawie tak stara jak systemy informatyczne dla biznesu. Podstawowym celem modelowania procesów jest opisanie firmy, określenie celu projektu reorganizacyjnego i jego zakresu, określenie wymagań na tworzone oprogramowania a wcześniej optymalizacji organizacji i przygotowanie jej do wdrożenia. Stworzenie opisu funkcjonalnego tego co będziemy oprogramowywać zawsze było wyzwaniem trudnym. Drugim, być może jeszcze trudniejszym jest (do dzisiaj) nawiązanie nici porozumienia i zrozumienia pomiędzy sferą biznesu a inżynierami i programistami.

Jedna z ról jaką ma do odegrania wykonany przez analityków model jest stworzenie szkieletu aplikacji lub przynajmniej opisu tego szkieletu. Naturalnym dążeniem jest także próba uniknięcia ręcznego “przepisywania” pracy analityków biznesowych modelu i wygenerowanie na jego podstawie kodu aplikacji lub przynajmniej jej modelu np. w postaci UML.

Notacje i metodyki modelowania można podzielić  na dwie grupy:

1. modelowanie do prowadzenia analiz i optymalizacji procesów i zdarzeń gospodarczych (procesów biznesowych)
2. modelowanie do celów tworzenia oprogramowania

Na świecie nadal najpopularniejsze są: IDEF wśród analityków i UML wśród programistów.

Modele analityczne

Tu się niewiele zmieniło. Nadal w użyciu jest IDEF0 i jego odmiany a raczej warianty czyli ICOM  i mniej znany IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czyli Wejście, Sterowanie, Wyjście, Mechanizm (tu chodzi o zasoby). Skrót IGOE ma rozwiniecie: Input, Guide (odpowiednik sterowania), Output, Enabler (tu chodzi o zasoby w kontekście inicjatora realizacji danej funkcji). W obu przypadkach ogólny schemat procesu w tych konwencjach przedstawiany jest za pomocą prostokąta symbolizującego funkcję realizowaną przez proces oraz strzałki obrazujące wymienione cztery jego atrybuty :

Na tym poziomie powstało wiele produktów, które niestety zawierają swoje unikalne rozszerzenia symboli i reguł. Doprowadziło to powstania wielu narzędzi do modelowania, których produkty są ze sobą niekompatybilne już na poziomie użytych symboli. Nie wymieniając ich tu napisze, tylko, że w dość powszechnym użyciu jest ich prawie dziesięć a Gartner zidentyfikował ich na rynku trzydzieści sześć. Z tego też powodu używam w pracy symboli ICOM prostych i zrozumiałych dla biznesu zaś w przypadkach bardziej “sformalizowanych” używam IDEF0. Z uwagi na stały rozwój także tych metod ostanio zainteresowąłem się notacją BPMN.

Modelowanie do celów tworzenia oprogramowania

Ten temat jest dużo trudniejszy, gdyż dążenie do realizacji “sprzęgu” pomiędzy analitykiem a informatykiem to temat istniejący od początku czasów tworzenia oprogramowania do celów biznesowych. Krótka historia narzędzi do modelowania na potrzeby tworzenia oprogramowania (rok powstania i nazwa metody):

• 1962: sieci Petriego (Carl Petri Network)
• 1970: ANSI Flow charts
• 1979: DFD (Data Flow Diagram)
• 1982: ISO TC87 (ISO Conceptual Schema Model)
• 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
• 1992; EPC (Eventdriven Process Chains)
• 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
• 2001: ebXML v.1.1 (electronic business using eXtesible Markup Language)
• 2002: BPML v.1.1 (Busines Process Modeling Language)
• 2002: WSCi v.1.0
• 2003: BPEL4WS (Business Process Execution Language for Web Services)
• 2004: BPMN (Business Process Modeling Notation)

(na podstawie “Process modeling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of technology Information).

Sieci Petriego są nadal uważane za jedno z najskuteczniejszych narzędzi do modelowania jednak ich głównym ograniczeniem jest dość skomplikowany model matematyczny oraz brak hierarchizacji funkcji jak to ma miejsce w realnych organizacjach.  Nie zawiera też w sobie narzędzi do opisu  architektury obiektowej oprogramowania. Metody tworzenia oprogramowania zorientowane obiektowo doprowadziły do powstania narzędzi typu UML jednak są one bardzo trudne do zastosowania w modelowaniu biznesowym gdyż natura organizacji jest hierarchiczna a nie obiektowa. Modele obiektowe są po pierwsze praktycznie niezrozumiałe dla biznesu po drugie nie sprawdzają się jako narzędzie do opisu organizacji, która żyje i ewoluuje. Stale rozwijające się metody zarządzania ewoluują w stronę procesów biznesowych ich natura zaś jest jest hierarchiczna. Kolejną próbą rozwiązania problemu jest powstanie BPMN.

BPMN – Business Process Modeling Notation

Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się “tłumaczyć” na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego  np. model wykonany za pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu typu CASE.

Notatka: W tym roku (2005) opublikowano wersję 1.0 notacji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odbyła się konferencja BPMN Foundation na której między innymi ogłoszono połączenie Notation Working Group z OMG i specyfikację BPMN v.1.0. W planie jest RFC.