Этим постом я начну небольшой цикл статей, посвящённых различных аспектам разработки приложений в системе электронного документооборота. Сегодня все более или менее мощные и современные СЭД/ECM-платформы содержат набор компонентов и инструментов для их реализации, и именно приложения, создаваемые на базе платформы, позволяют автоматизировать все разнообразие рабочих процессов клиента. Я расскажу о модели приложения платформы Docsvision, о компонентах и средствах разработки (настройки) этих приложений, о том, какие проблемы возникали у нас при реализации инструментария для их разработки, и о том, чего ждём в дальнейшем. Это будет интересно не только тем, кто плотно работает с Docsvision, но и позволит почерпнуть опыт тем, кому предстоит внедрять или развивать свою корпоративную СЭД.
Приложение современной СЭД. Определимся с терминами.
Современная СЭД/ECM-платформа – инструмент автоматизации самых разнообразных процессов обработки документов в компаниях различного масштаба. По сути, сама платформа не содержит законченной клиентской функциональности, а предоставляет набор сервисов, компонентов и инструментарий для ускоренного создания приложений на базе платформы. Ситуация чем-то похожа на ситуацию с ERP-платформами (Enterprise Resource Planning), где в каждом внедрении требуется существенная кастомизация, учитывающая особенности процессов конкретной компании. Однако уровень вариативности конкретных автоматизируемых процессов в СЭД даже выше, чем в ERP: практика показывает, что номенклатура задач, для реализации которых используются СЭД/ECM-платформы, сегодня практически не ограничена.
Определимся с терминами.
Приложением СЭД мы будем называть средства автоматизации конкретного изолированного рабочего процесса для решения определенного набора задач.
Несмотря на то, что стандарты и наборы типовых требований к платформам СЭД/ECM пока отсутствуют, все более или менее мощные платформы содержат набор компонентов и инструментов для реализации приложений. И структура приложений, выполненных на различных платформах, может существенно отличаться. В этой серии статей мы рассмотрим структуру приложений, создаваемых на базе платформы Docsvision. Как я отметил выше, эта информация может пригодиться и бизнес-аналитикам компаний, занимающихся разработкой аналогичных приложений.
Концепция приложения СЭД. От идеи к архитектуре.
Пойду в хронологическом порядке и начну с пары слов о том, что предшествовало разработке текущей архитектуры платформы (которая началась в 2000 году). Мы уже имели достаточно богатый опыт реализации приложений: сначала на базе разных платформ, затем был опыт проекта Docsvision 1.0, на котором было реализовано около десятка проектов и который пришлось закрыть и полностью переписать систему (новая архитектура, включающая модель приложения, о которой мы будем говорить, оказалась гораздо адекватней и развивается до сих пор). Именно этот опыт работы с различными решениями позволил нам выделить несколько ключевых идей для формирования следующей концепции приложений в комплексной СЭД.
Эти приложения могут использоваться в двух сценариях:
— Для внедрения AS-IS (реинжиниринговое внедрение, когда организация готова изменить имеющуюся структуру бизнес-процесса в соответствии с функциональностью приложения);
— В качестве начальной базы, модифицируемой с учетом специфики процесса в организации в том случае, когда реинжиниринговое внедрение невозможно.
Безусловно, эти требования не позволяют реализовывать приложения СЭД традиционным способом (независимое кодирование отдельных приложений). Очевидно, необходима платформа, интегрирующая все приложения и инструменты их быстрой разработки и модификации приложений.
Архитектура платформы
К счастью, на момент формирования новой архитектуры платформы мы уже имели опыт работы с системами различного класса:
Эти классы платформ имели совершенно различную идеологию и модель приложения, но все они в той или иной мере были применимы для создания приложений по обработке документов, которые требовались нашим клиентам. Правда, ни одна из них не была идеальной. Платформы групповой работы обеспечивали удобные инструменты навигации и неплохие инструменты работы со структурированной информацией о документах; DMS системы позволяли реализовать полный набор механизмов работы с неструктурированными данными (файлами), а Workflow инструментарий неплохо подходил для организации маршрутизации документов и последовательностей обработки файлов и электронных форм.
Беда заключалась в том, что для создания платформы, которая позволила бы реализовать приложения, соответствующие сформулированным нами выше требованиям (положениям), какой-то одной платформы было недостаточно. Например, система Lotus Notes на тот момент обладала крайне слабыми возможностями по обработке неструктурированной информации (возможность хранения файлов в RTF полях), в ней полностью отсутствовал инструмент моделирования процессов. К тому же, каждое приложение на базе платформы (база данных) было информационно изолировано, и для организации взаимодействия между приложениями требовались существенные усилия разработчиков – кодеров.
В итоге в основу архитектуры новой версии платформы Docsvision была положена модель приложения, совмещающая преимущества моделей приложений перечисленных систем.
Модель приложения Docsvision, 5 компонентов
Модель приложения Docsvision включает следующие основные компоненты:
1. Карточка – основной объект системы, который позволяет смоделировать любой прикладной объект приложения. Наиболее типичными объектами в приложениях СЭД являются карточки документов (входящий, исходящий договор) и заданий (задание на исполнение, задание на согласование).
2. Справочник – специальный вид карточки, существующий в системе в единственном экземпляре и позволяющий сохранять самую разнообразную справочную информацию, в частности, иерархически организованную.
Рис.1. Карточка приложения Docsvision
3. Процесс – объект, моделирующий последовательность выполнения действий в рамках приложения, группы взаимосвязанных приложений или на уровне системы. Процесс включает как ручные этапы (взаимодействия пользователя с карточками или внешними объектами) и автоматические этапы, реализуемые сервисом, для обеспечения логики обработки процесса.
Рис.2. Процесс Docsvision
4. Папка – объект, обеспечивающий группировку карточек. В системе имеются обычные папки — группируют карточки, которые в них созданы, либо посредством физического размещения в них ярлыков на карточки (аналогично папкам файловой системы) — и виртуальные, которые группируют карточки по соответствию определенным критериям (результатам поиска)
5. Представление — групповое представление набора карточек в виде таблицы или набора строк. В ячейках таблицы отображаются атрибуты карточек, их агрегаты и результаты выполнения расчетных операций.
Рис.3. Папки и представление приложения СЭД Docsvision
Любители системы Lotus Notes наверняка увидели много аналогий, это действительно так, Docsvision многое унаследовал от этой системы. Однако мы разрабатывали платформу с нуля, что позволило избежать многих ограничений Lotus Notes и реализовать в Docsvision много полезных и конструктивных идей.
Любое приложение является комбинацией определенного набора из перечисленных выше элементов. И для соответствия описанным выше требованиям к приложениям были реализованы следующие возможности.
Рис.4. Структура приложения Docsvision
Возможности приложений новой модели
Клиентские компоненты (навигатор и пр.) обеспечивают пользователю единую унифицированную систему навигации, поиска и доступа к данным всех приложений и справочных данных, к которым ему предоставлены права доступа.
Описанные возможности новой модели приложения обеспечили фундамент для реализации на базе Docsvision самых различных решений для совершенно разных отраслей, при этом позволив решить проблему размещения всех приложений в единой интегрированной среде.
В следующих статьях мы более подробно рассмотрим отдельные компоненты модели приложений Docsvision и дадим примеры реализации конкретных решений с использованием этих инструментов.
P.S. В последнее время эксперты стали отмечать интеграцию рынков ECM, BPM, Groupware и рождение новой парадигмы платформ, объединяющих достоинства этих технологий. Мы наблюдаем эти тренды с удовлетворением, т.к. осознали необходимость этой конвергенции еще 15 лет назад, и, более того, реализовали ее в конкретном продукте.
Приложение современной СЭД. Определимся с терминами.
Современная СЭД/ECM-платформа – инструмент автоматизации самых разнообразных процессов обработки документов в компаниях различного масштаба. По сути, сама платформа не содержит законченной клиентской функциональности, а предоставляет набор сервисов, компонентов и инструментарий для ускоренного создания приложений на базе платформы. Ситуация чем-то похожа на ситуацию с ERP-платформами (Enterprise Resource Planning), где в каждом внедрении требуется существенная кастомизация, учитывающая особенности процессов конкретной компании. Однако уровень вариативности конкретных автоматизируемых процессов в СЭД даже выше, чем в ERP: практика показывает, что номенклатура задач, для реализации которых используются СЭД/ECM-платформы, сегодня практически не ограничена.
Определимся с терминами.
Приложением СЭД мы будем называть средства автоматизации конкретного изолированного рабочего процесса для решения определенного набора задач.
Несмотря на то, что стандарты и наборы типовых требований к платформам СЭД/ECM пока отсутствуют, все более или менее мощные платформы содержат набор компонентов и инструментов для реализации приложений. И структура приложений, выполненных на различных платформах, может существенно отличаться. В этой серии статей мы рассмотрим структуру приложений, создаваемых на базе платформы Docsvision. Как я отметил выше, эта информация может пригодиться и бизнес-аналитикам компаний, занимающихся разработкой аналогичных приложений.
Концепция приложения СЭД. От идеи к архитектуре.
Пойду в хронологическом порядке и начну с пары слов о том, что предшествовало разработке текущей архитектуры платформы (которая началась в 2000 году). Мы уже имели достаточно богатый опыт реализации приложений: сначала на базе разных платформ, затем был опыт проекта Docsvision 1.0, на котором было реализовано около десятка проектов и который пришлось закрыть и полностью переписать систему (новая архитектура, включающая модель приложения, о которой мы будем говорить, оказалась гораздо адекватней и развивается до сих пор). Именно этот опыт работы с различными решениями позволил нам выделить несколько ключевых идей для формирования следующей концепции приложений в комплексной СЭД.
- Платформа должна позволять создавать приложения не только для автоматизации сугубо специфических задач «российского документооборота» (документационного обеспечения управления и создания архива электронных документов). Она должна обеспечить автоматизацию широкой номенклатуры так называемых документоцентричных процессов — тех, в которых документы являются центральным объектом обработки.
- Процессы обработки документов могут включать различные виды документов (включающих структурированные и неструктурированные данные, имеющих сложный жизненный цикл и бизнес-логику обработки). В процессе обработки информация может передаваться из одного документа в другие.
- Приложения не являются изолированными. Информация, порождённая в одном приложении, может быть передана в другие.
- Процессы, автоматизируемые приложениями на базе платформы СЭД, имеют специфику в каждой конкретной организации, и, соответственно, требуют адаптации приложения при внедрении.
- Процессы в конкретной организации также не являются стабильными, и могут достаточно часто модифицироваться.
- Для наиболее типовых задач, вариативность которых (и процессов в них) в разных организациях не столь велика, требуется наличие готовых «коробочных» приложений. (Сегодня такими приложениями для нашей СЭД являются «Делопроизводство», «Управление договорами», «Обращения граждан», «Управление совещаниями» и ряд других).
Эти приложения могут использоваться в двух сценариях:
— Для внедрения AS-IS (реинжиниринговое внедрение, когда организация готова изменить имеющуюся структуру бизнес-процесса в соответствии с функциональностью приложения);
— В качестве начальной базы, модифицируемой с учетом специфики процесса в организации в том случае, когда реинжиниринговое внедрение невозможно.
- Должна поддерживаться возможность создавать приложения, глубоко специфичные для конкретной отрасли или организации с нуля.
- Различные приложения могут содержать общие функции, элементы данных и компоненты доступа. Например, средства хранения и управления файлами, разделяемые справочники (контрагенты, сотрудники), категории документов, ссылки между документами в различных приложениях, средства уведомлений и пр. Система должна поддерживать общие механизмы работы с этими функциями и данными для всех приложений.
- Необходимо иметь единые инструменты, обеспечивающие навигацию, поиск, агрегированные табличные представления данных, которые обеспечивают доступ к документам из различных приложений. Например, поиск всех документов, содержащих ссылку на конкретного контрагента, вне зависимости от приложения, в которых они создавались.
- Приложения не изолированы в рамках СЭД и могут требовать интеграции с другими подсистемами корпоративной информационной системы.
Безусловно, эти требования не позволяют реализовывать приложения СЭД традиционным способом (независимое кодирование отдельных приложений). Очевидно, необходима платформа, интегрирующая все приложения и инструменты их быстрой разработки и модификации приложений.
Архитектура платформы
К счастью, на момент формирования новой архитектуры платформы мы уже имели опыт работы с системами различного класса:
- платформами создания приложений коллективной работы (Lotus Notes, Microsoft Exchange),
- системами класса Document Management System (DMS), понятия ECM тогда еще не было,
- Workflow-системами (термин «BPM система» тогда еще так огульно не применялся к любым средствам, содержащим Workflow движки).
Эти классы платформ имели совершенно различную идеологию и модель приложения, но все они в той или иной мере были применимы для создания приложений по обработке документов, которые требовались нашим клиентам. Правда, ни одна из них не была идеальной. Платформы групповой работы обеспечивали удобные инструменты навигации и неплохие инструменты работы со структурированной информацией о документах; DMS системы позволяли реализовать полный набор механизмов работы с неструктурированными данными (файлами), а Workflow инструментарий неплохо подходил для организации маршрутизации документов и последовательностей обработки файлов и электронных форм.
Беда заключалась в том, что для создания платформы, которая позволила бы реализовать приложения, соответствующие сформулированным нами выше требованиям (положениям), какой-то одной платформы было недостаточно. Например, система Lotus Notes на тот момент обладала крайне слабыми возможностями по обработке неструктурированной информации (возможность хранения файлов в RTF полях), в ней полностью отсутствовал инструмент моделирования процессов. К тому же, каждое приложение на базе платформы (база данных) было информационно изолировано, и для организации взаимодействия между приложениями требовались существенные усилия разработчиков – кодеров.
В итоге в основу архитектуры новой версии платформы Docsvision была положена модель приложения, совмещающая преимущества моделей приложений перечисленных систем.
Модель приложения Docsvision, 5 компонентов
Модель приложения Docsvision включает следующие основные компоненты:
1. Карточка – основной объект системы, который позволяет смоделировать любой прикладной объект приложения. Наиболее типичными объектами в приложениях СЭД являются карточки документов (входящий, исходящий договор) и заданий (задание на исполнение, задание на согласование).
2. Справочник – специальный вид карточки, существующий в системе в единственном экземпляре и позволяющий сохранять самую разнообразную справочную информацию, в частности, иерархически организованную.
Рис.1. Карточка приложения Docsvision
3. Процесс – объект, моделирующий последовательность выполнения действий в рамках приложения, группы взаимосвязанных приложений или на уровне системы. Процесс включает как ручные этапы (взаимодействия пользователя с карточками или внешними объектами) и автоматические этапы, реализуемые сервисом, для обеспечения логики обработки процесса.
Рис.2. Процесс Docsvision
4. Папка – объект, обеспечивающий группировку карточек. В системе имеются обычные папки — группируют карточки, которые в них созданы, либо посредством физического размещения в них ярлыков на карточки (аналогично папкам файловой системы) — и виртуальные, которые группируют карточки по соответствию определенным критериям (результатам поиска)
5. Представление — групповое представление набора карточек в виде таблицы или набора строк. В ячейках таблицы отображаются атрибуты карточек, их агрегаты и результаты выполнения расчетных операций.
Рис.3. Папки и представление приложения СЭД Docsvision
Любители системы Lotus Notes наверняка увидели много аналогий, это действительно так, Docsvision многое унаследовал от этой системы. Однако мы разрабатывали платформу с нуля, что позволило избежать многих ограничений Lotus Notes и реализовать в Docsvision много полезных и конструктивных идей.
Любое приложение является комбинацией определенного набора из перечисленных выше элементов. И для соответствия описанным выше требованиям к приложениям были реализованы следующие возможности.
Рис.4. Структура приложения Docsvision
Возможности приложений новой модели
- Каждый их элементов приложения (карточка, процесс, папка и представление) может быть модифицирован без модификации остальных компонентов. Например, если последовательность согласования документа изменилась, то можно перестроить процесс, не затрагивая другие компоненты приложения. По ходу возникновения новых функциональных требований в приложении могут создаваться новые объекты и подключаться к уже имеющимся.
- Для всех перечисленных компонентов системы имеются интерактивные конструкторы, которые позволяют как создавать приложения «без программирования», так и легко вносить изменения в уже работающие приложения.
- Поддерживаются низкоуровневые программные интерфейсы, которые позволяют реализовывать функциональность, недоступную для средств интерактивного моделирования.
- Отдельные приложения не изолированы друг от друга, доступ к отдельным объектам приложения разграничивается только правами доступа.
- Все приложения в системе используют общую структуру справочной информации.
- Один бизнес-процесс может работать с объектами, созданными в рамках различных приложений.
- Одна папка может группировать карточки, созданные в различных приложениях.
- Одно представление может отображать данные из карточек, созданных в различных приложениях.
- Карточки одного приложения могут содержать ссылки на карточки любого другого приложения, к которому пользователь имеет права доступа.
Клиентские компоненты (навигатор и пр.) обеспечивают пользователю единую унифицированную систему навигации, поиска и доступа к данным всех приложений и справочных данных, к которым ему предоставлены права доступа.
Описанные возможности новой модели приложения обеспечили фундамент для реализации на базе Docsvision самых различных решений для совершенно разных отраслей, при этом позволив решить проблему размещения всех приложений в единой интегрированной среде.
В следующих статьях мы более подробно рассмотрим отдельные компоненты модели приложений Docsvision и дадим примеры реализации конкретных решений с использованием этих инструментов.
P.S. В последнее время эксперты стали отмечать интеграцию рынков ECM, BPM, Groupware и рождение новой парадигмы платформ, объединяющих достоинства этих технологий. Мы наблюдаем эти тренды с удовлетворением, т.к. осознали необходимость этой конвергенции еще 15 лет назад, и, более того, реализовали ее в конкретном продукте.