Biznes chce kolejnego procesu. Czy naprawdę potrzebujesz przez to kolejnego systemowego silosu?
Magazyn chce WMS. Utrzymanie ruchu chce CMMS. Operacja chce ewidencji sprzętu. Sprzedaż chce CRM. Każdy problem może być realny — ale dla IT oznacza też dane, integracje, użytkowników, uprawnienia, utrzymanie i kolejny system, który ktoś będzie musiał wspierać.
Remanently pozwala uruchamiać konkretne procesy operacyjne bez przebudowywania całego ERP. Celem nie jest zastąpienie systemów, które już działają, ale obsłużenie tych procesów, których implementacja w obecnym środowisku byłaby zbyt kosztowna, zbyt długa albo niewygodna dla użytkowników.
Łatwe w zarządzaniu
3x bardziej efektywne operacje
Które z tych zdań słyszysz najczęściej, kiedy biznes przychodzi do IT z nowym problemem?
Problem biznesowy może być prosty. Techniczne konsekwencje jego rozwiązania już nie zawsze.
Proces istnieje w systemie głównym albo dałoby się go tam zbudować, ale koszt, czas lub wygoda obsługi powodują, że biznes szuka innej drogi.
Na początku działa. Później powstają kolejne wersje plików, ręczne przepisywanie danych i wiedza, której nie da się łatwo kontrolować.
Każda nowa aplikacja może rozwiązać lokalny problem i jednocześnie stworzyć kolejny silos danych, użytkowników i integracji.
Samo połączenie dwóch systemów nie odpowiada jeszcze na pytania o właściciela danych, kierunek synchronizacji, błędy i utrzymanie integracji.
Presja na szybkie wdrożenie nie znika po uruchomieniu. IT zostaje później z architekturą, dostępami, monitoringiem i odpowiedzialnością za ciągłość działania.
Ten sam klient, produkt, zasób albo lokalizacja zaczynają żyć w kilku systemach bez jednoznacznej odpowiedzi, które źródło jest nadrzędne.
Nie chodzi o to, żeby blokować kolejny system. Chodzi o to, żeby nie kupić sobie kolejnego długu technologicznego.
CIO/CTO nie odpowiada tylko za uruchomienie rozwiązania. Odpowiada również za to, co będzie z nim za rok, przy kolejnej integracji, zmianie ERP albo odejściu osoby, która „wiedziała jak to działa”.
Nowa aplikacja zaczyna przechowywać własną kopię danych, ale nie wiadomo jasno, które źródło jest nadrzędne.
Proces formalnie jest cyfrowy, ale człowiek nadal kopiuje dane z ERP, maila albo Excela do drugiego systemu.
Każdy kolejny system dostaje własne połączenie i z czasem zmiana jednego procesu zaczyna wpływać na kilka innych.
Kolejna aplikacja oznacza kolejne role, użytkowników i odpowiedzialność za dostęp.
Po wdrożeniu ktoś musi wiedzieć, co zrobić, kiedy proces, użytkownik albo integracja przestaje działać.
Im więcej logiki biznesowej zostaje zaszyte w jednym rozwiązaniu bez jasnego sposobu wymiany danych, tym trudniejsza staje się późniejsza zmiana.
Najpierw ustal: gdzie kończy się ERP, a gdzie zaczyna proces operacyjny?
Nie każda czynność wykonywana przez pracownika musi zostać rozbudowana bezpośrednio w ERP. Ale nie oznacza to również, że nowy system powinien przejąć dane i odpowiedzialności, które już mają swoje miejsce.
Dane finansowe, księgowe i inne informacje pozostające rdzeniem obecnego środowiska nie muszą być przenoszone do Remanently tylko dlatego, że proces operacyjny korzysta z ich kontekstu.
Remanently może obsługiwać konkretną operację wykonywaną przez użytkownika tam, gdzie proces w ERP byłby zbyt trudny, kosztowny lub niewygodny do zmiany.
Nie każda informacja musi być kopiowana w obie strony. Integracja powinna wynikać z odpowiedzialności za dane i rzeczywistego procesu.
Przed integracją trzeba ustalić, który system jest źródłem dla klienta, produktu, zasobu, magazynu albo innych danych współdzielonych.
„Mamy już ERP. Dlaczego nie zrobić tego po prostu tam?”
Jeżeli istniejący ERP obsługuje proces dobrze, nie ma powodu go zastępować.
Problem pojawia się wtedy, kiedy zmiana wymaga:
- kosztownego developmentu,
- długiego projektu,
- rozbudowy interfejsu niewygodnego dla użytkowników operacyjnych,
- wielu obejść,
- albo procesu, który i tak kończy się w Excelu, mailu lub na papierze.
Remanently nie musi zastępować ERP. Może działać jako warstwa operacyjna dla wybranego procesu i wymieniać z systemem głównym tylko te dane, których rzeczywiście potrzebuje.
Integracja nie zaczyna się od pytania „czy macie API?”. Zaczyna się od pytania „który system jest właścicielem danych?”.
Dobre połączenie systemów powinno mieć jasno określony cel, kierunek przepływu i odpowiedzialność za dane.
Ustal, skąd pochodzą klienci, produkty, pracownicy, zasoby, lokalizacje i inne dane potrzebne w procesie.
Ustal, które zdarzenia powstają w Remanently i które z nich powinny wrócić do innych systemów.
Nie zakładaj automatycznie synchronizacji wszystkiego w obie strony.
Integracja musi uwzględniać sytuację, w której dane nie mogą zostać przyjęte albo jedno ze źródeł jest chwilowo niedostępne.
Powiązanie rekordów pomiędzy systemami powinno być jednoznaczne i możliwe do utrzymania.
Integracja powinna dać się rozwijać bez przepisywania całego procesu przy każdej zmianie środowiska.
API jest ważne. Ale samo API nie jest jeszcze architekturą integracji.
Przed wykorzystaniem interfejsu trzeba wiedzieć, jakie dane są dostępne, które operacje mają być wykonywane, kto inicjuje wymianę i co dzieje się w przypadku błędu.
Najdroższa integracja to taka, w której po uruchomieniu nadal nie wiadomo, który system ma rację.
Techniczne połączenie danych nie rozwiązuje problemu ich odpowiedzialności.
Jeżeli produkt istnieje w ERP, trzeba jasno ustalić, czy Remanently korzysta z tego indeksu, czy może tworzyć własny.
Dane klienta nie powinny być utrzymywane niezależnie w kilku miejscach bez powodu.
Proces może potrzebować informacji o użytkowniku, ale zakres i źródło danych powinny wynikać z konkretnej operacji.
Trzeba ustalić, czy konkretny zasób jest zakładany w Remanently, ERP czy innym systemie i jak rekordy są ze sobą powiązane.
Struktura lokalizacji powinna być spójna z fizycznym procesem, a nie tylko wygodna dla jednej aplikacji.
Dane operacyjne powinny pozostać możliwe do odtworzenia również po zmianach w strukturze organizacyjnej lub systemowej.
Architektura może być poprawna, a wdrożenie nadal nie działać, jeśli użytkownik nie chce z niego korzystać.
System dla hali, magazynu albo technika powinien być oceniany również przez pryzmat liczby kroków potrzebnych do wykonania rzeczywistej operacji.
W wielu procesach użytkownik może pracować bezpośrednio tam, gdzie odbywa się operacja.
Jeżeli proces wymaga urządzenia przemysłowego, interfejs powinien wspierać sposób jego rzeczywistego użycia.
Identyfikacja może ograniczyć ręczne wyszukiwanie i przepisywanie danych.
Może mieć sens tam, gdzie skala procesu uzasadnia identyfikację wielu oznaczonych zasobów bez skanowania każdego osobno.
Bezpieczeństwo nie może być listą skrótów na landing page.
CIO/CTO potrzebuje konkretnych odpowiedzi dotyczących danych, dostępów, środowiska i odpowiedzialności.
Kto może zobaczyć, utworzyć albo zmienić konkretny rodzaj informacji?
Jak użytkownik jest uwierzytelniany i jak zarządzany jest jego dostęp?
Gdzie znajdują się dane i jakie mechanizmy ochrony są stosowane?
Czy istotne operacje pozwalają odtworzyć, kto i kiedy wykonał działanie?
Jak wygląda odpowiedzialność za kopie i odtworzenie środowiska?
Co dzieje się, jeżeli wystąpi problem wpływający na bezpieczeństwo lub dostępność?
System, który działa dla jednego procesu, powinien dać się rozszerzyć bez budowania wszystkiego od początku.
Remanently jest modułowe. Można rozpocząć od wybranego procesu i rozszerzać zakres wtedy, gdy pojawia się kolejna potrzeba operacyjna.
Rozwiązujesz konkretny problem bez wdrażania wszystkich obszarów.
Kolejny proces może korzystać z informacji, które już istnieją w rozwiązaniu.
Rozszerzenie organizacji nie powinno wymagać tworzenia całkowicie osobnego środowiska tylko dlatego, że proces działa w innym miejscu.
Nowa potrzeba może zostać dołączona jako kolejny moduł zamiast kolejnej niezależnej aplikacji.
Najlepszy argument architektoniczny pojawia się wtedy, gdy drugi problem nie wymaga drugiej osobnej platformy.
Jeżeli te same zasoby, produkty, lokalizacje albo użytkownicy uczestniczą w kilku procesach, wspólna platforma może ograniczyć liczbę niezależnych aplikacji i połączeń.
Wiesz, gdzie jest urządzenie. A czy jego historia techniczna musi żyć w drugim niezależnym systemie?
Asset Management odpowiada na pytania o zasób, lokalizację i odpowiedzialność. CMMS rozszerza ten sam kontekst o zgłoszenia, przeglądy i działania techniczne.
Maszyna wymaga części. Czy do tego procesu potrzebujesz jeszcze trzeciego ręcznego połączenia między systemami?
CMMS przechowuje kontekst techniczny urządzenia. WMS odpowiada za fizyczny proces magazynowy i dostępność części. Te procesy naturalnie spotykają się podczas realizacji naprawy.
Ewidencja mówi, że firma posiada sprzęt. Drugi proces odpowiada: kto właśnie z niego korzysta?
Asset Management przechowuje kontekst zasobu. Tools dodaje zapotrzebowania, rezerwacje, wydania i zwroty sprzętu.
Dane klienta też nie muszą kończyć się na jeszcze jednej niezależnej aplikacji.
CRM wykorzystuje informacje o kliencie, spotkaniach i historii zakupów. Trade Marketing rozszerza proces o promocje, bonusy, budżety i warunki handlowe.
Jeden nowy proces nie musi oznaczać jednej nowej wyspy systemowej.
Możesz zacząć od pojedynczego modułu. Jeżeli później pojawia się kolejny powiązany proces, warto sprawdzić, czy może korzystać z tej samej platformy i danych zamiast tworzyć następny osobny system.
Zasób i jego historia techniczna.
Urządzenie, działanie techniczne i części.
Majątek oraz jego wydanie użytkownikowi.
Klient, potencjał sprzedaży oraz koszt warunków handlowych.
„Nie chcę, żeby kolejny proces był zakładnikiem jednego dostawcy.”
To właściwe pytanie. Przed wdrożeniem trzeba wiedzieć, jakie dane znajdują się w rozwiązaniu, które z nich pochodzą z innych systemów, jak są identyfikowane i w jaki sposób można je wymieniać.
Które dane są własnością procesu i gdzie znajduje się ich źródło?
Czy wymiana danych ma jasno określony interfejs i odpowiedzialność?
Czy istotne dane procesu można pozyskać w sposób potrzebny organizacji?
Czy sposób integracji i model danych są wystarczająco opisane, aby nie zależeć wyłącznie od wiedzy jednej osoby?
„Wdrożenie trwa chwilę. Utrzymanie zostaje na lata.”
Przed decyzją warto jasno ustalić odpowiedzialność za użytkowników, konfigurację, integracje, aktualizacje i obsługę incydentów.
Kto odpowiada za reguły i konfigurację procesu?
Za jakie elementy środowiska i integracji odpowiada wewnętrzny zespół?
Za jakie elementy aplikacji odpowiada Remanently?
Jak wygląda proces wprowadzenia późniejszej zmiany bez rozbijania istniejącego rozwiązania?
Najbezpieczniejszy pierwszy krok może być również najmniejszy.
Nie musisz od razu integrować wszystkich procesów, systemów i lokalizacji. Możesz uruchomić konkretny zakres, sprawdzić go w rzeczywistej pracy, a dopiero potem rozszerzyć rozwiązanie.
Zacznij od problemu biznesowego, który ma jasno określony zakres.
Określ, jakie informacje proces naprawdę potrzebuje z istniejących systemów.
Zdecyduj, za które dane i operacje odpowiada Remanently, a za które system główny.
Nie buduj integracji szerszej niż proces, który ma obsłużyć.
Co możemy powiedzieć bez zgadywania?
Jaki problem biznes chce dziś rozwiązać — i które systemy naprawdę muszą w tym uczestniczyć?
Jeżeli odpowiemy na te dwa pytania, można dopiero sensownie rozmawiać o danych, integracjach i architekturze.