Co robić? Po pierwsze oddzielić "grubą kreską" procesy od zadań. Proces to jedno zadanie lub seria zadań (czynności). Model takiego procesu pokazuje kolejność tych zadań, ewentualne warianty tej kolejności. Jeżeli ma to być "mapa", proces musi być deterministyczny (przewidywalny w 100%). Jeżeli tylko okaże się, że liczba wariantów zaczyna nam w toku analiz rosnąć, jest to sygnał, że należy zrezygnować z pisania procedury i przejść na metodę "zespół z kierownikiem". Taki niepodzielny zespół jest reprezentowany na modelu procesów jako rola w osobie kierownika tego zespołu (lub nazwa zespołu). Dokumentacja "wnętrza" sprowadza się do listy reguł biznesowych oraz określenia liczebności zespołu.
Nikt tu nie namawia nikogo do pisania zintegrowanych systemów ERPII od zera, jednak dostosowywanie ich (kastomizacja) w zasadzie przeczy zdrowemu rozsądkowi, o czym nie raz już pisałem (wyjaśnienie w cytowanym powyżej artykule). Przypomnę, że mamy tu dwa problemy: pierwszy to koszty kastomizacji dużego systemu są niemalże zawsze większe (ja od 20 lat nie spotkałem się z tym by były niższe) niż zaprojektowane nowego dedykowanego modułu. Drugi: kastomizacja powoduje, że całe know-how firmy (związane z tym dostosowywanym oprogramowaniem) zostaje przejęte przez dostawce oprogramowania, który może handlować nim na rynku.
Być może więc za specyfikowanie wymagań na oprogramowanie powinny odpowiadać urzędy centralne od razu po tym, jak nałożą jakiś ustawowy obowiązek na podległe im urzędy? Wtedy mamy "osobę" analityka, który wykona analizę nowej ustawy i opracuje wymagania na oprogramowanie. Firma, która wygra przetarg, zapewne w ramach swojej analizy i opracowania koncepcji rozwiązania, popyta urzędników o jakieś szczegóły w rodzaju wewnętrzna organizacja pracy urzędu, struktury obowiązków i kompetencji itp. ale nie o to co urzędnik ma robić a czego nie!
I dokładnie takie samo podejście polecam firmom: zanim wybierzecie produkt lub wykonawce oprogramowania, jako interesariusze własnych projektów, zlećcie analizę i opracowanie specyfikacji i dopiero potem pozwalajcie własnym Waszym pracownikom decydować o Waszych firmach, nie to będą przynajmniej wasze kadry kierownicze.
Niedawno napisałem, ze Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją ((Jak rozmawiać z biznesem nt. Architektury Korporacyjnej | Jarosław Żeliński IT-Consulting). Cytowany w tym artykule prof. A.Sobczak, pisze w odpowiedzi: Ze względu na fakt, że decyzje, których podjęcie rekomenduje architekt korporacyjny (poprzez przygotowanie odpowiednich analiz) odcisną trwałe piętno na organizacji oraz ponieważ organizacja będzie musiała funkcjonować w oparciu o modele zaproponowane przez zespół architektoniczny ? dla mnie architekt korporacyjny powinien w pełni identyfikować się z organizacją i być jej pracownikiem etatowym! Czy to oznacza, że…
Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.
Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go "podsłuchiwać", i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej, kompletnej wiedzy o projekcie.
I tu dochodzimy do sedna: aby stworzyć profil notacji - co czasami bywa niezbędne dla jakości analizy - należy zbudować słownik pojęć z dziedziny analizowanego problemu. Bez takiego słownika analiza może być niewykonywalna, albo jej jakość będzie bardzo niska - czytaj użycie jej wyników będzie bardzo ryzykowne.
Pytanie moje: skoro OPZ opisuje [przedmiot zamówienia] w sposób jednoznaczny i wyczerpujący oraz zastrzeżeniem tajności [w ofertach przetargowych] nie mogą być objęte nazwy (firmy) oraz adresy wykonawców, a także informacje dotyczące ceny, terminu wykonania zamówienia, okresu gwarancji i warunków płatności zawartych w ofertach, to gdzie tu miejsce na inne "tajne informacje informacje posiadające wartość gospodarczą" w ofertach?
Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.
Ćwiczenie myślowe dla czytelników ;): biorąc pod uwagę znane Wam lub dostępne w sieci opisy metod pracy Agile, innych mniej lub bardziej sformalizowanych, "przyłóżcie" je do powyższego opisu poziomów. Czy nie macie wrażenia, że metody zwinne to jedyny sposób pracy w firmach na pierwszym poziomie? Czy nie macie wrażenia, że inne metody pracy niż czas i materiał, nie mają żadnego sensu w firmach na pierwszym poziomie dojrzałości? Jakie to ryzyko i straty (diagram powyżej)?
(developer nie jest w stanie stworzyć żadnego rozwiązania tylko na bazie obrazków).
Trudno z tym artykułem polemizować, a jednak rzesze analityków, i o dziwo developerów, chyba większości firm IT, jako produkty analiz wymagań przedstawiają tylko owe prototypy czyli "user story", mock-up'y ekranów, tabele itp. W środku jest jakaś określona logika i to ona jest kluczowym wymaganiem.
