Zamówienie pojawia się w sklepie internetowym, ale ktoś musi jeszcze wpisać je do drugiego systemu, sprawdzić dane klienta i wysłać wiadomość do osoby odpowiedzialnej za realizację. Każda z tych czynności może być prosta. Gdy powtarza się codziennie, zaczyna zajmować czas i utrudniać ustalenie, które informacje są aktualne.
Integracja może połączyć te kroki, ale samo przesyłanie danych nie wystarczy. Trzeba ustalić, co ma się wydarzyć, gdzie przechowywana jest właściwa wersja informacji i jak firma dowie się o błędzie. Poniżej pokazuję, jak podejść do takiego zadania bez rozpoczynania od wymiany wszystkich narzędzi.
Kiedy warto połączyć systemy
Dobrym sygnałem jest sytuacja, w której pracownicy regularnie przenoszą te same informacje: dane kontrahenta, pozycje zamówienia, status zlecenia lub numer dokumentu. Warto przyjrzeć się również przypadkom, gdy dwa działy mają różne wersje danych albo muszą pytać się nawzajem o aktualny stan sprawy.
Zanim powstanie nowa integracja, sprawdź funkcje obecnych narzędzi. Być może dostawca oferuje już odpowiednie połączenie, import pliku lub ustawienie, którego dotąd nie używaliście. Przy sporadycznej czynności uporządkowany eksport i import może być wystarczający. Własne rozwiązanie warto rozważyć, kiedy gotowa funkcja nie obsługuje potrzebnych danych, reguł lub wyjątków.
Nie trzeba też automatyzować całego procesu. Jeżeli problemem jest przenoszenie zamówień, pierwszy etap może dotyczyć właśnie tego kroku. Automatyczne fakturowanie, aktualizacja stanów magazynowych i komunikacja z klientem mogą wymagać osobnych ustaleń i testów.
Przykład: ze sklepu do obsługi zamówienia
Wyobraźmy sobie firmę handlową, która sprzedaje przez sklep internetowy, a realizacją zajmuje się w osobnej aplikacji.
Po złożeniu zamówienia sklep udostępnia jego dane. Integracja sprawdza wymagane pola, zapisuje powiązanie numerów zamówienia w obu systemach i tworzy sprawę w aplikacji do obsługi. Pracownik otrzymuje informację, że zamówienie czeka na weryfikację. Jeśli brakuje adresu dostawy, sprawa trafia do wyjaśnienia zamiast przechodzić dalej z niepełnymi danymi.
Na tym etapie pracownik nadal podejmuje decyzję o realizacji. Automatyzujemy przekazanie informacji, a nie każdą decyzję biznesową. Dzięki temu można sprawdzić działanie połączenia na ograniczonym zakresie, zanim dostanie ono uprawnienia do wykonywania kolejnych operacji.
Co ustalić przed rozpoczęciem
Najpierw opisz drogę jednej sprawy od początku do końca. Kto wprowadza dane? Kto je poprawia? Który dział potrzebuje informacji i w jakim momencie? Do rozmowy przydają się przykładowe zamówienia bez rzeczywistych danych klientów oraz lista używanych aplikacji.
Źródło informacji. Ustal, który system odpowiada za konkretne dane. Sklep może przechowywać zamówienie klienta, a aplikacja wewnętrzna jego status realizacji. Nie oznacza to, że obie aplikacje powinny móc dowolnie zmieniać każde pole. Trzeba również określić, co dzieje się po ręcznej poprawce.
Kierunek i częstotliwość przesyłania. Czy dane płyną w jedną stronę, czy w obie? Czy muszą pojawić się od razu, czy wystarczy synchronizacja w ustalonych odstępach? Połączenie dwukierunkowe wymaga dodatkowych reguł rozstrzygania konfliktów; nie warto dodawać go bez konkretnej potrzeby.
Identyfikatory i znaczenie pól. Ten sam produkt lub kontrahent może mieć różne numery w różnych narzędziach. Nazwa firmy zwykle nie wystarcza do rozpoznania rekordu. Trzeba ustalić powiązania identyfikatorów, formaty dat, jednostki i znaczenie statusów, zanim informacje zaczną krążyć automatycznie.
Dostęp do systemów. API to interfejs, przez który aplikacje mogą wymieniać dane. Dokumentacja dostawcy pozwala sprawdzić dostępne operacje, limity i sposób uwierzytelniania. Nie każde API udostępnia wszystkie funkcje widoczne w panelu użytkownika. Warto zweryfikować również opłaty oraz dostępność środowiska testowego.
Uprawnienia. Integracja powinna otrzymać dostęp potrzebny do uzgodnionego zadania. Ustal, kto zarządza jej kontem, gdzie przechowywane są dane dostępowe i jak zostaną zmienione lub odebrane. Dane klientów nie powinny trafiać do rejestru błędów bez uzasadnionej potrzeby.
Co zrobić, gdy coś pójdzie nie tak
Najważniejsze pytanie brzmi: czy firma zauważy, że część zamówień nie dotarła? Sam brak komunikatu o błędzie nie potwierdza, że wszystko zostało poprawnie przetworzone. Potrzebny jest sposób sprawdzenia, które operacje zakończyły się powodzeniem, a które wymagają interwencji.
Powtórzone zamówienie lub komunikat
System może wysłać tę samą informację ponownie. Przykładowo dokumentacja Stripe opisuje możliwość wielokrotnego dostarczenia zdarzenia i zaleca rozpoznawanie duplikatów. Integracja nie powinna z tego powodu utworzyć drugiego zamówienia. Sposób rozpoznawania powtórzeń trzeba dopasować do konkretnej operacji i możliwości aplikacji.
Brakujące lub niepoprawne dane
Ponowne wysłanie zamówienia bez wymaganego pola nie naprawi jego zawartości. Taka sprawa powinna otrzymać czytelny powód zatrzymania i trafić do właściwej osoby. Po poprawce potrzebna jest możliwość bezpiecznego wznowienia obsługi bez ręcznego odtwarzania całego zamówienia.
Niedostępna aplikacja
Przy chwilowej awarii można zaplanować ponowienie próby. Odstępy, limit prób i warunki zatrzymania dobiera się do dostawcy i rodzaju błędu. Nie każdy błąd jest przejściowy: nieprawidłowe uprawnienia wymagają innej reakcji niż chwilowy brak połączenia. Microsoft opisuje to rozróżnienie w zaleceniach dotyczących ponawiania operacji.
Istotna jest też sytuacja, gdy aplikacja zapisała zamówienie, ale odpowiedź nie dotarła. Ponowienie nie może wtedy tworzyć kolejnej kopii. To powód, by obsługę powtórzeń zaprojektować razem z mechanizmem ponawiania, a nie dopiero po pierwszej awarii.
Jak przeprowadzić pierwszy etap
Wybierz jeden przepływ i ustal, po czym poznacie poprawę. Można porównać liczbę ręcznych czynności, kompletność przeniesionych pól, zgodność statusów oraz liczbę spraw wymagających wyjaśnienia. Pomiar powinien dotyczyć tych samych typów zleceń przed zmianą i po niej, z uwzględnieniem czasu na poprawki.
Przygotuj zestaw przykładów obejmujący zwykłe zamówienie i wyjątki: brak adresu, zmianę danych, ponowne przesłanie i niedostępność drugiej aplikacji. Najpierw sprawdź je w środowisku testowym, jeśli jest dostępne. Potem można uzgodnić ograniczone uruchomienie z możliwością zatrzymania integracji oraz opisanym sposobem ręcznej obsługi.
Nie obiecuj z góry określonej oszczędności. Wynik zależy od obecnej pracy, jakości danych i liczby wyjątków. Pierwszy etap ma dostarczyć informacji, czy rozwiązanie pomaga i co należy poprawić przed rozszerzeniem zakresu.
Kto zadba o integrację po uruchomieniu
Dostawca może zmienić API, zasady dostępu lub sposób działania wybranej funkcji. Mogą wygasnąć dane dostępowe, pojawić się nowe pola albo zmienić wewnętrzny sposób obsługi zamówień. Dlatego przy wdrożeniu warto ustalić odpowiedzialność za monitorowanie, zgłaszanie usterek i wprowadzanie zmian.
Uzgodnij, kto otrzymuje powiadomienia, kto może wznowić zatrzymaną operację oraz gdzie znajduje się dokumentacja połączenia. Określ też zasady wsparcia i koszty utrzymania. Jednorazowe uruchomienie nie zastępuje ustaleń dotyczących późniejszej obsługi, nawet jeśli integracja początkowo obejmuje tylko jeden proces.
Od czego zacząć rozmowę
Nie potrzebujesz gotowej specyfikacji. Wystarczy opisać:
- Jakie informacje są dziś przepisywane i między jakimi narzędziami?
- Jak często wykonujecie tę czynność i kto się nią zajmuje?
- Jak rozpoznajecie błąd lub brak danych?
- Który jeden krok chcielibyście usprawnić jako pierwszy?
Na tej podstawie można sprawdzić możliwości obecnych narzędzi i zaproponować pierwszy zakres. Zobacz zakres automatyzacji i integracji lub opisz, co chcesz usprawnić.