Николай Крыгин

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

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

Я больше десяти лет занимаюсь внедрением и сопровождением СЭД и расскажу, как завершить проект и не превратить его в долгострой.

Почему после запуска становится дороже, а не дешевле

Логика проекта внедрения простая: чем дальше, тем меньше работы. С СЭД так не выходит.

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

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

Команда работала нормально, но среда менялась быстрее, чем ее успевали проверять. На тестовом стенде сценарии проходили, а на приемке все могло не заработать в любой день. Каждый показ начинался с вопроса «а вы вернули наши настройки?». Если во время демонстрации кто-то переключал поток обмена между базами, приемку переносили на два-три дня, и так не раз. Чем дольше решение не попадает в боевую среду, тем дороже каждый следующий шаг: копится расхождение между тем, что проверили на стенде, и тем, что работает у заказчика.

Что проверять вместе с пользователями до передачи

Главная ошибка при передаче — проверять систему строго по ТЗ, а не по пути пользователя. Команда тестирует функции, а сотрудник заказчика работает по сценариям, и они часто расходятся с ТЗ.

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

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

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

Дефект, новое требование или вопрос по использованию

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

Я делю обращения на три категории, и у каждой свой критерий и свой порядок работы.

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

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

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

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

Что включить в документацию и обучение

Документацию часто готовят только для того, чтобы сдать проект. Но ее задача в другом: чтобы поддержке не приходилось объяснять одно и то же дважды. Регламент на 50 страниц с этим не справляется: его не читают ни пользователи, ни поддержка.

Исключение я видел однажды: поддержка закрывала обращения ссылкой на пункт регламента и так приучила пользователей сначала искать ответ самостоятельно. Чаще бывает наоборот. В одной компании 12-страничный регламент по настройке нового пользователя заменили чек-листом из 11 пунктов, и стажер стал справляться за 5 минут вместо 30.

Что помогает при передаче СЭД в сопровождение:

  • Пошаговые сценарии с реальными данными. Например, «как создать договор с контрагентом X на сумму Y» — с экранами и типичными ошибками на каждом шаге. На одном проекте мы сделали такие сценарии по ключевым процессам вместе с пользователями, и за первый месяц обращений по этим процессам стало вдвое меньше.
  • Описания воспроизведения дефектов. Вместе с проблемой поддержка записывает шаги, при которых она возникает. Это ускоряет исправление, а со временем из таких описаний складывается база тест-кейсов. В одном из проектов так и получилось: по старым описаниям ошибок учились новые сотрудники и принимались релизы.
  • Скринкасты на 5–7 минут. По одной операции на ролик, голосом и с реальным экраном. В одной компании ролики за год посмотрели сотни раз, а текстовую инструкцию открыли раз двадцать.
  • Чек-листы для типовых операций. Настройка пользователя, выдача прав, добавление шаблона, подключение подразделения. Одна страница, 10–15 пунктов.
  • Парные сессии и ротация. Неделя работы рядом с коллегой передает знания быстрее любого регламента. В нашей команде специалисты раз в месяц-два менялись типами документов при тестировании релизов, и через полгода-год каждый знал большинство процессов.
  • Документация полезна, если ею можно воспользоваться, когда что-то сломалось. Формат стоит согласовать заранее: чек-листы, сценарии и ролики вместо мануала на десятки страниц. Если заказчику нужен формальный документ, его соберут из этих материалов позже.

Как распределить ответственность

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

Заказчик отвечает за:

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

Служба поддержки отвечает за:

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

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

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

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

Чек-лист передачи СЭД в сопровождение, который я как отправную точку и адаптирую под конкретный проект:

Перед передачей:

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

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

Сопровождение без авторов

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

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

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

Источник: