Наверх

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 4

Здорово, когда получается выстроить процесс управления изменениями на практике. Тем более, что сделано это было у реального заказчика, а не в ИТ-компании, многие из которых на процессе управления изменениями "собаку съели". 

Увидела регулярное проведение мониторинга количества внедренных изменений. Да, это важно для оценки эффективности работы команды аналитиков/разработчиков. Но ведь и бизнесу хочется оценить "выхлоп" от модификаций системы. Если до внедрения изменений аналитиком явно проводился анализ в виде "добавление дополнительной кнопки позволит половине пользователей тратить на полчаса меньше рабочего времени в день", то хотелось бы узнать, проводилась ли явная оценка эффективности использования таких "дополнительных кнопок" после внедрения? Т.е. когда планировали снизить временные затраты на полчаса, а по факту снизили всего на 5 минут или, наоборот, на целый час?

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

Суть методики оценки эффективности - это уже тема для отдельной статьи.

Хотелось убедиться, что оценка эффективности проводится. Убедилась, спасибо за ответ на комментарий! И да, я согласна, тема обширная, в двух словах не опишешь, поэтому с нетерпением будем ждать следующую статью!

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

Чтобы прокомментировать, или зарегистрируйтесь