Autor recenzowanego tekstu odnosi sie do skutków ekonomicznych, pomija jednak całkowicie skutki prawne kastomizacji kodu oprogramowania, które mają wpływ na koszty i ochronę wartości intelektualnych. Autor pisze we wstępie:
Celem niniejszego opracowania jest analiza możliwych metod kastomizacji systemów informatycznych zarządzania przeprowadzona z ekonomicznego punktu widzenia, w tym w szczególności opłacalności stosowania oprogramowania standardowego i wykorzystania poszczególnych metod jego adaptacji. […] Kastomizację systemu informatycznego ogólnie należy rozumieć jako jego adaptację do potrzeb konkretnego podmiotu. M. Flasiński określił kastomizację, jako ?konfigurację systemu, osadzenie w systemie za pomocą prac programistycznych dodatkowych funkcjonalności oraz modyfikację istniejących funkcjonalności systemu?
Dostarczanie oprogramowania i jego wdrażanie, wiąże się jego ewentualnym dostosowaniem do potrzeb użytkownika. Autor powyższego opracowania, stosując nieprecyzyjne definicje pojęć, wprowadza czytelnika w błąd, opisując przyczyny i konsekwencje związane z szeroko pojętym dostosowaniem oprogramowania do potrzeb użytkownika. Niestety z tego dokumentu korzysta wielu prawników, nazywając go nie raz nawet „wykładnią”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Posłużę sie nim teraz, przy okazji analizy tego czym jest oprogramowanie.
Materialną postać, gdzie wartość ma egzemplarz, ma dzieło takie jak np. rzeźba. Tu pojęcie reprodukcji (kopii oryginału) ma sens. Jednak oprogramowanie, podobnie jak muzyka, proza, poezja, fotografia, jest dziełem niematerialnym. To, że jego egzemplarze są „materializowane” na nośniku oznacza jedynie to, że zostało to dzieło utrwalone. Czytaj dalej… „Odsprzedaż sofware czyli czy można odzobaczyć to co się zobaczyło”→
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
W kończącym się roku trzy razy miałem do czynienia z nie małymi (czytaj kosztownymi) dokumentami zawierającymi „modele procesów biznesowych” i „specyfikację wymagań”. Wszystkie trzy miały pewne wspólne cechy:
były problemy z przydatnością tych dokumentów, co było powodem poproszenia mnie o ocenę i rekomendacje w kwestii ich naprawy,
wszystkie były produktem zbiorowych „warsztatów procesowych” i „warsztatów wymagań” z pracownikami modelowanej firmy,
żaden nie nadawał się do użycia jako materiał do stworzenia oprogramowania, mimo, że wszystkie one były produktem pierwszego etapu projektu o nazwie „analiza przed-wdrożeniowa”,
wszystkie cierpiały na problem nadmiaru szczegółów, niejednoznaczności i braku spójności.
Jedenaście lat temu (tak jedenaście!) napisałem:
Często firmy oferują usługę i produkt Model (mapę) Procesów Biznesowych. Co dają? Dają nieudolnie zrobiony opis procedur, niesłusznie nazwanych procesami. Setki schematów obrazujących kto, co i jak robi. A po co to robi? Tego tam z reguły nie opisano! Dziesiątki i setki stron diagramów, które lądują na półce i nie są używane podczas wdrożenia. Powstaje opracowanie, które jest niezrozumiałe przez zarząd firmy zlecającej tę pracę. Zarząd nie przyzna się, że nie rozumie bo podobno to znana firma doradcza lub wdrożeniowa opracowała. A moim zdaniem, jeżeli Zarząd nie potrafi zrozumieć udokumentowanego obrazu własnej firmy to dokument jest do kitu a nie Zarząd. (Modelowanie biznesowe czyli pilnowanie hochsztaplerów).
Dlaczego tak jest? Dlaczego tak bardzo popularne są tego typu warsztaty a nie rzetelne, dające wysokiej jakości produkty, analizy?
Obserwacja gry vs. reguły gry
To co się dzieje na stole bilardowym (metafora z książki M.Fowlera) można opisać z pomocą praw fizyki i reguł gry w bilarda. To co obserwujemy na szachownicy (metafora z bloga Paula Harmona) to wynik reguł gry, doświadczenia i klasycznych zagrywek. W obu przypadkach dochodzą też do głosu wiedza i umiejętności graczy. Piłka nożna to reguły gry, prawa fizyki (tor piłki po kopnięciu piłki) i umiejętności zawodników. Można tu podać wiele innych przykładów efektów łącznego istnienia określonych reguł oraz umiejętności ludzi.
Każda organizacja (firma, urząd, inne) to ludzie z ich wiedzą i umiejętnościami oraz reguły „gry” czyli obowiązujące Prawo i wewnętrzne regulacje. I teraz pojawia się pytanie: czym jest model organizacji? Przede wszystkim model to uproszczenie rzeczywistości, jednak stopień tego uproszczenia nie jest przypadkowy. To co upraszczamy (pomijane szczegóły) zależy od kontekstu w jakim ten model będzie użyty, bo tworzenie modelu na jeden cel: użycie go w konkretnym celu. Tu „niestety” wkracza nauka, mam na myśli podejście (metoda naukowa w analizie).
Spójrzmy na to od końca. Aby powstało jakiekolwiek narzędzie wspomagające pracę np. ludzi wykonujących swoje obowiązki w organizacji, narzędziem taki jest także oprogramowanie (czyli aplikacje), musi powstać opis tego narzędzia. Aplikacje to takie narzędzia, tworzymy je głównie z dwóch powodów: tworzymy elektroniczne wersje kartotek (rejestrów) oraz tworzymy elektroniczne wersje określonych umiejętności (np. wyliczanie pierwiastków w kalkulatorze). Tak więc aby zamówić u developera Kartotekę musi ją opisać i to jest relatywnie proste: tworzymy wzór Kartoteki, np. kartoteki pracownika, książki w bibliotece itp. Nieco trudniej jest opisać (udokumentować) umiejętność, zresztą najpierw trzeba ja jakoś zdefiniować. Umiejętności, tu wymagane, mogą być różne: od umiejętności weryfikacji danych wprowadzanych do kartotek aż do umiejętności wytwarzania nowych informacji na bazie tych dostępnych w kartotekach. Np. utworzenie faktury sprzedaży wymaga skorzystania z kartoteki klientów, z kartoteki oferowanych towarów i usług, kartoteki towarów dostępnych w magazynie, trzeba także posiadać umiejętność poprawnego wyliczenia wartości podatków na formularzu faktury, mogą do tego dojść upusty zależne od wielu czynników: wartości zakupu, aktualnych promocji, status kupującego i wiele innych. Inny przykład: zarejestrowanie nowego dokumentu w archiwum wymaga skorzystania z kartoteki dokumentów oraz umiejętności nadania dokumentowi specjalnego znaku, sygnatury.
I tu wpadamy w efekt „kręcenia filmu”. Najczęściej tak zwana analiza wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swoje pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).
Dokumenty, które dostaję do recenzji, to często właśnie zapisy, wręcz stenogramy z takich spotkań, i nie ma znaczenia czy to zapisy „prozą” czy zapisy w postaci obrazkowej z użyciem notacji BPMN czy UML (gdzie notacja jest wykorzystywana raczej jako biblioteka symboli a nie narzędzie z jego syntaktyką i semantyką). To dokumenty, które stanowią rodzaj stenogramu z rozmów, są jak filmy nakręcone podczas rozgrywania partii szachów lub bilarda: miłe w oglądaniu, długie, kosztowne i kompletnie nieprzydatne do napisania komputerowej gry.
Do opisania każdej z tych gier, a także do opisania tego jak funkcjonuje organizacja, wystarczy dokument opisujący zasady gry (reguły biznesowe) oraz minimalną wiedzę i umiejętności graczy oraz to jakie i w jakiej kolejności rzeczy maja powstać czyli model procesów biznesowych. Model procesów jednak to nie jest „film” opisujący czyjąś pracę a logiczny łańcuch aktywności tworzących, każda, przydatny biznesowi produkt.
Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.
Niestety wiele produktów etapu projektu o nazwie analiza przed-wdrożeniowa to tak zwane malowanie trawy: kawał kosztownej i nikomu nie przydatnej pracy. Jakiś temu pisałem z innej okazji:
Niestety, podczas tak zwanych typowych analiz, opartych na wywiadach i spotkaniach warsztatowych, im więcej interakcji tym większe pole do manipulacji i perswazji (świadomej lub nie, ale jednak). Po drugie, nie ma żadnej gwarancji, że niczego nie pominięto (w takich rozmowach w zasadzie omawiane są rzeczy ciekawe i rzadkie a prawie nigdy oczywiste). […]
Drugim problemem i poważnym błędem jest uznanie, że ?skoro te analizy to spotkania i zapisywanie ich wyników, to może to robić niemalże każdy byle był komunikatywny?. Bzdura. Po pierwsze takie działanie to nie są analizy a stenogramy ze spotkań, po drugie są one zapisem subiektywnego oglądu sytuacji, jaki mają odpytywani pracownicy danej firmy (do tego z ich tylko perspektywy). (Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT).
Dlatego rolą analityka biznesowego nie jest spisanie przebiegu dziesiątek wywiadów i setek indywidualnych wymagań. Nie mają większego sensu dokumenty na dwa, trzy tysiące stron (nikt ich nie czyta!). Rolą analityka biznesowego jest przeanalizowanie dostępnych dokumentów, informacji, i stworzenie opisu mechanizmu działania organizacji oraz opisu rozwiązania, narzędzia mogącego usprawnić działanie organizacji. Opisu zawierającego reguły biznesowe, przetwarzane informacje (wzory dokumentów) oraz listą usług jakie ma świadczyć planowana do wdrożenia aplikacja wraz z opisem tego, jak te usługi mają być realizowane (umiejętności, które można zautomatyzować). Sens mają więc zwięzłe opisy i modele mechanizmów działania organizacji oraz opisy tego jakie informacje i jak mają być przetwarzane z uwzględnieniem tego, że część tych prac nadal będą wykonywali ludzie. Takie jak reguły gry w szachy: ważne są dwie strony opisu reguł gry a nie setki stron opisów przykładowych partii.
Bardzo często słyszę od developerów, ze większość dokumentów jakie dostają jest nieprzydatna. Nie raz zastanawiam się, dlaczego mimo to większość usługodawców tworzy tak nieprzydatne dokumenty? Najprawdopodobniej dlatego, że słuchanie i stenografowanie jest łatwe… Z drugiej strony, nie raz niestety sami zamawiający chcą takich właśnie dokumentów, Ci jednak są usprawiedliwieni, bo to nie oni są analitykami. Ci ostatni sami decydują jakimi analitykami są…
Drugim powodem jest dość powszechny brak umiejętności abstrakcyjnego myślenia. Problem ten widać często na etapie modelowania procesów biznesowych: zamulanie zbędnymi szczegółami. Bardzo wielu analityków ma skłonności do wgłębiania się w nieistotne szczegóły, to właśnie objaw braku umiejętności tworzenia abstrakcji. Do tego stopnia, że powstał pomysł na sformalizowanie zajmowanie się tymi szczegółami (Case Management). Ciekawa dyskusja na ten temat pojawiła się na LinkedIn. Ja ze swej strony polecam artykuł (Case Managemet) oraz wypowiedzi Paula Harmona w dyskusji:
At the process level, we want the ability to describe and organize a generic set of activities. We might be concerned, for example, with how we organize Hotel Guest Services. To be clear what we mean by organizing Hotel Guest Services, we might talk about a specific instance in which a hotel organized guest services. One of the things we might decide, for example, was that the hotel wanted everyone to use the guest’s name. Thus, we might think of all of the activities in which employees might interact, and ponder how we would provide each set of employees with each guest’s name. It obviously wouldn’t be a matter of simply notifying one group – like those who take restaurant reservations of who is in what room – since, as Roger suggests, a hotel guest could proceed in any order, going to the pool, or to a conference session, or proceeding to make a restaurant reservation. In this case we are probably talking about putting information into a database from which various employees could easily retrieve it. Processes are dynamic and complex, in part, because the generic process description isn’t as prescriptive as it would be in a production line, where the stations are set and the behaviors expected at each station are well defined. They are „cases” because each instance of the process uses a different set of activities in a different order – as in the Rescue Hostage example. When we plan for a Rescue Hostage case or project if you prefer, we develop a series of scenarios, and practice a large set of activities. When the time comes to execute the process, we begin by planning for the specific instance case. The idea that we start the process with a generic: Plan for the Specific Rescue Effort, activity may be generic, but any detailed example of it will be an instance, since in the very nature of the planning we are tailoring to the specific instance. (Case Management Approaches | LinkedIn).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Pewien lider na rynku dostawców systemów ERP, ma zapis w umowie mówiący, że przejmuje prawa autorskie do całości pomysłów i kodu (funkcjonalności) jaki powstaną podczas prac z klientem nad dostosowaniem dostarczanego systemu ERP (czyli tak zwana kastomizacja). Czyli know-how zamawiającego idzie do konkurencji ? firma ta chwali się na rynku, że ma referencyjne branżowe rozwiązania ?
Byli bardzo zaskoczeni (i wściekli) gdy dowiedzieli się, że zgodnie z umową analizę i projekt implementacji (model PIM) nowych funkcjonalności, których nie ma ich ERP, robię ja. Ich tłumaczenie, że tylko oni maja wiedzę by to robić bo to ich ERP było nie do obrony: pokazałem im opis ich własnego systemu, jego metodyki wdrożenia i informację, że jest wykonany znanym narzędziem i w znanej technologii, i że projekt jaki ode mnie dostaną będzie wystarczający i prawidłowy by go zaimplementować w tym ERP. Niestety, tu nie przejęli wiedzy i pomysłów zamawiającego. Tak się da zrobić, trzeba nie dać się szantażować swojemu własnemu dostawcy.
To dlatego dostawcy Ci (nie tylko ERP i inne gotowe systemy, także firmy tworzące oprogramowanie dedykowane) zrobią wszystko, by zastana u klienta analiza poszła do kosza i naciskają na to, by analizę wymagań (przedwdrożeniową) powtarzać rękami ich pracowników. Nie prawdą jest, że analizę wymagań może poprawnie zrobić wyłącznie dostawca oprogramowania. Dostawca gotowego systemu ma wykonać analizą pokrycia wymagań przez dostarczane przez siebie oprogramowanie (opisana tu kiedyś analiza gap/fit). Deweloperzy, dostawcy spokojnie mogą wykonać implementację wymaganych nowych funkcjonalności na bazie poprawnego projektu. Problem mają w tym, że wtedy nie mogą go przejąć. (Prawo autorskie, szpiegostwo przemysłowe i projektowanie).
Artykuł ten stale na budzi wiele kontrowersji i pytań oraz sprzeciwów, głównie jednak ze strony dostawców oprogramowania. Obserwuje inny ciekawy symptom: kupujący systemy ERP wierzą, że dostawca oprogramowania ERP w jakiś cudowny sposób naprawi ich firmę i należy się go słuchać. Zresztą prawie każdy dostawca ERP tak mówi. To także jest mit. Artykuł ten dotyczy nieuczciwych praktyk a nie „wszystkich dostawców oprogramowania ERP”.
Zaczynam dostrzegać coraz większe podobieństwo pomiędzy korporacjami farmaceutycznymi i dostawcami kompleksowych systemów ERP, jedni i drudzy twierdzą, że:
kupując ich produkt gdy Cię boli, ból przejdzie,
kupując ich produkt gdy Cię jeszcze nie boli, nie zaboli Cię w przyszłości (inni biorą, ich nie boli), po zażyciu nie ma możliwości sprawdzenia co by było gdybyśmy nie zażywali ale mówią, że na wszelki wypadek należy zażywać (słynne reklamy witamin, suplementów diety a nawet pasty do zębów),
nie trzeba iść do lekarza na konsultacje, nasze produkty kupisz bez nich (bez recepty),
jeżeli ktoś mówi, że nasze lekarstwo nie działa to na pewno kłamie, nie słuchaj go,
owszem, wielu ludzi po zażyciu naszych leków miało kłopoty, niektórzy zmarli, ale to tylko dlatego, że nie czytali ulotki.
Dostrzegam także to, że wielu menedżerów daje się szantażować dostawcom ERP, którzy zaraz po podpisaniu umowy zaczynają stawiać warunki jakby zapominali kto komu i za co płaci. Zresztą bardzo często są to umowy o bardzo złej treści, gorąco odradzam zawieranie umów z dostawcami oprogramowania tylko ze wsparciem własnych prawników na bazie wzoru umowy dostawcy oprogramowania. Z całym dla nich szacunkiem, Wasi prawnicy są na pewno specjalistami z Waszej branży czy prawa gospodarczego, ale mało który ma doskonałe obycie w branży IT i prawie autorskim. Na tej niewiedzy żerują dostawcy oprogramowania, którzy często szantażują swoich klientów licencjami i ograniczeniami dostępu do kodu.
Jak zapanować nad dostawcą
Najpierw krótki opis tego co Państwo kupujecie. Poniżej struktura każdego dobrze zaprojektowanego oprogramowania:
A więc krótko, żeby nie zanudzać: Każde oprogramowanie jest mniej lub bardziej gotowe (zaryzykuje, że jest gotowe w ponad 90%), dotyczy to także tak zwanego oprogramowania dedykowanego. Oprogramowanie w całości dedykowane różni się od tak zwanego gotowego tylko tym, że nie ma jeszcze „Logiki biznesowej dostarczonej”. Dostawca oprogramowania w zasadzie musi zrobić dwie rzeczy: skonfigurować środowisko, które dostarcza w tym ewentualnie integrowane oprogramowanie (powyżej wszytko to co niebieskie) oraz stworzyć kod jeszcze nie istniejący czyli Logikę biznesową dedykowaną (implementacja). W przypadku dostawcy pakietu ERP tej gotowej logiki jest na prawdę bardzo dużo.
I teraz:
Dostawca udzieli Ci licencji na wszystko co niebieskie, tu należy sprawdzić czy jest autorem wszystkiego (co jest mało prawdopodobne) czy tylko części.
Najgłupszym pomysłem jest zgoda na dostosowywanie Logiki dostarczonej do swoich potrzeb bo:
jest to bardzo kosztowne (ingerencja w ogromny istniejący kod wymaga bardzo dużo zmian w tym testów)
całe Twoje know-how staje się własnością dostawcy oprogramowania, Twoja Logika biznesowa wzbogaciła kod dostawcy, praktycznie nie możesz zabronić jej dalszej sprzedaży.
Najlepszym pomysłem jest wcześniejsze udokumentowanie i zawarcie w kontrakcie oddzielnej części oprogramowania: Logiki biznesowej dedykowanej, do której zachowujesz pełnię praw i absolutnie nie przekazujesz tych praw wykonawcy oprogramowania, to że napisał ten kod na bazie dokumentacji jaką mu dostarczysz, nie daje developerowi żadnych praw do tej części kodu (Logiki biznesowej dedykowanej, ale to wymaga dobrze napisanej umowy!) gdyż wtedy programista tworzy utówr zależny i nie nabywa do niego żadnych praw, w umie należy dodatkowo zawrzeć klauzulę o ochronie know-how. Wiem, że większość programistów mówi, że to nie prawda, zapewniam Cie, że mam rację – sprawdzone w praktyce.
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 podobno dużo kosztuje! Nie, dostawca oprogramowania z reguły i tak na Twój koszt to w jakiejś formie zrobi! Dodatkowo 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). Większość wdrożeń jest prowadzona w sposób, który odradzam, owszem ale (ten cytat dla dociekliwych) większość firm IT dorada właśnie kastomizację:
…powszechność jakiegoś poglądu to bardzo słaby, by nie rzec – żaden dowód jego prawdziwości. Powszechne bywają chociażby mity, które ex definitione nie mają nic wspólnego z prawdą. […]
Dlatego właśnie Sokrates przywiązywał tak wielką wagę do tego, aby precyzyjnie i jednoznacznie definiować terminy i pojęcia, jakich używamy w dyskusji i odrzucać to, co w naszym ich rozumieniu jest przypadkowe, niepewne i stanowi efekt nie naszej faktycznej wiedzy, lecz jedynie podzielanego z innymi ludźmi stereotypu dotyczącego przedmiotu rozmowy. (Czy powszechność jakiegoś poglądu jest wprost proporcjonalna do jego prawdziwości?).
I na koniec: wybierając gotowe oprogramowanie na prawdę nie ma sensu wypisywanie setek wymagań. Należy zrezygnować z wielodniowych wywiadów i spisywania setek życzeń. Lepszym podejściem jest analiza tego jak organizacja działa, zidentyfikowanie obszarów „standardowych” oraz tych, które są Państwa „specjalnością” (Logika biznesowa dedykowana), potem wybrać najbardziej pasujący pakiet oprogramowania i nauczyć się go używać (wdrożyć do użycia). Brakującą logikę zlecić jako dedykowany pod-projekt (ale na bazie wcześniej wykonanego dla siebie projektu) i stać się właścicielem powstałego oprogramowania. Podejście polegające na uznaniu, że nowe oprogramowanie należy dostosować do potrzeb użytkowników z reguły kończy się sprowadzeniem nowego, nie raz bardzo wartościowego, oprogramowania do tego co stare i znane i to na koszt kupującego z bardzo miernym skutkiem.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Przypomnę na początek co prawie dwa lata temu napisałem:
Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża).
Tak więc jednak polecam: zastanowić się nad potrzebami, zamówić wykonanie analizy i dokumentacji wymagań i z tym dokumentem szukać dostawcy i nie dać wcisnąć sobie teorii, że duży może więcej?. Możliwe ale nie zapominajmy, że duży to także bezwładny (polecam cały artykuł: Nigdy więcej ERP w jednym kawałku!)
No i mamy obecnie:
Przedstawiciele co trzeciej brytyjskiej firmy (35 proc.) przyznają, że byliby skłonni zastąpić wykorzystywany obecnie system klasy ERP bardziej elastycznym rozwiązaniem o podobnej funkcjonalności. (źr. Czego najbardziej brakuje systemom klasy ERP?)
Nasuwa się pytanie: czym je zastąpić? Leży właśnie na moim stole książka ([[Large-Scale Software Architecture. A practical guide using UML. Jeff Garland, Richard Anthony]]). I co my tu mamy? Przede wszystkim opinię i wskazówki doświadczonych projektantów i developerów.
Książka jest tak „dobra”, że w zasadzie można ją w kawałkach zacytować od dechy do dechy. Jednak i nie chce i nie można tego robić :). W czym rzecz?
Duże oprogramowanie to nie jeden system
I tu leży pies pogrzebany. Kolejność zalecana przez autorów książki za każdym razem, niezależnie od wielkości projektu:
analiza i określenie celu projektu
analiza biznesowa, opracowanie wymagań
projekt architektury rozwiązania (ogólny model dziedzinowy), podział na komponenty (obszary dziedzinowe)
okreslenie, które komponenty (podsystemy) należy wytworzyć, a które można kupić na rynku (tak zwane COTS, ang. [[Commercial off-the-shelf]])
sprawdzenie dostępności i kosztów
opracowanie wynikowego projektu i wymagań na podsystemy dedykowane.
Praktyka pokazuje, że jednym z takich dużych COTS może być (i często jest) system ERP (jego wybrana część). Najczęściej moduły produkcji, księgi głównej, kadrowe itp. Jednak zarządzanie sprzedażą czy specyfika procesów wewnątrz organizacji to coś co spędza sen z powiek dostawców ERP bo to zawsze „nie pasuje”. Największym zaś, w moich oczach, nadużyciem ofert na ERP jest twierdzenie, że wspomagają zarządzanie procesami biznesowymi. Bo jeśli pomagają zarządzać dokumentami, co jest prawdą, to raczej nie są w stanie konkurować z systemami work-flow bo to zupełnie innego rodzaju systemy i nie przypadkiem powstały jako oddzielne rozwiązania. Do tego dokumenty finansowo-magazynowe to mniejsza część wszystkich dokumentów w firmie, więc dlaczego ERP miał by być tu „dobry”? A hurtownie danych? To także nie przypadek, że są osobnymi systemami. Dostawcy ERP permanentnie używają akronimu Moduł BI w swoich ofertach zaś cichaczem oferują dedykowane systemy BI i integrują je.
Tak więc najczęściej okazuje się, że niestety główną wadą systemów zintegrowanych ERP jest to, że są zintegrowane (czytaj niepodzielne) co już nie raz tu pisałem i wychodzi, że nie ja jeden.
W ubiegłym roku skończyłem projekt dla firmy [[Galeco Sp. z o.o.]]. W dużym uproszczeniu projekt wyglądał tak:
Analiza biznesowa: model biznesowy, optymalizacja procesów, określenie kluczowych czynników sukcesu,
Określenie wymagań na oprogramowania w kontekście kluczowych czynników sukcesu.
Wskazanie miejsc, w których można użyć gotowego oprogramowania
Zaprojektowanie wymagań na oprogramowanie (podsystemy itp.), które są potrzebne Galeco a nie są dostępne jako gotowe na rynku.
I ta własnie kolejność jest lepsza. Pozornie to samo osiągniemy gdy wpuścimy dostawcę systemu ERP i on po analizie powie czego (jakich wymagań) jego system nie realizuje. Jednak:
Dostawca gotowego systemu nie ma żadnej motywacji (wręcz przeciwnie) do wskazywania innych niż swoje rozwiązań (stąd permanentnie pojawiają się w ofertach i projektach tak zwane kastomizacje, które są powszechnie oferowane przez sprzedawców a odradzane przez producentów tego oprogramowania ERP).
U dostawcy ERP natychmiast pojawia się syndrom młotkowego: jak ktoś ma w ręku młotek natychmiast wszystko co zobaczy kojarzy mu się z gwoździem.
Wystarczy odwrócić kolejność działań: zamiast wybierać dostawcę ERP, który powie na czym wymięka jego system, warto najpierw zaprojektować całość a potem popytać kto i w czym czuje się świetnie. Tu jednak pojawia się problem: dostawca gotowego systemu nie zarobi na kastomizacji ale chyba o to chodzi by było od razu dobre a nie w nieskończoność dostosowywane.
Dlaczego producenci odradzają (metodyki zalecane przez producentów nie stosowane w Polsce!) ingerencje w ich gotowe oprogramowanie? Bo taka ingerencja odcina natychmiast użytkownika od możliwości wykonania prostego upgrade’u! Kolejna, nowa wersja systemu wdrożonego z tak dużym trudem (i kosztem) kastomizacji wymaga kompletnego projektu od zera, powtórzenia od początku całej pierwotnej pracy nad wdrożeniem.
Jak tego uniknąć? To proste, posłuchać producentów oprogramowawszy ERP:
Opracować własne wymagania.
Dać dostawcom systemów ERP by wykonali tak zwaną analizę gap/fit (co nasz system ma a czego nie ma).
Wybrać najkorzystniejszą ofertę, wdrożyć system szybko (bo bez kastomizacji).
Zaprojektować brakujące funkcjonalności i zamówić ich implementację, zintegrować z dostarczonym ERP.
Teraz upgrade ERP to proste wgranie nowej wersji (no prawie ale o niebo łatwiej i taniej!) Po drugie nie narażamy się na presję dostawcy ERP i nie uzależniamy od niego w 100% (zjawisko określane jako «vendor lock-in». Tak zaprojektowany system staje się systemem otwartym, pozwalającym wymienić lub dodać funkcjonalności bez ingerencji w pozostałe. I niezależnie od tego jak „uniwersalny” jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że „brzydszy” ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat… Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem.
Pamiętajmy pewną starą reklamę: „Banki od wszystkiego są do niczego”.…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Przyszła w końcu pora na model dziedziny systemu i model sekwencji dla przypadków użycia. Wspomnę także o wymaganiach niefunkcjonalnych? W poprzednim artykule: Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu opisałem proces do powstania opisu przypadków użycia. Mamy za sobą podstawową pracę z dziedziny jaką jest [[analiza systemowa]]. Postawiliśmy problem do rozwiązania: jakie oprogramowanie powinno powstać. Pod pojęciem jakie należy rozumieć: co powinno ono robić. Opracowano model, przetestowano go. Oceniono dwa warianty (w dużym skrócie ;)), w drugim wariancie obsługa płatności została zlecona partnerowi ([[outsourcing]]) i podjęto racjonalną decyzje o wyborze tego wariantu.
Po tej decyzji mamy zamknięty zakres wymagań: system ma rejestrować zamówienia i pozwalać na natychmiastowe dokonanie płatności. Wiemy także, że nasz system jest częścią większej całości. Outsourcing to decyzja hipotetycznego sponsora projektu na bazie otrzymanych informacji. Koniec analizy biznesowej.
Pora iść dalej. Tym razem problem brzmi: kto i w jakiej technologii ma wykonać to oprogramowanie. Znowu przydały by się warianty czyli różne oferty wykonania tego oprogramowania. Czego nam brakuje by oferty były porównywalne? Modelu tego co należy wykonać! Czy można jako element takiego zapytania dać model przypadków użycia? Z jednej strony można powiedzieć, że owszem. W końcu mamy dokładny opis tego, jakimi cechami (funkcjonalności) ma się charakteryzować to co otrzymamy. I robi tak większość firm. Gdzie widzę kłopot? Zapewne część czytelników zauważyła już, że pominąłem wymagania poza-funkcjonalne.
Dygresja budowlana – pouczająca przygoda
Wyobraźmy sobie, że chcemy zlecić budowę domu. Jego funkcjonalności to między innymi: oddzielne miejsca do spania oraz czytania i oglądania telewizji (tak zwany salon). Kuchnia złączona z salonem. Łazienka na każdym piętrze. Wejście z zewnątrz do salonu poprzez mały przedpokój. Garaż połączony z przedpokojem. I jeszcze wiele innych. Wymagania poza-funkcjonalne, tych może być ogrom! Dom ma być ładny, nie może być podobny do domu sąsiada, musi spełniać wymagania prawa budowlanego, kolorystyka dachu powinna być skorelowana z elewacją, bieżące koszty ogrzewania powinny być możliwie jak najniższe, dom powinien dać się w przyszłości łatwo rozbudować o dwa nowe pomieszczenia. Dom powinien być przygotowany do potencjalnej instalacji komputera w każdym pokoju. Powinno być możliwe zainstalowanie klimatyzacji w ciągu trzech lat od zakończenia inwestycji.
Taki dokument może mieć dziesiątki stron, weryfikacja jego treści (spójność, techniczna niesprzeczność, inne) może być trudna. Opracowanie go w gronie np. czteroosobowej rodziny będzie wyzwaniem już tylko w kategoriach negocjacji ;). Żeby zabezpieczyć się przed „interpretacją” wykonawcy dokument będzie obrastał w szczegóły, ale takie o których pomyślą autorzy dokumentu: rodzina. Jakie mają w tym doświadczenie? Większość tych oczekiwań to własnie poza funkcjonalne życzenia!.
Jak uniknąć tej benedyktyńskiej pracy, której ryzyko rośnie wraz z rozrostem dokumentu? Idziemy do architekta. Nasza rodzina idzie do architekta, ten na bazie powyższych opowieści doprowadza do jakiejś koncepcji rozwiązania (projekt wstępny, koncepcyjny). W momentach sporu pełni role mediatora (łazienka ma być przy salonie czy przy pokoju dzieci), pokazuje na modelu (projekt koncepcyjny, który ewoluuje w trakcie takiej rozmowy) wady i zalety obu rozwiązań, pozwala rodzinie podjąć świadomą decyzje. Zaletą wizyty u architekta, zanim zapytamy jakiegokolwiek developera, jest to, że architekt jest wolny od jakichkolwiek uprzedzeń czy przyzwyczajeń. W każdej dziedzinie inżynierii wykonawcy są wyspecjalizowani, jeśli damy im wybór, będą stosowali technologie najmniej ryzykowne dla siebie (najlepiej poznane) a nie optymalne dla inwestora i to jest oczywiste.
Dlatego warto najpierw iść do architekta, ten nieskażony technologiami (bo nie ma w tym żadnego interesu), opracuje nam projekt funkcjonalny, ale zawierający pewne szczegóły rozwiązań (np. zabroni budowy betonowej ściany w miejscu gdzie my oczekujemy przyszłej rozbudowy). Popatrzymy na coś, co potrafimy szybko ocenić nie tylko od strony wymagań funkcjonalnych (muszla pod półką spełnia stawiane jej wymagania ale czy jest to wygodne?) Na projekcie od razu wychwycimy, czego w tekście opisu raczej nigdy: elementy estetyki, wygody, podjęte kompromisy będą dla wszystkich zrozumiałe i nie będą w przyszłości podważane.
Diagram klas czy model dziedziny – co ma powstać?
(programiści mogą to pominąć)
Otóż [[diagram klas]] ([[UML]]) to narzędzie podobne do rysunku technicznego. Ważne jest to co on przedstawia i to należy najpierw zdefiniować (dopóki nie wiem czy mam napisać: książkę czy rozdział podręcznika, nie wiem co mam w tym języku wyrazić). Tak więc coś należy założyć. Podstawowym założeniem jakie tu przyjmę jest: nie tworzymy oprogramowania od zera. A wiec od czego? Wiele firm programistycznych używa gotowych szkieletów oprogramowania, tak zwanych [[framework]]ów. Są to gotowe, najczęściej dziedzinowe (adresowane dla konkretnej dziedziny zastosowań) biblioteki podprogramów (klas w technologiach obiektowych).
Obejmują zazwyczaj typowe,uniwersalne funkcjonalności takie jak logowanie, wyświetlanie treści na ekranie, zapis do bazy danych (a tak na prawdę utrwalanie, bo baza danych to nie jedyny sposób) , sterowanie zachowaniem się aplikacji, elementy bezpieczeństwa i wiele innych. Funkcjonalności większości biznesowych aplikacji można podzielić na trzy grupy: sterowanie programem, obsługa interfejsu użytkownika oraz funkcjonalności specyficzne dla dziedziny (miejsca) zastosowania. Mamy więc dziedzinę problemu, interfejs użytkownika i sterowanie całością. Innymi słowy mamy: Model, View (widoki), Controller (sterowanie) czyli najpopularniejszy obiektowy wzorzec projektowy aplikacji o wdzięcznej nazwie [[MVC]].
Wniosek z tego taki, że jeśli założymy, że taki szkielet zostanie użyty (a możemy to zapisać w wymaganiach poza-funkcjonalnych dla wykonawcy) to pozostaje po zakończonej analizie biznesowej dokonać analizy obiektowej i zaprojektować [[model dziedziny systemu]]. Narzędziem do jego pokazania jest właśnie diagram klas notacji UML.
Model dziedziny systemu Zamówienia
Tak więc wszystko jasne 🙂 wiec do roboty. Pierwszy etap to opracowanie listy obiektów biznesowych. Tu wkracza kolejna metoda, która stosuję: obiekty dzielimy na narzędzia i przedmioty przetwarzane z pomocą tych narzędzi, pamiętamy, że tego wszystkiego ktoś używa: nasz aktor. Prosty przykład: Do wystawienia faktury potrzebne są: formularz faktury (oczywiste) i fakturzysta (ktoś musi wiedzieć co należy zrobić). Pierwszy stopień innowacji: kalkulator dla fakturzysty. Kolejny stopień to elektroniczny formularz. Obiekty biznesowe: wzór formularza faktury, kalkulator, fakturzysta oraz oczywiście kuwetka na wystawione faktury. Dlaczego tak?
Kolejna metoda analizy i projektowania powiązana z wzorcem MVC: [[Domain Driven Design]] (projektowanie oprogramowania bazujące na modelu dziedziny systemu) czyli DDD. O co tu chodzi? Ogólnie o to by projektować oprogramowanie dość wiernie symulując (a raczej odwzorowując) poznaną rzeczywistość. Dlaczego? Bo osiągamy bardzo ważną korzyść: nawet jeżeli nie uda nam się odkryć sensu istnienia jakiegoś obiektu, mimo wszystko modelujemy go bez uproszczeń, dzięki temu w przyszłości, rozwijając system, nie nadziejemy się na problem wywołany takim uproszczeniem gdyż takie początkowe uproszczenie staje się nie raz poważnym ograniczeniem. Druga zaleta: model taki jest relatywnie łatwiejszy do percepcji niż model z uproszczeniami, w szczególności totalnie niestrawny dla zwykłych ludzi (czyta: nieweryfikowalny przez zamawiającego) [[model relacyjny w trzeciej postaci normalnej]]. Tu bardzo przepraszam czytelników biznesowych, że użyłem niezrozumiałych zapewne dla nich pojęć, ale to właśnie pokazuje, że na tym etapie zamawiający traci kontakt (zrozumienie) z wykonawca tego co sam zamówił zamawiający.
Z modelu procesu dowiadujemy się, że następujące obiekty biorą udział w realizacji potrzebnych nam funkcjonalności: Formularz Zamówienia i koniec! Na pewno? Nie 🙂 bo chcemy by jednak by był to automatyczny system internetowy, wiec potrzebny jest Zarządca. On wie: jak przyjmować Zamówienia oraz skąd brać dane i gdzie je wysyłać. Klient (zamawiający) jest tu aktorem i nie jest on absolutnie obiektem biznesowym do implementacji. Mamy więc dwa obiekty biznesowe: Zarządca i FormularzZamówienia. Do tego mamy interfejsy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzebna mi kuwetka. Baza danych to dla biznesu słowo obrzydliwe i nie używamy go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, .… aaaaaaaa, a same Zamówienia? :). Komplet:
FormularzZamówienia
GeneratorDruczków
Kuwetka
Zarządca
Zamówienia
Nie zapominamy, że mamy Framework i interfejsy (ERP i Płatności). Pojawił się jeszcze GeneratorDruczków. Skąd się wziął? Kolejna metoda projektowania: [[Role, odpowiedzialność, współpraca]]. Otóż, warto Zarządcę zwolnić z obowiązku posiadania wiedzy o aktualnych wzorach dokumentów. Te wiedzę o aktualnie stosowanych wzorach dokumentów (i rolę) posiada GeneratorDruczków. I mógł by ktoś powiedzieć, że niepotrzebnie komplikuje program. Owszem, skomplikował się. Jeśli jednak w programie pojawią się kiedyś nowe funkcjonalności, inni Zarządcy, wszyscy będą pobierali druczki z jednego miejsca bez zastanawiania się czy są właściwe bo mamy tylko jedno ich źródło, które odpowiada za to by zawsze były właściwe.
Jak wygląda diagram klas:
Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kontaktuje się wyłącznie z Zarządcą, który go obsługuje. Zarządca korzysta z usług GeneratoraDruczków, Kuwetki, zewnętrznych systemów poprzez interfejsy. Koniec. Co dalej? Ano wypadało by pokazać jak Zarządca, zdaniem projektanta (:)) realizuje nasz przypadek użycia. Na potrzeby usystematyzowania projektu przytocze jeszcze raz scenariusz w firmie troszkę sformalizowanej:
Taka postać scenariusza (dialog) pozwala upewnić się, że zamawiający i projektant myślą tak samo. Mały komentarz: Klient ma przed sobą Ekran Startowy i wybiera opcję (polecenie) Nowe Zamówienie. System pyta o NIP, Klient wpisuje NIP i potwierdza. Możliwe jest nie wpisanie NIP. System wyświetla formatkę nowego zamówienia. Formatka ma wypełnione dane Zamawiającego lub nie, jeśli nie podano NIPu albo nie znaleziono go na liście kontrahentów. Klient wprowadza dane poprzez zaznaczenie tego co chce zamówić, wpisuje ilości itp. na koniec potwierdza. System sprawdza i wyświetla kompletne zmówienie. Klient zatwierdza lub rezygnuje (pominąłem, ewentualną edycję dla uproszczenia, jeżeli firma oferuje tysiące produktów także będzie inaczej :)).
W tym momencie Klient ma jedno lub więcej zamówień do opłacenia, w kolejnym przypadku użycia może zaznaczyć zamówienia do opłacenia i wybrać opcję Inicjacja Płatności, System przygotuje niezbędne dane i przekaże sterowanie do Systemu obsługi Płatności. Nie będzie tu tego opisu, celem artykułu jest pokazanie metody a nie wykonanie kompletnego projektu.
Powyższy scenariusz posłuży teraz do przetestowania i uzupełnienia modelu dziedziny i uzupełnienia go (ten etap nazywany jest często [[proof-of-concept]]). Narzędziem do testowania będzie diagram sekwencji:
[singlepic id=73 w=320 h=240 float=center]
Samo wykonanie powyższego diagramu pozwala na sprawdzenie poprawności pomysłu i jego logiki oraz od razu daje nam możliwość weryfikacji atrybutów i operacji. Po tym teście (opracowanie tego diagramu jest testem koncepcji) uzupełniamy model dziedziny o atrybuty i operacje. Diagram klas to statyczny opis, który sam z siebie niczego nie mówi o współpracy obiektów. Jego poprawna interpretacja (nie licząc systemu pojęć) jest niemożliwa bez tego modelu dynamiki (diagram sekwencji to model dynamiki systemu). Zaryzykował bym nawet tezę, że sam diagram klas nie niesie prawie żadnej informacji wykonawcy.
Model dziedziny wzbogacił się:
Podsumowanie
Przytoczę ponownie cytowany diagram klas:
Powyższy diagram w moim mniemaniu jest raczej pewnym modelem pojęciowym. Bez kilku słów o metodyce projektowania trudno go w ogóle oceniać dlatego pokazałem swój diagram klas, i sposób w jaki powstał. Kluczowe różnice:
W moim modelu typ płatności będzie atrybutem Zamówienia
Obiekt Zamówienie, poza zawartością druku zamówienia, obsługuje także inne dodatkowe zadania (pamiętanie o sposobie płatności, przygotowanie serializacji XML do „wsadzenia” obiektu do ERP, może coś jeszcze…)
Klient w ogóle się nie pojawia, chyba już wiadomo dlaczego…
Pozycja zamówienia została „ukryta” w zamówieniu, zależnie od koncepcji były by to elementy agregatu (pozycjezamówienia u mnie były by w relacji kompozycji do obiektu bazowego DrukZamówienia), nie ma klasy Produkt (magazyn), jest to obiekt za który odpowiada system ERP.
U mnie pojawia się Kuwetka, obiekt odpowiedzialny za składowanie Zamówień, pytania o konkretne Zamówienie, ostatnie zamówienie, zestawienie zamówień za okres to potencjalne operacje obiektu Kuwetka.
Pojawia się także Zarządca, obiekt odpowiedzialny za obsługę przypadku użycia (byc może także innych). Na diagramie sekwencji pojawiła się klasa System obsługi…jest to abstrakcja elementu View wzorca MVC.
Powyższy projekt jest bardzo uproszczony i na pewno ma wiele wad, kilka iteracji projektowania i testów warto by jeszcze przeprowadzić. Celem moim jednak było pokazanie samej metody analizy i projektowania, tego do czego można użyć notacji UML. Pokazać, że można zaprojektować logikę oprogramowania i ją przetestować nie pisząc nawet linijki kodu.
Na koniec chciałem pokazać, że w projektach dedykowanych, jeżeli jest nawet cień ryzyka, że wykonawca będzie błądził realizując nasz projekt (nie oczekujmy od programistów, że będą znali i rozumieli naszą firmę, nie taka jest ich rola) warto wykonać taki właśnie projekt. Po pierwsze przetestujemy nasze życzenia, po drugie powstanie materiał, na bazie którego kilku wykonawców dokona wyceny z niewielkim błędem i bez dużych narzutów na niespodzianki. Czy takie projekty robią developerzy? Ich o to pytajcie. Czy ma to sens? Testowanie diagramów jest co najmniej o rząd wielkości tańsze niż testowanie prototypów przez programistów.
Kto powinien opracować taki projekt? Osobiście uważam, że nie powinien to być wykonawca projektu. Powodem jest po pierwsze to, o czym wspomniałem: każdy się specjalizuje w jakiejś jednej technologii. Po drugie w przypadku jakichkolwiek problemów Zamawiający, jako niespecjalista, nie ma żadnej możliwości merytorycznej oceny wykonawcy, nawet gdyby był szkodliwy dla zamawiającego. Nie twierdzę, że wszyscy developerzy to niekompetentni naciągacze ale też nie dam głowy, że takich nie ma. Sugeruję naśladowanie rynku budowlanego: zarządzanie ryzykiem czyli oddzielenie projektowania od wykonania.
Developer także odnosi tu pewną korzyść: jest zwolniony z odpowiedzialności i posądzania go o kombinowanie, zyskuje dodatkowo mediatora pomiędzy sobą i zamawiającym. Minus jest taki, że wynagrodzenie za analizę i projekt nie wpłynie do jego kieszeni ale cóż… to koszt komfortu pracy ale z reguły nie przekracza on 10 – 20% budżetu na powstanie oprogramowania.
Podsumowanie drugie
Czy to ma sens w przypadku gotowych ERP? Moim zdaniem:
Ingerencja (tak zwana kastomizacja) w gotowe oprogramowanie ERP kończy się bardzo często destabilizacją pierwotnie dobrego oprogramowania.
Jeżeli system ERP jest zamknięta bryłą (z reguły świadczy o tym fakt pracy na relacyjnej, znormalizowanej bazie danych) nie warto go kastromizować bo to kosztowny i bardzo ryzykowny proces, do tego pozbawiamy się możliwości prostego jego upgrade’owania.
Brakujące w firmie funkcjonalności lepiej tworzyć osobno, jako dedykowane projekty bo to po pierwsze chroni inwestycję w ERP, po drugie z reguły kosztuje znacznie mniej i znacznie szybciej jest gotowe do użycia (stworzenie małego oprogramowanie jest dużo prostsze niż modyfikacja dużego). Po drugie pojawiają się już systemy ERP mające strukturę własnie szkieletu opartego na wzorcu MVC i zaprojektowanie nowej funkcjonalności polega na analizie i projektowaniu takim jak wyżej opisane, z tą różnicą że implementacja ma miejsce w środowisku tego ERP a nie w środowisku odrębnego narzędzia programistycznego. Tak więc, paradoksalnie,
powyższe analiza i projektowanie powinny być zawsze pierwszym etapem projektu programistycznego niezależnie od tego czy ma powstać nowe oprogramowanie czy tylko nowe funkcjonalności do istniejącego.
A gdzie się podziały wymagania pozafunkcjonalne?
Generalnie w mojej metodyce są one ograniczeniami dokumentowanymi dla każdego przypadku użycia indywidualnie. Powstaje repozytorium ograniczeń i mapowanie ich na przypadki użycia. Bardzo restrykcyjne ograniczenia (np. wysoka dostępność) mogą być wydzielone z ich przypadkami użycia do osobnego podsystemu i implementowane nawet na osobnej platformie jeśli taka będzie potrzeba związana z rentownością. To jednak temat na osobny artykuł :).
Konkluzja biznesowa: Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
I tu wpadamy w efekt 
