Carveout, rollout, outsourcing

Projekt wdrożenia systemu SAP w Grupie Bakalland był złożonym przedsięwzięciem. Wiązał się z dużym nakładem pracy. Projekt można podzielić na dwa główne etapy: carveout i rollout. Pierwszy etap, carevout, to przejęcie systemu SAP z oryginalnej instalacji w Norwegii do lokalizacji w Polsce. Drugi, intensywny etap – rollout – wymagał od pracowników Bakalland i Delecta dużego zaangażowania. Konieczna była migracja z dotychczas używanego w Bakalland systemu ERP do istniejącej instalacji SAP Delecty. W trakcie analizy funkcjonalności i identyfikacji różnic w procesach zidentyfikowano ponad 100 gapów, różnic funkcjonalnych wymagających zaadoptowania. Etap rollout zostanie przedstawiony w kolejnym artykule. Poniżej opisujemy przebieg prac związanych z częścią pierwszą – carveoutem. Więcej o migracji i przeniesieniu systemu do All for One Data Centers czytaj w artykule “Bakalland i Delecta: Migracja, nowa lokalizacja i utrzymanie SAP“.

Biznesowe tło projektu

W ciągu 25 lat swojego działania Bakalland (początkowo Uno Tradex) z trzyosobowej firmy mieszczącej się w kawalerce wyrósł na lidera rynku bakalii w Polsce. Do sukcesu przyczyniły się konsekwentny rozwój sieci dystrybucyjnej i asortymentu. Już sześć lat od powstania rozpoczęto akwizycję kolejnych spółek, które „w posagu” wnosiły nowe rynki zbytu i pozwalały rozszerzyć portfolio produktów. Ale nie tylko. Połączenia z innymi firmami stwarzały świetną okazję do synergicznego wykorzystywania ich mocnych stron. W Bakallandzie bardzo dobrze opanowano tę umiejętność.

Kolejna okazja, by przejąć dobre praktyki nowego podmiotu w grupie, pojawiła się wraz z przejęciem firmy Delecta, które ostatecznie nastąpiło z początkiem 2015 r.

Poszerzenie portfolio o komplementarne produkty i większy potencjał rozwoju dystrybucyjnego zarówno w kraju, jak i za granicą to najważniejsze korzyści biznesowe z połączenia obu podmiotów. Korzyścią równie istotną, choć rzadziej wymienianą, jest wartość dodana do tego zakupu, jaką dla Bakallandu stanowi wdrożony i dostosowany do potrzeb biznesowych branży system SAP ERP.

Instalacja SAP stanowiła istotną część transakcji zakupu Delecty. Zanim jednak system mógł zacząć obsługiwać procesy biznesowe, należało przeprowadzić projekt informatyczny polegający – w dużym uproszczeniu na: wydzieleniu (carveout) części systemu obsługującego procesy Delecty z instalacji SAP koncernu Orkla (poprzedniego właściciela); następnie dostosowaniu go do wymagań biznesowych Bakallandu i wreszcie uruchomieniu w kolejnych spółkach grupy kapitałowej.

To złożone przedsięwzięcie biznesowo-informatyczne trwało od listopada 2014 r. do czerwca 2015 i zostało przeprowadzone ze wsparciem BCC (aktualnie All for One Poland).

Od lipca 2015 r. Grupa Bakalland korzysta z w pełni dostosowanego do swoich potrzeb systemu SAP, w szerokim zakresie funkcjonalnym (finanse i kontroling, gospodarka materiałowa i magazynowa, planowanie produkcji, zarządzanie jakością, gospodarka remontowa, zarządzanie kadrami). System funkcjonuje w wydajnej i podwójnie bezpiecznej infrastrukturze All for One Data Centers, administrowany przez specjalistów BCC. Zespoły serwisowe BCC wspierają pracowników grupy w codziennej pracy z systemem.

Przedstawiamy cele oraz metodykę BCC, według której zrealizowany został projekt dla firmy Bakalland.

Cele i uwarunkowania

Tak jak każdy projekt, także carveout, inaczej niż działalność operacyjna, ma dwa podstawowe atrybuty: ramy czasowe oraz mierzalny produkt/wynik. Carveouty mają te dwie cechy zwykle bardzo dobrze określone. Celem jest przejęcie części istniejącego systemu SAP i przeniesienie go do nowej infrastruktury sprzętowej. Ramy czasowe natomiast determinowane są zwykłe złożonością systemu oraz innymi, pozatechnicznymi czynnikami.

