Обновление ERP-системы

Михаил Мозгов,
разработчик Microsoft Business Solutions

Инна Самойлович,
менеджер по маркетингу продукта Microsoft Business Solutions-Axapta

Стратегия обновления: готовь сани летом

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

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

Разработчики готовят пакеты обновлений и новые версии, переносят свои системы на новые платформы. И все это также обуславливает необходимость постоянного обновления. Многие руководители и ИТ-менеджеры при покупке системы не задумываются о том, как будет происходить процесс ее обновления, насколько дорогим и трудоемким он окажется. Но на самом деле речь идет об одном из важнейших критериев выбора ERP-системы. Цена подписки на ежегодное сопровождение и обновление системы может достигать 15-20% от стоимости лицензии. Это немалая сумма, составляющая значительную часть совокупной стоимости владения (Total Cost of Ownership, TCO) системы.

При выборе ERP-решения необходимо учитывать и такие – на первый взгляд неочевидные – составляющие TCO, как модернизация парка компьютерной техники и обучение персонала. Если обучение пользователей обычно включается в стоимость внедрения, то обучение технических специалистов, которые будут отвечать за поддержку системы, зачастую планируется в недостаточной мере – важность такого обучения просто недооценивают. Между тем именно технические специалисты по завершении внедрения остаются единственными на предприятии "экспертами" по системе. Именно им придется отвечать на многочисленные вопросы пользователей, выполнять дополнительные настройки, может быть, даже что-то "допрограммировать". Конечно, для решения таких задач можно приглашать сторонних консультантов, но их услуги обойдутся компании несоизмеримо дороже и вряд ли окажутся эффективнее, да и находятся внешние консультанты гораздо дальше, чем родной системный администратор.

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

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

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

Большое число пользователей. Зачастую с информационной системой на предприятии
работает много пользователей, и устанавливать новую версию приходится на все
машины, где установлены системные модули; при этом желательно (а иногда и необходимо)
проводить такое обновление одновременно на всех рабочих местах. Это очень продолжительная
и трудоемкая работа для системного администратора, если, конечно, все пользователи
не работают с одним приложением, установленным на сервере, – такая схема работы
предусмотрена, например, в трехуровневой архитектуре системы Microsoft Business
Solutions-Axapta (вся бизнес-логика системы выполняется на отдельном сервере
приложений AOS – Axapta Object Server, что значительно снижает расходы на поддержку
системы).

Обеспечение сохранности данных. При модернизации особое внимание нужно
уделять сохранности данных в системе, особенно, если происходит обновление структуры
базы данных. Для решения проблемы, в частности, следует использовать резервное
копирование данных, желательно неоднократное.

Простота модификаций и обновлений

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

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

Обновление версий на примере Axapta

Давайте рассмотрим процедуру обновления на примере пакета Microsoft Business Solution-Axapta. Эта современная интегрированная система, относящаяся к классу ERP II, предназначена для автоматизации предприятий верхнего сегмента среднего бизнеса и ориентирована на структуры с относительно сложными бизнес-процессами.

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

Процедура обновления версий/переноса измененной функциональности на работающее
приложение происходит в такой последовательности.

1. Резервное копирование базы данных и приложения.
2. Удаление неиспользуемых данные (если таковые имеются) и неиспользуемого
   кода.
3. Развертывание новой версии приложения.
4. Перенос кода и компиляция приложения.
5. Перенос данных на новую версию, тестирование.

Поговорим о конкретных этапах более подробно.

 

Структура слоев Архитектура Microsoft Business Solution-Axapta базируется на структуре слоев, упрощающей контроль обновления и модификации функциональности. Стандартное приложение Axapta хранится в ядре, которое контролируется и сопровождается лишь разработчиком – компанией Microsoft Business Solution. Функциональность, специфичная для национальных рынков и отраслей, создается и хранится в слоях, дополняющих ядро. Эта функциональность может изменяться и дополняться в соответствии с нуждами клиентов. В соответствующих слоях пользователи сохраняют свои модификации, например, связанные с шаблонами отчетов. Объекты стандартной функциональности нельзя изменить или удалить. Когда партнеры или пользователи модифицируют функциональность, измененные объекты сохраняются в разных файлах. При изменении объект копируется в верхний уровень в иерархии слоев, элемент из верхнего слоя используется при вызове функциональности. Благодаря этой особенности клиенты и их партнеры могут вернуться к изначальной функциональности, просто удалив элемент из своего слоя.

Резервное копирование базы данных и приложения

Порядок выполнения резервного копирования данных зависит от характера базы данных, с которой работает ERP-система, – это может быть как встроенная в ERP-систему, так и внешняя СУБД.

В рассматриваемом примере с Axapta резервное копирование базы данных выполняется штатными средствами внешних СУБД Microsoft SQL или Oracle (работа с ними предусмотрена в Axapta). Совместимость с внешними широко распространенными СУБД – одна из важных характеристик системы управления предприятием, которая снижает совокупную стоимость владения системой. Стандартные СУБД знакомы гораздо большему числу специалистов, чем СУБД, встроенные в конкретные ERP-системы, а следовательно, получить любые консультации по использованию ПО и решить возникающие проблемы в первом случае оказывается легче, быстрее и дешевле.

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

Удаление неиспользуемого кода

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

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

Рис. 1. Сравнение слоев, содержащих одинаковые элементы.

Перенос кода в новое приложение

В системе Axapta предусмотрены два пути переноса кода – с помощью экспортного файла и путем переноса всего слоя, содержащего изменения.

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

К достоинствам такого подхода относят следующее:

• независимость от версии. Например, экспортный файл, сделанный в версии Axapta
  2.1, можно загрузить в версию Axapta 2.5;
• возможность переноса кода между слоями;
• возможность изменения или добавления только прикладных объектов, присутствующих
  в экспортном файле.

Вариант с переносом всего слоя подразумевает перемещение файла, содержащего весь код из USR-слоя, в каталог, где хранится новое приложение. Достоинства такого варианта – сохранение идентификаторов объектов и сохранение информации о проектах.

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

Рис. 2. Алгоритм обработки объекта приложения при обновлении.

Компиляция

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

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

 

Советы и рекомендации Перед переходом на новую версию обязательно проводите резервное копирование данных и приложения. Внесенные в код изменения выделяйте комментариями. В комментарии полезно включать следующую информацию: название проекта, в рамках которого выполнены изменения, дату, краткое описание внесенных изменений, имя сотрудника, изменявшего код. Все измененные объекты целесообразно маркировать префиксом, определяющим код проекта (в данном случае имеется в виду не проект в окне проектов Microsoft Business Solutions-Axapta, а совокупность работ по изменению функциональности системы). Все добавленные элементы объектов (поля таблиц, методы, управляющие элементы и т. п.) и все добавленные атрибуты классов также следует маркировать префиксом, определяющим код проекта. Все переменные и параметры, добавленные в уже существующие методы, должны начинаться с префикса, определяющего код проекта.