Как внедрить изменения в систему электронного документооборота и ничего не потерять?

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

Можно выделить несколько источников изменений:

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

●    оптимизация бизнес-процессов. Доработки и изменения, вносимые в текущий функционал системы;

●    решение инцидентов.

Как может быть построен процесс внесения изменений в СЭД?

1.   Анализ. Пользователи всегда генерируют пожелания к системе на уровне своего понимания проблемы. Как правило, такие пожелания невозможно реализовать «в лоб». Для того чтобы взять их в работу, необходимо провести предварительное исследование, которое позволит прояснить суть запроса.

Допустим, отдел ИТ просит убрать их из списка согласующих при рассмотрении договоров. На первый взгляд, да, для чего они там. Только часть договоров все-таки касается ИТ напрямую (поставки компьютерного оборудования) или договоры содержат условия по ИТ. Задача бизнес-аналитика на этом этапе – выяснить истинную задачу, стоящую перед пользователем.

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

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

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

●    количества пользователей, которые будут использовать новые возможности;

●    бизнес-роли затронутых изменениями сотрудников (например, более значимыми будут доработки, позволяющие руководителям быстрее принимать управленческие решения).

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

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

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

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

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

5.   Формирование блока работ на период и его реализация. Есть несколько подходов к реализации изменений. Первый из них можно описать принципом «решать проблемы по мере их поступления». Это вполне работоспособный, но слабо управляемый вариант: он не позволяет спланировать сроки реализации конкретного пожелания.

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

Управление знаниями

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

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

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

Этапы управления изменениями