9.4.Готовимся к обучению пользователей
На фазе «Разработка» начинается активная подготовка к опытной эксплуатации. А для того, чтобы начать эксплуатировать систему пользователям (путь пока еще только в опытом режиме), нужно уметь с ней работать, а для этого – пройти обучение.
Но для того чтобы пройти обучение, нужно иметь функциональность системы (и ее описание в виде руководств пользователей), а фаза разработки еще не прошла и не все готово. Получается парадокс: начинаем готовиться к обучению, когда система еще не готова.
С одной стороны, можно выделить из фазы «Разработка» все, что касается обучения и подготовки начальных данных, в отдельную фазу «Подготовка к опытной эксплуатации», но, с другой стороны, нет смысла делать эту фазу отдельной после фазы разработки. Ведь система большая и осваивать ее и готовить учебные материалы можно с самого начала (конечно, не по тем блокам, которые разрабатываются отдельно с нуля внутри фазы), а на подготовку начальных данных сотрудникам заказчика нужно время, и может получиться, что если фаза будет отделена от разработки, то часть команды исполнителя будет простаивать и ждать обратной связи от пользователей, которые еще не начали осваивать систему, а активная разработка уже завершилась. Из этого следует еще один плюс совмещения процессов разработки и обучения – это обратная связь от пользователей в процессе изучения системы на фазе разработки, которая влияет на разработку (юзабилити, понятность, ошибки, найденные самими пользователями).
Понятно, что обучение пользователей не нужно начинать с первого дня фазы разработки – этот процесс начнется по готовности функциональности к показу пользователям, но сама фаза завершится, когда пользователи пройдут обучение, аттестацию и будут готовы начать опытную эксплуатацию системы. А параллельно с началом обучения будут проходить доработки и настройки функциональности для следующих тем обучения.
Важно отметить, что поставляемая с ERP-системой документация – это не инструкции для конечных пользователей, нельзя просто выдать книжку или ссылку на электронную документацию ИТС и сказать: «Там все есть». Эти материалы для специалистов. Конечным пользователям нужно знать только то, что реально нужно им в работе, у них конечный набор сценариев работы в их бизнес-процессе, новые, возникающие в процессе деятельности компании ситуации и изменения бизнес-процессов требуют рассмотрения центром компетенции и закрытия их через дообучение и обновление инструкций. Поэтому инструкции пишем для конечных пользователей в процессе внедрения под бизнес-процессы компании, детализируя под их комфортное понимание и ввод в дело новых сотрудников, смену роли сотрудника и ротации между отделами. Закладываем это время в сроки и бюджет проекта.
Детализация инструкций пользователей не должна быть излишней: описывать, как нажимать кнопку OK или пользоваться формой выбора (автор видел и такие инструкции) на каждом скриншоте, конечно, не нужно, это некое неуважение к нормальным пользователям. На крайний случай (так как пользователи в компании могут быть далеки от уверенного владения ПК) нужна инструкция по работе с кнопками и мышкой в принципе как вводная для неподготовленных пользователей ПК, а для функциональности ERP-системы – нормальная (достаточная) для рабочего места инструкция по работе в системе, наложенная на бизнес-процесс компании.
Вообще ERP-система развивается по мере обновлений самим поставщиком, поэтому нужно планировать регулярное дообучение пользователей, обновление инструкций по ходу появления и внедрения в работу новых возможностей после обновления системы на новую версию. Стоит поставить это на поток: делать какие-то рассылки по корпоративной почте, например «новые возможности корпоративной ERP-системы», по факту переноса проектных доработок на рабочую базу и появления новых возможностей функциональности системы при обновлении версии самой ERP-системы. Такая визуализация и информирование об эволюции системы в компании создают хорошее к ней отношение: пользователям приятно видеть в обновлении то, что они сами заказывали ранее, что позволит им работать в системе лучше и больше сосредоточиться на самих бизнес-задачах, а не рутинных операциях.
По ходу проведения обучения и самообучения пользователей, и тем более по результатам опытной эксплуатации, становятся понятны места оптимизации «юзабилити» (англ. usability – удобство и простота использования). Банальное удобство для рутинных действий может экономить, например, 10 секунд (вроде немного), но при 100 повторах в час это будет 1000 с (16 минут), а за рабочие 8 часов экономия будет уже 2 часа! Это и есть эффект от оптимизации. Можно увеличить поток данных в бизнес-процессе компании через того же сотрудника – автоматизация бизнес-процессов в действии. За счет такой оптимизации за 4 рабочих дня сотрудник получит дополнительные 8 часов для работы (или перестанет зашиваться с ростом нагрузки при расширении бизнеса).
Такие «бантики» и доработки, вскрываемые консультантами по ходу подготовки системы к показу, проведения обучения и обратной связи от пользователей, должны рассматриваться и включаться в доработки системы (см. раздел «» в этой главе).
Как совет консультантам: если что-то в процессе тестирования начинает напрягать и становиться рутиной и есть понимание, как это сделать оптимальнее, нужно это сделать! Ведь вас это утомило за несколько часов тестирования, а пользователям с этим работать каждый день по 8 часов. Разработчики такие места склонны игнорировать и не думать о таких «бантиках» как о глобальной проблеме – нужно их в этом убедить. Система не просто должна работать корректно, она должна работать на конкретных пользователях, то есть они должны работать в системе без лишних сложностей. И мелочь для разработчика может быть очень важной опцией для пользователя. Система ценностей тут разная.
Само обучение может проходить:
- индивидуально (неэффективно при массе пользователей с одинаковыми ролями);
- занятиями в группах (логично проводить общие темы обучения в больших группах, а ролевые особенности уже в более мелких);
- комбинация подходов – вначале групповые занятия, потом индивидуальные (у пользователей разный темп усвоения информации и ритм обучения, кому-то после групповых занятий нужен будет дополнительный индивидуальный подход).
Обучение конечных пользователей проводят:
- консультанты исполнителя;
- центр компетенции заказчика (обученный предварительно специалистами исполнителя) – позволяет тиражировать знания о системе, сохраняет экспертизу внутри компании после завершения проекта.
Использование проектора и презентаций с тезисами, схемами и основными скриншотами системы позволяет фокусировать внимание на важных вещах. Наличие возможности делать практические задания (требует компьютеров у пользователей) зависит от инфраструктуры заказчика: есть в офисе дисплейный класс для проведения обучения или это только переговорные комнаты с большим экраном, тогда обучение состоит из лекций и самостоятельной работы на своем рабочем месте. В любом случае нужно организовать поддержку самостоятельной работы пользователей: быстрые ответы на вопросы (телефон, мессенджеры, корпоративный форум), а также доступ консультантов к рабочему месту пользователя или удаленное подключение к его рабочему столу.
Процент усвоенного материала и качество освоения системы зависят от формата подачи информации. Согласно исследованиям Эдгара Дейла, проводившимся в 1960–1970-х годах и позднее его последователями, человек способен усваивать только часть изучаемой информации. Наглядно это можно продемонстрировать через пирамиду обучения Дейла.
Рис. 9.4. Пирамида обучения Эдгара Дейла
Поэтому наличие скриншотов и схем в инструкциях пользователей, живая демонстрация системы в процессе обучения и, конечно, личная практика использования повышают качество обучения пользователей за счет большего объема усвоенной информации.
В принципе, обучение может проходить удаленно полностью, в формате вебинара, вопросов-ответов и подключения к рабочим столам пользователей. Но эффективность такого обучения может быть ниже очного – это происходит больше из-за психологии восприятия информации и категории/поколения пользователей. Если большинство пользователей – молодежь и привыкли к формату подачи информации в виде роликов и вебинаров, то текстовые инструкции можно заменить видеороликами. Вообще проводимые занятия полезно записывать либо готовить как видеоконтент заранее и раздавать пользователям для изучения (позволяет не отрывать сотрудников от работы массово, они изучают материалы в своем режиме). Такие записи будут хорошим подспорьем для подключения новых сотрудников (или тех, кто болел, был в отпуске), что сэкономит время и усилия консультантов на итерациях повтора обучения. Но нужно понимать, что инструкции пользователей приходится обновлять по мере изменения функциональности (меняются интерфейсы, появляются новые возможности функциональности), замена инструкций видеороликами не снимет задачу их обновления. Поэтому запись с очного (или удаленного) обучения будет актуальна только некоторое время.
Завершением обучения пользователей должна быть аттестация на готовность работы в системе по своей роли и бизнес-процессам в системе. Консультантам исполнителя нужно подготовить аттестационные задания и вопросы. Сам факт аттестации является хорошей мотивацией для приложения сотрудником заказчика должных усилий и усидчивости в освоении системы. Аттестация не должна быть формальностью, когда все проходят ее по умолчанию. Аттестация может и должна выявлять проблемы и может проходить итерациями. Результаты доводят до руководителя проекта заказчика, а он – до руководителей подразделений, там делают соответствующие выводы и мотивационные воздействия на сотрудников, вплоть до их ротации при невозможности дальше выполнять должностные обязанности с учетом автоматизации бизнес-процессов компании.
Исполнителю рекомендуется в договоре заранее прописать конечное количество «бесплатных» пересдач аттестации сотрудниками заказчика, чтобы не попадать в вечный цикл: «Ну, он уже все выучил, проверьте его еще раз». Руководитель проекта со стороны заказчика и центр компетенции заказчика тогда будут больше замотивированы в поддержке процесса обучения своими силами и аттестации пользователей специалистами исполнителя с минимумом итераций.
Некоторые сотрудники могут саботировать процесс обучения и аттестации по разным причинам: в силу природного консерватизма, опасений того, что автоматизация за счет прозрачности вскроет (закроет) возможности каких-то схем и махинаций, покажет реальную эффективность сотрудников (а не декларативно-показную). Но такая прозрачность, статистика и показатели работы персонала – это цели самой автоматизации для владельцев бизнеса. И стоящих у этих целей на пути сотрудников должен убеждать сам заказчик. Руководитель проекта со стороны заказчика должен организовать устранение таких возникающих проблем, используя соответствующие административные рычаги воздействия.
При подготовке к обучению пользователей нужно озаботиться настройкой разграничения доступа:
- Настройка прав доступа к функциональности и разграничение по записям (RLS).
- Нужно проектировать, кому что видно, что можно редактировать.
- Настройка и тесты прав доступа занимают время.
- Часто про разграничение доступа вообще забывают (даже не закладывается в бюджет).
Изучение системы пользователями должно проходить в обстановке, приближенной к «боевой» (как в будущей рабочей базе), то есть под правами доступа, какие у них будут потом. Это позволяет сразу оттестировать права доступа на реальных бизнес-процессах.
Настройка прав доступа на ранних стадиях снимает ряд вопросов вида: «А что это за кнопки/поля, когда мне ими пользоваться?» – когда под полными правами пользователь видит лишнюю для себя функциональность системы.
Нужно отметить, что скриншоты для инструкций пользователей также нужно снимать в конечном виде интерфейса для данной роли пользователей, то есть под неполными правами, иначе неминуемы обращения: «А у меня форма в системе не такая, как на картинке, у меня не все кнопки есть». Консультанты исполнителя часто мыслят категориями функциональности под полными правами и мысленно игнорируют лишнее, пользователи так не умеют, для них система новая, все поля и кнопки равнозначны, должны иметь значение и использоваться в работе.
Параллельно с обучением пользователей нужно проводить процессы подготовки начальных данных. Начальные данные, перенесенные в тестовом режиме, будут полезны при проведении обучения: пользователи будут видеть знакомые документы по знакомым номенклатурам и контрагентам. Настройки системы, даже для обучения, должны быть унаследованы от настраивавшегося на прошлых фазах прототипа системы: обучение на абстрактных демо-данных не столь эффективно, как на реальных учетных данных компании.
Когда пользователи прошли обучение и аттестованы, система успешно прошла тестирование, разработка завершена, можно переходить к следующей фазе проекта – «Опытной эксплуатации».
