Задать вопрос юристу

Модели электронного документооборота


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

Аналогичного подхода придерживаются и разработчики распространенных методик моделирования деятельности организаций, например IDEF или ARIS, разделяя процессы и функции.
Идентификация процессов в организации является одним из базисов как для проектирования системы документооборота, так и управления организацией и предприятием в целом. Под процессом понимается последовательность целенаправленных действий, необходимых для разрешения ПС, периодически предпринимаемых

Рис. 4.2. Процессы в организации
Рис. 4.2. Процессы в организации
структурными или функциональными подразделениями, измеряемых при помощи показателей (времени, ресурсов, затрат).
Следующим уровнем проектирования систем документационного обеспечения управления является декомпозиция управленческих задач. Под управленческой задачей понимается совокупность ПС, подлежащих решению для достижения организацией своих целей. Ни одна из моделей документационного обеспечения не делает систему управления эффективной, однако они дают возможность повысить эффективность решения управленческих задач. Разделение задач позволяет явно сформулировать последовательность действий подразделений, сотрудников организации для разрешения конкретных ПС. Выделяют вертикальный и горизонтальный уровни разделения задач.
  1. Вертикальный уровень позволяет определить типы и этапы работ. Например, маркетинг разделяют на изучение рынков, анализ продаж, построение прогноза продаж и т.п.
  2. Горизонтальный уровень позволяет сегментировать деятельность организации по этапам и элементам. Например, маркетинг или закупки можно разбить по регионам, или по продуктам, или по ключевым клиентам.

Проектирование систем ДОУ должно начинаться с определения того, что должно быть реализовано, т.е. с содержательной части. Вторым этапом становится практическая часть, в которой упор делается на то, как должна быть реализована система документационного обеспечения.
Таким образом, идентификация функций, процессов и задач является базисом для построения эффективной системы ДОУ.

Важным аспектом, предшествующим проектированию эффективной системы ДОУ, является стандартизация деятельности организации. Вопрос сертификации деятельности по стандартам ISO сегодня является актуальным вопросом для многих. Стандартизация позволяет привести деятельность компании в соответствие с широко распространенными требованиями к качеству, деятельность всех подразделений — к единым требованиям. В органах государственного управления существуют единые формы отчетности, и стандартизация деятельности всех подразделений позволяет упростить процесс подготовки консолидированной отчетности и внутренний аудит организаций.
Стандартизацию принято подразделять на ряд уровней:
  1. стандартизация «по входу», когда стандартизуется только уровень исполнителей, что характерно для, скажем, юридических, стратегических или инновационных служб предприятия;
  2. стандартизация «по выходу», когда стандартизуется результат деятельности организационной единицы или должностной позиции;
  3. стандартизация «по процессу», позволяющая определить инструкции для отдельных исполнителей относительно регламента поведения для разрешения типовых ПС.

Одним из эффективных способов управления на основе процессов является теория координации, позволяющая определить альтернативные пути развития процессов и решения управленческих задач. Сотрудники организации сталкиваются с проблемами координации, появляющимися в результате возникновения нетипичных ПС. Важным достоинством теории координации является возможность конструировать последовательности с применением методов координации. Функции и процессы, аналогичные по сути, могут быть заложены в деятельность различных структурных подразделений организации. Уровень компетенции различных сотрудников может требовать большего или меньшего уровня документационного обеспечения, необходимого и достаточного для разрешения ПС. Выбор конкретной структурной единицы, способной быстро и качественно разрешить ПС с привлечением минимального уровня ИР, является заслугой оптимальной системы координации внутри организации.
Следующим моментом, который зависит от выбора оптимального уровня координации, является управление зависимостями. Например, как результат координации могут формироваться механизмы управления ДОУ; маршрут документа может выстраиваться:
  • на основе личного выбора руководителя из всех сотрудников, с учетом их личной компетенции;
  • на основе случайного выбора руководителя;
  • на основе «рынка труда» внутри организации (т.е. из числа свободных в настоящий момент сотрудников).

Организации, имеющие идентичные функции, одинаковые процессы и единые стандарты, могут использовать различные системы ДОУ из-за разных подходов к координации деятельности подразделений отдельных сотрудников. Кроме того, с применением теории координации появляется возможность включать альтернативные процессы, которые позволяют произвести эффективный реинжиниринг процессов.
Последним концептуальным вопросом является выстраивание специализаций. Иерархия специализаций организует объекты от наиболее общих до наиболее уникальных. Для выполнения идентичных операций существуют различные методы, сходные по сути, но разные по содержанию. Введение специализаций позволяет более точно описать процессы с учетом их узкой специфики.
Стандарты и инструменты моделирования процессов. Согласно приведенной статистике значительное число организаций привлекали специалистов для идентификации бизнес-процессов. На этом этапе необходимо явно описать функции и процессы, а также определить взаимодействия между элементами организационно-функциональной структуры (рис. 4.3). Существуют три варианта такого описания:
  1. текстовое описание: как правило, описание всех процессов на крупном предприятии, сделанное в текстовой форме, сложно для восприятия, ошибки и неточности сложны для выявления;
  2. формальное описание: к текстовому описанию добавляются внутренние формы или процесс описывается посредством отдельных документов (инструкций, схем, распорядков);
  3. графическое описание: описание производится посредством диаграмм процессов, деревьев структур данных и т.п. Существуют различные стандарты и средства графического описания процессов.



