Софтверная чехарда скоро станет весьма распространённой болезнью компаний. Менять один софт на другой из-за каждой мелочи, прыгать с технологии на технологию, экспериментировать на живом бизнесе становится нормой. При этом в офисе начинается настоящая гражданская война: формируется движение сопротивления внедрению, партизаны ведут подрывную работу против новой системы, шпионы пропагандируют новый дивный мир с новым софтом, руководство с броневика корпоративного портала вещает про мир, труд, KPI. Революция обычно заканчивается полным провалом одной из сторон.
Мы знаем о внедрении почти всё, поэтому попробуем разобраться, как революцию превратить в эволюцию и сделать внедрение максимально полезным и безболезненным. Ну или по крайней мере расскажем, во что вы можете вляпаться в процессе.
Идеальная визуализация принятия нового ПО сотрудниками.Источник — Яндекс.Картинки
Зарубежные консалтеры начали бы эту статью примерно так: «Если вы предлагаете своим сотрудникам качественное программное обеспечение, которое способно улучшить их работу, оказать качественное влияние на показатели, принятие новой программы или системы произойдёт естественным образом». Но мы с вами в России, поэтому вопрос подозрительных и воинственных сотрудников весьма актуален. Естественного перехода не получится, даже с минимальным ПО типа корпоративного мессенджера или софтфона.
Откуда растут ноги у проблемы?
Сегодня в каждой компании установлен целый зоопарк ПО (мы берём общий случай, потому что в ИТ-компаниях количество софта больше вдвое или втрое, а проблемы адаптации пересекаются частично и весьма специфичны): системы управления проектами, CRM/ERP, почтовые клиенты, мессенджеры, корпоративный портал и т.д. И это не считая того, что бывают компании, в которых даже переход с браузера на браузер осуществляется всей командой без исключения (а ещё есть команды, полностью сидящие на Internet Explorer Edge). В общем случае есть несколько ситуаций, для которых может оказаться полезной наша статья:
- происходит процесс первичной автоматизации какой-то группы задач: внедряется первая CRM/ERP, открывается корпоративный портал, устанавливается система для технической поддержки и проч.;
- происходит замена одного ПО на другое по каким-то причинам: устаревание, новые требования, масштабирование, смена деятельности и т.д.;
- происходит наращивание модулей существующей системы для целей развития и роста (например, компания открыла производство и решила перейти с на с максимальной функциональностью);
- происходит серьёзное интерфейсное и функциональное обновление ПО.
Конечно, первые два случая гораздо более острые и типичные в своих проявлениях, обратите на них особое внимание.
Итак, перед тем, как начать работать с коллективом (который уже заподозрил, что ж-ж-ж-ж неспроста, и скоро будут перемены), попробуйте понять, в чём состоят реальные причины смены ПО и согласны ли вы с тем, что перемены столь уж необходимы.
- В старой программе сложно работать: она дорогая, неудобная, нефункциональная, перестала соответствовать вашим требованиям, не подходит для вашего масштаба и т.д. Это объективная необходимость.
- Вендор перестал поддерживать систему, либо поддержка и доработка превратились в бесконечную череду согласований и вытягивания денег. Если ваши затраты значительно выросли, и в перспективе обещают увеличиться ещё — ждать нечего, нужно резать. Да, новая система тоже будет стоить денег, но в конечном итоге оптимизация обойдётся дешевле, чем такая поддержка.
- Смена ПО — прихоть одного человека или группы сотрудников. Например, CTO хочет откат и лоббирует внедрение новой, более дорогой системы, — такое бывает в больших компаниях. Другой пример: проектный менеджер ратует за смену Asana на Basecamp, потом Basecamp на Jira, сложной Jira на Wrike. Нередко единственный мотив таких миграций — показать свою бурную работу и сохранить должность. В таких случаях нужно определять степень необходимости, мотивы и обоснованность и, как правило, волевым решением отказывать в изменениях.
Мы говорим о причинах именно переходов с одного ПО на другое, а не о первичной автоматизации — только потому что автоматизация априори необходима. Если в вашей компании что-то делается вручную и рутинно, но может быть автоматизировано, вы просто теряете время, деньги и, скорее всего, ценные корпоративные данные. Автоматизируйте это!
Как можно перейти: великий скачок или крадущийся тигр?
В мировой практике существуют три основных стратегии перехода на новое ПО, адаптации к нему — и они нам кажутся весьма годными, поэтому не будем изобретать велосипед.
Big Bang
Принятие методом «Большого взрыва» — максимально жёсткий переход, когда вы устанавливаете точную дату и осуществляете резкую миграцию, отключая старое ПО на все 100%.
Плюсы
+ Все работают в одной системе, не нужно синхронизировать данные, сотрудникам не нужно следить сразу за двумя интерфейсами.
+ Простота для администратора — одна миграция, одни задачи, поддержа одной системы.
+ Все возможные изменения наступают в один момент времени и заметны почти сразу — нет необходимости вычленять, что и в какой доле повлияло на продуктивность, скорость разработки, продажи и т.д.
Минусы
— Успешно работает только с простым программным обеспечением: чаты, корпоративный портал, мессенджеры. Даже электронная почта уже может дать сбои, не говоря уж о системах управления проектами, CRM/ERP и прочих серьёзных системах.
— «Взрывная» миграция с крупной системы на другую неизбежно вызовет хаос.
Самое важное для такого типа перехода в новую рабочую среду — это обучение.
Parallel Running
Параллельная адаптация к ПО — более мягкий и наиболее универсальный способ перехода, при котором задаётся временной промежуток, в течение которого будут одновременно функционировать обе системы.
Плюсы
+ Пользователи имеют достаточно времени, чтобы привыкнуть к новому ПО, оперативно работая в старом, отыскать параллели, вникнуть в новую логику взаимодействия с интерфейсом.
+ В случае внезапных проблем сотрудники продолжают работать в старой системе.
+ Обучение пользователей менее жёсткое и в целом обходится дешевле.
+ Негативная реакция сотрудников практически отсутствует — ведь их не лишили привычного инструмента или уклада дел (если автоматизация происходит впервые).
Минусы
— Проблемы администрирования: поддержка обеих систем, синхронизация данных, управление безопасностью сразу в двух приложениях.
— Бесконечно растягивается процесс перехода — сотрудники осознают, что у них в запасе почти вечность, и можно продлить использование привычного интерфейса ещё немножко.
— Путаница пользователей — два интерфейса сбивают с толку и вызывают ошибки в работе и данных.
— Деньги. Вы платите за обе системы.
Phased Adoption
Поэтапная адаптация — самый мягкий вариант перехода на новое ПО. Переход осуществляется пофункционально, в оговоренные периоды времени и по подразделениям (например, с 1 июня мы вносим новых клиентов только в новую CRM-систему, с 20 июня ведём сделки в новой системе, до 1 августа переносим календари и дела, и к 30 сентября завершаем миграцию — это очень грубое описание, но в целом наглядное).
Плюсы
+ Организованный переход, распределённая нагрузка на администраторов и внутренних экспертов.
+ Более продуманное и глубокое обучение.
+ Нет сопротивления изменениям, потому что они происходят максимально мягко.
Минусы — примерно такие же, как у параллельного перехода.
Так что теперь, только поэтапный переход?
Логичный вопрос, согласитесь. Зачем получить какую-то лишнюю мороку, когда можно составить график и действовать по чёткому плану? На самом деле не всё так однозначно.
- Сложность программного обеспечения: если речь идёт о сложном ПО (например, ), то больше подойдёт фазовая адаптация. Если ПО простое (мессенджер, корпоративный портал), то подойдёт модель, когда вы объявили о дате и отрубаете старое ПО в назначенный день (если повезет, сотрудники успеют вытащить всю необходимую им информацию, а если не рассчитывать на везение, то необходимо предусмотреть автоматизированный импорт необходимых данных из старой системы в новую, при наличии технической возможности).
- Степень риска для компании: чем рисковее внедрение, тем медленнее оно должно быть. С другой стороны, затягивание — тоже риск: например, вы переходите с одной CRM-системы на другую, и в период перехода вынуждены платить за обе, тем самым растут затраты и стоимость внедрения новой системы, а значит, растягивается период окупаемости.
- Численность сотрудников: большой взрыв точно не подойдёт в случае необходимости масштабирования и настройки множества пользовательских профилей. Хотя бывают случаи, когда ультра быстрое внедрение для большой компании — благо. Такой вариант может подойти для систем, которыми пользуются многие сотрудники, но при этом не могут иметь требования, поскольку не предполагается кастомизация. Но опять же, это big bang для конечных пользователей и огромная поэтапная работа для той же ИТ-службы (например, биллинг или пропускная система).
- Особенности внедрения выбранного ПО (доработка и т.д.). Иногда внедрение изначально поэтапное — со сбором требований, доработкой, обучением и т.д. Например, внедряется всегда поступательно и если вам кто-то обещает «внедрить и настроить за 3 дня или даже 3 часа» — вспомните эту статью и обойдите такие услуги стороной: установка ≠ внедрение.
Опять же, даже зная перечисленные параметры, нельзя однозначно становиться на тот или иной путь. Оцените ваше корпоративное окружение — это поможет одновременно понять расклад сил и определить, какая модель (или сочетание некоторых их элементов) вам подойдёт.
Агенты влияния: революция или эволюция
Первое, на что стоит обратить внимание, это сотрудники, которых заденет внедрение нового ПО. Собственно, проблема, которую мы с вами сейчас рассматриваем, чистой воды человеческий фактор, поэтому анализа влияния на сотрудников не избежать. Некоторых из них мы уже упомянули выше.
- Руководители компании определяют, как в целом будет принято новое ПО. И здесь не место рекламным речам и пламенным выступлениям, — важно показать именно необходимость изменений, пронести идею о том, что это всего лишь выбор более крутого и удобного инструмента, такой же, как замена старого ноутбука. Самая большая ошибка руководства в такой ситуации — умыть руки и самоустраниться: если начальству не нужна автоматизация компании, почему она должна быть интересна сотрудникам? Будьте в процессе.
- Руководители отделов (менеджеры проектов) — промежуточное звено, которое обязательно должно участвовать во всех процессах, управлять недовольством, проявить волю и отработать каждое возражение коллег, провести качественное и глубокое обучение.
- ИТ-служба (или системные администраторы) — на первый взгляд, это ваши early birds, самые адаптируемые и адаптирующие, но… нет. Нередко, особенно в малых и средних компаниях, сисадмины выступают против каких-либо изменений (усилений) ИТ-инфраструктуры, и связано это не с какой-то технической обоснованностью, а с ленью и нежеланием работать. А кто из нас не искал путей откосить от выполнения работы? Но пусть это будет не во вред всей компании.
- Конечные пользователи, как правило, хотят работать хорошо и удобно с одной стороны и, как и любые живые люди, боятся изменений. Основная аргументация для них честная и простая: зачем внедряем/меняем, какие границы у контроля, как будет оцениваться работа, что изменится и в чём риски (кстати, риски стоит оценить всем — мы хоть и вендоры , но не берёмся сказать, что всё всегда проходит гладко: риски есть в любом процессе внутри бизнеса).
- «Авторитеты» внутри компании — партизаны, которые могут оказывать влияние на остальных сотрудников. Это не обязательно человек с высокой должностью или большим опытом — в случае работы с ПО «авторитетом» может оказаться продвинутый всезнайка, который, например, перечитал Хабра и начнёт всех запугивать тем, как всё станет плохо. У него может даже не быть цели порушить процесс внедрения или перехода, — просто понты и дух сопротивления, — а сотрудники ему поверят. С такими сотрудниками нужно работать: разъяснить, расспросить, в особо тяжёлых случаях намекнуть на последствия.
Есть универсальный рецепт, как проверить, пользователи действительно чего-то опасаются или у них групповая паранойя во главе с подкованным лидером. Спросите их о причинах недовольства, об опасениях — если это не персональное переживание или мнение, аргументы посыпятся на 3-4 уточняющем вопросе.
Два важных фактора успешного преодоления «движения сопротивления».
- Проводите обучение: вендорское и внутреннее. Убедитесь в том, что сотрудники действительно всё поняли, усвоили и вне зависимости от уровня подготовки готовы начать работать. Обязательный атрибут обучения — печатные и электронные инструкции (регламенты) и максимально полная документация по системе (уважающие себя вендоры выпускают её вместе с ПО и предоставляют бесплатно).
- Ищите сторонников и выбирайте инфлюэнсеров. Внутренние эксперты и ранние последователи — ваша опора, которая и обучит, и развеет сомнения. Как правило, сотрудникам самим приятно помогать коллегам, вводить их в новый софт. Ваша задача — временно разгрузить их от работы либо достойно премировать за новую нагрузку.
На что нужно обратить внимание?
- Насколько продвинуты те сотрудники, которых затронут изменения? (Условно говоря, если завтра изобретут новую бухгалтерскую программу, на дай вам бог сунуться в бухгалтерию с дамами за 50 и предложить переход с 1С — живым не выйдете).
- Насколько сильно будут затронуты рабочие процессы? Одно дело поменять мессенджер в компании из 100 человек, другое — внедрить новую CRM-систему, на работе в которой завязаны ключевые процессы в компании (и это не только продажи, например, в старших редакциях затрагивает и производство, и склад, и маркетинг, и топ-менеджеров, которые вместе с командой будут выстраивать автоматизированные бизнес-процессы).
- Проведено ли обучение и на каком уровне?
Единственный логичный переход в системе корпоративного мышления
Что спасёт переход/внедрение нового ПО?
Прежде чем рассказать, какие ключевые моменты помогут вам комфортно переехать на новый софт, заострим ваше внимание на одном моменте. Есть то, что делать точно не надо — не надо давить на сотрудников и «мотивировать» их депремированием, административными и дисциплинарными взысканиями. Процесс от этого лучше не пойдёт, а вот отношение сотрудников ухудшится: раз продавливают, значит, будет контроль; раз заставляют, значит, не уважают наш интерес; раз насильно навязывают, значит, нам и нашей работе не доверяют. Поэтому всё делаем дисциплинированно, чётко, грамотно, но без давления и излишнего форсирования.
У вас должен быть подробный план действий
Вот всего остального может не быть, а план быть должен. Причём план корректируемый, обновляемый, чёткий и неотвратимый, при этом доступный для обсуждения и прозрачный для всех заинтересованных сотрудников. Нельзя директивно сообщать о том, что С 8 утра до 10 — подвиг, а в 16:00 война с Англией, важно видеть весь план в перспективе.
В плане обязательно должны быть отражены требования сотрудников, которые будут являться конечными пользователями — так каждый сотрудник узнает, какую именно желаемую фичу и в какое время он точно сможет использовать. При этом план перехода или внедрения это не какой-то неизменяемый монолит, необходимо оставлять возможность доработки плана и изменения его атрибутов (но не в виде бесконечного потока правок и новых «хотелок» и не в виде постоянного смещения сроков).
Что должно быть в плане?
- Основные вехи перехода (этапы) — что должно быть сделано.
- Детальные моменты перехода для каждого этапа — как должно быть сделано.
- Ключевые точки и отчётность по ним (сверка часов) — как будет измерено то, что сделано и кто должен оказаться на контрольной точке.
- Ответственные — люди, к которым можно обратиться и с которых можно спросить.
- Сроки — начало и конец каждого этапа и всего процесса в целом.
- Затронутые процессы — какие изменения произойдут в бизнес-процессах, что нужно поменять вместе с внедрением/переходом.
- Итоговая оценка — набор показателей, метрик или даже субъективных оценок, которые помогут оценить произошедшее внедрение/переход.
- Начало эксплуатации — точный срок, когда вся компания вольётся в обновлённый автоматизированный процесс и будет вести работу в новой системе.
Мы встречали презентации внедренцев, в которых красной линией проходит совет: внедрять насильно, реакцию игнорировать, с сотрудниками не разговаривать. Мы против такого подхода, и вот почему.
Посмотрите на картинку ниже:
Новая мышка, новая клавиатура, квартира, машина и даже работа — это приятные, радостные события, некоторые из них даже достижения. И пользователь идёт в Яндекс, чтобы узнать, как привыкнуть, адаптироваться. Как войти в новую квартиру и понять, что это твоё, впервые открыть кран, выпить чай, впервые лечь спать. Как сесть за руль и подружиться с новой машиной, твоей, но пока такой чужой. Новое ПО на рабочем месте ничем не отличается от описанных ситуаций: работа сотрудника никогда не станет прежней. Поэтому внедряйте, адаптируйте, растите с новым эффективным ПО. И это та ситуация, про которую можно сказать: поспешайте медленно.
Источник: habr.com