ZARZĄDZANIE ARCHITEKTURĄ IT 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. : THE HERTZ VS. ACCENTURE DISASTER)

Jako doświadczony Architekt IT od lat prowadzą Bloga, dzięki niemu możesz poznać mnie i mój dorobek. Jak uznasz, że mogę pomóc Twojej firmie, do dyspozycji jestem ja i mój czas.

Cyfrowa Transformacja

Wdrożenie nowego, lub aktualizacja, systemu wspierającego zarzadzanie to bardzo ryzykowny projekt:

“[…] 75% projektów ERP kończy się niepowodzeniem, […] tylko 30% projektów transformacji cyfrowej skutkuje poprawą wydajności firmy. […] 90% tych wdrożeń nie dało w efekcie żadnego wymiernego zwrotu z inwestycji. […] 3 główne powody: 1. firmy nie mają po swojej stronie doświadczonego analityka-projektanta, 2. kadra zarządcza nie wspiera i nie nadzoruje wdrożenia, oraz 3. większość kultur korporacyjnych jest w rzeczywistości anty-technologiczna (wbrew temu co same o sobie mówią) co wymaga zewnętrznego wsparcia dla powodzenia projektu.”

Andriole, S. (2021, March 25). 3 Main Reasons Why Big Technology Projects Fail – & Why Many Companies Should Just Never Do Them. Forbes. https://www.forbes.com/sites/steveandriole/2021/03/25/3-main-reasons-why-big-technology-projects-fail—why-many-companies-should-just-never-do-them/

Dlatego warto przemyśleć sposób jego przeprowadzenia, i pamiętać, że:

Jako analityk i projektant spoza organizacji analizowanej potrafię na nią obiektywnie spojrzeć i przygotować do wdrożenia zmian, nowych systemów ERP. Jako doświadczony praktyk i erudyta, jestem angażowany głównie do trudnych i ryzykownych projektów, często są to kolejne podejścia po nieudanym poprzednim wdrożeniu.

Jako doświadczony praktyk, badacz i wykładowca, wspieram zespoły analityków w firmach, dzięki czemu tracą one mniej czasu na szukanie rozwiązań w Internecie i nie ryzykują korzystania z niesprawdzonej wiedzy, co podnosi ich efektywność nawet o 30%.

Analizując firmę niczego nie tworzymy. Analizując firmę zbieramy dane by zrozumieć i opracować opis mechanizmu jej działania: to jej model biznesowy. To jest analiza. Dokument, który powstaje jako wynik analizy to nie jest dzieło czy utwór, to jest opis, to jest know-how analizowanej firmy. Wyzwaniem jest zrozumieć całość i udokumentowanie jej w taki sposób, tak by opis ten tłumaczył to co obserwujemy: dlatego to co powstaje w wyniku analizy to model. Model wyrażamy w sformalizowanej graficznej postaci, bo inna jest niejednoznaczna i nietestowalna. Taki model doskonale pomaga w zarządzaniu firmą.

Czym są wymagania na oprogramowanie? Wymagania na oprogramowanie to wybrany fragment tego modelu, przeznaczony do odtworzenia z pomocą komputera. Może to być wyłącznie przetwarzanie danych i sterowanie, bo komputer niczego więcej nie jest w stanie zrobić. Dlatego wymagania na oprogramowanie to szablony formularzy i procedury ich przetwarzania, gdy tych procedur jest dużo, grupujemy je w komponenty: to jest ich architektura.

Kod (źródłowy, maszynowy) dla komputera to jedynie te procedury wyrażone w wybranym języku programowania.

Jeżeli jakiś obszar firmy, mechanizm jego działania, jest zdeterminowany prawem, normą, czy uznanymi dobrymi praktykami, można w nim zastosować dostępne na rynku, standardowe, rozwiązania.

Całość należy zintegrować, co nie jest już wielkim problemem. (Jarosław Żeliński, 23 maj, 2025, Wstęp do nowej książki)

