Dużo się mówi od pewnego czasu o architekturze systemów informatycznych zorientowanej na usługi (SOA, ang. Service Oriented Architecture) . Jest to trend zmierzający w stronę budowy tych systemów pod kątem specjalizowanych potrzeb biznesowych. Opisane wcześniej procesy biznesowe to nasze potrzeby zaś system to świadcząca nam pewne usługi infrastruktura. Jeżeli jednym z procesów biznesowych jest w firmie fakturowanie to nasz system informatyczny powinien świadczyć usługę wspierającą ten proces w postaci np. programu lub jego modułu dedykowanego do procesu fakturowania. Program taki lub jego moduł powinien operować takimi danymi jakie my w firmie wykorzystujemy. To jest ten moment, w którym to my określamy wymagania na program a nie dostawca narzuca nam możliwości swojego systemu. Zawsze możliwe jest to, że dany produkt nie spełnia naszych wymagań i nie powinno się z niego po prostu zrezygnować.
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".
System IT powinien się zwrócić w okresie rzędu trzech do pięciu lat. Przyjmuje się taki mniej więcej okres zachodzenia istotnych zmian w otoczeniu rynkowym, niektóre firmy uznają nawet, że w ich branży okres ten nie przekracza jednego roku. Uśredniając podane wartości można uznać, że system IT powinien się zwrócić w trzy lata a minimalna inwestycja to 50tys.złotych. Oznacza to, że (dla uproszczenia nie licząc kosztu pieniądza) średniomiesięczny koszt to 50 tys./36 miesięcy=1388zł. Załóżmy, że na IT firmy wydają 2% przychodów (co moim zdaniem jest optymistycznym założeniem) to na inwestycję taką będzie stać firmę o minimalnych miesięcznych przychodach rzędu prawie 70 tys. zł.
Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.
Nie szukać systemu który ?pasuje do nas? bo raczej żaden od razu nie pasuje. Ostrożnie podchodzić do ?dobrych praktyk? i ?modeli referencyjnych?. Zgodnie z zasadą: Jeżeli w dwóch różnych firmach, nawet w tej samej branży, funkcjonuje taki sam model biznesowy i procesowy to w jednej z nich na pewno jest zły! System informatyczny powinien pozwolić obsłużyć nasze wymagania (procesy) ale nie procedury. Procedury tworzy się w tracie wdrażania.
Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien bez potrzeby kontaktu z pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.
Poprawny model organizacji, w szczególności mapa procesów biznesowych, powinien opisywać tylko przedmiot analizy np. specyfikę organizacji będąca np. źródłem jej przewagi konkurencyjnej i to jak organizacja tę specyfikę tworzy. Model powinien się odwoływać do innych istniejących już dokumentów, np. zakresu kompetencji pracownika czy instrukcji stanowiskowej. Model zawsze powinien mieć jakiś cel swojego powstania i kontekst.
Tak więc, model biznesowy, udokumentowane procesy i role powinny być kluczowym wymaganiem jakie stawiać należy systemom IT. Powinny one wspierać model biznesowy i strategię firmy a nie być tylko nowym fajnym i wizerunkowym zasobem. Moim zdaniem wymagania na systemem powinny być oczekiwaniem wsparcia dla modelu biznesowego a nie tylko prostą listą kilku tysięcy funkcjonalności.
Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.
Część analityków używa modelowania tylko do udokumentowania zastanego oraz planowanego stanu rzeczy jednak modelowanie może przynieść daleko większe korzyści poza projektami informatycznymi. Jak przynieść oszczędności samym tylko wykonaniem modelu? Jak osiągnąć korzyści z modelowania odkładając na zakończenie projektu wykonany model na półkę? Historia zna wiele przypadków, że samo wykonanie modelu firmy, oczyszczenie go z nielogiczności, zbędnych czynności itp. powodowało obniżenie kosztów nawet o 30%! Oczyszczenie firmy tylko z niepotrzebnych, nie wnoszących wartości procesów, może istotnie skrócić czas obsługi klientów a to już nic innego jak podniesienie konkurencyjności w czystej postaci.
Proces biznesowy to działanie charakteryzujące się przede wszystkim wnoszeniem wartości dodanej, obecność papieru czy dokumentu w wersji elektrycznej nie ma tu nic do rzeczy. Na mapie procesów biznesowych dokumenty i ich kolejne wersje stanowią produkty procesów (nie jedyne). Proces polegający na podjęciu decyzji to praca człowieka niosąca duża wartość dodaną ale nie obieg dokumentów będących śladami po niektórych tylko procesach w firmie. Inny przykład: procesem jest wyprodukowanie podzespołu i nie ma to nic wspólnego z systemem obiegu dokumentów. Gdzieś po drodze będzie proces powstania dokumentacji technicznej ale to jeden z elementów systemu zarządzania procesami w firmie, jego podsystem.
Ano mamy opis firmy i możliwość wskazania priorytetów w obszarach wymagań na system, tak ważnych przy określaniu wykonywalności projektu IT, w szczególności jego rentowności. Mając model łańcucha wartości można łatwo zbudować model wewnętrznych procesów biznesowych , gdyż jest on ta na prawdę niczym innym jak dekompozycją modelu łańcucha wartości. Idąc wiec droga od opisu firmy do modelu jej procesów można zbudować np. taki oto model w notacji BPMN (od góry: model biznesowy, model procesów, wymagania na system IT) :
