Problem z integracją starego programu z nowym systemem
Chcesz uruchomić sklep internetowy, CRM albo raportowanie, a program, na którym stoi sprzedaż lub magazyn, nie oddaje danych nigdzie dalej. Integracja starego programu z nowym systemem rozstrzyga się wtedy na poziomie tego, co ta aplikacja potrafi udostępnić, a dopiero potem na poziomie ceny.
W skrócie
Pytanie nie brzmi, czy stary program da się zintegrować, tylko czym. Zostaje interfejs programistyczny, dostęp do bazy danych, plik wymiany albo odczyt z ekranu aplikacji.
Ręczne przepisywanie danych między programami też jest formą integracji. Najdroższą w utrzymaniu i jedyną, która myli się przy każdym powtórzeniu.
Drogi wyjścia są cztery: warstwa pośrednia wymieniająca dane, odizolowanie starej aplikacji, przejście na nowszą wersję u dostawcy albo wymiana programu.
O wyborze drogi przesądza odpowiedź dostawcy programu na dwa pytania: czym aplikacja wymienia dane i jak długo ta wersja będzie jeszcze rozwijana.
Zanim wyjdzie zapytanie ofertowe na nowy system, trzeba wiedzieć, które dane mają krążyć między programami, jak często i w którą stronę.
Integracja to decyzja operacyjna, nie techniczna
Wiesz, czym Twój program sprzedażowy wymienia dane z innymi systemami?
Zamów konusltację z inżynierem Lizard.
Kreujemy standardy
Zespół Lizard
Od ponad 26 lat odpowiadamy za ciągłość działania firm, które powierzają nam swoje IT.
Partnerstwo, które napędza biznes
Współpracujemy z liderami technologii, aby zapewnić bezpieczne i niezawodne rozwiązania backupu i ochrony danych.
Kogo ten problem dotyczy najczęściej?
Stary program rzadko bywa tematem sam z siebie, bo przez lata robi dokładnie to, do czego go kupiono. Wychodzi dopiero przy nowym projekcie: sklepie, CRM, raportowaniu albo wymianie danych z kontrahentem, który tego wymaga w umowie.
Dyrektor operacyjny
Odpowiadasz za to, żeby zamówienie doszło do magazynu, a stan się zgadzał. Poznasz ten problem po tym, że ktoś w zespole ma w zakresie obowiązków przenoszenie danych z jednego okna do drugiego, a reklamacje wracają z rozjazdu między tym, co widzi klient, a tym, co leży na półce. Po temat sięgasz zwykle wtedy, gdy wolumen zamówień urósł na tyle, że ręczna obsługa zaczyna się nie wyrabiać.
Właściciel lub członek zarządu
Zatwierdziłeś budżet na nowy system i słyszysz, że wdrożenie stoi, bo stara aplikacja nie oddaje danych. Poznasz ten problem po tym, że kwota z oferty rośnie o pozycję, której nie było w rozmowie wstępnej, a terminy przesuwają się o kwartał. Po temat sięgasz, gdy trzeba zdecydować, czy dopłacić do integracji, czy wymienić program, na którym firma pracuje od kilkunastu lat.
IT Manager lub administrator
Wiesz, że ta aplikacja nie ma żadnego interfejsu wymiany danych, i mówisz to od dawna. Poznasz ten problem po tym, że na Twoim biurku lądują skrypty eksportujące dane z bazy po godzinach, a każda aktualizacja programu przez dostawcę potrafi je popsuć bez zapowiedzi. Po temat sięgasz, kiedy biznes przychodzi z terminem uruchomienia, a Ty masz wyliczyć, co się da zrobić do tej daty.
Źródło problemu
Dlaczego stary program nie oddaje danych do nowego systemu?
Aplikacja, która nie wymienia danych, nie jest zwykle wadliwa. Została kupiona do jednego zadania w czasach, gdy nic więcej od niej nie oczekiwano, i przez lata to zadanie wykonywała. Problem zaczyna się dopiero od strony drugiego systemu.
{acf_problem_definicja_akapit}
Aplikacja kupiona do pracy bez wymiany danych
Programy sprzedażowe i magazynowe sprzed kilkunastu lat projektowano jako zamknięte całości obsługiwane przez człowieka przy klawiaturze. Wymiana danych z innym systemem nie była wtedy wymaganiem rynkowym, więc nie powstał ani interfejs programistyczny, ani udokumentowany format eksportu. To, co dziś nazywa się integracją, sprowadzało się do wydruku albo do pliku tekstowego przygotowanego pod jeden konkretny cel. Aplikacja działa dalej poprawnie, tyle że granicą jej możliwości jest ekran, na który patrzy użytkownik.
Dostawca rozwijający wyłącznie nowszą wersję
Producent oprogramowania biznesowego utrzymuje jednocześnie kilka linii swojego produktu i w pewnym momencie przestaje dokładać funkcje do starszej. Interfejs wymiany danych pojawia się wtedy wyłącznie w nowej wersji, a przejście na nią bywa wyceniane jak osobne wdrożenie, razem z migracją danych i przeszkoleniem ludzi. Zdarza się też, że producent już nie istnieje albo przejął go ktoś, kto rozwija własną linię. W firmach, które przejmujemy, najczęściej widzimy wersję sprzed kilku wydań, utrzymywaną przy życiu dlatego, że działa, a rozmowa o przejściu dalej nigdy nie doszła do etapu oferty.
Baza danych traktowana jako sposób na integrację
Kiedy aplikacja nie udostępnia interfejsu, naturalnym odruchem jest sięgnięcie wprost do jej bazy danych i czytanie tabel po swojemu. Odczyt zwykle udaje się szybko i dlatego ta droga wygląda tanio. Kłopot zaczyna się przy zapisie i przy aktualizacjach, bo producent może zmienić układ tabel w dowolnym wydaniu, nie informując o tym nikogo, skoro nigdy nie obiecywał, że ten układ jest stały. Integracja zbudowana w ten sposób psuje się więc w losowym momencie, zwykle zaraz po aktualizacji, i nie jest objęta wsparciem producenta aplikacji.
Przepisywanie ręczne wpisane w obowiązki zespołu
Gdy nowy system rusza bez integracji, ktoś dostaje zadanie przenoszenia danych między programami i po kilku tygodniach przestaje to być tymczasowe rozwiązanie. Koszt rozchodzi się po etatach kilku osób i nie pojawia się w żadnej pozycji budżetu, więc nie ma momentu, w którym ktoś go porównuje z ceną integracji. Dopóki wolumen jest mały, układ się trzyma. Przy wzroście sprzedaży albo przy nieobecności tej jednej osoby wychodzi, że proces biznesowy stoi na przepisywaniu z ekranu na ekran.
Czym grozi ręczna wymiana danych między programami
Dopóki dane przechodzą między systemami przez człowieka, firma płaci za to w trzech miejscach naraz: w czasie pracy, w jakości danych i w tym, co da się pokazać przy kontroli albo audycie kontrahenta. Żadne z nich nie pojawia się jako osobna pozycja w zestawieniu kosztów, dlatego temat wraca dopiero przy większej pomyłce.
SKUTKI OPERACYJNE
Dane przenoszone ręcznie są zawsze opóźnione o tyle, ile trwa przerwa między jednym a drugim przepisaniem. Przy sklepie internetowym oznacza to sprzedaż towaru, którego nie ma, albo wstrzymanie sprzedaży towaru, który leży na półce. Przy magazynie oznacza inwentaryzację, która nie zgadza się z systemem, i czas spędzony na szukaniu różnicy zamiast na wydaniu towaru.
Drugi skutek dotyczy ludzi. Proces stoi na jednej lub dwóch osobach, które znają oba programy i wiedzą, co gdzie wpisać. Urlop, choroba albo odejście takiej osoby zatrzymuje przepływ danych, a przekazanie tej wiedzy komuś innemu trwa, bo nigdzie nie została spisana.
SKUTKI FINANSOWE
Koszt ręcznej wymiany danych rośnie wprost proporcjonalnie do liczby zamówień, pozycji w cenniku i kanałów sprzedaży, a koszt integracji jest w większości jednorazowy. Punkt, w którym jedno przecina drugie, zależy od wolumenu i od tego, ile operacji dziennie przechodzi przez człowieka, więc policzyć go trzeba na własnych danych.
Do tego dochodzą koszty, które nie wyglądają na koszty integracji: korekty faktur po pomyłce w przepisaniu, zwroty i reklamacje z rozjazdu stanów magazynowych, rabaty handlowe za opóźnioną realizację oraz czas działu IT zużywany na łatanie eksportów po każdej aktualizacji programu.
WYMAGANIA REGULACYJNE
Jeśli przepisywane dane obejmują dane klientów, obowiązki z RODO dotyczą także tej drogi. Rozporządzenie wymaga od administratora, żeby dane były prawidłowe i w razie potrzeby uaktualniane, oraz żeby przetwarzanie było zabezpieczone środkami technicznymi i organizacyjnymi odpowiednimi do ryzyka. Eksport do pliku, który trafia na pulpit, do skrzynki pocztowej albo na dysk współdzielony, trudno objąć takimi środkami, bo powstają kopie poza kontrolą i bez zapisu, kto je otwierał.
Przy kontroli albo audycie kontrahenta pytanie brzmi zwykle inaczej niż technicznie: gdzie są te dane, kto ma do nich dostęp i skąd wiadomo, że zapis w obu systemach jest ten sam. Firma, która wymienia dane plikami krążącymi między komputerami, zwykle nie ma na to odpowiedzi popartej czymkolwiek poza deklaracją.
Jak połączyć stary program z nowym systemem?
Kolejność jest tu ważniejsza niż wybór technologii. Decyzja o drodze integracji podjęta przed rozmową z dostawcą starego programu najczęściej trafia w wariant najdroższy w utrzymaniu. Pierwsze trzy kroki wykonasz siłami własnymi, bez żadnej umowy, i to one decydują o tym, ile będzie kosztowała reszta oraz czy w ogóle potrzebujesz nowego programu.
Wypisz dane, które mają krążyć między programami
Lista musi być konkretna. Dla każdej pozycji zapisz, co to za dane, z którego programu wychodzą, do którego wchodzą, jak często i czy ruch jest w jedną stronę, czy w obie. Towar, cena, stan magazynowy, zamówienie, status realizacji i dane kontrahenta zachowują się inaczej i każde może mieć inny tryb. Przy okazji wychodzi zwykle, że część danych wcale nie musi krążyć, bo wystarczy jeden kierunek raz na dobę. Krok jest zamknięty, gdy listę zatwierdziła osoba odpowiadająca za proces po stronie biznesu, a każda pozycja ma podany kierunek i częstotliwość.
Zapytaj dostawcę programu o interfejs wymiany danych
Zapytanie wyślij na piśmie i zadaj w nim trzy rzeczy: czy aplikacja udostępnia interfejs programistyczny albo udokumentowany format eksportu i importu, czy producent dopuszcza sięganie wprost do bazy danych i na jakich warunkach, oraz jak długo ta wersja będzie jeszcze objęta wsparciem. Odpowiedź rozstrzyga więcej niż jakakolwiek analiza wewnętrzna, bo wyznacza, co w ogóle wchodzi w grę. Krok jest zamknięty, gdy pisemna odpowiedź dostawcy leży w dokumentacji projektu, bo ustne zapewnienie infolinii technicznej przy wycenie integracji nic nie znaczy.
Policz, ile kosztuje dzisiejsze przepisywanie ręczne
Policz czas, który ludzie realnie poświęcają na przenoszenie danych w ciągu tygodnia, i dolicz to, co idzie na poprawianie skutków pomyłek: korekty, wyjaśnienia z klientami, szukanie różnic w stanach. Ta liczba jest potem jedynym punktem odniesienia przy ocenie oferty na integrację i jedynym argumentem, który działa w rozmowie o budżecie. Przy okazji zobaczysz, czy problem dotyczy całej firmy, czy jednego procesu. Krok jest zamknięty, gdy masz tygodniowy czas pracy w godzinach i wiesz, ilu osób dotyczy.
Wybierz drogę integracji dla pierwszego procesu
Drogi są cztery. Warstwa pośrednia odbiera dane z jednego programu, przekształca je i podaje do drugiego, przez co zmiana po którejkolwiek stronie nie wywraca całości. Odizolowanie starej aplikacji zostawia ją bez zmian, odcina od sieci poza tym, co konieczne, i obudowuje jedynym kontrolowanym punktem wymiany danych. Przejście na nowszą wersję u dostawcy daje gotowy interfejs, ale jest osobnym projektem z własnym budżetem. Wymiana programu ma sens, gdy integracja kosztuje porównywalnie. Krok jest zamknięty, gdy wybór dotyczy jednego procesu i ma oszacowany koszt utrzymania na rok.
Uruchom wymianę na jednym procesie i danych testowych
Pierwszy proces wybierz taki, który jest prosty i mierzalny, na przykład stan magazynowy w jedną stronę. Uruchom go najpierw na danych testowych, potem równolegle z przepisywaniem ręcznym, i porównuj wyniki przez kilka cykli, zanim wyłączysz tryb ręczny. Ten etap wychwytuje rzeczy, których nie widać w projekcie: inne jednostki miary, inne zaokrąglenia, inne kodowanie polskich znaków, braki w danych historycznych. Krok jest zamknięty, gdy przez uzgodniony okres oba tryby dają ten sam wynik, a różnice mają wyjaśnienie.
Ustal, kto pilnuje integracji po uruchomieniu
Wymiana danych psuje się cicho. Nie wyświetla błędu użytkownikowi, tylko przestaje przenosić część rekordów, a firma dowiaduje się o tym od klienta. Potrzebny jest więc monitoring samej wymiany, powiadomienie do konkretnej osoby, opis działania integracji w dokumentacji oraz ustalenie, kto sprawdza ją przed każdą aktualizacją któregokolwiek z programów. Krok jest zamknięty, gdy nieudana wymiana danych generuje zgłoszenie bez udziału użytkownika, a przy aktualizacji programu integracja jest na liście rzeczy do sprawdzenia.
Czego nie robić?
Czego to wymaga po stronie Twojej firmy?
Potrzebna jest osoba znająca proces od strony biznesowej, bo to ona rozstrzyga, które dane mają krążyć i co znaczy, że się zgadzają. Po stronie IT to dostęp do obu programów, do ich dokumentacji i do umowy z dostawcą. Konieczna jest też decyzja o budżecie na utrzymanie integracji, liczonym osobno od kosztu uruchomienia.
Jak realizuje to Lizard?
Lizard prowadzi planowanie i projektowanie IT jako osobną usługę. Zaczyna się ona od rozpoznania stanu wyjściowego, czyli tego, czym firma dysponuje dzisiaj, co działa, co niedomaga i czego oczekuje od środowiska po zmianie. Na tej podstawie powstaje projekt rozwiązania z wyceną i harmonogramem, w którym dobór licencji i planów zakupowych jest częścią tego samego opracowania. Pracami kieruje Architekt IT, a przy większych wdrożeniach dochodzi Kierownik Projektu IT odpowiadający za terminy i koordynację z działami.
Po stronie samej wymiany danych Lizard pracuje na Microsoft Power Platform oraz na platformie Webcon BPS, a w środowiskach, w których aplikację trzeba odizolować bez jej przepisywania, korzysta z konteneryzacji. Lizard napędza IT od ponad 26 lat i prowadzi 10 oddziałów w Polsce, co przy uruchomieniu integracji pozwala zaplanować obecność inżyniera na miejscu w dniu przełączenia. Zakres można ograniczyć do samego projektu albo rozszerzyć o utrzymanie, monitoring i dokumentację powykonawczą.
#MyWiemyJakToZrobić!
Kompetencje potwierdzone technologią i standardem
Microsoft Solutions Partner to status potwierdzający kompetencje w obszarze Azure, Microsoft 365 i Defender. Przy tym problemie liczy się Power Platform, która łączy się z systemami biznesowymi gotowymi łącznikami, a tam, gdzie aplikacja nie ma żadnego interfejsu, obsługuje ją na warstwie ekranu, czyli tak, jak robi to dziś człowiek.
Webcon Premium Partner to status partnerski potwierdzający kompetencje we wdrożeniach platformy Webcon BPS, służącej do budowy procesów biznesowych i obiegów dokumentów. Przy tym problemie pozwala wstawić między programy warstwę, która prowadzi proces, zapisuje historię zmian i pokazuje, w którym miejscu dane się zatrzymały.
Jak wyglądało to w praktyce?
#MyWiemyJakToZrobić!
Planowanie i projektowanie IT
#MyWiemyJakToZrobić!
Obsługa IT
Dzięki specjalizacji w wielu dziedzinach IT możemy profesjonalnie zająć się kompleksową obsługą IT Twojej firmy. Skontaktuj się z nami, doradzimy Ci, co możemy wspólnie zrobić.
Outsourcing IT
To idealne rozwiązanie dla małych i średnich przedsiębiorstw. Zdalna obsługa danego projektu daje jakość usług przy optymalnych kosztach.
Usługi IT
Zajmujemy się projektowaniem, wdrażaniem i utrzymaniem systemów IT. Ofertujemy usługi chmurowe i sieciowe dla małych, średnich i dużych przedsiębiorstw.
Helpdesk IT
Sprawna naprawa błędów informatycznych, dostęp do oprogramowania w ramach outsourcingu, dostęp do specjalistów od systemów IT czy sieci komputerowych.
Bazy danych
Dane to jedna z najistotniejszych wartości w wielu firmach. Administrując bazy danych dbamy o bezpieczeństwo Twojego biznesu.
Bezpieczeństwo IT
Jako Eksperci od cyberbezpieczeństwa IT, pomożemy w zabezpieczeniu systemów i sieci w Twojej firmie od firewall po politykę backup dla Twoich danych.
Najlepsi specjaliści IT dla Twojej firmy
Łączymy siły, by Twój zespół działał
Postaw na Lizard! W naszej firmie it oferujemy elastyczne pakiety obsługi informatycznej dopasowane do Twoich potrzeb, pakiety Basic, Basic Plus, Professional, Expert. Sprawdź wszystkie pakiety.
Audyt IT
Podczas audytu informatycznego sprawdzamy, czy dany system informatyczny i związane z nim zasoby są właściwie chronione.
Zobacz nasze artykuły
{acf_problem_definicja_akapit}
#MyWiemyJakToZrobić!
