Совершенствование системы

Давайте поговорим о более сложных ошибках в бизнесе. 

Начнем с небольшой зарисовки: 

В компаний на объекте сломался прибор (в принципе не важно какой). 

Каковы действия компании далее? 

Типовые действия которые наблюдал автор:

1. Прибор отправили в ремонтный отдел. 

2. В ремонтном отделе прибор разобрали и выяснил что сломалось.

3. Выяснили три наиболее вероятные причины поломки. 

4. Далее заказали сломанную деталь, заменили и отправили прибор обратно в работу. 

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

И каждый раз их чинили и возвращали обратном. 

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

Думаю что уважаемый читатель легко вспомнит такие ситуаций в своей практике. 

Это я называю отсутствующей в компании функцией улучшения (что является очень типовой ошибкой 👾). 

Которая должна быть на постоянной основе в любой компании. 

Раскроем что здесь имеется ввиду:

1. Помолка чего-либо (процесса или устройства) это всегда как не трудно догадаться потеря ресурсов (в широком смысле) на его ремонт. Поэтому компании на базовом уровне ВЫГОДНО снизить количество поломок. 

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

Например люди испортили прибор потому что не прочитали инструкцию, прибор привозят на ремонт, ремонтируют и отправляют обратно. Вопрос к вам, как скоро ситуация повторится? 

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

И через некоторое время проблема перестает восприниматься как проблема, а просто превращается в рабочий фон = так бывает с этим ничего не поделаешь => ЭТО НОРМА (это самое плохое). То есть люди просто перестают видеть проблемы.

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

Что с этим можно сделать?

Я бы назвал этот подход разработка ИМК (информационной модели компании). 

Что он подразумевает:

1. Создание первой версии модели (первая модель это сбор из лучших практик которые существуют на данный момент) = 

    1. схемы процесса/ов в нотации которая вам больше нравиться. В том числе реализации проекта. 

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

    3. Для каждого шага процесса (или подпроцесса) создание:

        1. Инструкций и руководств.  

        2. Чек-листов и списков ошибок и требований. 

        3.  Справочного каталога = набора полезных ссылок, литературы и пр. 

        4. Прошлого опыта = извлеченных уроков и справочника людей к которым можно обратиться (которые либо участвовали в прошлых аналогичных проектах, либо являются экспертами к которым уже обращались в прошлые разы).

2. Создание некоторого эталона к которому мы хотим прейти. 

3. Ведение явного списка того что нас не устраивает с текущей модели и что мы хотим исправить = таблички из статьи (Любимый прием российских менеджеров №1). Да ошибки которые весят нерешенными годами могут вызывать психическое беспокойство и от может хотеться избавиться представив что их нет. Но делать так я вам настоятельно не рекомендую. 

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

Но к сожалению просто создать модель мало надо еще и заставить людей с ней работать. 

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

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

Еще один способ это встраивание ссылок на те или иные инструкции, разделы модели, чек-листы и пр. в соответствующие шаблоны (шаблоны задач, отчетов, журналов и пр.). 

Все этим приемы направленны на то чтобы заставить сотрудников использовать модель. 

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

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

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

Смертельный грех 💀 здесь это жертвование данной функцией ради скорости. 

Визуально это можно представить следующим образом.

Более подробно и с примерами вы можете прочесть об этом в моей книге (там этому посвящена отдельная глава). 

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

Далее соответственно необходимо:

- Применять модель. 

- Фиксировать глюки и несоответствия модель vs реальность vs эталон. Фиксировать новые знания которых еще нет в модели. Об этом у меня будет или уже есть (в зависимости от того когда вы это читаете отдельные статьи). 

- Изменять модель на основе полученной информации. Условно создавать новую версию модели. 

Мини вывод:

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

В качестве упражнения можете ответить на несколько простых вопросов: 

1. Есть ли у Вас эталон для работ в компании?

2. Известно ли в вашей компании обо всех глюках/проблема которые были? Где хранятся данные о них

3. Что сделано для того чтобы они не повторялись?

4. Как часто меняется эталон?