Введение

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

Обзор

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

Другие виды усыновления

Помимо параллельного внедрения, можно выделить еще три общих типа внедрения. Выбор конкретного метода зависит от организационных характеристик; более подробная информация по этой теме будет представлена ниже. Эти три метода внедрения:
Big Bang Adoption/Plunge Adoption (Внедрение «Большой взрыв»/Резкое внедрение): Внедрение «Большой взрыв» подразумевает перенос всей организации со старой системы на новую системой единовременным переходом. Это самый дешевый вариант, но в случае сбоя новой системы организация столкнется с серьезными проблемами. Также существует риск непринятия системы пользователями. Однако это может быть единственным подходом, если две системы не могут сосуществовать или активация новой системы является критически важной. Поэтапное внедрение (также известное как постепенная конверсия): При поэтапном внедрении организация постепенно переходит на новую систему, поэтапно, по модулям или подсистемам. Некоторые системы невозможно внедрять по частям из-за их сильной зависимости от всей системы в целом. Поэтапное внедрение сопряжено с меньшими рисками, но вызывает наибольшие сбои из-за длительности перехода со старой системы на новую. Пилотное внедрение: Метод пилотного внедрения используется для крупных организаций с множеством филиалов или в значительной степени независимых подразделений. Новая система внедряется в одном из филиалов или подразделений и со временем распространяется на другие. (ограниченный масштаб в случае сбоя новой системы) (Turban, 2002)
Существуют ситуации, когда параллельное преобразование нельзя рассматривать как жизнеспособную стратегию. Во-первых, следует учитывать, содержит ли новая система значительные изменения схемы данных. Отсутствие необходимых элементов данных в одной из систем может привести, в лучшем случае, к неточности данных, а в худшем – к их повреждению. Другая проблема возникает, если система использует готовое программное обеспечение (COTS). Если в документации поставщика COTS указано, что несколько приложений не могут совместно использовать одну и ту же базу данных, то параллельное преобразование невозможно. Примером могут служить продукты Siebel от Oracle. Другие продукты COTS также могут накладывать ограничения, когда для установки исправлений или основных обновлений требуются уникальные лицензионные ключи. После применения они могут вносить изменения в базу данных, из-за чего приложение может ошибочно определять наличие параллельной системы, работающей с той же базой данных, как попытку обхода лицензионного контроля и, таким образом, отключать систему.

Место в процессе реализации

Кажется, что в отношении процесса параллельного внедрения существует немного устоявшихся норм. В нескольких источниках (например, Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999) не используется единое название для описания этого процесса. Термин "параллельное внедрение" используется в этих источниках, хотя и обозначается по-разному в каждом из них: параллельное преобразование, параллельная работа, теневое сопровождение, параллельный переход и параллельная реализация. Это, вероятно, связано с тем, что общее описание процесса не требует чёткой классификации. Существует ряд стандартных методов реализации, в которых описываются различные техники внедрения, но часто в практическом контексте – на примере реальных сценариев или в рамках более комплексных методик, таких как Regatta: метод внедрения, SIM и PRINCE2. В целом, параллельное внедрение лучше всего рассматривать как метод системной инженерии для внедрения новой системы. По сути, метод параллельного внедрения отличается от решения о смене системы в организации и может рассматриваться как один из возможных способов достижения этой цели. Однако при определении оптимальной стратегии реализации учитывается множество факторов. Более того, успех внедрения во многом зависит от выбранной техники внедрения (Lee, 2004).

Процесс

Параллельный процесс внедрения не может быть представлен без учета этапов, предшествующих фактическому преобразованию, а именно разработки сценария преобразования и идентификации и тестирования всех требований. Поэтому процесс объясняется последовательным рассмотрением всех выявленных процессов, представленных на рисунке 1, с кратким обзором общих действий, необходимых для любой из идентифицированных стратегий преобразования. Рисунок 1 дает обзор параллельного процесса внедрения. Левая сторона отображает поток действий, способствующих процессу. Действия, выполняемые одновременно, предваряются толстой черной линией. После завершения параллельного выполнения действий они вновь соединяются аналогичной черной линией. Отсутствие стрелки от одного действия к другому указывает на то, что они являются агрегатами более крупного действия, расположенного выше. Действия разделены на четыре основных фазы: определение стратегии внедрения, которая определяет, какая стратегия внедрения должна быть реализована; предварительная реализация, связанная с разработкой плана всех аспектов и требований, связанных с реализацией; подготовка организации, которая требует надлежащей подготовки организации в соответствии с предыдущей фазой; и преобразование, включающее сам процесс преобразования и его завершение, а также переход к новой системе. Основные фазы подразделяются на другие действия, которые будут кратко описаны в таблицах 1.1 – 1.4. Правая сторона модели описывает данные, участвующие в процессах. Некоторые из этих концепций, представленные парой перекрывающихся открытых прямоугольников, могут быть подразделены на более чем одну концепцию. Пара перекрывающихся закрытых прямоугольников указывает на закрытую концепцию, что означает, что она может быть разделена на более мелкие концепции, но не представляет дальнейшего интереса для параллельного процесса внедрения. Фигура в форме ромба указывает, что связанная с ней концепция служит агрегированной концепцией и состоит из других концепций. Наконец, открытая стрелка представляет собой отношение "суперкласс-подкласс". Концепция, связанная со стрелкой, является суперклассом концепций, связанных с ней. Синтаксис на рисунке 1 соответствует стандартам Unified Modeling Language (UML). Концепции на рисунке 1 определены в таблице 2. Более подробный контекст этих поддействий в процессе будет представлен ниже таблиц.

