Zbieractwo danych to wyzwanie, z którym mierzy się niemal każda firma.
Firmy gromadzą ogromne ilości danych, często bez realnej potrzeby. Według IDC, aż 90% z nich pozostaje niewykorzystanych, co prowadzi do chaosu i zbędnych kosztów. Najczęściej przechowywane w nadmiarze są logi systemowe, dane klientów, informacje IoT i kopie zapasowe, które często nie znajdują praktycznego zastosowania. Co gorsza, wiele firm nie wie kto odpowiada za dane i jak są one wykorzystywane.
Potrzeba Data Governance
Aby uniknąć bałaganu, firmy muszą świadomie zarządzać danymi. Data Governance pomaga określić, co zbieramy, po co i kto za to odpowiada. Dobre zarządzanie redukuje koszty, poprawia jakość informacji i minimalizuje ryzyko naruszenia regulacji takich jak RODO.
Jak przeprowadzić się do innego systemu?
Przede wszystkim, musimy zrozumieć założenia projektu i jego cel. A to definiuje możliwe scenariusze migracji danych:
– przeniesienie z jednego typu systemu do innego,
– przeniesienie się do nowszej wersji systemu,
– stworzenie wspólnego systemu po połączeniu różnych spółek,
– włączenie nowej spółki do aktywnego systemu w wyniku nabycia.
Zmiany mogą dotyczyć jednej lub wielu spółek. Projekt w przypadku wielu spółek może być rozbity na pilot i tak zwane rollouts lub może być realizowany jednoetapowo, tak zwany big bang.
Nic nie rodzi się z próżni.
Spółki łączą się ze sobą, zostają przejęte przez inne spółki, powstają w wyniku wydzielenia lub inwestycji. Żeby nie odkrywać koła na nowo, powinniśmy zawsze bazować na tym co udało się nam wcześniej stworzyć. Z pomocą przychodzi podejście, w którym kopiujemy elementy systemu odpowiadające za model operacyjny wcześniej utworzonej spółki i napełniamy go danymi nowej spółki.
Z perspektywy realizacji projektu, podejście kopiujemy nie zmieniamy jest proste, a zarazem bardzo efektywne jeśli chodzi o czas i budżet.
Jednak istnieje szereg czynników, które należałoby rozważyć:
Czy można skopiować ustawienia systemu dla firmy działającej w innym kraju? – żeby odpowiedzieć na to pytanie, trzeba sprawdzić czy model operacyjny i obowiązki związane ze sprawozdawczością finansową są jednakowe.
Jako przykład, rozważmy metodę rozliczenia podatku VAT. Te same transakcje wykonane w Polsce mogą podlegać metodzie opodatkowania split payment (część płatności trafia na specjalne konto), natomiast w większości krajów UE podlega metodzie reverse charge (kupujący jest odpowiedzialny za opłacenie podatku). Inne obowiązki podatkowe to inny model operacyjny, a model operacyjny determinuje potrzebne dane podstawowe do realizacji zadań w systemie.
Ok, ale czy to wszystko?
Poza tym należy zauważyć, że plan kont różni się pomiędzy krajami UE. No i oczywiście stawki VAT. Aspekt wysokości stawek VAT to raczej marginalny problem, ogranicza się do wyboru odpowiednich parametrów. Natomiast mechanizm rozliczenia podatku VAT i plan kont ma wpływ na sposób realizowanych procesów, a inny proces potrzebuje innych danych.
Odłóżmy na chwile komplikacje wynikające z faktu, że chcemy skopiować ustawienia, które nie do końca pasują do wymogów sprawozdawczości finansowej w danym kraju. Zamiast tego, rozważmy kopiowanie ustawień systemów, które do tej pory były wykorzystywane przez spółkę działającą w tym samym kraju, jednak w innej branży.
Często zdarza się, że np. firma produkująca żywność kupuje spółkę, która dostarcza opakowania. Czy model operacyjny, który sprawdza się w produkcji żywności, sprawdzi się również w produkcji puszek czy kartonów? Firmy produkujące żywność często stawiają na stabilność i niezmienną jakość składników. Rzadko tworzą nowe wersje receptur dla znanych produktów. Natomiast produkcja opakowań swoim charakterem bardziej przypomina drukarnie, dla której ważna jest możliwość zarządzania projektami graficznymi i wersjami projektów.
Czy w takiej sytuacji kopia systemu pokryje wszystkie wymagania innego modelu operacyjnego? – może być to co najmniej trudne i może się również wiązać z utratą części funkcjonalności.
A co z danymi? – też różnią się w tym przypadku dosyć znacząco. Receptura w branży FMCG, czyli inaczej BoM (bill of materials), to nic innego jak lista składników wraz z ilością. Dla branży opakowań nowa wersja produktu to raczej projekt introligatorski, a nie lista.
Ok, ale przejdźmy to prostszych scenariuszy. Załóżmy, że chcemy skopiować nasze rozwiązanie dla niedawno nabytej spółki, która działa w tym samym kraju i produkuje to samo co my. Czy mamy tu jakieś ryzyka?
Jak się zapewne domyślacie, także i w tym przypadku nie brakuje potencjalnych zagrożeń. Przede wszystkim, musimy sprawdzić otwarte zobowiązania spółki oraz jak wyglądają obowiązujące kontrakty i umowy ramowe. Dla przykładu: trzeba zastanowić się czy sposób rozliczania rabatów będzie możliwy w nowym systemie. Chociaż zaadaptowanie systemu w tym przypadku może nie być skomplikowane, z perspektywy migracji danych należy zwrócić szczególną uwagę na skalę naliczania rabatów, np. rabaty naliczane na skali ilościowej dla kategorii produktu to nie to samo co rabaty naliczane na podstawie całości obrotu.
Amputacja czy chirurgiczne cięcie?
Skopiowanie działającego systemu IT to interesująca opcja. Oszczędza zaangażowanie ludzi, czas i pieniądze. Czyli wszystko, czego potrzebują firmy. Niestety wiąże się to z pewnym ryzykiem. Zanim to zrobimy, musimy zastanowić się, które zmiany wynikają z wymogów prawnych, które mogą doprowadzić pogorszenia efektywności operacyjnej, a które spowodują, że nie będziemy mogli wywiązać się z naszych zobowiązań względem kontrahentów.
Zdecydowanie łatwiej jest skopiować system, ale najpierw należy sprawdzić które ze zmian są po prostu konieczne. Analiza tego jak chcielibyśmy, żeby nasz system funkcjonował w przyszłości, pozwoli nam zdefiniować jakich danych i w jakim formacie tak naprawdę potrzebujemy.
Jeśli uda nam się zrozumieć procesy i zdefiniować dane potrzebne do ich realizacji, będziemy mogli przenieść tylko te dane, których potrzebujemy. Podobnie jest z przeprowadzką: nie zabieramy ze sobą niepotrzebnych rzeczy. Koszt przenoszenia i utrzymania w porządku niepotrzebnych rzeczy w przypadku przeprowadzki jest bardziej namacalny: to czas, energia i miejsce. W przypadku migracji danych nie widzimy tego w tak bezpośredni sposób, ale zarządzanie danymi, które możemy utrzymać w porządku, pozwoli nam korzystać z nich lepiej w przyszłości. Pomimo tego, że koszty związane z śladem węglowym zeszły ostatnio na drugi plan, to aspekt utrzymywania zbędnych danych w przedsiębiorstwach wróci do nas niebawem w kontekście efektywności. Szczególnie, że według IDC (International Data Corporation) ilość danych w przedsiębiorstwach rośnie o przeszło 25% w skali roku, a w 2025 zużycie energii przez Centra Danych będzie wynosiło około 3% światowego zapotrzebowania na energię.
Chcesz uniknąć błędów przy migracji danych? Skontaktuj się z nami!