Od lat prowadzone są badania na temat przyczyn niepowodzeń projektów IT (InfoQ, 2015). Jedną z kluczowych, już na samym początku, jest emocjonalne i oparte na “intuicji” negocjowanie umów z dostawcami ERP, które ignorują fakty i statystyki: wiara w to, że jeden duży i skastomizowany system spełni wszystkie wymagania. W efekcie tylko niecała połowa projektów informatycznych (a tylko ok. 10% projektów średniej wielkości i większych) kończy się sukcesem (Standish Group, Chaos Report).

Doświadczenie zarządów wielu firm pokazuje, że korporacyjny system IT nie powinien mieć “wszystkiego w jednym”, pokazuje, że powinien to być zintegrowany system systemów, obejmujący “tylko to co konieczne”. (źr. LinkedIn: Układanie spraw jak należy).

“Duże projekty IT najczęściej kończą się niepowodzeniem. […] Kluczowe powody to: firmy nie potrafią zdefiniować problemów, które próbują rozwiązać, nie potrafią określić właściwych wymagań i zarządzać zakresem projektu”.

(żr.: Forbes 2021).

Analiza biznesowa i modelowanie systemu

Poniższy model pokazuje zakres i obszar mojego działania: System Informacyjny:

Czy analizę może zrobić dostawca oprogramowania? Hm.. on ma spełnić wymagania, a nie tworzyć je…

Metody

Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle “problemami złośliwymi” . “Problem złośliwy” to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

(Rittel & Webber, 1973)

Fundamentem metod jakie stosuję są modele: proste i skomentowane, sformalizowane schematy blokowe, zrozumiałe dla adresata. Detaliczne spisywanie obserwacji, zachowań i relacji pracowników organizacji odnosi taki sam skutek jak cykliczne, długie w czasie, fotografowanie tarczy zegara: zbierzemy ogrom danych, które nawet na krok nie przybliżą nas do zrozumienia tego, jak naprawdę działa zegar, a to znaczy, że nadal nie posiadamy wiedzy jak go skonstruować. Kilka słów o modelowaniu (i dokumentowaniu):

• jeżeli pracuję nad zrozumieniem logiki działania organizacji, nie ma znaczenia język programowania,
• jeżeli chce udokumentować to co odkryłem, nie ma znaczenia język programowania,
• jeżeli chce zaprojektować architekturę przyszłej aplikacji, nie ma znaczenia język programowania,
• jeżeli chcę opisać wymagane algorytmy, nie ma znaczenia język programowania,
• jeżeli chcę te algorytmy rozłożyć na poszczególne komponenty architektury aplikacji, nie ma znaczenia język programowania,
• jeżeli chce sprawdzić jak to zadziała i czy zadziała, nie ma znaczenia język programowania,

Co ma znaczenie? Znaczenie ma umiejętność dokumentowania wiedzy. Język programowania ma znaczenie dla dewelopera, bo tylko on się nim posługuje. Po drugie implementacja (kodowanie) jest najkosztowniejszym etapem projektu, więc należy minimalizować zaangażowanie dewelopera na rzecz etapu analizy i projektowania. (źr.: algorytmy)

Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm.

