Эта статья для тех, кто хоть раз организовывал переезд на новое ПО на работе. И не важно, что это было — Notion в стартапе, Jira для разработки или пачка отдельных SaaS-систем.

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

На правах специалиста с десятилетним стажем внедрения B2B-систем разного формата, а также продуктового (UI/UX) дизайнера, я постараюсь сформулировать боли общего процесса переезда и частые ошибки. Расскажу, чего нельзя избежать, а что можно сделать лучше. 

Привет, меня зовут Тимонов Максим, я дизайн-директор. Разрабатывал в роли продуктового дизайнера и лида как проекты с нуля, так и кастомизацию готовых продуктов или целиком обёртки к ним. Сейчас я выступаю в роли дизайн-директора BPM-системы «Первая Форма». Мы делаем low-code конструктор для настройки бизнес-процессов любой сложности.

А теперь подробнее о том, что это значит.

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

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

Итак, вот что случается через раз во время первой встречи с клиентом. К вендору приходит IT-директор или менеджер, отвечающий за закупку ПО. Никто из них не является конечным пользователем системы. В последний раз мы обсуждали процессы для продюсеров, ко мне пришёл менеджер по внедрению и два c-level менеджера из других отделов. 

Мы обсуждаем требования — обычно в этот момент у рабочей группы уже есть некоторые ожидания, сформированные на базе своего или чужого опыта. Но мнение конечных пользователей всё ещё игнорируется.

Затем мы настраиваем систему, проходим ПМИ, запускаем пользователей и — какая неожиданность — им всё не нравится. А что случилось?

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

Вот небольшой список ям, куда падает переезд на новое ПО. Дальше в статье я подробно их раскрою.

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

1. Заказчик упёрся в формальные требования.
   Если клиент настаивает на «правильно ВОТ ТАК» и не хочет вникать в логику системы, исполнитель рано или поздно сдастся и закроет требования костылями. Но опыт конечных пользователей по итогу будет такой себе.

2. Диалог идёт на птичьих разных языках.
   В каждой системе свои понятия, и важно сверять термины на берегу, чтобы не путать заказчика и исполнителя. В «Первой Форме», например, подписи — это конкретно подпись к задаче или цифровая подпись к файлу. А в другом продукте, с которого к нам переходили, так назывался весь процесс согласования договоров, то есть весь бизнес-процесс задачи.

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

4. Уход в когнитивные искажения команды заказчика.
   Каждый же хоть раз слышал «Всё фигня, нам не нравится, мы привыкли иначе». Выходить из этого сообщения можно через метрики, user story и референс-примеры. Прямое обсуждение в формате «А нам нравится» порождает только конфликты.

5. Оценка опыта за сотрудников. Фраза «Мне не понятно, а значит, и сотрудники не смогут разобраться» — субъективное мнение с когнитивным искажением-обобщением. В такие моменты мы обычно предлагаем попросить 10 сотрудников оценить удобство участка системы по 10-балльной шкале (по метрикам CES/CSI). В среднем выходит 7-9 баллов, и руководитель рабочей группы соглашается.

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

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

Из этого следует: переезд на новое ПО всё равно будет трудным. Что можно сделать — это максимально учесть предыдущий опыт работы. 

Если на этапе внедрения все общение между командой вендора и принимающей стороной сводится к неконструктивным жалобам, эскалациям и выпадам вроде «Вы нас не слышите», охладить дискуссии можно с помощью следующих UX-метрик:

• CES (Customer Efforts Score) — индекс усилий, которые нужно приложить, чтобы решить задачу в системе.

• CSI (Customer Satisfaction Index) — индекс удовлетворённости на конкретном участке интерфейса.

• CSAT (Customer Satisfaction Score) — индекс удовлетворённости всей системой.

О том, как их посчитать, уже исчерпывающе написали здесь.

Поэтому чем ближе новый опыт к предыдущему, тем ниже когнитивная нагрузка и проще переезд на новое ПО.

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

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

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

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

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

Важность этого я обосновал выше. Пример — сотрудники работали задачами в Outlook, где в одной части экрана список писем, а в другой содержимое задачи. 

Здесь играет не только привычка, но и удачная компоновка деталей интерфейса для конкретной деятельности — для потоковой обработки действительно удобнее открывать задачи в формате Outlook. Модальные окна перекрывали бы поля таблицы и отнимали время на скрыть/открыть.

Второй пример — команда работала по Agile и вела работу в Trello. Для них удобнее открывать задачи из Kanban в модальном окне, чтобы видеть только саму задачу, без других мешающих элементов. То есть наоборот — визуальная изоляция информации ценится больше.

Требования по нагруженности и плотности информации в интерфейсе сильно зависят от роли и компетенций сотрудника. Вот примерная формула:

3. MobileFirst 

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

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

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

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

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

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

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

Цель сотрудников — выполнять свою работу и закрывать KPI. Соберите их привычные практики и передайте вендору в сыром формате интервью или в виде уже обработанных выводов. Сформируйте тестовую группу сотрудников, к которой можно регулярно обращаться. Это значительно увеличит точность проектирования.

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

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

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

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

Обычно тиражированием системы в компании занимаются рабочая группа. Это их задача — показать пример работы с системой 

Но для лучшего результата стоит искать в компании тех, кто реально готов использовать новое решение, и собирать их отзывы о системе. Желательно, если это будут новички, которые не успели словить обобщение «Раньше было лучше». Они не воспримут переезд на новое ПО в штыки.

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

За новаторами подтянется раннее большинство, а тренинги помогут растолкать «отстающих» и погрузить их в инструменты. И начать выстраивать новые нейронные связи и привычки.

Вместо итога

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

С корпоративными системами — также. Сотрудники учатся пользоваться новыми инструментами, выстраивают новые договорённости и при этом пытаются сохранять эффективность в условиях стресса. И если не уделить внимание их потребностям и не помочь во всём разобраться, случится истерика.

Буду ждать ваши комментарии, вопросы и истории внедрений!