Жесткая.

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

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

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

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

• Системы со свободным движением документов с контролем доставки и
  прочтения - это обычные системы электронной почты.
  С помощью
  дополнительного программирования к ним можно добавить еще и контроль
  выполнения.
  
• Системы со свободным движением документов и со всеми функциями
  контроля исполнения, включая мониторинг, извещения и историю - это класс
  специализированных маршрутизаторов. К ним можно отнести маршрутизатор
  Компании ВЕСТЬ WorkRoute 1.0
  
• Системы с жестким движением документов и со всеми функциями контроля
  исполнения - это высший класс АДП-систем. К ним можно отнести Action
  WorkFlow, StaffWare, IBM FlowMark, WorkRoute II.

Рассмотрим компоненты АДП-систем

высшего класса, как наиболее неизвестного российскому
пользователю класса систем.

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

Кроме составных частей, которые описывают практически любую АДП-систему

, необходимо
помнить, что АДП-системы не должны работать напрямую со списком конкретных сотрудников,
а только через список ролей, которые могут исполнять конкретные сотрудники. Использование
ролей позволяет

• связывать структуру предприятия с конкретными деловыми процессами, что
  очень немаловажно
  
• связывать деловые процессы с ролями, а не сотрудниками, что имеет,
  естественно, более общую постановку. "Есть сотрудник, нет сотрудника,
  обязанности все равно остаются".
  
• динамически переназначать сотрудников на роли, что позволит системе
  более гибко реагировать на изменения происходящие на предприятии.
  
• более гибко управлять заданиями. Например, посылать задание на
  исполнение всем "менеджерам" и т.д.

После того, как мы обрисовали то, какие бывают и из чего состоит АДП-система, необходимо
поговорить об архитектуре построения систем. Относительно архитектурного построения таких
систем идут большие дебаты между специалистами в этой области. Что лучше, все хотят знать.
Но мир устроен таким образом, что не существует абсолютного оружия для всех целей. И ставить
вопрос, что лучше, не разумно. Лучше спросить, что лучше в моем случае, для моей конкретной
задачи. Обратимся к архитектурным моделям. В основном, они различаются по типу
ориентации

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

Какую модель выбрать для своей системы, это в основном зависит от Вас, от стиля работы


Вашего предприятия, от задач, которые стоят перед Вами. В жизни, никогда не побеждают
крайности и последние версии ряда АДП-систем доказывают нам это. Корпорация KeyFile
выпустила новую АДП-систему, которая в качестве транспортного механизма использует
Microsoft Exchange, а объектную базу данных собственной разработки для информационного
хранилища для деловых процессов. Также имеет право на жизнь и обратный подход, к
существующей АДП-системе основанной на базе данных прицепить почтового клиента,
который поддерживает удаленных пользователей
Все вышеизложенное выше не претендует на всесторонний анализ проблемы работы с
электронными документами, но он может быть оказаться полезным для выбора той или иной
системы. В данном обзоре, я не пытался дать какие либо рекомендации по выбору то или иного
конкретного программного продукта, так как рекомендации должны быть всегда привязаны к
конкретным требованиям и условиям заказчика. Эйфория об абсолютном оружии на все случаи
жизни была, но быстро прошла по мере погружения в проблему. Компания ВЕСТЬ имеет в своем
портфеле набор программных продуктов, которые закрывает определенные задачи. Но понимая
то, что каким бы хорошим продукт не был, он не решит все задачи, которые иногда возникают в
гениальном мозгу заказчика, нам пришлось обобщая накопленный опыт создавать новые
программные продукты, которые дополняют функционал уже имеющихся. Почему же не
написать все с нуля, задаст вопрос проницательный читатель. Идеи написания своей
операционной системы, системы управления документами и подобных сложных управляющих
комплексов посещают людей или никогда не писавших программы в своей жизни

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

[]
[]
[]

Содержание раздела

---

---

---

Главная сайта

---