(Craver & Tabery, 2019, patrz także https://pl.wikipedia.org/wiki/Redukcja_ejdetyczna)

Rynek zmienia się szybko, więc nie ma sensu długotrwałe zbieranie detalicznych wymagań i szczegółowe projektowanie czegokolwiek. Z uwagi na czas jaki zajmuje takie projektowanie, powstaje duże ryzyko, że taki szczegółowy projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś co nazywamy “waterfall”, jednak brak dokumentów to tak na prawdę brak planów. Co więc zrobić? Dla średnich i dużych projektów (projekty trwające co najmniej rok) tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia. Czyli to co pozwoli tworzyć i rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne i nie będzie wymagało zmian, gdy zmienią się warunki na rynku.

“Cechy wyróżniające nowoczesną teorię organizacji to jej pojęciowo-analityczna podstawa, jej oparcie się na danych uzyskiwanych z badań empirycznych, ale przede wszystkim jej syntetyzujący, integracyjny charakter. Te cechy wyróżniające są zawarte w filozofii, która akceptuje założenie, że jedynym sposobem badania organizacji jest traktowanie ich jako systemów” (Kostrzewski et al., 1979).

Analiza organizacji to forma audytu zgodności działania organizacji z celem powstania. Powinna być przeprowadzona przez “trzecią stronę” (nie powinien to być pracownik audytowanej organizacji ani żaden kontrahent). Nie powinna też się ona opierać na subiektywnych oczekiwaniach, przekonaniach i deklaracjach jej pracowników. Analiza powinna być w 100% oparta na faktach (dokumenty), a wynik analizy powinien wyjaśniać mechanizm powstawania tych faktów.

Udowodniono, że modelowanie procesów biznesowych skoncentrowane na artefaktach zapewnia większą elastyczność w modelowaniu i realizacji procesów niż tradycyjne metody modelowania skoncentrowane na działaniach.

https://www.sciencedirect.com/science/article/abs/pii/S0306437914001264

Na etapie rekomendacji zmian i projektowania rozwiązań, stosują sprawdzoną w nauce i zarzadzaniu metodę idealizacji:

“Projektowanie ideału jest takim sposobem myślenia o zmianie, który można przedstawić tak: w rozwiązywaniu problemów, praktycznie dowolnego rodzaju, można uzyskać najlepsze wyniki dzięki wyobrażeniu sobie idealnego rozwiązania, a następnie cofnięciu się aż do miejsca, w którym znajdujesz się w chwili obecnej. Dzięki temu unikniesz urojonych przez siebie przeszkód, zanim jeszcze w ogóle pojmiesz, jaki ma być ideał.” (Ackoff et al., 2006, 2007)

Aby poznać bliżej tok mojej pracy i jej efekty, zapraszam do lektury artykułu Metoda – analiza systemowa organizacji. Przykłady efektów mojej pracy można poznać z lektury mojej książki:  Analiza biznesowa. Praktyczne modelowanie organizacji adresowanej nie tylko do specjalistów ale szczególnie do odbiorców takich analiz i projektów.

Badanie wykazało o 268% wyższy wskaźnik niepowodzeń w projektach oprogramowania Agile

https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds

Dlatego wierzę nauce, bo nauka owszem, czasem się myli, ale wciąż myli się znacznie rzadziej niż ludzie.

Praca na uczelni daje mi dodatkowe źródło wiedzy oraz doświadczenie, którego źródłem są studenci, z których wielu to doświadczeni pracownicy firm, w których pracują. Publikowanie wyników moich prac to poddawanie ich wnikliwej krytyce recenzentów, to rodzaj audytu mojej osoby. Publikując wyniki moich prac badawczych, daje klientom gwarancję, że moja wiedza i doświadczenie są stale weryfikowane.

Specyfikowanie wymagań i projektowanie oprogramowania

Z uwagi na to, że temat inżynierski i dla wielu menedżerów jest mniej istotny, opis techniczny przeniosłem to artykułu o projektowaniu: Komponentowe metody projektowania oprogramowania zaś opis mojej roli na tym etapie zawiera opis Moja rola w projekcie.

Nadzór autorski

Kluczem sukcesu projektu jest nadzór autorski (lub merytoryczny). Standardowo moje projekty realizowane są wg. mojej specyfikacji, pod moim nadzorem (biorę odpowiedzialność za swoje rekomendacje), co daje Państwu gwarancję panowania nad jakością prac wykonawcy i kosztami tych prac. Jeżeli sami Państwo wybrali dostawcę i widzicie ryzyko po podpisaniu umowy, możecie mi zlecić nadzór merytoryczny nad tymi pracami. Nie wymaga to zgody tego dostawcy, bo nadzór taki to audyty produktów pracy dostawcy oraz wsparcie Państwa w kontaktach z tym dostawcą.

Korzyści

Podstawową korzyścią ze stosowania metod i narzędzi, które oferuję, są osiągane znaczne oszczędności i obniżenie ryzyka projektu. Analizy i projekty opracowane przez jednego, doświadczonego analityka projektanta, są zawsze bardziej spójne i mniej kosztowne niż produkty zespołów i pracy grupowej. 

W typowym projekcie daje to oszczędności nawet rzędu 50%, tym bardziej, że dostawca oprogramowania nie robi już po mnie żadnej analizy, a także nie traci czasu i zasobów (a to dodatkowy koszt Zamawiającego) na rozwiązywanie problemów braku spójności, niekompletności i niezrozumiałości dokumentów od Zamawiającego!

Koszt współpracy ze mną jest znacznie niższy niż potencjalne straty z powodu braku obiektywnego, merytorycznego nadzoru nad pracami dostawcy.

Zasoby

Moje działania wspiera kilkanaście osób, są to pracownicy partnerskich firm. Jako ekspert i firma Jarosław Żeliński IT-Consulting dysponuję pełną obsługą biurową, prawną, księgową, infrastrukturą i oprogramowaniem pozwalającym na bezpieczną wymianę dokumentów projektowych i zdalne konsultacje w sposób nie angażujący środków i zasobów klientów.

Moi klienci, na czas trwania projektu, otrzymują ode mnie pełne wsparcie zestaw narzędzi do zarządzania projektem (patrz: komunikacja w projekcie), przepływem informacji i dokumentów, bez potrzeby kupowania i instalowania jakiegokolwiek oprogramowania po swojej stronie. Po zakończeniu prac, przekazuję klientom komplet wytworzonych dokumentów i prawa majątkowe do ich treści.

Wybrane projekty i referencje

“Jesteśmy tym, co wielokrotnie czynimy, doskonałość nie jest więc aktem, lecz nawykiem.”

(Arystoteles)

Od pewnego czasu nie liczę już zrealizowanych projektów, od 1991 roku jest ich na prawde dużo. Każdego zaczynam i prowadzę jeden duży, a merytorycznie wspieram dziesiątki. Co prawda produkty mojej pracy w znakomitej większości są oznaczane jako tajemnica przedsiębiorstwa, jednak mój dorobek to także jawne opracowania dla administracji publicznej, recenzowane naukowe i popularnonaukowe publikacje, oraz artykuły na moim blogu (wpisy na blogu to fragmenty moich publikacji lub dozwolone, zanonimizowane elementy zakończonych sukcesem projektów).

Wśród wielu moich zrealizowanych projektów były:

• Analiza procesów biznesowych i przepływu spraw, opracowanie koncepcji i wdrożenie elektronicznego systemu przepływu pracy w Państwowym Inspektoracie Ochrony Środowiska.
• Analiza biznesowa i opracowanie map procesów biznesowych w obszarze rozwoju produktów grupy kapitałowej ORANGE SA (dawniej TP S.A.)
• Przeprowadzenie serii szkoleń z zakresu komunikacji i negocjacji dla Migut Media SA
• Analiza procesów biznesowych i opracowanie wymagań na internetowy system licencjonowania i pośrednictwa sprzedaży praw do zdjęć dla BE&W Agencja Fotograficzna.
• Analiza i modelowanie procesów biznesowych, szkolenie kadry kierowniczej z zakresu tworzenia map procesów oraz stałe wsparcie w reorganizacji procesów dla rodziny spółek FCA Sp.z o.o. i ASCOMP Sp. z o.o.
• Analiza i modelowanie procesów biznesowych w obszarze procesu developerskiego w celu ich optymalizacji i rekomendacji do analizy wymagań na system ERP dla Echo Investment SA
• Analiza i optymalizacja dotychczasowych, oraz opracowanie nowych, modeli procesów biznesowych pionu operacyjnego w WestLB Bank Polska.
• Analiza i modelowanie procesów biznesowych oraz modelowanie wymagań na rozbudowę systemu informatycznego Wydziału Dopłat Państwowego Funduszu Rehabilitacji Osób Niepełnosprawnych.
• Analiza procesów biznesowych i modele wymagań na dedykowane podsystemy CRM dla ogólnopolskiego operatora telewizji kablowej VECTRA S.A. (Firma WolaInfo SA w 2009 roku wdrożyła tu system windykacji na bazie Siebel CRM w oparciu o moją dokumentację, uznając ją za jedną z najlepszych z jakimi mieli do czynienia).
• Analiza, modelowanie i optymalizacja procesów biznesowych, opracowanie modelu informacyjnego i specyfikacji wymagań do wdrożenia systemu MS DynamixXL AXAPTA prowadzonego przez ITG SA.
• Analiza organizacji, modelowanie kluczowych procesów biznesowych, określenie strategii informatyzacji oraz rekomendowanej architektury oprogramowania, zdefiniowanie wymagań na kluczowe elementy oprogramowanie dla Eko-Park SA.
• Wykonanie analizy oraz opracowanie modelu kluczowych procesów i modelu danych dla Urzędu Komisji Nadzoru Finansowego na potrzeby wdrożenia systemu ECM (Enterprice Content Management).
• Opracowanie modelu biznesowego, specyfikacji wymagań oraz zaprojektowanie architektury oprogramowania System Zarządzania Obiegiem Korespondencji oferowanym w modelu SaaS (Software as a Service, ang. oprogramowanie jako usługa), projekt finansowany z funduszy Unii Europejskiej, zarządzany przez Krajową Izbę Gospodarczą Elektroniki i Telekomunikacji, oprogramowanie wykonała firma Neoteric (opis).
• Analiza biznesowa i opracowanie wymagań na oprogramowanie ERP wspomagające zarządzanie dla producenta systemów rynnowych Galeco Sp. z .o.o.
• Umowa na wsparcie merytoryczne projektu analizy i optymalizacji procesów biznesowych Urzędu. Dwukrotnie podpisana umowa z Biurem Polityki Długu i Zarządzania Płynnością Urzędu Miasta Stołecznego Warszawy.
• Przeprowadzenie szkoleń i warsztatów w celu opracowania i wdrożenia metodyki analizy i projektowania w ZETO Kielce SA
• Analiza biznesowa obszaru HR dla Narodowego Centrum Badań i Rozwoju.
• Przeprowadzenie szkoleń, warsztatów i opracowanie i wdrożenie metodologii analizy i dokumentowania procesów biznesowych w Orange SA (dawn. TP SA)
• Analiza procesów biznesowych i model wymagań na oprogramowanie wspierające sprzedaż nowego produktu przez Internet dla Polskiego Banku Przedsiębiorczości SA.
• Analiza modelu biznesowego i modeli procesów biznesowych, rekomendacje dla rozwoju architektury oprogramowania wspierającego proces wydawniczy Grupy Edukacyjnej SA. w Kielcach.
• Analiza, modelowanie i optymalizacja funkcjonowania firmy EXTREM Sp. j., (obecnie Fobaro Group) opracowanie modelu wdrożenia systemu CRM, wsparcie w negocjacjach z dostawcami, nadzór nad realizacją projektu. (referencje)
• Analiza biznesowa, reorganizacja procesów, opracowanie wymagań na system ERP, w tym architektury biznesowej, wybór dostawców i nadzór autorski dla ZWAE Sp. z o.o. w Lęborku.
• Analiza biznesowa i studium wykonywalności Portalu Usług Publicznych dla Miasta Stołecznego Warszawa.
• Analiza funkcjonowania i projekt standaryzacji procedur utrzymania ruchu KGHM SA Polska Miedź. Podpisana umowa na nadzór autorski w toku wdrożenia. Opinia pracownika.
• Analiza biznesowa, opracowanie Opisu Przedmiotu Zamówienia oraz nadzór autorski dla Kancelarii Senatu RP w zamówieniu na wykonanie, utrzymanie i udostępnianie w Internecie systemu informatycznego do obsługi ofert na realizację zadań publicznych w zakresie opieki nad Polonią i Polakami za granicą: Generator Ofert. (ogłoszenie o przetargu i kontakt do zamawiającego, uwagi i pytania zgłoszone do treści OPZ przez czytelników Bloga). Przetarg wygrała i projekt zrealizowała firma Red Ocean Sp. z o.o. z Warszawy.
• Opracowanie Opisu Technicznego Przedmiotu Zamówienia i Nadzór Autorski na system nazwie “System Wspierania Realizacji Zadań ŻW” dla Oddziału Zabezpieczenia Żandarmerii Wojskowej.
• Analiza organizacji i opracowanie strategii informatyzacji dla CAFFARO Sp. z o.o. sp.k.. Wsparcie w procesie wyboru dostawców oprogramowania i bieżący nadzór autorski nad realizacją.
• CAFFARO Sp. z o.o. sp.k.. umowa na utrzymanie i rozwój dokumentacji procesów biznesowych i systemów IT.
• Analiza, optymalizacja i udokumentowanie systemu przepływu pracy i dokumentów Centralnego Ośrodka Sportu wraz z oddziałami, opracowanie Opisu Przedmiotu Zamówienia dla przetargu na system EZD/EOD.
• Analiza wymagań i opracowanie Projektu Technicznego (OPZ) dziedzinowego systemu biznesowego dla TVP SA.
• Powołanie na biegłego ad-hoc przez Sąd rejonowy (pismo z sądu).
• Wsparcie firmy SKANSKA SA w procesie przetargowym (oświadczenie).
• Audyt procesów biznesowych i architektury IT, opracowanie rekomendacji na optymalizację procesów biznesowych i architektury IT dla Kerpro S.C., nadzór autorski i utrzymanie dokumentacji.

Firmy z jawnie podanymi ich nazwami, wyraziły na to zgodę i można się do nich pisemnie zwracać z pytaniami o jakość mojej pracy. Ich pracownicy zastrzegają jednak, że cele i przedmiot tych projektów bardzo często stanowią tajemnicę przedsiębiorstwa i z reguły nie udzielają innych informacji niż potwierdzenie faktu, że usługa została należycie wykonana. Proszę także pamiętać, że w tych firmach także jest pewna rotacja kadr.

Wielu nazw firm moich klientów powyższa lista nie zawiera, gdyż znaczna część umów zawiera zapisy o poufności typu “Strony nie będą informować na swoich stronach internetowych, profilach w mediach społecznościowych, portfelach, w komunikacji marketingowej, ofertach stron trzecich i demonstracjach dla klientów i klientów o współpracy Stron w ramach niniejszej Umowy i w związku z Usługami, w jakikolwiek sposób i w jakiejkolwiek formie, bez uprzedniej wyraźnej zgody drugiej Strony na taką komunikację”. Wiele moich projektów to także audyty w sporach oraz analizy powtarzane po poprzednikach, których dokumentacja została odrzucona z powodu niskiej jakości. Dlatego podstawowym źródłem informacji o jakości mojej pracy jest mój dorobek w postaci tego bloga, wydana książka oraz publikacje naukowe i w prasie branżowej (patrz artykuł O mnie).

Wszystkie publikowane tu artykuły to poddane anonimizacji elementy projektów u moich klientów nie stanowiące tajemnicy przedsiębiorstwa, lub preprinty i streszczenia publikacji naukowych i popularnonaukowych. Opisy użytych metod pracy to publicznie dostępne standardy lub mój osobisty i udostępniony dla innych, dorobek.

Wszystkie powyższe projekty, były realizowane w 90% zdalnie, od Marca 2020 były i są realizowane zdalnie w 100% (czytaj o komunikacji w moich projektach).

Jarosław Żeliński