Не повторяйте этих ошибок: как правильно организовать внедрение СЭД

Не спрашивать мнения конечных пользователей

Невовлечение пользователей – наиболее частое упущение бизнеса еще на этапе формирования технических требований.

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

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

Чтобы такого не происходило, важно, чтобы в проектную группу входили конечные пользователи (5-6 человек) и участвовали в тестировании на каждом этапе проекта. Эти люди должны не только детально описать свои потребности, но и в целом понять, какую пользу бизнесу и лично им принесет система, какие бизнес-процессы она оптимизирует. А также договариваться между собой, чтобы постановка задачи не превращалась в бесконечные споры.

Не назначить продукт-оунера, или ответственного за систему

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

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

Поэтому выбирайте подходящего продукт-оунера, трезво оценивая перспективы и объем нагрузки.

Не разъяснить ценность системы для пользователей

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

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

Не учитывать менталитет пользователей

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

Когда один наш клиент внедрял СЭД в своем офисе в Европе, оказалось, что уровень автоматизации и ИТ-грамотности персонала в этой стране совсем другой. Сотрудники не понимали очевидных для российских коллег вещей, задавали неожиданные вопросы на обучении. Например, они не понимали, что делать с информационными сообщениями с сайтов, где просто нужно нажать кнопку «Ок», и звонили каждый раз в техподдержку. Если бы руководство компании учла этот момент раньше, смогло бы сразу организовать расширенный курс обучения работе с системой или создать интерактивного помощника – и проблемы бы не возникло.

Экономить на аппаратных ресурсах

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

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

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

Не предусмотреть первую линию техподдержки

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

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

Резюмирую: что обязательно нужно сделать при внедрении СЭД.

1) Тщательно опросить конечных пользователей, чтобы понять их потребности и пожелания.

2) Выбрать владельца продукта – ответственного лидера, имеющего достаточно времени и мотивации для запуска и развития системы.

3) Заранее объяснить пользователям, какую выгоду от работы с СЭД они получат, заинтересовать их нестандартными способами. Сотрудничать с «агентами влияния», которые будут доносить до остальных позитивную информацию о системе.

4) Учесть социальные, профессиональные, культурные, национальные особенности пользователей системы.

5) Не экономить на аппаратных ресурсах, выполнять рекомендации вендора.

6) Заранее определиться с первой линией техподдержки пользователей, обладающей достаточной квалификацией.

При выполнении этих рекомендаций ваше внедрение СЭД должно пройти без всех вышеперечисленных проблем!