Ewolucja ERP od monolitycznego pakietu do zestawu usług aplikacyjnych - chmura uczy pokory

(loadposition Wiadomosci_Dzial}

 

W tym momencie warto zdefiniować pojęcie cloud computing. Wśród wielu spotykanych definicji, moim zdaniem najlepiej oddaje ideę ta, podana przez amerykański National Institute of Standards and Technology:

Cloud computing: model dostępu do puli współdzielonych zasobów przetwarzających dane, które mogą być dynamicznie rozdysponowane i udostępnione w sieci na żądanie, przy minimalnym udziale dostawcy.

Generalnie oczekiwane cechy systemów IT to krótki czas wdrożenia i swoboda reorganizacji. Krótki czas wdrożenia oznacza jednak, że nie ma czasu na kilkuletnie mega wdrożenia. Badania opublikowane przez Gartnera:

W poprzedniej epoce firmy wiązały się na wiele lat z jednym dostawcą systemów IT, rozprzestrzeniając wybrane systemy w całej organizacji, czego efektem było często powstanie trudno zarządzalnej, sztywnej infrastruktury, w niewielkim stopniu podatnej na zmiany. Analitycy Gartnera są zdania, że rozpoczęła się epoka projektów, które trzeba będzie rozpoczynać bez znajomości wszystkich wymagań użytkownika, aby nie spóźnić się na rynek z nowym produktem i wykorzystać sposobną chwilę, która może się nie powtórzyć. Przed nami epoka systemów, które budowane są z myślą o ich ustawicznych modyfikacjach w odpowiedzi na zmieniającą się sytuację rynkową.” (źr. Gartner 2013)

Tyle cytatów. Mamy rok 2013, coraz silniej jawi się wizja projektów, które w całości zamykają się w obrębie roku budżetowego.

Rok budżetowy to okres planowania taktyki. Strategie firm to plany na lata, opierają się na wizji i misji firm, jednak bieżące zarządzanie to coroczne budżetowanie, które tworzy roczne plany działania, nazywane często taktycznymi. Z roku na rok, taktyka realizacji strategii może ulegać zmianie. Zmienia się rynek, postęp technologii jest nieprzewidywalny. W efekcie wymagania na oprogramowanie wspierające zarzadzanie mogą ulegać znacznym zmianom w ciągu roku budżetowego. Nie ma czasu na drobiazgowe planowanie, a potem wieloletnie wdrażanie monolitycznych systemów ERP.

Powoli przebija się, z oporami po stronie dostawców zintegrowanych systemów ERP, idea systemów komponentowych.

 

 

Ten trend już można odczuć, kolejne firmy decydują się na zakup i wdrożenia odrębnych podsystemów dziedzinowych. Pozwala to na praktycznie natychmiastowe reagowanie na zmiany na rynku, zamiast 3-5.letnich kontraktów na wdrożenia, zawierane są krótsze, dające swobodę zmiany taktyki zarządzania organizacją, nie wiążące firm na długie lata z jednym dostawca i jedną technologią. Pojawia się pojęcie strategii IT organizacji i bieżącej taktyki.

Aby podejście takie było możliwe potrzebna jest zmiana postrzegania całej organizacji. Organizacje zmieniają spojrzenie na siebie same, zamiast wielkiego monolitu widzą teraz w sobie zespół współdziałających obszarów.

ARCHITEKTURA KORPORACYJNA JAKO STRATEGIA

Coraz częściej można spotkać się z pojęciem architektury korporacyjnej. Definicji tego pojęcia jest wiele, jednak mają one pewną wspólną cechę: wskazują na całościowe podejście do opisu organizacji. Książka „How to survive in the jungle of Enterprise Architecture Frameworks” (Jaap Schekkerman, 2004r.) zawiera taki ogólny opis: Architektura Korporacyjna to całościowy opis organizacji, plan jej wewnętrznego współdziałania, strategii, celów i wizji, definicji pojęć, aspektów operacyjnych, systemów informacyjnych i danych, elementów strukturalnych. Ta i wiele innych definicji nawiązuje do „danych” co jest moim zdaniem konsekwencją strukturalnych metod opisu systemów informacyjnych. Obecnie technologie informacyjne zostały zdominowane przez paradygmat obiektowy analizy i projektowania systemów (paradygmat obiektowy - postrzeganie systemów jako zespołu współpracujących obiektów, paradygmat strukturalny - postrzeganie systemów jako zbioru funkcji przetwarzających spójny zbiór danych). Z tego tez powodu na użytek obecnych projektów polecam posługiwanie się zmodyfikowaną ogólną definicją Architektury Korporacyjnej:



Jak widać nie odnosi się ona do danych. Zakłada, że zarządzanie to cel biznesowy jakim jest dostarczanie produktu na rynek, reszta jest temu podporządkowana. Schemat struktury modelu Architektury Korporacyjnej (AK) nawiązującej do paradygmatu obiektowego (systemowego) najogólniej wygląda tak:



AK to pięć abstrakcyjnych warstw opisujących całą organizację z jej zasobami informacyjnymi: warstwa motywacji biznesowej, procesów biznesowych, usług aplikacyjnych, aplikacji, infrastruktury.

Warstwa motywacji biznesowej opisuje strategiczne cele. Kluczem jest misja firmy, która wskazuje na kierunek rozwoju oraz strategia realizacji tej misji.

