Системный консалтинг 4 в 1

В современном мире информационные системы, автоматизирующие бизнес, – это сложнейший, состоящий из тесно связанных компонентов механизм. Фактически это тот же «самолет», пунктом назначения которого является достижение бизнес-целей компании. Однако порой мы наблюдаем, как компании внедряют отдельные системы, не имея в своем распоряжении общей схемы проекта, они безосновательно рассчитывают, что их «птица поднимется в воздух».

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

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

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

Шаг за шагом

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

По нашему мнению, для концептуального проектирования как нельзя лучше подходит парадигма так называемой архитектуры предприятия (Enterprise Architecture) – четко определенной практики для анализа и систематизации деятельности компании. Основным правилом при этом является автоматизация по принципу сверху вниз – от бизнес-целей к способам их достижения с помощью ИТ.

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

Рис. 1. «Серая зона» архитектуры

Затем разрабатывается функциональная архитектура. Шаги бизнес-процессов – функции – группируются в функциональные подсистемы, выявляются информационные потоки между ними. В результате формируются состав информационных систем и их функций, необходимых для автоматизации деятельности, схемы информационных потоков, функциональные и нефункциональные требования к системам.

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

Рис. 3. Пример функциональной архитектуры

По оценкам Deloitte Inc., наличие актуального описания архитектуры предприятия – «единой версии правды» о текущем и целевом состоянии компании в целом – дает возможность снизить затраты на ИТ-проекты на 15%.

Третий этап – разработка архитектуры приложений. На основании сформированных требований выбираются конкретные решения вендоров, разрабатывается карта программных компонентов и их взаимодействия (описание технологических платформ, интеграционных процессов, принципов межсистемного обмена). Подготавливается несколько вариантов архитектуры для выбора оптимального по соотношению «цена–качество». Для этого мы используем показатели качества, приведенные в табл. 1.

Табл. 1. Критерии выбора архитектуры приложений

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

По окончании проектирования формируется поэтапный план внедрения компонентов решения.

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

Рис. 4. Пример схемы концептуальной архитектуры приложений

Рис. 5. Пример диаграммы развертывания

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

Рис. 6. Пример концептуального плана внедрения

Еще одним примером использования методики является выбор системы управления персоналом для крупного российского онлайн-ритейлера – от описания бизнес-процессов «to be» и формирования требований к системе до предпочтения конкретного решения. Отметим, что основная сложность проекта заключалась в необходимости не просто описать процессы «to be», но и унифицировать их для трех разных компаний, не так давно вошедших в ритейловый холдинг.

Все идет по плану

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

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