Zwracam uwagę, że ?nowy system? to nie oprogramowanie pisane ?od zera? ale tworzenie go z komponentów (bo czym innym są szkielety programowe czyli tak zwane Frameworki). Warto taki scenariusz rozważyć zawsze jeśli koszt oprogramowania ERP wraz z modyfikacjami to kwota już nawet rzędu 200-300 tysięcy. Jeżeli to mniejsze projekty z grupy CRM, rozbudowanych stron WWW i podobnych, tym progiem są nie raz kwoty o rząd mniejsze. W takich przypadkach zawsze warto po prostu wysłać zapytania ofertowe także do firm programistycznych a nie tylko do dostawców gotowego oprogramowania.
Gdybym miał coś zasugerować w kwestii opisanego na początku problemu z wyciekiem danych to wykonanie analizy obecnej funkcjonalności posiadanego oprogramowania, wskazanie wszystkich ryzykownych punktów i dopiero od tego momentu szukał rozwiązania, przy czym nie szukałbym winnego, (bo to będzie teraz trudno udowodnić i jak już wspomniano najpewniej popsuje atmosferę w firmie) a po prostu pozatykałbym jak najszybciej wszystkie dziury.
Wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.
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).
Specyfikacja wymagań powinna dokładnie opisywać procesy, to jakie dane i gdzie są potrzebne, z jakimi innymi systemami należy się zintegrować i wiele innych, istotnych z punktu widzenia zamawiającego i jego infrastruktury oraz potencjalnych kosztów. Teraz dopiero dostawca może dokonać rzetelnej wyceny a specyfikacja wymagań będzie odzwierciedlała potrzeby zamawiającego a nie możliwości dostawcy J.
Po co to napisałem? Absolutnie nie była moim celem krytyka produktu, celem jest zwrócić Państwa uwagę na to by zawsze zapytać o to czy moduły oferowanego oprogramowania są samowystarczalne, czy mogą pracować z oprogramowaniem innych dostawców i jakie to oprogramowanie musi spełniać wymagania. Wybór monolitycznego pakietu to decyzja o tym, że wszystkie poszczególne moduły spełniają nasze wymagania. Nie dajcie się Państwo namawiać na kompromisy w rodzaju: ?ten moduł co prawda nie robi tego co Państwo chcecie ale jest konieczny by działał moduł XXX?.
To prosta droga do zniszczenia pieczołowicie wypracowanych metod pracy w firmie. Reorganizacja przed wdrożeniem nie polega na przejęciu cudzych metod (procesów referencyjnych itp.) tylko na optymalizacji własnych!
Każdy model procesów nie spełniający powyższych zasad można nazwać właśnie naiwnym modelem czyli takim, w którym dowolne symbole, bez zdefiniowanych zasad zostały połączone ze sobą tak jak usłyszano np. w rozmowie z pracownikiem analizowanej organizacji. Modele takie są bardzo często narzędziem do planowania zmian organizacyjnych, specyfikowania wymagań na systemy IT, specyfikowania centrów kosztów w metodach ABC zarządzania kosztami, w wielu innych sytuacjach. Użycie w którejkolwiek z tych potrzeb złego, naiwnego modelu skazuje cały projekt na niepowodzenie.
Tak więc model procesów bez zdefiniowanej i rygorystycznie przestrzeganej semantyki (słownika symboli), syntaktyki (zasad dopuszczalnych relacji pomiędzy tymi symbolami), pragmatyki (co modelujemy i jak) należy odrzucić!
Obecna praktyka pokazuje, że jednak kierunek komponentowy jest słuszny. Komponenty to między innymi: łatwa do wdrożenia architektura SOA, łatwe dzielenie systemu na obszary o dedykowanych kompetencjach (np. osobno kadry i osobno finanse, osobno sprzedaż, inne). Taki podział to tak zwane dziedzinowe obszary a te to nie raz właśnie osobne specjalizowane podsystemy oraz interfejsy pozwalające na ich współpracę.Przy takim podejściu możliwe staje się używanie w modelu SaaS np. systemu CRM i lokalnie księgowości gdyż ilość wymienianych danych jest relatywnie mała i nie stoimy w obliczu utratry integralności danych.
[Czytelnik] Mam do Pana zupełnie prywatnie pytanie. Jak Pana zdaniem wypada oprogramowanie XXXX w porównaniu z innymi, podobnymi rozwiązaniami tego typu na rynku? Chodzi mi zarówno o poziom cenowy jak i funkcjonalność i możliwości tego systemu?
[J.Ż.] Nie wiem czy to Pana pocieszy czy zmartwi ale moja praktyka potwierdza jedno: najpierw cel potem narzędzie. Co ciekawe praktyka pokazuje, że nie licząc pewnych specyficznych dla środowiska cech niezmiennych systemu (są to jego ograniczenia), wdrożyć da się każde narzędzie.
Model jawnie pokazuje, że bezpośredni związek z Bazą Danych mają Dane. Dalej już są wyłącznie niematerialne pojęcia czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?.
Paradoksalnie wykonanie takiego modelu jest tu największą trudnością. Dlaczego? Tworząc go należy bezwzględnie panować na jego złożonością, panować nad subiektywizmem osób z którymi prowadzimy wywiady, rozumieć strategię modelowanej firmy i jej model biznesowy, wiele innych. Identyfikacja procesów sama w sobie jest trudna, wymaga posiadania metod ich identyfikacji i weryfikacji poprawności samej analizy i modelu, to jednak temat na książkę a nie na taki artykuł.
Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?
