Temat: BPM to nie jest programowanie

Sam także spotykam się z dziwnymi stwierdzeniami, że procesy biznesowe, UML, SOA, BPMN/BPEL, itp. to robota dla programistów.

Zanim powstanie choć jedna linia kodu powinien powstać model organizacji gdyż dobry model zastępuje tę organizację jak materiał do badań, także na okoliczność analizy wymagań na oprogramowanie (tak!).

Model organizacji pozwala także zoptymalizować ją zanim zaczniemy cokolwiek utrwalać w niej implementując jakiekolwiek oprogramowanie.

Jaki to model? Otóż praktyka pokazuje, że najlepiej sprawdza się (najlepiej opisuje organizacje) model procesowy, który z programowaniem nie ma nic wspólnego, nie bezpośrednio, gdyż paradoksalnie, model procesów jest doskonałym narzędziem do analizy wymagań na oprogramowanie.

Ciekawy artykuł:
http://www.infoq.com/news/2009/01/BPMSoftwareEngineering

Temat: BPM to nie jest programowanie

SOA jest z jednej strony robota dla programistow a z drugiej dla testerow. Dlaczego? Otoz wiekszosc rozwiazan SOA opiera sie na zaprojektowaniu uslug w ramach xml, wsdl, tego nie da sie inaczej wykonac. Przez ostatnie miesiace mojej kariery w CU bawilem sie w to, tj przy pomocy oprogramowania SOAPUI http://eviware.com testowalem wywoalania uslug przygotowanych przez programistow. Jak to jest zrobione. Otoz w systemie dziedzinowym jest oprogramowanie przekazujace dane z bazy danych do specjalnego przekaznika do ktorego podlaczamy uslugi wystawione na okreslonym porcie serwera, nastepnie w SOAPUI tworzymy projekt ktory "zaciaga" uslugi z danego adresu i przystepujemy do zmudnego testowania. Samo testowanie to wywolywanie uslug zblizonych do dzialan na interfejsie uzytkownika, sprawdzamy czy dane przechodza, czy sa zapisywane itp
Tak wiec teoria mowi cos innego a praktyka cos innego.

Powyzsze wyszlo nam na podstawie analiz biznesowych i potrzeb organizacji do zbudowania takich uslug. To sie wzielo z tego ze w specyfice firmy ubezpieczeniowej ktora zawiazala spolke z bankiem jest koniecznosc sprzedazy ubezpieczen poprzez okienka bankowe. W tym momencie zostal zaprojektowany zestaw uslug ktore bank bedzie wykorzystywal do dzialalnosci operacyjnej przy uzyciu platformy ESB. Nie tylko bedzie cos sprzedawal ale juz po okresie subskrypcji bedzie odpytywal system dziedzinowy o rozne dane. Dlatego powstaly uslugi SOA :)

Ale to nie oznacza ze sie z toba nie zgadzam. Wszystko zalezy od modelu operacyjnego, ktory u nas jest okreslony jako UMO :)

Co do BPMN ktory realizowalem w ramach INTALIO Designer (polecam, znowu freeware:) ) to jest lepszy przyklad na budowe modelu. Przy uzyciu tej aplikacji modelowalismy procesy zachodzace przy obsludze produktow w banku i firmie ubezpieczeniowej. Aplikacja latwa i przyjemna, podobna do MS Visio w sensie diagramow, jednak ma pare wad. Np gdy wlaczysz do procesu kilku aktorow (w postaci organizacji) wowczas musisz sie przygotowac na wygenerowanie olbrzymich wydrukow, ktore musielismy sklejac tasma zeby pokazac dokladny przebieg procesu. Inna wada to "zwieszanie" aplikacji w kluczowym momencie podczas zapisu itd.

