|
Система компьютерного ведения документациипараметрам: . По списку пользователей и системе безопасности. Это означает, что если вы собираетесь послать кому-то документ, то адресат должен обладать соответствующим набором прав для работы с этим документом. Если прав недостаточно, то система должна попросить инициатора работы или маршрута установить соответствующие права. . Интеграция с операцией публикования документа. Задача состоит в том, что после окончания маршрута документ, ассоциированный с маршрутом, меняет свой статус на опубликованный. В качестве примеров таких маршрутов можно привести процесс утверждения документа. Рассмотренные возможности обеспечивают построение любой частной системы документооборота на любом предприятии в любой предметной области. Естественно, для построения частного решения можно ограничивать функционал системы в зависимости от предъявляемых заказчиком требований. 9. Два подхода к организации хранения электронных документов На сегодняшний день применяется два подхода к организации хранения электронных документов. Первый состоит в том, что собственно тело документов хранится в файловой системе, второй предусматривает хранение документов в реляционной или специализированной базе данных. Второй подход хотя и обладает большей степенью защиты собственно документов, но несет в себе следующих ключевых недостатков: . трудности с поддержкой носителей информации, отличных от жестких дисков (только СУБД Informix поддерживает магнитооптические накопители) и практическая невозможность построения гетерогенных систем хранения; . при работе с приложениями, в которых создаются и изменяются электронные документы тела документов в любом случае проходят через файловую систему, а так как приложение не умеет работать напрямую с базами данных это означает удвоение числа операций записи и считывания с жесткого диска. При больших размерах тел документов это серьезно влияет на скорость работы. 9.1. О стандартах Как и любая область человеческой деятельности, сфера документооборота не могла избежать всеобщего веяния стандартизации и имеет свои проблемы. Проблема 1. Архивная система должна быть интегрирована с приложениями, в которых порождаются различные электронные документы. Желательно, чтобы эта интеграция была прозрачной для пользователя, который работал бы с архивной системой напрямую, минуя обращения к файловой системе. Следовательно, диалоги операций с файловой системой должны быть заменены на диалоги работы с архивной системой. Единственным решением удовлетворить как производителей приложений, так и производителей архивный систем является выработка единого стандарта взаимодействия между системами такого класса. Этой цели достигла первая версия стандарта ODMA (Open Document Management API). На сегодняшний день данный интерфейс поддерживается следующими производителями архивных систем: PC DOCS, Saros, Novell (Soft Solutions), Watermark, Documentum и со стороны производителей приложений компаниями Corel (Corel WordPerfect Suite) и Microsoft (Office 97). Проблема 2. Иногда предприятие использует одновременно несколько систем управления документами. В качестве примера можно привести транснациональную и многопрофильную корпорацию DuPont. В подразделениях, которые ведут разработку новых химических продуктов, исторически используют Documentum; новые подразделения остановили свой выбор на DOCS Open, как на более дешевом решении в расчете на одного пользователя. Соответственно возникает проблема, как пользователю с одного рабочего места иметь доступ к нескольким архивным серверам для поиска документов. Для обеспечения совместной работы нескольких архивных серверов предназначен стандарт ODMA версия 2. Впервые такая совместная работа серверов DOCS Open и Documentum была продемонстрирована в середине 1996 года. Проблема 3. Аналогичная проблеме 2, но для систем класса workflow. Выработкой стандарта для совместной работы workflow-систем от различных производителей занимается некоммерческая организация WorkFlow Coalition, а выработанная ею спецификация носит название Workflow Coalition API. В середине 1996 года была показана совместная работа систем от семи производителей. Проблема 4. При работе с образами документов важна унификация используемых форматов. В качестве единого формата для черно-белых образов документов был принят формат TIFF GROUP IV. Для электронных документов другого типа стандартизация не достигла значительного прогресса вследствие разнообразия типов приложений, порождающих электронные документы. Для распространения электронных документов принят формат, разработанный компанией Adobe, - PDF. 10. Модель документооборота Определенные ранее направления автоматизации документооборота: поддержка фактографической информации, возможность работы с полнотекстовыми документами, поддержка регламента хождения документов, определяют трехмерное пространство свойств (рисунок 6), где по некоторой траектории движется любой программный продукт данного класса, проходя различные стадии в своем развитии. [pic] Рисунок 6. Модель документооборота. Первая ось (F) характеризует уровень организации хранения фактографической информации, которая привязана к специфике конкретного рода деятельности компании или организации. Например: при закупке материальных ценностей происходит оформление товарно-сопроводительных документов (накладных, приемо-передаточных актов, приходных складских ордеров и т.д.), регистрируемых в качестве операционных документов, атрибутика которых очень важна для принятия управленческих решений. Информация из операционных документов используется при сложной аналитической и синтетической обработке, и, в частном случае, может быть получена пользователем через систему отчетов. Вторая ось (D) - полнотекстовые документы, отражает необходимость организации взаимодействия: формирование и передача товаров, услуг или информации как внутри корпорации так и вне ее. В этих документах наряду с фактографической информацией содержится слобо структурированная информация, не подлежащая автоматизированной аналитической обработке, такая, например, как форс-мажерные факторы и порядок предъявления претензий при нарушении условий договора. Все взаимоотношения между субъектами бизнеса сопровождаются документами, которые становятся осязаемым отражением результата взаимодействия. Третья ось (R) вносит в пространство документооборота третье измерение - регламент процессов прохождения документов, а именно: описание того какие процедуры, когда и как должны выполняться. Основа для позиционирования относительно данной оси - набор формальных признаков (атрибутов) и перечень выполнения операций. Точка в пространстве (F, D, R) определяет состояние системы документооборота и имеет координаты (f,d,r), где f,d и r принадлежат множествам F,D и R, соответственно. Положение этой точки зависит от уровня развития и стадии внедрения системы документооборота на предприятии, а также от его специфики и самих масштабов бизнеса. Представив модель документооборота именно таким образом, можно, например, зная текущее положение дел с организацией делопроизводства на каждом конкретном предприятии, четко представить, в каких направлениях нужно двигаться дальше, чего недостает в текущий момент и каким образом органично использовать уже существующие системы автоматизации. Например, в одном из банков был накоплен большой массив фактографических данных, для обработки которых использовалась современная СУБД, развернутая на мощных, отказоустойчивых серверах - все, казалось бы, должно быть отлично. Однако при работе с внутренними документами наблюдалось дублирование информации: возникали ситуации, когда "никто вроде бы и не виноват", а банк время от времени лишается выгодных клиентов. Причина в том, что точка, отражающая положение системы документооборота для этой организации, имела достаточно большие координаты по оси "F" и, возможно, по оси "D", однако значение координаты по оси "R" было близко к нулю. Конкретным решением в этом случае может быть рассмотрение вопроса о внедрении системы управления регламентом. При этом не надо пока заботится о СУБД (ось "F") или электронных архивах (ось "D") - речь идет только об изменении значения координат по оси "R". В общем случае, как уже отмечалось, процесс автоматизации делопроизводства на предприятии можно представить в виде кривой в трехмерном пространстве координат F,D,R. Причем, чем круче эта кривая, тем быстрее идет процесс модернизации, а чем больше значения всех трех координат - тем выше уровень автоматизации на корпорации и, как следствие, тем меньше у нее проблем с организацией своей собственной деятельности. Работоспособна ли данная модель для задания пространства развития неавтоматизированной системы управления документооборотом? Да. Единственно, что в этом случае решается задача не облегчения рутинного труда по перемещению документов, их поиску и регистрации, а упорядочения всей системы документооборота. Новое качество, с которым сегодня ассоциируется возросший интерес к системам электронного документооборота, связано с использованием инструментальных систем, предназначенных для хранения, регистрации, поиска документов, а также для управления регламентом. Чаще ошибочно под новым качеством сегодня понимается простое внедрение отличной от ранее используемой технологии работы с документами, например локальной сети вместо дискет, переносимых с одного компьютера на другой. Вряд ли в этом случае уместно говорить о новом качестве управления предприятием. Кстати, уже упомянутый пример ручной работы режимных служб "почтовых ящиков", прекрасно вписывается в предложенную модель документооборота, а точка, отражающая его состояние, будет иметь координаты (1,1,1) - все равномерно, единственное, что отсутствует - компьютеризация. 10.1. Эволюция модели Предложенная модель документооборота не является застывшим образованием, данным нам в ощущениях - прежде чем сформировалось современное представление о контурах этой модели (рисунок 6), она претерпела три основные фазы своей эволюции. Фаза первая - фактографическая. Начало любой деятельности знаменуется обычно периодом накопления первичной информации, имеющей жесткую структуру и атрибутику. Рассмотрим пример: "на станцию Товарная пришел вагон с сырьем" или "согласно статистическим данным на рынке ощущается острая нехватка товаров для среднего класса". Условно эту фазу можно представить в виде одной единственной оси (рисунок 7). [pic] Рисунок 7. Первая фаза эволюции документооборота. Точка на этой оси - это текущее состояние системы документооборота организации. Движение по оси вверх характеризует накопление фактографической информации и начиная с определенного момента которого можно отметить второй этап первой фазы - возникновение понятия "операция". Документ теперь представляется как некоторый привязанный к бизнес-процессам предприятия агрегат из имеющихся характеристик (атрибутов). На этом этапе начинается процесс возникновения неравенства между ранее равноправными документами, в частности, документ-основание, а дальнейшее движение по оси приобретает все более операционный оттенок. После возникновения привязки к конкретным бизнес-процессам дальнейшая эволюция документооборота в одномерном пространстве уже невозможна - необходим новый качественный скачок к новой фазе. Фаза вторая - полнотекстовая. Расширение организации и увеличение круга решаемых задач требуют использования полнотекстовых документов, включающих уже не только тексты, но и любые другие способы представления: графики, таблицы, видео и т.п. Возникает новая ось - полнотекстовые или, лучше, мультимедийные документы, а точка в новом, уже двумерном, пространстве характеризует систему документооборота предприятия, где кроме фактографической базы документов имеются уже хранилища и архивы информации (рисунок 8). [pic] Рисунок 8. Вторая фаза эволюции документооборота. Хранилища позволяют накапливать документы в различных форматах, предполагают наличие их структуризации и возможностей поиска. Если на предприятии уже используется автоматизация, то хранилище - это не что иное, как электронный архив. Движение по оси "полнотекстовые документы" предполагает наращивание атрибутивных возможностей: разграничение доступа, расширение средств поиска, иерархию хранения, классификация. Здесь же возникают такие понятия как электронная подпись, шифрование и т.п. На данной оси также имеются свои этапы - с определенного момента развития хранилища можно уже говорить не об индивидуальном, а о корпоративном архиве, обслуживающем деятельность рабочих групп. Точка на плоскости эволюции, достигнутой во второй фазе, характеризует систему документооборота, позволяющую отображать фактографическую информацию в виде полнотекстовых документов, имеющих необходимое количество атрибутов. Доступ к этим документам может быть осуществлен по маршруту любого уровня сложности с соблюдением различных уровней конфиденциальности. Если, например, говорить о точке "А" (рисунок 8), то соответствующее ей состояние системы документооборота позволяет осуществлять синхронизацию работы различных рабочих групп сотрудников корпорации, расположенных на различных площадках. Система для этой точки предполагает также структурирование информации по уровням управления и наличие средств репликации данных. Однако, как только речь пошла о корпорации, двумерного пространства для соответствующей ей системы документооборота опять становится недостаточно - необходим новый скачок к очередной фазе. Фаза третья - регламентирующая. Нормальный документооборот в масштабах корпорации невозможен без решения вопросов согласования или соблюдения регламента работы. Если ранее, на второй фазе (плоскость) негласно присутствовал лишь один, простейший регламент (нулевая точка) - каждый сотрудник имел доступ к архиву или его части, либо в папку каждому работнику помещалось индивидуальное задание (иначе говоря, было известно только, что документ существует), то сейчас этого недостаточно. Требуется уже интегральная оценка. Необходим, например, контроль за тем, как работник выполнил задание, или как продвигается документ в условиях нелинейного процесса своего согласования. [pic] Рисунок 9. Третья фаза эволюции документооборота. Третья ось в пространстве документооборота предприятия, как и две другие имеет свое деление на этапы. Первоначальный этап движения по оси характеризуется наличием упрощенного регламента, отображаемого появлением атрибутов, отвечающих за регламент, например: "оплатить до", "действителен для". Количественное накопление атрибутов и расширение возможностей по управлению регламента сопровождается постепенным переходом ко второму этапу, отличительная черта которого - появление системы, специально предназначенной для отслеживания процесса соблюдения регламента. При дальнейшем движении вдоль этой оси можно говорить о появлении единой системы управления проектом. Теперь документ в системе "документооборота" становится вторичным - первична цель бизнеса, сам процесс реализации бизнес- процедур, оставляющий после себя документы. 10.2. Модель и типы собственности Оси "F" и "D" определяют специфику деятельности организации, регламентируемую положением третьей координаты (R) пространства модели документооборота. При этом модель не зависит от технологии обработки документов, принятой на предприятии - все решает только цель деятельности, будь то государственная организация, торговая компания и промышленная фирма. В общем случае можно выделить три типа организаций: . торговая компания: приобретение, наценка, продажа, получение прибыли - главный объект деятельности; . бюджетная организация: основная деятельность - формирование документов; . промышленное предприятие: закупка сырья, переработка, создание нового продукта, реализация, получение прибыли. Цель деятельности - операция. Если задачей организации является формирование документов, например мэрия, суд или министерство, то ее позиция в модели будет занимать достаточно высокое положение относительно осей "F" и "D". Кстати, сегодня наибольшей популярностью пользуются именно приложения, ориентированные на автоматизацию деятельности государственных и правительственных административных структур - основная цель которых и состоит в подготовке документов. Однако если рассматривать деятельность коммерческой фирмы задача которой - производство операций, материальных ценностей (принять сырье, преобразовать, создать новый продукт, реализовать его, получить выручку), то здесь уже все три координаты должны иметь сбалансированные значения. 10.3. Что же из всего этого следует? Координаты точки, характеризующей сбалансированную систему документооборота, должны иметь ненулевые значения, а в идеале быть примерно одинаковы - соответствовать друг другу. Главное не автоматизация как таковая, а оптимизация потоков документов и интегральность - даже самая прекрасная программа автоматизации документооборота окажется напрасным вложением средств, если модель одномерная или плоская. Нет большого смысла говорить о жизненном цикле документов без связи с основными бизнес-процессами предприятия. Система автоматизации документооборота, функционирующая в отрыве от всех слоев, будет мертва, мало того, она может нанести вред: запутать и без того неуправляемые бизнес- процессы, отвлечь персонал от выполнения основной работы ради поддержания системы автоматизации документооборота, по сути дела, ничего не автоматизирующего. И, как следствие, раздувание штатного расписания и дискредитация самой идеи автоматизации делопроизводства. Знакомая ситуация - все работники заняты, работа кипит, однако если рассмотреть две разные фирмы имеющие равный доход, занимающиеся одним бизнесом, то штат сотрудников у одной из них будет вдвое больше, чем у другой. В некоторых организациях положение усугубляется еще болезнью роста - привычка все делать своими силами играет роковую роль в деле автоматизации деятельности компании. Если уже стали достоянием прошлого надежды, что купив компьютер, можно сразу решить все проблемы; то с наличием на рынке большого выбора систем автоматизации документооборота связано еще предубеждение, что достаточно приобрести коробку с соответствующей программой и, опять-же, проблемы будут решены. Компьютер или программы типа 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. Сегодня имеется восемь типов функций: . преобразования: (NUM-строка в число, STR-число в строку); . системные функции работы с операционным окружением: (запрос информации о переменных окружения, работа с окнами и полями в файлах, управление выводом сообщений и т.п.); . файловые операции: (переименование, удаление, копирование и т.п.); . функции работы с временем и датой: (конструирование формата представления даты, расчеты по датам и времени, календарные функции и т.п.); . функции работы с текстами: (поиск подстрок, преобразования, вычисления над строками и т.п.); . работа с внешними программами: (вызов Unix программы, вызов программы в среде windows, подготовка документов в macintosh и т.п.); . функции выделения: (VLDFILE: взять данные из файла и поместить в список, VLDQUERY: взять данные из базы данных); . функции работы с DDE: (инициировать работу с сервером DDE, удалить сессию, послать команду, переслать данные и т.п.); . вызов сценария: (CALL: вызов программы описания сценария). 11.3. Взаимодействие с внешним миром Деятельность любой корпорации невозможна без взаимодействия с внешней средой - можно найти очень мало примеров, когда компания представляет только вещь в себе. Поэтому для построения полноценного документооборота в Staffware включены средства интеграции с другим информационными системами: базами и хранилищами данных, текстовыми процессорами и процессорами обработки изображений, системами автоматизации офиса, а также почтовыми системами. Технологическая схема интеграции системы Staffware с внешней средой представлена на рисунке 14. [pic] Рисунок 14. Технология интеграции системы Staffware с внешней средой. Как уже было сказано, автоматические шаги процедуры позволяют вызывать внешние процессы и программы, передавая и получая от них данные. Часто для организации взаимодействия с внешними программами используется скрытый вызов процессов, в качестве которых может выступать запрос к базе данных или хранилищу корпоративной информации. В качестве примера можно взять процедуру получения заема у банка по кредитной карте. После определения всех необходимых данных (суммы заема, информации о клиенте и условий договора) банковская система, построенная на базе Staffware может одновременно с процессом обработки заявки вызвать внешнюю программу проверки кредитной карты, сформировав запрос типа: database bank select * from credit where sname="&sname&" quit Данная возможность реализуется путем включения в описание процедуры соответствующего автоматического шага. Обратная связь может осуществляться путем записи ответа внешней программы в некоторый файл, например, в качестве подтверждения корректности кредитной карты будет создан набор, содержащий следующую последовательность: FNAME,Petra SNAME,Stauffer DATEOFBIRTH,07/12/1962 Также можно использовать возможность обмена на основе механизма, позволяющего передавать сообщения между двумя windows приложениями - клиентом и сервером. Такой механизм полезен и для обмена данными и формами между Staffware и программами работы с электронными таблицами или текстовыми процессорами. Для получения сообщений о событиях, происходящих во внешней, по отношению к Staffware, среде применяется специальный механизм управления событиями, который можно использовать следующим образом: . прерывание выполнения процедуры Staffware в момент наступления какого- либо внешнего события, например получения факсимильного сообщения об отказе поставщика отгружать товар; . выполнение работы процедуры на всем протяжении времени пока во внешней среде происходит какое-либо событие, например, обработка входных заявок до момента окончания рабочего дня; . запуск альтернативной ветки обработки документооборота, заменяющей основной регламент работы, например выполнение всех необходимых мероприятий после получения сигнала от пожарной сигнализации. Часто оказывается, что сами процедуры Staffware должны быть запущены извне, со стороны какого-либо приложения. Специально для этих целей в системе имеется интерфейс внешнего вызова, например, запуск процедуры обработки заявки клиента банка после получения сигнала от СУБД, управляющей базой данных всех владельцев счетов. Даже несмотря на такие широкие возможности Staffware, бывают ситуации, когда пользователю недостаточно предоставленных средств, либо условия работы меняются достаточно часто и неэффективно использовать, например заранее подготовленные формы для ввода информации. Для преодоления этих временных трудностей в Staffware предусмотрен специальный прикладной слой, содержащий программный интерфейс разработки новых модулей. Слой Staffware Application Layer (SAL) является частью клиента и образует отдельный слой в архитектуре клиент/сервер системы. SAL чаще всего используется системными интеграторами, создающими специализированные пользовательские интерфейсы, работающие, в частности, в составе программных комплексов, применяющих систему электронного документооборота в качестве одного из многих модулей. Функции этого слоя оформлены в виде библиотек на языке Си. 12. Проблемы внедрения систем электронного документооборота При внедрении систем электронного документооборота приходится решать не только специфические проблемы, обусловленные многосторонней сложностью такого рода систем, но и с иными проблемами, характерными для процессов коренной реорганизации деятельности предприятия. Известно, что переход на электронный документооборот можно с полным правом назвать именно коренным изменением организационного и административного устройства любой организации. 12.1. Проблема информированности Чтобы руководство организации пришло к выводу о необходимости внедрения СУД, оно должно, как минимум, знать о существовании таких систем, для чего они предназначены и как осуществить их внедрение. Есть и другая проблема: с чего начать внедрение СУД? 12.2. Организационные проблемы На каждом предприятии с течением времени складывается определенная организационная структура (причем - не всегда оптимальная), формируются свои, характерные только для нее, стили работы, методы управления и контроля. Внедряемая СУД, в подавляющем большинстве случаев, на первых порах оказывается как бы "чужеродным телом" для коллектива предприятия. Это происходит потому, что хорошо построенная СУД является своего рода "лакмусовой бумажкой", и многие недостатки в функционально-структурном построении предприятия проявляются уже на первых этапах процесса внедрения СУД. Возникает дилемма: что лучше и легче - строить СУД по образу и подобию того как дело обстоит у заказчика, или проводить у него реорганизацию с целью достижения максимальной эффективности СУД? Да, хорошие СУД обладают определенной возможностью адаптации к конкретному заказчику, но у всего есть свои границы. Если предприятие в значительной степени организационно не готово к внедрению СУД, то такое внедрение либо весьма затруднено, либо вовсе невозможно. Хорошей аналогией может послужить попытка установить более мощный двигатель на автомобиль со слабой ходовой частью. Результат известен заранее. 12.3. Психологические проблемы Как видится СУД большинству сотрудников предприятия - заказчика? Если они обладают поверхностной информацией, то руководству предприятия СУД представляется как панацея от всех неурядиц, то и дело возникающих из-за небрежного отношения к документам. А исполнители считают, что СУД - это что- то среднее между электронной почтой и привычным редактором. И только потом, по мере более детального ознакомления с системой, руководство вдруг с удивлением обнаруживает, что им тоже надо будет работать на компьютере, который долго пылился на рабочем столе, создавая в глазах посетителей определенный имидж хозяина кабинета. Для немалого числа руководителей старой закалки это оказывается психологическим барьером. Им куда привычнее работать непосредственно с людьми: "вызвал на ковер", "дал накачку", увидел страх в глазах подчиненного - приходишь к мысли, что не зря занимаешь кресло. У исполнителей же часто возникает ощущение, что с внедрением СУД появился еще один начальник, который постоянно стоит за спиной. Действительно, ведь теперь совершенно точно можно узнать при желании: кто, что, когда и сколько делает. Раньше можно было сколько угодно вешать начальству "лапшу на уши"^ что, мол, полдня искал такой-то и такой-то документ по всем этажам (хотя, на самом деле, играл в преферанс на компьютере). Вот и возникает у плохого начальства и у нерадивых работников психологический дискомфорт и полное неприятие СУД. Хорошо, если это выражается только в заявлении на увольнение. Чаще мы получаем стойких скрытых врагов, всячески сопротивляющихся такому нововведению, как СУД, которая воочию покажет их несостоятельность и бесполезность для предприятия. 12.4. Проблема кадров Внедрение СУД подразумевает, что все основные участники бизнес- процессов на предприятии должны уметь работать на компьютере. Это так и есть в молодых, относительно недавно созданных организациях и фирмах. Но что делать, если основной костяк руководства предприятия получил образование 20 - 15 лет назад? По своему опыту и профессиональным навыкам они могут полностью соответствовать занимаемым должностям, но они никогда не обучались и не работали на ПК. Отправлять их на учебу? Но, как правило, если на предприятии пришли к мысли о необходимости внедрения СУД, то интенсивность труда на этом предприятии весьма высока. Это значит, что обучение сотрудников с отрывом от производства практически невозможно. А факультативное обучение может оказаться неэффективным и будет приводить лишь к повышенной усталости работников предприятия. Пунктирно были указаны лишь основные проблемы, стоящие на пути внедрения СУД. Естественно, большинство из них находит свое решение и не является непреодолимым препятствием. Хочется лишь подчеркнуть, что все эти проблемы должны приниматься во внимание и тем, кто раздумывает о целесообразности внедрения СУД на своем предприятии или в своей организации, и тем, кто берется за само внедрение. 12.5. Делать самим или использовать готовые системы? Первый вопрос, который возникает в процессе создания системы документооборота - делать самим или использовать готовые программные продукты? Рассмотрев ситуацию на рынке можно увидеть большое количество программ от дешевых до дорогих. Изучив опыт нескольких реализаций, реальнее остановиться на втором варианте так как продукты, присутствующие на рынке, представляют фирмы которые достаточно долго работали над ними и имеют огромный опыт. При необходимости изготовитель может доработать продукт и оказать услуги по обслуживанию и установке системы. Следующий вопрос: что же выбрать? Современный рынок достаточно богат предложениями - необходимо только конкретно знать конечную цель, которая полностью удовлетворяла бы задачам пользователя. Приведенные в этой работе основные принципы должны помчь в выборе нужной системы и (или) если нужно необходимой доработке до нужного уровня. Примером для готовых систем может служить технология workflow позволяющая перевести аналитические результаты деятельности по реорганизации бизнес-процессов в практическую плоскость организации управленческой деятельности. Конкретно может быть пакет Staffware компании Staffware plc. (Великобритания), Excalibur EFS, Парус (Россия) специализирующихся на разработке автоматизированных систем класса workflow для комплексного решения задач управления бизнес-процедурами, деловыми операциями и документооборотом. Эти пакеты построены на основе новейших информационных технологий и могут быть использованы в каком угодно секторе рынка и при любых концепциях и процедурах управления организацией. Заключение В любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Небольшие организации используют для этого шкафы с папками, однако крупные корпоративные предприятия используют компьютеризированные системы автоматизации, позволяющие эффективно хранить, извлекать информацию и управлять большими объемами данных. Сегодня имеется множество систем автоматизации документооборота, отличающихся как по своей архитектуре, так и по функциональным возможностям. Для координации деятельности производителей, работающих на этом рынке создана даже специальная коалиция, призванная распространять стандарты, обеспечивать обмен мнениями и предложениями по развитию функционального наполнения систем класса workflow. Однако следует всегда учитывать, что системы класса workflow - это всего-навсего инструменты, неправильное использование которых иногда может принести вред. Это чаще всего происходит, если заказчик пытается сэкономить на предпроектных исследованиях своего предприятия. К счастью, на примере прошедшей уже волны увлечения оболочками для построения баз данных многие заказчики осознали, что ценность представляет не форма, а содержание - конкретная информация в базе данных. Аналогичным образом обстоит дело и с системами автоматизации электронного документооборота - четкая проработка бизнес-процессов предприятия является залогом успеха. Очевидно, что рассматренные технологии весьма дорого стоят и "по плечу" только крупным организациям. Но затраты окупаются тем, чтопользование информационных систем для управления документами делает любую организацию более конкурентоспособной за счет повышения ее управляемости и адаптируемости к изменениям рыночной конъюнктуры. Подобная автоматизация позволяет: . Повысить эффективность управления компанией за счет обеспечения руководителей и специалистов максимально полной, оперативной и достоверной информацией на основе единого банка данных. . Улучшить делопроизводство при помощи оптимизации и стандартизации документооборота, автоматизации наиболее трудоемких его процедур. . Снизить расходы на ведение дел за счет автоматизации процессов обработки информации, регламентации и упрощения доступа сотрудников компании к нужной информации. Изменить характер труда сотрудников, избавляя их от выполнения рутинной работы и давая возможность сосредоточиться на профессионально важных обязанностях. . Обеспечить надежный учет и контроль поступлений и расходования денежных средств на всех уровнях управления. . Повысить эффективность обмена данными между отдельными подразделениями, филиалами и центральным аппаратом. . Гарантировать полную безопасность и целостность данных на всех этапах обработки информации и многое другое. Список литературы. 1. Журнал Open Systems № 5, 2000 г. – «Управление электронными документами: технологии и решения» 2. Журнал Open Systems № 8, 2000 г. – «От автоматизации офиса до управления производством» 3. Кодд, Е.Ф. «Реляционная модель данных». Пер с англ. – Киев, Диалектика. 1996. 4. Перкинсон, Р.С. «Анализ данных: Ключ к проектированию баз данных». Пер с англ. – Киев, Диалектика. 1996. 5. «Проектирование и разработка систем автоматизации предприятий». 6. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г. 7. Финансовая газета № 35, 2000 г. - «Автоматизация и статистика», С. Золотова 8. ComputerWorld № 40, 1999 г. – «К оружию. Мощное средство в борьбе за выживание», М. Зырянов 9. «Database Unleashed», Indianapolis USA, «SAMS Publishing», 1996г. 10. Date C.J. «An Introduction to Database Systems» Volume 1, Reading, Mass.: Addison-Wesley Publishing Company, 1989. 11. PCWeek № 41, 1999 г. – «Богатым быть лучше...», Андрей Масалович 12. PCWeek № 40, 1999 г. – «Компании "Парус" и БИГ вооружают финансистов», Татьяна Богатова |
|
