С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.

Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ‑системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес‑процессов, вовлекающих как бизнес‑пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ‑сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:

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

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

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

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

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

Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.

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

Казалось бы, чего может быть сложного: спроектировали, разработали, протестировали программную информационную систему и все, осталось только ее запустить в продуктивный режим эксплуатации, что обычно неоднократно репетируется. Но так ли это просто? Ответ положительный, если внедряется ERP-система на подразделении с небольшим числом конечных пользователей, уровень владения компьютером у сотрудников плюс-минус нормальный, все участники проекта сосредоточены в одной локации и, наконец, число специфичных требований к системе небольшое. Сейчас мы рассмотрели типовой проект внедрения корпоративной системы (далее – КИС).

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

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

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

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

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

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

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

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

Последовавший в начале 2022 года уход из России практически всех известных вендоров от Microsoft, до SAP и Oracle, показал нашу сильную зависимость от прививаемого годами зарубежного ИТ-сервиса. По существу, начало полноценного замещения зарубежного ПО началось именно с этого момента, когда российские компании поставили перед фактом остановки поддержки, продления лицензий и работы самого ИТ-решения. Большинство ИТ-менеджером и директоров судорожно стало думать о переходе на российские аналоги, в частности на продукты 1С, как базового корпоративного решения. Однако, использование нового ПО на предприятии возможно лишь после его имплементирования, процесс которого оказался также сильно завязан на страны запада.

В это статье мы рассмотрим вопрос импортозамещения приложений класса ERP и ERP2, принимая во внимание тот факт, что это далеко не единственный компонент корпоративной информационной системы (далее – КИС). Для целей удобства повествования термины программное обеспечение, информационные и корпоративные системы, а также ERP-системы для нас будут тождественны. В работах [1-2] выделяют четыре основных уровня задач для внедрения КИС, к которым относят процессы, данные, приложения и технику, а также два вспомогательных: управление проектном и изменениями. Собственно говоря, процесс внедрения и импортозамещения ERP-систем мы будем рассматривать сквозь указанные 6-ть параметров.

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

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

Первыми изобретателями компьютера в СССР являются И.С. Брук и Б.И. Рамеев, совместно разработавшие проект цифровой ЭВМ с жестким программным управлением. В декабре 1948 г. они получили авторское свидетельство на изобретение «Автоматической цифровой машины».

«МЭСМ» (малая электронная счетная машина) – первый компьютер в СССР и в целом в континентальной Европе, была создан в 1951 г. под руководством С.А. Лебедева. Под его же руководством в дальнейшем были разработаны и сконструированы машины серии «М» (М-1, М-2 и другие ее модификации), из которых М-20 в 1960-х гг. была признана в СССР лучшей из отечественных машин. Специализированные ЭВМ, созданные под руководством С.А. Лебедева для системы противоракетной обороны, стали основой достижения стратегического паритета между СССР и США во время холодной войны.

В 1950 г. в Институте точной механики и вычислительной техники (ИТМ и ВТ) был организован отдел цифровых ЭВМ для их разработки и создания. В 1951 г. там была спроектирована машина БЭСМ (большая электронная счетная машина), а уже в 1952 г. началась ее опытная эксплуатация.

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

Информационная инфраструктура представляет собой систему организационных структур, подсистем, обеспечивающих функционирование и развитие информационного пространства страны и средств информационного взаимодействия. Информационная инфраструктур включает в себя совокупность информационных центров, подсистем, банков данных и знаний, систем связи, центров управления, аппаратно-программных средств и технологий обеспечения сбора, хранения, обработки и передачи информации; а также обеспечивает доступ потребителей к информационным ресурсам [1].

Информационные системы (ИС), являясь составляющей частью информационной инфраструктуры, представляет собой систему обработки информации совместно с соответствующими организационными ресурсами (человеческими, техническими, финансовыми и др.), обеспечивая ее распространение (ISO/IEC 2382:2015). ИС предназначена для своевременного обеспечения людей надлежащей информацией, то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция: документы, массивы данных, базы данных и информационные услуги. По охвату задач информационные системы можно классифицировать на персональные, групповые, корпоративные, системы органов власти и государственных учреждений [1].

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

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

Существует ошибочная точка зрения, что наиболее критичным этапом внедрения ERP-системы является разработка, это не совсем так. Немаловажны активности, связанные с тестированием, обучением и миграцией данных. Однако все это задачи, выполняются на стороне заказчика. В проект имплементации корпоративной информационной системы вовлечены и прочие заинтересованные стороны, в честности контрагенты [1]. Несмотря на то, что вопрос перехода к продуктивному использованию системы является ключевым в ходе запуска, его важность иногда недооценивается. По крайней мере, до тех пора пока вы не столкнетесь с Cutover’ом вплотную. Да, да, именно так называют план перехода в среде технических специалистов.

