Egy deal team, amely korábban már integrált egy akvizíciót, gyakran rendelkezik egy tervvel. Egy Day 1-checklistával, egy szinergiakategóriák listájával, egy kommunikációs ütemtervvel. Nagy a kísértés, hogy előhúzzuk azt a dokumentumot a fiókból, kicseréljük a neveket és a számokat, és folytatjuk. Ez időt takarít meg. Gondolkodási munkát is megtakarít, és pontosan ez a probléma.
Egy integrációs terv nem egy sablon egy organizációhoz, hanem az eredménye olyan döntéseknek, amelyeket egy másik vállalatkombinációnál hoztak meg. Melyik rendszerek olvadnak össze, melyik csapatok fuzionálnak, melyik ügyfélkapcsolatok maradnak külön — ezek a döntések attól függtek, milyen volt az előző két vállalat, nem attól, milyen ez a két vállalat. Ha egy tervet újrafelhasznál anélkül, hogy az alapul szolgáló döntéseket újra megvizsgálná, azt jelenti, hogy egy másik helyzetre épített struktúrát vesz át.
A kockázat nem a formában rejlik. Fázisbeosztás, egy benefit-tracker, egy függőségi lista — ezek az elemek gyakran remekül újrafelhasználhatók. A kockázat abban a tartalomban rejlik, amely észrevétlenül utazik velük: az a feltételezés, hogy az X részleg mindig összeolvad, hogy az Y rendszer mindig kivezetésre kerül, hogy a kultúraintegrációt mindig ugyanúgy kell megközelíteni. Ezek a feltételezések nem neutrálisak. Precedensek, és a precedens bizonyítéknak érződik, míg valójában nem az.
Három dolog rendszerint jól átvihető egyik projektből a másikba:
Ezek az elemek metódust jelentenek, nem eredményt. Megmutatják, hogyan jut el egy válaszhoz, nem azt, mi a válasz. Ez a különbségtétel a felelős újrafelhasználás lényege: a folyamatot átvenni, a következtetéseket nem.
Kockázatossá válik, amint egy korábbi terv magát a kérdést kihagyja. Ha az előző projektben azt állították, hogy két sales csapat összeolvad, és ezt automatikusan átveszik, mert „ez egyszerűen így működik”, akkor annak esélye, hogy ez most is helyes, a véletlenen múlik, nem az elemzésen. Bővebben arról, mikor rombol értéket az összevonás és min ismeri fel, olvashat egy másik oldalon, de az állandó kérdés itt visszatér: talán jobb lett volna ezt az elemet külön tartani.
Ez erősen igaz a rendszerekre. Egy IT-migráció, amely az előző dealnél logikus volt — mert a felvásárolt cég elavult platformmal rendelkezett —, nem automatikusan logikus egy olyan vállalatnál, amelynek éppen most megújított és jól funkcionáló rendszere van. Melyik rendszereket jobb megtartani, és min ismeri ezt fel, minden helyzetben külön mérlegelést igényel, nem egy szabályt, amelyet az előző dealtől átvesz.
Az organizációs struktúra is érzékeny a vak újrafelhasználásra. Ha az előző terv kimondta, hogy a pénzügyi részlegek mindig fuzionálnak, akkor ezzel az automatizmussal eltűnik a kérdés, hogy ez itt is helyes-e. Egy buy-and-build stratégiánál, ahol egy platform ismételten vállalatokat ad hozzá, a kísértés, hogy egyetlen sablont futtassanak, még nagyobb — és a szükség, hogy elemenként újra megnézzék, még sürgetőbb. Amit egy buy-and-build megközelítés kíván az integrációs stratégiától, és min ismeri fel ezt, ezért is megérdemel egy saját mérlegelést minden akvizíciónál, nem egyetlen visszatérő tervet.
Egy működő megközelítés az, hogy a korábbi tervet olyan kérdéslistaként használja, amelyet újra fel kell tennie, nem pedig olyan válaszlistaként, amely már eldöntött. Minden olyan elemnél, amelyet az előző tervben integráltak, újra felteszi a kérdést, hogy ez itt is érvényes-e. Minden olyan elemnél, amely külön maradt, megkérdezi magától, hogy ez az indok itt is alkalmazható-e. Az, hogy hogyan strukturálja ezt a döntést elemenként — integrálni vagy nem, és milyen kritériumok alapján —, végső soron többet határoz meg az eredményről, mint az, hogy milyen gyorsan kerül papírra a terv. Lásd még, hogyan építi fel ezt a döntést elemenként, és min ismeri fel: hogyan dönt elemenként az integrálásról vagy annak elmaradásáról.
Az, ami tudatosan külön marad, ugyanannyi figyelmet érdemel az újrafelhasznált tervben, mint az, ami összeolvad. Egy terv, amely csak integrációs lépéseket tartalmaz, és semmit nem mond arról, mi az, amit kifejezetten nem vonnak össze, a döntés felét hiányolja. Ha előre láthatóvá teszi, mi marad külön és miért, elkerülhető, hogy ezt a döntést később hibaként magyarázzák. Bővebben erről: mit hagy tudatosan külön, és hogyan rögzíti ezt előre.
A mergerintegration.net három generátora és integrációs irodája ezen a megkülönböztetésen alapul: struktúra, amely átutazik, nem következtetések, amelyek titkon átutaznak. Egy szinergia-alapvonalat, egy Day 1-tervet és egy Day 100-tervet minden helyzetben újra felépítenek ugyanazokból a kérdésekből kiindulva, egy benefit-trackerrel és egy döntéslistával, amelyek elemenkénti válaszra kényszerítenek. Ez struktúrát adó eszköz, nem garanciát adó tapasztalat — az eszköz még épül, és aki használni szeretné, feliratkozhat a várólistára.
Egy integrációs terv arról szól, ki milyen munkát végez, melyik részlegek olvadnak össze és melyik folyamatok maradnak fenn. Ez alatt a kérdés alatt egy pontosabb kérdés rejlik: mennyi az a munka, amelyet majd együtt vagy külön végeznek el, ami valójában olyan feladatmunka, amely automatizálható. Az FTE TO AI munkaterhelés-elemzése (werkscan) feladatonként kiszámítja, mekkora részét veheti át az AI, és ezzel számszerű alapot ad egy döntéshez, amely másképp feltételezésen nyugodna — pontosan az a kockázat, amely az újrafelhasznált integrációs terveknél is leselkedik.
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.