POPC Wsparcie

To kolejny artykuł z cyklu poświęconego architekturze systemów IT w kontekście wymiany danych między aplikacjami. Poszukamy w nim odpowiedzi na pytanie: Czy lepiej jest wdrożyć system zintegrowany, czy też może kilka systemów dziedzinowych i zapewnić wymianę danych między tymi systemami? By odpowiedzieć na tak postawione pytanie, najpierw zastanówmy się, jakie są zalety i wady każdego z rozwiązań.

Co to jest system zintegrowany?

System zintegrowany to rodzaj oprogramowania, w którym jedna aplikacja obsługuje wszystkie procesy (lub ich znaczącą większość) realizowane w jednostce publicznej.

 

Wiele dużych przedsiębiorstw komercyjnych stosuje z powodzeniem rozwiązania (systemy) zintegrowane. Takie rozwiązania nazywamy systemami ERP (ang. enterprise resource planning, planowanie zasobów przedsiębiorstwa).

 

Przykładami takich rozwiązań jest oprogramowanie SAP i Dynamics. Ich dostępne wersje komercyjne są przygotowane właśnie do obsługi przedsiębiorstw.

A co z jednostkami publicznymi?
Specyfika funkcjonowania jednostek publicznych sprawia, że nie możemy tych systemów wdrożyć bez dodania dużych części, które musi opracować integrator wdrażający system.
Chodzi tu przede wszystkim:

• o obszar planowania budżetu lub sprawozdawczości budżetowej,
• o cały obszar podatków i opłat,
• o specyficzne obszary dziedzinowe obsługiwane przez poszczególne resorty, urzędy czy inne instytucje.

Przedsiębiorstwa komercyjne nie realizują tego typu zadań. Dlatego producenci systemów ERP nie są zainteresowani tworzeniem modułów, które pozwalają obsługiwać tego typu procesy. Ma to duży wpływ na wdrożenie systemu ERP i jego dalsze funkcjonowanie w podmiotach, które realizują zadania publiczne. Tym zagadnieniem zajmiemy się za chwilę. Najpierw ustalmy, jakie zalety ma wdrożenie systemu zintegrowanego.

 

Zalety wdrożenia systemu ERP

1. Dane dotyczące praktycznie wszystkich procesów realizowanych w jednostce zgromadzone w jednym miejscu
   To umożliwia łatwiejszą optymalizację procesów. Pozwala też wdrożyć zasadę, że daną informację wprowadzamy tylko raz do systemu. Ponieważ mamy wszystkie dane w jednym miejscu, możemy je wielowymiarowo analizować.
2. Wspólne słowniki
   To umożliwia standaryzację nazewnictwa kategorii danych i samą analizę danych. Przykładem może być słownik dostawców i odbiorców usług, który jest wspólny dla wszystkich procesów. Raz wprowadzony odbiorca, na przykład mieszkaniec płacący podatek, jest tak samo identyfikowany zarówno w księgach pomocniczych, jak i na przykład w procesie windykacji. Dlatego możemy łatwo stwierdzić i wyszukać wszystkie należności danego mieszkańca oraz udostępnić mu usługi online, które pozwolą rozliczyć te zobowiązania.
3. Wymiana danych między obszarami merytorycznymi
   To umożliwia na przykład przekazanie listy płac z obszaru kadrowo-płacowego do księgowości. Już nie musimy ręcznie przepisywać danych z odrębnych systemów ani integrować tych systemów. Dzięki wymianie danych unikamy integracji systemów wewnętrznych.
4. Kompleksowe wdrożenie systemu bezpieczeństwa danych
   Rozwiązania dotyczą jednego systemu i oddziałują na wszystkie dane. To duża standaryzacja systemu bezpieczeństwa.

 

Wady wdrożenia systemu ERP

1. Wysokie koszty
   Dotyczą zarówno ceny takiego systemu, jak i jego późniejszego utrzymania po wdrożeniu.
2. Konieczność zaangażowania specjalistów
   Wdrożenie systemu w jednostce wymaga stworzenia zespołu w organizacji. Zespół powinien składać się z osób z poszczególnych obszarów merytorycznych objętych systemem, a także z osób z zespołu IT. We wdrożeniu kluczową rolę odgrywają przedstawiciele obszarów merytorycznych. To wbrew powszechnej opinii, że wdrożenie systemu IT to zadanie zespołu IT.
3. Ograniczona liczba dostawców
   Na rynku nie ma zbyt wielu firm, które mogą dostarczyć, zmodyfikować i wdrożyć taki system (zupełnie inaczej jest, gdy mówimy o dostawcach systemów dla konkretnych obszarów merytorycznych). Mniejsza konkurencja oznacza, że możemy mieć trudności w wyborze dostawcy, szczególnie że musimy pamiętać o wymogach prawa zamówień publicznych. Przekłada się to też na cenę rozwiązania.
4. Mniejsza elastyczność w dostosowaniu do potrzeb zamawiającego
   W tym wypadku również przewaga jest po stronie systemów przeznaczonych dla konkretnych obszarów merytorycznych. Możemy je zmodyfikować zdecydowanie łatwiej.
