СЭД протяженностью в тысячи километров

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

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

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

четкий и прозрачный контроль доступа:

• контроль исполнения и сбор отчетности по исполнению; 

• направленные на повышение эффективности использования информации; 

• сокращение времени доступа к документам; 

классификация документов, облегчающая их поиск;:

• структурированное хранение связанных документов; 

• история работы с документом.

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

«Территориальная распределенность для госструктур оборачивается, как правило, усложнением организационной структуры, — рассказывает Игорь Илюхин, руководитель направления по работе с государственными заказчиками компании „Систематика“. — Проблемы организации СЭД в этом случае заключаются в согласовании двух видов регламентов (бизнес-процессов) — между подразделениями и внутри подразделений».

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

Коллективный выбор для коллективной работы

СЭД территориально-распределенной организации может быть построена либо на базе централизованной архитектуры, либо по децентрализованному принципу. Поскольку на сегодняшний день сетевая инфраструктура зачастую не позволяет организовать надежный и бесперебойный доступ всех территориальных площадок к центральному узлу, наиболее жизнеспособной оказывается СЭД с объединенными локальными узлами. Вадим Ипатов, заместитель директора Центра маркетинга и продаж ЗАО «Компания „ИнтерТраст“», считает: «Лучше ориентироваться на децентрализованное построение корпоративной системы документооборота, когда пользователи каждого предприятия или удаленной площадки (офис) работают на своих локальных серверах, а не с центральными серверами всей организации. Такой подход, затратный с точки зрения поддержки этих серверов, более надежен и не приводит к полной остановке работы СЭД на предприятии вследствие различных нарушений в каналах связи с центром.

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

При выборе системы Рашид Мухарлямов, директор направления ECM (документооборот) TerraLink, советует с самого начала выяснить:

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

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

Еще одной рекомендацией при выборе системы является четкое формулирование целей, которые ставятся перед системой. В противном случае „на выходе“ можно получить безжизненный, никому не нужный продукт. Одновременно с определением целей необходимо выделить круг поставщиков, которые на практике достигали этих целей, и по возможности посетить те предприятия, на которых сходные цели были достигнуты».

Пилот прокладывает путь

Пилотный проект — наиболее ответственная стадия, критическая с точки зрения успешной реализации проекта в целом. В ее рамках решаются такие задачи, как:

•  замена унаследованных журналов регистрации документов полнофункциональными рабочими местами документоведов организации; 
• адаптация профильных сотрудников к новой программной среде, новым правилам организации деловых процессов; 
• регистрация и контроль исполнения документов в стенах канцелярии и секретариатов подразделений; 
• повышение уровня контроля над исполнением документов и решений руководства предприятия; 
• построение отчетов по исполнительской дисциплине.

  Многие компании, начиная проект внедрения распределенной СЭД и желая снизить риски, сначала реализуют пилотный проект на базе одного офиса, чтобы в дальнейшем развернуть решение на всю компанию. Такой здравый подход позволяет минимизировать риски и ошибки внедрения на последующих стадиях. «Однако к проектированию пилотных систем следует подойти особенно внимательно: многие бизнес-процессы и механизмы, реализующие технические требования одного локального офиса, будут заведомо проще и дешевле, чем внедрение распределенного решения, — отмечает Рашид Мухарлямов. — Важно избежать соблазна сделать упрощенную систему, которая будет реализовывать требования локального офиса, но окажется не готовой к развертыванию в распределенной среде». «Мы рекомендуем сначала внедрить систему в корпоративном центре, отладить все процессы, затем распространить решение на несколько наиболее управляемых региональных площадок, отладить схему регионального взаимодействия, разработать набор документации и инструментарий для внедрения во всех офисах территориально-распределенной организации и лишь затем тиражировать решение на остальные территориальные подразделения. Начинать с центрального офиса лучше потому, что все наиболее значимые бизнес-процессы реализуются с участием управляющей компании», — говорит Андрей Гриб, руководитель Центра компетенции «Электронный документооборот и Lotus-приложения» компании «Аплана».

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

На стадии пилотного проекта организация стремится получить ответ на вопрос: подходит ли выбранная платформа для создания СЭД вообще и распределенной СЭД в частности. Поэтому стремление к максимальной адаптации системы к задачам организации иногда приводит к созданию уникальной кастомизированной версии. «Особенно это требование присуще госструктурам, которые строят свою деятельность в соответствии с ведомственными регламентами, — рассказывает Александр Московой, начальник аналитического отдела департамента систем электронного документооборота „АйТи“. — Технологических проблем с кастомизацией практически не существует. Но, заказывая существенные доработки, заказчику надо помнить: кастомизированному решению потребуется индивидуальное управление конфигурациями, контроль проектной документации, управления изменениями. Кастомизация может существенно увеличить сроки проекта. Обновление версий тоже будет происходить с некоторой задержкой, поскольку потребуется дополнительная работа разработчика по внесению изменений в кастомизированный продукт. Стоимость поддержки кастомизированной версии у вендора будет всегда выше, поскольку он должен обеспечивать уникальное сопровождение уникального решения».

