лекция 4 по документированию управленческой деятельности. Лекция 4. Лекция 4 по дисциплине Документационное обеспечение делового общения на тему Компьютерные технологии документационного обеспечения управления
 Скачать 0.63 Mb.
|
|
Action WorkFlow, StaffWare, IBM FlowMark, WorkRoute II. Рассмотрим компоненты АДП-систем высшего класса. • Методология описания деловых процессов. В настоящее время без адекватной методологии трудно проектировать сложные деловые процессы. Это в основном связано с тем, что деловые процессы не являются некой жесткой структурой и меняются в течении жизни предприятия по самым разным причинам. К таким причинам можно отнести как изменяющиеся внешние условия жизни предприятия, так и естественное желание руководителя оптимизировать внутренние деловые процессы с целью высвобождения ресурсов и экономии средств. В результате мы имеем задачу с неопределенными внешними условиями. Следовательно, ее можно решать только через некий абстрактный уровень, который можно легко и быстро модернизировать и приводить в соответствие с настоящей или желаемой ситуацией. Далее АДП-приложение использует этот абстрактный уровень для своей работы. В настоящее время с методологией описания деловых процессов существуют определенные проблемы. Самой распространенной методологией на сегодняшний день является методология направленного графа. Истоки этой методологии лежат в истоках АДП-систем. Первые АДП-системы были созданы для деловых процессов производственного (даже конвейерного) толка, где сотрудники выполняли роль неких автоматов, работающих над конкретной технологической операцией. Сотрудник мог только выполнить операцию и доложить о ее выполнении. В некоторых случаях он мог сделать выбор между несколькими состояниями и принять решение о дальнейшем направлении движения делового процесса. В дальнейшем АДП-системы стали применяться для задач управления предприятием. Здесь такая методология не совсем подходит, так как она совершенно не учитывает влияние человека на конкретный деловой процесс. Если в конвейерной задаче мы можем им пренебречь, то в разработке контракта, где человек является главной производящей силой, влияние человека на конкретный бизнес-процесс огромно. Оно может носить как отрицательный характер — человек забывает, поступает вопреки логике, просто не хочет выполнять ту или иную работу, так и положительный характер — человек проявляет творчество, изобретательность при исполнении делового процесса. В том случае, если методология не учитывает реалии жизни, она все свои недостатки перенесет в АДП-приложение. Среди методологий, ориентирующихся на человека как главную производительную силу делового процесса, можно отметить ме- тодологию компании Action Technologies. В качестве элементарной составляющей делового процесса она рассматривает некий цикл, который построен между заказчиком и исполнителем работы. В этот цикл включены все возможные действия, могущие возникнуть в процессе взаимодействия двух сотрудников, например отказ от выполнения работ, контрпредложение, отклонение контрпредложения и т.п. Цикл имеет следующие параметры: условия завершения, время завершения и стоимость процесса. Грубо говоря, цикл от Action — это заранее предопределенная совокупность направленных графов, которая полностью описывает взаимодействие двух персон. Последовательно запрещая все возможные действия, вы можете свести весь цикл к одному графу, который соединяет двух персон. Данная методология особенно хороша тем, что она целостна (система не допустит незамкнутой схемы), а это означает, что ни одно задание не потеряется и не зайдет в тупик. Обычно к методологии прикладывается графический редактор, который позволяет в удобной форме проектировать карты деловых процессов. • Преобразователь методологии в конкретное АДП-приложение. Данный модуль выступает связным звеном между методологией и конкретным АПД-приложением. Обычно это некий конвертор, который, исходя из карты деловых процессов и их заданных параметров (роли, персоны, время исполнения и т.п.), формирует базу данных с соответствующей структурой и наполнением, а также создает триггеры, которые отслеживают выполнение бизнес-правил. • Модуль исполнения АДП-приложения. Данный модуль взаи- модействует со сформированными преобразователем методологии данными, программами и исполняет их. • Рабочее пространство пользователя. Можно сказать, что речь идет о рабочем месте пользователя и его интерфейсе. Он может быть отдельно стоящим, встроенным в какое-либо приложение или использующим для своей работы интерфейсы других программ. Каким бы образом интерфейс пользователя ни был бы организован, сколько кнопочек и бантиков на нем бы ни было, построение у всех одно и тоже. Это окно входящих заданий к пользователю и окно исходящих заданий от пользователя. Для каждого задания показывается его состояние и прочие его характеристики. Кроме составных частей, которые описывают практически любую АДП-систему, необходимо помнить, что АДП-системы не должны работать напрямую со списком конкретных сотрудников, а только через список ролей, которые могут исполнять конкретные сотрудники. Использование ролей позволяет: • связывать структуру предприятия с конкретными деловыми процессами, что очень немаловажно; • связывать деловые процессы с ролями, а не сотрудниками. Есть сотрудник, нет сотрудника, обязанности все равно остаются; • динамически переназначать сотрудников на роли, что позволит системе более гибко реагировать на изменения, происходящие на предприятии; • более гибко управлять заданиями. Например, посылать задание на исполнение всем «менеджерам» и т.д. Модели архитектуры АДП-систем различаются по типу ориентации. 1. Ориентированы на документ. В своей основе они рассматривают документ и процесс его движения между сотрудниками. Системы, ориентированные на документ, в архитектурном построении идут от почтовых систем. Самой сильной стороной такой модели является поддержка удаленных пользователей и офисов, поддержка работоспособности системы в самых разнообразных операционных и сетевых средах, поддержка множества типов клиентов и серверов. Непреодолимая слабость такого подхода — это сложность в управлении правилами деловых процессов. Так, система не предназначена с самого начала отслеживать деловой процесс, все попытки сохранить информацию в недрах системы не приводят к приемлемому результату. При таком подходе часто бывает трудно, а иногда невозможно определить текущий статус данного делового процесса. Кроме того, в приложениях, которые построены на таком подходе и которые маршрутизируют документ, документ становится недоступным никому, кроме получателя почты. Это довольно значительное ограничение в приложениях, когда требуется непрерывный доступ к документу. 2. Ориентированы на деловой процесс или на задание как составную часть делового процесса. Данные системы возникли от попыток не просто автоматизировать движение документов, а от попыток взглянуть на весь процесс управления предприятием в целом. Основная логика построения таких систем может быть выражена следующим образом: деловой процесс — задание — документ. К заданию может быть прикреплен документ, а может и нет. В реальной жизни подход от задания или делового процесса является более общим в документоориентированном подходе. Поэтому внимание уделяется не только поддержке документа (в реальных системах эти функции отдаются на откуп системам управления документами, см. выше), а в основном поддержке деловых процессов. Единственным местом, где можно хранить и обслуживать информацию о деловых процессах, является база данных со всеми ее преимуществами и недостатками. В таком случае мы можем следить за состоянием и историей каждого задания и каждого делового процесса. Недостатки же связаны с трудностью организации распределенных систем и особенно с поддержкой удаленных пользователей. В случае, когда удаленный пользователь может регулярно подсоединяться к центральной базе данных, эти проблемы решаются, но что делать если он находится в Владивостоке и единственная надежная связь — это электронная почта. Управление электронным документом ориентируется на реализацию принципа «конкретные документы конкретному исполнителю точно вовремя». Его реализация позволит значительно повысить эффективность и обоснованность принятия решений, сократить информационную инерционность ДОУ, удовлетворить информационные потребности ЛПР-экспертов. |