Reguły biznesowe, decyzje i pojęcia

Jeżeli uzna­my, że mode­lo­wa­nie zacho­wa­nia orga­ni­za­cji w posta­ci mode­lu pro­ce­sów pole­ga wyłącz­nie na two­rze­niu dia­gra­mów zawie­ra­ją­cych kolej­no wyko­ny­wa­ne deta­licz­ne czyn­no­ści, to zna­czy że wszel­kie powy­żej opi­sa­ne zacho­wa­nia znaj­dą się jako rów­no­praw­ne” aktyw­no­ści na tych dia­gra­mach. Powstają mon­stru­al­ne nie­czy­tel­ne sche­ma­ty blo­ko­we, zawie­ra­ją­ce set­ki deta­li, trud­ne do inter­pre­ta­cji, trud­ne i kosz­tow­ne w utrzy­ma­niu (aktu­ali­za­cja), i przede wszyst­kim nie pozwa­la­ją­ce na wypro­wa­dze­nie wprost z nich wyma­gań na opro­gra­mo­wa­nie. Można w zasa­dzie zary­zy­ko­wać tezę, że tak two­rzo­ne mode­le, w któ­rych cała wie­dza o orga­ni­za­cji zosta­ła zapi­sa­na jako łań­cu­chy deta­licz­nie zobra­zo­wa­nych czyn­no­ści, tak na praw­dę do nicze­go nie są przy­dat­ne. […] Czemu więc słu­żą żmud­ne wywia­dy, warsz­ta­ty, burze mózgów w toku ana­liz firm? Zaryzykuję, tezę, że nicze­mu nie służą.

Czytaj dalej Reguły biznesowe, decyzje i pojęcia

Zdalna analiza wymagań

Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy,  ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for…

Czytaj dalej Zdalna analiza wymagań

Reguły – jakie nie powinny być…

Kolejny artykuł z gatunku "przemyślenia i rady na koniec roku" :) Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje…

Czytaj dalej Reguły – jakie nie powinny być…

Sekwencje a procesy

Warstwa pro­ce­sów, usług aplikacyjnych/przypadków uży­cia i kom­po­nen­tów to odręb­ne war­stwy i per­spek­ty­wy. Nie mie­sza­my więc ani pozio­mów abs­trak­cji ani per­spek­tyw mode­li. W prze­ciw­nym razie, ule­ga­jąc suge­stiom w rodza­ju ale ja chcę zoba­czyć to wszyst­ko na jed­nym dia­gra­mie” pcha­my pro­jekt w kie­run­ku utra­ty pano­wa­nia nad zło­żo­no­ścią”… To pro­sta dro­ga do klę­ski projektu.

Czytaj dalej Sekwencje a procesy

CASE czyli komputerowe wspomagania analizy i projektowania systemów

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Czytaj dalej CASE czyli komputerowe wspomagania analizy i projektowania systemów

Analiza Potrzeb Użytkowników i Dokumentowanie Wymagań na system ERP

Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…

Czytaj dalej Analiza Potrzeb Użytkowników i Dokumentowanie Wymagań na system ERP

Stosowane metody analizy biznesowej i projektowania

Jeżeli czegoś nie potrafisz narysować, to znaczy, że nadal tego nie rozumiesz, jeżeli coś jest trudne do narysowania, to tym bardziej będzie to trudne do realizacji.(JarosŁaw Żeliński) Wprowadzenie Podstawowe pojęcie…

Czytaj dalej Stosowane metody analizy biznesowej i projektowania

Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Jeżeli jed­nak oka­że (ana­li­za) się, że zakup pro­gra­mu ma pomóc, to nale­ży opi­sać wyma­ga­nia jakie taki pro­gram musi speł­nić (wyma­ga­nia wobec pro­duk­tu). Te wyma­ga­nia są pod­sta­wą do wybo­ru goto­we­go, dostęp­ne­go na ryn­ku opro­gra­mo­wa­nia, lub decy­zji o napi­sa­niu dedy­ko­wa­ne­go, jeże­li poszu­ki­wa­nia nie dadzą pozy­tyw­ne­go rezul­ta­tu (ale etap szu­ka­nia goto­we­go powi­nien dla zasa­dy mieć miej­sce). Dedykowane roz­wią­za­nie wyma­ga jego zapro­jek­to­wa­nia, to moż­na (zale­ca­ne) zro­bić przed wybo­rem wyko­naw­cy lub zle­cić wybra­ne­mu wcze­śniej wyko­naw­cy. Wariant dru­gi nara­ża nas jed­nak na utra­tę pano­wa­nia nad pro­jek­tem bo wyko­naw­ca będzie for­so­wał meto­dy budu­ją­ce mu mar­że a potem sam sobie świad­czy nad­zór autor­ski. Wbrew pozo­rom, anga­żo­wa­nie audy­to­ra pro­jek­tu, któ­ry nie jest auto­rem doku­men­ta­cji wyma­gań nie wno­si nic, a kom­pli­ku­je cały pro­ces: taki audy­tor może jedy­nie oce­nić zgod­ność dzia­łań pro­jek­to­wych z doku­men­ta­cją wytwo­rzo­ną przez (audy­to­wa­ne­go) wyko­naw­cę, a w przy­pad­ku spo­ru i tak tu wła­dzę” ma autor pro­jek­tu a nie audytor.

I teraz: ogło­sze­nie prze­tar­gu na całość na począt­ku tej dro­gi jest jak widać idio­ty­zmem bo nie mamy żad­nej wie­dzy by oce­nić wynik pra­cy a dostaw­ca żad­nej by cokol­wiek sen­sow­nie wyce­niać. Pominięcie jakie­go­kol­wiek z tych w/w opi­sa­nych eta­pów to pod­no­sze­nie ryzy­ka pro­jek­tu, co mam na dzie­ję widać. Każde wyma­ga­nie może być zero jedyn­ko­we na każ­dym z tych eta­pów, wystar­czy chcieć i umieć. Owszem, moż­na je dzie­lić na biz­ne­so­we itp… ale to tyl­ko sztucz­ne podzia­ły, po pro­stu pod­czas reali­za­cji mamy już tyl­ko etap i jego wyma­ga­nia. (Nieudane wdro­że­nie sys­te­mu biz­ne­so­we­go – czy­li uczmy się na błę­dach innych | LinkedIn).

I tyl­ko tu poja­wia się pyta­nie jak w fil­mie MIŚ: a może to fak­tycz­nie ma być dro­gie i nie­przy­dat­ne a ja zupeł­nie bez sen­su jestem tym zdziwiony?

Czytaj dalej Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych