Обзор методологий внедрения

Мы убедились, что основой планирования проекта является разработка фаз и перечня работ — иерархической структуры работ (ИСР). Фазы и их содержание сильно зависят от принятой методологии внедрения информационной системы (ИС). Между подходами есть много общего, но понимание различий и особенностей критически важно. Это позволит вам осознанно формировать фазы и включать только те работы, которые действительно полезны для вашего проекта.

Мы рассмотрим, из каких фаз состоят проекты и какие работы рекомендуют разные методологии: методологии Microsoft, компании PeopleSoft и Oracle. Вы увидите сходства и отличия. Также вы получите для самостоятельного изучения пример корпоративной методологии — как на базе вендорских методик компании создают свои внутренние стандарты.

Методологии Microsoft: OnTarget и MBS

Рассмотрим две методологии: OnTarget и Microsoft Business Solutions Partner Methodology (MBS). Обе изначально создавались для внедрения систем Microsoft на платформах Navision и Axapta. Их структура подходит для систем среднего класса, таких как «1С» или BEST. Сначала появилась OnTarget, а затем, как ее развитие, — MBS. Между ними есть идеологические и формальные различия, заметные уже в названиях и содержании фаз.

Сравнение первых и последних фаз

• OnTarget: начинается с фазы «Подготовка проекта», заканчивается «Опытной эксплуатацией».
• MBS: начинается с «Диагностики», заканчивается «Начальным сопровождением».

Это различие подчеркивает разные цели. OnTarget ориентирована на внедрение системы под четко сформулированные заказчиком требования. Считается, что заказчик точно знает, чего хочет, и проект планируется под реализацию этих требований.

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

Различия в целях и работах по этапам

1. Первая фаза: Подготовка (OnTarget) vs. Диагностика (MBS)

• OnTarget (Цель): Сформировать команду и проектную документацию.
o Работы: Предварительное планирование, разработка правил выполнения проекта, формирование команды. Это стандартные действия по управлению проектами.
• MBS (Цель): Понять потребности заказчика и способы их удовлетворения.
o Работы: Сбор информации о потребностях, анализ возможностей их удовлетворения. Эти блоки являются пакетами работ, которые в дальнейшем детализируются до уровня операций в ИСР.

2. Вторая фаза: Анализ (общее название)

• OnTarget (Цель): Подготовить команду проекта и разработать спецификации требований к системе.
• MBS (Цель): Детально проработать спецификации и понять, как они позволят удовлетворить бизнес-потребности заказчика.

Ключевое различие проявляется в обучении, которое проводят на этом этапе.

• OnTarget: Обучение рабочей группы проекту. Цель — научить их работать в проектной команде, использовать средства моделирования, формировать требования и взаимодействовать с разработчиками.
• MBS: Поверхностное обучение большого количества пользователей работе с системой. Цель — дать им «почувствовать» систему, чтобы они могли уточнить и грамотно сформулировать свои требования. Задачи, люди и цели обучения здесь совершенно другие.

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

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

3. Третья фаза: Дизайн (общее название, но разное содержание)

• OnTarget: Проектирование решения, результатом которого является техническое задание и эскизный проект (необязательный этап).
• MBS: Процесс дизайна делится на два подэтапа для решения проблемы коммуникации между бизнесом и ИТ.
1. Концептуальный дизайн: Описание задач и возможностей системы на языке бизнеса, понятном заказчику. Позволяет ему убедиться, что предлагаемые решения верны, и согласовать их.
2. Детальный дизайн: Формулирование требований к системе в технических терминах ИТ-специалистов для последующей реализации. На этом этапе уже есть уверенность, что функциональность соответствует потребностям.

4. Четвертая фаза: Разработка и тестирование

• OnTarget: Создание системы (разработка или настройка) и проверка ее работоспособности. Всё.
• MBS: Гораздо более широкий объем работ. Сюда входит не только создание и проверка функций, но и наполнение системы реальной информацией и проверка ее работоспособности на этих данных. По сути, на этой фазе создание продукта полностью завершается. Также в MBS появляется требование разделять среды разработки, тестирования и продуктивной эксплуатации, чтобы они не мешали друг другу и позволяли вести поэтапное внедрение для разных бизнес-процессов.

