Оптимизация бизнеса для чайников. Почему смелые проекты часто не находят отклик?
Думаю, многие из вас знают то прекрасное чувство, когда в твоей голове зародился мега-проект с мега-эффективностью.
Ты уже представляешь, как после его запуска по офису ходят роботы, всю работу выполняет искусственный интеллект, сам офис напоминает больше серверную, по центру которой висит твоя фотография с надписью «мега-оптимизатор».
Ты все детальнее и детальнее прорисовываешь свою идею в голове и понимаешь, что для ее реализации нет абсолютно ни каких преград.
В голове играет музыка победы, ты продумываешь все возможные дополнительные вопросы, представляешь, как грациозно ты на них отвечаешь по уже заранее подготовленному для этого слайду, на котором графики эффективности, экономии, производительности бьют все мыслимые и немыслимые потолки.
Ошибки, вызванные человеческим фактором, исключены. Продажи идут в горы. Организация купается в сэкономленном ФОТ, а очередь покупателей такая, что первое открытие Макдональдса в Москве (1990 г.) нервно покуривает в сторонке.
Залпы фейерверков, тождественная музыка, большой фирменный торт и….отказ!
Поздравляю! Тобою допущена одна, или сразу несколько ошибок. Давай разберем подробнее.
Не просчитана эффективность или она несоизмерима с затратами на реализацию
Если эффективность проекта несоизмерима с затратами на его реализацию – идея провальная. Этот пункт необходимо просчитать сразу, он должен явно отображать эффективность с соотношением к затратам на реализацию.
Методы расчета эффективности зависят от проекта и могут отображать:
- экономию по ФОТ и прочим затратам в месяц, год и т.д. (данный пункт появляется при сокращении затрачиваемых ресурсов на функционирование какого-либо процесса, при сокращении доли претензионных клиентов и т.д.);
- увеличение объема продаж (данный пункт уместен в проектах в области автоматизации обработки коммерческих предложений, влияния на объем отмененных заказов или возвратов, проектов в области самообслуживания, рекламы и проч.);
- увеличение лояльности и удовлетворенности клиентов и сотрудников (проекты в области послепродажного сервиса, повышения качества продукции и услуг, в области адаптации и обучения сотрудников и т.д.);
- и многое, многое другое..
Эффективность должна стать в вашей презентации самым крупным блоком с самыми большими цифрами на самом красивом слайде – этому, при ознакомлении с проектом, будет уделено огромное внимание (иногда даже больше, чем самой идее).
Рядом с эффективностью должны отображаться затраты на реализацию:
стоимость программных обеспечений;
наличие и стоимость лицензий;
затраты ФОТ на реализацию и поддержку;
- затраты ФОТ при увеличении ресурсов, необходимых для функционирования смежных процессов (если такое предполагается);
и многое, многое другое.
При расчете этих двух значений желательно быть предельно честным, особенно с самим собой.
Куда проще отказаться от реализации проекта из-за несоизмеримых затрат, чем обосновывать отсутствие выгоды уже по факту его реализации.
Не просчитаны риски и не проработаны инструменты их предотвращения
Давай представим ситуацию:
Ты катаешься с приятелем на катере посреди моря, плавать из вас ни кто не умеет.
Вдруг, отвлекшись от какого-то разговора, приятель тебе сообщает: «Тут можно ходить по воде! Попробуй!».
Какие будут твои мысли? Достаточно ли будет тебе этих слов, чтобы поверить ему и спуститься на воду? Наверняка у тебя будет много вопросов, в том числе относительно его адекватности.
В бизнесе ситуация обстоит абсолютно также. Как бы сильно не сверкали у нас глаза при презентации очередной идеи, мы должны предоставить бизнесу гарантии, что она безопасна (а заодно и убедиться в этом самим).
Наиболее часто необходимость просчета рисков связана с автоматизацией процессов, т.к.:
решение по тому или иному действию машина принимает автоматически за долю секунды и часто его невозможно отменить;
алгоритмы принятия решения часто сложные, основываются на множестве данных, в постоянстве и корректности которых не всегда присутствует уверенность;
как бы подробно не прописывался алгоритм и как бы тщательно не проводилось его моделирование, работа в реальных условиях может несколько отличаться и результат может быть не всегда прогнозируемым;
- процесс принятия решения может быть изучен не в полном объеме и автоматический алгоритм может не учитывать редкие кейсы.
Самым оптимальным методом предотвращения рисков при оптимизации является временный тестовый запуск, когда принятое автоматически решение либо согласовывается живым сотрудником, либо принимается фоново, не влияя на текущий процесс. Т.е. сотрудник работает в прежнем режиме, вручную принимает решения. Система работает фоном и принимает свои, но ни каких действий не производит.
По результату некоторого времени их «совместной» работы снимается аналитика и просматривается разница в принятых решениях сотрудником и системой. Если она отсутствует – алгоритм проработан идеально. Если есть разница – выясняем причину.
Нередко причиной расхождений является и ошибка сотрудника, поэтому не всегда несоответствие будет являться плохим сигналом.
Если находим ошибку в алгоритме – дорабатываем и заново тестируем до тех пор, пока ошибки будут отсутствовать.
Как только мы будем иметь на руках большую статистику, где 100% автоматических решений принято верно, вероятность получения отказа в запуске близится к нулю.
Более того, такой статистикой мы можем показать и процент ошибок пользователей, которые может предотвратить автоматизированный алгоритм.
При внедрении такого алгоритма можно предусмотреть и второй этап – возможность настройки алгоритмов (или их частей) самостоятельно пользователем (без привлечения разработчиков). Можно даже предусмотреть «рубильник», позволяющий оперативно отключить всю автоматизацию и вернуться к прежней ручной работе.
Основное правило, к которому необходимо придерживаться, заключается в сохранении некоторой тайны вокруг этих инструментов настройки и отключения – чем меньше людей о них знают, тем меньше у них чешутся руки что-то настроить или отключить.
Выбран не тот согласующий
Если проект имеет бешеную эффективность; ни как не ухудшает, а лишь улучшает качество конечного продукта; предусмотрены все возможные инструменты контроля; предусмотрено несколько этапов внедрения, по результату которых все риски будут исключены, но по проекту все равно получен отказ, то этот пункт ваш.
За исключение случаев, когда компания не располагает ресурсами, необходимыми для запуска вашей идеи.
В данном случае проект необходимо постараться удешевить (придумать, как реализовать его иначе с применением имеющихся ресурсов)
Когда дело касается оптимизации и автоматизации в теории, то большая часть игроков в бизнесе будет довольно поддакивать, подчеркивать важность такой активности и даже озвучивать готовность помогать.
Когда дело касается практики, ситуация меняется.
Предположим, ты пришел с идеей автоматизации к руководителю отдела, где собираешься этот проект запустить.
У тебя наготове миллион «за» и даже увесистая аналитика, убивающее любое «против». Проект имеет очевидные плюсы и оставить его без внимания кажется, как минимум, глупым.
Но давай представим себя тем самым руководителем и заодно примем решение о запуске проекта от его лица.
Вот, что мы имеем:
- все лавры от реализации проекта достанутся не ему, он же будем числиться только в исполнителях;
- любая автоматизация сокращает объем ручной работы, снижает нагрузку и, в зависимости от масштаба проекта, приводит к сокращению штата;
- автоматизированные алгоритмы выдирают процесс из под нашего контроля – мы больше не сможем вклиниться «здесь и сейчас», мы больше не сможем сглаживать несовершенство процессов руками, мы больше не сможем «натянуть» процесс до временного совершенства в случае проверки со стороны руководства (и прочие внутренние страхи неуверенного в своих процессах руководителя);
любая автоматизация, чаще всего, приводит к тотальному анализу всех ступеней процесса, появляются горы аналитики и все его прошлые недоработки станут очень заметны (естественно, его за это не похвалят);
- если автоматизация частичная, то тотальному анализу может подвергнуться оставшийся ручной функционал, в совершенстве которого руководитель тоже не уверен.
И, главное, большая часть руководителей живет с уверенностью, что автоматизация=сокращение штата, а сокращение штата=сокращение его зарплаты или вовсе увольнение.
А что? Нагрузка упала, штата у тебя нет, работа отдела выполняется без твоего участия. Пока.
Есть еще один формат руководителей – в их мотивацию включен показатель eNPS или процент текучки. Такие руководители, вместо твоих доводов и аналитики, представляют отрицательные результаты опроса удовлетворённости сотрудников, которых придется уволить, и сотрудников из смежных отделов, которые посмотрят на волну увольнений и потеряют уверенность в завтрашнем дне (и не дай бог начнут еще какую-то забастовку.. уф). Подсчитывают потери в премии и.. отказывают, т.к. твой успешный успех в их мотивацию не входит.
Что делать в данном случае? - все зависит от целей.
Если твоя цель развиваться в области оптимизации бизнес-процессов и иметь крутые кейсы в портфолио – читай дальше. Если нет, то зачем ты столько времени убил на эту статью?
Для выхода из данной ситуации я вижу два способа – один лояльный, второй хитрый.
Лояльный способ заключается в поиске компромиссов. Уточняем риски, которые видит руководитель, и проводим работу по их предотвращению.
Можно применить забавный лайфхак: преподнеси идею не как проект, возникший из не откуда, а как решение какой-либо проблемы (предварительно стоит продумать, какую проблему твой проект решает). Т.е. на согласование приноси не целую презентацию, а "решение", урезанное до основных, неочевидных пунктов.
Еще круче - упомянуть о имеющимся решении тогда, когда руководитель в очередной раз упомянет одну из проблем, которую закрывает наш проект.
При озвучивании решения предложи вместе его доработать.
Когда последний самостоятельно придумает очевидные вещи, которые тобою уже придуманы, он перестанет чувствовать себя жертвой эпохи оптимизации, перестанет сопротивляться и включится в проект.
Но иногда все риски таких руководителей сводятся к банальному «не хочу, не буду». Тогда подключаем тяжелую артиллерию.
Хитрый способ заключается в полном искажении сути и этапов проекта и применим, когда первые два способа не сработали.
Теперь ты:
- не автоматизируешь работу, а повышаешь ее эффективность;
- не разрабатываешь алгоритмы автоматизации, а стандартизируешь работу и уменьшаешь ошибки;
- внедряешь изменения не с целью предварительной подготовки к автоматизации, а с целью полного анализа вариативности и эффективности процессов;
- разрабатываешь не автоматические алгоритмы принятия решений, а подсказки по верному решению для сотрудников;
- не внедряешь элементы автоматизации, а высвобождаешь ресурсы сотрудников для решения более важных вопросов.
В конечном итоге, когда все будет готово, останется сделать "еле слышный щелчок", чтобы система начала выполнять всю работу автоматически.
Самое забавное, что уже к этому моменту вся автоматизация будет полностью отлажена, каждый ее этап согласован, протестирован и даже запущен.
Данный метод противопоказан, если твои идеи противоречат видению твоего заказчика.
На этом все :)
Перед подготовкой презентации проекта проследи, чтобы в ней было мало текста, больше простых графиков и цифр, доказывающих его эффективность.
Ответ на много проще. Фанатиков ни кто не любит.
И если Вы так как, описано в статье будете презентовать свой проект, Вас зарубят с вероятность 95 процентов. Даже если буду уверенны, что вероятность успеха велика.
В 5 процентов можно будет попасть, если предложите его в нужное время, ну там показать в отчёте, попилить денег и прочие причины не имеющие к проекту прямого отношения.
Почему так.
Тот кто уверен в своём проекте на 100% и яростно доказывает его успех, зачастую плохо управляем и будет делать все, что бы доказать свою правоту. А это не всегда надо.
Идея идти к руководству на 2-3 ступени выше имеет тот же процент успеха. Там конечно тебя внимательно выслушают и поблагодарят. Но в любом случае позвонят в низ и узнают про Вас. А скачки через голову, не кто не любит. Так, что результат немного предсказуем.
Что делать.
Утихомирить первые эмоции. Все максимально упростить. Преподносит проект, не как панацею, а как вариант. Отставить, несколько очевидных пунктов, в проекте которые начальник добавить сам. Тем самым показав, что он тоже участник проекта и его перспективы быть замеченным начальником выше.
Вообщем быть, чуть хитрее)
Тут я с вами соглашусь.
Решил скорректировать пункт, убрав советы про токсичное поведение 😅
Совсем забыл о таком инструменте, т к смотрел на вопрос немного с другой стороны (когда оптимизатор не подконтролен подобному роду руководителям, а находится немного в стороне, между собственником и it-департаментом )