Wprowadzenie

Na temat tego czym jest “system klasy enterprise” toczy się wiele dyskusji, szczególnie w obszarze architektury i projektowania: czyli co to jest? Generalnie spotkać można podejście mówiące, że pojęcie „system klasy enterprise” (ang. enterprise system lub enterprise software) odnosi się do złożonego oprogramowania komputerowego przeznaczonego do obsługi kluczowych procesów biznesowych w dużych organizacjach, przedsiębiorstwach oraz instytucjach. Wielu autorów pisze, że w odróżnieniu od aplikacji konsumenckich czy małych programów narzędziowych, systemy klasy Enterprise są projektowane z myślą o skalowalności, bezpieczeństwie i spójności danych w całej strukturze firmy. Spróbuję uporządkować te definicje.

Pojawia się pierwsze pytanie: czym jest ta złożoność? Pojawia się także drugie pytanie: pojęcie “system klasy enterprise” dotyczy złożoności logiki aplikacji czy złożoności jej środowiska?

I tu pojawia się problem: całkowite pominięcie kwestii aplikacji jako takiej (realizacja funkcjonalności: komu i do czego ona służy oraz jako to robi) oraz środowiska w jakiej ona funkcjonuje. Popatrzmy na przeciętny tak zwany sklep internetowy: jest to logika obsługi klientów, cen, magazynu, płatności, upustów itp. oraz to ile transakcji dziennie jest zawieranych. Czy liczba tych transakcji dziennie ma wpływ na logikę działania sklepy? Nie.

Powiązanym zagadnieniem jest jakość wdrożeń tego typu systemów: niestety bardzo niska. Ciekawe jest to, że takie projekty (projektowanie systemu) często zleca się dostawcom technologii (vendor, deweloper), mimo tego że mają konflikt interesu i z reguły – jako dostawcy – nie mają, niezależnych od technologii, kompetencji analityczno-projektowych (patrz dodatek na końcu).

Pojawia się więc trzecie pytanie: skoro świat raczej nie zna nieudanych instalacji stosów technologicznych ale jednocześnie (wg. różnych szacunków) 75-95% projektów IT to projekty nieudane to gdzie leży trudność?

Krótki przegląd literatury i definicje

Pojęcie i definicja systemu klasy Enterprise (Enterprise Application Software) wywodzą się z praktyki inżynierii oprogramowania oraz standardów opisywanych przez czołowe firmy analityczne i dostawców rozwiązań technologicznych.

Główne użyte tu źródła oraz publikacje:

• Podejście rynkowe:
  • Gartner Glossary & Market Research – klasyfikacja oprogramowania wg Gartnera opisuje Enterprise Software jako aplikacje wspomagające krytyczne procesy biznesowe w organizacjach oraz definiuje standardy integracji i skalowalności (m.in. w raportach Emerging Tech Impact Radar).
  • TechTarget (SearchAppArchitecture / WhatIs) – baza wiedzy IT definiująca m.in. Enterprise Application Integration (EAI), architekturę systemów przedsiębiorstw oraz różnice między aplikacjami dla użytkowników indywidualnych a rozwiązaniami dla organizacji.
• Infrastruktura i dostawcy rozwiązań chmurowych:
  • AWS – What is Enterprise Software? – definicja platformowa charakteryzująca systemy klasy enterprise przez pryzmat skalowalności, automatyzacji i obsługi procesów o kluczowym znaczeniu (mission-critical).
• Akademickie ujęcia IT:
  • Wikipedia – Enterprise Software – ogólne ujęcie historyczne i terminologiczne, opisujące ewolucję pojęcia od lat 90. XX wieku oraz jego podział na moduły wspierające poszczególne funkcje biznesowe (ERP, CRM, SCM).

Wskazywane kluczowe cechy systemów określanych jako enterprise:

