Главная страница
Навигация по странице:

  • 5.6 Интеграция СЭД с системой интеллектуального анализа выполнения бизнес

  • 5.7 Обзор отечественных систем электронного документооборота.

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


    Скачать 3.12 Mb.
    НазваниеРеферат вопрос о необходимости автоматизации управления документооборотом давно перешел в практическую плоскость, и все больше российских предприятий внедряют у себя системы электронного документооборота,
    АнкорРазработка автоматизированной системы для документооборота
    Дата21.06.2022
    Размер3.12 Mb.
    Формат файлаpdf
    Имя файлаm_th_nechukhin_2014.pdf
    ТипРеферат
    #607275
    страница11 из 12
    1   ...   4   5   6   7   8   9   10   11   12
    5.5 Организация хранения журналов выполнения бизнес-процессов.
    Для хранения журналов в базе данных необходимо разработать ее структуру, учитывающую особенности работы алгоритмов восстановления МАБП (построение причинно- следственных матриц) [13]. В связи с тем что записей в журнале, как правило, очень много и они непрерывно добавляются, необходимо обеспечить высокую скорость добавления новых записей
    (что влияет на скорость работы системы электронного документооборота) и высокую скорость получения информации о задачах, пользователях, экземплярах бизнес-процессов, движении документов, подразделениях (что влияет на производительность системы интеллектуального анализа). Анализ МАБП происходит относительно редко, что является также существенным фактором в разработке архитектуры хранилища данных [14].
    Системы управления автоматизированными процессами располагают средствами поддержки выполнения бизнес-процессов, предоставляющими предписанные заранее модели, в которых журналы содержат информацию по экземплярам задач, выполняемым в каждом экземпляре процесса.
    В целях улучшения архитектурных характеристик хранилища под МАБП понимается множество взаимосвязанных между собой задач, участников и зависимостей между ними. Задачи связаны с индивидуальными шагами в бизнес-процессе, участники (информационные системы или

    107 люди) отвечают за выполнение задач, и, наконец, зависимости определяют, в какой последовательности будут выполняться задачи.
    Описание хранилища данных можно разделить на две части: описание прикладного программного представления хранилища (классов и зависимостей между ними) и структуры базы данных.
    Диаграмма классов для работы с журналами выполнения МАБП.
    Динамические и статические аспекты хранения журналов могут быть представлены посредством следующих сущностей:
     «Подразделение».
     «Пользователь».
     «Роль».
     «Участник».
     «Экземпляр составной задачи».
     «Экземпляр элементарной задачи».
     «Экземпляр внешней задачи».
     «Экземпляр задачи».
     «Экземпляр МАБП».
     «МАБП».
     «Задача».
     «Составная задача».
     «Внешняя МАБП».
     «Элементарная задача».
     «WFМодель».
     «Элемент модели».
     «Переход модели».
     «СпецПереход».
     «Инцидент задачи модели».
     «Инцидент контроля модели».
    Опишем наиболее важные связи между сущностями:
     «Подразделение» ссылается на родительское и дочерние подразделения, представленные объектом типа «Подразделение».
     «Участник» является наследником сущностей «Роль» и «Пользователь».
     «Экземпляр составной задачи» содержит экземпляр сущности «Экземпляр МАБП».

    108
     «Экземпляр задачи» ссылается на предыдущую и последующую задачи в МАБП типа «Экземпляр задачи», использует «Экземпляр МАБП», содержит ссылку на дочерний объект типа «Экземпляр составной задачи».
     «Экземпляр МАБП» является экземпляром «МАБП», содержит экземпляр
    «Участник».
     «МАБП» ссылается на автора МАБП типа «Участник», использует объект типа
    «Задача», является наследником сущности «Задача», ссылается на сущность
    «СпецИнцидент».
     «Задача» является наследником «Внешняя МАБП», ссылается на объект типа
    «Составная задача».
     «Составная задача» ссылается на объект типа «СпецИнцидент».
    МАБП, которую мы здесь предполагаем, при проектировании хранилища может быть представлена с использованием различных техник: структурированных или неструктурированных
    МАБП, в стиле текстовых языковых конструкций или в стиле грифовых интерпретаций.
    Диаграмма классов состоит из нескольких уровней. Уровень спецификации содержит описание типов МАБП и типов задач совместно с их композицией посредством происшествий
    (рис. 26). Уровень модели содержит расширенные спецификации МАБП, например инциденты задач могут иметь расширенные характеристики (время завершения, агенты и т.п.). Уровень экземпляров содержит информацию о характеристиках выполнения конкретных экземпляров задач и МАБП. И наконец, организационный уровень содержит информацию об участниках, их ролях, структуре всего предприятия.
    МАБП состоит из задач, которые в свою очередь могут быть МАБП, внешними МАБП
    (моделями бизнес-процессов, находящихся в другом домене), элементарными задачами, составными задачами. Составные задачи состоят из других задач, представленных как инциденты в составной задаче. Модель допускает наличие иерархической зависимости между задачами, в которой указываются родительская и дочерние задачи. Внутри составной задачи частная задача может иметь несколько инцидентов, что однозначно идентифицируется сущностью инцидент.
    Инцидент ассоциирован в точности с одной задачей и представляет место, где задача была использована в спецификации составной задачи. Каждый инцидент, между тем, имеет разных предшественников и последователей, что выражается ассоциативным классом «СпецПереход».
    Есть две причины, по которым произведено выделение сущностей «Задача» и «Инцидент задачи». Во-первых, это возможность повторного использования задачи в разных МАБП. Во- вторых, это упрощение поддержки, что подразумевает изменение лишь одного подпроцесса, влекущего за собой автоматическое изменение МАБП, в которых он используется. Это подразумевает, что новые МАБП могут быть получены путем композиции из существующих

    109 задач. Такая композиция называется спецификацией процесса. Идентификация множественного вхождения очень важна с точки зрения обработки хранилища журналов выполнения, так как это позволяет агрегировать данные о выполнении в различных позициях МАБП и даже в различных
    МАБП.
    Когда задача используется несколько раз в рамках одной МАБП, мы также различаем инциденты, обозначая итоговые элементы с использованием сущности «Элемент модели».
    Аналогично уровень спецификаций МАБП содержит информацию об элементах модели, иерархиях и отношениях переходов в этих элементах модели.
    На уровне экземпляров классы «Экземпляр МАБП», «Экземпляр задачи» используются для представления экземпляров МАБП и их задач во время выполнения. Аналогично МАБП экземпляр МАБП состоит из экземпляров задач, для которых описаны предшествующие и последующие задачи. Кроме того, экземпляр МАБП всегда соответствует в точности одной
    МАБП.
    Participant (участник) ответственен за выполнение бизнес-процессов. В этой метамодели участник может быть смоделирован с помощью пользователей и ролей. В идеальном случае должна использоваться концепция роли, которая дает более обобщенное описание пользователей.
    Однако в метамодели непосредственное описание единственного пользователя также возможно.
    Обобщенно предполагается, что пользователи, роли и пользователи в некоторых ролях могут участвовать в различных бизнес-процессах различных структурных подразделений организации.
    Разработка метамодели хранения данных определяется набором информации, который может представить система управления автоматизированными бизнес-процессами, и потребностями системы интеллектуального анализа выполнения бизнес-процессов. Тем не менее, каждое хранилище данных должно быть адаптировано под специфические черты конкретной корпоративной информационной системы (КИС). Здесь показывается прототипное хранилище данных, в каждом конкретном случае возможно внесение незначительных изменений для хранения большей или меньшей информации по выполнению процессов.
    Рассмотрим более подробно взаимодействие хранилища выполнения бизнес-процессов и хранилища статистики их выполнения. Основным компонентом бизнес-системы является миссия предприятия, определяющая назначение компании, ее значимость для общества и направление деятельности. С точки зрения организации бизнеса, изменение миссии эквивалентно построению новой компании. Практически столь же устойчивой является иерархия целей предприятия и стратегия его развития. Изменения в развитии являются, как правило, следствием таких внешних событий, как технологическая революция, радикальное изменение условий рынка или законодательства. Критические факторы успеха и состав тактических задач по реализации сформированных планов периодически пересматриваются на основе анализа тенденций развития

    110 рынка и статистики результатов деятельности. Определение результатов деятельности и подсчет значений показателей эффективности проводится столь часто, сколь это возможно для конкретного сектора рынка, групп изделий, услуг, клиентов, поставщиков и т.д. Однако и в этом случае достоверные данные являются результатом накопленной статистики, хотя и за менее продолжительный период. Все последующие компоненты входят в состав корпоративной информационной системы, задачей которой является информационная поддержка выполнения бизнес-процессов и принятие управленческих решений. При этом динамику развития этой системы в наибольшей степени определяют собственно бизнес-процессы. С точки зрения организации бизнес-системы основной задачей технологии управления автоматизированными бизнес-процессами является отделение правил выполнения бизнес-процессов от прикладных систем и систем управления базами данных, что обеспечивает принципиально большую гибкость и адаптируемость информационной системы. Иными словами, технология управления автоматизированными бизнес-процессами предоставляет возможность оперативной модификации правил выполнения бизнес-процессов без перестройки прикладного программного обеспечения или изменения структуры корпоративной базы данных.
    Другим важным направлением использования технологии управления автоматизированными бизнес-процессами служит интеграция различных приложений и данных вокруг бизнес-процесса. В этом отношении системы управления автоматизированными бизнес- процессами можно рассматривать как определенный шаг в развитии архитектуры открытых систем.
    Стандарты, разработанные WfMC, подтверждают эффективность и результативность усилий, нацеленных на развитие этого направления.
    Хранилище журналов не должно служить ограничением при изменении структуры бизнес- системы, правильным решением здесь было бы собирать данные посредством системы управления автоматизированным бизнес-процессами. При этом различные компоненты бизнес-системы можно свободно менять, не опасаясь за последствия.
    5.6 Интеграция СЭД с системой интеллектуального анализа выполнения бизнес-
    процессов.
    Хранение журналов выполнения бизнес-процессов организовано с использованием технологии OLAP для первоначальной агрегации, анализа и интерпретации информации. OLAP хранилища (Рисунок 5.10) отличаются от традиционных реляционных баз данных рядом аспектов: они разработаны для получения ответов на сложные вычислительные запросы в ущерб возможности сохранять большие массивы информации; также они отличаются, как правило,

    111 большими объемами хранимых данных; содержат данные за определенный период (снимок данных).
    Наиболее часто используемая архитектура для хранилищ данных – многомерные кубы данных, где транзакционные данные (ячейки, факты или измерения) описаны посредством иерархий измерений. В нашем случае транзакционными являются данные о выполнении задач бизнес-процесса в системе электронного документооборота, агрегированные в измерения.
    OLAP операции (детализация, обобщение, срезы, проецирование) позволяют аналитику быстро получать отчеты на различном уровне абстракции и рассматриватьданные с различных перспектив [45].
    Рисунок 5.10 - OLAP хранилище данных для журналов выполнения бизнес-процессов

    112
    В данном случае МАБП – это коллекция задач, участников и зависимостей между ними.
    Задачи соответствуют индивидуальным шагам в бизнес-процессе, участники (пользователи или программные подсистемы) отвечают за выполнение этих задач, зависимости определяют последовательность выполнения задач и потоки данных между ними.
    МАБП состоит из задач, которые могут быть в свою очередь либо МАБП, либо внешней
    МАБП, либо элементарной задачей, либо сложной задачей. Сложные задачи состоят из других задач, представленных как композиция.
    Структура хранилища данных определяется наличием информации в СЭД и потребностями аналитиков и используемых алгоритмов в системе интеллектуального анализа [9, 10].
    Помимо алгоритмов анализа системы, хранилищем могут пользоваться и системные администраторы, пользователи и администраторы WFMS, аналитики. Список возможных запросов:
     Как часто запускается конкретная МАБП? (Информация, полученная в результате этого запроса, может быть использована для идентификации ключевых процессов, которые подлежат пересмотру и оптимизации в первую очередь.)
     Какие задачи из этих МАБП наиболее часто используются?
     Выполнение каких МАБП регулярно не укладывается в сроки?
     Выполнение каких задач приводит к задержке по срокам?
     Каково количество просрочек?
     Как часто МАБП, вызывающие просрочки, инициируются к запуску?
     Как много различных пользователей участвуют в выполнении наиболее частых
    МАБП?
     Участие каких пользователей регулярно приводит к просрочкам?
     Какие из пользователей регулярно перегружены, а какие периодически имеют свободные ресурсы?
     Какие пользователи являются участниками данной МАБП?
     Сравнение характеристик различных версий МАБП.
     Анализ выполнения задачи в разных МАБП.
     Анализ выполнения задачи различными пользователями.
     Анализ производительности работы пользователей в разные периоды времени.
    Другим важным параметром анализа является время. Обнаружение пиковой загрузки может помочь решить проблемы оптимизации выполнения процесса (распределение нагрузки на серверы, распределение заданий между пользователями).
    Модель состоит из шести измерений:

    113
     МАБП;
     Участники;
     Подразделения;
     Серверы;
     Время;
     Измерения.
    Инциденты, необходимые для повторного использования, являются уровнем гранулярности
    [8] в измерении МАБП.
    Возможно несколько альтернативных путей для построения структуры измерения МАБП.
    Один из возможных – разделение задач и МАБП в два разных измерения с целью устранить проблему участия одной задачи в нескольких МАБП. Недостаток подобного подхода заключается в отсутствии возможности развернуть инциденты, ассоциированные с данной МАБП. Другой путь заключается в объединении инцидентов в значимые задачи и агрегировании этих задач соответствующими МАБП.
    В этом решении также обнаруживается недостаток: каждая задача может принадлежать множеству МАБП и их значения должны быть пропорциональны для каждой МАБП.
    Решение, предложенное в разработанном хранилище журналов, не содержит описанных выше недостатков. На первом этапе происходит объединение инцидентов в элементы, представляющие собой комбинации МАБП и задач. Далее эти элементы могут быть объединены в
    МАБП или задачи. В хранилище данных участие одной задачи в различных МАБП предоставляет возможность проанализировать параметры производительности этой задачи применительно к разным контекстам выполнения.
    Для представления пользователей и подразделений также существует несколько альтернатив. Во-первых, можно произвести разделение пользователей и их ролей по двум разным измерениям, где подразделения являются объединением пользователей. Смыслом подобного решения является потенциальная возможность каждого пользователя выступать в его департаменте в любой роли. На практике такого решения недостаточно, так как часто один пользователь может работать в нескольких подразделениях. В предложенном хранилище данных произведено разделение участников и подразделений на два различных измерения. Нижний уровень измерения участников представлен элементами – комбинацией пользователей и ролей.
    На следующем шаге эти элементы объединяются либо в пользователей, либо роли.
    Причиной для разделения пользователей и подразделений на разные измерения послужила возможность пользователей участвовать в различных МАБП от различных подразделений.

    114
    Введение измерения серверов имеет технические потребности и предоставляет возможность получить информацию о загрузке различных серверов, что может быть использовано для распределения нагрузки. Структура измерения серверов очень простая и самоописываемая.
    В измерении времени были выбраны календарные дни, которые объединяются в месяцы, кварталы и годы. Недели представлены в отдельной иерархии, так как в разных годах неделя может состоять в различных месяцах.
    Для измерения мер было выбрано следующее множество:
     время старта;
     время работы (время обновления – время старта);
     время простоя (ожидаемое время завершения – время обновления);
     время завершения;
     ожидаемое время завершения;
     ожидаемое превышение (время обновления – ожидаемое время завершения);
     превышение (время обновления – время завершения);
     среднее время работы.
    5.7 Обзор отечественных систем электронного документооборота.
    Российский рынок СЭД растет, и количество представленных систем постоянно увеличивается. Ниже приводится описание наиболее популярных систем с анализом возможности применения к ним методов интеллектуального анализа.
    «Docs Fusion» и «Docs Open». Это одна из самых популярных в мире систем, относящихся к классу «электронных архивов». Различные поколения и компоненты продукта получили различные названия, и поэтому при ознакомлении с ним возникает путаница. Изначально существовала система «Docs Open» – клиент-серверное приложение с «толстым» клиентом.
    Далее был разработан сервер приложений «Docs Fusion», позволивший избавиться от необходимости иметь «толстого» клиента, обращающегося напрямую к базе данных. К нему есть два клиента: Windows-клиент «PowerDocs» и Web-клиент
    «CyberDocs». Перспективной для компании является платформа «Docs Fusion». Для простоты мы далее будем называть систему словом Docs, имея в виду «Docs Fusion», и клиенты –
    «PowerDocs», «CyberDocs».
    В России система «Docs Open» представлена достаточно давно и уже применяется во многих организациях. «Docs Open» может эффективно применяться и в крупных организациях с большим числом сотрудников (тысячи человек), и в небольших фирмах, где работают пять-шесть человек. Система в первую очередь позиционируется для организаций, которые занимаются

    115 интенсивным созданием документов и их редактированием (головные офисы компаний, консалтинговые компании, органы власти и т.д.).
    Клиент «PowerDocs» – это «Windows»-интерфейс, по идеологии построения напоминающий «MS Outlook». Пользователь может обращаться к Docs через интерфейс самого
    «MS Outlook» и даже в окне «Windows Explorer», что позволяет работать с папками Docs как с обычной файловой системой. Клиент «PowerDocs» позволяет осуществить мобильный доступ с возможностью синхронизации при подключении, в том числе и по медленным линиям. Эта функция также позволяет обеспечить стабильную работу пользователя в режиме неустойчивой работы локальной сети. Клиент «CyberDocs» обеспечивает практически ту же функциональность, что и «PowerDocs», но через Internet-браузер.
    В одном комплексе может быть установлено несколько серверов «DocsFusion», при этом автоматически реализуется балансировка нагрузки и устойчивость к сбоям. Это значит, что при сбое одного из серверов пользователи почувствуют лишь некоторое замедление работы системы, а сама система действительно может обеспечить одновременную работу с ней достаточно большого количества пользователей. Для хранения данных системы необходимо использовать «Microsoft
    SQL Server» или «Oracle». В качестве хранилища для документов используется файловая система.
    Поддерживается механизм иерархического хранения данных HSM.
    Система позволяет осуществить интеграцию и стыковку с другими прикладными системами как на уровне клиента «PowerDocs», так и на уровне сервера. Docs – это открытая платформа, к ней поставляются средства разработки для создания специализированных приложений или интеграции с другими системами.
    Продукт не ориентирован на применение в области инженерно-конструкторского документооборота, в нем нет интеграции с системами CAD/CAM. В территориально распределенных организациях могут возникнуть проблемы, так как в системе нет механизмов репликации информации. В СЭД имеются средства поддержки совместной работы на уровне рабочей группы, однако для больших организаций этих средств недостаточно.
    «Documentum». «Documentum» — это система управления документами, знаниями и бизнес-процессами для крупных предприятий и организаций. Система только начинает внедряться в России, но уже давно и прочно заслужила позицию одного из лидеров индустрии. «Documen- tum» – это платформа, в большей степени, чем готовый продукт, предназначенная для создания распределенных архивов, поддержки стандартов качества, управления проектами в распределенных проектных группах, организации корпоративного делопроизводства, динамического управления содержимым корпоративных интранет-порталов.
    В продукте предусмотрено все, что нужно крупной организации, – это интегрированная система, позволяющая комплексно решать достаточно широкий спектр задач. Она включает

    116 необходимую функциональность для автоматизации деловых процессов: маршрутизацию, утверждение, распределение, уведомление и контроль исполнения. «Documentum» достаточно масштабируема, вся информация, которая хранится в системе, управляется выделенным серверным компонентом – хранилищем «DocBase». «Documentum» содержит механизмы, позволяющие управлять хранением информации: она поддерживает управление версиями, публикацией, доступом, местонахождением информации и дает возможность осуществлять архивацию. Система может эффективно работать в распределенной архитектуре в территориально разобщенных подразделениях благодаря реализованным механизмам репликации и синхронизации информации, а также централизованного администрирования.
    «Documentum» поставляется в нескольких редакциях, ориентированных на различные задачи: создание порталов, управление знаниями, обеспечение соответствия стандартам/управление качеством, организация B2B-взаимодействия. Важной особенностью для многих отраслей является возможность полного документирования всех событий и жесткого отслеживания выполнения определенных процедур.
    Продукт включает в себя средства, позволяющие создавать приложения в среде
    «Documentum», в том числе Web-приложения. Но для разработки приложений для «Documentum» и интеграции его с другими приложениями можно использовать и внешние средства разработки: продукт построен на современных открытых технологиях. Благодаря такой открытости для его внедрения в существующую информационную среду не потребуется существенных расходов на модификацию инфраструктуры. «Documentum» отличается мощной поддержкой форматов и средствами автоматической генерации файлов форматов PDF и HTML из любых хранимых данных. Одним из преимуществ использования этого продукта для промышленных предприятий является возможность его интеграции с ERP и CAD/CAM-системами.
    «Documentum» имеет относительно высокую стоимость внедрения за счет того, что является «конструктором», из которого собирается необходимая функциональность, и далек от
    «коробки», а кроме того, сложен в освоении, что является очевидной оборотной стороной его функциональной полноты. Поэтому оснащение этим продуктом отдельных рабочих групп или организаций с числом сотрудников порядка одного-двух десятков имеет мало смысла, разве что в случае, если предполагаются быстрые темпы роста.
    Безусловно, «Documentum» является одним из наиболее мощных продуктов, однако позволить себе такую систему могут только организации, которые очень серьезно относятся к задаче автоматизации документооборота и готовы выделить на нее достаточные финансовые и интеллектуальные ресурсы.
    Система «LanDocs». Система «LanDocs» в первую очередь ориентирована на делопроизводство и архивное хранение документов. Она состоит из нескольких компонентов:

    117 системы делопроизводства, сервера документов (архива), подсистемы сканирования и визуализации изображений, подсистемы организации удаленного доступа с использованием
    Internet-клиента, почтового сервера.
    Компонент делопроизводства реализован в клиент-серверной архитектуре на базе промышленной СУБД: «Oracle» или «Microsoft SQL Server». Программное обеспечение для централизованного управления хранением документов в электронном архиве реализовано в виде отдельного сервера. В качестве отдельной опции поставляется модуль полнотекстового поиска документов с учетом правил русского языка. Почтовая служба «LanDocs» сделана так, что сотрудники, у которых установлен специальный клиентский компонент «LanDocs», могут получать сообщения-задания и отчитываться по ним, используя стандартный почтовый ящик
    «Microsoft Exchange» или «Lotus Notes».
    Продукт открыт для разработчиков – имеется API для встраивания «LanDocs» в Windows- приложения сторонних разработчиков. Компонент сканирования и работы с изображениями имеет достаточно продвинутую функциональность: он позволяет фильтровать изображения, исправлять перекос, возникший после сканирования, распознавать текст в случае необходимости.
    Система «LanDocs» не ориентирована на поддержку коллективной работы и процесса создания документов.
    «Microsoft SharePoint Portal Server». Система является электронным архивом с развитыми средствами поддержки совместной работы. Поддерживает: совместное создание документов, ведение версий документов, изъятие и возврат документов в архив. В нем нет Windows-клиента как такового. Для доступа к архиву используется Web-клиент (сторонние разработчики могут дописывать для него свои компоненты) и компонент, интегрированный в «Windows Explorer», что позволяет обращаться к архиву как к набору файлов.
    В систему встроены достаточно мощные средства индексации и поиска. Причем поиск может осуществляться как по внутренним хранилищам информации (файлы, интранет-сайты, базы
    «Microsoft Exchange», базы «Lotus Notes»), так и по внешним (интернет). Система способна индексировать и публиковать документы, которые находятся в файловой системе на серверах локальной сети. В качестве альтернативы документы можно переместить в хранилище самого сервера (которое аналогично хранилищу «MS Exchange 2000»). Регистрационные данные о документах всегда помещаются в хранилище сервера, при этом нет необходимости в использовании отдельного сервера баз данных.
    Система достаточно открыта, к ней можно добавлять различные компоненты. Опора на
    Web-технологии делает такое трасширение технологичным.
    Продукт наиболее эффективен в качестве базы информационной инфраструктуры для компаний, которые делают ставку не на иерархическое управление, а на матричную организацию

    118 взаимодействия людей и плоскую структуру управления. Для традиционных фирм она может стать звеном в интранет-инфраструктуре для «оживления» последней, так как концепции, заложенные в эту систему, позволяют сделать процесс публикации информации на портале частью каждодневной работы с документами, не требующей особо сложных процедур, ресурсов и организационных усилий.
    Система «Oprima Workflow», кроме общего механизма организации потока работ, позволяет хранить на время проведения работ все документы, относящиеся к процессу. Для этого в качестве хранилища используется механизм общих папок «Microsoft Exchange». Полезной возможностью является отслеживание критических путей и представление комплекса взаимосвязанных работ в виде диаграмм Ганта. Впрочем, эту работу можно производить и в среде
    «MS Project» с использованием всех ее возможностей, так как «Optima Workflow» позволяет экспортировать данные о ходе работ в эту программу.
    Система автоматизирует процессы регистрации документов по правилам делопроизводства, реализует механизмы аннотирования и сбора резолюций, доставки отчетов об исполнении поручений.
    Тот факт, что «Optima Workflow» использует в качестве основного хранилища и транспорта
    «Microsoft Exchange», определяет все ее возможности по надежности хранения, защите от сбоев, возможности применения медленных линий связи, синхронизации данных, ограничения доступа к данным. Для регистрации версий документов используется СУБД, к которой осуществляется доступ через ODBC.
    Как уже указывалось выше при классификации систем, workflow-система удобна для формализации типовых процедур работы с документами в организациях, где такая работа является ежедневной практикой. Так как «Optima Workflow» в качестве сервера использует «Microsoft
    Exchange», его легко внедрить в тех компаниях, где он уже применяется по своему прямому предназначению – как почтовый сервер. Не нужно рассчитывать на то, что «Optima Workflow» позволит вам задействовать «Microsoft Exchange» в качестве электронного архива – для этого есть другие продукты, к примеру описанный выше «Microsoft SharePoint Portal Server». «Optima
    Workflow» хранит документы только в процессе, пока работы, связанные с ним, не завершены.
    Система «БОСС-Референт» относится к категории систем, ориентированных на поддержку управления организацией, эффективной работы сотрудников и на накопление знаний, и при этом имеет развитые дополнительные сервисы.
    Основное применение – создание корпоративной системы, охватывающей деятельность сотрудников на своих рабочих местах и поддерживающей управленческие бизнес-процессы.
    Поддерживает делопроизводство, организационное управление, согласование документов.
    Отличительная особенность ее в том, что, будучи полноценной системой документооборота, она

    119 уже обладает всей необходимой функциональностью для реализации делопроизводства. В ней с самого начала фигурируют понятия, роли и функции, присущие организациям со сложной иерархической структурой в России. Другая отличительная черта системы «БОСС-Референт»: в ней реализованы функции CRM-системы, контроля договоров, учета материальных ценностей, потокового сканирования и распознавания (в «БОСС-Референт» интегрирована система
    «FineReader»), электронной конференции и доски объявлений.
    Система реализована на платформе «Lotus Notes». Благодаря этому вдобавок к функциям
    «БОСС-Референт» пользователи получают в свое распоряжение все богатство функциональности самой среды «Lotus Notes», включая электронную почту, репликацию данных, возможность удаленной работы и т.д. «БОСС-Референт» является наиболее открытой во всех смыслах системой
    – она поставляется вместе с полными исходными текстами. К ней дополнительно прилагается инструментарий разработчика с полным описанием функций прикладного программного интерфейса.
    На «БОСС-Референт» стоит обратить внимание в первую очередь тем организациям, которые уже используют «Lotus Notes». Остальные должны отдавать себе отчет в том, что, выбирая эту систему, они получают и «Lotus Notes» в качестве основы своей информационной инфраструктуры и должны приобрести лицензию «Lotus Notes» на каждое рабочее место.
    Система «Дело», которая до недавнего времени называлась «Дело-96», является типичным представителем систем автоматизации делопроизводства и именно в этом качестве приобрела популярность у нас в стране. Продукт поддерживает идеологию делопроизводства, суть которой в следующем: чтобы было совершено любое действие в организации, нужен документ, для которого обеспечивается движение. Движение документов (при том, что физически они, естественно, не перемещаются) происходит за счет изменения учетных записей о документах в базе данных.
    Для хранения документов компания ЭОС недавно представила отдельный продукт, интегрированный с системой «Дело», обеспечивающий функции электронного архива. В системе реализован web-интерфейс, что удобно для организации удаленного доступа и построения интранет-порталов. Система имеет API, позволяющий интегрировать ее с различными приложениями. «Дело» хранит учетные записи средствами промышленной СУБД – «Oracle» или
    «Microsoft SQL Server»; осуществляет полное протоколирование действий пользователей с документами. Последняя версия интегрирована с системой распознавания «FineReader» для занесения в нее данных с бумажных документов.
    Продукт в первую очередь интересен для организаций, которые сталкиваются с необходимостью внедрения формализованного делопроизводства.
    «Евфрат» является простым электронным архивом с базовыми возможностями контроля исполнения.

    120
    «Евфрат» построен на парадигме «рабочего стола» с папками. Документы раскладываются по папкам, которые могут иметь любую степень вложенности. Собственного хранилища файлов
    «Евфрат» не имеет – система хранит только ссылки на файлы или на страницы в интернет. Для хранения реквизитов документов используется СУБД собственной разработки. В комплект продукта входят утилиты, позволяющие уплотнять и архивировать базу данных этой СУБД.
    Отличительной особенностью является возможность открыть и просмотреть любой документ поддерживаемого системой формата с помощью встроенной программы просмотра, правда, без форматирования и иллюстраций, что, впрочем, не составляет проблемы, так как документ можно открыть во внешнем «родном» приложении. К сожалению, «Евфрат» не дает возможности отслеживать получение и возврат документов и хранение версий, что может усложнить коллективную работу с документами. Система позволяет описать категории документов и приписать любой из категорий любые реквизиты.
    Для ввода информации с бумажных носителей в комплект продукта входит система потокового ввода, основанная на другом продукте компании – системе распознавания текстов
    «Cuneiform». По сути, «Евфрат» представляет собой средство сканирования, распознавания, регистрации документов, присвоения им реквизитов, индексации, полнотекстового поиска, назначения заданий, связанных с документом, и контроля их исполнения. Это недорогое решение, которое может оказаться полезным в малом офисе или на предприятиях, не предъявляющих высоких требований к масштабируемости информационной системы.
    Трудности, с которыми приходится сталкиваться при разработке сложных МАБП, стимулируют в последнее время разработку технологий восстановления моделей автоматизированных бизнес-процессов и интеллектуального анализа их выполнения в целом. Цель данной работы заключалась в автоматическом получении модели для процесса на основе аккумулированных в течение предыдущего выполнения данных. Существующие техники позволяют получить МАБП, хорошо подходящие для применения в WFMS, ввиду высокой актуальности (как следствия разработки на реальных данных выполнения МАБП).
    Несмотря на большой рост интереса к методам и алгоритмам интеллектуального анализа выполнения МАБП, все еще не существует системы, позволяющей их использовать при реальной работе аналитика. Авторами была разработана архитектура системы интеллектуального анализа, позволяющая реализовать существующие методы.
    Были сформированы и получены следующие основные выводы и результаты:
    1. Проведена классификация методов ИА и рассмотрены наиболее востребованные отрасли их практического применения.
    2. Сделана математическая постановка задачи ИА выполнения бизнес-процессов, а именно:
     задача получения комплексных WF-моделей;

    121
     задача поиска частых подпоследовательностей при данном журнале выполнения и
    МАБП.
    3. Разработан алгоритм получения комплексных WF-моделей на основе журнала выполнения.
    4. Разработаны два алгоритма поиска частых подпоследовательностей, а также произведен анализ их производительности на синтезированных данных.
    5. Разработана система интеллектуального анализа выполнения бизнес-процессов в управлении электронным документооборотом, а именно:
     архитектура взаимодействия компонент внутри системы с учетом особенностей рассмотренных методов и алгоритмов интеллектуального анализа;
     прикладные программные интерфейсы, предоставляемые системой с учетом обобщенных требований рассмотренных методов и алгоритмов интеллектуального анализа;
     структура хранения восстановленных журналов и сопоставленных с ними МАБП;
     хранилище данных, позволяющее интегрировать систему интеллектуального анализа с существующими СЭД.
    6. В предложенной системе интеллектуального анализа реализованы и апробированы на реальных данных алгоритмы восстановления комплексных WF-моделей, поиска частых подпоследовательностей.

    122
    1   ...   4   5   6   7   8   9   10   11   12


    написать администратору сайта