Ода децентрализации

Ода децентрализации

Бизнес-подразделения Корпорации сегодня работают в основном под единым брендом. Вместе с тем каждое из них имеет достаточно степеней свободы и самостоятельно в принятии рыночных решений. Решения эти зависят от специфики продукции, уровня спроса и конкуренции, особенностей внутренней структуры, зрелости процессов в самой СБЕ.

Как в такой ситуации развивать единую информационную систему, унифицировать процессы и при этом не подвергать избыточной нагрузке бюджеты и финансовый результат бизнес-единиц? Как, оставаясь максимально гибкими, не растерять единства процессов Корпорации и не снижать уровень сервиса для клиентов?

В книге «Бремя сервиса? Время сервиса», в главе 1 «О внутренних процессах» подробно описано, сколько сил и лет было затрачено на то, чтобы все клиенты Корпорации работали с нами через «единое окно» и сервисы получали по единым для всех бизнес-единиц прозрачным правилам.

Организационно эта проблема была решена созданием Отдела клиентского сервиса (ОКС), а технически — появлением модуля ОКСа, который фактически стал «позвоночником» централизованной информационной системы Корпорации. Когда в одном месте сосредоточена вся информация о наличии и стоимости продукции и там же можно сразу сформировать и сделать заказ, это очень удобно для клиентов.

Более того, это решение, сформировавшее единый для всех бизнес-единиц процесс и ставшее фундаментом для развития разнообразных ИТ-сервисов, вызвало к жизни целый «букет» новых возможностей, таких как:

• обеспечение клиентов транспортной логистикой, а не только централизованной системой заказов продукции;

• создание единого Соглашения об уровне оказания сервисов (SLA).

Принципы реализации продукции, заложенные в системе, как клей, связали, казалось бы, различные бизнесы в Корпорации, накрыли их «единым зонтиком».

Комплекс систем и процессов, поддерживающих весь жизненный цикл производства и продажи продукции и обеспечивающих непрерывность бизнес-процессов, работоспособность всей Корпорации, мы называем «централизованными системами».

Их создание, обслуживание и развитие производится в рамках корпоративного центра ИТ-дирекцией. Они — каркас «экзоскелета», который помогает бизнесу функционировать и развиваться.

Конечно, все централизовать нельзя, да и не нужно, у каждой СБЕ свои представления о жизни и допустимых затратах, свои пожелания по новым подходам, экспериментам (ИТ-специалисты называют их «бантиками»).

Понятно, что работа только в централизованных системах не всегда достаточна, требуются свои, локальные изменения прямо в точке возникновения потребности в автоматизации. К тому же локальные успехи не всегда можно и нужно переносить в другую среду.

Например, система ТОиР (техническое обслуживание и ремонты) была успешно реализована в СБЕ «Минеральная изоляция». Эффект превзошел ожидания, процессы выстроены, система развернута, компетенции накоплены. Даже лицензии на систему можно получить по льготной цене. Набегай — подешевело, внедряй — не хочу! Однако лидеры СБЕ у нас люди опытные, осторожные и считать умеют хорошо.

Другая крупная бизнес-единица, «Битумные материалы и гранулы», внимательно изучила ситуацию, оценила затраты и ожидаемый эффект (оборудование‑то у них на заводах другое, потому что продукция совсем другая) и пришла к выводу, что данная функциональность для них явно избыточна. Внедрили стандартный модуль ТОиР из 1С и успешно его эксплуатируют.

Так что централизация процессов и систем — не панацея, гнаться за ней не нужно. Системы, которые развиваются на площадках СБЕ и не связаны с изменениями в централизованных процессах, мы называем «локальными». Они финансируются из бюджетов СБЕ, под полную ответственность своих лидеров. Другое дело, если локальная система нуждается в данных из централизованных источников или требует интеграции с централизованными процессами.

В этом случае ИТ-дирекция корпоративного центра обязательно подключается: согласует процедуры обмена данными, дает рекомендации по размещению данных, а также по методам их хранения и работы с ними.