таблица 1.1: Предварительная реализация

| Действие | Описание |
|---|---|
| Определить стратегию внедрения | Стратегия внедрения определяется на этом раннем этапе. (Brown, Vessey, 1999) |
| Создать основной сценарий внедрения | Проводится первый первоначальный анализ требований, состоящий из нижеперечисленных требований. (Venture, 2004) |
| Разработать временной план | Впервые разрабатывается временной план процесса внедрения. (Rooijmans, 2003) |
| Определить организационные требования | Здесь определяются организационные требования. (Rooijmans, 2003) |
| Определить ИТ-требования | Определяются ИТ-требования. (Rooijmans, 2003) |

таблица 1.2: Подготовка организации

| Действие | Описание |
|---|---|
| Установить требования | Для подготовки организации устанавливаются определенные требования. Организация готовится, а ИТ устанавливается на тестовые машины. (Rooijmans, 2003, Eason, 1988, Microsoft, 2004) |
| Протестировать требования | Требования тестируются, чтобы определить, готова ли организация к внедрению. (Rooijmans, 2003) |
| Уточнить основной сценарий внедрения | Основной сценарий внедрения уточняется с учетом новой информации, полученной в процессе с помощью следующих действий. (Rooijmans, 2003) |
| Определить критерии-индикаторы | Для тестирования новой системы создаются критерии-индикаторы. (Rooijmans, 2003, Microsoft, 2004) |
| Сформулировать план обхода/отката | Также разрабатывается план обхода с сценарием отката. С помощью этих планов организация может соответственно попытаться исправить допущенные ошибки и вернуться к предыдущему состоянию, если внедрение на определенном этапе процесса не удастся. (Microsoft, 2004, Rooijmans, 2003) |
| Выполнить (сегментальное) тестовое преобразование | В очень сложных организациях может быть полезно провести тестовое преобразование перед переходом к "живой работе". (Microsoft, 2004, Rooijmans, 2003) |

таблица 1.3: Преобразование

| Действие | Описание |
|---|---|
| Догнать отставания | Процесс преобразования начался, ряд действий выполняется параллельно. На этом этапе происходит догонка по старой системе. Старая система лидирует, но новая работает параллельно. Все изменения в системе должны быть внесены в новую систему. (Microsoft, 2004, Rooijmans, 2003) |
| Контроль системы | Система постоянно контролируется системой контроля. С помощью определенных индикаторов и характеристик работы системы отслеживаются ошибки и недочеты. (Microsoft, 2004, Rooijmans, 2003) |
| Запустить лидирующую старую систему | Старая система лидирует, обрабатывая фактические данные. |
| Запустить новую систему | Новая система работает параллельно со старой и находится под пристальным наблюдением. (Microsoft, 2004, Rooijmans, 2003) |
| Перенести отставания в новую систему | Если критерии выполнены, отставания переносятся и передаются в новую систему, и процесс преобразования переходит к следующему этапу. (Microsoft, 2004, Rooijmans, 2003) |
| Выполнить стратегию обхода/отката | Если критерии не выполнены, выполняется стратегия обхода или отката, в зависимости от характера ошибок. (Microsoft, 2004, Rooijmans, 2003) |
| Догнать отставания | Отставания догоняются в целях безопасности, даже когда новая система лидирует. (Microsoft, 2004, Rooijmans, 2003) |
| Запустить старую систему | Старая система работает в качестве резервной, в целях безопасности. |
| Запустить лидирующую новую систему (1) | Новая система лидирует и находится в полном функционировании. Все транзакции и изменения в системе обрабатываются здесь. (Microsoft, 2004, Rooijmans, 2003) |

таблица 1.4: Завершение параллельного внедрения

