Библиотека управления

Автоматизация холдинговых структур: основные подходы

Долотин Игорь Старший специалист отдела IT-консалтинга ООО "Консультационная фирма "М-РЦБ"

Оглавление журнала

    В статье рассматриваются подходы к построению корпоративных информационных систем (КИС) в структурах холдингового типа. Проводятся анализ и сравнение двух основных подходов: революционного, когда осуществляется внедрение "тяжелой" ERP-системы, подменяющей уже действующие на предприятии автоматизированные системы управления (АСУ), и эволюционного, при котором производятся сращивание функциональности каждой из действующих АСУ и их интеграция на уровне цепочек бизнес-процессов.

Холдинговые структуры

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

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

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

Стоит заметить, что вертикально-интегрированные холдинги, как правило, образуются в сырьевых отраслях промышленности. Примером вертикально-интегрированного холдинга является ОАО "ГМК "Норильский Никель". Горизонтально-интегрированные холдинги представляют собой предприятия, производящие широкий ассортимент продукции в каком-либо определенном секторе промышленности, например в пивоварении либо производстве табачных изделий. В качестве примера можно привести такую компанию, как SUN Interbrew. И, наконец, смешанные холдинги представляют собой структуры, имеющие признаки одновременно двух или всех трех вышеуказанных типов. Пример смешанного холдинга - ОАО "Северсталь".

Рассмотрим основные пути образования холдингов. Диверсифицированные холдинги, как правило, образуются в результате покупки кажущихся наиболее перспективными предприятий различных отраслей. По сути, данный способ является способом инвестирования свободных денежных средств. Вертикально-интегрированные холдинги образуются либо путем формирования (приобретения) сбытовых и/или производящих компаний (интеграция вверх), либо путем формирования (приобретения) добывающих компаний и/или компаний-поставщиков (интеграция вниз). Наконец, горизонтально-интегрированные холдинги формируются за счет покупки конкурентов в отраслях профильного бизнеса. Что же касается смешанных холдингов, они и здесь оправдывают свое название, поскольку образуются самыми различными путями (в том числе и вышеназванными).

Условия проведения автоматизации

В силу того что холдинги состоят из нескольких компаний, имеющих различные бизнес-функции, как правило, образуется территориально-распределенная многофилиальная структура. Причем каждое из предприятий, входящих в холдинг, в силу исторических причин имеет (если имеет) свои собственные устоявшиеся бизнес-процессы, а также IT-стандарты и политики. Есть у него и свои АСУ - либо закупленные и внедренные, либо собственные разработки, которые велись, как правило, без достаточной информационной, методологической и организационной поддержки. Подобные системы в совокупности представляют собой так называемую "лоскутную автоматизацию", т. е. набор разобщенных АСУ, каждая из которых автоматизирует бизнес лишь в одной из предметных областей. Между тем "лоскутная автоматизация" - весьма характерный этап эволюционного развития IT-инфраструктуры предприятий; на определенном этапе развития бизнеса она неизбежно перестает соответствовать предъявляемым к ней требованиям, порождая следующие проблемы управления предприятием:

  • отсутствие полной и целостной информационной картины о деятельности предприятия в целом;
  • потребность большего времени для принятия менеджментом предприятия подкрепленных актуальными фактическими данными управленческих решений;
  • рассогласования в работе структурных подразделений предприятия, растущее удельное время выполнения ежедневных работ операционного цикла.
С технической точки зрения наличие на предприятии множества разрозненных АСУ также обладает серьезными недостатками:
  • корпоративная информационная база данных состоит из ряда слабо связанных друг с другом, в общем случае разноформатных БД;
  • ввод данных в АСУ производится задним числом, часто неоднократно;
  • совокупная стоимость владения АСУ и IT-инфраструктурой в целом довольно велика;
  • функционирование АСУ зависит от отдельных сотрудников, являющихся носителями "ноу-хау";
  • имеются проблемы с безопасностью данных.
Получившийся "зоопарк" АСУ являет собой одну из основных проблем на пути развития бизнеса холдинга в целом: подобную структуру очень трудно заставить работать как единый слаженный механизм. Ввиду того что пути образования холдингов неодинаковы (см. выше), у каждого холдинга этот "зоопарк" свой - отличаются состав АСУ, множество реализуемых ими функций, используемые БД, уровень и средства интеграции АСУ и т. д. Но перечисленные управленческие и технические проблемы становятся актуальными для всех холдингов.