Zakres systemu Delecty obejmował moduły: FI, CO, SD, MM, WM, PP, PM, QM oraz HR, zatem był bardzo szeroki i wymagał dużego zaangażowania zasobów.

Z drugiej strony istotny nacisk został położony na jak najszybsze zakończenie projektu. Podyktowane to było kwestiami budżetowymi: docelowo system miał być przejęty przez All for One Data Centers, co oznaczało kilkukrotnie niższe koszty utrzymania instalacji w stosunku do spółki-matki.

Taka sytuacja zresztą jest dość typowa dla projektów wydzielenia SAP, gdyż systemy podążają zwykle za przejętymi spółkami-córkami do tańszej infrastruktury zlokalizowanej w Polsce.

Tu pojawia się kolejny, bardzo istotny czynnik: dostęp do systemu źródłowego. Spółki-matki są zwykle bardzo niechętne udzielaniu dostępu do systemów centralnych zewnętrznym, nieposiadającym umowy o stałej współpracy firmom konsultingowym.

Dlatego w umowie przejęcia spółki warto zawrzeć odpowiednie postanowienia. W przeciwnym razie dostępne opcje przeprowadzenia projektu mogą się zredukować do skorzystania z usługi Company Code Deletion (CCD) świadczonej bezpośrednio przez SAP, bądź realizacji projektu przez centralny zespół IT. Obie opcje zazwyczaj są istotnie droższe (nawet ponad dwukrotnie) niż powierzenie realizacji doświadczonej firmie konsultingowej.

Poza kwestiami „politycznymi” na wybór narzędzi wykorzystanych do przeprowadzenia projektu istotny wpływ ma także organizacja samych danych. Mamy tu możliwe trzy scenariusze: dane wydzielonej spółki przechowywane są w oddzielnym systemie, na oddzielnym mandancie bądź zintegrowane z pozostałymi jednostkami organizacyjnymi korporacji.

Dwa pierwsze przypadki zdarzają się jedynie wyjątkowo, bo nie pozwalają na uzyskanie efektów synergii wspólnego przetwarzania danych wszystkich jednostek organizacyjnych. Mimo to warto zweryfikować sytuację w tym obszarze, gdyż wyodrębnienie jednostki w tych scenariuszach sprowadza się do przejęcia gotowego systemu bądź usunięcia nierelewantnych mandantów.

Opcja numer trzy występować będzie w 99% przypadków, miała też miejsce w przypadku Delecty, dlatego dalsza część rozważań zostanie poświęcona temu wariantowi.

Małgorzata Gołuchowska, Dyrektor Finansowy, Bakalland

SAP – ramy IT dla biznesu
Po fazie intensywnego wzrostu w firmie Bakalland przyszedł czas na uporządkowanie procesów, większą integrację i konsolidację grupy oraz nadanie naszym działaniom biznesowym ram, które dadzą dostęp do rzetelnej i aktualnej informacji i tym samym pozwolą na lepszą kontrolę i będą wspomagać podejmowanie trafnych decyzji zarządczych.
Konieczność ujęcia naszego biznesu w ramy informatycznego systemu zintegrowanego już od jakiegoś czasu była da nas oczywista, a w ostatnim czasie stała się wręcz paląca.
Włączenie w struktury Grupy Kapitałowej Bakalland firmy Delecta wraz z działającym systemem SAP stało się świetną okazją do osiągnięcia tego celu przy minimalizacji kosztów – zarówno finansowych, jak i organizacyjnych – projektu SAP. Nabyliśmy działający system obsługujący firmę z pokrewnej branży, który w stosunkowo krótkim czasie, ale przy bardzo intensywnej pracy zespołu udało się dostosować do wymagań Bakallandu.
Projekty SAP w grupie kapitałowej będącej w trakcie zmian organizacyjnych stawiają szczególne wymagania przed wszystkimi uczestnikami przedsięwzięcia. Wiedząc o czekających nas wyzwaniach, poszukiwaliśmy partnera z wszechstronnymi kompetencjami. Wybraliśmy BCC (aktualnie All for One Poland) ze względu na duży, kompetentny zespół konsultantów oraz bogate doświadczenia w projektach SAP związanych z fuzjami i przejęciami. A także z uwagi na kompletną ofertę utrzymania SAP, od serwisu aplikacyjnego dla użytkowników, po hosting i administrację.
Małgorzata Gołuchowska, Dyrektor Finansowy, Bakalland

