Система регламентов: Скрытая угроза. Как продлить жизнь системе регламентов, и чем опасны неактуальные документы?

«Стабильность — иллюзия. То есть, стабильности вообще не бывает. В любом процессе всегда есть или развитие, или деградация»

Макс Фрай

кому: собственникам, топ-менеджерам, руководителям

Сценарии использования статьи: кому полезна и для чего

Собственникам —осознать важность развития системы регламентов и организации процесса сбора идей.

Топ-менеджерам — научиться собирать проблемы и идеи подчинённых, классифицировать и обрабатывать их

Руководителям — понять, какие идеи нужны для развития процессов, как реализовывать их и решать возникающие проблемы.

Когда умирает человек? Мы знаем, что такое смерть с физиологической точки зрения. Но я считаю, что человек умирает тогда, когда перестаёт развиваться, в том числе в профессиональном плане. В стагнации человек просто доживает свою жизнь.

С системой регламентов происходит то же: она умирает в тот момент, когда её перестают развивать. Поэтому во многих компаниях система регламентов «умирает при рождении».

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

Опасность неактуальных регламентов

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

Неактуальные регламенты не только перестают приносить пользу, они начинают вредить деятельности компании

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

Если же специалист видит, что документ утратил актуальность, то он всё равно не будет его соблюдать, а попутно утратит доверие ко всей системе регламентов. Так зачем нужна система регламентов, которая существует лишь «для галочки»?

Как развивать систему регламентов?

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

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

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

Кто должен оптимизировать процессы?

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

Пример №1: Изменение формата работы

Один клиент работал с нами в формате оплаты по часам. Бывали случаи, когда мы не отрабатывали оплаченное время из-за недостаточного объёма задач от клиента, болезни наших сотрудников или других внутренних процессов. По итогам месяца мы фактически возвращали клиенту часть денег. Это нонсенс на рынке.

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

Что мы могли сделать? Мы могли поставить его перед фактом, и стоять на том, что у нас такой процесс, «не нравится — не работайте». Во многих компаниях, кстати, так и говорят, рискуя потерять клиента.

Мы пошли по другому пути: создали копию процесса и изменили её для этого клиента. Внутри компании мы установили лимиты часов, за которые нам нельзя было выходить. Если мы что-то не дорабатывали, то могли без согласования перенести часы на следующий месяц или, наоборот, перекрыть следующим месяцем небольшие переработки.

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

Пример №2: Корректировка договора

Другой наш клиент не хотел согласовывать отчёты, ссылаясь на нехватку времени. Между тем пункт об обязательном согласовании отчётов был прописан в нашем договоре. Замкнутый круг.

В итоге мы снова пошли по пути оптимизации процесса. Мы создали новую копию процесса и изменили её. В данном случае просто зафиксировали в договоре, что факт отправки отчёта приравнивается к его согласованию. Если от клиента не поступило вопросов и замечаний в установленный срок, то отчёт считается согласованным.

Гибкость или педантичность?

Я привёл два примера, когда процесс не вписывался в регламент. Но таких случаев могут быть десятки, сотни, тысячи… Если вы один раз построили процесс и не изменяете его, то количество «исключений» будет расти как снежный ком, игнорировать их будет всё труднее. «Позиция страуса» вас точно не спасёт.

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

У Сбербанка долгое время существовал неудобный для клиентов процесс перевыпуска карты: если клиент получил карту в одном отделении, то перевыпустить её он мог только в том же отделении. И неважно, переехал ли человек в другой район, город или страну. Вариантов не было.

На это правило жаловались многие клиенты, а у кого была возможность — меняли банки. Трудно сказать, сколько клиентов Сбербанк потерял из-за своей «неповоротливости».

Если мы не развиваемся, то не просто стагнируем, а «летим в пропасть», отставая одновременно и от конкурентов, и от рынка

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

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

Как собирать проблемы и идеи?

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

Возникает вопрос: «Нужно ли собирать некритичные проблемы и идеи, которые не привели к негативным последствиям?» Я считаю, что нужно. Для их сбора можно определить отдельное место, куда руководитель процесса периодически будет заходить и изучать накопленные идеи по его процессу.

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

Раздел «to do» в регламенте

Первое время я делал в каждом регламенте раздел «to do», который служил для фиксации идей как страница для заметок. Но у этого способа был существенный недостаток: не все регламенты описывали один отдельный процесс.

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

«Ящик для идей»

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

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

Бывают срочные и важные идеи, которые ликвидируют пробелы в процессе, снижают убытки. Их нужно обсуждать и внедрять немедленно. Нельзя допустить, чтобы такие идеи пылились в ящике неделями. Тут метод сбора идей «в ящик» не подойдёт.

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

Канбан-доска

В программном исполнении Битрикс24 предлагает использовать Канбан-доску. Это может быть неплохим решением, потому что на доске можно разместить карточки разной срочности, плюс поставить соответствующие метки или скопировать ссылку на карточку и прислать напрямую владельцу процесса, чтобы тот обратил на неё внимание.

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

Классификация идей

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

Я бы разделили идеи на три основные группы:

1. Как сделать по-другому, более эффективно.
2. Как потратить меньше ресурсов.
3. Как принести большую пользу клиенту.

Также нужно разделять идеи и проблемы. Идеи направлены на оптимизацию процесса, а проблемы (риски) препятствуют выполнению процесса. Прежде чем реализовывать новые идеи, нужно устранить существующие проблемы, иначе результат оптимизации невозможно будет оценить.

