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

Последовательность этапов внедрения СЭД
В соответствии с разработанными мировыми и отечественными практиками внедрения информационных систем (ИС) процесс внедрения СЭД включает несколько этапов работ, в результате выполнения которых разрабатываются соответствующие модели ИС.

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

На этапе предпроектного обследования, исходя из полученной первичной информации, назначается Руководитель проекта (РП), который составляет базовый план работ, иерархическую структуру работ -Work Breakdown Structure (WBS), а также Устав проекта (см. Методику управления проектами – PMBOK).
Предпроектное обследование
Пример WBS проекта «Внедрения СЭД»

Выбор СЭД
1. Составьте список требуемых возможностей продукта, указав, какие из них обязательны, а какие желательны. Этот список можно затем послать разным вендорам в качестве запроса. Пример списка обязательных функций:

Выбор СЭД
2. Проверьте, чтобы процесс выбора включал сбор следующей информации от вендоров в ответ на ваши запросы:
Системные требования. Эта информация необходима, чтобы обеспечить требуемую инфраструктуру оборудования, чтобы приложения работали эффективно. Без надлежащих аппаратных ресурсов программное обеспечение будет работать не с оптимальной производительностью, сводя к минимуму любой выигрыш времени, ожидаемый от внедрения электронного документооборота.
Требования, касающиеся специализированного оборудования: электронный идентификатор подписи, сканер, веб-сервер и т. п.
Стоимость сопровождения ПО и технической поддержки.
Предлагается ли техническая поддержка? Какова надежность разработчика?
Успешный опыт внедрения в организациях аналогичного размера.
Как осуществляется резервное копирование данных?
Предлагаемые программы обучения.
Доступность профессиональных услуг интеграции и адаптации на заказ.
Является ли ПО проприетарным или построено на открытой архитектуре?
Имеется ли комплект инструментов разработки (SDK) и/или интерфейс прикладного программирования (API) для интеграции с существующими программными продуктами?

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

Информационное обследование
Информационное обследование – сбор информации и данных о проекте внедрения СЭД, исследование существующих правил и способов работы с документами, выявление функциональных требований к СЭД, а также структуризация полученных данных и разработка концептуальной модели Систем с целью постановки задач на разработку и настройку СЭД.
В ходе информационного обследования исследуются и описываются существующие бизнес-процессы («as is» – «как есть»). В результате анализа собранных данных разрабатываются оптимизированные бизнес-процессы («to be» – «как должно быть»), формулируются функциональные требования к СЭД.

Целями информационного обследования являются:
изучение и точное описание бизнес-процессов, подлежащих автоматизации;
разработка рекомендаций по оптимизации документопотоков и организации документооборота и делопроизводства;
определение и описание модификаций системы, интерфейсов, в т.ч. интерфейсов с внешними системами и средств переноса данных из существующих программ, которые должны быть разработаны и внедрены в ходе проекта;
разработка технического задания (ТЗ).
Результаты работы находят отражение в документе «Функциональные требования» или «Отчете», или «Техническом задании» (в зависимости от сложности проекта).
Информационное обследование

С целью получения необходимой информации проводится анкетирование и интервьюирование основных пользователей (Заказчика, руководителя проекта, руководителей подразделений, основных пользователей) аналогично предпроектному обследованию, но на более детальном уровне.
Информационное обследование

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

Информационное обследование
Примеры оформления информации (оперограммы и др.), а также перечень вопросов, которые можно использовать в анкетах или при интервьюировании пользователей, Вы можете посмотреть в журнале «Делопроизводство и документооборот на предприятии» №2 2007 г.

Информационное обследование
Пример оформления алгоритма обработки приказов по основной деятельности

Информационное обследование
Пример оперограммы жизненного цикла приказа по основной деятельности

Информационное обследование
Пример оформления информации о контроле документов

Информационное обследование
Более глубоким является построение модели бизнес-процессов предприятия в форматах, отражающих процессы документационных и информационных потоков. Это следующие форматы:
IDEF0 или IDEF3, но обязательно с DFD - (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией внутри системы, так и самой системы с внешней информационной средой.
Стандартным является метод, при котором верхние 3-4 уровня модели строятся в нотации IDEF0, а завершающий нижний уровень — в нотации DFD.

Пример диаграммы DFD
Диаграмма потоков данных (Allfusion Process Modeler = Bpwin)

Информационное обследование
2) EPC – (англ. Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции.
Нотация EPC (верхнего уровня) была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS. За основу была взята нотация UML (Unified Modeling Language ) диаграммы деятельности).
Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т.е. выполнение Функции создает некоторое событие (состояние)
Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение.
Для ветвления процесса используются операторы И, ИЛИ, исключающее ИЛИ.
EPC используется на низших уровнях описания бизнес-модели, когда стоит задача описать подробный ход выполнения бизнес-процесса. Функции EPC могут быть декомпозированы (разбиты на детальные бизнес-процессы только в нотации EPC).

EPC-диаграмма «Поиск и выбор поставщика» (Business Studio)

Диаграмма Процедуры (Cross Functional Flowchart) диаграмма «Пуско-наладочные работы» (Business Studio)

Информационное обследование
3) BPMN – (англ. Business Process Modeling Notation), спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах (BPD).
Эта спецификация разработана организацией Business Process Management Initiative (BPMI) в 2001-2004 годах с учётом множества ранее существовавших диаграмм (UML и EPC, IDEF3). С 2005 года стандарт BPMN курирует некоммерческая международная организация OMG (разработчик UML).
Основной целью данной разработки было получение нотации верхнего уровня, легко понимаемой всеми пользователями: от бизнес-аналитика, создающего первые наброски описаний процессов, к техническим специалистам, отвечающим за реализацию этих процессов в Системе, и, наконец, до людей бизнеса, которые управляют этими процессами и контролируют их работу.
Спецификация BPMN 2.0 — это книга размером в триста страниц, которая содержит множество графических иллюстраций с подробными комментариями: всего около 130 рисунков! (бесплатно на www.bpmn.org)

Диаграмма процесса разрешения разногласий с помощью голосования по электронной почте в нотации BPMN

Диаграмма процесса работ с входящими документами в нотации BPMN

Диаграмма процесса работ по заключению договора в нотации BPMN

Нотации, технологии и ПО для моделирования БП, сравнение.

Диаграмма «Согласование договора» в дизайнере маршрута СЭД «Евфрат-документооборот»

Диаграмма «Согласование договора» в дизайнере маршрута СЭД «PayDox»

Маршрутизация документа «Приказ» в дизайнере маршрута СЭД «NauDOC»

Информационное обследование
В результате проведенных работ по организации эффективного делопроизводства и документооборота и принятом решении о внедрении системы электронного документооборота проектная команда формулирует требования к автоматизированной системе, составляет перечень процессов, подлежащих автоматизации, определяет приоритеты и очередность их автоматизации.
На основе перечисленной выше информации разрабатываются функциональные требования к СЭД или техническое задание на ее разработку. В частности, Аналитик должен составить требования к формату и составу регистрационно-контрольных карточек (набор и расположение полей в карточке, способы заполнения в СЭД и др.), маршрутам движения документов и другие требования, необходимые для настройки и разработки СЭД.

Информационное обследование
Четких требований для проведения обследования не существует, поэтому в каждом конкретном случае, используя готовые наработки, нужно проявлять творческий подход к получению необходимой информации, ее структуризации и отображению.
Информационное обследование является важным этапом оптимизации ДОУ и внедрения СЭД. Ведь от полученной информации и качества ее представления напрямую зависит качество принятых решений по оптимизации процессов и разработки требований к функционалу СЭД. В связи с этим необходимо придерживаться главного принципа обследования – получить полную, достоверную и актуальную информацию о процессах, которые планируется автоматизировать.

Как избежать неудачных внедрений СЭД
Перед началом внедрения СЭД необходимо:
Привести в порядок номенклатуру дел и принципы индексации во всех подразделениях;
Отладить регламент делопроизводства;
Разработать и внедрить показатели исполнительской дисциплины.
Система должна вводиться поэтапно, причем каждый этап должен быть функционально законченным.
Исполнитель – компания внедренец должен быть надежным, профессиональным и опытным, уважающим требования Заказчика.
Выбор «своей» системы.
Правильное планирование, выбор системы и платформы, реализация и внедрение проекта.

Как избежать неудачных внедрений СЭД
Участие топ-менеджеров в работе должно носить не разовый характер (подписал техзадание, отдал приказ), а постоянный, в том числе для оперативного преодоления возникающих трудностей.
Главный акцент на необходимость воли руководства предприятия внедрить СЭД в том числе в плане выделения ресурсов — финансовых, материальных, кадровых.
Ключевой аспект проблемы — люди, конечные пользователи. Нужно не только подготовить и обучить сотрудников, но и найти для них мотивацию. Надо помнить, что более квалифицированный персонал (который научится работать с компьютерными средствами) стоит дороже, поэтому руководству компании следует заранее готовиться к тому, что придется повышать зарплату своим подчиненным. И еще: процесс повышения квалификации и переподготовки сотрудников должен быть постоянным, что, в свою очередь, требует постоянного выделения средств на это.

Разработка и настройка СЭД
Целями физической реализации СЭД являются:
На данном этапе осуществляется реализация описанных в ТЗ требований: настройка СЭД, ее доработка или разработка новых функций Системы на выбранной платформе
разработка структуры БД СЭД;
разработка экранных форм;
разработка механизмов: визирования, регистрации, исполнения и др.;
разработка технической документации на Систему.

Разработка и настройка СЭД
В ходе этой стадии непосредственно реализуются описанные на этапе информационного обследования требования.
Большинство работ по разработке выполняется вне территории Заказчика, поэтому, постоянное и эффективное взаимодействие с Заказчиком является ключевым фактором для успешного завершения разработки и приемки системы Заказчиком.
Процесс тестирования является решающим в обеспечении качества разработки. Планирование и подготовка тестирования должны начаться насколько возможно рано. Конечные пользователи должны быть максимально вовлечены в подготовку критериев тестирования. Критически важным является то, чтобы тестирование проводилось Заказчиком.

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

Опытно-промышленная эксплуатация
Данный этап является наиболее сложным для всех участников проекта (пользователей, разработчиков, внедренцев). На данном этапе происходит адаптация программного продукта, его апробирование, тестирование в реальных условиях работы. Наиболее сложным является преодоление психологического барьера у пользователей при начале работы в новой для них среде, т.к. пользователи вынуждены изменить привычные и устоявшиеся для них способы работы. В связи с этим на данном этапе важно проводить обучение и консультирование пользователей. Это поможет им адаптироваться к новым условиям работы.

Промышленная эксплуатация
Это использование стабильно работающей и полностью отвечающей требованиям пользователей СЭД в процессе выполнения должностных обязанностей сотрудников организации.
Работы, выполняемые в процессе эксплуатации СЭД:
Консультирование и обучение пользователей по вопросам работы в СЭД;
Администрирование справочников (организационная структура, пользователей, маршруты согласования, списки рассылки и др.);
Администрирование сервера и ПО;
Осуществление резервного копирования (back-up)
На данном этапе можно инициировать развитие СЭД: добавление новых функций, расширение границ проекта внедрения (добавление новых категорий/видов документов, расширение числа пользователей / подразделений / предприятий холдинга).

С целью сокращения времени на реализацию и внедрение СЭД работы перечисленных этапов могут реализовываться параллельно в зависимости от уровня сложности задач автоматизации, используемого программного обеспечения (ПО) и др.
На протяжении всего жизненного цикла проекта внедрения СЭД должны проводиться работы по управлению проектом. Например, рекомендуется использовать американский стандарт ANSI/PMI 99-001-2004 (Руководство PMBOK).