Не будем лукавить, здесь потенциально конфликтная зона: вроде бы есть разрешение на развитие информационных систем в СБЕ, а ИТ-специалисты корпоративного центра опять вставляют палки в колеса и не дают выстроить «очень эффективную и нужную локальную систему». Такое бывает довольно часто.

Но что же делать, если локальные системы часто не соответствуют стандарту Корпорации по уровню защищенности и стабильности работы? Как только бизнес-критичные данные попадают в локальную систему, возникает много вопросов по надежности хранения информации.

Еще более важный вопрос: а не навредит ли локальная система централизованной? Тем более если обмен данными идет в обе стороны? Волей-неволей приходится «тормозить» развитие таких потенциально опасных инноваций.

В общем виде эта проблема еще ждет своего решения, но первые успехи уже есть: полномочия СБЕ активно расширяются, уровень компетенции их ИТ-специалистов растет. Каждый такой конфликт заканчиваем «разбором полетов»: анализируем ситуацию, выявляем причины проблем в процессах.

Когда удается определить «узкое звено», далее действуем по стандарту: сначала все процессы переориентируются на обеспечение непрерывности работы данного звена (как учит нас теория ограничений ТОС), а затем уже можно заниматься его «расшивкой».

Кроме централизованных и локальных систем, мы ввели еще один класс — «претендующие на централизацию». Бизнес-единицы ближе к реальным процессам и бизнесу, чем корпоративный центр, они гибче. Поэтому инициатива, возникшая на одном из заводов или в СБЕ, может оказаться очень ценной для всего нашего бизнеса.

И хорошо бы вписать ее в централизованные системы, но что делать, если на данном этапе у ИТ-дирекции корпоративного центра нет ресурсов на реализацию данного модуля. Сидеть и ждать, когда корпоративный центр освободится и «снизойдет» до реализации централизованного процесса для всех СБЕ?

В ТЕХНОНИКОЛЬ так не принято. В ИТ-стратегии Корпорации четко зафиксировано: бизнес-единицы могут развивать своими силами системы, претендующие на централизацию, с последующей централизацией данных систем и созданием центров компетенций на базе данного СБЕ.

Правда, степеней свободы у СБЕ в этом варианте несколько меньше: специалисты корпоративного центра будут принимать участие в выборе системы и подрядчика, давать рекомендации, задавать ограничения по используемым технологиям и методам интеграции в существующий контур.

Зато мы не тормозим развитие сервисов и систем в СБЕ. И компетенции внутри компании повышаем, и не занимаемся глобальной и тотальной автоматизацией там, где это совсем не нужно.

Инициаторами развития централизованных сервисов становились различные СБЕ — МИ, БМиГ, ПИ. Впрочем, без конфликтов и здесь не обошлось. Ведь у каждой СБЕ свое представление о функциональности и удобстве работы с тем или иным модулем, претендующим на централизацию. Как результат — развернутые и запущенные в разных СБЕ модули одинаковой функциональности, но на разных платформах.

Реальная ситуация: к тому времени, когда корпоративный центр пришел к выводу о необходимости внедрения системы управления персоналом, две бизнес-единицы уже активно использовали подобные системы. Причем разные.

Возник серьезный конфликт: какая из систем станет централизованной и на какой будет работать вся Корпорация? Вопрос не ограничивался дополнительными затратами по переходу на новую платформу тех, кто проиграет в споре, это была еще и серьезная борьба подходов, видений, точек зрения.

Пришлось генеральному директору Корпорации вмешаться и разрешить ситуацию в «ручном режиме». Без обиженных не обошлось, но компромисс в итоге был найден. Потом, как обычно, провели «разбор полетов» и утвердили новые правила:

• «претендующих на централизацию» систем в Корпорации может быть не более двух;

• если СБЕ принимает решение о развитии модуля системы, претендующей на централизацию, она обязана провести анализ и ознакомиться, кто с подобными системами уже работал в Корпорации и нет ли внедренных решений;

