Strategia platformowa to nie seria pojedynczych transakcji, które przypadkiem mają tego samego właściciela, ani też nie jest to fuzja równych sobie podmiotów. To sprawia, że kwestia integracji wygląda inaczej niż przy jednorazowym przejęciu. Przy każdym nowym add-onie powtarza się ten sam wybór: co łączy Pan/Pani z platformą, a co świadomie pozostawia osobno. Buy-and-build nie nagradza maksymalnej integracji. Nagradza spójny, powtarzalny sposób dokonywania tego wyboru, transakcja po transakcji.
W strategii platformowej pokusa, by jak najszybciej wtłoczyć każdy add-on w systemy, procesy i kulturę platformy, jest duża. Wydaje się to efektywne, ale to właśnie wtedy znika wartość. Add-on, który został kupiony ze względu na konkretną relację z klientem, niszową kompetencję lub lokalną znajomość rynku, traci właśnie to, gdy integracja posunie się za daleko. Pytanie, czy coś powinno zostać połączone, przy buy-and-build nie jest wyjątkiem od reguły. Jest regułą. Niektóre elementy wzmacniają platformę poprzez połączenie, inne właśnie przez ten sam ruch osłabiają ją. Na stronie kiedy integracja niszczy wartość i po czym Pan/Pani to poznaje opisano, gdzie zwykle przebiega ta granica.
Przy jednorazowym przejęciu pytanie o integrację stawia Pan/Pani raz, dokładnie, z dużą uwagą poświęconą konkretnemu momentowi. Przy buy-and-build podobne pytanie stawia Pan/Pani wielokrotnie, często pod presją czasu wynikającą z kolejnej transakcji, która jest już w przygotowaniu. To wymaga podejścia, które da się powtarzać, bez konieczności wymyślania koła na nowo za każdym razem. Bazowa linia synergii, plan na Dzień 1 i plan na Dzień 100 nie są wtedy jednorazowymi dokumentami, lecz szablonem, który wypełnia Pan/Pani przy każdej akwizycji. Jak to działa w praktyce, można zobaczyć na stronie jak ponownie wykorzystuje Pan/Pani plan integracji. Powtarzalność nie polega na kopiowaniu wyników, lecz na ponownym przechodzeniu przez tę samą strukturę pytań.
Przy buy-and-build istnieje kilka powracających kategorii, w których pozostawienie osobno występuje częściej niż łączenie. Relacje z klientami zbudowane na konkretnej osobie lub konkretnym zespole znoszą niewielkie zakłócenia. Systemy operacyjne, które właśnie zostały dopasowane do konkretnego przepływu pracy, często kosztują więcej w zamian za wymianę, niż przynoszą korzyści skali. Marki z własnym rozpoznawaniem w konkretnej niszy tracą wartość, gdy zanikają w marce platformy. Nie jest to lista wyczerpująca ani sztywna reguła, ponieważ zależy to od tego, dlaczego add-on został kupiony i co ta akwizycja ma dalej robić w ramach większej całości. Na stronie co świadomie pozostawia Pan/Pani osobno i po czym Pan/Pani to rozpoznaje z wyprzedzeniem opisano, jak rozpoznać to z wyprzedzeniem w każdym konkretnym przypadku, zamiast odkrywać to później.
W ramach strategii platformowej istnieje stała presja na konsolidację systemów: jeden ERP, jeden CRM, jedna struktura raportowania. Presja ta jest zrozumiała, ponieważ zarządzanie wieloma systemami kosztuje czas i przejrzystość. Ale konsolidacja nie jest celem samym w sobie. System, który dobrze odpowiada konkretnemu procesowi biznesowemu add-onu, może zniszczyć więcej wartości poprzez wymianę, niż przynosi korzyści w zakresie łatwości zarządzania. Pytanie nie brzmi, czy konsolidacja jest możliwa, lecz czy leżący pod nią proces jest faktycznie taki sam. Gdy to nie jest prawda, czasem lepiej pozostawić system w niezmienionej formie, nawet jeśli na pierwszy wzrok wydaje się to nieefektywne. Zobacz które systemy lepiej pozostawić w niezmienionej formie i po czym Pan/Pani to poznaje dla rozważań, które w tym przypadku mają znaczenie.
Sednem funkcjonalnego podejścia do buy-and-build jest to, że decyzja o integracji nie jest podejmowana na poziomie transakcji, lecz na poziomie elementu. Finanse, IT, sprzedaż, HR, marka, relacje z klientami: każdy element zasługuje na własną ocenę, z własnymi argumentami za połączeniem lub pozostawieniem osobno. Lista decyzyjna, która ustala to element po elemencie, zapobiega sytuacji, w której jeden argument za integracją automatycznie przeciąga za sobą wszystkie inne elementy. Jak zbudować taką listę i gdzie te oceny typowo się różnią, opisano na stronie jak decyduje Pan/Pani dla każdego elementu, czy integrować, czy nie. Dla szerszego kontekstu platformowego, w tym jak powtarzalność i indywidualne podejście mają się do siebie, dostępna jest również strona rozszerzająca temat na stronie co oznacza buy-and-build dla Pana/Pani podejścia do integracji, szczegółowo.
Trzy generatory oraz biuro integracji opisane tutaj są narzędziami służącymi do wprowadzenia struktury: stawiają pytanie o to, czy integrować, czy nie, na nowo dla każdego elementu, śledzą, jakie synergie zostały przyjęte i jakie faktycznie występują, oraz rejestrują zależności między elementami. Nie istnieje żaden przeprowadzony projekt, na który to narzędzie się powołuje; ono porządkuje Pana/Pani własne oceny, nie zastępuje ich. To narzędzie jest w budowie. Osoby, które chcą z niego korzystać od momentu jego dostępności, mogą zapisać się na listę oczekujących.
W ramach strategii platformowej nie tylko sama kwestia integracji jest powtarzalna, ale często również sama praca leżąca u jej podstaw: opracowywanie raportów, porównania danych z data room, przechodzenie przez listy kontrolne przy każdym nowym add-onie. Osoby, które chcą wiedzieć, jaka część tej powtarzającej się pracy może zostać przekazana AI, znajdą w skanie pracy FTE TO AI ukierunkowane na zadania obliczenie, które wskazuje dla każdego zadania, jaka jego część może zostać przejęta przez AI.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.