- Выгода: увеличение потенциала адаптации системы, увеличение лояльности кадров
- Цена внедрения: очень контекстуально-опосредована
- Риски сверху: вероятность неприятия руководством
- Риски снизу: нет
Процесс производства может просто работать, а может постоянно улучшаться, увеличивая эффективность.
Пример консервативного процесса — скрам, в котором у скрам-мастера есть прямая обязанность следить за тем, чтобы процесс не менялся:
Scrum master serves the team by:
...
- Ensuring that all Scrum events take place and are positive, productive, and kept within the
timebox.
Scrum master serves the organisation by:
...
- Planning and advising Scrum implementations within the organization;
Кажется очевидным, что консервативный процесс производства не позволяет быстро адаптироваться к постоянным изменениям внешней среды, в которой функционирует бизнес.
Все, должно быть, помнят пример Nokia с идеальным скрамом. Помог ли столь консервативный процесс компании отвечать на изменения рынка?
Конечно, одним лишь адаптивным процессом утопающий бизнес не спасти, но если в культуре компании — принятие изменчивости мира и готовность реагировать на изменения, то вероятность, что компания сможет адекватно подстроиться к среде, выше.
Адаптивный процесс по определению должен меняться в ответ на изменения среды.
Например, если культура труда выходит на уровень постоянного рационализованного улучшения и в результате исследования делается вывод, что регулярные встречи для коллективного анализа (по типу ретроспектив) больше не нужны, в адаптивном процессе производства такие встречи будут отменены.
Для того чтобы процесс стал адаптивным, нужно в первую очередь непрерывно получать информацию о его функционировании в условиях постоянных внешних изменений. Нужно понимать, что идет не так или идет так, но можно лучше.
Источниками любой информации являются люди.
Соответственно, чтобы понимать, что следует изменить в процессе производства, нужно получать информацию для анализа от всех участников процесса. А для этого необходимо, чтобы люди не боялись, хотели и умели поставлять информацию.
Также, конечно, нужно с этой информацией что-то делать, но пока говорим лишь о принципиальной необходимости поступления информации.
Человек, ощущающий вину за какой-то поступок на работе, будет опасаться совершать поступки вообще.
Как только руководитель начинает провоцировать в сотрудниках чувство вины или страха, в группе начинают происходить негативные социальные динамики — другие сотрудники неизбежно будут либо считать себя тоже «в зоне риска», либо предавать «виноватого» сотрудника остракизму.
Испытанное однажды чувство вины или страха приводит к тому, что человек избегает выполнения определенных действий.
Рассмотрим случай: сотрудник понял, что при проектировании системы он допустил досадную оплошность, в результате чего придется переписывать значительную часть этой системы.
Сотрудник, будучи ответственным человеком, считающим, что информацию о проблеме нужно сообщать, как только проблема обнаружена, оповестил руководителя о ситуации.
Руководитель отругал сотрудника за допущенную ошибку.
Вероятнее всего, после такого случая сотрудник трижды подумает, прежде чем снова принесет руководителю подобную информацию. Как следствие — сообщения о проблемах, скорее, будут «заметаться под ковер», что приведет к рассинхронизации между знаниями руководства о системе и самой системой.
Гораздо более перспективна ситуация, в которой вместо того, чтобы ругать сотрудника за ошибку, руководитель благодарит его за сообщение о проблеме. Ведь оно, с точки зрения грамотного руководителя, несет пользу: чем раньше информация будет получена, тем дешевле ее обработать.
Выше мы поговорили об атмосфере в коллективе, которая должна способствовать тому, чтобы люди не скрывали проблемы.
Также мы знаем, что информация о проблемах необходима для того, чтобы процесс можно было адаптировать.
Теперь нужно разобраться, кто и как адаптирует процесс.
Начинается все с того, что полученную информацию нужно обработать. Как минимум, нужно понять, насколько проблема — проблема. Нужно определить, есть ли экономический или какой-то иной вред, как именно использовать эту информацию.
Например, сотрудник сообщил, что на тестовом стенде набор автоматических тестов раньше выполнялся за 10 минут, а теперь занимает полчаса.
Полезна ли эта информация? Безусловно, полезна. Нужно ли что-то с ней делать? Безусловно, нужно.
Например, надо выяснить, почему изменилось время, есть ли вероятность, что ситуация ухудшится. Также следует разобраться, страдает ли общий процесс производства от увеличения времени выполнения этого набора тестов. И потом найти способ, каким эту проблему можно решить.
В общем, необходимо понять причины появления проблемы, ее масштаб и цену решения.
Кто этот процесс будет осуществлять? Вроде как раз руководитель и должен, правда?
Но сразу появляется вопрос — а кто больше разбирается в технической составляющей проблемы, у кого полнее информация о ней?
Думается, что именно у разработчика, который эту проблему и обнаружил.
Тогда кажется логичным и правильным помочь разработчику выявить причину проблемы, если он еще не умеет этого делать сам.
Далее. Раз сотрудник вполне способен установить причину проблемы, то, может, он и варианты решения в состоянии продумать?
Стало быть, сотрудник может не просто сообщать о проблеме, а приносить результат анализа сложившейся ситуации и свои предложения о том, как проблему можно решить. Возможно, даже несколько вариантов решения с указанием цены и выгоды каждого.
Но мы рассмотрели пример проблемы, в которой сотрудник и правда разбирается, — проблемы технической.
Что же делать, когда проблема скорее процессная? Или непонятно, процессная она или техническая? Как вообще определить, процессная проблема или техническая, и нужно ли разделять эти типы проблем?
Кажется, что особого смысла в таком разделении нет, есть лишь аспект умений и полномочий в решении проблемы:
- если проблему может полностью решить программист, пусть и отвечает за ее решение;
- если проблему может полностью решить лишь руководитель, пусть он отвечает за ее решение.
И получается, логично и продуктивно, если руководитель будет «обнажать инструментарий», обучая сотрудников, в частности, и анализу эффективности процессов. В компании будет правильным установить, что любое процессное или технологическое изменение должно проходить процедуру оценки эффективности, лишь тогда оно оправданно.
Добро пожаловать в мир ТЭО.
В советском союзе было общество ВОИЗ, занимающееся поиском тех параметров производства, которые можно рационализировать.
На отдельных предприятиях функционировали кружки качества — группы сотрудников, озадаченные обнаружением мест потенциального улучшения процесса. Потом подобные кружки качества стали создавать в Японии.
Советую попробовать открыть у себя в компании такой кружок качества и посмотреть, какие предложения об изменениях начнут приносить участники кружка.
В результате формируется культура постоянного накопления знаний, в которой поощряется доведение до руководителя информации, помогающей улучшать процесс производства.