В любой организации имеется значительное число целей, достижение которых может производиться как последовательно, так и параллельно. Функции и процессы, которые при этом используются, зачастую противоречивы. Для их описания применяют технологии инжиниринга, а для оптимизации — технологии реинжиниринга процессов. Эти технологии позволяют управлять развитием организации на основе сквозного управления потоками работ (workflow), которые рассматриваются как совокупность материальных, финансовых, информационных потоков, проходящих по взаимосвязанным подразделениям предприятия независимо от организационной структуры последнего. Современные стандарты и средства проектирования и анализа процессов позволяют построить, описать, проанализировать и оптимизировать процессную модель организации. Такой подход дает возможность оперативно вносить изменения в информационную систему организации, а также во взаимосвязанные процессы в смежных подразделениях других организаций.
Таким образом, моделирование процессов или реинжиниринг существующей процессной модели, как правило, проводится в следующих случаях:
  • подготовка и внедрение организационных изменений в организации;
  • разработка стратегии развития бизнеса на основе системы сбалансированных показателей (Balanced Scorecard) и ключевых показателей результативности (Key Performance Indicators);
  • анализ и оптимизация бизнес-процессов;
  • пооперационно-стоимостной анализ бизнес-процессов и управление издержками;
  • управление операционными рисками;
  • внедрение систем управления качеством;
  • внедрение систем документационного обеспечения управления и информационных систем класса ERP;
  • подготовка к сертификации по управлению качеством;
  • редокументирование внедренных информационных систем;
  • мониторинг работающих бизнес-процессов;
  • регламентация работы.

Таким образом, на основе стандартов и методологий моделирования и анализа процессов организации с применением современных CASE-средств можно решать следующие основные задачи, стоящие перед системой ДОУ организацией:
  • идентификация текущих функций процессов в организации, включая сложные процессы;
  • создание комплексной модели процессов организации с учетом координации и специализации структурных единиц;
  • осуществление декомпозиции процессов с целью оптимизации достижения целей организации;
  • реинжиниринг процессов для оптимизации деятельности организации.

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

