• 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 i spójne wymagania wyrażone jako projekt techniczny, obiektywizacja prac wykonawcy.

Niestety w przetargach na usługi IT kryteria pozacenowe często niczemu nie służą, a ostatecznie i tak decyduje cena. Zamawiający wpisują do specyfikacji coś, co kwalifikują jako serwis posprzedażny albo jakość, przy czym jakość rozumianą jako termin usuwania błędów oraz poziom SLA, czyli dostępność systemu. To kryteria, które nazywam pozornymi, dlatego, że na etapie oceny ofert są one w zasadzie niemożliwe do zweryfikowania. Wykonawcy wpisują do ofert najkrótszy z możliwych terminów usuwania błędów oraz najwyższy poziom SLA, a zamawiający nie może tego na etapie oceny ofert w żaden sposób sprawdzić. Przyznaje więc wszystkim maksymalną liczbę punktów w ramach tych kryteriów i ostatecznie znów o wszystkim decyduje cena. (Mec. Monika Wandzel, https://biznes.gazetaprawna.pl/artykuly/8120969,jak-zweryfikowac-jakosc-oferentow.html)

Wymagania

Wymagania mają dwa wymiary:

• biznesowe wymagania wobec rozwiązania (które tu jest czarną skrzynką)
• techniczne wobec rozwiązania (które tu są modelem mechanizmu działania rozwiązania, często zwane białą skrzynką)

Norma IEEE tak definiuje wymaganie:

1. warunek lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu
2. warunek lub zdolność, które muszą być spełnione lub posiadane przez system lub komponent systemu w celu spełnienia wymogów umowy, standardu, specyfikacji lub innego formalnie narzuconego dokumentu
3. udokumentowana reprezentacja warunku lub możliwości jak w (1) lub (2)

(źr.: norma IEEE1998)

Pierwsze to wymagania biznesowe, drugie to już projekt rozwiązania. Czym jest “udokumentowana reprezentacja”? Tu mamy wybór: może to być opis w języku naturalnym i ochroni go prawo autorskie, a może to być projekt techniczny wyrażony w ustalonej standardowej formie. Jeżeli jest to forma algorytmów, wzorów matematycznych, sformalizowanych schematów blokowych, to nie tylko chroni go prawo autorskie, ale dodatkowo także prawo dotyczące patentów i wzorów przemysłowych, taki dokument staje się także wiedzą chronioną jako know-how (patrz Ochrona wartości intelektualnych i know-how w organizacji).

Jednak same wymagania to nie jedyny produkt na etapie “zbierania wymagań”. Udokumentowana reprezentacja zawiera (powinna) opis logiki zbierania i przetwarzania informacji, a dostawca powinien dostać udokumentowana reprezentację tego co ma dostarczyć.

Rolą dostawcy oprogramowania jest dostarczenie i wdrożenie oprogramowania zgodnego z przedstawionymi mu wymaganiami i zapewnienie jego jakości, a nie analiza wymagań kupującego na tle możliwości oferowanego przez siebie produktu. Dlatego wymagania i logiczny projekt rozwiązania powinny być opracowane przed wyborem jego dostawcy.

Dlatego konieczny jest etap analizy i projektowania, jego produkty pokazano poniżej:

Na etapie analizy i projektowania (realizuje to analityk-projektant systemów) organizacja dostarcza dokumenty do analizy niosącę wiedze o niej. Dlaczego nie wywiady? Niestety, metody bazujące na zaufaniu w moc wywiadów z pracownikami i burz mózgów, w “wiedzę” wieloletniego pracownika i doświadczenie dostawcy określonego oprogramowania, stwarzają problemy z wdrażaniem systemów ERP. Wiele nieudanych projektów kończy się słowami: “Problem polegał na tym, że dostarczono nam dokładnie to co chcieliśmy, a nie to co jest nam potrzebne. Spisywanie wymagań w języku naturalnym to ogromne ryzyko niespójności i niekompletności:

Niestety same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych to wyłącznie idea jego powstania (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu, dającą ochronę w postaci pełnego prawa do powstałego produktu, uzyskuje się dopiero opracowując projekt jego konstrukcji, struktur danych i mechanizmu działania, stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe.

Dlatego poprawnym produktem analizy systemowej przedsiębiorstwa jest projekt architektury i logiki działania rozwiązania a nie konkretne oprogramowanie!

Udokumentowanie problemu, dostępnych rozwiązań i planu dostarczenia wartości pozwala wszystkim osiągnąć sukces. Przynajmniej w ten sposób staje się jasne, jaki problem ty i twój zespół próbujecie rozwiązać i jakie rozwiązania są dostępne i które z nich wybrałeś, sprawia, że jest jasne dla każdego, kto to czyta (zespół, interesariusze, zarząd, klient), w jaki sposób zamierzasz dostarczyć wartość. Jeśli nie możesz tego zapisać i uzyskać zgody interesariuszy, i tak musisz wykonać tę pracę: po prostu zanurkujesz w kodowanie mając nadzieję, że wszystko się ułoży. Jednak nadzieja nie jest dobrą strategią.

Warsztaty

Czy organizacja (jej pracownicy) powinna sama opisać swoje potrzeby? Prawo Conway’a mówi, że organizacje same projektują systemy, które odzwierciedlają ich własną strukturę komunikacyjną. Nazwa pochodzi od programisty komputerowego Melvina Conwaya, który wprowadził tę ideę w 1967 r.. Jego oryginalne sformułowanie brzmiało:

Każda organizacja, która projektuje system (zdefiniowany szeroko), wytworzy projekt, którego struktura jest kopią struktury komunikacyjnej organizacji.

(źr.: http://www.melconway.com/Home/Conways_Law.html)

Innymi słowy:

organizacje w których wymagania na system informatyczny są spisywane przez ich pracowników i zarazem przyszłych użytkowników tego systemu, dostaną system, który utrwala stan obecny, a nie zmienia go na lepsze.

Metoda ta ma także inne wade: opis taki jest bardzo często niejednoznaczny, dość ogólny i w żaden sposób nie chroni know-how i dorobku zamawiającego:

Niekompletność jest typowym problemem, który pojawia się, gdy interesariusze (np. eksperci domeny) posiadają pewne informacje i uznają je za ogólnie znane, i nie wspominają o nich analitykowi. Model oparty na niekompletnych wymaganiach cierpi z powodu brakujących obiektów, właściwości lub relacji.

Dzieje się tak nie dlatego, że ludzie ci mają złą wolę, a dlatego że stosowanie intuicji w miejscu gdzie należy użyć twardych reguł i faktów, prawie zawsze prowadzi do błędów .

Tworzenie systemów zawierających oprogramowanie obejmuje wiele poziomów abstrakcji, prowadzących od wymagań do kodu. Posiadanie abstrakcyjnych koncepcji pomaga zdefiniować kod i upewnić się, że komponenty oprogramowania zachowują się w oczekiwany sposób. Istnieje luka, która nie może być zamknięta przez zwykłe metody programowania, ale która może być zamknięta, jeśli programowanie jest wspierane przez odpowiednie ramy modelowania.

Dlatego zaangażowanie do tego celu analityka-projektanta z zewnątrz i sformalizowanie dokumentacji jest kluczowe, także dlatego, że standardowo prowadzi on także nadzór autorski nad pracami wykonawcy.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem.

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : 4 LESSONS FROM THE HERTZ VS. ACCENTURE DISASTER)

Systemy ERP

Skrót ERP to Planowanie Zasobów Przedsiębiorstwa (ang. ERP, Enterprise Resource Planning). Oznacza to zintegrowane zarządzanie głównymi procesami biznesowymi, często w czasie rzeczywistym i za pośrednictwem oprogramowania i technologii. ERP jest zwykle określane jako kategoria oprogramowania do zarządzania przedsiębiorstwem – zazwyczaj pakiet zintegrowanych aplikacji – które organizacja może wykorzystywać do gromadzenia, przechowywania, zarządzania i interpretowania danych z wielu działań biznesowych. Integracja ta może odbywać się poprzez współdzielenie jednej bazy danych lub poprzez wymianę danych na poziomie logiki biznesowej.

Wspólna współdzielona baza danych czyni taki system monolitem niepodatnym na zmiany (a ich ewentualne wprowadzanie – kastomizacja systemu – jest bardzo kosztowne i ryzykowne). Dlatego, przy obecnym poziomie technologii, integracja specjalizowanych systemów jest znacznie efektywniejsza i nie wymaga kosztownych kastomizacji. Tradycyjne systemy ERP budowane na jednej centralnej bazie danych są obecnie uważane za starszą technologię.

Wielu dostawców starszych technologii, integrujących funkcje z pomocą jednej wspólnej bazy danych, promuje tezy takie jak ta:

“W przypadku oprogramowań zamkniętych część funkcji systemu jest sztywna, a firma wdrażająca je w swoje struktury musi liczyć się ze zmianą własnych procedur w taki sposób, by dopasować się do wymogów oprogramowania. […] Niestety, porażka jest nieunikniona, jeśli firma chce zarówno wdrożenia nowego systemu, jak i pozostania przy wcześniejszym sposobie funkcjonowania. W przypadku systemu ERP takie założenie się wyklucza.”

Jest to konsekwencja monolitycznej, niepodatnej na zmiany, architektury. W bardzo wielu przypadkach sugestia, że nabywca ma porzucić swój wypracowany latami operacyjny styl pracy, dlatego bardzo wiele wdrożeń monolitycznych ERP kończy sie porażką , bywa, że upór wdrażających jest drogą do biznesowego samobójstwa.

Podstawowym celem wdrożeń systemów ERP jest poprawa funkcjonowania organizacji, osiągamy ją poprzez standaryzację i optymalizację. Standaryzacja ma sens tam, gdzie standaryzację narzuca prawo, dobre praktyki itp., najczęściej jest to obszar administracji. Optymalizację wprowadzamy wszędzie tam, gdzie to my decydujemy o kształcie procesów i procedur.

Poniżej znany od lat, tak zwany model wewnętrznego łańcucha wartości Portera .

Obszar szary to obszar standardowych procesów i procedur, w tej części praktycznie każda organizacja pracuje tak samo, to obszar w znakomitej większości regulowany prawem. Dlatego obszar szary standaryzujemy i tu ma sens “ERP z półki, a w zasadzie tylko jego standardowe moduły FK.

Obszar oznaczony kolorami to kluczowy obszar tworzący rynkową wartość dodaną i przewagę konkurencyjną: to tu “siedzi” know-how organizacji. Ten obszar optymalizujemy, i tu “wielkie ERP” jako “monolity na jednej bazie danych”, niestety nie mają absolutnie nic do zaoferowania poza “wyrównaniem w dół do reszty konkurentów”, a praktycznie każda próba kastomizacji ERP w tym obszarze kończy się kosztowną porażką .

Dlatego najpierw należy wykonać audyt procesów biznesowych i zidentyfikować w organizacji jej “kolorowy obszar”. Należy bardzo dobrze przeanalizować go od strony informacji jakimi tu zarządzamy (oprogramowanie nie zastępuje ludzi ani maszyn, ono TYLKO zarządza danymi na ich temat!), wynik analizy (w tym ewentualne standaryzacje i optymalizacje!) udokumentować jako wymaganie, i teraz dopiero dobrać na rynku pasujące rozwiązania (nie raz dla każdego dziedzinowego obszaru osobno) i zintegrować. I takie podejście daje wyniki nie raz nawet po roku i nie raz o rząd wielkości mniejszym kosztem.

Owszem bywa, że potrzebne są dedykowane rozwiązania… wtedy są one implementacją logiki biznesowej udokumentowanej w wynikach analizy biznesowej.

W dalszej części opisałem po kolei jak to zrobić.

Idealizacja jako metoda

Idealizacja to metoda opracowania wymagan na realne rozwiązanie. Polega na opracowaniu raportu z audytu organizacji, określenia biznesowego celu projektu i na tej podstawie, określeniu docelowej postaci (mechanizmu działania) organizacji czyli jej docelowego modelu. Pośrednim etapem jest model idealnej postaci docelowej oraz studium wykonalności tego ideału . Produktem ostatecznym jest kompromis pokazany poniżej:

Pierwszym etapem jest więc określenie stanu idealnego, drugim, ocena możliwości jego osiągnięcia i podjęcie decyzji o ostatecznym zakresie projektu (to wymagania na rozwiązanie). Ideał jest często wymaganiem, stan możliwy to Koncepcja Wdrożenia opracowana przez dostawcę (to on opracowuje studium wykonalności wymagań).

Podstawowym narzędziem w toku prac jest tak zwane modelowanie. Stosuję standard dokumentacyjny znany jako MDA/MDE (ang. Model Driven Architecture, Model Driven Engineering, więc w MDA…). Wszystkie średnie i duże projekty realizuję metoda iteracyjno-przyrostową (patrz także opis pojęcia stożek niepewności).

Etapy projektu

Projekt realizowany zgodnie z MBSE (Model Driven System Engineering) ma następującą strukturę:

Nazwy i cele kluczowych etapów pracy Analityka Projektanta :

Praktycznie wszystkie moje projekty mają podobny scenariusz:

1. Analityk jest w projekcie informatycznym jak architekt w projekcie budowlanym. Produktem Analizy Biznesowej jest model, który opisuje cel projektu, mechanizm działania organizacji, ale bez zbędnych detali. Stanowi sobą pewną idealizację organizacji . Produktem są Wymagania Biznesowe .
2. Na podstawie Wymagań Biznesowych określany jest zakres projektu (Przypadki użycia) i powstaje Opis Techniczny Rozwiązania zwany także PIM , zawierający między innymi model realizacji logiki biznesowej i przetwarzania informacji oraz architekturę integracji systemu . Projekt ten jest wymaganiem (PIM) wobec oprogramowania .
3. Wybór dostawców.
4. Nadzór autorski w toku prac wdrożeniowych Wykonawcy.

CIM (Computation Independent Model) Audyt i Model Biznesowy organizacji

CIM to model biznesowy abstrahujący od technologii. Jego celem jest zrozumienie mechanizmów działania organizacji. Stosowane przeze mnie metody oparte są na analizie faktów (dokumentów) i opracowaniu modelu ich powstania (procesy biznesowe) .

Ten etap jest realizowany jako audyt oraz projekt analizy i reorganizacji. Został opisany osobno jako Analiza i opracowanie Architektury Biznesowej organizacji.

PIM (Platform Independent Model) Opracowanie Projektu Technicznego czyli projektowanie rozwiązania

Przypadki Użycia to opis z perspektywy użytkownika, ich specyfikacja to model PIM: opis techniczny. Jest to model opisujący architekturę i logikę działania wymaganego rozwiązania (dedykowanego modułu). Tak opracowana dokumentacji chroni także know-how Zamawiającego.

Projektowanie architektoniczne jest działalnością intelektualną, w której architekt przechodzi od abstrakcji do rzeczywistości. W tym procesie, abstrakcja reprezentuje logiczne rozumowanie w jaki sposób forma architektoniczna jest skonfigurowana lub ustrukturyzowana, podczas gdy rzeczywistość odnosi się do ostatecznej formy fizycznej. Diagramy stają się integralną częścią projektu koncepcyjnego ponieważ pośredniczą pomiędzy tymi dwoma sferami.

Od dawna wiadomo, że rosnąca złożoność oprogramowanie nie daje już szans człowiekowi na napisanie kodu programu bezbłędnie za pierwszym razem. Luka pomiędzy wymaganiami a działającym kodem rośnie i będzie rosła. Dlatego od dawna lukę tę wypełnia się etapem modelowania, które nie narzuca technologii implementacji, uwzględnia możliwość mieszania dostępnych na rynku gotowych komponentów, a na etapie prototypowania jest wielokrotnie tańsze tańsze od kodowania,

Projekt rozwiązania jako Specyfikacja Wymagań

?First, solve the problem. Then, write the code. ? ? John Johnson

Najpierw powstaje tak zwana Architektura Wysokiego Poziomu (ang. HLD, High-Level Design) dla całości projektu. Tam gdzie wymagane będa dedykowane moduły, projekt jest uzupełniany o Architekturą Niskiego Poziomu (amg. LLD, Low-Level Design) czyli projekt techniczny (nadal tylko logika). Są to dwie co najmniej iteracje.

Etap projektowania rozwiązania jest więc realizowany zawsze (jest zalecany), gdy celem jest wdrożenie oprogramowania. Także dlatego, że może sie okazać, że większość, a bywa że 100%, tego co potrzebujemy (wiemy co bo mamy już model) można już kupić na rynku. Taki model staje wymaganiem dla dostawcy systemu.

Tu znowu przytoczę diagram obrazujący kolejne warstwy modelowania :

Mając już model biznesowy (w tym modele procesów biznesowych) i wymagania biznesowe (enterprise context) specyfikujemy wymagane usługi aplikacyjne (business services). Powstaje zakres projektu. Jest dokument opisujący usługi aplikacji, zawierający: specyfikację usług, powiązanych z nimi dokumentów, mapowanie ich na model procesów biznesowych, realizowane wymagania biznesowe (dostarczone przez zamawiającego). Produktem tego etapu jest opracowanie zgodne ze specyfikacją Model Driven Architecture/Computation Independent Model (źr. www.omg.org/mda/), etap ten (jako opracowanie) stanowi wynik transformacji modelu biznesowego na usługi aplikacyjne (jej przypadki użycia).

Usługi aplikacji to kontekst systemu wyrażony jako opis jako czarnej skrzynki, co modelujemy jako przypadki użycia systemu. Praktyka pokazuje, że sam opis czarnej skrzynki nie stanowi specyfikacji systemu, dlatego w inżynierii (oprogramowania także) stosuje się zasadę: model jako specyfikacja (MBSE: ang. Model-Based System Engineering) . Innymi słowy specyfikowanie wymagań na system polega na jego zaprojektowaniu, a projekt ten jest odpowiedzią na wymagania biznesowe.

Projekt systemu to model opisujący strukturę (architekturę) i zachowania. Zachowania systemu to jego reakcje na bodźce z zewnątrz, to jego przypadki użycia.

Dane to informacje dla człowieka

Kluczowym elementem tego opisu są struktury dokumentów wyrażone w sposób sformalizowany:

Zawierają one opis sposobu realizacji większości wymagań biznesowych (np. jeżeli “system ma pozwalać na kontrole wykorzystania urlopów” to znaczy, że wniosek urlopowy powinien zawierać dane: typ urlopu oraz liczba dni, co należy udokumentować jak wyżej). Więcej w artykule Dokumentowani przypadków użycia.

Jeżeli okaże się, że nie zaoferowano produktu istniejącego już na rynku (lub nie spełniają one wymagań w 100%), to znaczy że powstaną dedykowane komponenty. Jest to sytuacja, w której mechanizm (logika biznesowa) wybranego obszaru działania organizacji jest unikalna, bardzo często mechanizm ten stanowi chroniony know-how tej organizacji. W takiej sytuacji powstaje projekt techniczny tego komponentu, a od wykonawcy oczekiwana jest oferta na wykonanie implementacji.

(Dalsza część jest przeznaczona także dla dostawców i wykonawców oprogramowania)

Programming is not solely about constructing software?programming is about designing software.

(Programowanie nie dotyczy wyłącznie konstruowania oprogramowania – programowanie dotyczy projektowania oprogramowania. , więc od niedawna jestem programistą 🙂 )

Poprzedzanie programowania projektowaniem jest kluczowym etapem obniżającym ryzyko projektu .

“Niezależnie od tego ile przeprowadzisz rozmów z mistrzami gry w bilarda i ile godzin filmów nakręcisz nad stołem  bilardowym, nie zbliżysz się nawet do stworzenia dość dobrej gdy w bilarda. Jednak wystarczy, poświęcić czas na zrozumienie i zapisanie praw fizyki rządzących ruchem kul na stole bilardowym, by napisać grę doskonałą”.  

Projekt architektury aplikacji to także wymaganie: wymagamy dostarczenia tego co zaprojektowano. Nie jest to detaliczny projekt oprogramowania czy procedur, jest to opis architektury oprogramowania (systemu IT), oczekiwanej (idealizacja) logiki biznesowej mechanizmu jego działania.

Co do zasady projektowana jest tak zwana architektura wysokiego poziomu (model PIM wg. OMG.org/MDA), czyli system złożony z dziedzinowych komponentów, ich integracja, model informacyjny. Model informacyjny to opis zawartości (struktur) dokumentów ujawnionych w procesach w Analizie Biznesowej, logika poprawności danych na dokumentach oraz logika wiążąca dokumenty między sobą.

Dedykowane moduły – add-on’s

Wdrożenie w firmie jednego monolitu, czyli systemy ERP spełniającego wszystkie wymagania, jest praktycznie niemożliwe, a jego kastomizacja są najczęściej katastrofalne dla niego. Dlatego powszechna praktyką jest integrowanie z nim dedykowanych modułów kupowanych na rynku lub realizowanych jako dedykowane:

Czym jest moduł dodatkowy w systemie ERP? W skrócie, jest to składnik oprogramowania, który zapewnia dodatkowe możliwości, które rozszerzają i integrują się z pakietem podstawowym oferowanym przez dostawcę ERP. Czasami organizacje wybierają moduły dodatkowe od różnych dostawców, co jest uważane za najlepsze podejście.

https://www.panorama-consulting.com/what-is-add-on-module-in-erp/

W przypadku gdy na rynek nie oferuje gotowego rozwiązania (wiele firm ma swoją specyfikę) pozostaje zaprojektowanie go i implementacja.

Programowanie nie pole­ga już wyłącz­nie na pisa­niu kodu, pro­gra­mo­wa­nie pole­ga na projektowaniu. .

Projekt dedykowanego oprogramowania to tak zwany Opis Techniczny Rozwiązania to tak zwany model PIM (ang. Platform Independent Model) i jest to – ten projekt – wymaganie. Stanowi on specyfikację usług jakich oczekuje się od oprogramowania oraz opis logiki jaką ma ono realizować (dokładniejszy opis w tekście Analiza Biznesowa i Opis Techniczny Oprogramowania Dedykowanego).

Przypadki użycia, wyprowadzane z modeli procesów biznesowych, są dodatkowo dokumentowane z użyciem scenariuszy, te zaś wykorzystują komponenty realizujące logikę biznesową (tak zwany model dziedziny). Poniżej struktura modeli (perspektywy) jakie powstają (patrz także proces OMG SPEM):

Model logiki aplikacji pokazany powyżej to zgodny z podejściem MDA/MDE, jest to projekt logiki i architektury przyszłej aplikacji (w notacji UML). Całość jest wykonana w czytelny dla adresata sposób (niuanse notacji musi znać autor diagramów, ich odbiorcom wystarczy opisana legenda symboli).

Tworzenie kodu obejmuje wiele poziomów abstrakcji, prowadzących od wymagań do kodu. Posiadanie abstrakcyjnych koncepcji modelowania dostępnych jako wysokopoziomowe konstrukcje programistyczne pomaga zdefiniować kod i upewnić się, że komponenty oprogramowania zachowują się w oczekiwany sposób. Istnieje luka, której nie można wypełnić zwykłymi metodami programowania, ale którą można wypełnić, jeśli programowanie jest wspierane przez odpowiednie ramy modelowania (metodę projektowania i analizy oraz język).

Metody obiektowe mają ogromne zalety, są znane od lat, są stosowane… są mało popularne bo są trudne … ale ja robię to od 20 lat…

Opis bardziej techniczny oraz przykładową specyfikację znajdziecie Państwo na stronie Analiza, wymagania i usprawnianie organizacji czyli MBSE. Omówiony przykład OPZ dla administracji publicznej na stronie Generator Ofert. Przykładowy dokument projektowy i to jak powstawał na stronie Biblioteka.

Podsumowanie

• wymagania funkcjonalne są dokumentowane jako usługi aplikacji (jej przypadki użycia) i formularze (patrz Projekt aplikacji)
• w opisach formularzy i dokumentów posługuję się standardowo ich treścią i strukturą (XML),
• komunikacja ze mną w toku nadzoru autorskiego i rozwoju odbywa się z pomocą mojego repozytorium: Postmania.
• ostateczne decyzje i szczegóły powstają w toku Nadzoru Autorskiego (patrz Nadzór Autorski)

(na podstawie: P.Sienkiewicz, L.Koźmiński, P.Miller, OMG.org)

Sku­tecz­ny opis wyma­gań to spe­cy­fi­ka­cja wyra­żo­na języ­kiem o skoń­czo­nej licz­bie pojęć, pozwa­la­ją­ca pro­gra­mi­stom ?wlać? ją do kolej­nej ?for­mal­nej for­my? jaką jest język pro­gra­mo­wa­nia. (patrz: Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie)

Tu polecam referat na temat projektowania: jak i po co.

Wybór dostawców i umowa

Ten etap to ogłoszenie (rozesłanie) zapytania ofertowego. Standardowo w pierwszym kroku ogłaszam RFI (zapytanie o gotowość do złożenia oferty) bez podania danych Zamawiającego, na moich profilach w mediach społecznościowych (mam kilka tysięcy obserwujących osób i firm). Firmy, które zgłosiły się w tym etapie są oceniane przez Zamawiającego, który wybiera kilka. Wybranym firmom przekazywane jest pełne zapytanie RFP z Opisem Przedmiotu Zamówienia Przedmiotem Zamówienia są określone w zapytaniu usługi (np. wdrożenie, szkolenia itp.) oraz wynik Analizy Biznesowej i Opis Techniczny Oprogramowania) . Wybierany jest Wykonawca, który złożył najkorzystniejszą ofertę, kryteriami są zawsze cena, kompetencje i doświadczenie oraz zaoferowana technologia.

Na tym etapie, zgodnie z Art.634 KC, Wykonawca powinien zgłosić wszelkie ewentualne swoje zastrzeżenia do materiałów (dokumentacja) jakie otrzymał, i robić to na bieżąco także w toku realizacji projektu, jeżeli otrzyma jakiekolwiek nowe materiały.

Ogłoszenia i zapytania ofertowe moich klientów (w tym także Opis Przedmiotu Zamówienia) standardowo wysyłam na listę subskrybentów mojego serwisu.

Podpisanie Umowy i nadzór autorski

Wymagania na początku projektu nie są ostatecznym produktem analityka

Wszystkie detale technologiczne opracowuje Wykonawca, który składając ofertę zadeklarował, że dostarczy rozwiązanie zgodne z Projektem Technicznym, a w swoim dokumencie, jakim jest Koncepcja Wdrożenia, Wykonawca powinien opisać to, jak zrealizuje projekt z użyciem technologii jaką zaoferował.

Koncepcja nadzoru autorskiego zakłada, że projektant (autor), na zlecenie inwestora, projektuje rozwiązanie a następnie, po wyborze wykonawcy, nadzoruje realizację rozwiązania i uzupełnia treść projektu o wymagane szczegóły, odpowiadając na pytania zarówno inwestora jak i wykonawcy. Dokumentacji projektowej nie da się “zamrozić” na czas trwania nie raz wielomiesięcznego projektu. Dlatego większe projekty są realizowane komponent po komponencie w pętli iteracyjno-przyrostowej.

Po zakończeniu implementacji, uzupełniane w toku projektu, powiązane z sobą Projekt rozwiązania (uzupełniany w toku nadzoru autorskiego) i Opis implementacji (uzupełniany przez Wykonawcę), stanowią kompletną dokumentację dostarczonego produktu. Całość zobrazowano na poniższym diagramie:

Dostawca rozwiązania nie robi żadnej swojej analizy przed-wdrożeniowej. Na podstawie otrzymanych materiałów opracowuje Koncepcję Wdrożenia, którą realizuje w toku projektu.

Praktyka pokazuje, że problemy z wdrożeniem system ERP są powodowane, przez założenie kupującego, że dostawca ma doświadczenie i wie jak wdrożyć swój system. Problem w tym, że dostawca w dobrej wierze, wdroży to co ma, osobną kwestia jest upewnienie się, że to co ma jest tym czego potrzebujemy. To dlatego wybór dostawcy rozwiązania powinien być ostatnim, a nie pierwszym etapem projektu przygotowania do wdrożenia. Istotne jest także, co pokazano na powyższym diagramie, ścisłe rozdzielenie kodu licencjonowanego od wytworzonego w toku wdrożenia (patrz: Kastomizacja).

Polecam także artykuł Wymagania umarły…^?1?

Dodatek: Podmioty publiczne i PZP

Na zakończenie kilka słów o zamówieniach publicznych, skupię jednak wyłącznie na kwestiach usług jakie osobiście oferuję. Jestem gorącym zwolennikiem poniższej tezy:

Kryteria pozacenowe nazywam pozornymi, dlatego, że na etapie oceny ofert są one w zasadzie niemożliwe do zweryfikowania Niestety w przetargach na usługi IT kryteria pozacenowe często niczemu nie służą, a ostatecznie i tak decyduje cena.

(mec Monika Wandzel, źr.: Jak zweryfikować jakość oferentów?)

Dlatego zgadzam się z opiniami mówiącymi, że najskuteczniejszą metodą wyrażania wymagań na rozwiązanie jest projekt tego rozwiązania, a nie opis jego cech.

Od wielu lat moimi zleceniodawcami są także podmiotu publiczne (między innymi: PFRON, Urząd Miasta Warszawy, PSE, KGHM SA, Żandarmeria Wojskowa, Kancelaria Senatu). Przetargi publiczne z zasady są projektami określanymi jako “fixed-price” (całkowity koszt określany w momencie zamówienia) co czyni je trudniejszymi na etapie przygotowania. Pojawiają się publikacje na temat stosowania “zwinnych metod w administracji publicznej”, firmowane nawet przez znane kancelarie prawne, jednak praktyka pokazuje, że tworzenie OPZ w postaci “otwartego zarządzalnego zakresu projektu” nie rozwiązuje praktycznie żadnych problemów, za to stwarza ogromne ryzyko przejęcia zarządzania zakresem projektu przez dostawcę (“dostaniesz to co chce Ci dostarczyć dostawca a nie to czego potrzebujesz”), Jeden z moich komentarzy na ten temat tu: Agile w PZP (2017).

W Czerwcu 2020 roku, Urząd Zamówień Publicznych opublikował dokument: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO NA SYSTEM INFORMATYCZNY. We wstępie autorzy piszą:

Zakup systemów informatycznych to złożony proces, który wymaga od zamawiających rzetelnego przygotowania. Istotny wpływ na powodzenie zamierzenia inwestycyjnego związanego z zamawianym systemem IT ma wiele czynników, wśród których przykładowo można wymienić znajomość rozwiązań IT występujących na rynku, aktualność posiadanych przez zamawiającego w tym zakresie informacji, czy też świadomość co do możliwości własnych zamawiającego w zakresie prawidłowego i wyczerpującego przygotowania postępowania na zakup systemu IT. Prawidłowe przygotowanie zamawiającego do przeprowadzenia postępowania, tj. na etapie jeszcze przed wszczęciem postępowania o udzielenie zamówienia publicznego, pozwala minimalizować problemy, jakie mogą wystąpić w prowadzonym w przyszłości postępowaniu, a także w trakcie realizacji oraz eksploatacji przedmiotu zamówienia, szczególnie w przypadku nabywania złożonych rozwiązań technologicznych.

Jak widać zwraca się szczególną uwagę na kompetencje wymagane do opracowania niezbędnej dokumentacji oraz na wewnętrzne przygotowanie do przyszłego wdrożenia i eksploatacji systemu informatycznego. Autorzy zwracają uwagę, że:

…choć obowiązek przeprowadzenia analizy potrzeb i wymagań, o której mowa w art. 83 ustawy PZP dotyczy tylko niektórych zamawiających i postępowań (tzn. nie dotyczy zamówień o wartościach nieprzekraczających progów unijnych oraz zamówień sektorowych), to jednak przeprowadzenie analogicznego procesu może być uzasadnione także w wypadkach, w których nie jest on obligatoryjny.

Ważny zapis:

W nowej ustawie PZP określony został próg wartościowy wyznaczający obowiązek stosowania przez zamawiającego przepisów tej ustawy. Obowiązek ten powstaje, jeżeli wartość zamówienia osiągnie ten próg. Zgodnie z przepisem art. 2 ust. 1 pkt 1 ustawy PZP, jej przepisy stosuje się, co do zasady, do udzielania zamówień publicznych oraz organizowania konkursów, których wartość jest równa lub przekracza kwotę 130 000 zł, przez zamawiających publicznych.

W dalszej części dokumentu czytamy:

Zamawiający powinien zweryfikować kompetencje własnego zespołu i sprawdzić, czy dysponuje specjalistami, którzy: (-) przygotują opis przedmiotu zamówienia w sposób wystarczająco precyzyjny i dokładny, a także uwzględniający adekwatne potrzeby zamawiającego, najnowsze standardy i wytyczne, normy branżowe, w tym także w zakresie cyberbezpieczeństwa systemów IT, (-) zapewnią sprawną realizację postępowania zamówieniowego (np. w zakresie odpowiedzi na pytania wykonawców, oceny ofert,) (-) zapewnią należytą realizację umowy zawartej w ramach zamówienia.

Przygotowanie do przetargu (analiza potrzeb i opracowanie OPZ), wsparcie w toku postępowania oraz roczny nadzór autorski (wiele wdrożeń systemów informatycznych, jakie prowadziłem, mieści sie w granicach roku od podpisania umowy z dostawcą), to w moim przypadku, to usługa o wartości bardzo często poniżej 130 tys. zł, wraz z kosztem. Oznacza to, że możecie Państwo zlecić mi taką usługę (przygotowanie do przetargu) bez straty czasu na konkursy (bez nadzoru autorskiego jest to koszt 40 tys. zł). Wystarczająca jest ocena dorobku, kompetencji i doświadczenia oraz (co bardzo ważne) podpisanie oświadczenia o braku konfliktu interesu:

Zamawiający musi więc pamiętać o treści art. 85 oraz art. 108 ust. 1 pkt 6 ustawy PZP, które nakazują przeciwdziałać sytuacji, w której udział danego wykonawcy w przygotowaniu postępowania zakłóci konkurencję, a jeżeli tego zakłócenia wyeliminować się nie da, nakazują wykluczyć z postępowania wykonawcę, który był zaangażowany przy przygotowaniu postępowania.

Autorzy zaleceń piszą także:

Wobec dynamiki zmian zachodzących w zakresie rozwiązań informatycznych, zamawiający powinien szczególnej uwadze poddać aktualność posiadanych informacji. Mając na uwadze powyższe, istotne jest również to, aby zamawiający planował przeprowadzenie postępowania w taki sposób, aby zapobiegać przewlekłości procesu zakupowego, gdyż powoduje ona ryzyko dezaktualizacji opracowanej dokumentacji.

Jednak “część formalna SWZ” powinna być przygotowania przez Zamawiającego i jego służby prawne. Autorzy zwracają tu uwagę, że:

Nie można też zapomnieć o treści projektowanych postanowień umowy ? ich przygotowanie bez dogłębnej wiedzy o przedmiocie zamówienia oraz przebiegu jego realizacji, jest błędem, na który nie może sobie pozwolić żaden zamawiający.

Poniżej treść omawianego dokumentu:

Polecam lekturę powyższego dokumentu w całości.

Dodatek: Opis odwoływania się, w Koncepcji Wdrożenia, do wymagań

Każdy dostawca rozwiązania, jako pierwszy produkt w realizacji Umowy (lub na etapie ofertowania) musi (powinien) opracować dokument Koncepcja Wdrożenia (studium wykonalności, analiza fit-gap, lub odpowiednik), opisujący to jak proponuje, wdrażając oferowany produkt, zrealizować Wymagania Zamawiającego.

“Analiza Biznesowa i Projekt Techniczny Rozwiązania” (dalej Analiza) zawiera między innymi rozdziały: Model Procesów Biznesowych oraz Model Kontekstowy Systemu IT (Zamawiającego). Pierwszy zawiera opis działania organizacji, drugi zawiera zakres wdrożenia w postaci listy wymaganych usług aplikacyjnych (wyrażonych jako przypadki użycia UML oraz ich specyfikacje, to wymagania wyrażone metodą MDA/MBSE).

Opis każdej wymaganej usługi aplikacji w Analizie (przypadki użycia) zawiera:

• kontekst i celu jej użycia i wskazanie jej aktora (pracownik, klient, inny system itp..),

• szablon formularza ekranowego/wydruku i walidację pól,

• architekturę i logikę realizacji wymiany danych z innymi formularzami i innymi aplikacjami, jeżeli to wymagane (integracja).

Dostawca rozwiązania w treści proponowanej Koncepcji Wdrożenia (to produkt dostawcy):

1. albo organizuje ten dokument w taki sposób, że wskazuje w nim jak zrealizuje każdą wymaganą usługę aplikacji (wtedy podstawą spisu treści Koncepcji Wdrożenia są wymagane usługi aplikacji),
2. albo organizuje ten dokument w taki sposób, że wskazuje (przywołuje) w np. standardowym opisie dostarczanego rozwiązania (np. Instrukcja Obsługi) miejsca (np. funkcje aplikacji w menu), które realizują określoną, wymaganą usługę aplikacji (wtedy podstawą spisu treści Koncepcji Wdrożenia jest opis funkcjonalny dostarczanej aplikacji).  

Pierwszy przypadek np.: “wymagana usługa [nazwa usługi: przypadku użycia ] jest realizowana przez [tu wskazanie, które standardowe funkcje dostarczanego oprogramowania ją realizują i jak]”.

Drugi przypadek:  “Nasze oprogramowanie ma funkcje [tu nazwa i opis tej funkcji], która realizuje potrzeby opisane jako [tu nazwa usługi aplikacji – przypadek użycia – w Analizie]”.

Jeżeli dostarczone oprogramowanie w wersji standardowej nie realizuje jakiejś wymaganej w Analizie usługi, powinna się pojawić taka informacja wraz z propozycją metody rozszerzenia funkcjonalności standardowej wersji dostarczanego oprogramowania. Tak zorganizowany dokument Koncepcji Wdrożenia jest także często nazywany “analizą fit-gap” . Patrz także powyżej: Idealizacja jako metoda.

Źródła

Zapytanie

Jarosław Żeliński