Традиционно при автоматизации бизнес-процессов компании выделяются два вида информации, что соответственно приводит к внедрению двух классов систем:

• Системы обработки структурированной информации – класса ERP(SAP);
• Системы для обработки неструктурированной информации – скан-копии документов и сами документы как таковые – системы класса ECM*.

Примечание: Enterprise Content Management (ECM) - стратегия, методы и инструменты, используемые для сбора, управления, хранения, сохранения и доставки контента и документов, связанных с организационными процессами (источник: AIIM).

В настоящий момент времени SAP представляет несколько функциональностей, предназначенных для обработки неструктурированной информации:

1. DMS – Document Management System
2. RCM – Record and Case Management System
3. ECM – SAP xECM by OpenText

Необходимо отметить, что если первые два решения являются частью SAP ERP ECC, то третье, хоть и является тесно интегрированным в SAP ERP- представляет собой отдельную платформу. В статье хотелось бы затронуть аспекты построения системы документационного обеспечения предприятия на основании компонентов, входящих в ECC, обладающими возможностями уменьшения эксплуатационных расходов Заказчика. Так как DMS является хорошо известной и давно внедряемой на рынке компонентой, остановимся на RCM - достаточно недавно появившейся в линейке продуктов SAP и еще не завоевавшей широкого признания в России, как со стороны фирм интеграторов, так и со стороны клиентов. Тем не менее, SAP - RCM обладает всеми традиционными возможностями современных систем электронного документооборота. Она охватывает практически все аспекты в области управления документами и позволяет организовать эффективную документационную поддержку бизнес-процессов компании в соответствии с требованиями государственных стандартов, нормативных документов и принятых в компании принципов работы в существующих регламентах. Необходимо отметить, что RCM построена с использованием методологии SOA. Это позволяет ей обладать достаточной гибкостью.

Давайте рассмотрим классические задачи, которые ставятся Бизнесом перед консультантами при запуске СЭД (системы электронного документооборота):

1. Создание документов, ведение их версионности, использование шаблонов;
2. Обработка документов (построение иерархии, объединение в дело);
3. Постановка задач по обработке документов (пакетов документов), их согласование, коллективная разработка и контроль исполнения;
4. Формирование номенклатуры дел;
5. Поиск документов (атрибутный и полнотекстовый). Журналы регистрации и реестры документов.

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

Рис.1. Архитектура RCM

Area - область деятельности, в рамках которой предприятие предоставляет вид работ и услуг, предусмотренных Уставом компании. Каждая area содержит свою группу сервисных провайдеров (Service Provider). В SAP предусмотрено несколько area. К примеру, можно выделить area,  в состав которых входят компоненты, отвечающие за обработку документов (включая обработку карточек документов, записей, ведение из версионности маршрутизации и т.д.).

Service Provider (SP) предоставляет набор средств и услуг для работы с определенным видом объекта (задачи, карточки, документы, письма, бизнес-объекты и т.д.). Каждый сервисный провайдер отвечает за обработку информации об определенной группе объектов. Примером может служить SP,  отвечающий за обработку объекта документ (ведение его карточки, версионности контента и т.д.)

ElementType (ET) – конкретная реализация сервисного провайдера. С технической точки зрения -  он же тип элемента, унаследованный от ServiceProvider. Один сервисный провайдер может порождать один или более ElementType.

RMS_ID– логическое, в соответствии с внедряемой бизнес функцией, объединение сервисных провайдеров.

Element(E) – инстанция ET.

Таким образом, технически нашу задачу можно разбить на следующие части:

• Создание своего RMS_ID ,  отражающего бизнес-специфику решаемой задачи;
• Настройка стандартных RMS_ID,ET,Eи присвоение им нового RMS_ID.

В решаемой нами задаче мы предлагаем к использованию следующие ET: Record, RecordModel, ArchiveLinkDocument, FilePlan.

Все настройки, выполняемые по вышеуказанным ET,  выполняются посредством транзакции srmregedit.

Кроме того, мы рассмотрим casemanagement, в разрезе инструментария, для эффективной постановки задач по разработке (исполнению) документов и контролю данного исполнения.

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

1)      Обработка документов, ведение их версионности, использование шаблонов

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

Сам документ состоит из и contentmodel (карточки документа) и самого файла, хранилище которого является настраиваемым  посредством KPRO (Рис.2).

Contentmodel содержит описательную часть файла и атрибуты файла, которые в случае MSOffice, могут быть считаны автоматически.

Возможно ведение версионности, как на уровне contentmodel (карточки документа), так и содержимого (файла). Необходимо отметить, для  contentмодели, можно осуществить настройку сети статусов, отражающих жизненный цикл документа. Причем сама сеть статусов имеет более широкую вариацию для настройки по сравнению с DMS (DocumentManagementSystem). К примеру, в DMS можно было указать в настройке текущего статуса не более 6  статусов предшественников, в RCM количество статусов предшественников неограниченно.

Рис.2. Обработка файла

Рис.3. Контент модель файла

Contentmodelявляется настраиваемой и подлежит наследованию от вышестоящей, приобретая все ее свойства и атрибуты. Настройка contentmodelпроисходит в транзакции DMWB. Contentmodel состоит из Input/Output атрибутов, свойства которых, так же подлежат настройке (Рис.4). Таким образом, при грамотном построении архитектуры системы, на этапе предварительного обследования, рекомендуется: определить атрибутику всех документов, используемых в организации; выделить одинаковые для всех документов атрибуты; построить на их основании общую contentmodel, а в дальнейшем - наследоваться от нее, после чего расширить параметры специфичных для того или иного документа, атрибутов. При обработке не редактируемых файлов представляется возможность их аннотирования с использованием Integrated Document Viewer.

Рис.4 Контент-модель, настройка свойств Input/Outputатрибута

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

Рис.5. Формирование файла по шаблону

Рис.6. Выбор шаблона

Рис.7. Окончательно сформированный шаблон

2)      Обработка документов (построение иерархии, объединение в дело).

Часто, при обработке документов возникает необходимость объединения их в некое подобие дела (папку), а так же указать документ - основание (вышестоящий документ). Рассмотрим данную потребность на основании договора. Формирование папки документов, а также их  иерархии возможно по принципу SPтипа record.

Record – состоитизcontent model (Рис.8) иrecord model (Рис.9). Recordможет содержать соединенные с ней, посредством modelrecord, объекты (бизнес-объекты SAP, документы, транзакции, отчеты, url-ссылки и т.д.). В то же время,  она может быть включена, в качестве элемента, в другой recordmodel. Интересной особенностью recordmodelявляется возможность содержать ссылки на бизнес-объекты системы. В свою очередь, объекты системы могут содержать ссылки, посредством GOS(GenericObjectService), на объекты record. Таким образом, мы получаем неограниченную интеграцию любых record, содержащих документы к фактически любому объекту SAP, имеющему  в своем распоряжении GOS. Настройка recordmodel является весьма гибкой и удобной (Рис.9). Изначально строится структура папок, листами которых могут являться ссылки на Eили ET, определенные обрабатываемой RMS_ID. Все настройки осуществляются путем транзакции srmcustomizing.

Рис.7. Content-model записи

Рис.8. Record-modelзаписи