· промышленное предприятие: закупка сырья, переработка, создание нового продукта, реализация, получение прибыли. Цель деятельности - операция.
Если задачей организации является формирование документов, например мэрия, суд или министерство, то ее позиция в модели будет занимать достаточно высокое положение относительно осей "F" и "D". Кстати, сегодня наибольшей популярностью пользуются именно приложения, ориентированные на автоматизацию деятельности государственных и правительственных административных структур - основная цель которых и состоит в подготовке документов.
Однако если рассматривать деятельность коммерческой фирмы задача которой - производство операций, материальных ценностей (принять сырье, преобразовать, создать новый продукт, реализовать его, получить выручку), то здесь уже все три координаты должны иметь сбалансированные значения.
Координаты точки, характеризующей сбалансированную систему документооборота, должны иметь ненулевые значения, а в идеале быть примерно одинаковы - соответствовать друг другу. Главное не автоматизация как таковая, а оптимизация потоков документов и интегральность - даже самая прекрасная программа автоматизации документооборота окажется напрасным вложением средств, если модель одномерная или плоская.
Нет большого смысла говорить о жизненном цикле документов без связи с основными бизнес-процессами предприятия. Система автоматизации документооборота, функционирующая в отрыве от всех слоев, будет мертва, мало того, она может нанести вред: запутать и без того неуправляемые бизнес-процессы, отвлечь персонал от выполнения основной работы ради поддержания системы автоматизации документооборота, по сути дела, ничего не автоматизирующего. И, как следствие, раздувание штатного расписания и дискредитация самой идеи автоматизации делопроизводства. Знакомая ситуация - все работники заняты, работа кипит, однако если рассмотреть две разные фирмы имеющие равный доход, занимающиеся одним бизнесом, то штат сотрудников у одной из них будет вдвое больше, чем у другой.
В некоторых организациях положение усугубляется еще болезнью роста - привычка все делать своими силами играет роковую роль в деле автоматизации деятельности компании. Если уже стали достоянием прошлого надежды, что купив компьютер, можно сразу решить все проблемы; то с наличием на рынке большого выбора систем автоматизации документооборота связано еще предубеждение, что достаточно приобрести коробку с соответствующей программой и, опять-же, проблемы будут решены. Компьютер или программы типа workflow - это только голый инструмент, неумелое использование которого чаще всего влечет за собой только вред, а не долгожданное облегчение и освобождение от внутрикорпоративных проблем по управлению.
Два завода отгружают продукцию друг другу, например, руду вагонами. От поставщика приходят счета фактуры, которые попадают в канцелярию потребителя, откуда направляются по двум адресам: бюро цен и финансово-расчетная группа. Первые проверяют корректность цен, с тем, чтобы поставщик не завысил цену, ставят свою отметку и пересылают счета в отдел материально-технического снабжения (МТС) для уведомления. Вторые делают запись в реестре о передаче счета в МТС и его оплате.
Даже в такой простой схеме в результате обследования была выявлена черная дыра, через которую уходили значительные средства потребителя. Отдел МТС сопоставляет суммы, полученные от финансово-расчетной группы с объемами руды, фактически пришедшей в вагоне от поставщика. Как правило цифры отличаются; если реальный показатель не меньше данных, указанных в счетах, то все подтверждается и сделка завершена, если меньше, то, тем не менее счета оплачивают, но выставляют претензии на фактически недопоставленный объем сырья. Далее в дело вступает юридический отдел, который оформляет претензии и переправляет их поставщику. В итоге, все отделы свою работу выполнили, однако на вопрос "проходила ли реально доплата или допоставка по претензиям" ответа никто дать не смог. Ни одна из служб не отслеживала факт получения ответа от поставщика и оплаты претензий.
В контексте предложенной модели для данного случая точка, описывающая положение системы документооборота предприятия была очень близко расположена к нулю по осям "Фактография" и "Регламент". Иногда, правда, факт недостачи обнаруживался - тогда начинало действовать координационное бюро, цель которого - проводить сверки счетов поставщика и потребителя. Нетрудно видеть, что работа этого лишнего подразделения отнимает массу времени, отвлекает от работы другие подразделения, требует больших затрат на командировки. Всего этого можно избежать, если построить систему автоматизации на модели, где учитывалось бы вся необходимая фактография, а достаточно высокое значение координаты по осям "F" и "D" позволяло бы автоматически обнаруживать дырки в регламенте, а также организовывать проверки и контроль без аврала и привлечения дополнительных ресурсов.
Электронный документооборот, реализуемый с помощью программных систем класса 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 были предложены адекватные решения.
В основу архитектуры системы были положены три принципа: независимость, открытость и интегрированность. С появлением Internet/intranet все эти принципы получили еще одно измерение - WWWW (World Wide Web Workflow) как аппарат работы с глобальными компьютерными сетями, используемыми сегодня для управления корпорациями.
Как и большинство современных программных комплексов, пакет использует парадигму клиент/сервер, позволяя строить как одноузловые конфигурации, например Unix-сервер, вокруг которого размещается множество рабочих мест (Windows, NT, OS/2, удаленный терминал типа VT100, Macintosh), так и многоузловые, содержащие несколько серверов, работающих под управлением ОС Unix или NT и оперирующих своим подмножеством клиентов. Клиентский компонент Staffware имеет пользовательский интерфейс, настроенный на конкретную прикладную область и отражающий очередь рабочих заданий сотрудника компании или организации. Данный интерфейс - своеобразное окно в систему электронного документооборота, он может интегрироваться с широким спектром программных продуктов: текстовые процессоры, офисные системы управления делопроизводства, различного рода записные книжки, блокноты и т.п.
Связь между клиентом и сервером осуществляется при помощи механизма удаленного вызова процедур (RPC), позволяющего одной программе использовать сервис другой. С точки зрения клиента и сервера логическое взаимодействие осуществляется на локальном уровне, реально же сервер располагается обычно на другой аппаратной платформе, а взаимодействие осуществляется по протоколу TCP/IP.
На рисунке 10 представлена диаграмма организации взаимодействия, принятая в системе Staffware.
Рисунок 10. Диаграмма организации взаимодействия в системе Staffware.
Кроме коммуникационного слоя (TCP/IP/ и sockets, UUCP, NFS, X.400), система Staffware имеет несколько слоев, содержащих функциональные зоны, в совокупности реализующие три основных компонента системы: представление информации, реализация логики конкретного приложения и доступ к данным.
Слой пользовательского интерфейса предназначен для удовлетворения всех специфических для конкретной прикладной области запросов оператора, работающего с системой: оформление экрана, организация ввода запросов и получение ответов. Прикладной слой обеспечивает интерфейс с системой workflow и призван экранировать пользователя от конкретных деталей работы с данными, получаемыми от сервера: инициация рабочей сессии, запуск и удаление процессов, управление очередями заданий и т.п. Файловый интерфейс обеспечивает прозрачный доступ к данным со стороны прикладного интерфейса: выборка логических записей из базы данных, их конвертирование в специфическую для каждой конкретной СУБД форму, а также ряд других операций, призванных экранировать все вышележащие слои от конкретных особенностей используемых систем хранения данных.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
