także analiza przedwdrożeniowa

Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :).  O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…

Czytaj dalejVisual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Architektura korporacyjna a strategia wzrostu

Patrząc na powyższe można przyjąć, że ?działania operacyjne na pewno mają wpływ na skuteczność działań z zakresu wzrostu jakości i skuteczności w obsłudze klientów. Patrząc zaś na wyniki ankiet można uznać, że priorytetem jest wzrost, a wzrost firmy to głównie wzrost przychodów. Jeżeli uznać, że ankietowani nie mieli na myśli kosmetycznych wzrostów a rynek jest nasycony, to moim zdaniem, "duży wzrost" jest możliwy głównie poprzez przejęcia. Strategia przejęć niewiele ma jednak wspólnego ze sprawnością operacyjną.

Czytaj dalejArchitektura korporacyjna a strategia wzrostu

A po co nam ten SWOT

Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego - jak sądzą - potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.

Czytaj dalejA po co nam ten SWOT

Ile jest tych wymagań na system ERP

Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli). Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).

Czytaj dalejIle jest tych wymagań na system ERP

Czy aby na pewno zarządzamy procesami biznesowymi?

...analiza i specyfikowanie wymagań na systemy przepływu dokumentów czy po protu poprawy procesów biznesowych to przygotowanie firmy do zmian organizacyjnych a nie spisywanie oczekiwań pracowników z nadzieją, że dział HR nie odczuje tej zmiany. Nie zarządzamy procesami, kształtujemy je.

Czytaj dalejCzy aby na pewno zarządzamy procesami biznesowymi?

User story czyli nic nie poprawić a może nawet bardziej skomplikować

W większości chyba firm, z powodów historycznych, niemalże każdy kierownik i dyrektor ma nieco inny próg kwotowy samodzielnej akceptacji poniesionego koszu. Zapisanie w postaci wymagań a potem implementacja, takiego systemu przepływu dokumentów kosztowych, bywa koszmarem. Koszmar ten jest bardzo kosztowny z uwagi na swoją złożoność i brak ogólnych zasad. Powoduje to, że zamiast uzyskania automatyzacji i znacznego wzrostu efektywności uzyskuje się bardzo złożony i pracochłonny (kosztowny) system zamrażający zastany stan rzeczy, jedyną korzyścią czasami bywa to, że z raportów wiemy, że to na prawdę długo trwa. A to tylko jeden aspekt opisu organizacji i wymagań na oprogramowanie.

Czytaj dalejUser story czyli nic nie poprawić a może nawet bardziej skomplikować

Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Gdzie tkwi podstęp: Logika Biznesowa Dedykowana MUSI być udokumentowana osobno w sposób jednoznaczny, nie dający programiście pola do własnej interpretacji, a to wymaga opisania tego metodami formalnymi. Logika biznesowa dedykowana musi być odrębnym TWOIM kodem (w umowie prawa majątkowe do niego oraz umowa o ochronie Twojego know-how). Ale to dużo kosztuje! Dostawca oprogramowania i tak na Twój koszt to w jakiejś formie zrobi! Otóż praktyka pokazuje, że zaprojektowanie i wykonanie odrębnej Logiki biznesowej dedykowanej, kosztuje zawsze mniej (nie raz znacznie mniej!) niż koszt dostosowywania ogromnej istniejącej już logiki dostarczonej. Większość kupujących systemy ERP z powodu braku tej wiedzy i pod naciskiem dostawcy oprogramowania, przyjmuje niekorzystną dla siebie metodę wdrożenia i podpisując wcześniej niekorzystną dla siebie umowę (kastomizacja oprogramowania).

Czytaj dalejNie dać się szantażować swojemu własnemu dostawcy oprogramowania

Demo System Szachownica

Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści. Kliknij i pobierz aktualny plik projektu Wszelkie pytania i sugestie na temat treści projektu…

Czytaj dalejDemo System Szachownica

Architektura korporacyjna i dojrzałość

kto powinien taki model stworzyć i zarządzać jego zmianą? Na to pytanie jednak, moim zdaniem, każdy z Państwa sam sobie musi odpowiedzieć, ale jak chyba widać, powinna to być osoba neutralna w organizacji. Jak to robić? Chyba nie ma sensu rzucanie się na tworzenie całego takiego modelu za jednym podejściem. Biorąc pod uwagę to, że decyzje mające wpływ na system informacyjny są podejmowane od czasu do czasu, warto mieć opracowany sposób na tworzenie tego modelu (metodyka, ramy) i tworzyć te jego elementy, które przysłużą się w konkretnym przypadku. Z każdym takim projektem organizacja będzie coraz pełniej udokumentowana aż osiągnie etap, w którym z tworzenia modelu, płynnie przejdzie na zarządzanie jego zmianą.

Czytaj dalejArchitektura korporacyjna i dojrzałość

Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Od samego początku analizy i projektowania logiki systemu należy skupić się na tym "co i po co" a nie "jak". Zajmowanie się pytaniami "jak" (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy - mając szkielet całego projektu - wiemy które mają jakiekolwiek znaczenie.

Czytaj dalejKrótka lista pięciu rzeczy, które nie są regułami biznesowymi

Piraci drogowi i limit prędkości – droga jako system

Artykuł ten napisałem z dwóch powodów. Pierwszy to odpowiedz na cytowaną tezę pod artykułem o radarach laserowych rodem z mojej Alma Mater (WAT). Sugeruję kierowcom nie używać na drodze prostych heurystyk tylko przestrzegać znaków drogowych, z dwojga złego lepiej zwolnić na źle oznakowanej jezdni niż kogoś zabić lub okaleczyć. Drugi to przestrzec przed prowadzeniem analiz wymagań metodą wywiadów wierząc, że "skoro klient mówi to wie i tak chce", bi niestety w większości przypadków jest to nieprawda.

Czytaj dalejPiraci drogowi i limit prędkości – droga jako system

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia)  (polecam artykuł Łukasza Barana)  i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.

Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:

Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).

To na co chcę zwrócić tu uwagę w szczególności, to metafora:

projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.

Swego czasu pisałem, w artykule o nazywaniu klas,  że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.

(więcej…)

Czytaj dalejPlansza do gry w szachy czyli analiza i projektowanie

Koniec treści

Nie ma więcej stron do załadowania