Между тем именно соответствие уровня зрелости IT основным бизнес-целям стало одним из ключевых конкурентных преимуществ современного предприятия. И рано или поздно перед руководством холдинга встает необходимость радикального улучшения ситуации.

Основные подходы к автоматизации холдингов

В числе стоящих перед холдингами основных задач комплексной автоматизации бизнеса, решению которых может помочь внедрение единой глобальной КИС, можно указать следующие:

  • анализ, формализация и, если необходимо, оптимизация бизнес-процессов;
  • контроль и управление информационными потоками;
  • консолидация в центре информации из периферийных подразделений холдинга.
Перед руководителем (собственником) холдинга встает резонный вопрос: как эффективно решить в конкретных условиях своего предприятия эти задачи, несущие столь очевидные выгоды (о чем постоянно сообщают специализированные и околоспециализированные СМИ), и при этом не потерять средства, время и, что не менее важно, квалифицированный персонал?

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

  • заказчик - собственно сам холдинг как будущий владелец результатов автоматизации;
  • консультант - компания, осуществляющая методологическую поддержку проекта автоматизации;
  • внедренец - компания, непосредственно осуществляющая внедрение КИС согласно разработанной методологии;
  • поставщик - компания, осуществляющая поставки программного и аппаратного обеспечения КИС.
Разделение на роли в известной степени условное: реалии жизни демонстрируют различное соответствие ролей участникам проекта (заказчик может взять на себя роль консультанта; консультант, внедренец и поставщик также могут быть одной компанией). Наиболее верной практикой все же следует признать ситуацию, когда заказчик и консультант не являются аффилированными.

Итак, предположим, что мы имеем "правильную" ситуацию: стороны проекта автоматизации не являются зависимыми. Заказчик нанимает консультанта, на долю которого приходится самая важная часть работ проекта автоматизации - разработка методологии автоматизации. Именно верный выбор консалтинговой компании как создателя не менее верной, адаптированной под нужды конкретного предприятия, методологии внедрения часто определяет общий успех проекта автоматизации. Частью любой методологии должен являться концептуальный подход к автоматизации в части построения программно-аппаратной платформы КИС.

В настоящее время существуют два доминирующих подхода к автоматизации крупных бизнес-структур - революционный и эволюционный. Остановимся подробнее на каждом из них.

Подход первый - революционный

Данный подход подразумевает внедрение на базе одной из ERP-систем единой многофункциональной многомодульной КИС, охватывающей все подлежащие автоматизации бизнес-процессы предприятия. Внедряться может вся функциональность системы одновременно, помодульно или по организационным единицам холдинга. Подобные проекты внедрения длятся по несколько месяцев или даже лет, часто буксуют из-за внутреннего сопротивления, непонимания или нежелания со стороны персонала и/или руководства заказчика, а в конечном счете дают отрицательные результаты или приносят лишь частичный успех из-за методологических просчетов. По разным оценкам, в нашей стране от 50 до 70% всех инициированных проектов внедрения КИС либо заканчиваются полной неудачей, либо во многом не достигают поставленных целей (если таковые вообще были сформулированы перед началом проекта). И это притом, что проект внедрения КИС в крупном холдинге весьма затратный (бюджет может составлять десятки миллионов долларов, и львиную его долю - до 60% - порой "съедает" закупка лицензионного ПО КИС). Перед заказчиком также стоит непростая проблема выбора определенной ERP-системы в качестве платформы при построении КИС.

Революционность данного подхода заключается в следующем: внедряемая КИС, обладающая широкой функциональностью, фактически подменяет существующие в холдинге АСУ. То есть множество существующих разобщенных либо слабо связанных АСУ, условно говоря, выбрасывается, а на их место приходит одна, "тяжелая", но не имеющая проблем с интеграцией между модулями система. При этом декларируется, что организация вышла на новый качественно более высокий уровень зрелости IT. Насколько это соответствует действительности, зависит от степени успешности конкретного проекта.

