В първите сто дни след сделка проблемът често изглежда като липса на решения. По-често проблемът е последователността. Решение относно общата ERP-система блокира изграждането на отчетните линии. Решение за кой получава търговския мандат, блокира всеки разговор с общи клиенти. Докато никой не назове тази зависимост, два екипа чакат едновременно един другия, без никой да го забележи.
Не всяко неразгледано решение е проблем. Някои неща могат да чакат, без останалото да спре — кои са те и кой има право да реши това, е описано на страницата за това, какво може да чака до след Day 100. Блокирано решение е нещо друго: то е решение, от което зависят други решения, и което видимо ги задържа. Разликата не винаги е видима от гледна точка на един екип. Финансовият отдел не вижда, че чакането му за избор на система също спира интеграцията на HR, защото фишовете за заплати са свързани със същата система. Тези връзки стават видими само когато някой ги картографира изрично, отделно от отдела, който случайно е последен на опашката.
Разходите на блокирано решение рядко са фиксирана сума на седмица. Те зависят от това, какво стои неподвижно: договорена цена, която не може да бъде преразгледана, докато продуктовото портфолио не е обединено, ключов служител, който напуска, защото никой не му дава яснота за ролята му, клиент, който преминава към конкурент, защото два екипа по клиенти си противоречат. Това не са числа, които могат да бъдат изчислени предварително. Могат обаче да бъдат подредени: кое решение засяга колко други решения и какъв е характерът на щетата, ако отнеме повече време. Тази подредба — по несигурност и последствие, не по кой вика най-силно — е разгледана на страницата за подреждането на решения по разходи за несигурност.
При картографирането на блокиращи решения принадлежи въпрос, който не бива да бъде пропуснат: трябва ли тази част всъщност да бъде интегрирана. Разрешаването на зависимост чрез обединяване на две системи не е автоматично по-добро от това, да ги оставите да съществуват паралелно. Понякога най-бързият начин да се премахне блокада е да се реши, че интеграцията в тази точка не добавя стойност. Това решение не бива да се взема безмълвно, защото никой не е задал въпроса; то трябва изрично да бъде поставено на масата, редом с въпроса кога и в каква последователност.
Списък с блокиращи решения е неполен вече в първия ден на интеграцията и става такъв все по-бързо с всяко взето решение. Нови зависимости възникват веднага щом старите се разрешат: системата е избрана, а сега се оказва, че внедряването зависи от договор с доставчик, който все още тече. Някой трябва да поддържа тази карта актуална, не като еднократно упражнение през първата седмица, а като текуща задача — иначе блокадата само се премества. Кой изпълнява тази роля и как тя не позволява самата карта да се превърне в забавяща бюрокрация, е описано на страницата за поддържането на интеграционния офис работоспособен.
Блокираните решения често са причината, поради която план за Day 100 не се изпълнява, не защото планът е бил грешен, а защото зависимост е била подценена. Кои решения по принцип принадлежат на първите сто дни и кой следи те действително да бъдат взети, е описано на страницата за решенията в първите сто дни. Какво да се прави, ако крайният срок все пак не се постигне — кои решения тогава се преподреждат по приоритет и кой решава това — е описано на страницата за неизпълнението на Day 100. Сигнализирането на блокада не е същото като нейното разрешаване, но без сигнализиране забавянето остава невидимо до момента, в който трябва да се предаде отчетът.
Генераторите и интеграционният офис на mergerintegration.net структурират тези зависимости: те картографират кое решение чака кое друго решение и коя част от организацията в резултат стои неподвижна. Това не е послужен списък — няма изпълнен проект, на който този инструмент да се позовава, и това не се предполага тук. Това е начин да се постави въпросът точно преди забавянето да стане видимо в числа, които никой вече не може да коригира. Който иска да работи с това, може да се запише в списъка на чакащите; инструментът е в процес на изграждане.
Част от времето, което се губи за блокирани решения, отива в работа, която хората правят ръчно, докато може и автоматично: обединяването на списъци с клиенти, сравняването на договорни условия, поддържането на карта на зависимостите, която се променя след всяка среща. Работният скенер на FTE TO AI изчислява за всяка задача коя част от нея може да бъде поета от 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.