Strategia wyznacza metody działania, opisują je procesy biznesowe, które są zgodne ze strategią. Stanowią tak zwany wewnętrzny łańcuch wartości. Proces biznesowy to także wejście, produkt procesu i jego wykonawca. Warstwa procesów biznesowych opisuje operacyjne funkcjonowanie organizacji.

Wiele procesów w dzisiejszych czasach to przetwarzanie informacji. Obecnie praktycznie nie jest to możliwe bez komputerów i oprogramowania. Procesy biznesowe wymagają więc wsparcia usługami aplikacyjnymi. Warstwa usług aplikacyjnych to abstrakcja definiująca wymagania wobec oprogramowania. Z perspektywy oprogramowania są to przypadki użycia tego oprogramowania.

Usługi aplikacyjne są świadczone przez konkretne aplikacje, każda ma interfejs użytkownika (GUI). Aplikacje są zintegrowane z pomocą interfejsów w celu umożliwienia im współpracy (wymiana informacji). Warstwa aplikacyjna reprezentuje oprogramowanie wykorzystywane w organizacji.

Najniższa warstwa to warstwa platform systemowych. Tu dokumentowane są środowiska sprzętowo-systemowe, w których wykonują się aplikacje.

KORPORACYJNY SYSTEM REGUŁ BIZNESOWYCH JAKO METODA DZIAŁANIA

Tu należy powiedzieć o bardzo ważnej rzeczy: regułach biznesowych. Najprostsza definicja reguł biznesowych brzmi: reguły biznesowe wyznaczają granice pomiędzy akceptowanymi i nieakceptowanymi zrachowaniami w organizacji. W ramach AK stanowią one ograniczenia w całej organizacji, dotyczy to wszystkich opisanych warstw. System reguł biznesowych i słownik pojęć biznesowych (pojęcia stosowane w regułach muszą mieć gwarantowaną jednoznaczność) to system obejmujący swoim zasięgiem całą AK, dlatego jest bardzo istotnym elementem AK (nie ma diagramie).

CHMURA I SYSTEMY ERP

Teraz pora na podsumowanie czyli wyjaśnienie tytułu tej pracy. Jak wynika z definicji cloud computing jest to „model dostępu do puli współdzielonych zasobów przetwarzających dane, które mogą być dynamicznie rozdysponowane i udostępnione w sieci na żądanie”.

Kluczem jest tu słowo „dynamicznie”. Spójrzmy jeszcze raz na model AK: z perspektywy procesów biznesowych istotne są wyłącznie usługi aplikacyjne (usługi te, jako przypadki użycia, opisują konkretne aplikacje). Tak więc zabezpieczenie wsparcia dla procesów wymaga wyłącznie dostarczenie konkretnej wymaganej usługi aplikacyjnej. Jeżeli uznamy, że interfejsy są już standaryzowane a integracja w paradygmacie obiektowym to wymiana danych (transfer obiektów biznesowych poprzez interfejsy) a nie ich współdzielenie (współdzielone dane w bazach danych), to widać, że idea „dynamicznego udostępniania przy minimalnym udziale dostawcy” staje się realna. Miejsce fizycznego położenia aplikacji przestaje mieć znacznie (osobnego rozpatrzenia wymaga bezpieczeństwo danych), znaczenie ma wyłącznie dostęp do usługi. Tak zwana chmura nie musi być outsourcingiem. Tak zwane „chmury prywatne” to nic innego jak ta sama technologia wykorzystana lokalnie w organizacji.

Teraz widać, że idea systemu ERP jako zestawu usług aplikacyjnych jest nie tylko możliwa, jest bardzo efektywna biznesowo. Każda aplikacja może mieć własny cykl życia, ich integracja przestaje być nieosiągalnym kosztownym marzeniem. Decyzje o tym jakie i kiedy usługi aplikacyjne uruchomić, nie są ograniczone technologią czy licencją jednego dostawcy całości systemu. Można rezygnować z określonych usług na korzyć innych ich implementacji, można dodawać nowe, mogą to być aplikacje własne lub dzierżawione.

Tak wiec system ERP jako zintegrowany pakiet oprogramowania, w rozumieniu monolitu pochodzącego od jednego dostawcy, zmuszający do korzystania z ograniczonego zestawu usług aplikacyjnych (nawet bardzo bogatego), odchodzi powoli do lamusa. Nadchodzi era usług aplikacyjnych dobieranych na życzenie, gotowych, łatwych w uruchomieniu. W przypadku problemu z pozyskaniem usługi dopasowanej do naszych potrzeb, relatywnie łatwo można taką usługę (lub ich zestaw) zaprojektować i wykonać jako niewielki dedykowany element naszego systemu, bez ryzyka dla całości, co było i jest zmorą monolitycznych systemów ERP (ich kastomizacja).

Architektura korporacyjna nabiera nowego znaczenia: nie jest już tylko dokumentacją zasobów IT, staje się żyjącym modelem opisującym to, jak działa organizacja. Z jednej strony mamy model biznesowy z procesami biznesowymi z drugiej infrastrukturę IT. Całość łączy warstwa usług aplikacyjnych stanowiąca abstrakcję wykorzystywanej technologii IT. Biznes nie musi już zamawiać „nowej technologii”, zamawia usługi. To czy dostarczy jest zewnętrzny dostawca (chmura publiczna) czy będą to zasoby własne (chmura prywatna) traci znaczenie, istotna jest rentowność i funkcjonalność.

Autor: Jarosław Żeliński