Moim zdaniem, taka era nigdy się nie zaczęła. W branży IT, podobnie jak w każdej innej, panują mody na różne rozwiązania, teorie czy metodyki. Jedną z nich jest wizja zintegrowanego systemu, który wspiera firmę w całym zakresie jej funkcjonowania. Taki model oprogramowania oczywiście ma zalety wynikające choćby z integracji informacji, spójności danych i wsparcia dla całości biznesu. Jest to jednak idea, która w praktyce nie może zostać zrealizowana. Nie jest bowiem możliwe stworzenie jednego, uniwersalnego systemu wspierającego wszystkie obszary biznesowe w danej firmie. Byłby to system bardzo wyspecjalizowany, specyficzny dla tej konkretnej firmy, a w związku z tym drogi i nieopłacalny. Żeby zapewnić dochodowość swoich firm, dostawcy starają się standaryzować systemy. To z kolei powoduje, że nie ma systemu, który da się idealnie dopasować do potrzeb każdej firmy, tym bardziej że wszystkie podmioty są różne i nieustannie się zmieniają. Koło się zamyka.

Jak w takim razie zmniejszyć ryzyko niepowodzenia projektu wdrożeniowego?

Jedną z najważniejszych przyczyn opóźnień i przekroczeń budżetu jest kwestia integracji. Generalnie, zawsze systemy projektowało się w ten sposób, że tworzono moduły obsługujące różne procesy biznesowe i starano się je wzajemnie integrować. Problem zwykle pojawia się, kiedy przechodzimy z procesu A do procesu B. Trudne jest już odpowiednie zamodelowanie przesyłania danych. Struktury danych zmieniają się podobnie jak całe systemy. Cała sztuka wdrożeń polega na tym, żeby wybrać odpowiednie systemy i w odpowiedni sposób je zintegrować. Tymczasem główną zaletą ERP ma być integracja i wsparcie różnych, często wykluczających się procesów biznesowych. To jest właśnie ta fikcja. Trzeba się naprawdę mocno nagimnastykować, żeby poszczególne moduły prawidłowo ze sobą związać. Sporym ułatwieniem może być lepsze przygotowanie do wdrożenia. Przeprowadzenie analizy przedwdrożeniowej to jednak nie wszystko. Uruchomienie ERP samo w sobie - też nie. Warto zastanowić się nad stworzeniem metodycznego projektu architektury korporacyjnej (enterprise architecture).

Projektowanie architektury organizacji powinno obejmować trzy warstwy: biznesową, informacyjną i techniczną. Na pierwszą warstwę składają się zewnętrzne usługi biznesowe i procesy zmierzające do realizacji celu biznesowego. Powinny one zostać zmapowane na wewnętrzne usługi biznesowe, które z kolei muszą być obsługiwane przez odpowiednio zdefiniowane usługi informatyczne. Druga warstwa to warstwa aplikacji i danych (informacyjna). Na tym etapie tworzone są definicje konkretnych danych i komponentów informatycznych oraz projekt ich wzajemnych zależności. Najniższa warstwa dotyczy parametrów technicznych.