План перехода включает в себя ряд активностей, выполнение которых решает две основные задачи: техническая подготовка программного решения для функционирования в режиме реального времени, а также взаимодействие с клиентами и поставщиками для обеспечения непрерывной работы с ними. Cutover-план затрагивает технические, бизнес и вопросы, связанные с историческими данными [2]. Формирование плана перехода начинается много раньше промышленного запуска, так как задача в первую очередь требует большого вовлечения сотрудников заказчика, во-вторых, сильно зависит и влияет на технические активности смежных команд.

Своевременная подготовка, а она занимает в среднем два-три месяца, и выполнение Cutover-плана, длящегося около двух месяцев, позволяют обеспечить такой режим запуска новой программной системы, который никак или минимально повлияет на клиентов и поставщиков предприятия. Будьте уверены, вы не сможете подготовить план перехода без заказчика. Эту и другие особенности Cutover-плана мы попытаемся рассмотреть в настоящей статье.

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1].

Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].

Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

Агрессивная, навязчивая реклама товаров, работ, услуг, продвижения бренда в PR-технологиях и маркетинге компаний сегодня начинает давать «обратный» эффект и со временем в таком формате уйдет в прошлое. Новой технологией подачи информации становится сторителлинг, который активно используется как коммуникационный метод продвижения бренда. Сегодня выделиться в огромном количестве информации в информационном потоке стало намного сложнее, поэтому сторителлинг – один из способов это сделать. Сторителлинг (Storytelling) – термин, употребляемый маркетологами, журналистами, психологами, преподавателями и понимаемый как коммуникативная технология, позволяющая посредством нарратива сделать информацию интересной и запоминающейся для адресата. Технология сторителлинга, или рассказывания историй, за последние несколько лет приобрела заметную популярность; она используется в различных профессиональных средах. Изначально сторителлинг был успешно внедрен и апробирован Дэвидом Армстронгом как инструмент управления персоналом. Затем этот метод  начал активно использоваться в маркетинге, PR, журналистике, образовании. 

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

Внедрение корпоративных информационных систем позволяет автоматизировать большинство административно-хозяйственных операций предприятия. Класс системы, например, ERP, ERP2 или MRP, специфицирует бизнес-процессы, подлежащие автоматизации. Имплементация ERP-систем затрагивает две ключевые области деятельности компании: логистику и финансы. Причем специфика страны накладывает свой отпечаток: в Европе преимущественно акцент делается на логистических операциях, в России, напротив, – финансовых [1]. Для обеспечения эффективной работы ERP-системы необходимо обеспечить разумный баланс между логистическими и бухгалтерскими требованиями, их реализацией в программной системе.

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

Следует отметить, что, несмотря на кажущуюся простоту закупок, процесс ее отражения в ERP-системе достаточно непрост. Существуют различные виды закупок, каждая их которых имеет свои отличительные особенности и требует уникальной реализации в программной системе [2]. Зачастую в проектах внедрения ERP-систем цепочки закупок имеют сложную реализацию из-за необходимости удовлетворения бухгалтерским требованиям. Давайте рассмотрим схемы закупок, точки интеграции с финансовыми операциями и найдем способ их отражения в ERP-системе.

Цифровизация предприятия ведется за счет внедрения интегрированных программных систем для управления бизнес-процессами и базами данных. Комплексное программное обеспечение задает класс систем вида ERP, который часто в русскоязычной литературе называют корпоративными информационными системами. Сложность имплементации ERP-систем состоит в том, что одновременно должны решаться задачи по оптимизации бизнес-процессов, разработке программ, переносу данных, управлению изменениями, настройке технической инфраструктуры и «дирижированию» проектом. Миграция информации из исторической системы в целевую систему является одной из важнейших проектных задач, так как низкое качество начальных данных может заблокировать выполнение бизнес операций и их отражение в программной системе. Качественный процесс переноса данных обеспечивается правильно подобранной и реализованной стратегией миграции. Какие стратегии существуют, каковы их особенности и способы выполнения? Мы постараемся найти ответы на эти вопросы в данной статье.

Несмотря на важность вопроса мигрирования данных корпоративных информационных систем, литературных источников, дающих исчерпывающее представление о переносе информации не так много. Но даже в них есть изъяны: или слишком поверхностное описание, или излишняя детализация, исключающая стратегию как таковую. Примером первой категории работ служит статья [1], повествующая о миграции данных в SAP ERP, однако тонкости и детали переноса основных и переменных данных в ней не раскрыты. Прочие работы [2-3] дают максимум информации по автоматизированным средствам переноса данных в той же системе SAP, хотя взаимосвязь между техническими средствами и концепцией, стратегией, видением не прослеживается. Все это подчеркивает необходимость детального анализа миграции данных ERP-систем, что особенно актуально для транзакционных информационных систем.