Rollout czy nie rollout? – Paweł Prymakowski

Co to jest rollout?

Zdarza się, że polski oddział międzynarodowej firmy rozpoczyna, zwykle na polecenie „centrali”, wdrożenie systemu (np. ERP), który używany jest w całej korporacji. Pojawia się wtedy tajemnicze sformułowanie: projekt rollout. Rollout to rozwinięcie systemu, który funkcjonuje w przedsiębiorstwie na spółki córki czy inne podmioty grupy. Pierwsze wdrożenie zazwyczaj staje się wzorcem, z którego powinny skorzystać podległe firmy. Jednak często działają one w różnych kulturach organizacyjnych czy środowiskach prawnych.

Co jest rolloutem, a co nie jest…

Podczas wielu implementacji systemów ERP w polskich oddziałach międzynarodowych organizacji spotykałem się z różnymi podejściami do takich projektów.

Podejścia do projektów:

• „Klasyczny” rollout to projekt realizowany w oparciu o „wzorcowe” wdrożenie. Zwykle funkcjonalność, procesy, wymiary analityczne, ustawienia nie odbiegają (lub niewiele odbiegają) od korporacyjnego standardu. Najczęściej instalacja jest realizowana w oparciu o centralną (międzynarodową) bazę danych. Ewentualne zmiany są zazwyczaj związane z lokalną specyfiką lub wymaganiami prawnymi danego kraju. Projekt jest zarządzany z poziomu centrali (centrala firmy + globalny partner IT), a „lokalni” pełnią funkcję doradczą (a nie decyzyjną).

Możemy łatwo zauważyć, że klasyczny roll-out nie zakłada pełnej analizy biznesowej. Takie wdrożenie korzysta z danych uzyskanych podczas wdrożenia pierwotnego (modelowego). Wdrożenia rollout wymagają zapoznania się z modelem. W tym celu najlepiej jest powołać lokalny zespół roboczy i pokazać zgodność modelu z lokalną specyfiką.  

• Zupełne przeciwieństwo podejścia pierwszego: „Centrala wdrożyła system X, jesteśmy zadowoleni, proszę w spółce Y wdrożyć ten sam system.” W takim modelu spółka-córka jest/nie jest (niepotrzebne skreślić) zobowiązana do stosowania się do ogólnych standardów (ale są one właśnie „dość ogólne”) i zachowuje swobodę w ustalaniu zakresu projektu i szczegółów konfiguracji. Wdrożeniem zajmuje się lokalny partner, a projekt zarządzany jest z poziomu „krajowego”. System może być zainstalowany w spółce lokalnej i np. zintegrowany z centralnym. Taki model projektów spotyka się dość często przy okazji wdrożeń Microsoft Dynamics. W zasadzie nie mówimy w tym przypadku o rolloucie. Jest to tak naprawdę wskazanie systemu docelowego, który zostaje dopasowany do lokalnej specyfiki i jej wymagań.
• Często spotykane są modele pośrednie: łączące wybrane elementy z obu wyżej opisanych podejść. Na przykład zarządzanie projektem i budżetem odbywa się centralnie, ale zespół i zakres ustalany jest lokalnie przy uwzględnieniu kilku kardynalnych reguł (np. układu controllingowego).

Jak sprawić, żeby rollout był udany?

Decyzja o wybranym modelu może zależeć od kilku czynników: polityki centrali, układu sił w korporacji/grupie, uwarunkowań technicznych, itp.

Pewne komplikacje wprowadza fakt, że w projektach typu rollout uczestniczy dość dużo podmiotów, które nie zawsze mają zgodne interesy, a sprawna komunikacja między nimi jest zazwyczaj wyzwaniem. Najczęściej spotkamy ludzi z:

• Centrali firmy – „chcemy wdrożyć w lokalnym oddziale szybko, niskim kosztem i podobnie jak w centrali, bo nasz standard jest uniwersalny”
• Oddziału lokalnego – „oni w centrali nie wiedzą, ale my mamy swoją specyfikę (…) no i te polskie przepisy podatkowe…”
• Globalnego partnera wdrożeniowego (zatrudnionego przez centralę) – „mamy gotowe rozwiązanie, potrzebujemy tylko drobne dodatki, żeby obsłużyć lokalne przepisy; raptem kilka dni roboczych”
• Lokalnej firmy wdrożeniowej – „ale pakiet lokalizacyjny to nie wszystko, jeszcze jest sporo elementów, żeby system był wdrożony ‘po polsku’”
• Ew. innych podmiotów – zewnętrzni konsultanci, firmy obsługujące infrastrukturę IT, itd.

Podstawą sprawnego działania jest ustalenie podziału zadań, odpowiedzialności i zasad komunikacji.

Niezależnie od tego, zespół, który przygotowuje się do takiego projektu, powinien we własnym interesie zadbać o kilka spraw:

• Dopilnować standardów (nie tylko minimum wymaganych przepisów, ale też „dobrych praktyk”). Dzięki temu otrzyma system, który nie tylko zawiera standardową funkcjonalność, ale system, który jest również dostosowany do lokalnych wymagań (przepisy, formaty dokumentów, ergonomia).
• Zapewnić sobie wsparcie zewnętrznego konsultanta. Pozyskanie eksperta pomoże nam w obronie naszych wymagań. Pozwoli na odparcie opinii z centrali: „To za drogo, za duża ingerencja w system”, „Ale to dobrze działa w Niemczech/Włoszech/Holandii/ wszędzie”, „Wasze wymagania to fanaberie”. Rolą konsultanta jest wypracowanie kompromisu oraz wytłumaczenie, które elementy są z naszego punktu widzenia kluczowe i w jakim zakresie można przyjąć rozwiązania proponowane „z góry”.
• Zapewnić wsparcie we własnej organizacji na poziomie kierownictwa. Zwykle zespół z centrali niechętnie będzie podejmował rozmowę o naszych propozycjach. Warto byłoby mieć wsparcie w przypadku poważniejszych konfliktów, tak żeby móc wywalczyć to, co jest najistotniejsze.
• Ostatnie – często najtrudniejsze zadanie: spróbować nawiązać dobre relacje z zespołem z centrali. Nierzadko wiele celów i działań udaje się pogodzić przy odrobinie dobrej woli i otwartości na kompromisy.

Autor

Paweł Prymakowski, CEO IT Vision – firmy wdrażającej ERP od 2000 roku. Doświadczony ekspert wykonawczy, sprzedaży i rozwoju biznesu.
Doświadczony ekspert. Prowadził wiele projektów międzynarodowych. Posiada doświadczenie w wielu branżach: IT, usługach, produkcji, budownictwie, zarządzaniu obiektami, handlu / dystrybucji. Paweł zna również bardzo dobrze obszary biznesowe takie jak: zarządzanie, kontroling, BPR, księgowość, zarządzanie projektami IT, fundusze unijne oraz planowanie i realizacja projektów międzynarodowych.