Система компьютерного ведения документации

прекрасная программа автоматизации документооборота окажется напрасным

вложением средств, если модель одномерная или плоская.

Нет большого смысла говорить о жизненном цикле документов без связи с

основными бизнес-процессами предприятия. Система автоматизации

документооборота, функционирующая в отрыве от всех слоев, будет мертва,

мало того, она может нанести вред: запутать и без того неуправляемые бизнес-

процессы, отвлечь персонал от выполнения основной работы ради поддержания

системы автоматизации документооборота, по сути дела, ничего не

автоматизирующего. И, как следствие, раздувание штатного расписания и

дискредитация самой идеи автоматизации делопроизводства. Знакомая ситуация

- все работники заняты, работа кипит, однако если рассмотреть две разные

фирмы имеющие равный доход, занимающиеся одним бизнесом, то штат

сотрудников у одной из них будет вдвое больше, чем у другой.

В некоторых организациях положение усугубляется еще болезнью роста -

привычка все делать своими силами играет роковую роль в деле автоматизации

деятельности компании. Если уже стали достоянием прошлого надежды, что

купив компьютер, можно сразу решить все проблемы; то с наличием на рынке

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

предубеждение, что достаточно приобрести коробку с соответствующей

программой и, опять-же, проблемы будут решены. Компьютер или программы типа

workflow - это только голый инструмент, неумелое использование которого

чаще всего влечет за собой только вред, а не долгожданное облегчение и

освобождение от внутрикорпоративных проблем по управлению.

10.4. Один пример из жизни предприятия

Два завода отгружают продукцию друг другу, например, руду вагонами. От

поставщика приходят счета фактуры, которые попадают в канцелярию

потребителя, откуда направляются по двум адресам: бюро цен и финансово-

расчетная группа. Первые проверяют корректность цен, с тем, чтобы поставщик

не завысил цену, ставят свою отметку и пересылают счета в отдел материально-

технического снабжения (МТС) для уведомления. Вторые делают запись в

реестре о передаче счета в МТС и его оплате.

Даже в такой простой схеме в результате обследования была выявлена

черная дыра, через которую уходили значительные средства потребителя. Отдел

МТС сопоставляет суммы, полученные от финансово-расчетной группы с объемами

руды, фактически пришедшей в вагоне от поставщика. Как правило цифры

отличаются; если реальный показатель не меньше данных, указанных в счетах,

то все подтверждается и сделка завершена, если меньше, то, тем не менее

счета оплачивают, но выставляют претензии на фактически недопоставленный

объем сырья. Далее в дело вступает юридический отдел, который оформляет

претензии и переправляет их поставщику. В итоге, все отделы свою работу

выполнили, однако на вопрос "проходила ли реально доплата или допоставка по

претензиям" ответа никто дать не смог. Ни одна из служб не отслеживала факт

получения ответа от поставщика и оплаты претензий.

В контексте предложенной модели для данного случая точка, описывающая

положение системы документооборота предприятия была очень близко

расположена к нулю по осям "Фактография" и "Регламент". Иногда, правда,

факт недостачи обнаруживался - тогда начинало действовать координационное

бюро, цель которого - проводить сверки счетов поставщика и потребителя.

Нетрудно видеть, что работа этого лишнего подразделения отнимает массу

времени, отвлекает от работы другие подразделения, требует больших затрат

на командировки. Всего этого можно избежать, если построить систему

автоматизации на модели, где учитывалось бы вся необходимая фактография, а

достаточно высокое значение координаты по осям "F" и "D" позволяло бы

автоматически обнаруживать дырки в регламенте, а также организовывать

проверки и контроль без аврала и привлечения дополнительных ресурсов.

11. Пример построения документооборота на основе программы Staffware

Электронный документооборот, реализуемый с помощью программных систем

класса workflow представляет собой автоматизированный процесс управления

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

их группами внутри организации. Системы данного класса не только

регламентируют правила, маршруты и расписание движения документов но и

представляют собой технологию, позволяющую перевести теоретические выводы

BPR (Business Process Re-design) в практическую плоскость, причем

достаточно быстро и при минимальных первоначальных затратах. Для того чтобы

оценить важность и актуальность работ по автоматизации документооборота

достаточно взглянуть на некоторые цифры. Рынок систем класса workflow

ежегодного растет на 30-35%, а по данным компании Delphi Consulting в 2000

году стоимость этого рынка оценивалась в 5.34 млрд. долл. Около 80% крупных

организаций и корпораций начали проводить у себя работы в направлении

автоматизации документооборота, причем в 1999 году уже 65% всех более-менее

крупных компаний имели на вооружении системы класса workflow. По мнению

ряда аналитиков к 2001 году пользователи будут расходовать на мероприятия,

связанные с автоматизацией делопроизводства до 7 млрд. долл. в год. Сегодня

эта цифра составляет 4 млрд. долл.

Рынок программных средств достаточно быстро отреагировал на

актуальность проведения процесса автоматизации делопроизводства для бизнеса

- сегодня имеется около десятка инструментальных систем, позволяющих

заказчикам самостоятельно или с помощью консалтинговых компаний провести у

