Первая Форма — полезные статьи и обновления системы

Почему переезд на новое ПО — такая боль для сотрудников. С чем смириться и что можно улучшить

Эта статья для тех, кто хоть раз организовывал переезд на#nbsp;новое#nbsp;ПО на#nbsp;работе. И#nbsp;не#nbsp;важно, что это было#nbsp;— Notion в#nbsp;стартапе, Jira для разработки или пачка отдельных SaaS-систем.
В#nbsp;процессе жизни и#nbsp;роста любой компании приходится перетасовывать, объединять, менять системы, на#nbsp;которых уже сложились процессы команд, и#nbsp;это всегда неприятно.
На#nbsp;правах специалиста с#nbsp;десятилетним стажем внедрения B2B-систем разного формата, а#nbsp;также продуктового (UI/UX) дизайнера, я#nbsp;постараюсь сформулировать боли общего процесса переезда и#nbsp;частые ошибки. Расскажу, чего нельзя избежать, а#nbsp;что можно сделать лучше.

Содержание

Как усложнить переезд на#nbsp;новое#nbsp;ПО ещё на#nbsp;старте проекта
________________________________________________________________________________
Привет, меня зовут Тимонов Максим, я#nbsp;дизайн-директор. Разрабатывал в#nbsp;роли продуктового дизайнера и#nbsp;лида как проекты с#nbsp;нуля, так и#nbsp;кастомизацию готовых продуктов или целиком обёртки к#nbsp;ним. Сейчас я#nbsp;выступаю в#nbsp;роли дизайн-директора BPM-системы «Первая Форма». Мы#nbsp;делаем low-code конструктор для настройки бизнес-процессов любой сложности.
Одной строкой#nbsp;— ОЧЕНЬ краткое содержание статьи:

Лучший способ усложнить переезд на#nbsp;новое ПО#nbsp;— неправильно выстроить команду внедрения и#nbsp;процесс сбора требований. Работать стоит не#nbsp;по#nbsp;водопаду, а#nbsp;по#nbsp;Agile с#nbsp;периодическими CustDev с#nbsp;конечными пользователями.
А теперь подробнее о том, что это значит.

Как усложнить переезд на новое ПО ещё на старте проекта

Я#nbsp;рассмотрю ситуацию, при которой вы#nbsp;уже выбрали решение и#nbsp;пришли за#nbsp;ним к#nbsp;вендору или интегратору. Сам поиск идеального ПО#nbsp;— это долгий и#nbsp;сложный процесс, о#nbsp;котором нужна отдельная статья.
Итак, вот что случается через раз во#nbsp;время первой встречи с#nbsp;клиентом. К#nbsp;вендору приходит IT-директор или менеджер, отвечающий за#nbsp;закупку#nbsp;ПО. Никто из#nbsp;них не#nbsp;является конечным пользователем системы. В#nbsp;последний раз мы#nbsp;обсуждали процессы для продюсеров, ко#nbsp;мне пришёл менеджер по#nbsp;внедрению и#nbsp;два c-level менеджера из#nbsp;других отделов.
Мы#nbsp;обсуждаем требования#nbsp;— обычно в#nbsp;этот момент у#nbsp;рабочей группы уже есть некоторые ожидания, сформированные на#nbsp;базе своего или чужого опыта. Но#nbsp;мнение конечных пользователей всё ещё игнорируется.
Затем мы#nbsp;настраиваем систему, проходим ПМИ, запускаем пользователей и#nbsp;— какая неожиданность#nbsp;— им#nbsp;всё не#nbsp;нравится. А#nbsp;что случилось?

5 частых проблем рабочей группы

