Процессы слияний и поглощений компаний различных отраслей постоянно происходят на рынке. Изменение структуры компании, безусловно, затрагивает ИТ-процессы и специалистов. В этой статье я предлагаю поделиться фрагментом нашего собственного опыта, на что важно обратить внимание в части ИТ, когда предстоит решать вопрос о приобретении бизнеса.
В основе нашего подхода – интересы бизнес-заказчика и возможные дополнительные ИТ расходы. На практике уже выработался следующий чек-лист, и он не зависит от рода деятельности рассматриваемой компании:
Общие вопросы;
Продукты и сервисы;
Персонал;
Расходы;
Compliance и контрагенты;
Процессы.
Общие вопросы
К ним мы относим, в первую очередь, количество сотрудников, причем важно, сколько из них работает в сети продаж.
Поскольку мы финансовая структура, нам не обойтись без отделений, и сразу на входе важно понимать, в каких регионах они могут работать, сможет ли после покупки компании ИТ функция в принципе сопровождать удаленные точки и к каким сюрпризам нужно готовиться. Например, рабочие станции и серверы в ряде российских регионов можно привезти только летом, пока есть навигация.
На эту тему у Самата Галимова в подкасте «Запуск завтра» в эпизоде про Яндекс-маркет классно было замечено: «Пилили мы тут такое в облаке, продукты, все дела, а потом в черную пятницу сгорела газель на трассе Нижний Новгород – Москва, и тут пришло понимание, что это – физический мир».
Планы по развитию компании и людей не менее важны, поскольку надо понять, насколько и в какой момент людей необходимо оснащать техникой, программным обеспечением, вычислительными мощностями и т. п.
При рассмотрении оргструктуры мы получаем понимание о том, есть ли зависимые дочерние организации, и в каких местах еще есть люди, которых необходимо обслуживать (например, могут быть подразделения в городах без наличия там розничной сети). Изменить расположение точки розничной сети – это регулярная история, к которой ИТ, как правило, всегда готово. В то время как перевезти контакт-центр, или операционное подразделение из города в город – это нетривиальная и дорогая задача, которую, возможно, придется решать в дальнейшем.
Места и площади размещения ИТ, в том числе ЦОДы (серверные комнаты и склады), интересны тем, что необходимо знать, какая часть из них находится в собственности и какая часть свободна. Это важный момент для понимания, откуда можно обеспечивать людей техникой, как посмотреть, какое оборудование где находится на самом деле, сходится ли с табличками и CMDB, и куда можно масштабироваться, какие площадки должны быть включены в сделку, а от каких нужно срочно избавляться. Где в основном находятся коллеги из ИТ и куда надо ехать знакомиться с командой. Здесь мы увидим, каким хозяйством на самом деле располагает компания, что работает, сколько стоит в загашнике и что можно использовать под совместные нужды (места в стойках, склады в точках пересечения сети и т. п.).
Текущая ИТ-стратегия – довольно важный вопрос, который сразу показывает отношение людей к своей работе и понимание того, что в организации происходит. В разных организациях она может принимать разные формы, например, форму целевой архитектуры с роадмэпом достижения, или KPI.
Еще очень важный вопрос – кто такой архитектор, каково его место, что он с командой делает для организации. Тут можно миллион копий сломать, потому что кажется, что только классификация начала устаканиваться.
Продукты и сервисы для клиентов
Перечень систем и описание их основных функций и пользователей – очевидный вопрос, который помогает сразу перепроверить полноту архитектуры, увидеть точки для будущих интеграций, или будущие архивы, или бутылочные горлышки для развития.
Планы развития продуктов и сервисов на текущий год. Несмотря на то, что технологическое развитие двух организаций будет двигаться в одном русле, чтобы не уронить клиентский сервис или обязательства перед регулятором, важно на берегу понимать, какие активности из запланированных нельзя останавливать ни в коем случае. Этот план будет хорошим подспорьем для коллег из бизнес-линий обеих организаций (приобретающей и приобретаемой).
Распределение выручки по продуктам за предыдущий год. Для себя очень правильно понимать, на что тратить ограниченные силы, а с чем лучше даже не связываться. Для многих технологов часто становится откровением, что зарабатывает обычно инвестиционный бизнес, а ресурсы тратятся в основном на розничный. Полученную информацию можно сравнить и перепроверить с годовым отчетом. В присоединяемой организации важно поддержать зарабатывающие направления, принимая во внимание, что на слияние будут потрачены ресурсы с обеих сторон, которые, как водится, всегда в дефиците.
Список проектов, завершенных за два предыдущих года и список текущих проектов. Сразу становится понятно, какие вещи не делаются, к ним стоит присмотреться внимательнее и закрыть. Также интересны активности, которые проектами не являются, но, представленные в качестве проектов, могут повлечь за собой значительные расходы. Отдельно стоит присмотреться к бюджетам ИТ-проектов: тут интересно понимать, сколько в него включено Business as usual (непроектных) расходов, и делаются ли проекты в принципе.
Основные регуляторы и госорганы, с которыми происходит коммуникация. Чтобы не упустить какую-то важную коммуникационную цепочку, мы всегда стараемся этим вопросом перепроверить полноту нашего будущего взаимодействия.
Какое подразделение занимается разработкой продуктов и сервисов и их сопровождением (в разрезе «Заказчик – ИТ»). Было бы неправильно пытаться перестроить логику работы коллег, не разобравшись в том, каким образом какие команды работают. Также эта информация является определяющей для слияния команд в будущем.
Персонал
Расходы на команду в финансовом секторе составляют порядка 60%, поэтому дальше мы формируем блок вопросов про людей.
Доверенности на сотрудников сразу показывают ключевых сотрудников и распределение чувствительного функционала.
Организационно-штатная структура ИТ – кажется, что это первым делом просят все и всегда, просто как базовый ориентир.
План по персоналу ИТ на текущий год – обычно из него видно, к чему стоит внимательнее присмотреться, потому что там, где просят много людей, есть возможность для сокращения расходов.
Место сотрудников с ИТ-функцией в общей оргструктуре, но не находящихся в ИТ – то, что Gartner называет shadow IT, поскольку такие люди могут оказаться надежными контрагентами, а могут навтыкать палок в колеса. Поэтому необходимо идти и сразу знакомиться с коллегами, узнавать проблематику с ИТ, договариваться о том, как работать дальше.
Список ключевых сотрудников ИТ с указанием должностей и основных обязанностей. Несмотря на то что этот вопрос могут рассматривать как враждебный акт, мы предпочитаем задавать этот его открыто, без секретиков, поскольку он является одним из первых мостиков для будущего взаимодействия и перемешивания команд.
Список сотрудников без «бэкапа» функционала на время отпусков – это операционно неустойчивая структура, которую надо сразу же устранять, нельзя перегревать человека и не давать ему отдыхать сутками напролет. Часто оказывается, что эти сотрудники входят в список ключевых (см. предыдущий пункт).
ФОТ (staff cost), переработки, количество неиспользованных отпускных дней. Ранее я говорил про 60% расходов? Люди с длинным хвостом отпусков (а мы с вами компанию покупаем, и коллеги могут все разом психануть и уволиться) – это потенциальный риск нагрузки на годовой ФОТ, из нашей практики процентов на 7-15%. А переработки в принципе могут создать двойную нагрузку. Еще интересно сравнивать плановый и фактический ФОТ, потому что при планировании все комбинации учесть невозможно, точно так же, как и всех творческих людей одновременно идентифицировать.
Ответственные за прием оборудования, ответственные за склады. Довольно очевидно, что важно понимать, кто может стать точкой утечки оборудования, или наоборот, на кого будут особенно давить поставщики и подрядчики, интересно сравнить со списком людей с доверенностями.
Ответственные за вендор-менеджмент. Это наши супердрузья, от которых зависят договоренности с вендорами, как следствие, прошлые экстрарасходы, либо будущие хорошие условия, а может нежданчики по доставкам оборудования, или внезапно найденные аппаратные системы на тестировании.
Ответственные за закупки. Ответственные за платежи ИТ и ведение договоров. Надо понять, это лица, принимающие решения, или исполнители и совмещаются ли роли с вендор-менеджерами.
Расходы
Еще раз извините, что не про технологии, но поскольку в ИТ крутится куча денег, а разного рода внутренние контролеры и аудиторы не всегда могут досконально понять, о чем идет речь.
Топ 20 контрагентов по расходам в предыдущем году. Работа с этими контрагентами должна приносить основные успехи, отношения с контрагентами, показавшими свою эффективность, нужно поддерживать, обозначить принятые в покупающей организации правила игры, например, многовендорные закупки и отсутствие защит сделок. Непонимание и взаимные обвинения внутри и снаружи организации происходят, как правило, из-за того, что стороны не до конца понимают мотивацию и ограничения друг друга. Причинами могут стать: уровень маржи, ограниченный снизу материнской компанией, необходимая скорость поставки, как следствие, со склада. Также на этом этапе мы смотрим, можно ли агрегировать контракты после слияния, и каким образом, в какой момент лучше это сделать.
ИТ расходы предыдущего года – на что тратили деньги в прошлом году с учетом ограничений, пересмотров, дополнительно выделенных денег.
ИТ бюджет предыдущего года – и как хотели его на самом деле потратить, что поменялось, кто и какие причины этому послужили, как это повлияло на динамику расходов и расклад контрагентов.
ИТ бюджет текущего года – сделали ли выводы из плана-факта прошлого года, например, у нас была история, когда 40% бюджета прошлого года лежало в проектах, которые по разным причинам не осуществлялись. Очевидно, что нет смысла повторять такой подход и слепо доверять заказчикам без входного фильтра.
В другой организации попросил заявки на компы и ноуты за прошлый год, получилась цифра «Икс», две недели спустя в рамках вопроса про обновление парка дали выгрузку из CMDB, и она оказалась в два раза меньше закупленного. Всего на складах не оказалось, большой привет креативным товарищам, которые работают на пяти работах и получают от организаций не только зарплату, но и технику, ниже яркий пример.
Какие расходы, де-факто сопровождаемые ИТ не включены в бюджет ИТ – shadow IT снова с нами и может прилететь к нам в любой момент.
Даты и предполагаемые суммы продления поддержки SW и HW – здесь надо понять, есть ли время, и как его выиграть на адаптацию и улучшение условий.
Задолженности перед текущими контрагентами – проверяем, насколько они честные и справедливые, как давно не платятся и будет ли возможность заплатить быстро. Также с этим списком будет легко оппонировать манипуляторам, просящим вернуть деньги по каким-то незавершенным сделкам.
Оборудование на тестировании или неоплаченное, но установленное оборудование. В одной из компаний мне поступил звонок перед 23 февраля:
— У нас тут СХД на тестировании стоит уже год, надо вернуть.
— А документы есть?
— Нет, не было ничего, договора же нет.
— А если вы просто купленную хотите вывезти? Давайте искать факты поставки. И еще, скажите, а это точно все оборудование на тестировании?
— Да, точно больше нет.
Забавно, что через 2 недели, перед 8 марта состоялся у нас точно такой же диалог, потому что нашлась еще одна СХД от другого партнера, и тоже на тестировании.
Compliance и Контрагенты
Карта рисков для информационных систем «Что будет, если упадет вот этот квадратик и пролежит день». Все говорят, что все зарезервировано и работает, но на самом деле нет. Потом оказывается, что резервный ЦОД не вывезет нормальную нагрузку при отключении основного ЦОДа. Из десятка организаций, в которых я имел возможность задать этот вопрос за последние 10 лет, только одна смогла положить канал и переключиться, но после полуторагодового проекта по DR. Если нет, то хоть в каком-то виде надо нарисовать, чтобы понять, что где укреплять, и как обрабатывать руками, если все в результате внешнего воздействия или само по себе все упадет.
Степень лицензирования и даты последних аудитов с результатами. После того как основные лицензиаты нас покинули, вопрос может показаться неактуальным, но нет. Лицензионные претензии, как правило, завышены в 5-20 раз, а M&A сделка прямо прописана как триггер для проверки или для претензии с новыми неразобравшимися менеджерами. Поэтому важно сразу понимать, как много не докуплено, как с этим жили и как вести диалог дальше.
Ответственный за общение с аудиторами – в списке ключевых сотрудников его могут не показать, при этом он может слить все фактическое лицензионное состояние, не осознавая этого и даст возможность получить компании лицензионную претензию на миллион долларов или рублей.
Поддержка оборудования – собственная или вендора, SLA. Тоже довольно очевидный пункт: необходимо понимать на какую скорость устранения неполадок можно рассчитывать, есть ли возможность привлекать ресурсы извне организации, придется ли платить штрафы, или иметь предвзятое отношение со стороны вендора в случае, если поддержка делается своими, или неавторизованными ресурсами
АРМы контрагентов (если есть) – это суперважная штука, которая не зависит от тебя, надо понять, как ее охранять и не дать ею манипулировать. Даты замены ключей и ответственные, а также способы хранения паролей давно работающие сотрудники забудут напомнить, а ты прощелкаешь и невольно остановишь операционный процесс.
Долгосрочные обязательства, контракты и договоры длительностью от 1 года. Всегда есть шанс пропустить такой в этом году, потому что платили в позапрошлом году, и внезапно обнаружить у себя круглую сумму на продление поддержки на 3-5 лет в бюджете следующего года.
BCP и DRP с планами перехода и указанием ответственных и акты текущих тестов. В одной американской организации для обновления этой истории и регулярного тестирования был выделен целый человек, и все равно, когда случился пожар (8:30) процедура не помогла к 10 часам быть наготове проводить клиентские операции. Тем не менее, каждому важно понимать свои действия во время DRP. Кому звонить, кого не трогать, и что делать самому. Очень хороший сводный документ на эту тему есть у Microfocus (открывается с VPN), там хорошая не только техническая, но и организационная часть, которой обычно не хватает.
Процессы
Архитектура SW (as is и to be, согласно стратегии ИТ). Реестр систем с описанием функционала и точек интеграции. Важно понять, с чем мы работаем, и провести кросс-проверку со списком софта и его функционалом. В реестре в каждой системе просим пометить производителя или провайдера поддержки, или доработчиков (если своими силами, то просим указать подразделение и фамилии), таким образом, дополняем список ключевых сотрудников и контрагентов.
Ролевые модели для каждой из систем – обычно показывают степень аккуратного обновления документации, если вообще есть. Незамыленному взгляду очень помогает понять, кто из сотрудников старой команды может произвести какие лишние действия.
Объем доработок по каждой из систем в предыдущем и текущем году – на эту тему у нас есть вот тут красивые картинки
И что интересно, ситуация не меняется от года к году, от отрасли к отрасли. При дефиците ресурсов в разработку кладется колоссальное количество часов без выхлопа. Тем не менее, мы всегда обращаем на это внимание для понимания дальнейшего развития систем.
Перечень систем со схожим функционалом для разных процессов и сегментов (к примеру, есть ли две CRM). В компании, где работает больше 500 человек, всегда оказывается две или больше операционных CRM, а если нет, значит я или спросил плохо, или есть несколько инстансов, которые под разные задачи используются, развиваются и ведут себя как разные системы. То же самое может касаться хранилища, или учетных систем, или аналитических систем, где заказчик выбирает решение по вкусу.
SW и HW для дистанционных каналов обслуживания и сервисов. По этим данным мы смотрим насколько масштабируемо решение и готово к резкому всплеску объемов, характерных для дистанционных каналов. Периодические происходят события, вызывающие резкий рост количества операций, который не закрыть текущим ресурсом. Коллеги, кто занимается инфраструктурой в финсекторе, не дадут соврать и только за этот год приведут не менее пяти пиков нагрузки.
Реестр выведенных из эксплуатации систем, использующихся в архивном режиме. Нужен для понимания, что живет в архивном режиме, что мы не платим за неиспользуемую поддержку архивных систем, что у нас есть экспертиза на случай регуляторных доработок.
Архитектура HW (as is и to be, согласно стратегии). Список и схема каналов связи, схема резервирования. Пункт, который часто становится первым вопросом, поскольку формирует базу для дальнейшей сборки всей архитектуры. Здесь интересно посмотреть отказоустойчивость с одной стороны, и избыточность – с другой. А также на входе понять, чего будет стоить подружить между собой две архитектуры, и насколько возможно использовать сильные стороны обеих организаций.
Список ЦОДов и состав оборудования и систем в них. Перечень оборудования: сетевого, серверного, систем хранения и систем резервирования (с указанием «резерва мощностей»). Пересекается с предыдущим пунктом – всегда интересно, как организовано с точки зрения DR. Дополнительно стоит свериться с «живым» визитом, посмотреть насколько данные расходятся с реальностью.
ITIL процессы – что внедрено, внедряется и автоматизируется (детально: разработка, документирование и Service Desk, внутренний и внешний). Поскольку ITIL-сертификации широко распространены, и довольно много коллег стараются работать по библиотеке, ответ на этот вопрос приносил нам довольно много информации в каждой организации.
Перечень оборудования, установленного в предыдущем году – обычно отражает, решали ли программную проблему с помощью «железа», либо показывает список действительно завершенных проектов, а также отношение к регулярности обновления аппаратной части и отказоустойчивости. Еще интересно посмотреть, что купили, что установили и что осталось лежать на складе.
Перечень оборудования, выведенного из эксплуатации в предыдущем году с указанием причины. Здесь интересно посмотреть насколько эффективно б/у оборудование утилизируется (бесплатно, за деньги, либо продается), и какова приблизительная длина жизненного цикла оборудования.
Перечень оборудования в лизинге и аренде. Поскольку обычно мы выступаем со стороны банка, лизинг оборудования всегда оказывается дешевле досрочно прекратить, потому что ставка лизинга всегда выше, чем любая другая в банке.
Количество рабочих станций и телефонов, закупленных в прошлом году. Интересно посмотреть, как и для кого обновляется парк оборудования. Попутно возникают вопросы про апгрейды, и организацию перемещения техники между компанией и ее дочерними структурами. Также мы обращаем внимание на количество рабочих станций на одного офисного сотрудника, использующего компьютер. В одной из организаций это число дошло до 2,5 (компьютер для удаленного подключения, ноутбук домой для удаленки, ноутбук для работы в коворкинге), что очевидно много и дорого.
Кто имеет право вносить доработки на prod-среду? Есть ли среди имеющих такое право представители сторонних организаций? Временный ли это доступ? Это вопросы про управляемость ситуации, есть ли у организации действительный контроль над своими системами.
DR-план, RTO, RPO, дата и протокол последних «учений». Выше уже упоминали disaster recovery, поэтому в данном вопросе интересно выяснить, есть ли понимание с бизнесом и заказчиками, какой сервис с какими характеристиками восстанавливается, и самое главное – был ли опыт, который подтверждает на деле, что эти характеристики правильные, не избыточны и позволяют не уронить сервис для клиентов.
Процесс принятия решения о проектах и доработках (жизненный цикл от выставления требования до закупок, ввода в эксплуатацию и поддержки HW/SW). Каким образом организованы проектное управление, расчет TCO и экономического эффекта, а также контроль успешности проектов. Два бюрократичных вопроса в самом конце, чтобы провалидировать подходы будущих коллег к развитию и, возможно, оценить в целом подходы к принятию решений.
Заключение
Вот такие основные данные мы собираем с коллег для понимания, из чего состоит ИТ в компании-таргете, и как выстраивалась его эволюция в последнее время.
Повторяющиеся вопросы в блоках появляются с тем, чтобы интервьюируемые коллеги, смотря на один и тот же предмет с разных сторон, могли рассказать о нем максимально много.
Уважаемую аудиторию не призываю искать в моем тексте какую-то абсолютную новизну, но, скорее, воспринять этот текст как чек-лист, с помощью которого можно пройтись по основным вопросам, ничего не забыть и сформировать M&A-команде правильный перечень дополнительных расходов и рисков для устранения либо для принятия.
Этот опыт я разделил со своими коллегами Михаилом, Сергеем и Вячеславом. Хочу выразить им свою признательность за возможность работать над интересными задачами.
mikhailmartynov
Спасибо