Обычный путь российской компании средних размеров – начать автоматизацию управления с бухгалтерии, отдела кадров и документооборота, затем перейти к производственным и коммерческим бизнес-процессам. Наконец, возникает большой соблазн получить абсолютно интегрированную систему, которая объединит все в «единое информационное пространство».
Конечно, не существует общих рекомендаций по выбору уровня интеграции. Руководство каждой компании самостоятельно решает этот вопрос, исходя из своих потребностей и ресурсов. Статья о том, что риск вынужденной реорганизации бизнеса в связи с внедрением интеграционных решений не «сопутствующий», а достаточно высокий. Настолько высокий, что его нужно учитывать в качестве основного.
Что дает интеграция
Традиционные методики расчета эффекта от автоматизации известны многим руководителям и являются основными аргументами при выделении бюджетов. Сложность заключается в том, что рост эффективности автоматизации «глохнет» на стыках, при обмене информацией между подразделениями.
При отсутствии интегрирующего программного обеспечения используются «древние технологии» вроде распечаток на бумаге с повторным вносом данных, экспортом/импортом через электронные таблицы или «лоскутные» решения. Обмен данными становится самым узким участком и определяет общую производительность IT в рамках предприятия. Поэтому, с точки зрения экономики, подход к обоснованию актуальности интеграции между подразделениями почти идентичен обоснованию автоматизации подразделений. Цель – повышение эффективности.
Однако, стоимость интеграции зачастую выше стоимости автоматизации. Поэтому может оказаться, что интегрированные IT-решения невыгодны экономически. Для малых предприятий интеграция почти всегда убыточна, средний бизнес балансирует на пределе окупаемости интеграционных проектов, и только в крупном бизнесе интеграция дает существенные технологические преимущества.
На практике построение единой, высоко интегрированной КИС (корпоративной информационной системы) часто становится самоцелью для IT-специалистов, вне зависимости от масштаба компании, ее бизнес-целей и экономической целесообразности. В IT-сообществе польза высокоинтегрированных КИС редко подвергается сомнению. И зря, потому что их эффективность сильно зависит от контекста.
Интеграционные технологии
По сути, в IT есть два основных подхода к интегрированию:
1) Монолитные информационные системы.
2) Интеграционная шина предприятия.
Термин «монолитные ИС» применяется для систем с широким перечнем функций (почти ERP), но все же ограниченных сферой применения среднего бизнеса. Технически проблем с интеграцией в них не существует, благодаря использованию единой базы данных, в которой хранится абсолютно вся информация. Примерами таких систем являются решения на платформах 1С, «Галактика».
Монолитные системы обладают рядом недостатков, связанных с обновлением и скоростью работы. Кроме того, не все компании, выросшие из малого бизнеса, готовы отказаться от годами развиваемых собственных ИС и внедрить «чужое» монолитное ПО.
Интеграционная шина позволяет наладить обмен данными между различными ИС и создать централизованное хранение для всех справочников. Технология интеграционной шины может быть внедрена самостоятельно или приобретена в составе готовых IT-решений SAP, Microsoft и других разработчиков, предлагающих автоматизацию для крупного бизнеса. Наличие интеграционной шины решает техническую IT-задачу интеграции, но не обеспечивает интеграции бизнес-процессов. Если в случае с монолитными системами такой задачи не существует, то при связывании различных ИС с помощью интеграционной шины нужно самостоятельно проектировать систему справочной информации (проще говоря, единую базу данных), разрабатывать процедуры записи и обновления информации и т.д. Все это весьма трудоемко и как следствие дорого – что наверняка не подходит ни малому, ни среднему бизнесу.
Уровни интеграции
Интеграция может рассматриваться как механизм передачи информации в сквозном бизнес-процессе с участием нескольких подразделений. Технически возможны следующие варианты:
1) Подразделения используют единую КИС, единые справочники и документы. Это означает, что интеграция полностью выполнена.
2) Автоматическая интеграция – когда ИС без участия человека синхронизируют справочники и документы с использованием сервисной шины предприятия и подсистемы НСИ (нормативно-справочной информации).
3) Автоматизированная интеграция – когда автоматически синхронизируется справочники, а документы переносятся с участием сотрудников.
4) Полуавтоматизированная интеграция – справочники и документы переносятся с участием сотрудников.
5) Ручная интеграция – информация распечатывается и заново вносится в другую ИС.
Трудозатраты, связанные с переносом данных, растут от пункта 1 к пункту 5. Соответственно, замедляются сквозные бизнес-процессы между подразделениями. То есть первые варианты – лучшие с точки зрения IT и de facto являются стандартом построения интегрированной КИС. С другой стороны, они же являются самыми дорогими. Причем не только по внедрению. В худшем случае автоматическая интеграция может привести к структурным противоречиям.
Интеграция против организационной структуры
При формировании организационной структуры сильно связанные функции группируются в рамках подразделений. Понятие связности, взятое из теории структурного программирования, показывает, насколько задачи зависят друг от друга. Это может быть функциональная или информационная связь, временная или логическая и т.д. Связность задач внутри подразделения всегда выше связности задач между подразделениями.
При построении структуры бизнес-процессов связность также является основополагающим фактором. Бизнес-процесс может начинаться с поступления сырья и заканчиваться за воротами предприятия, но в таком длинном (сквозном) виде он будет неудобочитаем. Поэтому его разбивают на подпроцессы, руководствуясь связностью. Таким образом, именно связность между задачами определяет, как происходит разбиение сложной системы на подсистемы и формирование структур.
Интеграция высокого уровня меняет связность между задачами, что приводит к необходимости реорганизации структур.
При отсутствии интеграции передача информации между подразделениями происходит через руководителя подразделения в ручном или автоматизированном режиме. На практике руководитель делегирует задачу передачи информации, но сути это не меняет. Подразделение владеет информацией, полностью отвечает за релевантность и целостность, контролирует ее передачу наружу.
Благодаря интеграции обмен данными между подразделениями существенно ускоряется, поэтому можно классифицировать такое взаимодействие как сильно связное. Подобная связность больше, чем внутри подразделения, так как отсутствует какой-либо контроль со стороны подразделений. Сложно однозначно определить, кто владеет общей интегрированной ИС двух подразделений, необходимо дополнительно проговаривать и контролировать данный вопрос.
Итак, интеграция перекраивает организационную структуру и перестраивает бизнес-процессы – что вызывает недовольство у руководителей подразделений. Вынужденная перестройка организационной структуры плохо управляема, сложна, и непонятно будет ли вообще полезной для организации. Поэтому иногда лучше специально понижать уровень интеграции, переводя ее в ручной режим управления.
Владение справочниками
Если в ситуации до интеграции у каждого подразделения свои данные в ИС, то в ситуации после картина кардинально меняется. Как правило, документы, хранящиеся в ИС подразделений и передаваемые в рамках интеграционного обмена, описывают факты хозяйственной деятельности и привязаны к бизнес-процессам. Не возникает проблем с тем, кто изменил документ, системы четко фиксируют все изменения, в рамках бизнес-процесса всегда ограничены возможности сотрудника изменять документ.
В ситуации со справочниками ситуация более сложная. Функция контроля за ведением справочников, корректностью ввода, отсутствием дублей должна быть закреплена за кем-то особо. То есть владение справочником является еще одним атрибутом «власти». Полномочия по справочникам не должны идти вразрез с организационной структурой.
Например, IT в малом российском бизнесе, как правило, начинается с автоматизации бухгалтерии и кадрового учета. Финансовое руководство логично становится владельцем всех информационных баз компании. Затем, когда компания растет до уровня среднего бизнеса (что может происходить довольно быстро, за считанные годы), появляется полноценная IT-служба. Ее руководитель, избегая лишних согласований и конфликтов с «финансистами», обычно создает параллельную структуру пользователей, номенклатур, контрагентов.
Стратегия интеграции
Фактически, существует всего три стратегии построения единой КИС:
1) Внедрение готовой интегрированной КИС. Путь технологически наиболее правильный, сулящий максимальный эффект – и самый затратный. Подходит для крупного бизнеса, когда наведение порядка производится «любой ценой» (можно и без кавычек).
2) Поэтапное построение КИС с единой базой справочников. Это ловушка, в которую попадает большинство компаний из самых лучших и, на первый взгляд, здравых предпосылок. Опасность заключается в катастрофической недооценке рисков централизации справочников. По сути, проект изначально не «айтишный», поэтому выполнить его в рамках IT невозможно.
3) Поэтапное построение КИС с децентрализованной базой данных. Наиболее безболезненный и перспективный подход, так как он позволяет компании с помощью «лоскутной интеграции» постепенно созреть до уровня полноценного комплексного решения.
Можно смело сказать, что у растущего бизнеса выбора стратегии не существует. Начинать интеграцию следует только с третьего, самого «скромного» варианта. После достижения достаточно высокой степени заинтересованности и взаимопонимания руководителей на всех ключевых уровнях управления компанией можно сделать серьезный шаг и переходить ко второй стратегии; либо, при наличии достаточных ресурсов и резервов – к третьей.
Выводы
Руководство компании должно осознавать, что интеграция не относится к категории типичных IT-задач. Это дорогое удовольствие и зона ответственности топ-менеджмента. IT-сообщество часто манипулирует понятием интеграции, суля баснословный рост эффективности. В то же время IT-директора не способны брать на себя всю полноту ответственности за растущие издержки (вместо их оптимизации), особенно за необходимость изменения бизнес-процессов.
При решении задач интеграции нужно учитывать существующее распределение сфер влияния на бизнес-процессы, справочники и данные, которое отражается в организационной структуре. Нужно внимательно следить, чтобы слишком хорошая интеграция не перекраивала бизнес-процессы и в некоторых случая интеграцию намеренно «ухудшать», переходя на ручной режим управления.
Я не призываю отказаться от интеграции как таковой, всего лишь предлагаю внимательнее относиться к этому инструменту. Потребности в интеграции должны быть продиктованы руководством компании. Не стоит бежать впереди паровоза и внедрять чрезмерно перспективные решения.
Редактор рубрики «IT для бизнеса» – Сергей Соловьев
Евгений Любимов пишет: ''При решении задач интеграции нужно учитывать существующее распределение сфер влияния на бизнес-процессы, справочники и данные, которое отражается в организационной структуре.''
Согласен. Нужно! Еще как нужно!
Можно даже расширить перечень того, что нужно учитывать «при решении задач интеграции» Более того, даже можно опустить в начале утверждения слова : «При решении задач интеграции ». Всё равно первая часть утверждения останется верной.
Вот только далеко не все, что «нужно учитывать» «отражается в организационной структуре». Руководство компании будет разочаровано, когда осознает этот печальный факт. Было бы правильно сказать, что все это отражается в описании Архитектуры Предприятия, только Руководству предприятия от этого не станет легче «учитывать существующее распределение сфер влияния». Но, может быть оно [Руководство] осознает, что не надо стремглав бросаться осуществлять даже самые правильные и авторитетные рекомендации - сначала надо проверить текущие состояние предприятие на соответствие тех условий, при которых эти рекомендации осуществимы за разумное время и деньги.
Считаю, что не внедрение интеграционных решений должно приводить к необходимости реорганизации процессов, а наоборот, потребность в реорганизации процессов приводит к необходимости создания дополнительных интеграционных швов. Вряд ли руководитель компании беспокоится о том, как ему интегрировать ИС отдела продаж с ИС производственников. Его скорее беспокоят сложности во взаимодействии этих подразделений и скорость реакции на запрос клиента.
В чем согласен с Евгением, так это в том, что подобные задачи (все-таки назову их задачами выделения сквозных бизнес-процессов, включающими в себя в т.ч. и задачи интеграции) далеко не IT-шные и не могут быть выполнены без сильной административной поддержки.
А что касается стратегии - интегрированные КИС на сегодня доступны не только крупному бизнесу. Существуют решения, подходящие как для среднего, так и для малого бизнеса. В ситуациях, когда встает выбор между системой, которая поддержит процессы без создания интеграционных швов, и несколькими системами, которые придется интегрировать, я почти всегда склоняюсь к первому варианту.
Знаете что интересно, что говоря о эффективности и интеграции, и о прочем. никто не учитывает интересы потребителей... и никто реально не задавался вопросами возникновения кризисов... Или вот везде, особенно тут говорят про передовой опыт США... при этом не изучая вопросов опустевшего Детройта... Но сначала о БМВ... Дизайнеры (исходя из потребностей моды и красоты) создают новую модель скульптор воплощает в форму, конструктора реализуют конструктив, исходя из потребностей рынка... Далее автоматизированное производство... Машиностроительный Детройт, занимаясь ( видимо бухгалтерско-финансовой ) интеграцией, упустил главное - дизайнеров и конструкторов, ну и конечно рынок... Да что говорить, если дизайнеров упустили даже некоторые Американские игровые компании... Можно сколько угодно вваливать в интеграцию, автоматизацию и даже иностранных топ менеджеров, но если товар не интересен, то его не купят... Отечественная военка, стала поступать разумно... и результаты видят все... - это как пример интеграций...
Исхожу из того, что большинство интеграционных швов, с которыми приходится сталкиваться у клиентов, напоминают ''поделки'' школьников и начинают сбоить при увеличении передаваемых объемов информации. Кроме того, возникает зависимость от автора ''поделки'', поскольку малейшее изменение в структуре передаваемой через шов информации не может сделать никто, кроме автора - невозможно разобраться. Вот и получается, что сопровождение швов встает в ''регулярную копейку''.
Да, конечно, бывают очень продуманные и качественные интеграционные решения. Чаще всего это решения, разработанные самими вендорами ПО, причем крупными вендорами. На такие решения можно спокойно опираться при построении КИС. Но вендоры обычно прорабатывают только те интеграционные швы, которые встречаются наиболее часто. Например, Майкрософт задумавается о том, как синхронизировать их outlook-календари с другими календарями, 1С думает о том, как информации о начислениях зарплаты передаются из базы для учета кадров в базу бухгалтерии.
Когда Вы, Евгений, говорите о том, что интеграционные решения должны быть еще гибче, немного непонятно, от кого это требовать.
Коллеги прошу обратить внимание, что в статье я не делал упор на технологию интеграции. Вопрос не стоит интегрировать или не интегрировать. Конечно, интегрировать! Вопрос в том, что интегрируя, мы изменяем бизнес-процессы, меняем организацию и это никому не нравиться.
Почему-то никто не пишет в публикациях, что на таком-то уровне зрелости бухгалтерию можно интегрировать с кадрами или складом, а вот здесь стоит повременить. Или проведите вот такой тест и посмотрите готово ли руководство и владельцы бизнеса к интеграции. Нам (ИТ специалистам) удобней говорить о том, что нравиться, то есть какая отличная штука «интеграция». Это подчеркивает некоторую не зрелость и не понимание бизнес целей ИТ руководителями.
Многие знакомы с SOA архитектурой. Основная проблема в том, что в момент принятия решений о ее внедрении почти нет аргументов в ее пользу. Нужно потратить кучу денег и переделать все старое накоплено, а результат мы увидим через 5-7 лет, когда будет очередной цикл обновления ПО. И как тут считать эффективность? Руководство компании меняется чаще, чем ПО.
SOA находит хорошо применение, когда без нее не реально обойтись. Не разумно строить, что-то самому, когда уже есть готовое решение, если вы создаете новый транснациональный бизнес. Однако барьер для применения этих технологий велик и часто непреодолим для уже существующего среднего бизнеса.