Plan działania

Zanim przejdziemy do szczegółów, warto najpierw odpowiedzieć na pytanie, na czym zasadniczo polega carveout SAP.

Jest to projekt, w ramach, którego wykonuje się kopię centralnego, produktywnego systemu SAP, z której następnie usuwa się nierelewantne dane i w końcowym kroku tak spreparowane środowisko przenosi na nową infrastrukturę sprzętową.

Istnieje także alternatywna możliwość utworzenia pustego środowiska docelowego i stopniowego przenoszenia do niego konfiguracji, rozszerzeń i ostatecznie także danych. Jednak ze względu na fakt, że zwykle jednym z głównych celów jest przejęcie danych transakcyjnych, oznacza to konieczność ich migracji. Nie jest to zadanie łatwe, więc takie podejście jest w praktyce wykorzystywane raczej rzadko, jedynie w specyficznych przypadkach.

W warunkach rzeczywistych dąży się do minimalizacji ryzyka związanego z wprowadzaniem zmian w systemach krytycznych dla działalności operacyjnej i jest to prawda także dla projektów carveout. W tym celu stosuje się określoną metodykę działania. Choć na pierwszy rzut oka może się to wydać zaskakujące, do wydzielenia systemu Delecty została zastosowana standardowa metodyka BCC Go Forward, opracowana do prowadzenia wdrożeń SAP. Wprowadzony został podział na pięć faz:

• przygotowanie projektu,
• koncepcja,
• realizacja,
• przygotowanie startu,
• start i wsparcie po starcie.

O ile fazy projektu pokrywają się z innymi rodzajami projektów SAP, to już same zadania realizowane w poszczególnych fazach mają inny charakter.

Koncepcja nie skupia się na procesach biznesowych i ustawieniach systemu, ale na identyfikacji obiektów i zakresu usuwanych danych oraz narzędzi do tego wykorzystywanych.

W ramach realizacji nie budujemy rozwiązań, ale usuwamy dane. Pozostaje tu jednak jeden wspólny element – testy systemu. Po usunięciu danych pożądana jest weryfikacja, czy system nadal funkcjonuje prawidłowo. Jest to krok niezbędny, gdyż szereg ustawień zależy od prawidłowych danych podstawowych, które przecież są modyfikowane podczas realizacji. Realizacja i weryfikacja systemu przeprowadzana jest na instancji testowej SAP.

Pozytywny odbiór pozwala na przejście do fazy przygotowania startu produkcyjnego. W odróżnieniu od standardowych projektów SAP w carveoucie nie przeprowadza się migracji danych i nie szkoli się użytkowników. Zamiast tego opracowane wcześniej narzędzia wykorzystuje się do usunięcia danych tym razem na systemie produktywnym, które kończy się uzyskaniem zielonego światła dla migracji systemu od organizacji kontrolującej system źródłowy.

Start produkcyjny w zasadzie sprowadza się do przeprowadzenia migracji systemu do nowego data center i odtworzenia z pojedynczej kopii docelowego środowiska SAP.

Generalizując, działania w projekcie typu carveout (także w projekcie realizowanym dla Bakalland-Delecta) to po kolei:

• przygotowanie roboczego środowiska SAP – snapshot środowiska produktywnego SAP,
• identyfikacja obiektów i zakresu usuwania nierelewantnych danych,
• usunięcie danych na środowisku testowym,
• wykonanie testów weryfikujących integralność środowiska,
• wykonanie kopii systemu produktywnego i przełączenie działalności operacyjnej przejmowanej spółki na skopiowany system,
• usunięcie danych na nowym systemie produktywnym,
• migracja „wyczyszczonego” systemu do nowej infrastruktury sprzętowej,
• rozpoczęcie pracy operacyjnej na nowym systemie.

Koncepcja

Ten etap projektu jest szczególnie ważny, gdyż błędy popełnione w tej fazie mogą spowodować znaczne opóźnienia w dalszych fazach projektu.

W pierwszym kroku koncepcji należy zdefiniować, jakie narzędzia zostaną użyte do usunięcia zbędnych danych. Pojawiają się tutaj dwie opcje:

• usługa SAP Company Code Deletion (CCD),
• narzędzia archiwizacji danych.

