Параллельное внедрение

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

Обзор

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

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

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

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

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

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

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

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

Процесс

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

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

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

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

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

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

Таблица 1-1: Предварительная реализация
Активность	Описание
Определить стратегию реализации	Стратегия реализации определяется на этом раннем этапе. (Браун, Весси, 1999)
Создать основной сценарий реализации	Проводится первый первоначальный анализ требований, состоящий из приведенных ниже требований. (Предприятие, 2004)
Планирование времени строительства	В настоящее время строится первое временное планирование процесса реализации. (Ройманс, 2003 г.)
Определить организационные требования	Здесь определены организационные требования (Ройманс, 2003).
Определить ИТ-требования	Определены требования к ИТ (Ройманс, 2003 г.)

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

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

Таблица 1-4: Завершение параллельного внедрения
Активность	Описание
Запустите ведущую новую систему(2)	Все догоны и контроль закрыты. Новая система является единственной действующей системой. (Майкрософт, 2004 г., Ройманс, 2003 г.)
Отключить старую систему	Старая система больше не нужна и отключена. (Майкрософт, 2004 г., Ройманс, 2003 г.)

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

Таблица 2-1: Список определений понятий
Концепция	Определение
Стратегия реализации	Стратегия, которая будет выбрана для внедрения новой системы. Возможные варианты: «большой взрыв», поэтапное, параллельное внедрение, пилотное преобразование или комбинация этих четырех. (Тюрбан, 2002 г., Ройманс, 2003 г.)
Скрипт реализации	Необработанная версия фактического сценария преобразования, состоящая из организационных требований, требований к ИТ и первоначального планирования времени. (Венчур, 2004 г., Исон, 1988 г.)
Организационные требования	Требования внутри организации, которые должны присутствовать для успешной реализации. Они занимаются оптимизацией (изменением) организации под новую систему. Затрагиваемые вопросы могут быть следующими: Управление человеческими ресурсами, изменение органограмм и новые бизнес-структуры. (Ройманс, 2003 г.)
ИТ-требования	Требования к информационным технологиям — это требования к программному и аппаратному обеспечению, выбор платформы с учетом бюджета и существующих систем. (Ройманс, 2003 г.)
Планирование времени	Планирование, при котором действиям назначается период времени, в течение которого они должны быть завершены, что дает общую картину проекта реализации с учетом доступного времени. (Исон, 1988)
Требования
Соответствие	Соответствие – это соответствие требованиям. (ИСО 9000)
Сценарий конверсии	Переработан сценарий реализации с учетом соответствия требованиям. Кроме того, сценарий преобразования состоит из обходного пути и плана отката. Сценарий конверсии представляет собой основу проекта реализации. (Ройманс, 2003 г.)
Стратегия обхода	Резервный план; Стратегия, принятая в сценарии преобразования, позволяет предотвратить ошибки в процессе преобразования и попытаться обойти их, чтобы реализация по-прежнему была успешной. (Ройманс, 2003 г.)
Показатели критериев	Количественные и измеримые критерии требований, позволяющие определить, был ли процесс внедрения успешным. (Ройманс, 2003 г.)
План отката	План, который поможет изменить направление репликации на противоположное, чтобы вернуться к старой системе без потери данных или информации. (Майкрософт, 2004 г.)
Тестовая конверсия	Сегментное тестовое преобразование перед фактическим преобразованием с целью лучше подготовиться к неопределенностям или проблемам в фактическом процессе преобразования. (Майкрософт, 2004 г.)
Старая система	Старая система: когда ведущее = true; старая система обрабатывает системные транзакции в реальном времени: Основные функциональные объекты, входящие в состав продукта, например аппаратное обеспечение, программное обеспечение. Также организованный и дисциплинированный подход к выполнению задачи, например, система отчетов об отказах (ISO 9000).
Новая система	Новая система (цель): Новая система, при ведении = true; новая система обрабатывает системные транзакции в реальном времени. Основные функциональные объекты, входящие в состав продукта, например аппаратное обеспечение, программное обеспечение. Также организованный и дисциплинированный подход к выполнению задачи, например, система отчетов об отказах (ISO 9000).
Контроль	Общая система контроля, включающая в себя показатели эффективности, а также оценку надежности и догонялки. Система управления очень широка и представляет собой центральную командную систему преобразования старой системы и управления новой в ходе параллельного процесса внедрения. (Ройманс, 2003 г., Microsoft, 2004 г.)
Производительность	Количественная оценка эффективности старой и новой системы служит входными данными для системы управления. (Ройманс, 2003 г.)
Оценка надежности	Количественная оценка надежности продукта, системы или их части. В таких оценках обычно используются математическое моделирование, непосредственно применимые результаты испытаний продукта, данные об отказах, расчетные показатели надежности и нестатистические инженерные оценки. (ИСО 9000)
Догонялки	Догоняющие копии состоят из автоматически или неавтоматически созданных резервных копий системы, использующих старую систему, для перевода в новую систему. (Ройманс, 2003 г.)
Автоматические догонялки	Автоматически создаваемые догонялки (Ройманс, 2003).
Догонять вручную	Догоняющие данные, созданные вручную (Ройманс, 2003 г.)

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

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

Риск против затрат

Причиной, по которой организация выбирает параллельное внедрение в пользу пилотного преобразования, «большого взрыва» или поэтапного внедрения, часто является компромисс между затратами и риском (Andersson, Hanson, 2003). Параллельное внедрение — самый дорогой метод внедрения (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), поскольку он требует от организации, чтобы две системы работали параллельно в течение определенного периода. Одновременная эксплуатация двух систем означает инвестиций в человеческие ресурсы необходимость . Помимо хорошей подготовки (дополнительного) персонала , ему приходится пройти через напряженный период параллельной работы, когда процедуры пересекаются. (Ройманс, 2003 г., Исон, 1988 г.) Необходимо приложить усилия для обеспечения согласованности данных и предотвращения повреждения данных между двумя системами. (Chng et al. 2002, Yusuf, 2004) Не только для самого процесса преобразования, но и для обучения их работе с новой системой.

Когда необходимо внедрить новую систему по принципу «большого взрыва», риск неудачи высок (Lee, 2004). Когда организация требует серьезного изменения старой (устаревшей) системы, компромисс между дополнительными затратами и менее рискованным параллельным подходом должен быть в пользу этих дополнительных затрат (Lee, 2004), несмотря на это, мы видим что внедрение ERP в большинстве случаев следует за большим взрывом (Microsoft, 2004, Yusuf, 2004).

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

Разрабатываем сценарий внедрения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конверсия

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

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

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

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

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

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

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

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

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

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

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

См. также

Ссылки

Статьи

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

Книги

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

Внешние ссылки

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