Вот небольшой список ям, куда падает переезд на#nbsp;новое#nbsp;ПО. Дальше в#nbsp;статье я#nbsp;подробно их#nbsp;раскрою.
В#nbsp;этих примерах заказчик#nbsp;— это любой менеджер, диктующий условия, которые для него критически важно соблюсти при настройке конкретного процесса.
  • Заказчик упёрся в#nbsp;формальные требования. Если клиент настаивает на#nbsp;«правильно ВОТ ТАК» и#nbsp;не#nbsp;хочет вникать в#nbsp;логику системы, исполнитель рано или поздно сдастся и#nbsp;закроет требования костылями. Но#nbsp;опыт конечных пользователей по#nbsp;итогу будет такой себе.
  • Диалог идёт на птичьих разных языках. В#nbsp;каждой системе свои понятия, и#nbsp;важно сверять термины на#nbsp;берегу, чтобы не#nbsp;путать заказчика и#nbsp;исполнителя. В «Первой Форме», например, подписи#nbsp;— это конкретно подпись к#nbsp;задаче или цифровая подпись к#nbsp;файлу. А#nbsp;в#nbsp;другом продукте, с#nbsp;которого к#nbsp;нам переходили, так назывался весь процесс согласования договоров, то#nbsp;есть весь бизнес-процесс задачи.
  • Заказчик навалил «ненужных» требований. Начинать надо с#nbsp;малого, вроде#nbsp;бы это очевидно. Но#nbsp;некоторые сразу рисуют в#nbsp;требованиях сложные условия, множество статусов и#nbsp;автоматизации для всех случаев жизни. При этом каждое новое условие умножает время и#nbsp;стоимость реализации, и#nbsp;это откладывает получение ценности здесь и#nbsp;сейчас.
  • Уход в когнитивные искажения команды заказчика. Каждый#nbsp;же хоть раз слышал «Всё фигня, нам не#nbsp;нравится, мы#nbsp;привыкли иначе». Выходить из#nbsp;этого сообщения можно через метрики, user story и#nbsp;референс-примеры. Прямое обсуждение в#nbsp;формате «А#nbsp;нам нравится» порождает только конфликты.
  • Оценка опыта за#nbsp;сотрудников. Фраза «Мне не#nbsp;понятно, а#nbsp;значит, и#nbsp;сотрудники не#nbsp;смогут разобраться»#nbsp;— субъективное мнение с#nbsp;когнитивным искажением-обобщением. В#nbsp;такие моменты мы#nbsp;обычно предлагаем попросить 10 сотрудников оценить удобство участка системы по#nbsp;10-балльной шкале (по#nbsp;метрикам CES/CSI). В#nbsp;среднем выходит 7−9 баллов, и#nbsp;руководитель рабочей группы соглашается.
Мы#nbsp;знаем, как облегчить переезд на#nbsp;новое#nbsp;ПО
Отправьте заявку, и#nbsp;мы#nbsp;рассмотрим задачи вашей компании на#nbsp;демо-встрече
Отправить заявку
{$co}

Но почему так тяжко привыкнуть к новому? Проблема в продукте?

Помимо того, что в#nbsp;B2B конечных пользователей обычно забывают спросить, что им#nbsp;нужно, дело ещё в#nbsp;работе мозга. Сила привычки в#nbsp;рутинном процессе значительно упрощает выполнение задачи. А#nbsp;вот чтобы выстроить новые нейронные связи у#nbsp;взрослых людей, придётся напрячься.
Из#nbsp;этого следует: переезд на#nbsp;новое#nbsp;ПО всё равно будет трудным. Что можно сделать#nbsp;— это максимально учесть предыдущий опыт работы.
Если на#nbsp;этапе внедрения все общение между командой вендора и#nbsp;принимающей стороной сводится к#nbsp;неконструктивным жалобам, эскалациям и#nbsp;выпадам вроде «Вы#nbsp;нас не#nbsp;слышите», охладить дискуссии можно с#nbsp;помощью следующих UX-метрик:
  • CES (Customer Efforts Score)#nbsp;— индекс усилий, которые нужно приложить, чтобы решить задачу в#nbsp;системе.
  • CSI (Customer Satisfaction Index)#nbsp;— индекс удовлетворённости на#nbsp;конкретном участке интерфейса.
  • CSAT (Customer Satisfaction Score)#nbsp;— индекс удовлетворённости всей системой.
О#nbsp;том, как их#nbsp;посчитать, уже исчерпывающе написали здесь.
Простой пример: за#nbsp;годы работы команда усвоила, что приоритетные задачи начальник пишет в#nbsp;письме с#nbsp;темой «Заняться», а#nbsp;утверждает фразой «Выглядит неплохо».

Если мы#nbsp;переходим в#nbsp;новую систему и#nbsp;отказываемся от#nbsp;почты, процесс ломается. Да, в#nbsp;новом решении могут быть приоритеты, статусы и#nbsp;возможность принять работу подписью. Но#nbsp;это всё ещё абсолютно новый опыт для всех участников процесса, и#nbsp;в#nbsp;таком случае трава будет зеленее в#nbsp;почте.

А «больнее» всего будет руководителю. У#nbsp;него нет ни#nbsp;времени, ни#nbsp;сил привыкать к#nbsp;новым названиям, кнопкам и#nbsp;этапам. И#nbsp;если не#nbsp;учесть его потребности, может возникнуть конфликт с#nbsp;идеологами цифровизации.
Поэтому чем ближе новый опыт к предыдущему, тем ниже когнитивная нагрузка и проще переезд на новое ПО.

Как вендор или интегратор может улучшить переезд на новое ПО

Итак, что команда внедрения может и#nbsp;должна взять на#nbsp;себя.

Собрать требования рабочей группы

Мы#nbsp;должны как сформировать список всех базовых user story, так и#nbsp;уточнить технические критерии. Без первого мы#nbsp;не#nbsp;сможем точно понять, как будет работать функция и#nbsp;как она должна выглядеть в#nbsp;интерфейсе, а#nbsp;без второго#nbsp;— внести критически важные поля и#nbsp;настройки. Дальше я#nbsp;приведу пример такой ситуации.

Настроить интерфейсы и процессы, стараясь учесть прошлый опыт, если он был

Важность этого я#nbsp;обосновал выше. Пример#nbsp;— сотрудники работали задачами в#nbsp;Outlook, где в#nbsp;одной части экрана список писем, а#nbsp;в#nbsp;другой содержимое задачи.
Здесь играет не#nbsp;только привычка, но#nbsp;и#nbsp;удачная компоновка деталей интерфейса для конкретной деятельности#nbsp;— для потоковой обработки действительно удобнее открывать задачи в#nbsp;формате Outlook. Модальные окна перекрывали#nbsp;бы поля таблицы и#nbsp;отнимали время на#nbsp;скрыть/открыть.
Второй пример#nbsp;— команда работала по#nbsp;Agile и#nbsp;вела работу в#nbsp;Trello. Для них удобнее открывать задачи из#nbsp;Kanban в#nbsp;модальном окне, чтобы видеть только саму задачу, без других мешающих элементов. То#nbsp;есть наоборот#nbsp;— визуальная изоляция информации ценится больше.
Требования по#nbsp;нагруженности и#nbsp;плотности информации в#nbsp;интерфейсе сильно зависят от#nbsp;роли и#nbsp;компетенций сотрудника. Вот примерная формула:
Чем проще роль сотрудника, тем быстрее он#nbsp;должен привыкнуть к#nbsp;системе и#nbsp;начать полноценно в#nbsp;ней работать. Для этого интерфейс должен быть максимально привычным, понятным и#nbsp;линейным, а#nbsp;его освоение#nbsp;— не#nbsp;требовать длинных дорогих курсов обучения.

И#nbsp;наоборот#nbsp;— чем сложнее должность сотрудника, тем больше данных и#nbsp;манипуляций с#nbsp;ними он#nbsp;производит. И#nbsp;здесь уже можно дать время на#nbsp;погружение, но#nbsp;предусмотреть ролевой доступ с#nbsp;разграничением информации. И, конечно, заложить процесс онбординга для работы с#nbsp;процессом.

MobileFirst

Ещё на#nbsp;этапе выбора продукта вам стоит продумать, есть#nbsp;ли в#nbsp;планах использовать систему не#nbsp;с#nbsp;десктопа. При этом стоит учесть, какие это будут устройства, для каких ролей и#nbsp;какой части процесса. Тогда мы#nbsp;можем реализовать функции для тех, кто часто работает вне офиса. Например:
Руководители. Защищённое корпоративное приложение позволяет им#nbsp;получать автоматизированные уведомления о#nbsp;проблемах и#nbsp;вопросах вне офиса. Например, пока коммерческий директор сидит на#nbsp;переговорах без доступа к#nbsp;ноутбуку, новички-сейлы могут слить продажу.

Сотрудники на#nbsp;местах и#nbsp;выездах: курьеры, проверяющие, работники складов. Для одного клиента мы#nbsp;настроили считывание штрихкодов на#nbsp;документах через приложение. Работники архива получают короба с#nbsp;документами на#nbsp;хранение, сканируют штрихкод и#nbsp;через систему могут контролировать сроки. На#nbsp;десктопе#nbsp;же функции считывания нет, потому что там она не#nbsp;нужна.

Офисные сотрудники. Через мобильное корпоративное приложение они могут оформить больничный, внести в#nbsp;систему результаты выездной работы, присутствовать на#nbsp;планёрке из#nbsp;пробки.
Мобильное приложение «Первой Формы» полностью повторяет функции и#nbsp;возможности десктопной версии. Это позволяет выполнять любые задачи без ноутбука
Узнать больше
{$co}

Брендирование системы

Это ещё один слой, влияющий на#nbsp;удовлетворённость от#nbsp;работы в#nbsp;компании и#nbsp;HR-бренд. Вендор может задать цвета, шрифты, логотип, иконки и#nbsp;иллюстрации на#nbsp;определённых экранах. Отдельная опция#nbsp;— бренд-приложение в#nbsp;сторах, у#nbsp;которого будет свой цикл обновлений и#nbsp;оформление.

Как заказчик может упростить переезд на новое ПО

От вендора зависит не всё. Теперь посмотрим, что можете сделать вы.

Спрашивать мнение сотрудников

В#nbsp;основном в#nbsp;компаниях нет Agile-коучей и#nbsp;других специалистов, которые могут регулярно анализировать и#nbsp;оптимизировать бизнес-процессы. Поэтому в#nbsp;каждом отделе и#nbsp;между ними складывается уникальный опыт рабочего взаимодействия.
Цель сотрудников#nbsp;— выполнять свою работу и#nbsp;закрывать KPI. Соберите их#nbsp;привычные практики и#nbsp;передайте вендору в#nbsp;сыром формате интервью или в#nbsp;виде уже обработанных выводов. Сформируйте тестовую группу сотрудников, к#nbsp;которой можно регулярно обращаться. Это значительно увеличит точность проектирования.
Один клиент прислал нам как образец Excel-таблицу со#nbsp;списком получателей разной документации. В#nbsp;одном столбце был код формата «ДГ#nbsp;241 206−00−2432», но#nbsp;никаких пояснений не#nbsp;было. Мы#nbsp;настроили тестовый процесс по#nbsp;первичным требованиям с#nbsp;полем для кода, запустили сотрудников. Они остались недовольны.

Оказалось, что цифры «00» в#nbsp;середине этого кода обозначали группу топ-руководителей. В#nbsp;Excel были настроены фильтры по#nbsp;набору групп и#nbsp;условное форматирование цветом, которое в#nbsp;требованиях не#nbsp;описали. Никто кроме исполнителей не#nbsp;знал об#nbsp;этой условности, но#nbsp;на#nbsp;ней был завязан целый бизнес.

Сначала оптимизируйте, потом — автоматизируйте

Как я#nbsp;упоминал выше, при избыточных критериях к#nbsp;новому процессу легко увязнуть в#nbsp;многоэтажной настройке. 10 статусов и#nbsp;20 согласований разумны для сложного и#nbsp;рискованного проекта стройки с#nbsp;циклом в#nbsp;год-два. Но#nbsp;не#nbsp;для задач, которые должны закрываться за#nbsp;два рабочих дня.
Один наш клиент собрал пожелания к#nbsp;процессам от#nbsp;заказчика#nbsp;— HR-команды,#nbsp;— но#nbsp;не#nbsp;проанализировал критичность и#nbsp;не#nbsp;дал нам провести с#nbsp;пользователями интервью.

Так, в#nbsp;списе оказался пункт, что на#nbsp;середине онбординга в#nbsp;качестве наблюдателей подтягивались гендиректор и#nbsp;вся группа HRBP. Им#nbsp;начали приходить все типы уведомлений о#nbsp;движении задач и#nbsp;их#nbsp;изменениях.

Уведомления превратились из#nbsp;полезного инструмента в#nbsp;непонятную кашу с#nbsp;логами. Действительно важные сообщения в#nbsp;ней было не#nbsp;найти, система стала «плохой и#nbsp;неудобной». Исправить ситуацию помогла только эскалация проблемы и#nbsp;снятие требований от#nbsp;первого менеджера.
Вендор может автоматизировать любые мелочи и#nbsp;условия, но#nbsp;надо#nbsp;ли это вам? Избыток контроля, информации или запроса действий вызовут путаницу. Поэтому сначала стоит привести требования в#nbsp;порядок и#nbsp;отказаться от#nbsp;условий, мало влияющих на#nbsp;конечный результат.

Ищите в компании сотрудников, заинтересованных в новом решении

Обычно тиражированием системы в#nbsp;компании занимаются рабочая группа. Это их#nbsp;задача#nbsp;— показать пример работы с#nbsp;системой.
Но#nbsp;для лучшего результата стоит искать в#nbsp;компании тех, кто реально готов использовать новое решение, и#nbsp;собирать их#nbsp;отзывы о#nbsp;системе. Желательно, если это будут новички, которые не#nbsp;успели словить обобщение «Раньше было лучше». Они не#nbsp;воспримут переезд на#nbsp;новое#nbsp;ПО в#nbsp;штыки.
Этот график показывает распространение инновации во#nbsp;времени. В#nbsp;начале в#nbsp;команде будет минимум сотрудников, которые без проблем захотят пользоваться решением, и#nbsp;именно их#nbsp;нужно поддержать. Идеально, если среди них будет лидер мнений, чей опыт может перекрыть предвзятость.
За#nbsp;новаторами подтянется раннее большинство, а#nbsp;тренинги помогут растолкать «отстающих» и#nbsp;погрузить их#nbsp;в#nbsp;инструменты. И#nbsp;начать выстраивать новые нейронные связи и#nbsp;привычки.

Вместо итога

Переезд на#nbsp;новое#nbsp;ПО в#nbsp;B2B похож на#nbsp;смену квартиры, где вся команда#nbsp;— это дети. Их#nbsp;мнение#nbsp;— не#nbsp;ключевое на#nbsp;первых этапах, но#nbsp;им#nbsp;нужно привыкать к#nbsp;новому окружению. И#nbsp;если это вызывает проблемы, ситуация может эскалироваться до#nbsp;блокировки работы отдела и#nbsp;конфликта с#nbsp;вендором из-за «некачественного решения».
С#nbsp;корпоративными системами#nbsp;— также. Сотрудники учатся пользоваться новыми инструментами, выстраивают новые договорённости и#nbsp;при этом пытаются сохранять эффективность в#nbsp;условиях стресса. И#nbsp;если не#nbsp;уделить внимание их#nbsp;потребностям и#nbsp;не#nbsp;помочь во#nbsp;всём разобраться, случится истерика.