wtorek, 29 grudnia 2015

RE@BPM


Pełny artykuł w BPMstandard.pl
Ponadto, osoby zainteresowanych tematyką, zapraszam 23 marca 2016 na darmowe seminarium Stowarzyszenia Inżynierii Wymagań pod nazwą "RE@BPM".


W tytule proponuję trudne do zaakceptowania połączenie skrótów. „RE” to skrót od angielskiej nazwy inżynierii wymagań (requirements engineering), a BPM, jak doskonale wiecie, to skrót angielskiej nazwy zarządzania procesami biznesowymi (business process management). Na pozór, w codziennej praktyce, te dziedziny nie mają ze sobą wiele wspólnego, nawet nazwy zdają się należeć do różnych światów [...]

W rzeczywistości i w praktyce, obie te dziedziny łączą się ze sobą bardzo blisko, a ci, którzy jako pierwsi to dostrzegą i będą umieli wykorzystać, osiągną znaczną przewagę.


Kilka słów wprowadzenia do inżynierii wymagań

Inżynieria wymagań, to – według definicji ISO/IEC/IEEE 29119 – dziedzina interdyscyplinarna, zajmująca się metodami pozyskiwania, analizy, modelowania i konsolidacji wymagań, czyli założeń, które ma realizować konstruowany system informatyczny. [...]

Niezależnie od preferowanej nazwy, większość przyzna, że to dziedzina często zdumiewająco zaniedbywana, a dokładniej – realizowana jakby cichaczem, dyskretnie, ukryta za plecami innych. [...] Jakim cudem wobec tego sukcesem, czy choćby względnym sukcesem, kończy się jakikolwiek projekt? Otóż rolę analityka, lepiej lub gorzej, wykonują inni: kierownicy projektów, którzy muszą przecież choć w przybliżeniu znać cel działań, które nadzorują; programiści, mający niezwykły dar zarówno trafnego domyślania się, jak i talent do przeinaczania zleconych im do realizacji wymagań; wreszcie testerzy, których zadaniem, kiedy wszyscy inni zawiedli, jest zarówno zdobycie wymagań, jak i sprawdzenie, na ile testowany system je spełnia. [...]


Gdzie w BPM jest inżynieria wymagań?

Definiowanie procesów „as is”

Pierwszy krok BPM, czyli opis, czy diagnoza, aktualnego procesu biznesowego (as is), to niemal dokładnie ta sama czynność, którą analiza / inżynieria wymagań nazywają „pozyskiwaniem i wymagań”. [...]

W porównaniu z typowymi projektami IT, przedsięwzięcia BPM są w luksusowej sytuacji. Po pierwsze, decyzje o podjęciu BPM podejmowane są zwykle na wysokich szczeblach zarządzania, więc mają zasoby i poparcie, o których twórcy pojedynczych aplikacji mogą sobie tylko bezskutecznie pomarzyć. [...]

Negocjowanie wymagań

W inżynierii wymagań nie zapominamy, że różni interesariusze systemu IT zwykle mają także zróżnicowane poglądy na wymagania dla tego systemu – niekiedy wręcz przeciwstawne. [...]

Definiowanie procesów „to be”

Drugi obszar, gdzie technologie inżynierii wymagań mogą przydać się w zarządzaniu procesami biznesowymi, to projektowanie nowych, lepszych procesów, procesów zwanych przez BPM „które mają być”, czyli „to be”. Tak bowiem dzieje się w niejednym projekcie informatycznym, że kiedy klientowi przyjdzie do głowy, aby wesprzeć swój biznes jakąś aplikacją, systemem, to podczas zamawiania, a nawet – niestety - o wiele później, okazuje się, że tak naprawdę nie bardzo wiadomo, jakie procesy ten system ma wspomagać, albo że wymagają one przeróbek, poprawienia. [...]

Od wymagań do Javy w mgnieniu oka

Celem większości przedsięwzięć BPM jest najpierw zbudowanie, a potem modyfikowanie, ilekroć zajdzie potrzeba, kompleksowego, zintegrowanego systemu IT sterującego procesami biznesowymi, zwanego „BPMS” (Business Process Management System). Droga od modelu procesu, zapisanego w graficznym języku BPMN, do działającego systemu, prowadzi przez język BPEL (business process execution language, odmiana XML) do serwera, na którym skrypty BPEL są wykonywane, zwanego czasem „motorem BPEL” (BPEL engine). [...] trzeba więc wrócić na ścieżkę tradycyjną, skonstruować oprogramowanie w języku takim jak Java, C#, czy jednym w wielu innych. Opisując wymagania dla tych aplikacji, zwykle nie posługujemy się ani BPMN, ani BPEL, tylko – o zgrozo – językiem naturalnym, lub innymi językami modelowania, zwykle należącymi do rodziny UML. [...]


Nie tylko RE@BPM, ale także BPM@RM

Potencjalne korzyści współpracy idą w obu kierunkach. IT cierpi od początku swego istnienia, więc już blisko 70 lat, na problem z niejasnymi, niejednoznacznymi, często niespójnymi wymaganiami. Jest wiele przyczyn tego stanu rzeczy, ale głównym ich źródłem jest, moim zdaniem, nasze przywiązanie do języka naturalnego jako medium do porozumiewania się. Według wielu antropologów, powstanie języków wśród naszych przodków 100 – 50 tysięcy lat temu służyło głównie utrzymywaniu spójności grup hominidów, czyli relacjom, wzajemnemu „iskaniu się”, jak zabawnie wyrażają to badacze naczelnych. [...]


Jakość procesów

Podejście BPM zwykle – jeśli nawet nie w teorii, to w praktyce – bardzo wąsko widzi optymalizację procesów, którą stara się zrealizować na drodze od „as is” do „to be”. Dominuje nacisk na redukcję kosztów, którą zwykle osiąga się poprzez wyeliminowanie rzekomo zbędnych kroków i zadań procesu, zmniejszenie liczby uczestniczących w nim osób, lub likwidację czasowych wąskich gardeł.
Nie negując, że czasem procesy zawierają zbędne kroki czy zbędne zawiłości, aż proszące się o eliminację, to koszty są wyłącznie jednym z wielu atrybutów jakości procesu. Tutaj BPM może nauczyć się od inżynierii wymagań szczególnie dużo. [...]


Ulepszanie procesów w IT

Stare przysłowie „szewc bez butów chodzi”, w odniesieniu do procesów IT sprawdza się w 100%. Z jednej strony, IT dostarcza technologii, pozwalających na szybkie, elastyczne zmiany, na ulepszanie i automatyzację najbardziej nawet tradycyjnych procesów. Jednocześnie, swoje własne procesy, procesy wytwarzania oprogramowania, zwykle traktuje metodami z epoki kamienia łupanego. Standardy i sylabusy, popularne i autentycznie przydatne: PMI, PRINCE 2, ITIL, IPMA, IIBA, IREB, ISTQB, ISO 12207 – opisują swoje procesy… słowami. Rozbudowane metodyki oceny dojrzałości – np. CMMI, SixSigma, ISO 15504 („SPICE”), TMMi czy TPI oferują „jedynie słuszne” kryteria jakości procesów, ignorując potrzebę ich dostosowania do kontekstu. Nawet rodzina metodyk agile, choć akceptuje fakt, że wzorcowy proces nie musi, nie powinien nawet być zbyt szczegółowy, lecz oferować raczej minimalistyczne rusztowanie (framework) [...]

Pod tym względem BPM jest narzędziem, które – zastosowane do procesów samego IT – może stać się motorem jakże potrzebnej w IT zmiany.

Brak komentarzy:

Prześlij komentarz