• Obsługa procesów biznesowych (Business-Critical): Zarządza krytycznymi dla funkcjonowania firmy obszarami (np. finanse i księgowość, logistyka, kadry i płace, produkcja, relacje z klientami).
• Skalowalność i wydajność: Jest w stanie obsłużyć tysiące jednocześnie pracujących użytkowników oraz bardzo duże wolumeny transakcji i danych bez utraty stabilności.
• Integracja danych i architektura: Zapewnia jedno „źródło prawdy” (single source of truth) w organizacji poprzez integrację wielu działów lub dostarczanie interfejsów (API) do połączenia z innymi systemami.
• Wysoki poziom bezpieczeństwa: Oferuje zaawansowane mechanizmie kontroli dostępu (RBAC – Role-Based Access Control), szyfrowanie, audytowalność operacji oraz zgodność z regulacjami prawnymi i branżowymi (np. RODO/GDPR, ISO).
• Niezawodność i wysoka dostępność (HA / High Availability): Konstrukcja systemu minimalizuje ryzyko przestojów (np. architektura rozproszona, tworzenie kopii zapasowych w czasie rzeczywistym).

Tu warto podkreślić, że na pierwszym miejscu są procesy biznesowe a pozostałe cechy to cechy środowiska technicznego. To procesy biznesowe tworzą wymagania funkcjonalne, a o przydatności aplikacji decyduje przede wszystkim produkt przetwarzania, bo to, że to przetwarzanie “ma działać szybko i niezawodnie” jest problemem czysto technicznym.

Aplikacja, zarówno w języku polskim jaki angielskim, to “komputerowy program użytkowy” rozumianym jako narzędzie dla człowieka.

Aplikacja, zwana również programem użytkowym lub oprogramowaniem użytkowym, to pakiet oprogramowania komputerowego, który realizuje określoną funkcję bezpośrednio dla użytkownika końcowego lub, w niektórych przypadkach, dla innej aplikacji. Aplikacja może być samodzielnym programem lub zbiorem programów. Program to zbiór operacji, które zapewniają działanie aplikacji dla użytkownika.

W odróżnieniu od oprogramowania użytkowego, programy oprogramowania systemowego działają w tle i nie wchodzą w bezpośrednią interakcję z użytkownikiem komputera. Oprogramowanie systemowe zarządza działaniem komputera lub instancji i zazwyczaj obejmuje system operacyjny, hiperwizor oraz sterowniki. Są to zazwyczaj programy niskopoziomowe lub podstawowe w porównaniu z aplikacjami przeznaczonymi dla użytkowników końcowych.

Aplikacje korzystają z oprogramowania systemowego w celu uzyskania dostępu do podstawowych zasobów sprzętowych, takich jak pamięć, pamięć masowa i inne narzędzia. Na przykład aplikacja korzysta z oprogramowania systemowego, aby uzyskać dostęp do systemu plików w celu zarządzania plikami i ich przechowywania.