Pierwsza z opcji jest z oczywistych względów rekomendowana przez firmę SAP, jednak jej koszty mogą być bardzo wysokie.

Opcja druga to narzędzia archiwizacji danych stosowane przede wszystkim w celu zmniejszenia wielkości tabel, a tym samym przyśpieszenia pracy systemu. Oryginalnie nie są one przeznaczone do przeprowadzania carveoutów, ale praktyka pokazuje, że się świetnie do tego nadają. W przypadku Delecty zastosowanie miała właśnie opcja druga i dalszy wywód będzie prowadzony w tym kontekście (niezależnie jednak od przyjętego narzędzia, kroki opisane w poprzednim punkcie pozostają tożsame).

Koncepcja carveoutu jest specyficzna i w zasadzie koncentruje się wyłącznie wokół obiektów danych (zarówno transakcyjnych, jak i podstawowych).

Nie wystarczy wszakże zidentyfikować samych obiektów, niezbędne jest także określenie ich atrybutów. Atrybuty te definiują, w jaki sposób zostanie określony zakres danych dla wybranego obiektu przeznaczonych do usunięcia.

Definiowanie atrybutów należy rozpocząć od prezentacji struktury organizacyjnej zaimplementowanej w SAP, wraz ze wskazaniem gałęzi reprezentujących wydzielaną część organizacji.

Na pierwszy rzut oka mogłoby się wydawać, że wskazanie jednostki gospodarczej, która powinna zostać zachowana, jest wystarczające, jednak nic bardziej błędnego.

W przypadku Delecty w ramach jej jednostki gospodarczej zdefiniowany był zakład, który jednak nie dotyczył spółki. Była to pozostałość po dawnej strukturze organizacyjnej, którą należało przed migracją usunąć.

Fakt istnienia dodatkowego zakładu wpłynął na sposób identyfikacji danych (np. niemożliwe stało się wykorzystanie dla obiektów SD jedynie organizacji sprzedażowej przypisanej do Delecty; należało zidentyfikować indywidualne dokumenty związane z usuwanym zakładem).

Aby uniknąć przykrych niespodzianek, niezbędne jest przeanalizowanie całej struktury organizacyjnej (jednostki gospodarcze, zakłady, składy, organizacje sprzedażowe, organizacje zakupowe, obszary rachunku kosztów itd.).

Drugim zbiorem danych do weryfikacji jest zakres modułowy, który może być różny dla spółki wydzielanej i całej organizacji. W projekcie wydzielenia systemu Delecty okazało się, że organizacja centralna wykorzystywała moduł PM, który pozostawał jednakże poza zakresem działalności Delecty (moduł nie był więc uwzględniony na etapie ofertowania, ale został włączony do zakresu projektu już po jego rozpoczęciu).

Ważna uwaga: ze względu na fakt, że zielone światło dla migracji systemu zapalane jest przez organizację centralną oraz ma ona pełną wiedzę o całym wykorzystywanym zakresie systemu, koncepcja powinna być zatwierdzona właśnie przez organizację centralną, a nie wydzielaną spółkę.

Ostatnim krokiem po identyfikacji obiektów archiwizacji i ich atrybutów (kryteriów identyfikujących usuwane dane) jest przygotowanie mapy archiwizacji. Przedstawia ona zależności pomiędzy poszczególnymi obiektami, a zatem determinuje również kolejność wykonywania archiwizacji.

Realizacja

Realizacja carveoutu, jak już wspomniano, sprowadza się do wykonania archiwizacji zgodnie z przygotowaną koncepcją. Niestety, proces ten zwykle nie przebiega bezproblemowo. Kłopoty pojawiają się najczęściej w dwóch obszarach:

• Nieukończone procesy – narzędzia archiwizacyjne działają jedynie na danych wygenerowanych przez poprawnie zakończone procesy. Nie da się zarchiwizować praktycznie żadnych otwartych dokumentów (zleceń produkcyjnych, zleceń sprzedaży, niezafakturowanych dostaw itp.). Oznacza to, że wszystkie otwarte pozycje muszą być najpierw zamknięte. Dla dużej liczby obiektów istnieją narzędzia SAP pozwalające na wprowadzanie masowych zmian, ale niestety nie dla wszystkich. Ważne jest, aby wszelkie dokonywane zmiany rejestrować we wcześniej przygotowanym logu. Wszystkie wykonane czynności na etapie realizacji będzie trzeba przecież powtórzyć w fazie przygotowania startu na nowym systemie produktywnym. W systemie Rieber Foods niestety natrafiliśmy na bardzo dużą liczbę otwartych zleceń procesowych, których obsłużenie wpłynęło na czas potrzebny do wykonania carveoutu.
• Bardzo duże/mało wydajne obiekty danych – w zależności od wieku i intensywności wykorzystania systemu może on osiągnąć bardzo duże rozmiary. Usunięcie dużej liczby danych niestety jest czasochłonne. Dla bardzo dużych, ale prostych obiektów (np. ruchy materiałowe w WM) proces archiwizacji może zająć nawet kilka dni, co przy odpowiednio ustawionej kolejności działania jest akceptowalne. Niestety, oprócz dużych i prostych obiektów zdarzają się też duże i skomplikowane. Skomplikowane w tym sensie, że przed usunięciem pojedynczego rekordu wykonywana jest duża liczba (może dochodzić do kilku tysięcy) dodatkowych zapytań weryfikujących, czy dany obiekt może zostać usunięty (np. obiekt MM_SPSTOCK). Sytuacja staje się bardzo trudna, gdyż standardowy program archiwizacji dla takiego obiektu może pracować nawet kilkadziesiąt dni (bez przerwy), co raczej z perspektywy projektowej jest dyskwalifikujące. W takim przypadku nie pozostaje nic innego, jak napisać własny program imitujący działanie standardowego, jednak zoptymalizowany pod kątem usunięcia konkretnego zakresu danych. Wiąże się to ze sporym ryzykiem, które może być minimalizowane doświadczeniem i dogłębnymi testami firmy konsultingowej. W Delekcie udało się przyspieszyć proces archiwizacji obiektu MM_SPSTOCK z szacowanych około 150 dni do około 8 godzin.

Powyższe potencjalne problemy generują ryzyko, że po usunięciu danych system nie będzie działał prawidłowo. W takich przypadkach działaniem mitygującym jest zawsze przeprowadzenie pełnych testów akceptacyjnych. Testy takie powinny być poparte właściwą dokumentacją, czyli wypełnionymi scenariuszami testowymi. Bardzo często projekty carveout przeprowadzane są na systemach „starych”, dla których mogą nie istnieć aktualne scenariusze testowe. Pamiętając o tym, warto rozpocząć weryfikację jakości dokumentacji na jak najwcześniejszym etapie projektu (niepełna dokumentacja powinna zostać zaktualizowana na etapie budowy koncepcji).

Poza testami akceptacyjnymi przeprowadzonymi przez wydzielaną jednostkę, niemniej istotna jest również weryfikacja systemu przeprowadzana przez organizację centralną. Zwykle w proces zaangażowane są jednostki biznesowe, których dane były usuwane. Przy planowaniu projektu należy uwzględnić fakt, że dostępność osób z poszczególnych jednostek może być ograniczona, zatem warto zagwarantować sobie odpowiednie wsparcie w tym zakresie zawczasu, najlepiej w umowie z organizacją centralną.

Czas trwania procesu realizacji w dużej mierze zależy od wielkości systemu oraz infrastruktury sprzętowej go wspomagającej. W Delekcie na dość dużym systemie testowe usunięcie danych zajęło niespełna dwa miesiące.

Dobrą praktyką w fazie realizacji jest prowadzenie dziennika archiwizacji. W dzienniku rejestrujemy czas trwania archiwizacji poszczególnych obiektów. Dzięki temu w miarę precyzyjnie będziemy w stanie oszacować czas niezbędny do przeprowadzenia fazy przygotowania startu.

Przygotowanie startu

Uzbrojeni w koncepcję oraz log aktywności wynikający z jej zastosowania w praktyce i całość zweryfikowaną przez testy, możemy przejść do usunięcia danych na systemie produktywnym. Oczywiście celem nie jest pozbawienie organizacji centralnej wszystkich danych poza tymi należącymi do właśnie wydzielonej jednostki. To zatem wymusza utworzenie alternatywnego środowiska produktywnego dla wydzielanej jednostki. Środowisko to powstaje podczas „mini go-live” w którym:

• tymczasowo blokuje się jakikolwiek dostęp do bieżącego systemu produktywnego,
• wykonuje się jego kopię,
• migruje na nową platformę sprzętową (będącą jednakże cały czas pod wyłączną kontrolą organizacji centralnej),
• przełącza się wszelkie interfejsy,
• dokonuje się zmian w autoryzacjach (dostęp do nowego systemu pozostaje włączony jedynie dla członków jednostki wyodrębnianej; natomiast tracą oni dostęp do dotychczasowego systemu produktywnego),
• przełącza się SAP GUI na nowy system.

W tym miejscu warto zwrócić uwagę na kilka szczegółów.

Powyżej opisany proces jest praktycznie w całości wykonywany przez organizację centralną, zatem niezbędne jest zagwarantowanie odpowiednich zasobów w umowie. „Mini go-live” z powodzeniem może zostać wykonany w weekend, pod warunkiem wcześniejszego przygotowania odpowiedniej infrastruktury.

Zasoby sprzętowe przydzielone do nowego systemu nie mogą znacznie różnić się od zasobów obsługujących bieżący system produktywny. Jest to związane z faktem, iż pomimo zmniejszenia liczby użytkowników obciążających nowy system produktywny, równolegle będzie przeprowadzana archiwizacja danych powodująca duży stres systemu. Kwestie te zatem również dobrze jest określić w umowie.

Na początku etapu przygotowania startu projekt dysponuje już testowym systemem z usuniętymi danymi, potwierdzonym przez organizację centralną. Jest to fantastyczna okazja do przeprowadzenia migracji testowej systemu. Migracja taka pozwala zweryfikować dwie niezwykle istotne kwestie: łącze danych oraz kompatybilność platformy docelowej. Ze względu na postanowienia licencyjne i platformę SAP HANA jako docelowe środowisko Bakalland-Delecta zdecydowała się na MaxDb jako warstwę bazodanową. Oryginalny systemem Orkli był wspierany przez Oracle. W tym przypadku wchodziła w grę jedynie testowa migracja heterogeniczna, która zakończyła się sukcesem.

Okazało się jednakże, że prędkość łączy jest zbyt niska – transfer bazy testowej zajął cztery dni (o konsekwencjach tego faktu piszemy dalej).

Ze względu na wcześniej zdobyte doświadczenia faza przygotowania startu trwa znacznie krócej niż realizacja. W projekcie dla Bakalland-Delecta produktywne usunięcie danych zrealizowane zostało w trzy tygodnie. Faza kończy się finalnym audytem systemu przez organizację centralną (poszczególne jednostki biznesowe weryfikują, czy w systemie nie pozostały wrażliwe dane). Dopiero pozytywny wynik audytu pozwala na przejście do ostatniej fazy projektu.

Go-live

Tak jak każdy start produkcyjny SAP, także carveout wymaga pewnego czasu niedostępności systemu dla działań operacyjnych. Naturalnie dąży się do jego minimalizacji. W carveoucie czas niedostępności jest determinowany przez długość trwania trzech podstawowych aktywności:

• eksport systemu do pliku,
• fizyczny transfer wygenerowanego pliku,
• odtworzenie środowiska SAP z pliku (ze względu na ograniczony czas zwykle nie odtwarza się pełnego środowiska, a jedynie system produktywny; pozostałe systemy uruchamiana są niezależnie w kolejnych dniach po starcie).

Po usunięciu danych system Delecty okupował 1.5 TB przestrzeni dyskowej. Eksport systemu takiej wielkości zajął ponad 8 godzin. Na odtworzenie systemu wraz z dostosowaniem ustawień i rekonfiguracją interfejsów potrzebne było kolejnych 14 godzin, co łącznie dało niemal dobę.

Jak już wcześniej wspomniano, transfer bazy testowej zajął 4 doby, zatem całe okno startowe powinno wynieść co najmniej 5 pełnych dób (bez jakichkolwiek buforów), co było nieakceptowalne z biznesowego punktu widzenia. Wdrożony został plan alternatywny: dane zostały przetransportowane samolotem na dyskach zewnętrznych przez pracownika Delecty. Całość operacji fizycznego transferu danych została skrócona do 8 godzin.

System został uruchomiony w zakładanym czasie bez większych problemów. W kolejnym kroku można było rozpocząć rozbudowę systemu dla potrzeb Grupy Kapitałowej Bakalland. Ten etap, który obejmuje także rollouty rozwiązania do pozostałych podmiotów w grupie, także odbywa się ze wsparciem BCC (aktualnie All for One Poland).