Rysunki w Intalio mialy cel tzw use case czyli jak powinien przebiegac proces biznesowy. Generowalismy sciezke pozytywna, negatywna i zamykalismy proces jesli zachodzila taka koniecznosc.
Z pktu widzenia projektowania modelu Intalio mialo swoje odzwierciedlenie w specyfikacji wymagan, a dokladnie przy opisie produktu. W naszej specyfice chodzilo generalnie o to co ma sie dziac kiedy klient podejdzie do okienka bankowego, co sie ma dziac kiedy bank przesle pliki do nas itp. Przydatna sprawa przy projektowaniu, chociaz troche nieuzyteczna przy testowaniu, malo kto testujac dokladnie ogladal procesy wklejone z Intalio do MS Word i zazwyczaj dowiadywal sie od analitykow jak to jest zrobione i jak cos dziala :)Adam C. edytował(a) ten post dnia 27.01.09 o godzinie 07:39

Temat: BPM to nie jest programowanie

Jarek Żeliński:

Zanim powstanie choć jedna linia kodu powinien powstać model organizacji gdyż dobry model zastępuje tę organizację jak materiał do badań, także na okoliczność analizy wymagań na oprogramowanie (tak!).

A czy tworzenie modelu to nie istota inżynierii oprogramowania? Programowanie można porównać to pracy rzemiślnika, tworzenie modelu - planu, jest zdaje się istotą inżynierii.

K

Temat: BPM to nie jest programowanie

Jarek Żeliński:
Zanim powstanie choć jedna linia kodu powinien powstać model organizacji gdyż dobry model zastępuje tę organizację jak materiał do badań, także na okoliczność analizy wymagań na oprogramowanie (tak!).

Model organizacji pozwala także zoptymalizować ją zanim zaczniemy cokolwiek utrwalać w niej implementując jakiekolwiek oprogramowanie.

Jaki to model? Otóż praktyka pokazuje, że najlepiej sprawdza się (najlepiej opisuje organizacje) model procesowy, który z programowaniem nie ma nic wspólnego, nie bezpośrednio, gdyż paradoksalnie, model procesów jest doskonałym narzędziem do analizy wymagań na oprogramowanie.

Nie wiem czy na temat, ale moim zdaniem zanim zaczniemy coś budować trzeba ocenić krytycznie stan istniejący i przeprowadzić jego analizę. mając taką wiedzę dopiero budujemy modele. Jakie podejście jest właściwe - nie wiem ? ja preferuję systemowe.

Temat: BPM to nie jest programowanie

Budowę każdego systemu, który później ma być wykorzystywany w organizacji ZAWSZE (z podkreśleniem i pogrubieniem) powinno poprzedzić się dobrą analizą.
Analiza biznesowa i procesowa organizacji wiążą się z programowaniem, ale nie bezpośrednio. Tylko mając bardzo dobre pojęcie o samej strukturze i produktach organizacji można przystąpić do modelowania jej a następnie dopiero do tworzenia kodu.
Przykładowo jest to w RUPie - najpierw analiza potem tworzenie. Takie podejście do sprawy, że programista powinien robić wszystko wiąże się według mnie trochę z tym, że polski informatyk/programista musi wiedzieć wszystko i sam wszystkim się zająć. W poważnym przedsięwzięciu informatycznym powinien jednak nastąpić odpowiedni podział na role, by skutecznie zarządzać całym cyklem życia projektu.
Bardzo ciekawym podejściem jest stosowanie odpowiednich kompilacji metodyk oraz procesu wytwarzania oprogramowania (PRINCE2 oraz RUP) Polacy mają doświadczenie też promując XPRINCE.
Niestety prawdą też jest, że w polskich realiach mało która organizacja pozwala sobie na poprawne postępowanie według światowych standarów. Skutkiem takiego działania są potem buble - gdzie klient dostaje zupełnie co innego niż zamawiał. przypomina mi się tu znany chyba wszytkim komiks z modelem huśtawki na drzewie :D Wdrożenia projektów potem trwają latami, bądź całkowicie upadają. Nie wspomnę już jak kiedyś byłem świadkiem wdrożenia Axapty w pewnej spółce księgowej, gdzie Księgowa prosiła wdrożeniowca o dodanie bardzo ważnego dla ich pracy formularza, a usłyszała krótkie - tego się nie da zrobić. Ręce mi wtedy opadły - bo przecież w informatyce zrobić można wszystko, pytanie tylko na kiedy, bo to implikuje za ile to się zrobi.