| Действие | Описание |
|---|---|
| Запустить лидирующую новую систему (2) | Все отставания и проверки закрываются. Новая система является единственной работающей системой. (Microsoft, 2004, Rooijmans, 2003) |
| Отключить старую систему | Старая система больше не нужна и отключается. (Microsoft, 2004, Rooijmans, 2003) |

Концепции из рисунка 1 определены в таблице 2.1 ниже.

таблица 2.1: Список определений концепций

| Концепция | Определение |
|---|---|
| Стратегия внедрения | Стратегия, которая будет выбрана для внедрения новой системы. Варианты: "большой взрыв", поэтапное, параллельное внедрение, пилотное преобразование или комбинация этих четырех. (Turban, 2002, Rooijmans, 2003) |
| Сценарий внедрения | Черновой вариант фактического сценария преобразования, состоящий из организационных требований, ИТ-требований и первоначального временного плана. (Venture, 2004, Eason, 1988) |
| Организационные требования | Требования внутри организации, которые должны быть выполнены для успешного внедрения. Они связаны с оптимизацией (изменением) организации для новой системы. Возможные вопросы: управление персоналом, изменение организационных схем и новые бизнес-структуры. (Rooijmans, 2003) |
| ИТ-требования | Требования к информационным технологиям - это требования к программному и аппаратному обеспечению, выбору платформы с учетом бюджета и существующих систем. (Rooijmans, 2003) |
| Временной план | План, в котором мероприятиям назначается временной период, в течение которого они должны быть завершены, обеспечивая общий обзор проекта внедрения с точки зрения доступного времени. (Eason, 1988) |
| Соответствие требованиям | Соответствие требованиям - это соответствие требованиям. (ISO 9000) |
| Сценарий преобразования | Уточненный сценарий внедрения с учетом соответствия требованиям. Кроме того, сценарий преобразования состоит из плана обхода и отката. Сценарий преобразования является планом проекта внедрения. (Rooijmans, 2003) |
| Стратегия обхода | Резервный план; стратегия, применяемая в сценарии преобразования для предотвращения ошибок в процессе преобразования и попытки обойти их, чтобы внедрение все же могло быть успешным. (Rooijmans, 2003) |
| Критерии-индикаторы | Количественные и измеримые критерии в отношении требований для определения успешности процесса внедрения. (Rooijmans, 2003) |
| Откат... |

Определение стратегии параллельного осуществления

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

Риск и затраты

Причиной выбора параллельного внедрения вместо пилотного преобразования, подхода "большого взрыва" или поэтапного внедрения часто является компромисс между стоимостью и риском (Andersson, Hanson, 2003). Параллельное внедрение – наиболее дорогостоящий метод внедрения (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), поскольку оно требует от организации одновременной работы двух систем в течение определенного периода. Одновременная работа двух систем означает необходимость инвестиций в человеческие ресурсы. Помимо надлежащей подготовки (дополнительного) персонала, который должен пройти через напряженный период параллельной работы, когда процедуры пересекаются и взаимодействуют. (Rooijmans, 2003, Eason, 1988) Необходимо приложить усилия для обеспечения целостности данных и предотвращения их повреждения между двумя системами (Chng et al. 2002, Yusuf, 2004). Это касается не только самого процесса преобразования, но и обучения персонала работе с новой системой. Если необходимо внедрить новую систему методом "большого взрыва", риск неудачи высок (Lee, 2004). Если организация сильно зависит от изменений в старой (устаревшей) системе, компромисс между дополнительными затратами на менее рискованный параллельный подход должен быть в пользу этих затрат (Lee, 2004). Однако мы видим, что внедрение ERP в большинстве случаев происходит методом "большого взрыва" (Microsoft, 2004, Yusuf, 2004). Это означает, что организация должна тщательно продумать свою стратегию внедрения и интегрировать это решение в анализ управления рисками или управления изменениями.

Требования к ИТ

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

Планирование времени

Очень важно иметь подробный план внедрения новой системы в организации (Lee, 2004, Eason, 1988). Самое важное в планировании времени при параллельном переходе – не спешить и не бояться возможных задержек на этапе фактического перевода. (Lee, 2004). Также может быть очень полезно работать с четко определенными вехами (Rooijmans, 2003), подобными используемым в методологии PRINCE2. Дополнительную информацию о планировании времени можно найти в разделах "Планирование" и "Стратегическое планирование".

Оценка требований

Оценка требований включает в себя переопределение плана реализации. Необходимо протестировать сформулированные ИТ- и (по возможности) организационные требования. Некоторые тесты могут быть проведены для оценки как организационных обязанностей (Rooijmans, 2003), так и ИТ-требований. Здесь вновь важно заручиться поддержкой и вовлеченностью высшего руководства (Eason, 1988). Если высшее руководство не выделит ресурсы для оценки, внедрение может оказаться безуспешным. После этой оценки план реализации перерабатывается в более детальный сценарий преобразования.