5. Пятая фаза: Развертывание (OnTarget) vs. Развертывание и завершение (MBS)

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

6. Шестая фаза: Опытная эксплуатация (OnTarget) vs. Начальное сопровождение (MBS)

• OnTarget: В развернутую и проверенную систему загружаются реальные данные. Проводится проверка ее работоспособности, устраняются выявленные недостатки, и только после этого проект закрывается.
• MBS: Проект уже закрыт. На этом этапе анализируется эффективность внедренного решения и ищутся пути его дальнейшей оптимизации, чтобы сделать его удобнее и эффективнее для заказчика.

Методологии OnTarget и MBS внешне похожи, но имеют принципиальные различия в содержании работ. Если посмотреть на развитие проекта во времени, OnTarget продвигается более интенсивно на ранних фазах. Эти методологии являются закрытыми и доступны только официальным партнерам Microsoft вместе с шаблонами документов и поддерживающим ПО.

Методология PeopleSoft (One Methodology)

Компания PeopleSoft была куплена Oracle, но внедрение ее продуктов (например, линейки JD Edwards) ведется по собственной методологии. Ее идеи отличаются от всего, что мы рассматривали ранее, и интересны для понимания альтернативных подходов.

Комплекс программ PeopleSoft включает как стандартные ERP-решения, так и специализированные продукты: CRM-системы (управление взаимоотношениями с клиентами), системы бизнес-аналитики (Business Intelligence, BI). Идеология методологии в том, чтобы подобрать для заказчика подходящий набор модулей из широкого спектра, проверить правильность выбора и затем уже разворачивать внедрение.

Этапы проекта по One Methodology

1. Определение рамок внедрения: Описание проекта: цели, рамки, подразделения, бизнес-процессы, содержание. По сути, создаются Устав проекта и документы, определяющие его границы. Важный акцент — определение интерфейсов с унаследованными и внешними системами, что характерно для модульного подхода.
2. Модель (Анализ и проверка): Детальный анализ деятельности компании и проверка того, как эта деятельность может поддерживаться имеющимися у разработчика инструментами. Определяются недостатки и составляется план доработок.
3. Конфигурирование (Пилотный проект): Реализуется пилотный проект на ограниченном объеме данных, рабочих мест и бизнес-процессов. Проверяется, подходит ли решение. Если да, выполняется ввод исходных данных, доработка ПО и разработка документации. На этом техническая часть проекта заканчивается, и система становится работоспособной.
4. Запуск в эксплуатацию: Детальная проверка созданной конфигурации. Здесь фокус смещается: на предыдущем этапе проверяли функционал, а здесь проверяют производительность системы под нагрузкой. Проводится подготовка пользователей.
5. Развитие: Анализ недостатков, выявленных при реализации. Ключевое отличие — оптимизация бизнес-процессов происходит на последнем этапе, уже с учетом реального опыта эксплуатации системы. Обычно процессы оптимизируют до автоматизации (модель «как должно быть», TO-BE). Здесь же автоматизируют существующую деятельность («как есть», AS-IS), а улучшают ее потом, что снижает риск ошибок, сделанных без опыта работы с системой.

Методология Oracle (Application Implementation Method, AIM)

Компания Oracle уделяет огромное внимание методическому обеспечению. Метод Oracle (Oracle Method) охватывает множество дисциплин, от управления изменениями и проектами до разработки ИТ-стратегии и архитектуры предприятия. Архитектура предприятия — это способ целостного описания компании во взаимосвязи ее бизнес-процессов, информационных систем и ИТ-инфраструктуры. Нас интересует метод AIM (Application Implementation Method) — метод внедрения приложений.

