Визуальное программирование бизнес-процессов

На Российском рынке наступил период, когда Заказчики желают самостоятельно развивать и поддерживать информационные системы без привязки к вендорам и интеграторам. Для систем СЭД стали востребованны визуальные редакторы бизнес-процессов и карточек документов. Эти же идеи сейчас активно эксплуатируются маркетингом крупных производителей ЕСМ-систем.

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

Типичные запросы на изменения

В общих чертах, изменение функционала в системах документооборота требует следующих вещей

  • Создание и изменение типов документов (серверная часть)
  • Описание действий над документами и поручениями (карточки задач, пользовательский интерфейс)
  • Справочники

Работа с типами документов

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

Работа с карточками документов и задач

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

  • Описание выбора значений из справочников, в том числе иерархических, с фильтрацией и удобным интерфейсом
  • Разбивку карточки документа на логические разделы. Например: отдельные закладки для информационных полей, для маршрута, для истории документа, для связанных поручений итд
  • Поддержку внесения записей, содержащих ссылки на другие объекты системы. Например: запись в истории о рассмотрении должна ссылаться на визу, запись в талице поручений должна ссылаться на конкретное поручение, запись в таблице связанных документов должна ссылаться на связанный документ итд
  • Описание взаимосвязей между полями (если выставлена галка «Контрольное поручение», loan fees amortization то поле «Контрольный срок» доступно для редактирования итд)
  • Редактирование иерархических структур, например списка согласования из этапов и сотрудников на каждом этапе.
  • Сложные варианты валидации данных по сочетаниям нескольких полей, в том числе из справочников. Например: поле отчет должно быть обязательно заполнено в случае если поручение контрольное и при этом контрольный срок еще не наступил.
  • Видимость полей в зависимости от сложных условий. Например, если согласование не является обязательным для документа, то в маршруте не нужно показывать этап с пустыми списками согласующих.
  • Использование сложных правил для автоматически заполняемых полей. Например — формирование регистрационного номера документа.
  • Крайне желательно управление расположением – простой список полей в столбик хорош не всегда

Сколько-нибудь подходящего решения для создания веб-интерфейсов с такими возможностями к сожалению не существует. (А если бы существовал, то сложность освоения такого инструмента была бы выше чем сложность освоения nys deferred compensation loans простого языка программирования) Современное состояние стандартизации в этой области привело к тому, что существует W3C стандарт XForms для описания пользовательских интерфейсов, но визуальные редакторы на его основе сколько-нибудь сложные формы редактировать не в состоянии.

Работа с installment loan poor credit описаниями бизнес-процессов

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

  • Часть широко распространенных loans 100 в российском документообороте практик, например выдача поручений с перепоручениями, не описываются в терминах бизнес-процессов (такие действия как выдача перепоручения или перенос срока не приводят к продвижению по схеме бизнес-процесса, поэтому описать их на схеме невозможно)
  • Единственное средство взаимодействия с пользователем при описании процесса с помощью bpm-редактора – назначение на пользователя задачи. Единственные возможные действия со стороны пользователя– это открытие задачи, заполнение карточки и нажатие кнопки Submit. Если мы хотим описать процесс с выдачей пользователю нескольких форм (начальная форма, реакция сервера, вторая форма), то это можно описать только как назначение на пользователя нескольких задач (типичный пример — регистрация документа сразу после создания его в системе). При этом с точки зрения эргономики решение не выдерживает никакой критики – после заполнения первой формы пользователь должен будет найти и открыть новую задачу самостоятельно. На практике обычно обе формы объединяют в одну задачу, а взаимодействие с сервером программируют вручную – его не будет видно в схеме бизнес-процесса, и ценность последнего как отражения реальных процессов организации резко падает

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

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

Задачи которые следует решать при помощи визуального программирования процессов.

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

В таких применениях использование высокоуровневых визуальных инструменов вполне оправдано и успешно поскольку задача абсолютно соответствует инструменту. В качестве примеров таких применений можно назвать процессы автоматизации для Электронного правительства (когда БП monthly loans no credit check автоматизируется между несколькими ведомствами), процессы автоматизации структур, использующих несколько разнородных систем в одном бизнес-процессе (Например: сквозной процесс: Склад — СЭД — ERP — Отчетность)

Выводы

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

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