Софтверная чехарда скоро станет весьма распространённой болезнью компаний. Менять один софт на другой из-за каждой мелочи, прыгать с технологии на технологию, экспериментировать на живом бизнесе становится нормой. При этом в офисе начинается настоящая гражданская война: формируется движение сопротивления внедрению, партизаны ведут подрывную работу против новой системы, шпионы пропагандируют новый дивный мир с новым софтом, руководство с броневика корпоративного портала вещает про мир, труд, KPI. Революция обычно заканчивается полным провалом одной из сторон.
Мы знаем о внедрении почти всё, поэтому попробуем разобраться, как революцию превратить в эволюцию и сделать внедрение максимально полезным и безболезненным. Ну или по крайней мере расскажем, во что вы можете вляпаться в процессе.
Идеальная визуализация принятия нового ПО сотрудниками.Источник — Яндекс.Картинки
Зарубежные консалтеры начали бы эту статью примерно так: «Если вы предлагаете своим сотрудникам качественное программное обеспечение, которое способно улучшить их работу, оказать качественное влияние на показатели, принятие новой программы или системы произойдёт естественным образом». Но мы с вами в России, поэтому вопрос подозрительных и воинственных сотрудников весьма актуален. Естественного перехода не получится, даже с минимальным ПО типа корпоративного мессенджера или софтфона.
Сегодня в каждой компании установлен целый зоопарк ПО (мы берём общий случай, потому что в ИТ-компаниях количество софта больше вдвое или втрое, а проблемы адаптации пересекаются частично и весьма специфичны): системы управления проектами, CRM/ERP, почтовые клиенты, мессенджеры, корпоративный портал и т.д. И это не считая того, что бывают компании, в которых даже переход с браузера на браузер осуществляется всей командой без исключения (а ещё есть команды, полностью сидящие наInternet Explorer Edge). В общем случае есть несколько ситуаций, для которых может оказаться полезной наша статья:
Конечно, первые два случая гораздо более острые и типичные в своих проявлениях, обратите на них особое внимание.
Итак, перед тем, как начать работать с коллективом (который уже заподозрил, что ж-ж-ж-ж неспроста, и скоро будут перемены), попробуйте понять, в чём состоят реальные причины смены ПО и согласны ли вы с тем, что перемены столь уж необходимы.
Мы говорим о причинах именно переходов с одного ПО на другое, а не о первичной автоматизации — только потому что автоматизация априори необходима. Если в вашей компании что-то делается вручную и рутинно, но может быть автоматизировано, вы просто теряете время, деньги и, скорее всего, ценные корпоративные данные. Автоматизируйте это!
В мировой практике существуют три основных стратегии перехода на новое ПО, адаптации к нему — и они нам кажутся весьма годными, поэтому не будем изобретать велосипед.
Принятие методом «Большого взрыва» — максимально жёсткий переход, когда вы устанавливаете точную дату и осуществляете резкую миграцию, отключая старое ПО на все 100%.
Плюсы
+ Все работают в одной системе, не нужно синхронизировать данные, сотрудникам не нужно следить сразу за двумя интерфейсами.
+ Простота для администратора — одна миграция, одни задачи, поддержа одной системы.
+ Все возможные изменения наступают в один момент времени и заметны почти сразу — нет необходимости вычленять, что и в какой доле повлияло на продуктивность, скорость разработки, продажи и т.д.
Минусы
— Успешно работает только с простым программным обеспечением: чаты, корпоративный портал, мессенджеры. Даже электронная почта уже может дать сбои, не говоря уж о системах управления проектами, CRM/ERP и прочих серьёзных системах.
— «Взрывная» миграция с крупной системы на другую неизбежно вызовет хаос.
Самое важное для такого типа перехода в новую рабочую среду — это обучение.
Параллельная адаптация к ПО — более мягкий и наиболее универсальный способ перехода, при котором задаётся временной промежуток, в течение которого будут одновременно функционировать обе системы.
Плюсы
+ Пользователи имеют достаточно времени, чтобы привыкнуть к новому ПО, оперативно работая в старом, отыскать параллели, вникнуть в новую логику взаимодействия с интерфейсом.
+ В случае внезапных проблем сотрудники продолжают работать в старой системе.
+ Обучение пользователей менее жёсткое и в целом обходится дешевле.
+ Негативная реакция сотрудников практически отсутствует — ведь их не лишили привычного инструмента или уклада дел (если автоматизация происходит впервые).
Минусы
— Проблемы администрирования: поддержка обеих систем, синхронизация данных, управление безопасностью сразу в двух приложениях.
— Бесконечно растягивается процесс перехода — сотрудники осознают, что у них в запасе почти вечность, и можно продлить использование привычного интерфейса ещё немножко.
— Путаница пользователей — два интерфейса сбивают с толку и вызывают ошибки в работе и данных.
— Деньги. Вы платите за обе системы.
Поэтапная адаптация — самый мягкий вариант перехода на новое ПО. Переход осуществляется пофункционально, в оговоренные периоды времени и по подразделениям (например, с 1 июня мы вносим новых клиентов только в новую CRM-систему, с 20 июня ведём сделки в новой системе, до 1 августа переносим календари и дела, и к 30 сентября завершаем миграцию — это очень грубое описание, но в целом наглядное).
Плюсы
+ Организованный переход, распределённая нагрузка на администраторов и внутренних экспертов.
+ Более продуманное и глубокое обучение.
+ Нет сопротивления изменениям, потому что они происходят максимально мягко.
Минусы — примерно такие же, как у параллельного перехода.
Так что теперь, только поэтапный переход?
Логичный вопрос, согласитесь. Зачем получить какую-то лишнюю мороку, когда можно составить график и действовать по чёткому плану? На самом деле не всё так однозначно.
Опять же, даже зная перечисленные параметры, нельзя однозначно становиться на тот или иной путь. Оцените ваше корпоративное окружение — это поможет одновременно понять расклад сил и определить, какая модель (или сочетание некоторых их элементов) вам подойдёт.
Первое, на что стоит обратить внимание, это сотрудники, которых заденет внедрение нового ПО. Собственно, проблема, которую мы с вами сейчас рассматриваем, чистой воды человеческий фактор, поэтому анализа влияния на сотрудников не избежать. Некоторых из них мы уже упомянули выше.
Есть универсальный рецепт, как проверить, пользователи действительно чего-то опасаются или у них групповая паранойя во главе с подкованным лидером. Спросите их о причинах недовольства, об опасениях — если это не персональное переживание или мнение, аргументы посыпятся на 3-4 уточняющем вопросе.
Два важных фактора успешного преодоления «движения сопротивления».
На что нужно обратить внимание?
Единственный логичный переход в системе корпоративного мышления
Прежде чем рассказать, какие ключевые моменты помогут вам комфортно переехать на новый софт, заострим ваше внимание на одном моменте. Есть то, что делать точно не надо — не надо давить на сотрудников и «мотивировать» их депремированием, административными и дисциплинарными взысканиями. Процесс от этого лучше не пойдёт, а вот отношение сотрудников ухудшится: раз продавливают, значит, будет контроль; раз заставляют, значит, не уважают наш интерес; раз насильно навязывают, значит, нам и нашей работе не доверяют. Поэтому всё делаем дисциплинированно, чётко, грамотно, но без давления и излишнего форсирования.
Вот всего остального может не быть, а план быть должен. Причём план корректируемый, обновляемый, чёткий и неотвратимый, при этом доступный для обсуждения и прозрачный для всех заинтересованных сотрудников. Нельзя директивно сообщать о том, что С 8 утра до 10 — подвиг, а в 16:00 война с Англией, важно видеть весь план в перспективе.
В плане обязательно должны быть отражены требования сотрудников, которые будут являться конечными пользователями — так каждый сотрудник узнает, какую именно желаемую фичу и в какое время он точно сможет использовать. При этом план перехода или внедрения это не какой-то неизменяемый монолит, необходимо оставлять возможность доработки плана и изменения его атрибутов (но не в виде бесконечного потока правок и новых «хотелок» и не в виде постоянного смещения сроков).
Что должно быть в плане?
Мы встречали презентации внедренцев, в которых красной линией проходит совет: внедрять насильно, реакцию игнорировать, с сотрудниками не разговаривать. Мы против такого подхода, и вот почему.
Посмотрите на картинку ниже:
Новая мышка, новая клавиатура, квартира, машина и даже работа — это приятные, радостные события, некоторые из них даже достижения. И пользователь идёт в Яндекс, чтобы узнать, как привыкнуть, адаптироваться. Как войти в новую квартиру и понять, что это твоё, впервые открыть кран, выпить чай, впервые лечь спать. Как сесть за руль и подружиться с новой машиной, твоей, но пока такой чужой. Новое ПО на рабочем месте ничем не отличается от описанных ситуаций: работа сотрудника никогда не станет прежней. Поэтому внедряйте, адаптируйте, растите с новым эффективным ПО. И это та ситуация, про которую можно сказать: поспешайте медленно.
Мы знаем о внедрении почти всё, поэтому попробуем разобраться, как революцию превратить в эволюцию и сделать внедрение максимально полезным и безболезненным. Ну или по крайней мере расскажем, во что вы можете вляпаться в процессе.
Идеальная визуализация принятия нового ПО сотрудниками.Источник — Яндекс.Картинки
Зарубежные консалтеры начали бы эту статью примерно так: «Если вы предлагаете своим сотрудникам качественное программное обеспечение, которое способно улучшить их работу, оказать качественное влияние на показатели, принятие новой программы или системы произойдёт естественным образом». Но мы с вами в России, поэтому вопрос подозрительных и воинственных сотрудников весьма актуален. Естественного перехода не получится, даже с минимальным ПО типа корпоративного мессенджера или софтфона.
Откуда растут ноги у проблемы?
Сегодня в каждой компании установлен целый зоопарк ПО (мы берём общий случай, потому что в ИТ-компаниях количество софта больше вдвое или втрое, а проблемы адаптации пересекаются частично и весьма специфичны): системы управления проектами, CRM/ERP, почтовые клиенты, мессенджеры, корпоративный портал и т.д. И это не считая того, что бывают компании, в которых даже переход с браузера на браузер осуществляется всей командой без исключения (а ещё есть команды, полностью сидящие на
- происходит процесс первичной автоматизации какой-то группы задач: внедряется первая CRM/ERP, открывается корпоративный портал, устанавливается система для технической поддержки и проч.;
- происходит замена одного ПО на другое по каким-то причинам: устаревание, новые требования, масштабирование, смена деятельности и т.д.;
- происходит наращивание модулей существующей системы для целей развития и роста (например, компания открыла производство и решила перейти с RegionSoft CRM Professional на RegionSoft CRM Enterprise Plus с максимальной функциональностью);
- происходит серьёзное интерфейсное и функциональное обновление ПО.
Конечно, первые два случая гораздо более острые и типичные в своих проявлениях, обратите на них особое внимание.
Итак, перед тем, как начать работать с коллективом (который уже заподозрил, что ж-ж-ж-ж неспроста, и скоро будут перемены), попробуйте понять, в чём состоят реальные причины смены ПО и согласны ли вы с тем, что перемены столь уж необходимы.
- В старой программе сложно работать: она дорогая, неудобная, нефункциональная, перестала соответствовать вашим требованиям, не подходит для вашего масштаба и т.д. Это объективная необходимость.
- Вендор перестал поддерживать систему, либо поддержка и доработка превратились в бесконечную череду согласований и вытягивания денег. Если ваши затраты значительно выросли, и в перспективе обещают увеличиться ещё — ждать нечего, нужно резать. Да, новая система тоже будет стоить денег, но в конечном итоге оптимизация обойдётся дешевле, чем такая поддержка.
- Смена ПО — прихоть одного человека или группы сотрудников. Например, CTO хочет откат и лоббирует внедрение новой, более дорогой системы, — такое бывает в больших компаниях. Другой пример: проектный менеджер ратует за смену Asana на Basecamp, потом Basecamp на Jira, сложной Jira на Wrike. Нередко единственный мотив таких миграций — показать свою бурную работу и сохранить должность. В таких случаях нужно определять степень необходимости, мотивы и обоснованность и, как правило, волевым решением отказывать в изменениях.
Мы говорим о причинах именно переходов с одного ПО на другое, а не о первичной автоматизации — только потому что автоматизация априори необходима. Если в вашей компании что-то делается вручную и рутинно, но может быть автоматизировано, вы просто теряете время, деньги и, скорее всего, ценные корпоративные данные. Автоматизируйте это!
Как можно перейти: великий скачок или крадущийся тигр?
В мировой практике существуют три основных стратегии перехода на новое ПО, адаптации к нему — и они нам кажутся весьма годными, поэтому не будем изобретать велосипед.
Big Bang
Принятие методом «Большого взрыва» — максимально жёсткий переход, когда вы устанавливаете точную дату и осуществляете резкую миграцию, отключая старое ПО на все 100%.
Плюсы
+ Все работают в одной системе, не нужно синхронизировать данные, сотрудникам не нужно следить сразу за двумя интерфейсами.
+ Простота для администратора — одна миграция, одни задачи, поддержа одной системы.
+ Все возможные изменения наступают в один момент времени и заметны почти сразу — нет необходимости вычленять, что и в какой доле повлияло на продуктивность, скорость разработки, продажи и т.д.
Минусы
— Успешно работает только с простым программным обеспечением: чаты, корпоративный портал, мессенджеры. Даже электронная почта уже может дать сбои, не говоря уж о системах управления проектами, CRM/ERP и прочих серьёзных системах.
— «Взрывная» миграция с крупной системы на другую неизбежно вызовет хаос.
Самое важное для такого типа перехода в новую рабочую среду — это обучение.
Parallel Running
Параллельная адаптация к ПО — более мягкий и наиболее универсальный способ перехода, при котором задаётся временной промежуток, в течение которого будут одновременно функционировать обе системы.
Плюсы
+ Пользователи имеют достаточно времени, чтобы привыкнуть к новому ПО, оперативно работая в старом, отыскать параллели, вникнуть в новую логику взаимодействия с интерфейсом.
+ В случае внезапных проблем сотрудники продолжают работать в старой системе.
+ Обучение пользователей менее жёсткое и в целом обходится дешевле.
+ Негативная реакция сотрудников практически отсутствует — ведь их не лишили привычного инструмента или уклада дел (если автоматизация происходит впервые).
Минусы
— Проблемы администрирования: поддержка обеих систем, синхронизация данных, управление безопасностью сразу в двух приложениях.
— Бесконечно растягивается процесс перехода — сотрудники осознают, что у них в запасе почти вечность, и можно продлить использование привычного интерфейса ещё немножко.
— Путаница пользователей — два интерфейса сбивают с толку и вызывают ошибки в работе и данных.
— Деньги. Вы платите за обе системы.
Phased Adoption
Поэтапная адаптация — самый мягкий вариант перехода на новое ПО. Переход осуществляется пофункционально, в оговоренные периоды времени и по подразделениям (например, с 1 июня мы вносим новых клиентов только в новую CRM-систему, с 20 июня ведём сделки в новой системе, до 1 августа переносим календари и дела, и к 30 сентября завершаем миграцию — это очень грубое описание, но в целом наглядное).
Плюсы
+ Организованный переход, распределённая нагрузка на администраторов и внутренних экспертов.
+ Более продуманное и глубокое обучение.
+ Нет сопротивления изменениям, потому что они происходят максимально мягко.
Минусы — примерно такие же, как у параллельного перехода.
Так что теперь, только поэтапный переход?
Логичный вопрос, согласитесь. Зачем получить какую-то лишнюю мороку, когда можно составить график и действовать по чёткому плану? На самом деле не всё так однозначно.
- Сложность программного обеспечения: если речь идёт о сложном ПО (например, CRM-системе), то больше подойдёт фазовая адаптация. Если ПО простое (мессенджер, корпоративный портал), то подойдёт модель, когда вы объявили о дате и отрубаете старое ПО в назначенный день (если повезет, сотрудники успеют вытащить всю необходимую им информацию, а если не рассчитывать на везение, то необходимо предусмотреть автоматизированный импорт необходимых данных из старой системы в новую, при наличии технической возможности).
- Степень риска для компании: чем рисковее внедрение, тем медленнее оно должно быть. С другой стороны, затягивание — тоже риск: например, вы переходите с одной CRM-системы на другую, и в период перехода вынуждены платить за обе, тем самым растут затраты и стоимость внедрения новой системы, а значит, растягивается период окупаемости.
- Численность сотрудников: большой взрыв точно не подойдёт в случае необходимости масштабирования и настройки множества пользовательских профилей. Хотя бывают случаи, когда ультра быстрое внедрение для большой компании — благо. Такой вариант может подойти для систем, которыми пользуются многие сотрудники, но при этом не могут иметь требования, поскольку не предполагается кастомизация. Но опять же, это big bang для конечных пользователей и огромная поэтапная работа для той же ИТ-службы (например, биллинг или пропускная система).
- Особенности внедрения выбранного ПО (доработка и т.д.). Иногда внедрение изначально поэтапное — со сбором требований, доработкой, обучением и т.д. Например, CRM-система внедряется всегда поступательно и если вам кто-то обещает «внедрить и настроить за 3 дня или даже 3 часа» — вспомните эту статью и обойдите такие услуги стороной: установка ? внедрение.
Опять же, даже зная перечисленные параметры, нельзя однозначно становиться на тот или иной путь. Оцените ваше корпоративное окружение — это поможет одновременно понять расклад сил и определить, какая модель (или сочетание некоторых их элементов) вам подойдёт.
Агенты влияния: революция или эволюция
Первое, на что стоит обратить внимание, это сотрудники, которых заденет внедрение нового ПО. Собственно, проблема, которую мы с вами сейчас рассматриваем, чистой воды человеческий фактор, поэтому анализа влияния на сотрудников не избежать. Некоторых из них мы уже упомянули выше.
- Руководители компании определяют, как в целом будет принято новое ПО. И здесь не место рекламным речам и пламенным выступлениям, — важно показать именно необходимость изменений, пронести идею о том, что это всего лишь выбор более крутого и удобного инструмента, такой же, как замена старого ноутбука. Самая большая ошибка руководства в такой ситуации — умыть руки и самоустраниться: если начальству не нужна автоматизация компании, почему она должна быть интересна сотрудникам? Будьте в процессе.
- Руководители отделов (менеджеры проектов) — промежуточное звено, которое обязательно должно участвовать во всех процессах, управлять недовольством, проявить волю и отработать каждое возражение коллег, провести качественное и глубокое обучение.
- ИТ-служба (или системные администраторы) — на первый взгляд, это ваши early birds, самые адаптируемые и адаптирующие, но… нет. Нередко, особенно в малых и средних компаниях, сисадмины выступают против каких-либо изменений (усилений) ИТ-инфраструктуры, и связано это не с какой-то технической обоснованностью, а с ленью и нежеланием работать. А кто из нас не искал путей откосить от выполнения работы? Но пусть это будет не во вред всей компании.
- Конечные пользователи, как правило, хотят работать хорошо и удобно с одной стороны и, как и любые живые люди, боятся изменений. Основная аргументация для них честная и простая: зачем внедряем/меняем, какие границы у контроля, как будет оцениваться работа, что изменится и в чём риски (кстати, риски стоит оценить всем — мы хоть и вендоры CRM-системы, но не берёмся сказать, что всё всегда проходит гладко: риски есть в любом процессе внутри бизнеса).
- «Авторитеты» внутри компании — партизаны, которые могут оказывать влияние на остальных сотрудников. Это не обязательно человек с высокой должностью или большим опытом — в случае работы с ПО «авторитетом» может оказаться продвинутый всезнайка, который, например, перечитал Хабра и начнёт всех запугивать тем, как всё станет плохо. У него может даже не быть цели порушить процесс внедрения или перехода, — просто понты и дух сопротивления, — а сотрудники ему поверят. С такими сотрудниками нужно работать: разъяснить, расспросить, в особо тяжёлых случаях намекнуть на последствия.
Есть универсальный рецепт, как проверить, пользователи действительно чего-то опасаются или у них групповая паранойя во главе с подкованным лидером. Спросите их о причинах недовольства, об опасениях — если это не персональное переживание или мнение, аргументы посыпятся на 3-4 уточняющем вопросе.
Два важных фактора успешного преодоления «движения сопротивления».
- Проводите обучение: вендорское и внутреннее. Убедитесь в том, что сотрудники действительно всё поняли, усвоили и вне зависимости от уровня подготовки готовы начать работать. Обязательный атрибут обучения — печатные и электронные инструкции (регламенты) и максимально полная документация по системе (уважающие себя вендоры выпускают её вместе с ПО и предоставляют бесплатно).
- Ищите сторонников и выбирайте инфлюэнсеров. Внутренние эксперты и ранние последователи — ваша опора, которая и обучит, и развеет сомнения. Как правило, сотрудникам самим приятно помогать коллегам, вводить их в новый софт. Ваша задача — временно разгрузить их от работы либо достойно премировать за новую нагрузку.
На что нужно обратить внимание?
- Насколько продвинуты те сотрудники, которых затронут изменения? (Условно говоря, если завтра изобретут новую бухгалтерскую программу, на дай вам бог сунуться в бухгалтерию с дамами за 50 и предложить переход с 1С — живым не выйдете).
- Насколько сильно будут затронуты рабочие процессы? Одно дело поменять мессенджер в компании из 100 человек, другое — внедрить новую CRM-систему, на работе в которой завязаны ключевые процессы в компании (и это не только продажи, например, внедрение RegionSoft CRM в старших редакциях затрагивает и производство, и склад, и маркетинг, и топ-менеджеров, которые вместе с командой будут выстраивать автоматизированные бизнес-процессы).
- Проведено ли обучение и на каком уровне?
Единственный логичный переход в системе корпоративного мышления
Что спасёт переход/внедрение нового ПО?
Прежде чем рассказать, какие ключевые моменты помогут вам комфортно переехать на новый софт, заострим ваше внимание на одном моменте. Есть то, что делать точно не надо — не надо давить на сотрудников и «мотивировать» их депремированием, административными и дисциплинарными взысканиями. Процесс от этого лучше не пойдёт, а вот отношение сотрудников ухудшится: раз продавливают, значит, будет контроль; раз заставляют, значит, не уважают наш интерес; раз насильно навязывают, значит, нам и нашей работе не доверяют. Поэтому всё делаем дисциплинированно, чётко, грамотно, но без давления и излишнего форсирования.
У вас должен быть подробный план действий
Вот всего остального может не быть, а план быть должен. Причём план корректируемый, обновляемый, чёткий и неотвратимый, при этом доступный для обсуждения и прозрачный для всех заинтересованных сотрудников. Нельзя директивно сообщать о том, что С 8 утра до 10 — подвиг, а в 16:00 война с Англией, важно видеть весь план в перспективе.
В плане обязательно должны быть отражены требования сотрудников, которые будут являться конечными пользователями — так каждый сотрудник узнает, какую именно желаемую фичу и в какое время он точно сможет использовать. При этом план перехода или внедрения это не какой-то неизменяемый монолит, необходимо оставлять возможность доработки плана и изменения его атрибутов (но не в виде бесконечного потока правок и новых «хотелок» и не в виде постоянного смещения сроков).
Что должно быть в плане?
- Основные вехи перехода (этапы) — что должно быть сделано.
- Детальные моменты перехода для каждого этапа — как должно быть сделано.
- Ключевые точки и отчётность по ним (сверка часов) — как будет измерено то, что сделано и кто должен оказаться на контрольной точке.
- Ответственные — люди, к которым можно обратиться и с которых можно спросить.
- Сроки — начало и конец каждого этапа и всего процесса в целом.
- Затронутые процессы — какие изменения произойдут в бизнес-процессах, что нужно поменять вместе с внедрением/переходом.
- Итоговая оценка — набор показателей, метрик или даже субъективных оценок, которые помогут оценить произошедшее внедрение/переход.
- Начало эксплуатации — точный срок, когда вся компания вольётся в обновлённый автоматизированный процесс и будет вести работу в новой системе.
Мы встречали презентации внедренцев, в которых красной линией проходит совет: внедрять насильно, реакцию игнорировать, с сотрудниками не разговаривать. Мы против такого подхода, и вот почему.
Посмотрите на картинку ниже:
Новая мышка, новая клавиатура, квартира, машина и даже работа — это приятные, радостные события, некоторые из них даже достижения. И пользователь идёт в Яндекс, чтобы узнать, как привыкнуть, адаптироваться. Как войти в новую квартиру и понять, что это твоё, впервые открыть кран, выпить чай, впервые лечь спать. Как сесть за руль и подружиться с новой машиной, твоей, но пока такой чужой. Новое ПО на рабочем месте ничем не отличается от описанных ситуаций: работа сотрудника никогда не станет прежней. Поэтому внедряйте, адаптируйте, растите с новым эффективным ПО. И это та ситуация, про которую можно сказать: поспешайте медленно.
Комментарии (17)
epishman
05.06.2019 01:26Десяток проектов сделал, и понял, что и большой взрыв и тигр на цыпочках — оба не работают, но по разным причинам. Поскольку компании разные, то и ситуации на проектах разные, в первую очередь приходится смотреть насколько формализованы потребности, и насколько компетентны люди со стороны заказчика на разных участках. А в общем — большой взрыв более рискован для подрядчика, поэтому последние усиленно форсят скрам, который часто вырождается в обычную почасовку, естественно, с превышением сроков как минимум.
Mana_Banana
06.06.2019 09:35Эххх… помню замену кассовой системы в сети магазинов, в которой я работал когда то. Сам продавец, но помню все эти проблемы связанные с банальной работой.
В общем, захотели на 1С натянуть скин с большими кнопочками, понятным интерфейсом, легким внедрением скидок и учётностью. Протестили меньше месяца систему в одном маленьком магазине на двух кассирах. Те что-то промычали про функционал и начальство приняло это за удачный эксперимент. Ну, а после, года 2 ошибок, истерик, непонимания, обучения и переобучения уже по факту внедрения. Сейчас это более-менее работает, судя по новичкам за кассами и довольно сносной скорости работы, но стоило ли 2 года ради этого мучатся?
Не говоря уже о битриксе24 на нынешней работе. Я готов ко многому привыкнуть, но когда систему внедряют криво, а она еще не поддерживает работу с большинством функционала на котором базируется твоя работа — это ад. В итоге, попытались внедрить со всеми фишками — обделались. Оставили учетную часть — обделались. Зажали бабла на норм «внедрителей» — обделались. И всё чем я сейчас пользуюсь — онлайн чат и костыльная синхронизация по статусам заказов. Респект таким руководителям.
Guitariz
Дело ж не в софте)
Замените «софт» на «реорганизацию работы» — особо в проблематике ничего не изменится
Garbus
Думаю всё проще объясняется другой фразой «Что мне за это будет?». Человек должен или видеть финансовый интерес, или уменьшение нагрузки на него лично. Во всех остальных случаях недовольные будут непременно. Нынче совсем не СССР где такие моменты бывали, пропаганда нынче в сторону «Не пойман, не вор.».
DrPass
Главный момент в том, чтобы человек не видел увеличение нагрузки на него. Если, например, взять тот же CRM, то самое первое впечатление, которое испытывает продажник, это «Ёп, теперь мне надо будет сюда вносить всю информацию о моих делах? Это ж сколько работы! А вы ещё и контролировать меня тут будете? Неее, я так не хочу!»
А вот реально полезные вещи для него раскроются уже потом, после обкатки… если предприятие до этого дотянет, а не сдастся под натиском всего отдела продаж :)
EgorZanuda
Если CRM встроено в саму учетную систему, то менеджер продаж вообще не заметить нагрузки работы в CRM. А вот если ее прилепят параллельно то это уже не CRM, а геморой для любого звена в компании.
Garbus
Нуу, любое изменение процесса работы это нагрузка на мозг, вынужденный учиться новому. А так как стимулировать мозги на работу та еще задача, без сочной «морковки» какой либо разновидности, причин не напрягаться будет сгенерировано любое потребное количество.
Axelus Автор
Правильное внедрение CRM должно повышать эффективность линейного персонала, делать его работу более легкой и понятной. Чтобы донести это до линейных сотрудников, руководство может выпустить специальный регламент с разъяснениями, какие действия должен каждый сотрудник регистрировать в CRM и как. А самое главное, показать на примере, как правильное ведение собственных дел должно привести к увеличению эффективности этого сотрудника и материализоваться в деньги.
Тогда не будет ни саботажа, ни противодействия.
DrPass
CRM эффективно решает массу задач. Она повышает скорость и точность доставки заказов на обработку в бэк-офис, избавляет от массы лишних коммуникаций между сотрудниками, позволяет оценивать продуктивность работы продажников, устанавливать им KPI, находить возможность кросс-продаж, сделать клиентскую базу независимой от продажников и защитить компанию от их ухода вместе с клиентской базой и т.д.
CRM много чего позволяет. Но вот единственное, чего она не позволяет — уменьшить количество работы для продажника. Потому как «продавать и записывать выборочно в блокнот то, что мне надо, как я считаю», это всегда легче, чем «продавать и регистрировать все регламентированные действия в CRM». И плюс ещё вся подноготная работы теперь становится как на ладони у начальства. Поэтому продажники практически всегда или саботируют внедрение или хотя бы просто недовольно терпят, в зависимости от мотивации. Никакое повышение эффективности для них не компенсируется увеличением контроля и отчетности.
Axelus Автор
Когда каждый линейный сотрудник делает то, что он считает правильным, а не то, что от него требует руководство, то такая деятельность неизбежно приводит к хаосу. А глубина этого хаоса прямопропорциональна количеству сотрудников, работающих по такому принципу.
Я понимаю, что сейчас огребу бурю негодования за свои слова, но я исхожу из того, что бизнес должен быть измеряемым и управляемым. А это задача руководства. Руководитель не сможет качественно управлять бизнесом, если линейный персонал будет выполнять лишь то, что ему нравится и так, как хочет. Даже если лично для линейного сотрудника такой подход более выгоден, то бизнесу в целом он наносит только вред.
DrPass
Это вопросы из разных плоскостей. Мы говорили о принятии системы персоналом, а вы говорите о полезности системы для бизнеса. Естественно, вы правы.
Slaavon
Вы неправы. Ваша позиция напоминает очень сильно, компанию, которая, типа, анализирует «ошибки» в софте и пишет тут часто PV*- Studio. (Ненужный продукт для бизнеса, но с обоснованиями, почему задорого). Второе, самое главное, в каждой сделке с клиентом, это важно её совершить и завершить путём переговоров (может даже краткосрочных), но тем не мененее(!), получить деньги и выйти с прибылью и никакой Ваш формализованный бизнес процесс этого не может обеспечить, не так ли?
Axelus Автор
Конечно не так. Автоматизация осуществляет ускорение прохождения бизнес-процессов, а значит увеличивает эффективность. Привести пример? Продажа обычно состоит из нескольких этапов. И одним из этапов может быть создание условий для переговоров. И когда менеджер назначил встречу, если процесс автоматизирован, то сразу три коллеги могут получить мгновенные уведомления: начальник отдела о факте назначенных переговоров, менеджер сопровождения сделок о необходимости подготовить такие-то документы к такому-то времени, секретарь о бронировании переговорной. А сам сотрудник за полчаса до назначенного времени получит напоминание в виде смс или е-мейл. При этом единственное, что должен сделать сотрудник — зафиксировать в CRM факт назначения переговоров. Ему даже не потребуется обзванивать своих коллег с этой информацией. А в нужное время у него уже будет забронирована переговорная, подготовлены документы и рекламные материалы, свежий кофе с печенюшками, и точно об этой встрече никто не забудет, даже если она будет назначена через неделю или две. Вот это и есть автоматизация. Она должна помогать и линейному персоналу и, соответственно, руководству. А квалификацию менеджера никто не отменял. Он как раньше проводил переговоры, так и с CRM-системой будет проводить. Если менеджер никакой, то и автоматизация не поможет. Клиент просто убежит из переговорной с криком "О Боже, куда я попал? Что за идиоты здесь работают..."
Хотя, если одно из уведомлений будет направлено в отдел принуждения к сделкам и в процессе переговоров вокруг переговорной будет стоять рота солдат с автоматами, то и в этом вопросе автоматизация может помочь справиться… ;)
Jon7
То что продавцы саботируют внедрение это правильно. Потому что при этом всё сваливается в одну кучу. Фактически проводиться одновременно несколько изменений, а они требуют разных подходов и способов решений. Увеличение контроля и отчётности может, и должно происходить независимо от внедрения и целесообразно до внедрения, можно на бумаге. Элементарно ведётся картотека на основании которой строиться прогноз тех же продаж, это как пример. Понятно что появление CRM в этом случае будет благом. Одна группа изменений это наведение элементарного порядка в проектировании и организации работ, другая группа автоматизация рутины. А то что называют саботажем внедрения при анализе оказывается разумным протестом против автоматизации хаоса, на языке ИТ это GIGA в чистом виде.