(https://www.techtarget.com/searchsoftwarequality/definition/application)

Według Martina Fowlera: „Aplikacje korporacyjne służą do wyświetlania, przetwarzania i przechowywania dużych ilości często złożonych danych oraz do wspierania lub automatyzacji procesów biznesowych z wykorzystaniem tych danych”.

Przykłady takich aplikacji:

1. ERP (Enterprise Resource Planning) – zintegrowane zarządzanie zasobami przedsiębiorstwa (np. SAP S/4HANA, Microsoft Dynamics 365, Oracle Cloud ERP).
2. CRM (Customer Relationship Management) – zarządzanie relacjami z klientami i procesami sprzedażowymi na dużą skalę (np. Salesforce, HubSpot Enterprise).
3. SCM (Supply Chain Management) – zarządzanie łańcuchem dostaw i logistyką.
4. HRM / HCM (Human Capital Management) – zaawansowane zarządzanie kapitałem ludzkim (np. Workday, SAP SuccessFactors).
5. BPM (Business Process Management) – platformy do modelowania, automatyzacji i wykonywania złożonych procesów biznesowych.

Podsumowując tę część: system klasy enterprise to może być „duży program”, ale jest to z zasady przemyślana infrastruktura aplikacyjna, która modeluje, wspomaga i automatyzuje działanie całej organizacji, łącząc rożne działy w jeden spójny ekosystem informacyjny. Nie jest to więc jedna aplikacja a system, zbudowany ze zintegrowanych dziedzinowych aplikacji zapewniający spójność danych i systemów pojęciowych, zdolny do obsługi dużych wolumenów danych i dużej liczby użytkowników.

Co ciekawe, wiele firm narzeka na bałagan informacyjny, nie raz używa AI to opanowania tego bałaganu, a to akurat tworzy jeszcze większy bałagan. Od wielu lat (patrz diagram powyżej) mamy dwa rodzaje aplikacji:
– eksperckie, wspierające pracę pojedynczych osób,
– biznesowe, wspierające całe organizacje w zarządzaniu informacje i jej przepływem (enterprise systems).

Problem wielu firm polega na tym, że używają aplikacji jednostanowiskowych do zarzadzania całą firmą. I nie pomaga tu wcale sieciowy dysk i poczta elektroniczna, one tylko powiększają chaos.

Duży system czyli co?

Od wielu lat setki autorów publikują opisy różnych metod modelowania firm wraz z ich zasobami, jedną z typowych form jest piramida procesów biznesowych oraz architektura zorientowana na usługi . Na podstawie tego typu publikacji powstał poniższy model:

Jest to typowa warstwowa architektura modeli opisująca organizację.

Warstwa usług aplikacji to wymagania funkcjonalne wywodzone z modeli procesów biznesowych. Usługi aplikacji to jej przypadki użycia z perspektywy niej samej. Np. aplikacja oferuje zarządzanie dokumentami takimi jak np. faktury jednak kontekst użytkownika: chce sprawdzić co sprzedano lub komu, to cecha procesu biznesowego a nie aplikacji (aplikacje “nie wie” po co jest używana).

Warstwa aplikacyjna to aplikacje biznesowe i ich integracja. Ta warstwa to dziedzinowe aplikacje (ERP, CRM, it;.) i wymiana komunikatów między nimi. Aby ta komunikacja była jednoznaczna, konieczny jest wspólny dla organizacji słownik pojęć, te pojęcia to nazwy i treść atrybutów (pól) formularzy (czyli tych komunikatów).

To czego potrzebuje organizacja to funkcjonalność aplikacji: one wspierają aktywności ludzi: wykonawców zadań w procesach. Dlatego warstwa aplikacji to określona ich architektura i komunikacja. Ta komunikacja to skutek realizowanych usług aplikacji: ich produkty i scenariusze. Przykładowa architektura integracji aplikacji poniżej.

Powyższe to często spotykane tak zwane przetwarzanie rozproszone: komponenty i ich integracja wyrażona w postaci interfejsów i komunikatów przesyłanych w wywołaniach :

Obliczenia rozproszone, takie jak architektury zorientowane na usługi, kładą szczególny nacisk na interfejsy. Interfejsy mogą być zorientowane na procedury (takie jak zdalne wywołania procedur) lub zorientowane na dokumenty (takie jak usługi internetowe). Przyjrzymy się cechom przejrzystości i luźnego sprzężenia, które są kluczowe dla interfejsów rozproszonych, aby pomóc Ci budować lepsze systemy rozproszone.

Najniżej (Architektura korporacyjna) mamy warstwę infrastruktury czyli środowisko pracy aplikacji. Tu są realizowane wyłącznie wymagania pozafunkcjonalne: wydajność, bezpieczeństwo, dostępność.

Warte zaznaczenia: jako ludzie używamy komputera a nie “oprogramowania” (kodu). Oprogramowanie (kod) to lista instrukcji dla procesora komputera, ten dopiero – wraz z urządzeniami peryferyjnymi (klawiatura monitor, drukarka, itp.) – jest narzędziem pracy, a nie “kod”. Poniżej dość znany schemat, pojawia sie w wielu książkach na temat architektury:

Generalnie komputer “od dołu” to kolejno:

• hardware (sprzęt) czyli płyta główna i na niej układy scalone procesora, pamięci, układy i szyny komunikacyjne, porty i urządzenia we/wy itp.
• firmware to oprogramowanie standaryzujące fizyczny sprzęt do poziomu “uniwersalnych komunikatów”, na tym poziomie fizyczne cechy sprzętu są “ukryte” przed systemem operacyjnym dlatego nazywamy to Hardware Abstract Layer (HAL) czyli “abstrakcja sprzętu”.
• OS (Operating System) łączy to wszystko w jednolite, standardowe środowisko dla aplikacji, którego celem jest stworzenie standardowej listy usług (uniwersalne API) dla aplikacji (software), dlatego nazywamy to Operating-System Abstract Lauer (OSAL), mamy obecnie trzy takie standardy: UNIX/Linux, Windows, MacOS.
• Software to to czego używają ludzie (aplikacja).

Czym jest to środowisko? Generalnie sprzęt (jeden lub wiele serwerów) i tak zwane usługi systemowe (czyli te, które nie realizują wymagań funkcjonalnych, tu przypominam, że logowanie to usługa środowiska a nie funkcjonalność aplikacji). Podział na aplikacje i jej środowisko (granica podziału to OSAL) jest także nazywany architekturą hexagonalną . W wersji zawierającej więcej detali przedstawia to poniższy schemat:

Powyższy schemat obrazuje separację aplikacji i całego sprzętu wraz z usługami jakie świadczy, jednak są tu usługi dla aplikacji a nie dla człowieka. Aplikacja to w 100% wirtualny mechanizm implementowany z pomocą komputera: procesor i program (procedury czyli kod), ta abstrakcja jest osadzona w środowisku jakim jest system operacyjny i wszystko to co za nim czyli dyski twarde, bazy danych itp. czyli generalnie porty komunikacyjne (dlatego obecnie Cockburn w miejsce “architektury heksagonalnej” używa pojęcia “to “architektura porty i adaptery”).

Podsumowanie

Przypomnijmy opis (definicję) z początku tego artykułu:

„system klasy enterprise” (ang. enterprise system lub enterprise software) odnosi się do złożonego oprogramowania komputerowego przeznaczonego do obsługi kluczowych procesów biznesowych w dużych organizacjach, przedsiębiorstwach oraz instytucjach. Wielu autorów pisze, że w odróżnieniu od aplikacji konsumenckich czy małych programów narzędziowych, systemy klasy Enterprise są projektowane z myślą o skalowalności, bezpieczeństwie i spójności danych w całej strukturze firmy.

Słownik Języka Polskiego tak definiuje złożoność:

złożony: «składający się z części, elementów», «obejmujący wiele aspektów i trudny do zrozumienia»,

Obie części tej definicji są tu kluczem: duża ilość elementów systemu i w efekcie wiele aspektów jego działania i trudna do zrozumienia całość. Co jest lekarstwem na złożoność? rezygnacja z monolitów na rzecz systemów komponentowych i “federacji aplikacji” pokazanej wyżej. Druga kluczowa rzecz i warunek to dokumentacja projektowa: projekt mechanizmu działania (jak realizowane są funkcjonalności) a potem dopiero implementacja tego mechanizmu. W tej kolejności dokumentacja jest “szczupła” bo zawiera opis istoty działania bez narzuty użytego języka i frameworka (patrz artykuł Ile jest kodu w kodzie). Całość można zobrazować jak poniżej:

Czym więc są “systemy klasy enterprise”? Są to systemy logicznie złożone a przyczyną ich złożoności jest ich wielodziedzinowość a potem ewentualnie obciążenie. Na świecie od dekad mamy dosłownie kilka środowisk, są doskonale poznane a ich “stawianie” jest co najwyżej kosztowne ale nie trudne. Natomiast wielodziedzinowa logika to dziesiątki dokumentów z ich logiką tworzenia i walidacji oraz procedur tworzenia i udostępniania. To tu tkwi wyzwanie: projektowanie systemów informacyjnych a nie informatycznych jest problemem. Jak widać spotykamy dwa podejścia: “enterprise system” to albo określona rozbudowana aplikacja albo całość systemu informacyjnego danej organizacji. Biorąc pod uwagę, że coraz częściej zamiast monolitów ERP wdrażane są i integrowane dziedzinowe aplikacje, ta druga wersja jest mi znacznie bliższa.

Pytanie na koniec: Co jest większym wyzwaniem w projekcie, to, że jakaś firma generuje np. 1000 faktur na minutę, czy to by na każdej fakturze powinien być odpowiedni indywidualny upust wynikający z programu lolajnościowego obejmującego historię klienta i stan jego rozrachunków?

Od dekad nie powstają nowe środowiska ale każdego dnia powstają (są inicjowane) nowe aplikacje. I mamy to na myśli “system wspierający całą organizację” a nie jedną aplikację, zaś zwolennicy “wszystkiego w jednym i jednej bazie danych” w zasadzie zawracaja rzekę kijem, bo jedyne co czasami osiągają to “Gwiazda Śmierci” (Death Star):

Pewne ciekawe spostrzeżenie na koniec

Niska jakość projektów IT

Poniżej wykres jakości projektów: odsetek sukcesów w zależności od wielkości projektów (sukcesem jest osiągnięcie celu w terminie i budżecie)

Jak widać im większy projekt tym, pewniejsza porażka. Nasuwa się więc prosta odpowiedź: nie robić mega projektów, dzielić je na mniejsze. A jednak ludzie tego nie robią.

Z technicznego i biznesowego punktu widzenia niepowodzenia megaprojektów IT (kosztujących powyżej 100 milionów dolarów) wynikają z kilku powtarzających się, systemowych błędów. Według badań prof. Benta Flyvbjerga z Oksfordu, aż 99,5% megaprojektów przekracza budżet, harmonogram lub nie dowozi celów.

Oto główne przyczyny tego zjawiska:

1. Efekt skali i nieliniowa złożoność

• Złożoność nie rośnie liniowo: Projekt dwa razy większy nie jest dwa razy trudniejszy – jest trudniejszy wielokrotnie ze względu na liczbę powiązań.
• Problem integracji: Połączenie setek systemów tworzy tzw. „dług technologiczny” już na etapie produkcji.
• Czynnik ludzki: Koordynacja pracy tysięcy programistów generuje gigantyczny szum informacyjny.

2. Prawo Conwaya i silosy organizacyjne

• Odwzorowanie struktury: Systemy IT odzwierciedlają strukturę komunikacyjną firmy, która je tworzy.
• Brak elastyczności: Wielkie korporacje mają sztywne działy, co prowadzi do tworzenia niespójnego, „posklejanego” oprogramowania.

3. Psychologia decyzji (Błędy poznawcze)

• Skrzywienie optymistyczne: Menadżerowie zakładają najlepszy możliwy scenariusz, ignorując ryzyka.
• Strategic misrepresentation: Świadome zaniżanie kosztów i czasu przez oferentów, aby wygrać przetarg.
• Pułapka kosztów utopionych: Kontynuowanie skazanego na porażkę projektu, bo „wydano już miliony”.

4. Zmiana otoczenia w czasie (Erozja założeń)

• Zbyt długi czas realizacji: Budowa trwa 5–7 lat, a technologia i rynek zmieniają się w 2–3 lata.
• Scope creep: Ciągłe dopisywanie nowych funkcji w trakcie trwania projektu niszczy pierwotny plan.

Powyższe wnioski pochodzą z publikowanych badań nad “regułą 99,5%” i “czarnymi łabędziami” megaprojektów. Najważniejsze analizy statystyczne dotyczące megaprojektów (w tym IT) prowadzi prof. Bent Flyvbjerg z Uniwersytetu Oksfordzkiego:

• Dane o skali porażek 99,5% dużych przedsięwzięć szczegółowo opisuje jego najnowsza książka napisana wspólnie z Danem Gardnerem: How Big Things Get Done na łamach Business Insider.
• Genezę zjawiska tzw. „czarnych łabędzi” w IT (gdzie 1 na 6 projektów notuje średni wzrost kosztów o 200%) Flyvbjerg i Alexander Budzier opisali w klasycznym już artykule Why Your IT Project May Be Riskier Than You Think opublikowanym przez Harvard Business Review. Artykuł bazuje na analizie 1471 dużych projektów technologicznych.

Raporty branżowe na temat statystyk porażek w IT: The Standish Group (Raporty CHAOS): To najbardziej znane, cykliczne źródło danych o porażkach oprogramowania. Z ich wieloletnich analiz wynika, że tylko około 31% projektów IT kończy się pełnym sukcesem, a im większy budżet, tym szansa na sukces drastycznie spada. Metodologię i wnioski opisuje m.in. podsumowanie na BudgetOverrun dotyczący Standish CHAOS Report, a zestawienie historycznych wskaźników znajdziesz w analizie Software Project Failure Statistics na łamach Rockstar Developer University.

Analizy strategiczne i psychologia decyzji:

• McKinsey & Company: Wspólnie z Uniwersytetem Oksfordzkim McKinsey stworzył bazę danych obejmującą tysiące projektów IT, wykazując nieliniowy wzrost ryzyka wraz ze wzrostem budżetu powyżej 15 milionów dolarów. Ich podejście do zarządzania ryzykiem wielkich inwestycji technologicznych opisuje m.in. artykuł Delivering large-scale IT projects on time, on budget, and on value.
• Oxford Said Business School: Oficjalny portal uczelni w artykule Why Megaprojects systemically fail – and what can be done about it? opisuje błędy poznawcze decydentów, w tym skrzywienie optymistyczne (optimism bias) i pułapkę kosztów utopionych.

Konflikt interesu i brak nadzoru

I na tym tle pojawia się ciekawe spostrzeżenie: wymagania pozafunkcjonalne rzadko stanowią więcej niż 10% wszystkich wymagań , a z perspektywy objętości specyfikacji projektowej jest to kilka procent. Mimo tego praktycznie każdy projekt z obszaru software engineering jest zlecany deweloperom lub dostawcom określonej technologii, do czego nie mają oni kompetencji, za to mają ogromny konflikt interesu w roli projektanta. Poniżej pokazano znany w inżynierii v-model (pętla SDLC, Software Development Life-Cycle), mający zastosowanie także w inżynierii oprogramowania.

Standardy branżowe, takie jak niezależna weryfikacja i walidacja (IV&V), kładą duży nacisk na wykrywanie błędów na etapie definiowania wymagań i projektowania. Zgodnie z zasadą 1:10:100 wykrycie błędu na etapie projektowania kosztuje 1 dolara, podczas gdy jego wykrycie podczas standardowych testów kosztuje 10 dolarów, a po wdrożeniu – 100 dolarów (Ensure success in modernization projects with external IV&V services).

Typowe w IT jest zlecanie całości jednej firmie, i to deweloperskiej, co jest pogwałceniem zasady mówiącej by nie łączyć projektowania (lewa strona) z wykonaniem (prawa strona). Powodem jest konflikt interesu: zlecenie całości deweloperowi powoduje, że deweloper (wykonawca) sam sobie stawia zadania i sam ocenia ich wykonanie. To powoduje, że realnie żadnego nadzoru nie ma.

Dlatego od wielu lat pojawiają sie opracowania analityczne o znanych i dużych porażkach, takie jak np. What Hertz v Accenture teaches us about failure in systems development projects) i prawie zawsze pojawia się ta sama rekomendacja: 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. I praktyka pokazuje, że tak zwane nadzorowane wdrożenia, nadzorowane przez zamawiającego z pomocą wynajętego, niezależnego od dewelopera, projektanta-architekta, notują znacznie wyższy odsetek sukcesów.

