W firmie produkcyjnej działającej w wielu krajach pytanie o architekturę ERP zaczyna się od tego, co zakłady muszą robić wspólnie. Sprawozdawczość finansowa grupy, zakupy i przesunięcia między zakładami wymagają różnych form koordynacji. Niekoniecznie oznacza to jednak identyczny przebieg lokalnych procesów.
Użyteczne porównanie nie sprowadza się więc do wyboru między globalnym a lokalnym ERP. Chodzi o to, jaką część odpowiedzialności operacyjnej powierzyć wspólnemu systemowi, jaką pozostawić zakładom i gdzie egzekwować wspólne zasady.
Podczas webinaru SoftEngine o strategii ERP prelegenci przekonują, że dopasowanie do strategii jest ważniejsze niż pochodzenie dostawcy. Omawiają możliwości wdrożeń międzynarodowych, znajomość regionalnych uwarunkowań oraz rozwiązania łączące lokalne operacyjne systemy ERP z systemem międzynarodowym. To dobry punkt wyjścia: najpierw ustal podział odpowiedzialności, zamiast traktować kraj pochodzenia dostawcy jako wyznacznik jego przydatności.
Oddziel produkt, instancję i proces
Decyzja o architekturze ERP obejmującej wiele krajów wymaga odpowiedzi na odrębne pytania:
- Wybór produktu: czy zakłady powinny korzystać z tego samego oprogramowania ERP, czy z różnych produktów?
- Projekt instancji: czy powinny współdzielić środowisko aplikacyjne, czy działać w osobnych środowiskach?
- Standaryzacja procesów: które reguły biznesowe, definicje i przebiegi procesów muszą być wspólne, niezależnie od tego, gdzie są realizowane?
W dyskusji o architekturze rozpatruj te pytania osobno. Określenie „ten sam ERP” nie powinno zastępować odpowiedzi na każde z nich. Wspólny produkt z niezależnie utrzymywanymi konfiguracjami lokalnymi to coś innego niż wspólny produkt zarządzany według jednolitego wzorca. Wcześniejsze badanie opublikowane w Communications of the ACM wyraźnie rozróżnia ustandaryzowaną konfigurację obejmującą wiele jednostek biznesowych od kilku różnych konfiguracji, wskazując na ich potencjalnie odmienne skutki organizacyjne.
Globalny wzorzec ERP powinien określać zasady, które organizacja zamierza stosować wielokrotnie: wspólne definicje danych, struktury księgowe, odpowiedzialność za transakcje oraz procesy łączące zakłady. Osobno zdecyduj, czy wdrożyć ten wzorzec we wspólnym środowisku, czy odwzorować go w oddzielnych środowiskach. W przeciwnym razie decyzja o sposobie wdrożenia może niepostrzeżenie stać się polityką organizacyjną, której nikt świadomie nie zatwierdził.
Oddziel też architekturę od decyzji inwestycyjnej. Pozostawienie lokalnego ERP nie dowodzi, że spełnia on potrzeby firmy, a wybór wspólnych procesów nie oznacza, że każdy system trzeba wymienić. Rozstrzygnij to poprzez ocenę, czy ERP usprawnić, czy wymienić, zamiast traktować nazwę architektury jako uzasadnienie biznesowe.
Czego wspólny globalny ERP wymaga od firmy
Wspólne podejście jest najbardziej spójne wtedy, gdy zakłady potrzebują ścisłej koordynacji i mogą zaakceptować wspólne definicje oraz uprawnienia decyzyjne. Jego zaletą jest możliwość ustalenia reguły centralnie i ponownego jej stosowania, zamiast ciągłego przekładania lokalnych interpretacji. Wiąże się z tym obowiązek dopilnowania, aby wspólna reguła odpowiadała potrzebom zakładów, które mają jej przestrzegać.
Zacznij od danych podstawowych. Ustal, które identyfikatory produktów, jednostki miary, dane identyfikujące klientów i dostawców oraz klasyfikacje finansowe powinny być definiowane na poziomie grupy. Następnie oddziel je od atrybutów lokalnych. Wspólna identyfikacja materiału nie musi oznaczać identycznych parametrów planowania w każdym zakładzie. Jednocześnie dopuszczenie lokalnych parametrów planowania nie powinno dawać przyzwolenia na tworzenie niezgodnych identyfikatorów tego samego materiału.
Transakcje wewnątrzgrupowe wymagają podobnej precyzji. W przypadku przepływów między podmiotami prawnymi uzgodnij powiązanie zapisów po stronie wysyłającej i przyjmującej, zdarzenia potwierdzające wysyłkę i przyjęcie oraz odpowiedzialność za rozstrzyganie rozbieżności. Wspólne środowisko aplikacyjne nie powinno zastępować tych ustaleń. Zapytaj, w jaki sposób wybrany projekt zapewnia widoczność i kontrolę uzgodnionej transakcji.
Obciążenie organizacyjne staje się najbardziej widoczne przy zgłaszaniu zmian. Kto może zmienić wspólne pole? Które zakłady muszą zatwierdzić zmianę procesu? Kto rozstrzyga, czy lokalne wymaganie powinno wejść do wzorca? Centralna kontrola jest użyteczna tylko wtedy, gdy towarzyszy jej sprawny sposób rozstrzygania rzeczywistych różnic.
Tę samą logikę zastosuj do aktualizacji. W przypadku wspólnego środowiska ustal, jak zakłady uczestniczą w zatwierdzaniu nowych wersji i jak ich kalendarze operacyjne wpływają na harmonogram. W przypadku osobnych środowisk korzystających ze wspólnego wzorca określ, które zmiany muszą być wdrażane razem i jak będą śledzone odstępstwa. Wybór architektury powinien uwzględniać tę stałą koordynację, a nie tylko początkowe wdrożenie.
Centralny rdzeń z lokalnymi ERP przesuwa granicę wspólnego zakresu
W dwupoziomowej architekturze ERP dla produkcji systemy centrali i zakładów odpowiadają za różne obszary. Infor opisuje ten podział jako koncentrację zakładów na systemach operacyjnych, a centrali na zarządzaniu finansami i innych systemach obejmujących całą organizację. Taki podział jest punktem wyjścia do określenia zakresu, a nie kompletnym projektem integracji.
Wspólny zakres może być stosunkowo wąski. Badanie ACM opisuje połączenie lokalnej autonomii operacyjnej ze wspólną konsolidacją finansową, w tym przykład różnych operacyjnych produktów ERP połączonych ze wspólnym systemem finansowym. Przedstawia też szerszy model, w którym centrala koordynuje łańcuch dostaw dzięki dostępowi do lokalnych potrzeb zakupowych, stanów magazynowych i harmonogramów produkcji. Są to istotnie różne architektury: sama sprawozdawczość finansowa nie zaspokaja potrzeb informacyjnych związanych z koordynacją produkcji między zakładami.
Odpowiednio zdefiniuj więc centralny rdzeń. Jeśli jego celem jest konsolidacja, określ, jak lokalne konta są mapowane na sprawozdawczość grupową, jak uzgadnia się przekazywane dane i jak zatwierdza korekty. Jeśli rdzeń koordynuje również zaopatrzenie, określ, jakich informacji o zapasach i planowaniu potrzebuje, co one oznaczają oraz od jakiego momentu mogą służyć do podejmowania decyzji.
Integracja nie usuwa potrzeby standaryzacji. Zmienia miejsce, w którym trzeba egzekwować uzgodnione zasady. W przypadku danych podstawowych wskaż, kto rozstrzyga o każdym wspólnym polu, i określ powiązanie lokalnych rozszerzeń z tym polem. Dla transakcji wewnątrzgrupowych uzgodnij identyfikatory łączące zapisy w różnych systemach oraz odpowiedzialność za usuwanie niezgodności. W konsolidacji zachowaj możliwość prześledzenia powiązań między przekazanymi danymi grupowymi a lokalnymi zapisami.
Przypisz stałą odpowiedzialność za tę pracę:
- Właściciele danych zatwierdzają wspólne definicje i mapowania.
- Właściciele procesów rozstrzygają rozbieżności między centralnymi a lokalnymi regułami transakcji.
- Właściciele aplikacji i integracji zarządzają zmianami interfejsów, odrzuconymi wymianami danych oraz odpowiedzialnością za przywrócenie poprawnej obsługi.
- Osoby odpowiedzialne za finanse zatwierdzają uzgodnienia i korekty sprawozdawcze.
Lokalna swoboda wdrażania nowych wersji również powinna mieć wyraźną granicę. Wymagaj oceny wpływu, gdy zmiana dotyczy wspólnego pola, transakcji lub danych raportowych. Dopuszczaj lokalne harmonogramy tam, gdzie pozwalają na to zależności, ale uwzględnij sprawdzanie zgodności w zatwierdzaniu zarówno centralnych, jak i lokalnych wydań. W przeciwnym razie „lokalna autonomia” pozostawia bez rozstrzygnięcia odpowiedzialność za ochronę wspólnych procesów.
Odróżnij rzeczywiste różnice od odziedziczonych preferencji
Lokalną różnicę warto oceniać merytorycznie, zamiast automatycznie ją akceptować lub odrzucać. W dyskusji SoftEngine prelegenci odróżniają znajomość regionalnego rynku i specyfikę przepisów od kwestii związanych z globalnym wdrożeniem, jednocześnie odnosząc decyzję do strategicznych priorytetów firmy. Przełóż to na konkretne uzasadnienie samego wymagania.
W przypadku różnicy wynikającej z przepisów wskaż obowiązujący wymóg, zapisy lub dokumenty, na które wpływa, oraz lokalną osobę odpowiedzialną z obszaru finansów lub prawa. Następnie oceń, czy wspólne rozwiązanie może go spełnić dzięki obsługiwanej lokalizacji lub konfiguracji. Wymóg prawny określa to, co trzeba osiągnąć; sam w sobie nie przesądza o potrzebie osobnego ERP.
Przykład ilustracyjny: zakład wytwarzający urządzenia projektowane na zamówienie oraz zakład produkujący powtarzalnie standardowe komponenty mogą potrzebować różnych procesów planowania. Zanim narzucisz wspólny proces, zbadaj rzeczywiste różnice w definiowaniu zamówień, harmonogramowaniu i kalkulacji kosztów. Zakłady nadal mogłyby korzystać ze wspólnych identyfikatorów materiałów, definicji klientów i zasad sprawozdawczości grupowej. Decyzja dotyczy tego, gdzie wspólne rozwiązania pozostają użyteczne, a nie tego, czy zakłady są identyczne.
Z kolei stwierdzenie „zawsze stosowaliśmy tę kolejność zatwierdzania” nie wystarcza, by uzasadnić trwały wyjątek. Zapytaj, jaki obowiązek biznesowy lub ograniczenie operacyjne spełnia ta sekwencja. Jeśli wspólny proces zaspokaja tę potrzebę, zachowanie starej kolejności wprowadza różnicę bez wyraźnego celu. Gdy wymaganie jest już zrozumiałe, skorzystaj z procesu zatwierdzania konfiguracji i modyfikacji, aby zdecydować, jak je zrealizować.
Oddziel też autonomię zakładu od granicy odpowiedzialności systemów obsługujących produkcję. To, czy dana czynność produkcyjna należy do ERP, czy do systemu realizacji produkcji, jest innym pytaniem niż to, czy zakład potrzebuje własnego ERP. Podział odpowiedzialności między ERP a MES powinien wspierać wybraną architekturę, a nie służyć jako skrótowe określenie lokalnej niezależności.
Ustal wspólną odpowiedzialność przed wyborem układu systemów
Skłaniaj się ku wspólnemu globalnemu podejściu tam, gdzie wspólne reguły operacyjne i ścisła koordynacja między zakładami uzasadniają wspólną kontrolę nad zmianami. Wybierz centralny rdzeń z lokalnymi ERP tam, gdzie istotne różnice operacyjne uzasadniają lokalną odpowiedzialność, a organizacja jest gotowa zarządzać łączącymi je mapowaniami, interfejsami i uzgodnieniami.
Żaden wybór nie usuwa potrzeby zarządzania. Wspólne podejście skupia decyzje dotyczące wspólnych procesów i nowych wersji. Podejście hybrydowe przenosi większą odpowiedzialność na styki między systemami. Lepszy projekt to ten, w którym firma potrafi wyjaśnić, przypisać i utrzymać obowiązki związane z dalszym funkcjonowaniem rozwiązania.
Jeśli określasz taki podział między krajami i zakładami, usługi ERP Digiventi mogą być kolejnym krokiem do wspólnego omówienia konfiguracji procesów i integracji systemów.