Tak więc nie raz dedykowane rozwiązanie jest lepsze mimo, że może być kosztowniejsze ale tu wraca jak bumerang to czego prawie nikt nie robi przy projektach IT: analiza strategiczna firmy i budowa scenariuszy rozwoju a potem dopiero wymagania na system IT.
Swego czasu popełniłem artykuł o dedykowanych systemach zatytułowany [[Schyłek epoki krawców]]. Była to polemika z wypowiedzią Prezesa jednej z firm IT, który oświadczył: “[[Powoli odchodzi się od rozwiązań szytych na miarę. Dawniej byli krawcy i im zlecało się robienie garniturów. Teraz po prostu krawców już nie ma]]”. I nadal uważam (mimo, że artykuł uzyskał dość niska ocenę u czytelników), że epoka krawców nie odeszła! Dzisiaj będzie o strategii firmy. Najogólniej rzecz ujmując ([[A.A. Thompson, A.J. Strickland 1996]]) Strategia jest: 1) planem działania; 2) odzwierciedla wzorzec zarządzania w sferze rynku; 3) wskazuje jak wypełnić misje i osiągnąć założone cele.
Ja nadal uważam, że liderzy rynku to firmy korzystające z usług “krawców“!
Na forach internetowych i blogach pojawiają się dyskusje na temat analiz wymagań, jakości oprogramowania, projektowania systemów itp. Motorem tych dyskusji są pojawiające się od czasu do czasu informacje o kolejnych nieudanych projektach zarówno tych wdrożeniowych jak tych strategicznych (w sensie doradztwa strategicznego).
Ostatnimi czasy przybywa zwolenników teorii, że systemy dedykowane dla biznesu odejdą w niebyt. Ciekawe jest jednak to, że lansują tę teorię tylko dostawcy gotowych, ewentualnie tak zwanych parametryzowanych systemów wdrażanych zresztą także nie małym wysiłkiem i współtworzących także tę niechlubną czarną statystykę nieudanych projektów IT.
Ale co to jest ten system dedykowany? Pisany od zera? Nie! Dziś nikt rozsądny nie pisze systemów dla biznesu od zera czyli nie startuje od pustego ekranu. Jak rozumiemy pojęcie systemu dedykowanego? System dedykowany moim zdaniem to taki, który powstał z myślą o konkretnej firmie. Czy trzeba go pisać od zera?
Specyfiką firmy są dane i ich “inność” wynikająca np. z modelu biznesowego czy np. specjalnie opracowanej metody współpracy z kontrahentami. Może to być specyfika rozliczeń z kontrahentami, dedykowany model samoobsługi przez sieć i wiele innych. Specyfiką firmy jednak (raczej) nie jest to, że się faktury wystawia czy to, że jest magazyn. Te moduły czy komponenty z reguły są już kiedyś zrobione, pisanie ich jeszcze raz nie ma sensu, i dzisiaj żadna rozsądna firma z doświadczeniem nie tworzy tych elementów systemu od zera. Ma swoje lub kupione i sprawdzone biblioteki, komponenty, te które z wielu powodów są powtarzalne (np. ustawa o rachunkowości jasno precyzuje jak i jaką wystawić fakturę). Powtarzalne są także elementy zapewnienia bezpieczeństwa, interfejs użytkownika itp. Niektóre nowe systemy “gotowe” to tak na prawdę taka właśnie “kupa bibliotek i komponentów” z “motorem systemu”, który jest czymś pomiędzy systemem gotowym a pisaniem go “od zera”.
Więc jak?
Ano, nie ma moim zdaniem jedynie słusznej decyzji. Firma musi sobie sama odpowiedzieć na ile jest specyficzna i na ile ma sens wdrażanie gotowego systemu albo po prostu zatrudnić analityka i wykonać analizę i projekt.
Stale dziwi mnie to, że tak wiele firm podejmuje decyzje o zakupie tak zwanego gotowego systemu nie mając analizy wymagań i oceny progu rentowności. Na jakiej podstawie ta decyzja? Rozsądniej było by może:
- przeprowadzić analizę biznesową, określić zakres projektu,
- przeprowadzić analizę wymagań i opisać nie tylko oczekiwania w stosunku do systemu ale także cel jaki firma chce osiągnąć z pomocą nowego systemu by ocenić próg rentowności projektu,
- przeprowadzić wybór dostawcy pytając ile będzie kosztowało osiągniecie powyższych wymagań nie decydując z góry czy ma to być system gotowy czy dedykowany bo skąd gwarancja, który będzie mniej korzystny.
Mój ostatni projekt developerski plus kilka analitycznych (modele procesów i wymagania) potwierdzają moje wcześniejsze przypuszczenia. Niektóre firmy mają skuteczną strategię rynkową polegającą na stałym powiększaniu luki do lidera (ich dystans do konkurencji). Ogólnie rzecz biorą polega to na tym, by utrudnić konkurencji szybkie skopiowanie naszego produktu. Jak? Jeżeli elementem tego produktu jest np. sposób świadczenia usługi to:
- system standardowy czyli dostępny na rynku może kupić niemalże natychmiast każdy konkurent,
- system dedykowany jest trudny lub nawet niemożliwy do szybkiego skopiowania (chodzi o uzyskaną dedykowaną funkcjonalność), szczególnie jeśli ktoś z zewnątrz wykona analizę, projekt i przekaże prawa majątkowe do tak powstałego dzieła (tak ja właśnie robię).
Inaczej rzecz ujmując, zbudowanie systemu dedykowanego (co by to nie miało tu znaczyć) daje dużą szansę, że konkurencja będzie miała duży problem z szybkim jego “zmałpowaniem” czyli użyciem standardowego, dostępnego na rynku systemu i co jeszcze gorsze, referencyjnych rozwiązań. Zakup takiego “gotowca” to nic innego jak podkładanie się, bo konkurent poczeka na efekty i kupi to samo na rynku bez większego wysiłku. Powiem więcej, dostawca takiego gotowca, jak tylko skończy go wdrażać sam pobiegnie do naszych konkurentów oferując im “branżowe, prekonfigurowane rozwiązania do szybkiego wdrożenia“.
Implementacja dedykowanego systemu
Moje doświadczenie wskazuje między innymi na to, że największej “odkrytych” podczas wdrożenia “nowych potrzeb” dotyczy danych i ich formatów oraz dedykowanych procedur. Dlatego w środowisku developerów coraz częściej słyszy sie o analizach i wdrożeniach (tworzeniu) nowych systemów zorientowanych na model dziedziny, która to właśnie najczęściej kryje tę “specyfiką” firmy a wykonanie takiej całościowej analizy zabezpiecza przed takim “odkryciami” niemal zupełnie.
Spotkać można w literaturze i nie tylko opis czterowarstwowego modelu aplikacji gdzie druga od dołu warstwa to właśnie warstwa modelu dziedziny. To tu zawarta jest specyfika modelu biznesowego, przetwarzane informacje i reguły biznesowe. Jest to także najważniejsza warstwa aplikacji i projektu zarazem. Tak więc powielenie jej w kolejnej firmie, u kolejnego klienta, wraz z gotowym systemem, czym jest?
Jestem zwolennikiem tezy, że to [[model biznesowy jest źródłem przewagi na rynku]] a nie użyte narzędzia czy same produkty. Jednak system informacyjny firmy wspiera ten model (no tak powinno być). Wśród wielu wzorców projektowych, opisanych między innymi przez Fowlera, jest jeden bardzo skuteczny i zalecany: wzorzec modelu dziedziny. Szczegóły w jego książce, ogólnie rzecz polega na tym, że projekt systemu zaczynamy od wykonania analizy systemowej i modelu biznesowego firmy, nad którym dopiero nadbudowujemy aplikację. Ale temat wzorców projektowych i dedykowanych systemów to już inny artykuł ;), pojawi się niedługo….