• менеджеры СБЕ при внедрении подобной системы сознательно принимают на себя риски того, что данная система может быть заменена в процессе централизации (если выбор падет на второго претендента).

Зачем же вы разрешили две системы? — может спросить читатель. Не проще ли было директивно определить одну? Проще, конечно, но более рисково и менее эффективно. Не принимать во внимание альтернативных решений, тем более в столь сложной и «разношерстной» Корпорации, было бы принципиально неверно. А так мы делаем выбор, основываясь на опыте реального внедрения и эксплуатации конкретных систем, — получается экономически более выгодно.

Общая классификация наших систем показана на рисунке.

Примечание: в модели заложена возможность миграции систем из локальных в претендующие на централизацию, а также в централизованные. Этот процесс будет происходить по мере развития систем в СБЕ.

А что же с оставшимися ИТ-функциями? С закупкой материалов для ИТ, обслуживанием пользователей, сопровождением систем? Тоже все децентрализовано? Не удивляйтесь — да! Практически все, что не касается централизованных систем и единой архитектуры, децентрализовано.

Совсем недавно после прохождения аудита ИТ-закупок ИТ-дирекция получила очередную стандартную рекомендацию от аудиторов: «полностью централизовать закупки ИТ по всем комплектующим и основным средствам с целью получения синергетического эффекта». Мы уже говорили выше о проблемах общения с аудиторами и консультантами, которые норовят загнать нас в общее «прокрустово ложе».

При нашей географической распределенности централизованные закупки быстро наткнутся на проблемы логистики. Доставить три ноутбука или системных блока в Красный Сулин или Учалы — та еще проблема, да и стоить это будет недешево. К тому же зачем тратить дорогой ресурс корпоративного центра для решения локальных задач отдельного завода? Экономия может быть, если мы покупаем какую‑то крупную партию оборудования (в этом случае мы включаем механизм централизации), но подобные проекты скорее исключение.

ИТ-дирекция корпоративного центра обеспечивает все, что связано с поддержкой, развитием, обеспечением безопасности и непрерывности функционирования централизованных ИТ-систем.

Практически каждая крупная бизнес-единица имеет собственную ИТ-дирекцию во главе с ИТ-директором. Они могут инициировать ИТ-проекты, сопровождать и развивать локальные проекты, развивать компетенции своих ИТ-специалистов на местах, на заводах. У них есть право привлекать внешних подрядчиков и принимать решение о развитии ИТ-процессов, которые выходят за рамки централизованных.

Не сталкиваемся ли мы с эффектом «лебедя, рака и щуки»? Управляема ли данная структура? Как показывает наш опыт — управляема. Единые принципы взаимодействия с клиентами, общая структура централизованных процессов и информационных систем — жесткий стержень, который удерживает всю конструкцию в равновесии.

А большая доля самостоятельности СБЕ, отсутствие излишних ограничений и запретов для менеджеров и их творческих экспериментов позволяют Корпорации оставаться гибкой. Глобальная насильственная централизация исключает гибкость, блокирует развитие процессов и систем, приводит к нестыковкам и неповоротливости структур.

Зачем всем СБЕ, независимо от их потребностей и текущих финансовых возможностей (это же предпринимательские по сути структуры!), «брать под козырек» и разворачивать, тратя попусту деньги и время, ненужные им на данном этапе сервисы?

Да и подготовить такую глобальную централизацию очень непросто. Собрать все (зачастую взаимоисключающие) требования, «хотелки», ограничения, согласовать со всеми СБЕ, найти консенсус… Сколько сил и времени уйдет на этот процесс? А зачем конкретной СБЕ идти на компромиссы, которые потом могут негативно сказаться на ее результатах?

Корпоративный центр не стремится всюду насаждать свои правила. Есть четко очерченный круг общих централизованных зон. Остальное — поле для «творчества». В разных СБЕ разные процессы, поэтому они сами выбирают, что делать, расставляют приоритеты и реализовывают свои замыслы. А для клиентов Корпорация остается гибким партнером, способным реагировать на различные потребности и запросы.