5. Brak gotowych rozwiązań ERP
   Jako jednostka publiczna obsługujemy specyficzne procesy, takie jak plan budżetu czy też podatki i opłaty. Czołowi dostawcy rozwiązań klasy ERP (tacy jak SAP, Oracle czy Microsoft) nie oferują takich rozwiązań. Przygotowują standardowe produkty na potrzeby dużych firm komercyjnych, często przedsiębiorstw produkcyjnych. Dlatego jednostka publiczna często nie jest w stanie wdrożyć u siebie ich systemu ERP bez dużych modernizacji. Oczywiście obszary takie jak zakupy, magazyn czy księga główna i księgi pomocnicze możemy wykorzystać niemalże w standardzie oferowanym przez producenta. Wystarczy tylko parametryzacja takich modułów. Niestety pozostałe obszary integrator, który dostarcza system, musi „dopisać”. Właśnie ta konieczność dostosowania i tak już drogiego systemu zaburza konkurencyjność. W efekcie po wdrożeniu takiego systemu praktycznie tylko dostawca zamówienia jest w stanie świadczyć usługi utrzymaniowe. To przekłada się na relacje z nim oraz koszty utrzymania. 

 

Czy warto?

Poprawnie wdrożony system zintegrowany to korzyści, ale też koszty, jakie poniesiemy w przyszłości na utrzymanie takiego systemu. Musimy też pamiętać o tym, że kiedyś będziemy musieli go wymienić albo co najmniej znacząco zmodernizować. W tej chwili nie możemy oprzeć się na doświadczeniach innych jednostek, ponieważ żadna z nich jeszcze nie przeprowadziła tego typu zmiany (nikt nie wymieniał jednego systemu zintegrowanego na drugi system zintegrowany). W chwili pisania tego artykułu właśnie kończy się taka wymiana w Łodzi, a we Wrocławiu trwają przygotowania do niej, właśnie z powodów wysokich kosztów utrzymania i małej elastyczności dotychczasowego systemu.

 

Co to są aplikacje rozproszone?

Zupełnie innym modelem architektury, jaki możemy wdrożyć w organizacji, jest model aplikacji rozproszonych.

W aplikacjach rozproszonych dla poszczególnych obszarów merytorycznych wdrażamy przeznaczone dla nich systemy dziedzinowe, takie jak: księgowość z gospodarką magazynową,  podatki i opłaty,  budżetowanie i sprawozdawczość,  windykacja, gospodarowanie mieniem.  Każdy taki system może pochodzić od innego dostawcy i może być wdrażany niezależnie.

Podobnie jak system zintegrowany – także model rozproszony ma swoje wady i zalety.

 

Zalety wdrożenia modelu rozproszonego

1. Możliwość zakupu mniejszych aplikacji dziedzinowych
   To powoduje, że koszt wdrożenia wszystkich aplikacji do obsługi wszystkich procesów realizowanych w jednostce publicznej możemy rozłożyć na kilka lat. Dzięki temu możemy w każdym roku zaplanować budżet adekwatny do możliwości finansowych naszej jednostki.
2. Najpopularniejsze aplikacje dziedzinowe dostępne jako gotowe produkty – sprzedawane z półki
   Producent takiego oprogramowania często oferuje te same rozwiązania zarówno podmiotom publicznym, jaki i firmom komercyjnym. Dla nas to oznacza korzyści. Dlaczego? Producent rozwiązań często we własnym zakresie i z własnej inicjatywy rozwija swoje rozwiązania, bo w ten sposób zachęca przedsiębiorców do współpracy. Przede wszystkim dostosowuje oprogramowanie do zmian przepisów prawa. W ten sposób zyskujemy też my – w innych modelach często jednostki publiczne muszą osobno płacić (jak za prace dodatkowe) za zmiany w aplikacji wynikające ze zmiany prawa.
3. Niższy koszt utrzymania systemu dziedzinowego
   Ten koszt jest niższy niż w systemie zintegrowanym. Producenci oprogramowania mają wielu klientów kupujących ten sam produkt. Dlatego koszty utrzymania zespołu programistów tworzących produkt dzielą na większą grupę jego odbiorców. Systemy przeznaczone dla danej jednostki i systemy, który choć są potencjalnie standardowe, to nie mają wielu klientów, często przenoszą całe koszty utrzymania zespołu wsparcia tylko na jednego klienta.
4. Wymiana modułu zamiast systemu
   Jeśli zajdzie potrzeba wymiany danej aplikacji dziedzinowej, na przykład gdy producent oprogramowania zakończy działalność, wystarczy wymienić ten jeden moduł. Nie musimy wtedy wymieniać całego systemu w całej organizacji.
5. Niewielki zespół wdrożeniowy
   Zespół wdrożeniowy w organizacji może być niewielki. Czasami nawet wystarczy, że składa się z przedstawicieli merytorycznych jednej komórki organizacyjnej oraz zespołu IT.

 

Wady wdrożenia modelu rozproszonego:

1. Niekończący się proces wdrażania aplikacji
   Wdrażanie małych aplikacji dla poszczególnych obszarów procesów funkcjonujących w organizacji często jest rozciągnięte w czasie. A to sprawia, że dopiero po wielu latach będziemy w pełni obsługiwać wszystkie procesy. Często też zdarza się, że zanim kompleksowo wdrożymy wszystkie zaplanowane aplikacje, musimy już wymienić którąś wcześniej wdrożoną. W efekcie proces wdrażania aplikacji nigdy się nie kończy.
2. Braku ustandaryzowania słowników
   Często architektura wewnętrzna poszczególnych aplikacji sprawia, że nie możemy ustandaryzować wszystkich słowników. Co to może spowodować? Na przykład ten sam kontrahent nie będzie tak samo oznaczony we wszystkich systemach.
3. Trudniejsza analiza zarządcza
   Mówimy tu zwłaszcza o wykonaniu analizy zarządczej na poziomie całej organizacji.
4. Konieczność wymiany danych
   Nie chcemy, by różne osoby, na przykład kontrahenci, po kilka razy wprowadzały te same dane. Dlatego musimy zaplanować i stworzyć system wymiany danych między aplikacjami. Architekturę wymiany danych musi zaplanować i opisać nasz zespół – zespół funkcjonujący bezpośrednio w organizacji, czyli SOA Governance. Wyniki analizy architektury wymiany danych staną się podstawą wymagań dla systemów dziedzinowych. Dzięki temu każdy system będzie potrafił eksportować dane potrzebne do pracy w innych systemach oraz importować takie dane z pozostałych aplikacji. Wykonanie samego mechanizmu wymiany danych zgodnie z zaplanowaną wcześniej architekturą to odrębne zadanie jednostki publicznej. Właśnie konieczność wykonania we własnym zakresie takiej architektury wymiany danych jest najsłabszym ogniwem całego rozwiązania. W praktyce, poza nielicznymi przypadkami, jednostki publiczne nie mają zespołów odpowiedzialnych za tworzenie architektury wymiany danych. W efekcie wymiana danych między systemami odbywa się wyłącznie w zakresie przewidzianym przez twórcę aplikacji. Niestety najczęściej dane przenoszą pracownicy jednostki, którzy po prostu wprowadzają informacje z dokumentów papierowych.

 

Jaki model wybrać?

Niezależnie od tego, jaki model wybierzemy, coraz ważniejsza jest integracja z systemami referencyjnym, szczególnie na szczeblu rządowym.

 

Takimi systemami referencyjnymi są:

• REGON – Krajowy Rejestr Urzędowy Podmiotów Gospodarki Narodowej,
• CEIDG – Centralna Ewidencja i Informacja o Działalności Gospodarczej,
• eDeklaracje – system, który pozwala podmiotom gospodarczym przesłać elektronicznie deklaracje podatkowe.

Niektóre z tych integracji weryfikują poprawność danych w systemie, na przykład REGON. Inne pozwalają elektronicznie przekazywać wymagane prawem informacje (zamiast tradycyjnie – w formie papierowego dokumentu), jak na przykład eDeklaracje. Niektórzy producenci systemów dziedzinowych oferują tego typu funkcjonalności w ramach ceny za oprogramowanie.

Nieco inaczej to wygląda w systemach klasy ERP. W nich takie integracje nie są dostępne z pudełka. Powstają w ramach dostosowywania systemu do potrzeb zamawiającego.

Z punktu widzenia tworzenia architektury wymiany danych nawet w systemie zintegrowanym (czyli tam, gdzie wymiana danych między obszarami merytorycznymi jest automatyczna) musimy pamiętać o integracji z systemami zewnętrznymi. Dlatego musimy powołać zespół odpowiedzialny za stworzenie i utrzymanie modelu wymiany danych. Pamiętajmy, że jego prawidłowe funkcjonowanie dostrzeżemy dopiero po dłuższym czasie. Brak takiego zespołu na początku nie będzie dostrzegalny. Ale z każdym rokiem będzie coraz bardziej uciążliwy – w miarę wzrostu relacji między poszczególnymi systemami IT wewnątrz organizacji oraz z systemami zewnętrznymi.

 

Wróćmy do pytania z początku artykułu: Który model jest lepszy – architektura systemu IT opartego na systemie zintegrowanym czy architektura aplikacji rozproszonych?
Nie ma jednoznacznej odpowiedzi na to pytanie, bo model optymalny, model dla każdego nie istnieje. Każdy podmiot publiczny sam musi odpowiedzieć na to pytanie. Musimy przy tym uwzględnić wszystkie aspekty, takie jak: zasoby finansowe, możliwości organizacyjne czy też rozwój cyfrowy naszej organizacji. Musimy też pamiętać, że z każdym rokiem zespoły odpowiedzialne za model wymiany danych będą nam coraz bardziej potrzebne. Im większa organizacja – tym szybciej.

W praktyce często występuje model mieszany. Jednostki publiczne kupują jeden system, który obejmuje na przykład księgowość, magazyn, środki trwałe, kadry i płace – jako system zintegrowany. A do obsługi pozostałych obszarów używają przeznaczonych do tego aplikacji dziedzinowych.

 

Autor: Wojciech Ciesielski

 

Artykuły powiązane: