Сотрудники не хотят новый софт — идти на поводу или гнуть свою линию?

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

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

Идеальная визуализация принятия нового ПО сотрудниками.Источник — Яндекс.Картинки

Зарубежные консалтеры начали бы эту статью примерно так: «Если вы предлагаете своим сотрудникам качественное программное обеспечение, которое способно улучшить их работу, оказать качественное влияние на показатели, принятие новой программы или системы произойдёт естественным образом». Но мы с вами в России, поэтому вопрос подозрительных и воинственных сотрудников весьма актуален. Естественного перехода не получится, даже с минимальным ПО типа корпоративного мессенджера или софтфона.

Сегодня в каждой компании установлен целый зоопарк ПО (мы берём общий случай, потому что в ИТ-компаниях количество софта больше вдвое или втрое, а проблемы адаптации пересекаются частично и весьма специфичны): системы управления проектами, CRM/ERP, почтовые клиенты, мессенджеры, корпоративный портал и т.д. И это не считая того, что бывают компании, в которых даже переход с браузера на браузер осуществляется всей командой без исключения (а ещё есть команды, полностью сидящие на Internet Explorer Edge). В общем случае есть несколько ситуаций, для которых может оказаться полезной наша статья:

• происходит процесс первичной автоматизации какой-то группы задач: внедряется первая CRM/ERP, открывается корпоративный портал, устанавливается система для технической поддержки и проч.;
• происходит замена одного ПО на другое по каким-то причинам: устаревание, новые требования, масштабирование, смена деятельности и т.д.;
• происходит наращивание модулей существующей системы для целей развития и роста (например, компания открыла производство и решила перейти с RegionSoft CRM Professional на RegionSoft CRM Enterprise Plus с максимальной функциональностью);
• происходит серьёзное интерфейсное и функциональное обновление ПО.

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

Итак, перед тем, как начать работать с коллективом (который уже заподозрил, что ж-ж-ж-ж неспроста, и скоро будут перемены), попробуйте понять, в чём состоят реальные причины смены ПО и согласны ли вы с тем, что перемены столь уж необходимы.

• В старой программе сложно работать: она дорогая, неудобная, нефункциональная, перестала соответствовать вашим требованиям, не подходит для вашего масштаба и т.д. Это объективная необходимость.
• Вендор перестал поддерживать систему, либо поддержка и доработка превратились в бесконечную череду согласований и вытягивания денег. Если ваши затраты значительно выросли, и в перспективе обещают увеличиться ещё — ждать нечего, нужно резать. Да, новая система тоже будет стоить денег, но в конечном итоге оптимизация обойдётся дешевле, чем такая поддержка.
• Смена ПО — прихоть одного человека или группы сотрудников. Например, CTO хочет откат и лоббирует внедрение новой, более дорогой системы, — такое бывает в больших компаниях. Другой пример: проектный менеджер ратует за смену Asana на Basecamp, потом Basecamp на Jira, сложной Jira на Wrike. Нередко единственный мотив таких миграций — показать свою бурную работу и сохранить должность. В таких случаях нужно определять степень необходимости, мотивы и обоснованность и, как правило, волевым решением отказывать в изменениях.

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

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

Принятие методом «Большого взрыва» — максимально жёсткий переход, когда вы устанавливаете точную дату и осуществляете резкую миграцию, отключая старое ПО на все 100%.

Плюсы

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

Минусы

— Успешно работает только с простым программным обеспечением: чаты, корпоративный портал, мессенджеры. Даже электронная почта уже может дать сбои, не говоря уж о системах управления проектами, CRM/ERP и прочих серьёзных системах.
— «Взрывная» миграция с крупной системы на другую неизбежно вызовет хаос.

Самое важное для такого типа перехода в новую рабочую среду — это обучение.

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

Плюсы

+ Пользователи имеют достаточно времени, чтобы привыкнуть к новому ПО, оперативно работая в старом, отыскать параллели, вникнуть в новую логику взаимодействия с интерфейсом.
+ В случае внезапных проблем сотрудники продолжают работать в старой системе.
+ Обучение пользователей менее жёсткое и в целом обходится дешевле.
+ Негативная реакция сотрудников практически отсутствует — ведь их не лишили привычного инструмента или уклада дел (если автоматизация происходит впервые).

Минусы

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