Плюсами данного подхода можно признать:

  • внедрение единой целостной системы, что минимизирует затраты на интеграцию;
  • наличие у ведущих вендоров ERP-систем индустриально ориентированных производных решений с адаптированным под данную индустрию набором наиболее типичных бизнес-процессов, функций и настроек (решения для ТЭК, финансового сектора, сектора розничной торговли и т. д.). Подобные решения позволяют минимизировать трудозатраты на оптимизацию бизнес-процессов и настройку системы под нужды конкретного предприятия;
  • наличие достаточно проработанных и апробированных методологий внедрения, сетей бизнес-партнеров и обученных консультантов-внедренцев, что теоретически должно снижать риск неудачи внедрения - как правило, каждый производитель крупной ERP-системы имеет собственную методологию внедрения, которую и рекомендует к использованию (что, надо заметить, не мешает формировать упомянутую выше статистику по успешности внедрений);
  • вероятное сокращение расходов на IT в силу упразднения прежних разобщенных АСУ и высвобождения ресурсов, занятых на их поддержку;
  • наличие у ведущих ERP-систем развитых средств обмена, конвертации, архивирования и резервного копирования данных, удаленного доступа и формирования разнородной отчетности.
Существуют и минусы:
  • необходимость значительных единовременных инвестиций в IT;
  • довольно большая длительность проектов автоматизации, не позволяющая быстро получить результаты и оценить их;
  • отсутствие преемственности IT-инвестиций - инвестиции в IT, вложенные на протяжении многих лет, фактически теряются;
  • неявная привязка программно-аппаратного обеспечения к одному вендору-поставщику и предлагаемым им технологиям;
  • нередко возникающая необходимость подстройки бизнес-процессов предприятия под бизнес-процессы, предопределенные во внедряемой ERP-системе.
Отметим большие риски проектов внедрения крупных КИС на базе ERP-систем: при значительных финансовых и временных параметрах проектов заказчик не имеет возможности быстро оценить правильность направления движения и эффективность результатов. В силу этого шанс подтвердить неутешительную статистику собственным опытом весьма велик.

Успех проекта зависит от профессионализма участников проекта, от их опыта, способности предвидеть риски и качества управления проектом.

    По разным оценкам, в нашей стране от 50 до 70% всех инициированных проектов внедрения КИС либо заканчиваются полной неудачей, либо во многом не достигают поставленных целей

Подход второй - эволюционный

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

На сегодняшний день существует два основных типа интеграции разнородных корпоративных приложений (для общности предположений будем считать, что на предприятиях холдинга функционируют приложения, имеющие различные форматы представления и хранения данных):

  • интеграция приложений в рамках предприятия (Enterprise Application Integration, EAI);
  • интеграция приложений между предприятиями (Business-to-Business Integration, B2Bi). Учитывая то, что холдинг являет собой сложную организационную структуру, состоящую из нескольких компаний с различными бизнес-функциями и АСУ, при осуществлении комплексной автоматизации холдинга не избежать применения обоих типов интеграции. При этом надо понимать, что оба указанных типа не являются альтернативами, но представляют собой разные уровни интеграции - очевидно, что межкорпоративная интеграция является интеграцией более высокого уровня.
Интеграцию разнородных приложений можно осуществлять тремя способами:
  • на основе промышленных платформ интеграции приложений сторонних вендоров (таких как IBM WebSphere, BEA WebLogic или Microsoft BizTalk Server);
  • на основе собственных разработок;
  • смешанным путем - берем за основу промышленные платформы и самостоятельно дописываем необходимые интерфейсы.
Наиболее часто встречающийся вариант - третий, когда базовый функционал интеграционного сервера наращивается либо адаптируется в соответствии с требованиями предприятия посредством доработки собственными силами. Первый вариант, как правило, малопригоден в силу редкости совпадения "интеграционных нужд" предприятия и стандартной функциональности промышленных серверов интеграции. Второй вариант не слишком хорош для холдингов по ряду причин:
  • затруднительность создания собственного продукта, обладающего нужной функциональностью при необходимых характеристиках надежности, быстродействия и т. д., без крупных инвестиций;
  • отсутствие возможности постоянного развития системы с учетом появления новых IT-технологий и стандартов и/или обновления в рамках текущих (как правило, небольших по сравнению с бюджетами разработки и внедрения) IT-бюджетов;
  • промышленные платформы интеграции, как правило, имеют лучшие показатели TCO (Total Cost of Ownership, полная стоимость владения) и ROI (Return On Investment, возврат на инвестиции), нежели собственные разработки. Данные показатели крайне важны в силу обычно больших размеров холдинга и наличия возможности экономить на масштабах.