Комплексные решения по реорганизации предприятий всегда являются сложными. Для решения задач моделирования сложных систем существуют методологии и стандарты.
В качестве средств компьютерной поддержки деятельности аналитиков в области структурного анализа, идентификации и моделирования процессов организации используют CASE-системы. Архитектура большинства CASE-систем базируется на схеме «методология — модель — нотация — средства».
Под методологией структурного анализа понимают методы и средства для исследования структуры и деятельности организации. Она определяет основные принципы и приемы использования моделей. Модель — это совокупность символов (математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними. Нотации — система условных обозначений, принятая в конкретной модели. Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.
Такие системы позволяют автоматизировать построение моделей на основе идентифицированных процессов организации. Такие модели должны отражать: функции, которые должна выполнять система; процессы, которые обеспечивают выполнение функций; данные и отношения между данными, которые необходимы для выполнения функций; организационные структуры, которые обес
печивают выполнение функций; материальные и информационные потоки, возникающие в ходе выполнения функций.
Несмотря на достаточно широкий спектр используемых методов и диаграммных техник, большинство методологий базируется на следующей классической совокупности.
SADT (structured analysis and design technique) — технология структурного анализа и проектирования. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка — сама методология SADT. В дальнейшем вы увидите, что графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению. С точки зрения SADT модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADT-модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы — моделями данных, функциональная модель представляет с требуемой степенью детализации систему функций, которые, в свою очередь, отражают свои взаимоотношения через объекты системы. Модели данных дуальны к функциональным моделям и представляют собой подробное описание объектов системы, связанных системными функциями. Полная методология SADT поддерживает создание множества моделей для более точного описания сложной системы.
DFD (data flow diagrams) — диаграммы потоков данных. DFD представляет модульную систему в виде работ, связанных между собой. DFD описывает функции обработки информации (работы), документы, объекты, сотрудников или отделы, которые участвуют в обработке информации, внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы, таблицы для хранения документов. Связи в DFD показывают, как объекты (включая данные, информацию, знания) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов в отличие от IDEF0, где система рассматривается как взаимосвязанные работы. DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто
включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации». Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
STD (state transition diagrams) — диаграммы перехода состояний для проектирования систем реального времени. Наиболее часто спецификации управления формализуются с помощью диаграмм переходов состояний, позволяющих задавать состояния различных объектов системы. Например, лицевой счет может иметь состояния «открыт», «закрыт», «заблокирован». Такие диаграммы позволяют описать условия переходов из одного состояния в другое. При этом становится возможным отображать как внешние по отношению к системе, так и внутренние, возникающие в самой системе состояния, а также совершаемые при переходах действия.
ERD (entity-relationship diagrams) — диаграммы «сущность-связь» предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Структурные карты Джексона и (или) Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов. Техника структурных карт используется на фазе проектирования, для того чтобы продемонстрировать, каким образом требования к системе будут отражаться комбинацией программных структур. Структурные карты являются моделью отношений иерархии между модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы. При этом циклические и условные вызовы модулей моделируются специальными узлами, поэтому потоки должны быть изображены проходящими через эти специальные узлы. Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам (т.е. к вызовам модулей), стрелками указываются направления потоков и связей.
FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описы
вают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели.
Одним из наиболее распространенных стандартов структурного анализа и проектирования процессов является стандарт IDEF (ICAM definition, где ICAM обозначает аббревиатуру, означающую интеграцию компьютерных и промышленных технологий). IDEF принят в качестве государственного стандарта в США. Данный стандарт является достаточно универсальным средством и применим во многих сферах: промышленности, торговле, государственных органах. Известно, что его успешно применяют в Федеральной налоговой службе Российской Федерации. Более того, методики IDEF широко применяются для реинжиниринга процессов.
Семейство IDEF включает:
  • IDEF0 — методология функционального моделирования, являющаяся составной частью SADT и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций;
  • IDEF1 — методология анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия;
  • IDEF1X — методология информационного моделирования, основанная на концепции «сущность-связь», предложенной Ченом. Применяется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы и обеспечивающий универсальное представление структуры данных в рамках предприятия, независимое от конечной реализации базы данных и аппаратной платформы;
  • IDEF3 — методология документирования технологических процессов, предприятия, позволяющая моделировать их сценарии посредством описания последовательности изменений свойств объекта в рамках рассматриваемого процесса;
  • IDEF4 — методология объектно-ориентированного проектирования для поддержки проектов, связанных с объектноориентированными реализациями;
  • IDEF5 — методология, обеспечивающая наглядное представление данных, полученных в результате обработки онтологических запросов, в простой, графической форме.

При помощи этих методов могут быть построены логические модели исходной и реорганизованной систем управления организацией.
В основе нотации и методологии IDEF0 лежит графическая визуализация процессов в виде блоков с различной функциональной ролью (рис. 4.4).
Рис. 4.4. Графическая визуализация в методологии IDEF0
Рис. 4.4. Графическая визуализация в методологии IDEF0
Объектами преобразования для процессов могут являться ресурсы предприятия: материальные, финансовые, информационные. В диаграммах IDEF0 обозначения этих ресурсов располагаются на дугах графа. Как правило, одновременно описываются материальные (или финансовые) потоки и связанные с ними информационные. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация или другой ресурс, которые подвергаются обработке, показаны с левой стороны блока, а результаты (выход) с правой стороны. Механизм (подразделение, человек или автоматизирован
ная система), который реализует функцию (операцию) представлен дугой снизу.
Одним из важных моментов при описании процессов с помощью методологии IDEF0 является точная спецификация типов связей между функциями:
  • коммуникационная, при которой функции используют одни и те же данные и/или производят одни и те же выходные данные;
  • последовательная, при которой выход одной функции служит входными данными для другой;
  • функциональная, отражающая полную зависимость одной функции от другой (например, управление в ходе решения общей задачи).

В IDEF0 существуют правила, по которым блоки объединяются в модель:
  • правило функциональной декомпозиции;
  • правило контекстной диаграммы;
  • правило ограничения сложности.

Правило функциональной декомпозиции представляет собой модельную интерпретацию той практической ситуации, когда любая функция (а функция — это свернутый бизнес-процесс) может быть разбита на более простые действия (процессы или функции более низкого уровня, вплоть до элементарных операций).
Правило контекстной диаграммы требует, чтобы моделирование начиналось с единственного блока. Все потоки на данной диаграмме подразумеваются приходящими извне (или уходящими вовне, к объектам вне организации). В ходе моделирования для каждого блока надо определить, что нужно сделать для реализации возложенной на него задачи (миссии).
Согласно правилу ограничения сложности диаграммы IDEF несут в себе очень концентрированную информацию, поэтому необходимо применять меры по повышению их наглядности. Основными являются два принципа:
  • общее количество блоков, включенных в одну диаграмму, не должно превышать шести;
  • количество интерфейсных дуг, подведенных к одной стороне блока, должно быть не более четырех.

Применение методологий семейства IDEF (особенно в сочетании с соответствующими программными средствами) позволяет существенно повысить эффект от взаимодействия специалистов как внутри организации, так и с внешними консультантами, например на этапе концептуального проектирования информационной системы.
Другим широко применяемым решением для идентификации и визуализации процессов в организации является методология ARIS
(architecture of integrated information system), разработанная профессором А. В. Шеером, определяющая принципы моделирования деятельности организации. Основой для моделирования процессов является концепция интеграции, целостного взгляда на процессы. Ключевым понятием является архитектура, описывающая типы используемых методов, их функциональные свойства и взаимоотношения между составными частями моделируемой системы.
В рамках архитектуры организации как целостной системы, согласно ARIS, выделяют ряд подсистем:
  • организационная — идентифицирует общую структуру организации в виде иерархии подразделений и должностных лиц, а также территориальное расположение организации;
  • функциональная — идентифицирует функции в организации;
  • подсистемы входов/выходов — определяют потоки продуктов и услуг в рамках организации;
  • информационная (подсистема данных) — описывает сбор, тиражирование и доступ к информационным ресурсам и запасам;
  • подсистема процессов управления — определяет логическую последовательность выполнения функций на основе идентифицированных функций;
  • подсистема целей организации — описывает структурную последовательность целей, достигаемых в ходе выполнения того или иного процесса;
  • подсистема средств производства — описывает жизненный цикл основных и вспомогательных средств производства;
  • подсистема человеческих ресурсов — описывает привлечение, обучение, ротацию и продвижение персонала организации;
  • подсистема расположения организационных структур — описывает территориальное расположение структурных единиц организации.

После идентификации подсистем организации производится их декомпозиция, в результате которой каждая из этих подсистем разбивается на модули. Подсистемы не являются обособленными, поэтому одинаковые модули, полученные в результате декомпозиции, могут использоваться в описании различных структур в рамках целостной архитектуры организации. Аналогично методологии IDEF имеется ограничение сложности представления структуры организации в виде предельного числа типов моделей. ARIS выделяет пять типов моделей:
  1. организационные модели — описывают структуру системы в виде иерархии организационных подразделений, должностных лиц, связи между ними и территориальную принадлежность;
  2. функциональные модели — идентифицируют функции и процессы в организации в организации;
  3. информационные модели (модели информационных ресурсов и информационных запасов) — отражают структуру информационных ресурсов и информационных запасов, необходимых для реализации всех функций организации;
  4. модели процессов и управления — отражают пути реализации процессов организации и объединяют другие модели;
  5. модели входов-выходов — описывают движение потоков внутри организации (например, движение денежных средств и т.п.).

Остальные модели составляются на основе вышеперечисленных.

Все подсистемы организации связываются между собой в виде совокупности взаимосвязанных и скоординированных между собой моделей.
Таким образом, разработку систем ДОУ с учетом использования указанных стандартов, методологий и средств можно разделить на следующие этапы:
  • анализ существующей системы управления, построение функциональной модели организации;
  • функциональную декомпозицию, построение графических диаграмм;
  • построение функциональных моделей с функционально-стоимостной оценкой предлагаемых решений;
  • построение бизнес-процессов на основе построенных функциональных моделей;
  • анализ основных и вспомогательных бизнес-процессов, переход к проектированию системы ДОУ;
  • описание информационных потоков, построение диаграмм потоков данных и диаграмм потоков работ;
  • внедрение и эксплуатацию информационной системы управления производством;
  • построение информационной системы на основе однозначного соответствия между материальными и информационными потоками.

Выбор методологии идентификации процессов и средств проектирования системы ДОУ — сложный и многогранный процесс, требующий значительных инвестиций. Жизненный цикл создания сложной информационной системы сопоставим с ожидаемым временем ее эксплуатации. В современных условиях организации осуществляют реинжиниринг процессов примерно один раз в два года (в соответствии с требованиями к внутреннему аудиту в рамках требований стандартов ISO). Срок разработки информационной системы крупного масштаба составляет также около двух лет. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания крупной ИС жиз
ненно необходим инструмент, значительно (в несколько раз) уменьшающий время разработки ИС. Помимо этого следует учитывать ряд требований:
  • функциональные возможности средства идентификации и описания процессов — должны учитываться факторы избыточности, минимальной достаточности, перспективного развития организации. Важно также учитывать и возможности для совместной работы нескольких сотрудников на одним проектом, а также возможности интеграции с другими программными продуктами, используемыми в организации (например, базами данных и т.п.);
  • стоимость — как уже говорилось, срок возврата инвестиций в разработку ИС, как правило, достаточно долгий, что важно учитывать при выборе методологии описания процессов. Кроме того, зачастую помимо основного пакета существует необходимость приобретения дополнений, стоимость которых может превышать стоимость самого ПО;
  • необходимость обучения персонала — внедрение новых программных средств в организации требует дополнительного обучения сотрудников, которые будут эти средства использовать;
  • техническая поддержка — необходимо учитывать стоимость обновлений программных продуктов, надежность программного обеспечения и функционирование службы поддержки клиентов (в виде форумов, ответов на вопросы, задаваемые пользователями, и т.п.).

По функциональным возможностям эти средства можно условно разбить на следующие группы.
  1. Средства функционального моделирования — для решения задачи функционального моделирования применяются два типа моделей: SADT-диаграммы и диаграммы потоков данных (DFD). В случае наличия в моделируемой системе программной/программируемой части (т.е. практически всегда) предпочтение, как правило, отдается DFD.
  2. Средства событийного моделирования — основываются на расширении DFD потоков данных за счет введения управляющих потоков и процессов, являющихся интерфейсом между DFD и спецификациями управления, моделирующими поведение. Спецификации управления, как правило, формализуются с помощью диаграмм STD, позволяющих задавать состояния различных объектов системы.
  3. Средства технологического моделирования — используются диаграммы PFDD (описания последовательности этапов процесса) и OSTN (состояния объекта и его трансформаций в процессе).
  4. Средства информационного моделирования — используются диаграммы ERD «сущность-связь».

На российском рынке присутствует достаточно много программных инструментальных средств, с помощью которых можно строить функциональные, информационные, стоимостные и имитационные модели деловых процессов, системы управления и системы управления качеством организаций и предприятий. Например, BPwin, ERwin, Design/IDEF, EasyABC, Design/CPN, S-DesigMr, CASE- Аналитик, Designer/2000, ReThink, ABC FlowCharter, Oracle*Case, Visible Analyst Workbench, EasyCASE, Silverrun, Westmount I-CASE, PRO- IV, Select Yourdon, программные продукты серии ARIS и др. Наиболее популярными продуктами являются:
  • BPwin/ERwin (Platinum Technology);
  • ARIS (Scheer AG);
  • Rational Rose (Rational Software Corporation).

Их основные функциональные особенности приведены в табл. 4.1 (источник: http://www.idefinfo.ru/content/view/23/25/).
Таблица 4.1. Сопоставительный анализ комплексов функционального моделирования
Функции, свойства ARIS BPwin/
Rwin
Rational Rose
1. Моделирование организационных функций и процессов + + +
2. Разработка технического задания + +/ - +/ —
3. Функционально-стоимостной анализ + + +/ —
4. Оптимизация бизнес-процессов +
5. Имитационное моделирование, событийно-управляемое моделирование + +/ —
6. Генерация кода приложения - + +/ —
7. Оформление проектной документации; генерация технологических инструкций для рабочих мест + +/ — +
8. Хранение моделей деятельности предприятий + +/ — +/ —
9. Создание концептуальных и физических моделей структуры базы данных +/ - + +
10. Генерация программного кода,
SQL-сценариев для создания структуры базы данных.
+ +/ —
11. Стандартное представление основных бизнес-процессов (более 100) +
12. Ведение библиотеки типовых бизнес моделей + +/ — +/ —
13. Групповая работа над проектом + + +
14. Выдача встроенных отчетов по стандарту ISO9000 +
Ценовые различия, долл. 31 740 23 685 40 520
(+ 14 610) (+ 4 245) (+ ?)



Помимо средств идентификации и визуализации процессов существуют средства, которые в первую очередь нацелены на рационализацию и совершенствование разработки программных средств систем ДОУ. Основными задачами, которые ставятся перед такими средствами, являются:
  • интеграция средств описания процессов и средств разработки;
  • параллельное планирование и правильная постановка задач перед разработчиками систем ДОУ;
  • последовательная разработка средств автоматизации управления организацией;
  • управление изменениями и версиями программного обеспечения (что особенно важно в ходе реинжиниринга процессов);
  • сопровождение системы документационного обеспечения управления.

Одним из таких средств является нотация Unified Modeling Language (UML). Основными понятиями, используемыми в UML, являются:
  • бизнес-транзакция — реализация некоторой функции управления определенной предметной областью, осуществляемой на некотором уровне управления на основе совокупности ресурсов, результатом которой является значимый для функционирования организации результат;
  • бизнес-процесс — совокупность бизнес-транзакций, реализующая законченный цикл управления некоторой предметной областью функционирования организации;
  • организация — сбалансированная интегративная совокупность взаимосвязанных бизнес-процессов, обеспечивающая достижение целей функционирования организации.

Применение UML при моделировании организации и ее бизнес-процессов позволяет в полной мере реализовать представление в динамическом, статическом и структурном аспектах. Получаемая в ходе объектно-ориентированного анализа и проектирования UML- модель организации представляет собой совокупность взаимосвязанных диаграмм, идентифицирующих бизнес-процессы, описывающих их жизненный цикл, структуру организации и взаимодействие процессов ее функционирования во времени и пространстве с привязкой к используемым ресурсам и получаемым результатам.
UML-модель применительно к бизнес-моделированию может включать в себя следующие диаграммы:
  • структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, струк
    турно организующие предметную область и иерархически упорядоченную структуру организации;
  • динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесов в их взаимодействии во времени и пространстве с привязкой к используемым ресурсам и получаемым результатам;
  • статический аспект: Class-диаграммы, отражающие совокупность взаимосвязанных объектов, т.е. рассматривает логическую структуру предметной области, ее внутренние концепции, иерархию объектов и статические связи между ними, структуры данных и объектов; Deployment-диаграммы, отражающие технологические ресурсы организации.

UML-модель в части бизнес-модели позволяет получить детальные ответы на ряд типичных вопросов о деятельности организации:
  • каковы виды деятельности организации и предметные области управления (предметно-структурный аспект)?
  • какие функционируют бизнес-процессы (функциональный аспект)?
  • кто и где выполняет бизнес-процессы (организационный аспект)?
  • как выполняются бизнес-процессы (методический аспект)?
  • когда выполняются бизнес-процессы (динамический аспект)?
  • что, откуда и куда перемещается, обрабатывается, получается в материальных и в связанных с ними информационных потоках (сущностно-элементный аспект)?
  • с помощью чего (какими инструментами) выполняются бизнес-процессы (ресурсный и технологический аспекты)?

Таким образом, UML-модель рассматривается как средство документирования и анализа существующих бизнес-процессов, их оптимизации или перепроектирования, моделирования новых бизнес- процессов во взаимосвязи с организационной структурой, предметными областями и функциями управления организацией, а также как фундаментальная основа для формирования требований к построению информационных систем, поддерживающих процессы деятельности организации.
C UML тесно связана методология RUP — rational unified process, представляющая собой базу знаний в виде набора исчерпывающих рекомендаций для создания практически любых программных продуктов, в том числе и систем ДОУ. RUP подробно рассказывает, когда, кто и что должен делать в проекте, чтобы в результате получить ИС в установленные сроки, с определенной функциональностью и в рамках отведенного бюджета. Для реализации тре
бований заказчика в установленные сроки унифицированный процесс разделяется на фазы, которые состоят из итераций (последовательных изменений), поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели — созданию программной системы.
Статическая структура RUP состоит из дисциплин, в которые группируются работы, задачи, артефакты и роли. Для описания осмысленной последовательности выполнения работ и задач используются рабочие процессы. Они описывают, кто, что, как и когда выполняет в процессе. В RUP входят шесть основных дисциплин:
  1. бизнес-моделирование (business modeling);
  2. управление требованиями (requirements);
  3. анализ и проектирование (analysis and design);
  4. реализация (implementation);
  5. тестирование (test);
  6. развертывание (deployment) и три вспомогательных:
  1. управление проектом (project management);
  2. управление изменениями (change management);
  3. среда (environment).

Динамическая структура RUP состоит из четырех фаз: inception, elaboration, construction и transition. Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.
Методология UML + RUP позволяет достичь необходимого уровня координации при разработке программных продуктов, информационных систем, систем документационного обеспечения управления, что особенно важно при реализации крупных проектов. Кроме того, методики фиксации последовательных изменений и оперативного внедрения изменений в действующую структуру позволяют производить реинжиниринг процессов с минимальными потерями для работоспособности информационной системы организации.
URL-модель документооборота администрации города. В качестве примера рассмотрим модель документооборота Администрации города Анжеро-Судженска, построенного в соответствии с регламентом делопроизводства, принятого ею.
На основе использования унифицированного процесса разработки реализуются четыре вида работ:
  1. перечисление возможных требований;
  2. осознание контекста системы;
  3. определение функциональных требований;
  4. определение нефункциональных требований.

Каждая из них является важной, но мы остановимся лишь на решении второй задачи. Контекст системы служит для осознания разработчиками той предметной области, для которой эта система разрабатывается. Контекст может быть представлен в двух видах: модель деловых процессов или модель предметной области. Последняя является частным случаем и описывает основные объекты предметной области, их функциональность, связи между ними. Модель предметной области обычно статична и больше акцентирует внимание на параметрах объектов, чем на их операциях.
Модель деловых процессов содержит в себе элементы, описываемые предметной областью, но в большей степени служит для представления функциональных компонентов реальной системы. Унифицированный процесс разработки предлагает подходы для выявления вариантов использования и построения архитектуры системы, исходя из построенной модели деловых процессов.
Технически модель деловых процессов поддерживается двумя типами моделей: моделью прецедентов и моделью объектов. В нотации UML первый тип представлен в основном диаграммами прецедентов, а второй — диаграммами классов. Хотя оба типа моделей могут быть дополнены и другими видами диаграмм UML для большего понимания контекста.
Перейдем теперь к составлению модели деловых процессов для делопроизводства администрации города (в дальнейшем — организации). Перечислим основные виды документов, которые участвуют в документообороте:
  1. входящие — под этим термином будем понимать любые документы, поступающие от граждан, организаций, в том числе вышестоящих, а также устные обращения граждан;
  2. исходящие — документы, которые генерируются внутри самой организации и направляются к внешним участникам документооборота;
  3. внутренние — документы, которые создаются внутри организации и конечным пунктом назначения, как правило, является также организация. Как будет показано в дальнейшем, в эту категорию попадают также внутренние распоряжения и служебные записки, приводящие к адресату вне организации. Основное отличие между ними заключается лишь в особенностях заключительного этапа;
  4. протоколы — документы созданные коллегиальными органами, функционирующими при организации. По функциональному назначению эти документы подобны остальным внутренним до
    кументам, однако схема их движения имеет существенные отличия, что приводит к необходимости отдельного рассмотрения данного вида документов.

Выделим основные действия, которые участники документооборота осуществляют над объектом Документ.
  1. Инициация — действия, побуждающие начать движение некоторого документа: обращение гражданина, получение письма по почте и т.п.
  2. Исполнение — мероприятия по осуществлению указаний, представленных в документе или его части, рапорт об их проведении, а также сообщение об отказе от исполнения с указанием причин.
  3. Старт документооборота — создание документа: подготовка текста устного обращения, служебной записки, проекта постановления. Результатом действия является создание экземпляра сущности Документ.
  4. Контроль за исполнением — наблюдение за движением документа, анализ выполнения, просмотр архива.
  5. Стоп (остановка документооборота) — окончание движения документа в системе, обычно означающее передачу документа в архив.
  6. Отправка — передача документа внешним или внутренним адресатам.
  7. Регистрация — присвоение документу номера, подтверждение его внутреннего юридического статуса.
  8. Согласование — передача или перенаправление документа между бизнес-рабочими для подтверждения его силы либо перенаправления поручения по исполнению. Частным видом согласования является утверждение — окончательное подтверждение юридического статуса документа.

В соответствии с обязанностями по исполнению операций документооборота выделим следующих участников (под словом «лицо» понимается как физическое лицо, так и юридическое, а также структурные подразделения организации, ее сотрудники, руководители и коллегиальные органы).
  • Участник — любое лицо, участвующее в документообороте. Участник может производить Инициацию документооборота, а также являться адресатом операции Отправка.
  • Исполнитель — любое лицо, которое может осуществить операцию Исполнение. Исполнитель также является участником, так как может вызвать Инициацию документооборота и являться адресатом Отправки (как любое лицо).
  • Сотрудник — лицо, находящееся, как правило, внутри структуры организации, которое может выполнять функции исполнителя, и, кроме того, выполнять операцию Старт.
  • Контролер — сотрудник, выполняющий функции Контроля.
  • Менеджер — контролер, обладающий правом выполнять операцию Стоп.
  • Оформитель — менеджер, производящий канцелярские операции Отправка и Регистрация.
  • Руководитель — менеджер, обладающий правом производить подтверждение в операциях Согласование и Утверждение.

На основании изложенного можно составить следующую схему модели вариантов использования (рис. 4.5). Запись схем будем вести в нотации, принятой для моделирования в рамках унифицированного процесса разработки Rational Rose.

Рис. 4.7. Основные объекты, связанные с движением документа
Рис. 4.7. Основные объекты, связанные с движением документа
Рис. 4.6. Объектная модель деловы1х процессов
Рис. 4.6. Объектная модель деловы1х процессов
Следует обратить внимание на то, что Менеджер является абстрактным классом, так как далее будет видно, что экземпляры данного класса не участвуют в процессах. Необходимость его введения обусловлена передачей наследуемым классам функциональности, связанной с операцией Стоп. Кроме того, для простоты на схеме представлены только активные участники. Так, например, инициатором Отправки является Оформитель, но кроме него к этому действию имеет отношение Участник, который играет роль Адресата по отношению к этому прецеденту. Пассивное участие можно увидеть на схемах модели бизнес-объектов (рис. 4.6—4.11).

Рис. 4.9. Движение документов вида «Исходящие»
Рис. 4.9. Движение документов вида «Исходящие»




Рис. 4.11. Движение документов вида «Протокол»
Рис. 4.11. Движение документов вида «Протокол»
Естественно, что участники модели в чистом виде не встречаются в реальной жизни, однако каждого реального участника процесса можно описать, пользуясь данной терминологией. Например, секретарь коллегиального органа относится к классу Оформитель, так же как и приемная по обращению граждан, а сам коллегиальный орган или, например, начальник отдела относятся к классу Руководитель.

Чтобы более четко выделить участников, связи между ними, а также процессы, в которых они участвуют, построим объектную бизнес-модель.
На данной схеме представлены все возможные связи между участниками документооборота. При этом все акторы схемы прецедентов, являющиеся внутренними по отношению к Системе, переобозначе- ны стереотипом «бизнес-рабочий». Кроме того, введена управляющая бизнес-сущность Движение документа, основная задача которой — координировать действия других бизнес-рабочих и акторов, перемещать документ по этапам движения, формировать схему движения в соответствии с шаблонами и корректировать ее в зависимости от действий участников.
Естественно, что в реальности существуют еще некоторые бизнес-сущности, участвующие в документообороте. В первую очередь это сам Документ. Кроме того, уже упоминалось понятие Архив — коллекция документов, завершивших свое движение. Схема на рис. 4.7 показывает связи между этими объектами, Движением документа и участником Контролер. Далее для упрощения мы будем опускать связи, представленные на этой схеме, учитывая, что операция Перенос в архив осуществляется непосредственно за операцией Стоп для документа, а операция Контроль может выполняться контролером в любое время с момента регистрация.
Опишем конкретные схемы движения различных видов документов.
Движение документов вида «Входящие» (см. рис. 4.8) начинается с инициации, выполняемой участником по отношению к Оформителю (гражданин обратился в приемную, в сектор делопроизводства пришло письмо). Оформитель производит операцию Старт, создавая новый экземпляр класса Движение документа. Последний, в свою очередь, согласно заложенной в него схеме, требует от Оформителя регистрации документа (т.е. присвоения номера, заполнения даты получения и т.п.). Как уже упоминалось, с момента регистрации Документ становится контрольным, т.е. любой контролер (руководитель, сектор контроля и т.п.) может отслеживать его движение и исполнение. Далее схема движения такого документа адресует его к Руководителю (например, начальнику отдела, отвечающего за указанный в письме круг вопросов) для согласования, т.е. принятия решения об исполнении и назначении исполнителей. При этом может производиться корректировка схемы движения, т.е. перенаправление документа другим руководителям, связанное, например, с их компетенцией. Руководитель, оказавшийся в конце цепочки согласований, поручает исполнение указаний документа
(включая дополнительный текст, появившийся в результате согласований) некоторому исполнителю.
По окончании работ исполнитель сообщает этому руководителю об успешности или не успешности завершения исполнения, руководитель останавливает движение документа (операция Стоп), внося информацию об исполнении. Как уже было сказано, после этого документ со всей приращенной информацией автоматически переносится в архив.
Движение исходящих документов начинается с инициации, которую выполняет сотрудник (см. рис. 4.9). За старт движения документа в этой цепи отвечает оформитель (например, машбюро или канцелярия). Прежде чем пройти регистрацию, документ проходит этапы согласования (аналогично предыдущей схеме их может быть несколько), а затем утверждение у руководителя наивысшего ранга, обладающего компетенцией в данном вопросе (обычно это глава города). После этого оформитель регистрирует документ и останавливает его движение. Затем оформитель отправляет документ адресату (участнику).
Старт движения документов «служебная записка» (см. рис. 4.10) в отличие от предыдущих случаев начинается сотрудником (можно считать, что этап инициация выполняется самим сотрудником по отношению к себе же). После согласования с руководителем, компетентным в данном вопросе, производится регистрация документа у оформителя и окончание движения. На самом деле в данной схеме операция отправка реально, примерно в половине случаев означает дальнейшее движение, аналогичное исполнению в схеме входящих документов. Для упрощения на данной диаграмме соответствующая часть схемы не показана. Именно благодаря такому обобщению к данной категории можно отнести и большинство других документов внутреннего характера.
И наконец, схема движение документов вида «протокол» аналогична предыдущей схеме с двумя небольшими отличиями: старт движения начинает оформитель (например, секретарь градостроительного совета), а вместо согласования всегда выполняется операция Утверждение, поскольку решение коллегиального органа (здесь — Руководитель) является окончательным (см. рис. 4.11). Выполнение операции Отправка аналогично предыдущей схеме т.е. зачастую влечет дальнейшие процессы по исполнению и контролю, которые не представлены на данной схеме.
Моделирование электронного документооборота обеспечивает упорядоченность, рациональность и контролируемость всех процессов ДОУ, возможность их реинжиниринга для поддержания качест
ва управленческих услуг и эффективности принимаемых решений. Визуализация моделей повышает их информативность и обозримость процессов документооборота в организации, а программная поддержка исключает возможные нестыковки и ошибки. 
<< | >>
Источник: Гринберг А.С., Горбачев Н.Н., Мухаметшина О.А.. Документационное обеспечение управления. Учебник. 2010

Еще по теме Модели электронного документооборота:

  1. Электронный документооборот. Электронные административные регламенты
  2. Управление электронным документооборотом
  3. Системы автоматизации делопроизводства и электронного документооборота
  4. Электронные документы и «электронное правительство»
  5. График документооборота
  6. 4. Аудит системы документации и документооборота
  7. 3.4.2. Документационное обеспечение системы управления персоналом. СИТУАЦИЯ «ПОСТРОЕНИЕ СХЕМЫ ДОКУМЕНТООБОРОТА»
  8. 2.5. Организация документооборота
  9. 5.5. Порядок построения документооборота аудиторских компаний
  10. Документационное обеспечение электронной торговли
  11. Электрон