Оптимизация бизнеса для чайников. Почему смелые проекты часто не находят отклик?

Думаю, многие из вас знают то прекрасное чувство, когда в твоей голове зародился мега-проект с мега-эффективностью.

Ты уже представляешь, как после его запуска по офису ходят роботы, всю работу выполняет искусственный интеллект, сам офис напоминает больше серверную, по центру которой висит твоя фотография с надписью «мега-оптимизатор».

Ты все детальнее и детальнее прорисовываешь свою идею в голове и понимаешь, что для ее реализации нет абсолютно ни каких преград.

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

Ошибки, вызванные человеческим фактором, исключены. Продажи идут в горы. Организация купается в сэкономленном ФОТ, а очередь покупателей такая, что первое открытие Макдональдса в Москве (1990 г.) нервно покуривает в сторонке.

Залпы фейерверков, тождественная музыка, большой фирменный торт и….отказ!

Поздравляю! Тобою допущена одна, или сразу несколько ошибок. Давай разберем подробнее.

Если эффективность проекта несоизмерима с затратами на его реализацию – идея провальная. Этот пункт необходимо просчитать сразу, он должен явно отображать эффективность с соотношением к затратам на реализацию.

Методы расчета эффективности зависят от проекта и могут отображать:

• экономию по ФОТ и прочим затратам в месяц, год и т.д. (данный пункт появляется при сокращении затрачиваемых ресурсов на функционирование какого-либо процесса, при сокращении доли претензионных клиентов и т.д.);
• увеличение объема продаж (данный пункт уместен в проектах в области автоматизации обработки коммерческих предложений, влияния на объем отмененных заказов или возвратов, проектов в области самообслуживания, рекламы и проч.);
  
• увеличение лояльности и удовлетворенности клиентов и сотрудников (проекты в области послепродажного сервиса, повышения качества продукции и услуг, в области адаптации и обучения сотрудников и т.д.);
  
• и многое, многое другое..
  

Рядом с эффективностью должны отображаться затраты на реализацию:

• стоимость программных обеспечений;

• наличие и стоимость лицензий;

• затраты ФОТ на реализацию и поддержку;

• затраты ФОТ при увеличении ресурсов, необходимых для функционирования смежных процессов (если такое предполагается);

• и многое, многое другое.

Давай представим ситуацию:

Какие будут твои мысли? Достаточно ли будет тебе этих слов, чтобы поверить ему и спуститься на воду? Наверняка у тебя будет много вопросов, в том числе относительно его адекватности.

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

Наиболее часто необходимость просчета рисков связана с автоматизацией процессов, т.к.:

• решение по тому или иному действию машина принимает автоматически за долю секунды и часто его невозможно отменить;

• алгоритмы принятия решения часто сложные, основываются на множестве данных, в постоянстве и корректности которых не всегда присутствует уверенность;

• как бы подробно не прописывался алгоритм и как бы тщательно не проводилось его моделирование, работа в реальных условиях может несколько отличаться и результат может быть не всегда прогнозируемым;

• процесс принятия решения может быть изучен не в полном объеме и автоматический алгоритм может не учитывать редкие кейсы.

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

По результату некоторого времени их «совместной» работы снимается аналитика и просматривается разница в принятых решениях сотрудником и системой. Если она отсутствует – алгоритм проработан идеально. Если есть разница – выясняем причину.

Если находим ошибку в алгоритме – дорабатываем и заново тестируем до тех пор, пока ошибки будут отсутствовать.

Как только мы будем иметь на руках большую статистику, где 100% автоматических решений принято верно, вероятность получения отказа в запуске близится к нулю.

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

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

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

Когда дело касается практики, ситуация меняется.

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

У тебя наготове миллион «за» и даже увесистая аналитика, убивающее любое «против». Проект имеет очевидные плюсы и оставить его без внимания кажется, как минимум, глупым.

Но давай представим себя тем самым руководителем и заодно примем решение о запуске проекта от его лица.

Вот, что мы имеем:

• все лавры от реализации проекта достанутся не ему, он же будем числиться только в исполнителях;
• любая автоматизация сокращает объем ручной работы, снижает нагрузку и, в зависимости от масштаба проекта, приводит к сокращению штата;
  
• автоматизированные алгоритмы выдирают процесс из под нашего контроля – мы больше не сможем вклиниться «здесь и сейчас», мы больше не сможем сглаживать несовершенство процессов руками, мы больше не сможем «натянуть» процесс до временного совершенства в случае проверки со стороны руководства (и прочие внутренние страхи неуверенного в своих процессах руководителя);
  

• любая автоматизация, чаще всего, приводит к тотальному анализу всех ступеней процесса, появляются горы аналитики и все его прошлые недоработки станут очень заметны (естественно, его за это не похвалят);

• если автоматизация частичная, то тотальному анализу может подвергнуться оставшийся ручной функционал, в совершенстве которого руководитель тоже не уверен.

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

Есть еще один формат руководителей – в их мотивацию включен показатель eNPS или процент текучки. Такие руководители, вместо твоих доводов и аналитики, представляют отрицательные результаты опроса удовлетворённости сотрудников, которых придется уволить, и сотрудников из смежных отделов, которые посмотрят на волну увольнений и потеряют уверенность в завтрашнем дне (и не дай бог начнут еще какую-то забастовку.. уф). Подсчитывают потери в премии и.. отказывают, т.к. твой успешный успех в их мотивацию не входит.

Что делать в данном случае? - все зависит от целей.

Для выхода из данной ситуации я вижу два способа – один лояльный, второй хитрый.

Лояльный способ заключается в поиске компромиссов. Уточняем риски, которые видит руководитель, и проводим работу по их предотвращению.

Можно применить забавный лайфхак: преподнеси идею не как проект, возникший из не откуда, а как решение какой-либо проблемы (предварительно стоит продумать, какую проблему твой проект решает). Т.е. на согласование приноси не целую презентацию, а "решение", урезанное до основных, неочевидных пунктов.

При озвучивании решения предложи вместе его доработать.

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

Но иногда все риски таких руководителей сводятся к банальному «не хочу, не буду». Тогда подключаем тяжелую артиллерию.

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

Теперь ты:

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

В конечном итоге, когда все будет готово, останется сделать "еле слышный щелчок", чтобы система начала выполнять всю работу автоматически.

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

На этом все :)

Перед подготовкой презентации проекта проследи, чтобы в ней было мало текста, больше простых графиков и цифр, доказывающих его эффективность.