Спринт-история о том, как мы не стали писать регламент
При обсуждении факапов прошлого, пожаров настоящего, планов будущего, всегда находится тот, кто вывешивает на доску проблему "недостаточно налажены бизнес процессы" Спасибо, кэп! Но как их наладишь, когда их так много, еще и все меняется постоянно, и кони бегут, и избы горят.
И вот во время обсуждения лавины факапов по клиентским заказам, один наш любимый душнила написал: "Отсутствует регламент принятия клиентской заявки". И в целом, он даже был готов взяться за этот эпохальный текст (поверьте, если бы взялся он, то текст точно вышел бы эпохальный).
Но! Мы же как-то принимаем клиентские заказы и как-то даже попадаем результатом в требования, а значит какой-то регламент уже есть. И он даже как-то исполняется. Даже если он не зафиксирован на бумаге, даже если он не прописан в должностных инструкциях. Плюс у нас были огромные сомнения, что хотя бы кто-то сможет осилить до конца новый душный регламент. А на то, что его запомнят и будут исполнять, было еще меньше надежды.
Но мы же не зря столько лет изучаем и практикуем наследие Голдратта (Теория Ограничений). Там есть ряд правил, которые нужно соблюсти, чтобы формулировка проблемы стала формулировкой настоящей проблемы. Мы решили, что прежде чем работать над регламентом, стоит поработать над формулировкой проблемы.
Для начала мы избавились от претензии ко всему процессу принятия заявки и попытались понять, почему мы вообще к нему пристали. Ответ прост: потому что клиенты на позднем этапе требуют внести изменения в заказ. Но это тоже не тянуло на хорошую формулировку. Вряд ли мы что-то сможем сделать, чтобы клиенты перестали требовать (хотя можно закрыться, точно перестанут). А еще говорят, что начинать надо с себя. В итоге мы пришли к такой формулировке "Выполненный заказ не соответствует ожиданиям клиента".
Для нас такая проблема прозвучала даже воодушевляюще. Ожидания! Это же то с чем надо работать! Работать с ожиданиям звучит как более перспективное и интересное направление, чем работать с регламентом принятия заявки. И тогда в случае успеха мы не просто уменьшим количество переделок, мы еще и получим куда более удовлетворенного клиента.
Я обожаю истории и аллегории. Поэтому напоследок анекдот)
-Золотая рыбка, сделай так, чтобы у меня все было!
-Поздравляю! У тебя уже все было!
Будьте аккуратны в формулировке желаний и проблем❤
А вот канал с уведомлением о новых заметках и короткими заметками, которых здесь не будет https://t.me/AABryzgalova
Прикольная мысль. Сколько раз писал регламенты, очень быстро они устаревают и, в результате, перестают работать. Теперь буду правильно формулировать проблемы)
:) а иногда и не начинают работать)
С одной стороны - факт, но с другой "бескультурие" бизнес процессов создает огромную сложность для расширения команды: новым сотрудникам будет абсолютно непонятна логика, по которой текущие лидеры продуктовых решения все делают) возможно я не прав, и готов выслушать критику, но мой опыт показывает, что регламенты в корпорациях дают больше профита (даже не смотря на бюрократию), чем их отсутствие
Спасибо за классный комментарий! Если мы будем сравнивать две крайности, то расширение в большой системе в среде «бескультурия» действительно может
проиграть «бюрократии», но здесь немножко не об этом.
Давайте сравним в вашем контексте две проблемы: «бескультурные бизнес-процессы» и «скорость расширения команды ниже необходимой». Это очень разные проблемы с разными путями решения. Разбираясь со второй, мы должны подумать откуда у нас необходимая скорость (допустим там действительно без вариантов). Тогда следующий вопрос, что расширение это и поиск, и адаптация. Допустим с поиском у нас все хорошо. Тогда проблема уже может звучать ближе к «новые сотрудники включаются в работу дольше n месяцев». Это уже намного больше похоже на важную проблему, решение которой даст заметные результаты.
Сравним ещё раз⚖️
«У нас мутные бп» и «новые сотрудники включаются в работу дольше n месяцев».
Регламенты сами по себе ни плохи, ни хороши. В определенных ситуациях это классный инструмент, который трудно чем-то заменить. Но плохо, если в качестве корневой причины всех своих бед, мы выбираем «кривые регламенты». Такая формулировка проблемы сужает варианты решений до «прописать регламенты» (в лучшем случае ещё не забудем про «внедрить»), а результат такого решения скорее всего нельзя будет назвать прорывным.
Есть контакт?
Двоякое отношение к этой истории. С одной стороны: плохо, что не применили регламент там, где он нужен; с другой - хорошо, что не стали решать проблему с помощью неподходящих инструментами :)
Регламенты, как вообще любой инструмент, имеет ограниченную область применения. И по cynefin он соответствует простым (очевидным) средам. Мне видится, что принятие клиентской заявки попадает в область простых сред, значит регламент там имеет все шансы на успех. Он позволит: снизить требования к кандидатам при найме; сократить время обучения новых работников; обеспечить контроль; дать инструменты для стимуляции и всё в таком духе. Это же хорошо?
Регламент не решает проблему несоответствия ожиданиям клиента, но ряд проблем управления устоявшимся процессом - вполне.
Проблема, которая нас беспокоила, звучит так:"клиенты на позднем этапе требуют внести изменения в заказ" (она указана в тексте). Чтобы разобраться с ней, нужно для начала разобраться, какие изменения они вносят, а точнее какие являются для нас проблемой. Оказалось, что часть изменений можно обсудить на этапе приема заявки, какие-то уточнить перед запуском заказа в производство и так далее. Решением проблемы стала превентивная работа с конкретными ожиданиями клиента на разных этапах выполнения заказа. "Описать регламент приема заявки" - вообще никак не решил бы нашу проблему.
После того, как мы разобрались, мы изменили процесс приема заявки, но не только его. Писать регламент по этому поводу или нет - зависит от компании. Для каких-то компаний в схожей ситуации (большой штат, регулярное появление новых сотрудников), вероятно нужно будет написать регламент. Но не потому что "он не написан", а потому что "мы забываем спросить то-то и то-то". И в некоторых случаях (например, в нашем) в качестве регламента будет чек-лист.
"Снизить требования к кандидатам при найме; сократить время обучения новых работников; обеспечить контроль; дать инструменты для стимуляции и всё в таком духе", "ряд проблем управления устоявшимся процессом" - за каждым из этих словосочетаний для каждой компании стоят разные подробности. И разбираться нужно с этими подробностями, в том порядке, который даст наиболее быстрые результаты. И это всегда не просто "написать регламент". Регламент еще надо внедрить, он должен быть понятным, его нужно постоянно обновлять.
Сейчас пишу статью с еще одним примером про регламент как раз по поводу обучения. Выложу - напишу ссылку.
Разве принятие заявки - процесс, а не часть сквозного процесса "выполнение заказа"?