Wyobraźmy sobie sytuację, kiedy gigantycznej wielkości przedsiębiorstwo przewozowe dysponuje tysiącami wagonów (choć równie dobrze mogłyby to być autobusy, tramwaje czy taksówki), które remontuje w kilku różnych firmach usługowych. Są nimi zarówno producenci wagonów (autobusów, tramwajów, taksówek), jak i firmy specjalizujące się wyłącznie w remontach. Kwestia kompletnego powiązania danych o stanie majątku w przedsiębiorstwie z wiedzą o remontach prowadzonych u usługodawców może okazać się w tym przypadku dość złożona.

PUNKT WIDZENIA REMONTOWEGO USŁUGODAWCY

Firma podejmująca się remontu wagonów z reguły wykorzystuje zapewne od wielu już lat własne oprogramowanie obsługi gospodarki remontowej. Prawdopodobnie stanowi ono fragment systemu ERP eksploatowanego w szerokim zakresie.

Dla firmy o tym charakterze pro-wadzenie usługowe remontów jest elementem produkcji. Firma z jednej strony prowadzi produkcję nowych wagonów, wytwarza części zamienne do nich, podzleca produkowanie różnych materiałów i podzespołów. Musi mieć więc dostęp do rozliczania remontów, połączenie z systemem CRM, umieć prowadzić kalkulacje opłacalności, no i oczywiście precyzyjnie kontrolować sam przebieg procesu remontowego, w tym zużycie materiałów czy koszty robocizny. Można powiedzieć, że usługodawca na potrzeby prowadzonych przez siebie remontów w swoim systemie ERP bardziej potrzebuje funkcji operacyjnych MRO (Maintenance, Repair and Operations) niż klasycz-nych narzędzi zarządzania majątkiem (CMMS; Computerised Maintenance Management Systems).

OPTYKA ZLECAJĄCEGO

Przedsiębiorstwo przewozowe reprezentuje nieco inny punkt widzenia niż producent czy firma serwisowa. Chce dysponować swoją indywidualną wiedzą na temat eksploatowanych wagonów. Ma ona w pierwszym rzędzie charakter ewidencji środków trwałych, a więc kosztów zakupów, amortyzacji, przeglądu wiedzy na temat częstotliwości i kosztów remontów. Wykorzystuje do tego celu albo funkcje CMMS/EAM, stanowiące być może fragment własnego, szerszego systemu ERP, albo też funkcje pochodzące z samodzielnego systemu stosowanego jedynie przez działy nadzoru i kontroli majątku przedsiębiorstwa. System ten nie musi koncentrować się tylko na wagonach, może też obsługiwać dane na temat innych składników majątku przedsię-biorstwa: budowli, oprzyrządowania, infrastruktury.

Wydaje się, że potencjał drzemiący w dwóch systemach gospodarki remontowej w opisanym przypadku nie będzie w pełni wykorzystany dopóty, dopóki nie zostaną one ze sobą połączone. Jeśli partnerów utrzymania taboru przedsiębiorstwa przewozowego jest wielu, to integracja wiedzy z różnych systemów, pochodzących od różnych usługodawców i na różnych poziomach agregacji wydaje się nie tylko możliwa, ale po prostu niezbędna.

Przy integrowaniu takich systemów należy podjąć szereg decyzji na temat mechanizmów tejże integracji. O ile dane o materiałach zużytych w trakcie napraw mogą być interesujące, o tyle informacja, która brygada na której zmianie likwidowała usterkę — już nieco mniej szczegółowa. Dane o poprzednich remontach zlecający powinien jednak w jakimś zakresie mieć w komplecie. Usługodawca dysponuje nimi nie zawsze: tylko wtedy, jeśli te remonty sam przeprowadzał.

PROBLEM OD STRONY INFORMATYKI

Jak zintegrować informację, którą dysponują tak różne podmioty, do tej pory przyzwyczajone do pracy na jednym systemie na potrzeby własne. Z technicznego punktu widzenia taki opis współpracy w stylu B2B wydaje się dość prosty. Załóżmy, że duże przedsiębiorstwo przewozowe dysponuje tylko jednym, w pełni zintegrowanym własnym systemem zarządzania majątkiem. Nazwijmy go systemem A. Powiedzmy, że przedsiębiorstwo to korzysta z usług kilku firm remontowych, z których każda używa innego systemu gospodarki remontowej. Dla uproszczenia wizji nazwijmy je literami B, C, D, E, F.

