Построение Системы Электронного Документооборота На Rcm - Sapland

26.02.
2020 Построение системы электронного документооборота на Record and Case management System / Сапёр / Статьи / База знан…
База знаний
Построение системы электронного документооборота на Record and Case management System

Александр Остапко
Традиционно при автоматизации бизнес-процессов компании выделяются два вида информации, что соответственно приводит к внедрению двух
классов систем:
Системы обработки структурированной информации – класса 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).
Прежде чем преступать к решению задачи, вкратце остановимся на основных понятиях архитектуры.
https://sapland.ru/kb/articles/stats/postroenie-sistemi-elektronnogo-dokumentooborota-na-record-and-case-management-s.html 1/11
26.02.2020 Построение системы электронного документооборота на Record and Case management System / Сапёр / Статьи / База знан…
Рис.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 содержит описательную часть файла и атрибуты файла, которые в случае MSO ce, могут быть считаны автоматически.
Возможно ведение версионности, как на уровне 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записи
Рис.9. Настройка record модели
3) Постановка задач по обработке документов (пакетов документов), их согласование, коллективная разработка и контроль исполнения.
Обозначенную бизнес-задачу можно решить, используя SPSCMG_SP_CASE. Вся настройка Case-Management ведется в транзакции scase_customizing.
Case-management является компонентом для обработки инцидентов, например, входящее письмо. Система выводит на экран обзор всей информации о
случае на одном экране и дает возможность электронной маршрутизации объекта другим пользователям. Case, так же как и Record содержит
настраиваемую и весьма гибкую сеть статусов. Каждому виду caseможно присвоить свою статусную схему.
Case– является интегрирующим компонентом, содержащим в себе следующие три основные части (Рис.10):
Функции (push-buttonв верхней части рисунка);

Атрибуты (средняя часть рисунка);
Компоненты (нижняя часть рисунка).
Функции обеспечивают обработку действий выполняемых пользователем в процессе жизненного цикла case. Технически функции обрабатываются во
внедрениях BADI. Бизнес примером реализации функции может служить отправка экспресс-оповещения сотруднику, инициировавшему процесс
рассмотрения документа с указанием о необходимости внесения изменений в рассматриваемый документ.
Рис.10. Общий вид case
Атрибуты – метаданные, описывающие caseкак сущность, где часть заполняется - автоматически, часть – вручную (Рис.11). Существует широкий
спектр настройки свойств каждого атрибута: обязательность, невидимость, журналирование (сохранение в таблицах изменений) и т.д. Кроме того, при
настройке атрибуты можно разделить на группы по их смысловому содержанию.
Рис.11. Атрибуты Case
Компоненты – «связанные» с caseобъекты и приложения. В стандартной поставке, SAP предлагает достаточное большое количество преднастроенных
компонент. Мы же - рассмотрим компоненты SAP, позволяющие обеспечить возможность постановки задач по обработке документов:
а) «Соединенные объекты» (casemodel) - аналогичны recordmodelи позволяют осуществить прикрепление к рассматриваемому случаю любых
настроенных ET (Рис.12). В нашем случае, это могут быть сервисные провайдеры вида documentили record. В случае сложных процедур
согласования, можно построить «дерево» из задач, каждая из которых будет, в свою очередь, подлежать согласованию на уровне своей
маршрутной схемы.
Рис. 12. Соединенные объекты
б) «Путь выполнения» - маршрут движения case (задачи) по исполнителям. Можно использовать как преднастроенный путь выполнения, так и
формировать свой в процессе маршрутизации. Формирование пути исполнения достаточно гибко и позволяет использовать возможности как
последовательной, так и параллельной маршрутизации документа (Рис.13). Для каждого добавляемого в путь рассмотрения пользователя (US–
логин, S– штатная должность, O– организационная единица) есть возможность установки следующих параметров (Рис.14):
Вид деятельности – номер задачи TS (WorkFlow) подлежащей исполнению данным обработчиком;