себя на предприятии внедрение электронного документооборота. Типичным

представителем таких систем, является пакет Staffware компании Stawffare

plc., вобравший в себя современные достижения автоматизации

делопроизводства и занимающий сегодня почти половину европейского рынка

среди продуктов такого класса. Пакет работает на 12 языках в 50 странах

мира.

Независимо от того, какая именно программа из класса workflow

используется для автоматизации делопроизводства ее функционирование

начинается с описания бизнес процессов, происходящих на конкретном

предприятии, задания регламента их взаимодействия, моделирующего реальную

производственную обстановку, отладки и, наконец, собственно работы с

реальными потоками документов. По мнению некоторых аналитиков, одной из

сильных сторон Staffware является инструмент, с помощью которого можно

описать самые, казалось бы, сложные и запутанные бизнес-процедуры.

Учитывая, что предприятие заказчика - это не застывшее раз и навсегда

образование, а постоянно действующий организм, развитие которого

подразумевает изменение бизнес-процедур, смену аппаратной и программной

платформы, появление новых средств автоматизации для архитектуры системы

Staffware были предложены адекватные решения.

11.1. Архитектура Staffware

В основу архитектуры системы были положены три принципа:

независимость, открытость и интегрированность. С появлением

Internet/intranet все эти принципы получили еще одно измерение - WWWW

(World Wide Web Workflow) как аппарат работы с глобальными компьютерными

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

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

парадигму клиент/сервер, позволяя строить как одноузловые конфигурации,

например Unix-сервер, вокруг которого размещается множество рабочих мест

(Windows, NT, OS/2, удаленный терминал типа VT100, Macintosh), так и

многоузловые, содержащие несколько серверов, работающих под управлением ОС

Unix или NT и оперирующих своим подмножеством клиентов. Клиентский

компонент Staffware имеет пользовательский интерфейс, настроенный на

конкретную прикладную область и отражающий очередь рабочих заданий

сотрудника компании или организации. Данный интерфейс - своеобразное окно в

систему электронного документооборота, он может интегрироваться с широким

спектром программных продуктов: текстовые процессоры, офисные системы

управления делопроизводства, различного рода записные книжки, блокноты и

т.п.

Связь между клиентом и сервером осуществляется при помощи механизма

удаленного вызова процедур (RPC), позволяющего одной программе использовать

сервис другой. С точки зрения клиента и сервера логическое взаимодействие

осуществляется на локальном уровне, реально же сервер располагается обычно

на другой аппаратной платформе, а взаимодействие осуществляется по

протоколу TCP/IP.

На рисунке 10 представлена диаграмма организации взаимодействия,

принятая в системе Staffware.

[pic]

Рисунок 10.

Диаграмма организации взаимодействия в системе Staffware.

Кроме коммуникационного слоя (TCP/IP/ и sockets, UUCP, NFS, X.400),

система Staffware имеет несколько слоев, содержащих функциональные зоны, в

совокупности реализующие три основных компонента системы: представление

информации, реализация логики конкретного приложения и доступ к данным.

Слой пользовательского интерфейса предназначен для удовлетворения всех

специфических для конкретной прикладной области запросов оператора,

работающего с системой: оформление экрана, организация ввода запросов и

получение ответов. Прикладной слой обеспечивает интерфейс с системой

workflow и призван экранировать пользователя от конкретных деталей работы с

данными, получаемыми от сервера: инициация рабочей сессии, запуск и

удаление процессов, управление очередями заданий и т.п. Файловый интерфейс

обеспечивает прозрачный доступ к данным со стороны прикладного интерфейса:

выборка логических записей из базы данных, их конвертирование в

специфическую для каждой конкретной СУБД форму, а также ряд других

операций, призванных экранировать все вышележащие слои от конкретных

особенностей используемых систем хранения данных.

Данная организация позволяет реализовать принцип естественного отбора:

без нарушения работы всей системы электронного документооборота корпорации

заказчика и существующей инфраструктуры проводить модернизацию аппаратного

и программного обеспечения, выбирая оптимальные решения. Кроме

независимости от сетевой, аппаратной, программной технологии, а также от

типа СУБД, эта архитектура обеспечивает возможность постепенного

масштабирования, начиная от индивидуальных рабочих мест, к рабочим группам

и далее до масштабов отделений корпорации, разбросанных по всему миру.

11.2. Возможности настройки

Сам по себе пакет Staffware - это интегрированный набор

инструментальных средств, не зависящих от конкретной прикладной области.

Одна из главных целей, которую преследует архитектура Staffware - это

гибкость при работе с самыми разнообразными приложениями. Как известно, не

бывает двух полностью идентичных компаний, предприятий или государственных

организаций - везде обязательно существуют свои нюансы организации

делопроизводства. Поэтому средства описания конкретных бизнес-процессов

предприятия заказчика занимают значительную часть в общей концепции

Staffware.

11.2.1. Описание бизнес-процедур

Процесс описания включает спецификацию шагов процедуры, для каждого из

которых задается его цель, исходные данные и порядок действий пользователя.

На рисунке 11 представлена структура определения бизнес-процесса для