Фильтрация и приоритеты

При использовании программного обеспечения, например, канбан-доски, карточки легко отфильтровать по тегам. Это удобно, когда владелец процесса решает провести ретроспективу. Анализируя идеи и риски, можно расставлять приоритеты. Понятно, что все идеи не могут и не будут реализованы одновременно, но они являются ресурсом для развития компании.

За идею, которая была внедрена и принесла компании деньги, её автор получает финансовое поощрение

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

Не все идеи могут и должны относиться к конкретному процессу, могут быть идеи по организации работы в целом. В компании должно работать правило: «За идею, которая была внедрена и принесла компании деньги, её автор получает финансовое поощрение».

Кто отвечает за сбор идей?

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

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

Обработка идей

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

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

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

Другой пример. Кто-то может внести предложение публиковать вакансии компании в общую ленту, чтобы коллеги, у которых есть подходящие кандидаты, могли их порекомендовать. Это уже не проект, достаточно обновить регламент HR-специалиста и написать, что одновременно с публикацией вакансии на hh.ru он должен публиковать краткую выдержку в новостной ленте.

Таким образом, чтобы сотрудники делились идеями, они должны видеть, что идеи обрабатываются. Это не значит, что все идеи должны внедряться. Можно оставить комментарий: «идея отложена на год» или «сейчас идея для нас неактуальна». Это тоже пример обратной связи. При этом стоит избегать стандартных отписок. Даже если идея не прошла, нужно объяснить причину.

Если ругать за плохие идеи, вскоре не будет никаких. Мы не можем заставить человека генерировать только хорошие идеи. Одна из задач руководителя — сделать так, чтобы человек реализовался в компании, но чтобы его реализация соответствовала целям компании.

Реализация идей

Как я отметил, многие идеи фактически являются процессами, поэтому и работать с ними нужно как с процессами. Нужно провести эксперимент, например, выпустить пробную партию, посмотреть, какой объём продаж был до и после эксперимента, не снизился ли он? Да, это сложно, но я не сторонник ведения бизнеса методом «игры в русскую рулетку».

Многие идеи фактически являются процессами, поэтому и работать с ними нужно как с процессами

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

Контроль за ходом работы с идеей

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

Когда мы закрываем идею как реализованную, нужно получить обратную связь от её автора. Он в данном случае играет роль фаната. У автора идеи нужно спросить, так ли он представлял себе реализацию? Какие недостатки и достоинства итоговой реализации он видит?

Конечно, с автором идеи лучше детально пообщаться ещё до начала работ, чтобы уже на финише не обнаружить, что идея была неправильно понята и, соответственно, неправильно реализована. При принятии решения о реализации идеи нужно оценить, как это повлияет на наши процессы, не навредит ли им.

Решение проблем в процессах

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

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

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

Изменение схемы процесса и регламента

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

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

Если меняется логика построения процесса, то сначала правильнее будет перестроить схему процесса, а уже потом вносить изменения в регламент, либо делать это параллельно. При этом старые версии схем нужно сохранять. Я рекомендую не исправлять схемы процессов, а создавать их новые версии: версия 1.0, версия 1.1, версия 1.2 и т. д.

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

Синхронизация регламентов и схем процесса

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

Если какой-то регламент в компании постоянно развивается и дорабатывается, может возникнуть проблема синхронизации текста регламента и схемы процесса

Я советую сначала дорабатывать регламент (все изменения можно будет посмотреть через историю изменений), а потом раз в месяц проводить ретроспективы и проверять, что нужно доработать на схеме процесса. Это не догма, нужно искать кратчайший путь к решению задачи. Но при такой схеме работы в период между ретроспективами регламент и схема могут расходиться.

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

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

На мой взгляд, штатный бизнес-аналитик нужен в компании с численностью от 30 человек, но всё зависит от специфики деятельности.

Информирование об изменениях

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

Эти комментарии потом тоже анализируются. Так мы решаем две основные задачи:

1. Развиваем систему регламентов: собираем идеи, возможности и риски.
2. Информируем об изменениях сотрудников, которые работают по регламентам.

Ретроспектива процессов и регламентов

Вместе с ретроспективой (ревизией) процесса нужно проводить ревизию его схемы. Иногда регламент становится слишком большим. Тогда можно уменьшить его объём за счёт выделения из него небольших отдельных подпроцессов.

Например, процесс собеседования в регламенте HR-менеджера по поиску сотрудников занимает 20 страниц. Значит, чтобы «облегчить» основной регламент, можно вынести описание процесса по проведению собеседования в отдельный документ и поставить в нём ссылку на «родительский» регламент. Главное — не забывать обновлять ссылки в других местах.

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

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

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

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

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

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

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

Мораль

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

Тренировка управленческой мышцы

Я рассказал о том, почему важно развивать систему регламентов и как собирать и обрабатывать идеи. Предлагаю ответить на несколько вопросов, чтобы закрепить пройденный материал:

1. Вспомните структуру системы регламентов, что нужно развивать в первую очередь, чтобы система регламентов развивалась?
2. Вспомните, бывали ли случаи, когда копия процесса не вписывалась в основной процесс? Как вы поступали в такой ситуации?
3. Нужно ли подстраивать свой процесс под запросы клиента или в данном случае гибкость — признак слабости?
4. Назовите несколько методов сбора идей? Какой из них вы используете сейчас или хотите внедрить? Почему?
5. У вас в компании есть регламент, который постоянно развивается и дорабатывается? К какой проблеме это может привести? Как снизить риски?