Поэтапная адаптация — самый мягкий вариант перехода на новое ПО. Переход осуществляется пофункционально, в оговоренные периоды времени и по подразделениям (например, с 1 июня мы вносим новых клиентов только в новую CRM-систему, с 20 июня ведём сделки в новой системе, до 1 августа переносим календари и дела, и к 30 сентября завершаем миграцию — это очень грубое описание, но в целом наглядное).

Плюсы

+ Организованный переход, распределённая нагрузка на администраторов и внутренних экспертов.
+ Более продуманное и глубокое обучение.
+ Нет сопротивления изменениям, потому что они происходят максимально мягко.

Минусы — примерно такие же, как у параллельного перехода.

Так что теперь, только поэтапный переход?

Логичный вопрос, согласитесь. Зачем получить какую-то лишнюю мороку, когда можно составить график и действовать по чёткому плану? На самом деле не всё так однозначно.

• Сложность программного обеспечения: если речь идёт о сложном ПО (например, CRM-системе), то больше подойдёт фазовая адаптация. Если ПО простое (мессенджер, корпоративный портал), то подойдёт модель, когда вы объявили о дате и отрубаете старое ПО в назначенный день (если повезет, сотрудники успеют вытащить всю необходимую им информацию, а если не рассчитывать на везение, то необходимо предусмотреть автоматизированный импорт необходимых данных из старой системы в новую, при наличии технической возможности).
• Степень риска для компании: чем рисковее внедрение, тем медленнее оно должно быть. С другой стороны, затягивание — тоже риск: например, вы переходите с одной CRM-системы на другую, и в период перехода вынуждены платить за обе, тем самым растут затраты и стоимость внедрения новой системы, а значит, растягивается период окупаемости.
• Численность сотрудников: большой взрыв точно не подойдёт в случае необходимости масштабирования и настройки множества пользовательских профилей. Хотя бывают случаи, когда ультра быстрое внедрение для большой компании — благо. Такой вариант может подойти для систем, которыми пользуются многие сотрудники, но при этом не могут иметь требования, поскольку не предполагается кастомизация. Но опять же, это big bang для конечных пользователей и огромная поэтапная работа для той же ИТ-службы (например, биллинг или пропускная система).
• Особенности внедрения выбранного ПО (доработка и т.д.). Иногда внедрение изначально поэтапное — со сбором требований, доработкой, обучением и т.д. Например, CRM-система внедряется всегда поступательно и если вам кто-то обещает «внедрить и настроить за 3 дня или даже 3 часа» — вспомните эту статью и обойдите такие услуги стороной: установка ≠ внедрение.

Опять же, даже зная перечисленные параметры, нельзя однозначно становиться на тот или иной путь. Оцените ваше корпоративное окружение — это поможет одновременно понять расклад сил и определить, какая модель (или сочетание некоторых их элементов) вам подойдёт.

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

• Руководители компании определяют, как в целом будет принято новое ПО. И здесь не место рекламным речам и пламенным выступлениям, — важно показать именно необходимость изменений, пронести идею о том, что это всего лишь выбор более крутого и удобного инструмента, такой же, как замена старого ноутбука. Самая большая ошибка руководства в такой ситуации — умыть руки и самоустраниться: если начальству не нужна автоматизация компании, почему она должна быть интересна сотрудникам? Будьте в процессе.
• Руководители отделов (менеджеры проектов) — промежуточное звено, которое обязательно должно участвовать во всех процессах, управлять недовольством, проявить волю и отработать каждое возражение коллег, провести качественное и глубокое обучение.
• ИТ-служба (или системные администраторы) — на первый взгляд, это ваши early birds, самые адаптируемые и адаптирующие, но… нет. Нередко, особенно в малых и средних компаниях, сисадмины выступают против каких-либо изменений (усилений) ИТ-инфраструктуры, и связано это не с какой-то технической обоснованностью, а с ленью и нежеланием работать. А кто из нас не искал путей откосить от выполнения работы? Но пусть это будет не во вред всей компании.
• Конечные пользователи, как правило, хотят работать хорошо и удобно с одной стороны и, как и любые живые люди, боятся изменений. Основная аргументация для них честная и простая: зачем внедряем/меняем, какие границы у контроля, как будет оцениваться работа, что изменится и в чём риски (кстати, риски стоит оценить всем — мы хоть и вендоры CRM-системы, но не берёмся сказать, что всё всегда проходит гладко: риски есть в любом процессе внутри бизнеса).
• «Авторитеты» внутри компании — партизаны, которые могут оказывать влияние на остальных сотрудников. Это не обязательно человек с высокой должностью или большим опытом — в случае работы с ПО «авторитетом» может оказаться продвинутый всезнайка, который, например, перечитал Хабра и начнёт всех запугивать тем, как всё станет плохо. У него может даже не быть цели порушить процесс внедрения или перехода, — просто понты и дух сопротивления, —  а сотрудники ему поверят. С такими сотрудниками нужно работать: разъяснить, расспросить, в особо тяжёлых случаях намекнуть на последствия.

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