системы Staffware.

[pic]

Рисунок 11.

Структура определения бизнес-процесса.

Различаются два основных типа шагов: нормальный шаг, автоматический и

событие.

Нормальные шаги предназначены для организации взаимодействия с

конечными пользователями и ассоциируются с конкретными методами работы с

ними: экранные формы Staffware, аппарат PowerSoft PowerBuilder, Informix

New Era и др. Автоматический шаг применяется для автоматизации некоторых

видов деятельности, связанных с определенным шагом, например, вызов

внешнего приложения без участия пользователя: изменение базы данных, печать

письма или вывод изображения.

Шаг типа "событие" применяется для управления ходом выполнения

процедуры, ставя его в зависимость от специальных условий, возможно,

внешних процедур. С помощью механизма напоминания и ожидания можно

синхронизировать нормальные шаги в общей системе документооборота в

соответствии с событиями, в той или иной степени оказывающими влияние на

текущую процедуру: получение письма-запроса от поставщика продукции,

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

документом и т.п. Другим назначением шагов данного типа является создание

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

нюансы делопроизводства, обычно возникающие в средних и крупных

организациях различных видов собственности. На рисунке 12 приведена

структурная схема выполнения шагов процедуры.

[pic]

Рисунок 12.

Схема выполнения шагов процедуры.

По аналогии с языками программирования для управления ходом выполнения

процедуры предусмотрены операторы ветвления по условию, циклы и средства

распараллеливания.

Для работы с шагами процедуры можно использовать наборы данных,

называемых "множество выбора", позволяющие упростить процесс заполнения

полей экранных форм. Различаются четыре типа данных: скаляр (текст, числа,

дата, время, валюта), переменная - текстовое поле, которым можно

манипулировать как целым, приложение - имя файла, используемое в качестве

дополнения к одной из выбранных пользователем альтернатив, композиция -

таблица базы данных вместе с данными из других полей.

11.2.2. Конструкторы

Средой выполнения процедур в Staffware служит Графический Конструктор

(Построитель) Процедур (GWD), позволяющий анализировать и описывать

сценарии реальных бизнес-процессов, отражающих различные виды деятельности.

Данный инструмент предназначен прежде всего для специалиста в конкретной

прикладной области и не требует глубоких знаний архитектуры и технических

особенностей аппаратной и программной платформы.

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

наглядно отображать потоки выполнения бизнес-процедур. Все правила

выполнения регламента запоминаются в виде программы, на языке

программирования, которая может быть подвергнута любой модификации и

отладке. Такая программа отличается динамичностью, она способна

настраиваться на конкретные условия и перезагружать бизнес-процедуры.

На рисунке 13 приведен пример конкретного представления бизнес-

процедуры, подготовленного с помощью конструктора GWD и отражающего точку

зрения конечного пользователя.

[pic]

Рисунок 13.

Пример представления процедуры средствами графического конструктора

потоков.

Для определения экранных форм, используемых при работе с конечным

пользователем применяется Конструктор Графических Форм (GFD). В полях формы

пользователь может вводить запросы системе путем заполнения полей,

ассоциированных с определенной процедурой. Данные в этих полях могут

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

рода ссылки, информация, генерируемая при выполнении предыдущих процедур)

либо вручную. Разумеется, для заполнения полей может быть организован

доступ к любой информации, во внешних базах данных, текстовых процессорах

или файлах, размещаемых на сервере.

Интересной особенностью GFD являются интеллектуальные формы, меняющие

свой формат и наполнение в зависимости от контекста: регламента выполнения

бизнес процедуры или типа данных, например:

IF

Только первое поле

- текстовый блок

ELSE

Все поля формы

- текстовые блоки

ENDIF

Кроме этого имеется возможность задавать порядок вывода информации в

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

содержание, вычисляемое значение, скрытое содержание поля.

Для расширения возможностей GFD, не предусмотренных при первоначальной

настройке можно использовать специальное поле "Command", где указываются

операторы вызова внешних программ или манипуляции с данными из полей формы.

В разных местах определения процедуры можно указывать уравнения,

используемые для вычисления данных по значениям полей. Такие выражения

применяются для выполнения вспомогательных вычислений, проверки

корректности данных, определения условий перехода в операторах ветвления и

т.п. В выражениях можно использовать обычные арифметические и логические

операции: сложить, вычесть, эквивалентность, неравенство, больше/меньше и

присваивание.

11.2.3. Макрокоманды

Макрокоманды или сценарии представляют собой наборы операторов,

которые можно поместить в любое место выполнения процедуры. Типичный пример

использования макрокоманд - постоянно повторяющийся обмен данными между

Staffware и приложениями Windows через аппарат DDE.

Язык описания сценариев является достаточно мощным средством

программирования системного окружения, позволяя на базе Staffware

разрабатывать различные приложения. Основные операторы языка - условные

переходы IF ELSEIF ENDIF и циклы WHILE

WEND.

Внутри программ описания сценариев обычно помещаются функции, которые

могут вызываться и в любом другом месте Staffware. Сегодня имеется восемь

Страницы: 1, 2, 3, 4, 5, 6, 7