234 Znaleziono wyniki wyszukiwania

Szukałeś: "reguły biznesowe"
Inżynieria wymagań

Inżynieria wymagań

Jak widać, z zupełnie z innej strony “odkryliśmy” coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!

Czytaj dalej Inżynieria wymagań
Kolejna wpadka IT: obiektowość

Kolejna wpadka IT: obiektowość

obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy “świata” i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie – obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).

Czytaj dalej Kolejna wpadka IT: obiektowość
Sami zbudujemy oprogramowanie…

Sami zbudujemy oprogramowanie…

Od dłuższego czasu nurtuje mnie czym kierują się ludzie zawierający umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu. Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).

Czytaj dalej Sami zbudujemy oprogramowanie…
Proces to strategia nie taktyka

Proces to strategia nie taktyka

Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy – podstawowe narzędzie analizy i modelowania.

Czytaj dalej Proces to strategia nie taktyka
Opis stanowiska pracy architekta korporacyjnego

Opis stanowiska pracy architekta korporacyjnego

Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.

Czytaj dalej Opis stanowiska pracy architekta korporacyjnego
Macierz RACI czyli jak nie zużyć hektara papieru

Macierz RACI czyli jak nie zużyć hektara papieru

Kolejne przeprowadzone szkolenia za mną, kolejna seria trudnych pytań też. Na szkoleniach z analizy biznesowej podaję, poza opisem dobrych praktyk, także anty-przykłady. Jednym z typowych anty-przykładów są diagramy zbyt szczegółowe, w szczególności próby “narysowania” konsultacji, serii zapętlonych zgłaszanych uwag do dokumentów i ich akceptacji, dziesiątek przekazywanych komuś innemu informacji. Diagram procesu BPMN nafaszerowany dziesiątkami rombów z wieloma wyjściami w rodzaju kto i w jakich warunkach ma coś skontrolować, zaakceptować, odesłać do poprawy itp. To mega diagramy, niemożliwe do zrealizowania próby algorytmizacji pracy modelowanej firmy (żadna firma nie jest deterministyczna). Przypomnę, że na poziomie procesów biznesowych (wewnętrzny łańcuch wartości) “pętle wstecz” reprezentują cofnięcie się w czasie, a czy to faktycznie ma miejsce?

Czytaj dalej Macierz RACI czyli jak nie zużyć hektara papieru
Procedura – co to za zwierzę

Procedura – co to za zwierzę

Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego “przejścia” (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożona normę ISO9000, to modelując procesy biznesowe i “podpinając” do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcja.

Czytaj dalej Procedura – co to za zwierzę