Każdy z wymienionych systemów A-F jest wyposażony w swoją konwencję danych: ich zakres, szczegółowość wreszcie strukturę. Usługodawcy stosujący swoje systemy gospodarki remontowej o nazwach B-F nie chcą zmieniać swoich struktur danych, ponieważ obsługują wielu różnych klientów. Podobnie przedsiębiorstwo przewozowe, samo raczej nie będzie chciało zmienić swojej struktury wiedzy, bo jego własna wypracowana przez wiele lat metodyka pozwala mu na w miarę efektywne za-rządzanie.

POGODZIĆ SPRZECZNE METODY

Kontakty B2B między wieloletnimi kontrahentami przy obecnych możliwościach informatyki nie powinny się opierać tylko na elektronicznej wymianie dokumentów zleceń, specyfikacji i protokołów zdawczo-odbiorczych. To, co łatwo mogą obecnie wprowadzić usługodawcy stosujący systemy B-F, to zdalne udostępnienie terminali swoich poszczególnych systemów gospodarki remontowej dla klienta stosującego system A. W ten sposób klient na sześciu ekranach (kolejno z systemami A-F) dysponowałby pełną informacją o swoim majątku i o wszystkich remontach w toku, które są lub były prowadzone. Szkopuł w tym, że przewoźnik takiego udogodnienia nie chciałby. Nie byłoby to dla niego rozwiązanie zanadto wygodne. Uważa on bowiem, że system A jest najlepszy w realizacji jego potrzeb, ponieważ scala w jednym miejscu wszystkie potrzebne mu informacje.

Zlecający remonty przewoźnik jest zainteresowany możliwie szczegółową i bieżącą informacją dostępną w jednym miejscu, o całości majątku trwałego, któ-rym dysponuje. Liczba remontowanych wagonów czy pociągów, nawet jeśli stanowiłaby 5% całego majątku przewoźnika to kwota na tyle duża, że warto mieć na bieżąco dostęp do informacji na ich temat. Celem, do którego zapewne dążyłby zlecający, jest wprowadzenie do jego systemu A wszystkich danych, jakie są generowane przez systemy B-F. Systemy B-F pracują jednak w sposób dalece niejednolity. Można założyć, że na potrzeby jednego kontrahenta, nawet znaczącego, usługodawcy nie chcieliby zbyt głęboko przebudowywać struktury swoich funkcji MRO. Z punktu widzenia standaryzacji kontaktów aplikacji A z pozostałymi, należałoby więc przede wszystkim przeprowadzić ewidencję i analizę struktur danych udostępnianych przez systemy z grupy B-F, a następnie dokonać wyboru, które z tych danych będą rzeczywiście potrzebne dla użytkownika A.

Minimalistyczny wariant to akceptacja części wspólnej zbioru danych oferowanych przez aplikacje B-F. Jeśli natomiast zlecający jest zainteresowany wszystkimi dostępnymi danymi, to może się zdecydować na wariant maksymalistyczny. Wtedy dane wprowadzane do A stałyby się teoriomno-gościową sumą danych pochodzących z systemów B-F. Istnieje oczywiście też całe spektrum wariantów pośrednich. To wymagałoby analizy potrzeb, po której należy podjąć mnóstwo szczegółowych decyzji; leżą one w gestii użytkowników systemu A. Prostsze reguły integracji wiedzy z różnych systemów będą zapewne także tańsze we wdrożeniu niż reguły zanadto wyrafinowane.

TECHNIKA INTEGRACJI

Integracja aplikacji zarządzania majątkiem przewoźnika A z aplikacjami remontowymi usługodawców B-F oparłaby się zapewne na wzorcach SOA (Service Oriented Architecture). Najbardziej przejrzyście można budowę integracji stworzyć na bazie specyfikacji XML. Nie zawsze jest to jednak wykonalne — wszystko zależy od specyfiki poszczególnych systemów gospodarki remontowej.

Jeśli systemem A byłoby oprogramowanie IFS Applications, to najpewniej do integracji danych użyto by platformy IFS Enterprise Operational Intelligence (IFS EOI). Jeśli IFS Applications byłby używany jako system gospodarki remontowej B-F, zapewne narzędzia integracji mogłyby być inne, zawsze optymalnie dostosowane do wymogów aplikacji A. Również rozwiązanie IFS EOI może być w tym przypadku rozpa-trywane jako jeden z wariantów imple-mentacyjnych.

Wydaje się też, że marzenia o integracji wszystkiego ze wszystkim powinny być raczej ograniczone do niezbędnego minimum (czyli części wspólnej danych). To tańsze, szybsze, a przez to najbardziej pragmatyczne. Potrzebne pozostaje tylko otwarcie furtek na ewentualnie bardziej wyrafinowaną integrację w przyszłości. Apetyt na integrację może bowiem wzrastać w miarę nabierania doświadczeń przez użytkowników.

Źródło: www.ifsworld.com