Read more about the article Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP
11392158 - the great east japan earthquake

Dyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Krótki wstęp

Od cza­su do cza­su są takie momen­ty, że świat pod­su­wa mi goto­we tek­sty do publi­ka­cji. Każdy kto mnie zna i czy­ta wie, że od lat odra­dzam wdra­ża­nie wiel­kich mono­li­tów ERP, uza­sad­nie­nie tego z moich ust naj­czę­ściej jest jed­nak odbie­ra­ne jako moje spe­ku­la­cje (mimo, że zawsze uza­sad­niam swo­je zda­nie a przy­kła­dów nie bra­ku­je). A o tym sądzą dyrek­to­rzy firm?

(wię­cej…)

Czytaj dalejDyrektorzy mówią Dość! Biznes wychodzi z objęć monolitycznego systemu ERP

Fundament analizy: metodyka

Nieco ponad rok temu opisywałem sytuację, w której pewien doświadczony analityk narzekał, że pracownicy jego klientów nie potrafią mu powiedzieć czego chcą i jak ma działać ich przyszły system. Odpowiedź moja jest w takich sytuacjach zawsze taka sama: ...analiza nie polega na słuchaniu! (wyobrażacie sobie leczenie, w którym diagnozy stawiają pacjenci?). Nie raz tu pisałem i kolejny raz powtórzę:Analiza oparta na zeznaniach i życzeniach jej [firmy zamawiającego] pracowników jest bardzo narażona na fiasko, gdyż subiektywna wiedza pracowników oraz ich spekulacje, mogą nie mieć wiele wspólnego z rzeczywistością lub pożądanym stanem…

Czytaj dalejFundament analizy: metodyka

Logika ogólna czyli o słownikach i prawach

Dwa lata temu pisałem o budowaniu słowników pojęć jako kluczowymi elemencie każdego dokumentu analitycznego. (trójkąt semiotyczny) Tak więc podejmując się analizy, warto robić to ?dobrze?, można to nazwać metodą naukową i nie będzie w tym przesady. Reguły biznesowe, rygory ich tworzenia, słownik pojęć, model pojęciowy, to wszystko służy poprawie jakości wyników analizy, dokumentacji, późniejszego projektu. Specyfikacja SBVR bardzo w tym pomaga. (o formalizacji modeli)Jeżeli mieliście kiedyś problem z projektem, to jest bardzo prawdopodobne, że jedną z kluczowych tego przyczyn był zły (lub jego brak) model  pojęciowy.Analitycy! Studiujcie logikę. Źródło: ?1?…

Czytaj dalejLogika ogólna czyli o słownikach i prawach

Wymagania umarły. Rozwiązaniem jest cykl życia produktu

Jak to mawiał mój dawny profesor filozofii: "gdy dwóch mówi to samo to już nie jest samo".  To co nazywamy "zwinnym podejściem" to coraz częściej uznanie nieskuteczności metody polegającej na "zbieraniu wymagań" i obrona przed "obiecaniem z góry tego co ma powstać", bo nikt nie wie czym to coś będzie jak już powstanie...(o ile powstanie). Takie głosy pojawiają się coraz częściej, i to nie od wczoraj.... Dzisiaj metody oparte na abstrakcji Takie "pomysły" jak MDA (architektura bazująca na modelowaniu), MDE (inżynieria bazująca na modelowaniu), notacje BPMN, UML, SysML, SoaML i…

Czytaj dalejWymagania umarły. Rozwiązaniem jest cykl życia produktu

Visual Paradigm 14.0 czyli efektywniejszy analityk

19 Grudnia opu­bli­ko­wa­no nową wer­sję pakie­tu Visual Paradigm: 14.0, w sto­sun­ku do poprzed­nie (13.2) wie­le ulep­szeń i kil­ka nowych zaba­wek”. Nie będę opi­sy­wał wszyst­kich (szcze­gó­ły na stro­nie pro­du­cen­ta, link na koń­cu artykułu). 

Na począ­tek waż­na uwa­ga i wyja­śnie­nie: korzy­sta­nie z narzę­dzi CASE z rów­no­le­głym two­rze­niem doku­men­tów na boku”, z uży­ciem pakie­tów biu­ro­wych jest kom­plet­nie pozba­wio­nym sen­su podej­ściem: tra­ci­my 3/4 war­to­ści tych narzę­dzi, jaką jest gene­ro­wa­nie ad-hoc wyso­kiej jako­ści, spój­nej, kom­plet­nej i nie­sprzecz­nej doku­men­ta­cji. Modele two­rzy­my z kil­ku powo­dów: zapi­su­je­my wyni­ki ana­li­zy, pro­jek­tu­je­my roz­wią­za­nia, testu­je­my je, ale przede wszyst­kim prze­ka­zu­je­my tę wie­dzę, czy­li two­rzy­my doku­men­ty opi­su­ją­ce efek­ty naszej pra­cy. Główną pra­cą jaką wyko­nu­je ana­li­tyk jest ana­li­za i pro­jek­to­wa­nie. Jeżeli więc two­rze­nie doku­men­tów zaj­mu­je mu wię­cej niż umow­ne 20%, sta­je się po pro­stu nie­efek­tyw­ny czy­li bar­dzo kosz­tow­ny. Często spo­ty­kam się z sytu­acją gdy tak na praw­dę 90% cza­su ana­li­zy zaj­mu­je spo­ty­ka­nie się i mozol­ne two­rze­nie doku­men­tów, 10% to fak­tycz­na ana­li­tycz­na i twór­cza pra­ca. To mega mar­no­traw­stwo (lub kom­plet­ny brak sza­cun­ku dla zama­wia­ją­ce­go). Dlatego gene­ro­wa­nie wyso­kiej jako­ści mery­to­rycz­nej doku­men­ta­cji (a nie tyl­ko ślicz­nie sfor­ma­to­wa­nej) jest klu­czo­wym ele­men­tem dobre­go pakie­tu CASE (poza oczy­wi­ście zesta­wem nota­cji i ich zgod­no­ścią ze stan­dar­da­mi). Tu tyl­ko wspo­mnę, że od wie­lu lat nie uży­wam edy­to­rów tek­stów do two­rze­nia pro­duk­tów swo­jej pra­cy (w tym obsza­rze). (wię­cej…)

Czytaj dalejVisual Paradigm 14.0 czyli efektywniejszy analityk

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…

Czytaj dalejMDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Idealizacja w toku projektowania czyli proste jest piękne

Nie raz pojawiały się tu (mój blog) odniesienia do tak zwanego ideału (idealizacja ) jako wzorca lub szkieletu. W artykule o studium wykonalności pisałem: Brak wiedzy o stanie idealnym możliwym i brak modelu, czyni analizę wykonalności bardzo ryzykowną, więc praktycznie bezwartościową. (Źródło: Studium wykonalności ? czym naprawdę jest | | Jarosław Żeliński IT-Consulting) Dzisiaj kilka słów o jednym z "kilerów" projektów analitycznych: utrata panowania nad szczegółowością. Detale, detale... Praktycznie zawsze w toku odbioru wyników prac analitycznych słyszę: "ale tu nie ma wielu rzeczy". I jest to prawda, ale nie ma (zostały…

Czytaj dalejIdealizacja w toku projektowania czyli proste jest piękne
Read more about the article Produkt analizy jako twierdzenie naukowe
praca grupowa,

Produkt analizy jako twierdzenie naukowe

Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być). Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często ;) ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność. Wprowadzenie Ludzie i ich praca…

Czytaj dalejProdukt analizy jako twierdzenie naukowe

Koncepcja to nie wymagania!

"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.

Czytaj dalejKoncepcja to nie wymagania!

Model pojęciowy, model danych, model dziedziny systemu

Niemalże każde spotkanie projektowe, na którym omawiane są modele UML, na każdym szkoleniu na temat UML, pojawia się problem o którym pisze Ron Ross (wytłuszczenia moje): Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That?s wrong. A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It?s about communication. A logical data model is about how you organize what you think you know about the world…

Czytaj dalejModel pojęciowy, model danych, model dziedziny systemu

TDD – czy same testy to wymagania?

Na niedawno zakończonej konferencji beIT organizowanej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygłosiłem referat zatytułowany Filozofia czyli Aplikacja jako element biznesowej rzeczywistości (a nie gra komputerowa). Przesłanie tej prezentacji to: Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polegać na zrozumieniu i udokumentowaniu mechanizmu działania "tego czegoś" a nie jedynie na spisaniu zewnętrznych oznak tego działania i zarządzanie tym spisem. Referat miał lekkie podłoże filozoficzne :). Ten artykuł nie będzie jednak powtórzeniem referatu (wyżej link…

Czytaj dalejTDD – czy same testy to wymagania?

Model to mechanizm

Wstęp

Niedawno pisa­łem o regu­łach biz­ne­so­wych i poli­ty­kach postę­po­wa­nia w zarządzaniu:

…zamiast brać na sie­bie, jako pre­zes fir­my, mene­dżer śred­nie­go szcze­bla itd. ogrom zda­rzeń w posta­ci podej­mo­wa­nia decy­zji za każ­dym razem, gdy jest taka wyma­ga­na, moż­na stwo­rzyć sys­tem poli­tyk, zesta­wów reguł biz­ne­so­wych, skut­kiem cze­go fir­ma będzie spraw­nie funk­cjo­no­wa­ła nie anga­żu­jąc, nawet do bar­dzo try­wial­nych zadań, wyso­kich ran­gą pra­cow­ni­ków. Nie jest to dele­go­wa­nie upraw­nień, poli­ty­ki i regu­ły biz­ne­so­we to rodzaj z góry pod­ję­tych decy­zji. Owszem żad­nej fir­my nie da się zal­go­ryt­mi­zo­wać, dla­te­go zawsze wyż­sze kadry będą potrzeb­ne jed­nak ich klu­czo­wą rolą jest usta­la­nie zasad i zarzą­dza­nie nimi a bez­po­śred­nie reago­wa­nie powin­no doty­czyć tego ?nie­zal­go­ryt­mi­zo­wa­ne­go? zakre­su zda­rzeń (op. 20% :), regu­ła Pareto). Zarządzanie zorien­to­wa­ne na regu­ły biz­ne­so­we to wła­śnie takie podej­ście: to cze­go moż­na się spo­dzie­wać, opi­su­je­my regu­ła­mi, zda­rze­nia wyjąt­ko­we obsłu­gu­je­my oso­bi­ście. Reguły biz­ne­so­we war­to zebrać w jed­no miej­sce, ?wyjąć? je z prze­ro­śnię­tych opi­sów zakre­sów obo­wiąz­ków i kom­pe­ten­cji, upo­rząd­ko­wać zarzą­dze­nia zarzą­du. (Reguły biz­ne­so­we i poli­ty­ki jako mecha­nizm dzia­ła­nia orga­ni­za­cji | | Jarosław Żeliński IT-Consulting)

W powyż­szym cyta­cie wytłu­ści­łem klucz dzi­siej­sze­go wpi­su: mecha­nizm (ale nie ma tego sło­wa w powyż­szym cytacie).

(wię­cej…)

Czytaj dalejModel to mechanizm

Koniec treści

Nie ma więcej stron do załadowania