Особенность внедрения СЭД в госструктурах — организация проектных работ по ГОСТам 34-й серии, которые подробно регламентируют стадии создания систем, описывают требования к составу работ и отчетных документов. «Но ГОСТы не являются всеобъемлющими, в них, например, не предусматривается устав проекта. Поэтому в крупных проектах параллельно применяются классические методики PMI», — отмечает Игорь Илюхин.

Система выходит в тираж

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

• развертывание рабочих мест СЭД на ограниченном участке в центральном аппарате организации в рамках пилотного проекта; 
• подключение к системе руководителей и функциональных сотрудников центрального аппарата организации с целью организации электронного документооборота, коллективной подготовки и согласования документов; 
• развертывание рабочих мест системы в региональных филиалах.

  Типичная последовательность функционального масштабирования:

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

  Выбор варианта тиражирования обусловлен бюджетными возможностями заказчика, планами по организации поддержки системы и масштабов проекта, степенью унифицированности затрагиваемых бизнес-процессов в территориально разнесенных офисах и их готовностью воспринимать типовое, тиражируемое ПО. Иногда исполнитель целиком выполняет все проектные работы «под ключ», вплоть до оказания услуг по инсталляции системы на рабочих местах и обучения региональных пользователей. В других проектах исполнитель осуществляет только шеф-контроль над ходом проектных работ, которые заказчик выполняет своими силами. Если заказчик предполагает осуществлять поддержку системы силами своих специалистов, самостоятельное внедрение даст возможность специалистам заказчика уже в ходе проекта приобрести необходимые знания и опыт. «Порой заказчики распределяют масштабный проект по разным субподрядчикам, — рассказывает Денис Красавин, директор департамента систем электронного документооборота „АйТи“. — Это самый худший вариант. Когда в проекте работает много разных команд, с разным объемом компетенций и опыта, проект, как правило, выходит за рамки запланированных сроков, и качество его снижается. Оптимальный вариант реализации масштабного проекта — комбинированный, когда 80% работ осуществляет исполнитель с высокой экспертизой, а 20% работ выполняется заказчиком. Это обеспечивает передачу знаний от исполнителя к заказчику и поддерживает качество проекта на должном уровне».

Приемы экономии

На оптимизацию стоимости проекта влияют два фактора: правильный выбор жизненного цикла и наличие регламентов. За счет чего можно уменьшить время и стоимость внедрения СЭД в территориально-распределенной организации на этапах пилотного проекта и тиражирования?

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

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

  На стадии пилотного проекта сокращение затрат достигается за счет экономии на второстепенных функциях. «Целью пилотного проекта не является получение полностью функционирующего промышленного решения, — подчеркивает Рашид Мухарлямов. — Именно поэтому важно правильно выбрать точку приложения пилотного проекта — такой набор бизнес-процессов и организационных подразделений, который сможет в деле проверить необходимые для распределенного решения функции».

Для уменьшения затрат на этапе тиражирования г-н Мухарлямов советует заранее заложить в решение функции, являющиеся ключевыми для распределенного решения. Кроме того, на стоимость проекта влияют:

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

  «Уменьшения времени и стоимости внедрения можно достичь за счет предустановки системы на оборудование, которое будет внедрено в регионах», — говорит Александр Московой.

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

В качестве альтернативного варианта можно воспользоваться услугами организации, которая является поставщиком и внедренцем решений. Такие организации могут предоставить своего руководителя проекта. Но здесь есть тонкий психологический нюанс. Между заказчиком и исполнителем не всегда возникает доверие высокого уровня, поэтому во избежание конфликтов лучше приглашать стороннего руководителя проекта».

Душа компании

Как правило, одно из важных мест в СЭД занимает специальный модуль, отображающий структуру организации. Это не просто справочник, а целая система управления ролями субъектов документооборота. СЭД присуща интеграционная функция связи приложений в рамках сквозных бизнес-процессов.

Интеграция с ERP-системой нацелена в основном на поддержку договорной работы: все финансовые факторы учитываются и контролируются ERP, а контроль согласований договоров возлагается на СЭД. «Интеграция с перенесением из ERP в СЭД ряда процессов позволяет сэкономить на лицензиях ERP, поскольку стоимость последних намного выше, чем лицензий СЭД», — отмечает Андрей Гриб. В последнее время наблюдается интересная тенденция, которая становится все более распространенной. Многие компании с низким уровнем ИТ-развития, стремящиеся совершить прорыв в данной сфере, внедряют сначала СЭД, а затем реализуют в ней некоторые функции ERP. Причем делается это осознанно — таким образом быстро и без больших затрат создается и шлифуется прототип ERP, наличие которого позволяет в дальнейшем снизить стоимость проекта по внедрению ERP.

Интеграция СЭД с системами управления персоналом обычно реализуется на уровне справочников. CRM интегрируется с СЭД для отслеживания истории взаимоотношений с контрагентами и сокращения времени на согласование совместных документов. Еще одна точка интеграции СЭД с внешними приложениями — корпоративный портал. Приказы и распоряжения, подготовленные в СЭД, автоматически публикуются на корпоративном портале. И, наконец, интеграция с системой Service Desk помогает сотрудникам службы поддержки согласовывать решения, необходимые для выполнения заявок.

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

Источник: http://www.cio-world.ru, http://www.doc-online.ru