Управление проектом
Проект – временное предприятие для создания уникальных продуктов или услуг
Управление проектом – отдельная область менеджмента, предназначенная специально для управления временной деятельностью с уникальными результатами
Самые известные/широко используемые стандарты управления проектами:
PMBOK (американский стандарт: www.pmi.ru);
Price2 (английский стандарт: www.ogc.gov.uk/prince2);
IPMA (европейский стандарт: www.ipma.org);
P2M (японский стандарт: www.pmcc.or.jp/eng/index.htm)

Основные действующие лица
Заинтересованные стороны в проекте
Команда проекта
Команда управления проектом
Менеджер проекта
Спонсор проекта
© PMI PMBOK
Управление проектом

Менеджер (руководитель) проекта – лицо, ответственное за управление проектом
Спонсор проекта – лицо, обеспечивающее финансовые ресурсы проекта и осуществляющее административную и организационную поддержку проекта
Заказчик (потребитель) проекта – лицо, которое будет использовать результаты проекта
Заинтересованные стороны в проекте – лица, активно вовлеченные в проекта и/или интересы которых могут быть затронуты выполнением проекта (которые влияют и на которых влияют результаты проекта)
© PMI PMBOK
Управление проектом

Управление проектом
© PMI PMBOK
Заинтересованные стороны в проекте

Управление проектом
© PMI PMBOK
Пример жизненного цикла проекта
Жизненный цикл проекта
Выходы управления проектом
Основные цели и задачи проекта
Начало
Устав
Требования
Спецификация
План
Базовый план
Принятие
Утверждение
Передача заказчику
Завершение
Продукт

Управление проектом
© PMI PMBOK
Устав проекта – это первый официальный документа проекта. Формально подтверждает существование проекта. Наделяет РП полномочиями задействовать ресурсы организации на операциях проекта. РП определяется и назначается как можно раньше. РП необходимо всегда назначать до начала планирования и желательно на этапе разработки Устава проекта.
Устав проекта подлежит детализации в фазе планирования проекта.
Устав проекта может включать в себя:
Описание бизнес потребностей для инициации проекта;
Цель или основание проекта;
Описание потребностей и ожиданий, а также степень влияния заинтересованных сторон;
Суммарный план ключевых контрольных точек проекта (Milestones);
Описание функциональных организаций;
Описание организационных допущений и ограничений;
Суммарный бюджет проекта.

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

Управление проектом
© PMI PMBOK
План управления проекта – это официально утвержденный документ для руководства исполнением проекта. Это документ, который содержит и интегрирует результаты планирования во всех областях проекта (время, затраты, ресурсы, риски, качество и т.д.)
План управления проектом может состоять из одного или нескольких дополнительных планов, таких как:
План управления содержанием проекта;
Календарный план;
План управления стоимостью;
План управления качеством;
План управления персоналом;
План управления взаимодействием;
План управления рисками;
План управления снабжением;
План усовершенствования процессов
Невозможно создать детальный план для всего проекта сразу.

Управление проектом
© PMI PMBOK
Базовый план – это официально утвержденный документ, относительно которого измеряется выполнение проекта и который будет использован для управления и контроля за исполнением проекта. Используется для контроля отклонения хода проекта.
Рабочий план – это документ или набор документов, который изменяется по мере выполнения проекта и поступления дополнительной информации. Рабочий план, как правило, всегда отличается от базового. Рабочий план изменяется РП.

Управление проектом
© PMI PMBOK
Исполнение проекта – основной процесс осуществления проекта (задействована значительная часть ресурсов).
В основные обязанности РП входят:
Интеграция и координация действий по выполнению плана проекта;
Постоянное сравнение и анализ отклонений текущего исполнения проекта по сравнению с базовым планом проекта;
При необходимости – инициация запросов на изменение;
Прогнозы стоимости и сроков проекта.

Управление проектом
© PMI PMBOK
Закономерности жизненного цикла проекта
Время
Возможность влияния
Стоимость изменений
Возможность влияния на проект всех заинтересованных сторон уменьшается по мере продвижения к финишу, стоимость изменений, напротив, растет.