Сценарий конверсии

Таким образом, сценарий перехода представляет собой план организационных изменений во всех аспектах. Однако есть две темы, которым еще не уделено должного внимания в рамках параллельного внедрения. Стратегия обхода / план отката: в отличие от других сценариев внедрения, в сценарий перехода также интегрирована стратегия обхода или план действий в чрезвычайных ситуациях с планом отката. Стратегия обхода определяется в более широком контексте в другом документе, но в данном случае она означает, как указано в вышеприведенной таблице: резервный план; стратегия, применяемая в сценарии перехода для предотвращения ошибок в процессе преобразования и попыток их обойти, чтобы обеспечить успешную реализацию (Microsoft, 2004). План отката, являясь одной из возможных стратегий обхода, активируется, если что-то пойдет не так на этапе преобразования. Поскольку в случае параллельного внедрения обе системы работают одновременно, план отката подразумевает, что база данных или другая система, обрабатывающая транзакции, должна быть полностью восстанавливаемой в устаревшей системе (Microsoft, 2004). Фактически, параллельное внедрение по определению предусматривает наличие такого плана отката благодаря своей природе, заключающейся в наличии ведущей и резервной (не ведущей) системы. Критерии-индикаторы: поскольку сценарий перехода является планом реализации передачи двух систем, он также включает в себя количественно определяемые критерии. Пересмотренные ИТ и организационные требования преобразуются в измеримые компоненты. Если критерии не выполняются в ходе тестового преобразования, следует задействовать стратегию обхода.

Перевод

Фактически, этап внедрения уже запущен. В течение этого процесса организация переживает период повышенного напряжения (Eason, 1988, Rooijmans, 2003). Обе системы работают параллельно в соответствии со сценарием перехода, и новая система находится под пристальным контролем. Когда критерии новой системы будут выполнены, старая система перестанет быть основной, и новая система возьмет на себя управление. Операции наверстывания, являющиеся частью стратегии обходного решения, представляют собой резервные копии старой системы и обеспечивают возможности для разработки надежности и восстановления данных. Существуют два способа выполнения операций наверстывания: автоматический и ручной. (Rooijmans, 2003). При необходимости может быть также развернута служба удаленного резервного копирования.

Система управления

Автоматические догоняющие операции: Догоняющие операции, передаваемые автоматизированной системой, созданной на этапе подготовки организации. Эта система автоматически передает данные или информацию в новую систему при переходе от старой основной системы к новой основной системе. Преимущество автоматизированной системы – скорость и точность. Недостаток – необходимость затрачивать время на создание системы передачи на раннем этапе. Ручная доработка: Если фактический перенос данных занимает немного времени или сложность передаваемой информации невелика, организация может выбрать ручную доработку. Преимущество этого подхода – отсутствие необходимости в системе (программном обеспечении) для передачи информации и связанных с ней возможных проблем. Однако это достигается за счет точности и времени. Ручная доработка требует значительно больше времени и более подвержена небольшим человеческим ошибкам (Rooijmans, 2003). Более того, дополнительные затраты на рабочее время и так высоки, а ручная система доработки создает еще большую нагрузку на персонал.

Статьи

Андерссон И., Хансон К. (2003). Диффузия технологий в организации, разрабатывающей программное обеспечение, диссертация на соискание степени лиценциата по прикладной информатике, Университет Гётеборга.
Brown, C. V. & Vessey, I. (1999). Подходы к внедрению ERP: к построению ситуационной модели, материалы 20-й Международной конференции по информационным системам, Шарлотт, Северная Каролина, 13–15 декабря, 411–416.
Chng, S., & Vathanophas V. (2002). К межорганизационной корпоративной системе: исследование с использованием фокус-групп. 6-я Тихоокеанско-Азиатская конференция по информационным системам (PACIS 2002). Токио, Япония, 2–4 сентября 2002 г.
Lee, O. (2004). Анализ случая системы DMV штата Невада, Журнал Академии бизнеса и экономики, том 3.
Ribbers, P. & Schoo, K. C. (2002). Разработка комплексных программ внедрения программного обеспечения, 35-я ежегодная Гавайская международная конференция по системным наукам (HICSS'02), том 8.
Yusuf, Y. & Gunasekaran, A. & Abthorpe M. S. (2004). Реализация проектов корпоративных систем: тематическое исследование внедрения ERP в Rolls Royce. Международный журнал экономики производства, 87, 251–266.