Dane potwierdzające wpływ zewnętrznego nadzoru na sukces projektów IT pochodzą z globalnych badań agencji badawczych, firm doradczych oraz organizacji zarządzania projektami:

Project Management Institute (PMI) i PwC – W cyklicznych raportach PMI Pulse of the Profession wykazano, że organizacje wdrażające dojrzały, niezależny nadzór strategiczny (Enterprise PMO) odnotowują o 38% więcej projektów osiągających cele oraz o 33% mniej całkowitych porażek projektowych.

Standish Group (Raporty CHAOS) – Standish Group od lat bada przyczyny porażek wdrożeń oprogramowania. Średni wskaźnik pełnego sukcesu projektów IT wynosi zaledwie około 29–31%. Wśród kluczowych czynników sukcesu (tzw. CHAOS Success Factors) niezmiennie wymienia się:

• Formalną weryfikację wymagań i zarządzanie zakresem – co stanowi główny element audytów zewnętrznych (QA).
• Dojrzałość procesową zespołu – obiektywnie weryfikowaną przez zewnętrzny nadzór w celu eliminacji błędów estymacji.

Analizy McKinsey & Company – Badania McKinsey nad dużymi projektami technologicznymi i transformacjami cyfrowymi pokazują, że aż 17% przedsięwzięć IT idzie tak źle, że zagrażają one egzystencji firmy. McKinsey wskazuje, że organizacje stosujące niezależną funkcję wyzwania (ang. challenge function) oraz obiektywne oceny przekazywane bezpośrednio do zarządu (z pominięciem filtracji przez zespół wykonawczy) znacznie lepiej kontrolują budżet i harmonogram.

Metodologie Audytu IT (np. ISACA / COBIT) – Polskie i międzynarodowe opracowania akademickie oraz branżowe (np. analizy Politechniki Warszawskiej dotyczące modeli audytu informatycznego) wskazują na tzw. merytoryczny i formalny audyt jako jedyne narzędzie dostarczające kierownictwu realnych, niefiltrowanych informacji o stanie systemów IT.

Żródła