Podsumowując, według mnie analiza organizacji zamawiającej jakiś system jest kluczowa dla powodzenia całego projektu i powinno się jej przywiązywać jak największą uwagę, bo to pozwoli w późniejszym czasie sprawniej i lepiej zrealizować cały projekt. Dopiero mając dobry model można zająć się klepaniem kodu. Wielokrotnie słyszałem, że znacznie to skraca czas - bo nie trzeba potem przebudowywać całego systemu i budować jakiś jego elementów od podstaw. Powinna to wykonywać osoba mająca doświadczenie w tej dziedzinie i także w programowaniu - dlatego takim specjalistą można zostać dopiero mając kilkuletnie doświadczenie.Andrzej Chęć edytował(a) ten post dnia 27.01.09 o godzinie 10:02

Temat: BPM to nie jest programowanie

Spróbuje to uporządkować (nawet sobie samemu):
- określić cel np. zwiększenie sprzedaży
- podjąć decyzję a wiec:
-- zbudować model organizacji (procesy i strukturę zasobów)
-- upewnić się, że rozumiemy od czego zależy poziom sprzedaży w organizacji
-- zidentyfikować procesy mające wpływ na poziom sprzedaży
-- sprawdzić czy obecny stan jest optymalny, jeśli nie zoptymalizować (procesy i strukturę zasobów)

do tej pory był BPM

-- na optymalnym modelu wskazuje to co należy wesprzeć (wybrane procesy) by zwiększyć poziom sprzedaży (wybór zakresu projektu) ograniczeniem zakresu jest budżet wynikający z rentowności projektu
-- na bazie wyłonionych do projektu procesów tworzę listę tych procesów, które planuję wesprzeć informatycznie
-- opisuję czego oczekuję (jakich funkcjonalności) od nowych zasobów w każdym tych procesów, powstaje lista usług i powiązań między nimi czyli koncepcja architektury systemu (tu zorientowanej na usługi)

to było SOA

-- mając listę usług i to jakie zadania powinny realizować stworzyć specyfikację każdej usługi
-- dla każdej usługi stworzyć model Use Case (np. usługi jako podsystemy)
-- dla całego systemu model dziedziny

to była analiza i specyfikacja wymagań, teraz będzie RUP i implementacja np. (ale nie koniecznie) z pomocą webserwisów.
Tu dopiero pojawia się kodowanie....

-- uruchomić projekt implementacji systemu

to moim zdaniem słuszna kolejność...Jarek Żeliński edytował(a) ten post dnia 27.01.09 o godzinie 10:54

Temat: BPM to nie jest programowanie

Przeczytany artykułu odniosłam do gruntu na którym pracuje, jak i swoich doświadczeń w tym zakresie i naszły mnie pewne przemyślenia...realizacja wielu procesów biznesowych na moim firmowym podwórku jest bardzo silnie wspomagana przez systemy informatyczne, w tym system procedur work-flow i to już od 2001 roku… kiedy to nic albo niewiele było słychać o BPML etc. Zbudowanie procedur work-flow zostało powierzone zespołom pracowników, z których bardzo niewielu miało podbudowę informatyczną, natomiast zostali gruntownie przeszkoleni z posługiwania się narzędziem do budowy tych procedur. Część dokumentacji procesów biznesowych przez wiele lat stanowiły diagramy procedur work-flow wspierających procesy… dopiero od niedawna budujemy modele graficzne podstawowych procesów biznesowych z pełną świadomością, że system procedur work-flow jest systemem wspomagającym przebiegi procesów. Procedury work-flow wtedy zaprojektowane, podlegały i podlegają modyfikacjom bardzo silnie sprzęgając się przez te lata z systemami dziedzinowymi. Inny charakter przybrała także współpraca pomiędzy odpowiedzialnymi za zarządzanie, poprawne funkcjonowanie procesów biznesowych, a technicznie nimi administrującymi, programistami etc.