ERP

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

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

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

Обновление адаптируемых систем

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

Рис. 1. Дерево конфигурации прикладного решения

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

Рис. 2. Сравнение и объединение конфигураций в процессе обновления

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

Таблица 1. Правила модификации свойств объекта клиентского приложения

Рассмотрим реализацию этого подхода на примере платформы "1С:Предприятие 8.0".

Структура прикладного решения

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

Обновление прикладных решений

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

Рис. 3. Настройка фильтра просмотра изменений

Если клиент пользуется прикладным решением поставщика, не внося в него своих изменений, процесс обновления очень прост и выполняется автоматически - этот случай не отличается от апгрейда жестких систем. Интерес представляет объединение изменений, внесенных и вендором, и клиентом. "1С:Предприятие 8.0" автоматически определяет такую ситуацию в процессе обновления и выполняет сравнение всех трех версий конфигурации, после чего осуществляется автоматическая настройка правил объединения, основанная на вышеописанных принципах (см. рис. 2). Последняя версия конфигурации поставщика автоматически сохраняется внутри конфигурации клиента. Можно в любой момент посмотреть внесенные изменения и при необходимости полностью или частично их отменить.

Рассмотрим возможные варианты модификации свойства объекта клиентского приложения по отношению к версии "Поставщик1" (см. таблицу 1).

Рис. 4. Отчет о сравнении версий

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

Таким образом, из всего множества объектов (а конфигурация может включать тысячи объектов и десятки тысяч свойств) будут показаны только те, которые требуют ручной настройки. Разработчик клиентского приложения сможет проанализировать отличия и задать правило объединения.

При этом механизм сравнения может сформировать очень подробный и наглядный отчет (см. рис. 4).

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

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

Рис. 5. Настройка правил поставки объекта

Для каждого объекта могут быть заданы следующие правила поставки (см. рис. 5).

· Изменения разрешены. Клиент может редактировать объект. Это правило устанавливается по умолчанию.

· Изменения не рекомендуются. Клиенту не рекомендуется редактировать объект.

· Изменения запрещены. Клиенту не разрешается редактировать объект без снятия с поддержки всей конфигурации.

Рис. 6. Настройка правил поддержки объекта

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

Клиенту разрешается установить для объекта следующие правила поддержки:

· объект поставщика не редактируется;

· объект поставщика редактируется с сохранением поддержки;

· объект поставщика снят с поддержки.

Варианты политики поддержки объекта, которые разрешается задавать клиенту в зависимости от указанного поставщиком правила его поставки, показаны на рис. 7.

Таблица 2. Варианты настройки правилш объединения

С учетом этой схемы меняется и настройка правил объединения по умолчанию (см. табл. 2).

Создание конфигураций поставщика и постановка на поддержку

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

Рис. 7. Соответствия правил поставки и поддержки

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

Несколько конфигураций поставщика

Рассмотрим следующую ситуацию. Клиенту требуется решение на платформе "1С:Предприятие", позволяющее в комплексе автоматизировать основную деятельность (например, продажи турпутевок или планирование производства), управление финансами, персоналом и т. д., но имеющиеся на рынке предложения его не устраивают. Тогда он может приобрести (как у одного, так и у разных поставщиков) отдельные решения для каждого участка и создать из них единую конфигурацию, используя те же механизмы, которые были описаны выше. Что происходит в этом случае с поддержкой? Она будет сохранена: клиент может получать обновления исходных решений у соответствующих поставщиков и аккумулировать их в объединенной конфигурации. Эта схема действует и в том случае, если исходные решения содержат ряд совпадающих объектов (справочник клиентов, справочник банков и т. д.). Единственное исключение возникает при конфликте в правилах поставки объектов - если исходные конфигурации от различных поставщиков содержат одинаковый объект и его редактирование запрещено сразу несколькими (двумя и более) поставщиками.

Объединение модулей

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

Использование при разработке тиражных решений

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

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

Автор - специалист отдела разработки платформы "1С:Предприятие" фирмы "1С".