Общая схема AIM строится на здравом смысле:
1. Понять, как осуществляется деятельность заказчика.
2. Определить, какие средства Oracle могут ее поддержать.
3. Детально описать деятельность и отобразить (маппировать, mapping) ее на функциональность приложений.
4. Провести демонстрацию решения на основе библиотеки типовых проектных и отраслевых решений.
5. Провести GAP-анализ — анализ разрывов между требуемым и имеющимся функционалом.
6. Решить, что выгоднее: адаптировать бизнес или дорабатывать ПО. Если доработка слишком дорога, воздействуют на бизнес-процессы; если приемлема — реализуют. Доработки, с точки зрения Oracle, должны быть небольшими изменениями модулей.

Методология AIM состоит из задач. Каждая задача имеет вход и выход (документ, настройка, код). Задачи сцепляются в цепочки (процессы) для решения конкретных проблем.

Фазы и процессы внедрения по AIM

Фазы проекта стандартны: Определение, Анализ операций (детальный анализ автоматизируемой деятельности), Разработка решения, Создание решения, Переход на новое решение и Продуктивная эксплуатация.

На протяжении этих фаз выполняется ряд сквозных бизнес-процессов внедрения:
• Определение бизнес-требований: Ключевая особенность — требования, определенные на первых этапах, не расширяются в дальнейшем. Это обеспечивает стабильность проекта.
• Отображение требований (маппирование): Проводится GAP-анализ, фиксируются несоответствия, определяется, что нужно доработать. Отсюда возникают функциональная и техническая архитектуры.
• Разработка дополнительной функциональности: Допрограммирование, если оно экономически обосновано.
• Конвертация данных: Определение того, какую информацию из каких унаследованных систем переносить в новую, какими средствами (программно или вручную).
• Документирование: Разработка документации.
• Тестирование (функциональное и производительности): Начинается с самых первых фаз. На старте тестировщики проверяют корректность архитектуры и взаимосвязей. Тесты пишутся заранее на основе сценариев использования системы (прецедентов), которые описываются на этапе анализа операций.
• Обучение: Состоит из двух частей:
1. Подготовка проектной группы в начале проекта.
2. Обучение конечных пользователей в конце.
• Ввод в эксплуатацию: Закрытие проекта.

Важный нюанс: работа с Oracle требует использования собственного средства для описания бизнес-процессов (основанного на DFD-диаграммах, где отражаются все документы и их атрибуты), а не привычных инструментов вроде IDEF0 или ARIS.

Управление проектом в AIM

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

Состав команды, по AIM, строится вокруг консультантов по внедрению — специалистов, обладающих знаниями и опытом одновременно в бизнес-процессах, в управлении проектами внедрения и в самой ИС. Также могут привлекаться сторонние эксперты. Это отличается от детального ролевого описания, характерного для Microsoft Solutions Framework (MSF).

Корпоративная методология внедрения (пример)

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

Рассмотрим пример компании, внедрявшей системы Microsoft (Navision, Axapta) и связанные с ними решения по бюджетированию.

• Структура фаз и процессов здесь очень близка к Oracle AIM. Фазы фактически те же, что и в AIM, но добавлены специфические процедуры предварительного планирования и обязательного завершения проекта с фиксацией накопленного опыта («извлечение уроков»), что характерно для MSF.
• Организационная структура управления проектом может быть двух типов:
1. Центр ответственности на исполнителе: Ключевые менеджеры (по функциональности, по технологиям разработки, по бизнес-процессам) — представители компании-внедренца.
2. Центр ответственности на заказчике: Ответственность за организацию и управление возлагается на представителей заказчика.
• Команда проекта делится на группу управления и группу исполнения. В группе исполнения работают бизнес-аналитики. Бизнес-аналитик здесь — специалист, способный построить модель бизнес-процесса, оценить его эффективность, предложить модификацию и понять, как его автоматизировать. Грань между ИТ- и бизнес-консалтингом здесь очень тонка.

Таким образом, корпоративная методология на уровне описания фаз и работ переходит от цепочек задач, жестко привязанных к продукту (как в AIM), к простому перечислению пакетов работ, как в OnTarget и MBS. Эти пакеты затем детализируются до операций.

Краткие итоги

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

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

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

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