Сроки (самое позднее время окончания обработки, время обработки);
Полномочия по изменению схемы маршрутизации;
Приоритет шага (самый высокий приоритет ознаменуется отправкой обработчику экспресс-сообщения при получении им case).
Рис.13. Представление пути маршрутизации case
Рис.14. Добавление пользователя в путь маршрутизации
Компонента содержит в своем составе журнал пути маршрутизации, что позволяет осуществлять контроль сроков на уровне каждого сотрудника
(Рис.15).
Рис.15. Журнал пути маршрутизации.
Необходимо отметить, что использование маршрутизации Caseна основании WorkFlow позволяет использовать при внедрении такие «классические»
возможности, как и календари, контроль сроки, ведение заместителей, переадресация и т.д.
в) компонент «примечание» предназначен для ведения переписки между пользователями в процессе маршрутизации case (Рис.16).
Рис.16. Лента действий.
4) Формирование номенклатуры дел.
В соответствии с ГОСТ Р 51141 - 98 «Делопроизводство и архивное дело», номенклатура дел - систематизированный перечень наименований дел,
заводимых в организации, с указанием сроков их хранения, оформленный в установленном порядке.
FilePlan, в классическом его образе, представляет структуру вида «дерево». К листовым элементам FilePlan может быть присвоено 1 или несколько
элементов и решаемой нами задачи – это непосредственно документы. Удобство работы с FilePlan заключается в построении структуры хранения
документов любой глубины.
Рис.17. Внешний вид номенклатуры дел.
5) Поиск документов (атрибутный и полнотекстовый). Журналы регистрации и реестры документов.
Несомненным достоинством RCM является расширенные возможности поиска всех указанных выше объектов. В зависимости от вида объекта,
используются различные виды поисковиков, которые условно можно разделить на полнотекстовые и атрибутные. В случае с атрибутным поиском для
recordи document, можно использовать два вида поисковиков. Первый – вызывается на основании контекстного меню при выборе объекта (Рис.18).
Характерной особенностью указанного поисковика, кроме использования классических вариантов для настройки select-screen, является дополнительная
возможность использования так называемого «Архива списка» - списка ранее выбранных объектов. Причем, при повторном использовании «Архива
списка», поиск значительно ускоряется за счет хранения в базе данных ранее выбранных объектов. Для каждого атрибута contentmodelи recordи
documentсуществует возможность настройки видимости на уровне полей выбора.
Рис.18. Поискrecord иdocument.
Интересной возможностью является использование так называемого общего поиска, работающего на основании общих атрибутов для различных
видов объектов. К примеру, атрибуты contentmodel – «Уникальный идентификатор», «Описание», «Автор» и т.д. применяютсяв любой contentmodel, что
позволяет эксплуатировать их для поиска различных объектов посредством одного поискового запроса.
Рис. 19. Общий поиск.
Для указанных выше поисковиков характерно создание преднастроенных вариантов, позволяющих получить на основании их, журналы регистрации и
реестры всех ведущихся в системе документов.
Для Case характерно подключение отдельного средства поиска посредством указания для SPSCMG_SP_CASE_LOCATOR.
Рис.20. Поиск case.
Так же необходимо отметить возможности полнотекстового поиска по документам с использованием trex. В стандарте указанная возможность
реализуется с помощью DocumentFinder.
Напоследок, хотелось бы так же упомянуть о расширенных возможностях RCM, которые напрямую не относятся к процессу обеспечения
документационной поддержки предприятия, но, тем не менее, существенно расширяют функционал системы:
Настройка меню транзакций scaseи organizer, в соответствии с ролью пользователя;

Возможность формирования фаворитов и ведения повторного представления объектов (системы напоминаний);
Возможность просмотра истории, последних обработанных элементов;
Возможность осуществлять поиск не только по документам, но и по объектам системы, в связи с прикрепленными к ним документами,
и т.д.
Необходимо отметить, что SAP- RCM для внедрения СЭД наиболее эффективно, если в компании уже используются какие-либо бизнес-приложения SAP.
В этом случае имеется ряд преимуществ, а затраты на интеграцию в несколько раз ниже, чем при создании СЭД на основе любого другого решения. Кроме
того, весьма удобной представляется возможность обработки документов из объектов системы (бизнес-объектов), опираясь на один и тот же привычный
пользователю интерфейс. В этом случае само внедрение пройдет гораздо «мягче», чем при внедрении систем с различными интерфейсами и не вызовет
негатива со стороны пользователей.
Автор статьи: Остапко Александр Сергеевич, системный архитектор ООО «Сайнер», является кандидатом технических наук, сертифицированным
специалистом AIIM ECM Practitioner, имеет сертификат по SAP Business Work ow with SAP NetWeaver 7.0. С SAP работает с 2005 года. Специализация:
построение систем документационного обеспечения предприятия. Технические навыки: DMS, RCM, WorkFlow, ABAP. Связаться можно по адресу
Ostapko_AS@sciener.ru
Ключевые слова: Управление документооборотом

Функциональная область: Управление документооборотом / Document Management
Ролевое назначение: Руководитель / Manager, Ключевой пользователь / Expert, SAP Консультант / Consultant
Нравится 12 Не нравится
Комментарии:
Галина Нудьга (Рейтинг: 37) 14:49, 01 апреля 2015
Здравствуйте.
У системы много возможностей, но хотелось бы узнать и о недостатках.
Любое воспроизведение запрещено. Копирайт © «Издательство ООО «Эксперт РП»
18+ © 2009 - 2020, Издательство ООО «Эксперт РП». Все права защищены Сообщество Разработка и поддержка сайта — OpenStart
Связаться с нами support@sapland.ru
Политика конфиденциальности
Републикация материалов — только со ссылкой на SAPLAND.RU, с разрешения редакции сайта. Редакция не несет ответственности за высказывания пользователей на сайте.

Построение Системы Электронного Документооборота На Rcm - Sapland

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Построение Системы Электронного Документооборота На Rcm - Sapland

Загружено:

Авторское право:

Доступные форматы

26.02.

Построение системы электронного документооборота на Record and Case management System

Системы обработки структурированной информации – класса ERP(SAP);

1. DMS – Document Management System

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.9. Настройка record модели

Функции (push-buttonв верхней части рисунка);

Рис.10. Общий вид case

Рис.11. Атрибуты Case

Рис. 12. Соединенные объекты

Вид деятельности – номер задачи TS (WorkFlow) подлежащей исполнению данным обработчиком;

Рис.13. Представление пути маршрутизации case

Рис.14. Добавление пользователя в путь маршрутизации

Рис.15. Журнал пути маршрутизации.

Рис.16. Лента действий.

4) Формирование номенклатуры дел.

Рис.17. Внешний вид номенклатуры дел.

5) Поиск документов (атрибутный и полнотекстовый). Журналы регистрации и реестры документов.

Рис.18. Поискrecord иdocument.

Рис. 19. Общий поиск.

Рис.20. Поиск case.

Настройка меню транзакций scaseи organizer, в соответствии с ролью пользователя;

Ключевые слова: Управление документооборотом

Любое воспроизведение запрещено. Копирайт © «Издательство ООО «Эксперт РП»

Вам также может понравиться