Параллельное усыновление - Parallel adoption

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

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

Обзор

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

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

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

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

Есть несколько случаев, когда параллельное преобразование нельзя считать жизнеспособной стратегией преобразования. Сначала подумайте, содержит ли новая система значительные изменения схемы. Элементы данных, требуемые одной системой, которые не заполняются другой, могут в лучшем случае привести к неточности данных, а в худшем - к их повреждению. Другая проблема заключается в том, полагается ли система на готовую потребительскую технологию (COTS). Если в документации поставщика COTS указано, что несколько приложений не могут совместно использовать одну и ту же базу данных, то параллельное преобразование невозможно. Примером могут служить продукты Oracle Siebel. Другие продукты COTS также могут накладывать ограничения, когда для исправлений или крупных обновлений требуются уникальные лицензионные ключи. После применения они могут вносить изменения в базу данных, которые могут привести к тому, что приложение ошибочно обнаружит параллельную систему, работающую с той же базой данных, в качестве попытки обойти элементы управления лицензированием и тем самым отключить систему.

Место в процессе внедрения

Похоже, есть небольшие договоренности относительно процесса параллельного усыновления. Некоторые источники (например: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999) не используют единственное имя описания процесса. Период, термин параллельное усыновление обозначается в этих источниках, хотя и согласован для каждого источника как: параллельное преобразование, параллельный запуск, теневой запуск, параллельное переключение и параллельная реализация. Это, по-видимому, так, потому что общее описание процесса не требует отдельной классификации. Существует довольно много стандартных методов реализации, в которых описаны различные методы внедрения, но часто в практическом контексте; сценарий из реального мира или более полный набор методов реализации, например Регата: метод принятия, SIM и PRINCE2. В общем, параллельное внедрение лучше всего рассматривать как Системная инженерия метод выполнение новой системы.

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

Процесс

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

На рисунке 1 представлен обзор параллельного процесса внедрения. В левой части изображен поток действий, которые способствуют процессу. Действия, которые выполняются одновременно, отмечены толстой черной линией. Когда параллельное выполнение действий завершено, действия снова объединяются в аналогичную черную линию. Отсутствие стрелки от одного действия к другому указывает на то, что они являются агрегатами более крупного действия, указанного выше. Мероприятия разделены на четыре основных этапа:

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

Основные этапы подразделяются на другие виды деятельности, которые будут кратко описаны в таблицах с 1-1 по 1-4.

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

Рисунок 1. Диаграмма метапроцесс-данные параллельного внедрения

Понятия из рисунка 1 определены в таблице 2-1 ниже.

Определение стратегии параллельной реализации

Фигура 2. стратегия реализации

Параллельному внедрению предшествует определение стратегии внедрения, которая не является уникальной для параллельного внедрения, но может рассматриваться как часть управление изменениями процесс, в который входит организация. (Ли, 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).

Это означает, что организация должна четко обдумать свою стратегию внедрения и интегрировать это решение в свои Управление рисками или же Управление изменениями анализ.

Разработка сценария реализации

Рисунок 3. Предварительная реализация

IT-требования

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

Организационные требования

Помимо ИТ-требований, организационные требования требуют Управление человеческими ресурсами такие вопросы, как обучение персонал, иметь дело с возможно изменением организационная структура, органическая организация или же Механистическая организация характеристики организации (Daft, 1998) и, самое главное: поддержка высшего руководства (Brown, Vessey, 1999). Brown et al. (1999) выделяют две различные роли, которые может выполнять высшее руководство: так называемые роли спонсора и защитника:

• «Спонсор проекта несет ответственность за бюджетную поддержку и обеспечение того, чтобы ключевые представители бизнеса играли роль в команде проекта».
• «Руководитель проекта может быть или не быть официальным членом команды проекта, но может играть ключевую роль в усилиях по управлению изменениями»

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

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

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

Подготовка организации

Рисунок 4. Подготовка организации

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

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

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

Таким образом, сценарий преобразования представляет собой план организационных изменений во всех аспектах. Однако есть две темы, которым еще не было уделено должного внимания в контексте параллельного внедрения.

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

Преобразование

Рисунок 5. Преобразование

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

Система контроля

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

Оценка / Практическая значимость

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

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

• Оценка рисков и планирование на случай непредвиденных обстоятельств (обходных путей) очень важны
• Назначьте роли в команде проекта
• Постройте определенные этапы (например, PRINCE2 ) которые включают планы обучения и тестирования
• Выявить потенциальные риски и при необходимости выполнить план действий в чрезвычайных ситуациях
• Сообщите статус проекта
• Изменения должны быть соответствующим образом разрешены
• В стратегии конверсии необходимо тщательно изучить требования к данным.
• Новые и измененные данные следует проверять на соответствие правилам проверки.
• Составьте подробный план отката
• По возможности договоритесь о пилотной конверсии

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

1. Непрактично ожидать, что конечные пользователи, будь то клиенты, рабочие производственной линии или почти кто-либо другой, будут вводить каждую транзакцию дважды через разные интерфейсы.

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

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

Смотрите также

• Принятие программного обеспечения продукта: принятие большого взрыва
• Поэтапное принятие
• Принятие (реализация программного обеспечения)
• Регата: метод принятия
• Управление изменениями
• Техника надежности
• Откат (управление данными)
• Управление рисками
• Программная инженерия
• Выполнение

Рекомендации

Статьи

• Андерссон И. Хэнсон, К. (2003). Распространение технологий в программной организации, Лицензионная работа в области прикладных информационных технологий, Гетеборгский университет
• Браун, C.V. И Весси, I. (1999). Подходы к внедрению ERP: к схеме на случай непредвиденных обстоятельств, Материалы 20-й Международной конференции по информационным системам, Шарлотт, Северная Каролина, 13–15 декабря, 411-416.
• Чнг, С., и Ватанофас В. (2002). К межорганизационной системе предприятия: исследование фокус-группы. 6-я Тихоокеанская азиатская конференция по информационным системам (PACIS 2002). Токио, Япония. 2–4 сентября 2002 г.
• Ли, О. (2004). Пример системы DMV Невады, Журнал Академии бизнеса и экономики, Том 3
• Рибберс, П. & Schoo, K.C. (2002). Разработка сложных программ внедрения программного обеспечения, 35-я ежегодная Гавайская международная конференция по системным наукам (HICSS'02), Том 8
• Юсуф Ю., Гунасекаран А. и Абторп М.С. (2004). Реализация проекта корпоративных систем: пример ERP в Rolls Royce. Международный журнал экономики производства, 87, 251-266.

Книги

• Дафт, Р. (1998). Организационная теория и дизайн. Запад: Интернешнл Томсон
• Исон, К. (1988). «Глава 9, Внедрение и поддержка» в: Информационные технологии и организационные изменения. Лондон: Тейлор и Фрэнсис
• Тюрбан, Э., Маклин, Э. и Уэтербе Дж. (2002) «Глава 14, Создание информационных систем», в: Информационные технологии для управления. Нью-Йорк: John Wiley & Sons, inc.
• Ройманс Р., Хи М. де и Куп Р. (2003). Regatta: внедрение ИКТ также с помощью vier-met-stuurman. Гаага: Ten Hagen en Stam Uitgevers.

внешняя ссылка

• Переплатформенное направление бизнес-приложений с UNIX на Windows. (2004), версия 1.0 Microsoft, Проверено 5 марта 2006 г. [1]
• Внедрение системы учета портфеля: уроки из окопов (2004 г.), Venture Financial Systems Group Ltd, Проверено 6 марта 2006 г. [2]