Два важных фактора успешного преодоления «движения сопротивления».

1. Проводите обучение: вендорское и внутреннее. Убедитесь в том, что сотрудники действительно всё поняли, усвоили и вне зависимости от уровня подготовки готовы начать работать. Обязательный атрибут обучения — печатные и электронные инструкции (регламенты) и максимально полная документация по системе (уважающие себя вендоры выпускают её вместе с ПО и предоставляют бесплатно).
2. Ищите сторонников и выбирайте инфлюэнсеров. Внутренние эксперты и ранние последователи — ваша опора, которая и обучит, и развеет сомнения. Как правило, сотрудникам самим приятно помогать коллегам, вводить их в новый софт. Ваша задача — временно разгрузить их от работы либо достойно премировать за новую нагрузку.

На что нужно обратить внимание?

1. Насколько продвинуты те сотрудники, которых затронут изменения? (Условно говоря, если завтра изобретут новую бухгалтерскую программу, на дай вам бог сунуться в бухгалтерию с дамами за 50 и предложить переход с 1С — живым не выйдете).
2. Насколько сильно будут затронуты рабочие процессы? Одно дело поменять мессенджер в компании из 100 человек, другое — внедрить новую CRM-систему, на работе в которой завязаны ключевые процессы в компании (и это не только продажи, например, внедрение RegionSoft CRM в старших редакциях затрагивает и производство, и склад, и маркетинг, и топ-менеджеров, которые вместе с командой будут выстраивать автоматизированные бизнес-процессы).
3. Проведено ли обучение и на каком уровне?

Единственный логичный переход в системе корпоративного мышления

Прежде чем рассказать, какие ключевые моменты помогут вам комфортно переехать на новый софт, заострим ваше внимание на одном моменте. Есть то, что делать точно не надо — не надо давить на сотрудников и «мотивировать» их депремированием, административными и дисциплинарными взысканиями. Процесс от этого лучше не пойдёт, а вот отношение сотрудников ухудшится: раз продавливают, значит, будет контроль; раз заставляют, значит, не уважают наш интерес; раз насильно навязывают, значит, нам и нашей работе не доверяют. Поэтому всё делаем дисциплинированно, чётко, грамотно, но без давления и излишнего форсирования.

Вот всего остального может не быть, а план быть должен. Причём план корректируемый, обновляемый, чёткий и неотвратимый, при этом доступный для обсуждения и прозрачный для всех заинтересованных сотрудников. Нельзя директивно сообщать о том, что С 8 утра до 10 — подвиг, а в 16:00 война с Англией, важно видеть весь план в перспективе.

В плане обязательно должны быть отражены требования сотрудников, которые будут являться конечными пользователями — так каждый сотрудник узнает, какую именно желаемую фичу и в какое время он точно сможет использовать. При этом план перехода или внедрения это не какой-то неизменяемый монолит, необходимо оставлять возможность доработки плана и изменения его атрибутов (но не в виде бесконечного потока правок и новых «хотелок» и не в виде постоянного смещения сроков).  

Что должно быть в плане?

1. Основные вехи перехода (этапы) — что должно быть сделано.
2. Детальные моменты перехода для каждого этапа — как должно быть сделано.
3. Ключевые точки и отчётность по ним (сверка часов) — как будет измерено то, что сделано и кто должен оказаться на контрольной точке.
4. Ответственные — люди, к которым можно обратиться и с которых можно спросить.
5. Сроки — начало и конец каждого этапа и всего процесса в целом.
6. Затронутые процессы — какие изменения произойдут в бизнес-процессах, что нужно поменять вместе с внедрением/переходом.
7. Итоговая оценка — набор показателей, метрик или даже субъективных оценок, которые помогут оценить произошедшее внедрение/переход.
8. Начало эксплуатации — точный срок, когда вся компания вольётся в обновлённый автоматизированный процесс и будет вести работу в новой системе.

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

Посмотрите на картинку ниже:

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

Автор: Axelus

Источник