Остановимся подробнее на варианте третьем.

В качестве платформы интеграции используется один из промышленных интеграционных серверов, на который возлагаются функции объединения разрозненных АСУ и обработка основных массивов данных. АСУ предприятия дорабатываются так, чтобы беспрепятственно осуществлять передачу промежуточных либо конечных результатов своей работы интеграционному серверу. В условиях значительной территориальной распределенности рабочих мест крупного многофилиального холдинга наиболее эффективным методом "сращивания" существующих АСУ с интеграционным сервером сегодня представляется применение технологий Web-сервисов. Концепция Web-сервисов все еще довольно нова для применения на предприятиях нашей страны, однако уже несколько лет с успехом применяется на Западе.

Различные (практически любые) приложения, изначально общающиеся, образно выражаясь, на разных языках, за счет использования открытых, общепринятых стандартов Web-технологий, приводятся к "единому знаменателю", т. е. начинают говорить на одном языке.

С точки зрения сетевой топологии КИС в рамках холдинга может иметь два основных варианта:

  • наличие выделенного интеграционного сервера средней вычислительной мощности и сервера СУБД в каждом подразделении (дивизионе) холдинга, между которыми налажен обмен репликами БД по ЛВС для синхронизации используемого массива информации. Подобный вариант приемлем для холдингов, между подразделениями (дивизионами) которых нет интенсивного частого обмена информацией, т. е. подразделения в большой степени информационно автономны;
  • прикладные АСУ, используемые подразделениями холдинга, интегрируются с одним интеграционным сервером большой мощности (чаще - кластером серверов). Подобная схема оптимальна для многофилиальных холдингов, между подразделениями которых идет непрерывный обмен данными высокой интенсивности по оптоволоконным каналам большой пропускной способности.
Передача данных между подразделениями холдинга посредством Web-сервисов может происходить и через Интернет. Причем совершенно не имеют значения конкретные условия работы интегрируемых приложений: синхронность или асинхронность работы, используемая БД и форматы данных, операционная система и т. д.

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

  • общий бюджет и сроки реализации проекта значительно меньше, чем при внедрении многофункциональной КИС;
  • обеспечение преемственности инвестиций в IT;
  • резкое снижение расходов на лицензионное ПО за счет использования открытых стандартов и ПО с открытым исходным кодом, а также отсутствие привязки к вендору ПО и/или технологий (за исключением ПО интеграционного сервера).
Минусами являются:
  • недостаточная проработка методики построения распределенных интегрированных КИС (в т. ч. на основе Web-сервисов);
  • значительная вероятность зафиксировать при интеграции АСУ не вполне оптимальные бизнес-процессы и тем самым снизить общий эффект интеграции, т. к. не происходит взаимной "притирки" предопределенных и адаптированных под нужды конкретной индустрии бизнес-процессов внедряемой системы и бизнес-процессов, существующих на предприятии.
Таким образом, второй подход, образно говоря, более творческий, т. е. специалисты, проводящие комплекс работ по интеграции, практически не ограничены в реализации ни с технической, ни с методологической точки зрения. Однако в этом же кроется и основная проблема подхода - увеличение вероятности реализации рисков, связанных с закладкой в фундамент интегрирующей системы неоптимальных (либо просто неверных) бизнес-процессов, а это неизбежно нивелирует экономический эффект автоматизации.

Заключение

Было бы в высшей степени некорректно однозначно утверждать безусловную эффективность (или просто правильность) какого-либо из описанных выше двух подходов к автоматизации конкретной холдинговой структуры - общих критериев нет и быть не может в силу разнообразия контекста проекта автоматизации. В этой статье мы старались объективно показать как плюсы, так и минусы каждого из них. При этом, кроме методологических и технических вопросов, в проектах автоматизации необходимо также принимать во внимание степень готовности заказчика нести проектные риски, наличие политической воли к проведению изменений, уровень обеспеченности проекта ресурсами и некоторые другие сложноформализуемые, но весьма важные для успешности проекта автоматизации в целом аспекты.

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

[an error occurred while processing this directive]