••• Риски при внедрении системы электронного документооборота

Андрей СУКАЧ

Ключевые работники заказчика, участвующие в проекте, не могут уделять ему достаточно времени

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

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

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

Частое изменение целей и задач проекта

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

Большой объем нерегулируемых пожеланий от пользователей

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

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

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

Впрочем, описания и требования к будущим интерфейсам системы тоже могут иметь место, однако чаще всего разработка такой индивидуальной СЭД предполагает разработку с нуля под строгие задачи заказчика. Также она существенно дороже внедрения коробочной версии (как без доработки, так и с частично подгонкой под нужды конкретной организации).