Оглавление

Предисловие

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

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

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

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

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

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

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

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

Итак, в чем же суть продвигаемого мною системного подхода?

Он построен на сочетании:

— Бережливого производства

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

— Проектного управления

Позволяет минимизировать риски и бюджет.

— Использования продуктового подхода

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

— Теории ограничений системы

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

— Внедрения изменений

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

— Управления коммуникациями между подразделениями

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

Вообще работать с ТОПами очень сложно. Как правило, это люди так называемого «Е-типа» по Адизесу: предприниматели, яркие и сильные личности, авторитарные, не терпящие мнения, отличного от своего.

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

От этого в управлении и есть такой принцип: централизация власти нужна на старте и при распаде системы, для развития же нужна децентрализация.

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

И теперь представьте, каково такой сильной личности научиться отстраняться от ручного управления?

— Использования цифровых технологий и данных для принятия решений

Этому разделу, по сути, была посвящена первая книга. Цифровая трансформация подразумевает активное использование цифровых инструментов и аналитики для минимизации рисков, создания новых продуктов.

— Практик регулярного менеджмента

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

— Работы со стратегией, организационной структурой и бизнес-процессами

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

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

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

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

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

Возможно ли освоить весь подход одному человеку? При должном упорстве и постоянстве в течение 10—15 лет — да. Разумеется, такого количества времени ни у кого нет, поэтому единственный путь — формировать команду с правильными компетенциями.

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

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

Глава 1. Организационная структура и бизнес-процессы

Начнем мы именно с организационной структуры и работы с бизнес-процессами. Если перевести на бытовой язык, то орг. структура — скелет компании, а описанные, отлаженные и эффективные бизнес-процессы — нервная система.

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

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

Четкая и визуализированная организационная структура является ОБЯЗАТЕЛЬНЫМ условием. В моей практике не было ни одного случая, чтобы компания работала слажено без описанной организационной структуры, доступной и понятной всем.

Чаще всего я наблюдаю следующее:

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

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

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

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

Однако описанные бизнес-процессы не заработают без четкой и понятной организационной структуры, ведь у вас не будет скелета.

Типы организационных структур

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

— линейная;

— функциональная,

— линейно-функциональная или линейно-штабная

— дивизиональная,

— рыночная,

— матричная

— продуктовая

Разберем каждую из них

Линейная

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

Плюсы:

— простота и скорость принятия управленческих решений;

— быстрая реакция на указания и распоряжения;

— ясное распределение обязанностей и ответственности;

— дисциплина.

Минусы:

— перегруженность руководителей;

— концентрация большого количества непрофильной работы на руководителях;

— слабые взаимосвязи между исполнителями;

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

Функциональная

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

Плюсы:

— узкая специализация направлений — повышение производительности и качества;

— четкое распределение ответственности;

— освобождение линейных руководителей от функций вне их компетенции;

— отсутствие дублирования функций (если выстроены бизнес-процессы).

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

Линейно-функциональная

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

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

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

Плюсы:

— узкая специализация направлений — повышение производительности и качества;

— простота и скорость принятия управленческих решений;

— быстрая реакция на указания и распоряжения;

— минимизация дублирования работ.

Недостатки:

— высокие, порой неоправданно, затраты на содержание административного персонала;

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

Дивизиональная / рыночная / продуктовая

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

Плюсы:

— гибкость — можно разрабатывать индивидуальные стратегии и бизнес-процессы для каждого продукта / региона;

— простота координации и согласования управленческих решений;

— высокая скорость реагирования на возникающие проблемы;

— высокая производительность и качество управления благодаря специализации.

Минусы:

— как и в предыдущих моделях, возможно отсутствие общей цели, каждый сам за себя;

— нездоровая конкуренция между структурами и направлениями, рост политических разногласий;

— разная продуктивность;

— низкая эффективность использования бюджета.

Матричная

Это сложная модель, предназначенная, в первую очередь, для реализации проектов. У сотрудника может быть несколько руководителей, а управление проектом и ресурсами доверяется руководителю проекта / подразделения.

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

Плюсы:

— за реализацию отвечает руководитель с высокой профессиональной компетенцией;

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

Недостатки:

— сложность в реализации проектов и распределении ответственности, конфликты интересов, необходим высокий уровень компетенций у менеджера;

— низкая производительность;

— дублирование функций.

Приведу пример реализации такого подхода.

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

Центральный аппарат инициирует внедрение сложной ИТ-системы, которая охватывает большое количество бизнес-процессов и требует включение и технического блока, и финансового, и HR. В каждом региональном подразделении назначается ответственный менеджер и начинается веселье… Менеджер отвечает за весь проект, но ресурсов и полномочий для управления чужими (финансовым, HR) блоками нет, а желания у других меняться по собственному желанию тем более. Куратор в центральном аппарате не всесилен и тоже находится внутри функционального подразделения. В общем, реализовать такой проект — тот еще квест.

Матричные структуры можно также разделить на слабые, сильные и сбалансированные.

Слабые

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

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

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

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

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

Сильные

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

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

Сбалансированные

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

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

Резюме

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

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

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

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

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

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

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

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

Основные подходы к моделированию и описанию бизнес-процессов

Введение

Помимо организационных структур есть еще одно ключевое направление — бизнес-процессы.

Полный список практически всех подходов к описанию с иллюстрациями, примерами отображения и видео, доступными IT-решениями, представлен по QR-коду и ссылке ниже.

Здесь же я рассмотрю самые распространенные из них, отвечу, кому именно они нужны, покажу, что я наблюдаю в жизни, использую сам, и подведу итог — что важнее: структура или бизнес-процессы?

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

Основные подходы к описанию бизнес-процессов

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

Например, бизнес-процесс закупки включает следующие стадии: получение заявки — поиск поставщиков — сбор предложений — поставка материалов — передача заказчику. Но каждый этап также разбивается на отдельные бизнес-процессы. Поэтому надо понимать, что описание бизнес-процессов — практически бесконечная задача, и вам необходимо будет выбрать уровень детализации, на котором скажете «все, хватит». Чем ниже уровень компетенций команды, тем детальнее следует делать описание. Или же надо обучать команду, но тогда расти придется и вам, как руководителю. Умные кадры не потерпят обращения как с дураками.

Условно существует несколько подходов к описанию бизнес-процессов:

— Диаграммы цепочки добавленной ценности (value added chain diagram, VAD)

— SIPOC

— Событийная цепочка процессов (event-driven process chain, EPC)

— BPMN 2.0 (Business Process Model and Notation 2.0)

— Flow Charting (нотации Процесс и Процедура)

— IDEF (Integrated Definition Language)

— UML (Unified Modeling Languages)

— VSM (Value Stream Mapping)

— ARIS

— DFD

Диаграммы цепочки добавленной ценности (VAD)

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

То есть это некая «мастер-модель», дающая понимание всей команде, как ее работа влияет на компанию в целом.

Правила построения VAD-модели процесса добавленной стоимости:

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

— Далее выстраивается их логическая взаимосвязь.

— Определяются и указываются владелец и подразделение, отвечающие за процесс.

— Указываются главные документы, регулирующие бизнес-процесс.

— Указывается дополнительная информация и необходимые ресурсы для выполнения бизнес-процесса.

— К каждому верхнеуровневому бизнес-процессу прикрепляются ссылки на диаграммы более низкого уровня.

SIPOC

Подход к описанию бизнес-процессов, являющийся инструментом в бережливом производстве. Название отражает всю суть подхода, который фокусируется на пяти составляющих:

— Supplier (поставщик) — человек или компания, которые поставляют ресурсы для выполнения бизнес-процесса (производство, деньги, материалы, данные);

— Input (вход) — ресурсы для бизнес-процесса: материалы, деньги, производственные мощности, данные);

— Process (процесс) — все те задачи, которые позволяют в результате работы преобразовать сырье в конечный продукт;

— Output (выход) — продукты деятельности бизнес-процесса;

— Customer (заказчик) — получатели услуги, те, кто пользуется продуктом бизнес-процесса.

Бизнес-процесс по SIPOC описывается с конца:

— Определите заказчика бизнес-процесса;

— Опишите итоговый продукт (выход), который нужен заказчику;

— Выделите 5—7 ключевых операций бизнес-процесса;

— Определите необходимые ресурсы (вход) для бизнес-процесса;

— Определите поставщиков этих ресурсов

Ключевое преимущество — скорость описания, возможность выявить лишние шаги, которые не создают ценность. Этот подход чем-то похож на VAD и является верхнеуровневым описанием. Позволяет выявить самые явные потери.

Событийная цепочка процессов (EPC)

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

Основные элементы описания:

— Событие — то, что создает необходимость действия.

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

— Исполнители — те, кто реализуют функцию, в том числе утверждают, согласовывают и т. д.

— Ресурсы — это все то, что необходимо для реализации функции: деньги, информационные системы или отдельные модули, документы, операционные риски.

В отличие от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.

Алгоритм описания:

— Определяем, что у нас есть и чего мы хотим — граничные события.

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

— Добавляем всю необходимую информацию об исполнителях и ресурсах.

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

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

BPMN 2.0 (Business Process Model and Notation 2.0)

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

Пример описания в этой нотации ниже.

Что я наблюдаю в жизни и применяю сам

К сожалению, в 99% компаний или нет никакого описания бизнес-процессов, ни верхнеуровневого, ни тем более детализированного, или оно формально и сделано для галочки, а в жизни все работает иначе. И пока организация маленькая, 5—10 человек, это не страшно. Но после того, как она начинает расти, хаос становится все более дорогим удовольствием.

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

Резюме 1 главы и рекомендации

Что важнее: организационная структура или описанные бизнес-процессы? С чего начинать? Это извечная дискуссия. Лично мое мнение: пока компания небольшая, идет ее становление или перестройка, подбор той бизнес-модели, которая будет давать результат, можно обойтись без бизнес-процессов. Если у вас есть организационная структура, четко прописаны функции, ключевой продукт и, желательно, метрики (я не вывожу это в обязательное условие, потому что видел единичные случаи качественно проработанной системы ключевых показателей), то вы не утонете в хаосе. Люди смогут между собой общаться и договариваться, а это — ключевой элемент. Я бы даже сказал, что это полезное упражнение — сначала научить людей работать сообща, разделив между ними полномочия, ответственность и ресурсы, а затем внедрять процессное управление. В итоге работа с орг. структурой позволит создать скелет системы управления, в том числе:

— обеспечить эффективное использование ресурсов;

— повысить производительность;

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

— минимизировать риски для компании, особенно связанные с зависимостью от отдельных людей;

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

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

Кроме того, на ранних этапах, в том числе при запуске цифровизации, ваши бизнес-процессы будут меняться слишком часто, и постоянно их переделывать и актуализировать — слишком дорогое удовольствие. А если описать и «заморозить», то вы теряете главное преимущество молодой команды — ее гибкость. Исключение — критичные процессы с высокими рисками и процессы бэкофиса, они зачастую стабильны и заниматься ими лучше изначально.

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

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

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

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

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

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

Как же выстроить подходящую организационную структуру? И как часто ее пересматривать?

Я рекомендую следующий алгоритм:

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

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

— Оценить доступные технологии и ресурсы, в том числе цифровые.

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

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

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

Еще одна рекомендация: по достижении целей или после внедрения и освоения новых технологий пересматривайте вашу орг. структуру. Или возьмите за правило это делать каждые 6—12 месяцев.

Что касается бизнес-процессов, то тут могу дать следующие рекомендации:

— изначально сделайте VAD-схему по всей компании;

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

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

— не надо описывать каждый бизнес-процесс, только те задачи, которые либо типовые, либо несут риски для бизнеса;

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

— описывайте бизнес-процессы так, чтобы они умещались на одном листе А4, если надо запустить процесс, и в нотации BPMN если нужно проанализировать и оптимизировать процесс. И только после оптимизации занимайтесь IDEF, чтобы автоматизировать;

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

По QR-коду и ссылке ниже вы можете перейти на статью с большим количеством иллюстраций и полезных ссылок на эту тему:

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

В целом тут, как я считаю, необходимо отталкиваться от:

— вашего масштаба и доступности ресурсов;

— текущего уровня цифровизации и готовности;

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

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

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

Если ваш бизнес вырос из малого в средний, в связи с чем появились признаки хаоса и отсутствие работы с данными, то нужно навести порядок и устранить потери (в главе про бережливое производство поговорим подробно об этом понятии), снять внутренние ограничения, а на языке управления данными пройти ступени CDO 1.0 и 2.0. Для этого лучше отдать роль лидера цифровизации операционному директору.

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

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

Ну, а если вы — топ-менеджер корпорации с ресурсами, то лучше всего выделить отдельное подразделение во главе с CDTО (руководителем цифровой трансформации), которое будет выстраивать методологию системного подхода и выступать центром компетенций по работе с цифровыми технологиями, процессами, ведением проектов, созданием продуктов. Состав команды должен обязательно включать: специалиста по процессам / бизнес-аналитика (лучше парочку), специалиста по данным, системного аналитика/архитектора, специалиста по ИБ (этому мы посвятим следующую книгу), руководителя портфеля проектов (если вы будете обучать персонал, то хватит одного, если нет, то по руководителю проекта в каждое подразделение). Если вы их будете размещать в разных подразделениях, то этим людям придется выстраивать горизонтальные связи и матричное взаимодействие. А это дольше и подходит только зрелым компаниям, с уважением в коммуникациях. Если компания менее зрелая, то это выльется в увеличение сроков. В слабой системе нужно централизованное управление.

Я крайне не рекомендую отдавать функцию цифровизации и цифровой трансформации директору по информационным технологиям. Ведь довольно ограниченное количество директоров по ИТ может заниматься перестройкой процессов (что является ядром трансформации), подходов к реализации проектов, созданию продуктов, обладает клиентоориентированностью, в том числе к сотрудникам своей компании. Для них далеки такие понятия как UX|UI дизайн решений и процессов.

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

Глава 2. Теория ограничений систем

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

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

Чтобы понять принцип этого инструмента, рассмотрим два практических примера.

Практические примеры

Пример первый.

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

— снижение внутренних издержек и потерь за счет организации труда по принципам бережливого производства;

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

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

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

По предварительным расчетам, для модернизации цеха необходимо 200 млн рублей, что приведет к росту производительности на 40% и снижению доли брака на 80%. Совокупно это увеличит общую производительность на 60%.

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

В результате вы увидели, что можно вложить всего 10 млн рублей, и производительность цеха вырастет на 35%, а доля брака снизится на те же 80%. Общая производительность предприятия вырастет на 53—55%.

Это и есть принцип теории ограничения систем.

Второй практический пример.

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

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

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

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

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

— ухудшение KPI отдела продаж и менеджеров, что приводит к конфликтам между подразделениями;

— начнут появляться «срочные» и важные заказы, а это уже вмешательство в производственный цикл и еще большее снижение производительности с лавинообразным эффектом;

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

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

Этот пример взят из реальной жизни. В компании за год сменились 8 начальников и 90% производственного персонала, возникли риски штрафных санкций на 20 млн рублей. И ограничение тут было в руководителях. Да, ограничения не всегда технологические, подробный перечень мы рассмотрим чуть ниже.

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

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

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

Если мы вернемся к инструменту, то в теории ограничений есть пять так называемых «этапов фокусировки».

5 этапов — суть всего инструмента

Этап 1 — поиск ограничения.

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

На этом этапе мы выявляем ключевые ограничения. Инструменты, которые могут помочь: мозговые штурмы, ТРИЗ, моделирование и блок-схемы, ментальные карты.

Этап 2 — решить, как максимально использовать ограничение.

Для демонстрации этого подхода давайте возьмем пример выше с ограничением производственных мощностей.

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

Во-первых, мы внедрили оперативное планирование на день вперед. С утра все знали, что производить и в каком порядке. Во-вторых, мы начали организовывать ввоз сырья на дневную смену заранее, в итоге люди после утренней планерки сразу приступали к работе. В-третьих, мы перешли с режима 5/2 по 8 часов на 2/2 по 12 часов. Уже только это позволило увеличить количество рабочих часов с 40 до 84, то есть более чем в 2 раза. Добавляем увеличение производительности в 2,5 раза за счет планирования загрузки (машинное время увеличилось с 30 до 70%) и получаем кратный рост производительности. Благодаря этому подразделение стало выполнять все прошлые заказы плюс все крупные от сетевых заказчиков (ИКЕА, Леруа, Castorama).

Этап 3 — управляем системой с учетом ограничения.

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

Этап 4 — расширяем ограничение.

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

Этап 5 — возвращение к первому шагу.

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

К чему привела наша работа по развитию производительности? Если в начале проекта у нас было 300—400 м² склада сырья, а готовая продукция отгружалась из цеха, то после всех изменений, у нас был пуст склад сырья, все пускалось на производство сразу после разгрузки, а готовая продукция отгружалась уже с отдельного склада с помощью 150—200 м². Тут производительность уже ограничивалась только поставками сырья.

Ключевые инструменты

— Метод «барабан — буфер — верёвка»

«барабан» — внутреннее ограничение, например, предельные показатели того, сколько предприятие может произвести продукции;

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

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

— Метод критической цепи

Его суть в том, что необходимо сократить многозадачность, избавиться от синдрома студента и учитывать закон Паркинсона.

Наш мозг не может работать в режиме многозадачности. Это миф. На самом деле это приводит к тому, что люди начинают переключаться с задачи на задачу, не доводя ни одну до конца, бросая их, и потом люди вынуждены тратить время на погружение в курс дела. Это занимает в среднем не меньше 20 минут. Так, ограничение количества задач до трех может повысить производительность человека до 50%.

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

Синдром студента — характерная для многих привычка откладывать все на потом и приниматься за выполнение задачи в последний момент.

— Мыслительные процессы

Здесь мы используем моделирование и аналитические схемы:

Дерево текущей реальности — выявление причинно-следственных отношений между нежелательными явлениями и корневой причиной большинства этих явлений.

Диаграмма разрешения конфликта — устранение противоречий и скрытых конфликтов в системе, которые часто являются причиной хронических проблем.

Дерево будущей реальности — схема, демонстрирующая, как должна работать система с учетом всех правок.

Дерево перехода — выявление возможных препятствий на пути преобразований и их устранения.

План преобразований — план действий с инструкциями для исполнителей.

Данный подход описан в художественной форме в книге «Цель-2. Дело не в везении». Более формальным академическим языком — в книге У. Детмера «Теория ограничений Голдратта». Найти их можно по QR-коду и ссылке в конце главы.

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

— Ясность и однозначное понимание всех используемых терминов и утверждений.

— В каждом утверждении есть законченная мысль.

— Все выявленные причины вызывают указанные следствия, то есть не нарушена причинно-следственная связь.

— Названная причина достаточна, чтобы вызвать указанное следствие.

— Проведена проверка возможных альтернатив, и именно указанная причина приводит к последствию.

— Причина и следствие не перепутаны.

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

— Отсутствие тавтологии.

Типы ограничений

Голдратт выделил следующие типы ограничений:

— Физические ограничения

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

— Политические ограничения

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

— Ограничения парадигмы

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

Причем во многих проектах именно ограничения в личной эффективности руководителя, неполнота его знаний и ресурсов: умение критически подходить к приоритетам, навыки постановки задач, концентрация, внимание, время и т. д. — в итоге становятся ограничением производительности их подразделений.

— Ограничения рынка

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

Типовые ошибки

— Остановка процесса совершенствования после очередного этапа

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

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

— Узкий фокус внимания

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

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

Резюме 2 главы

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

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

При этом, как показывает практика, главные ограничения зарыты в мышлении руководителей. Помните второй практический пример, где проводили изменения, в том числе изменяли режимы работы производства? Как думаете, что случилось после моего ухода и завершения антикризисного управления? Полагаю, вы догадались. Руководители решили, что все хорошо, можно снова на полную включать продажи, не учитывая производственные мощности и добавляя в дневной график «срочные заказы», пренебрегая тактическим и оперативным планированием. В итоге через 3 месяца все вернулось обратно: просрочка стала расти, люди стали выражать недовольство. Поэтому та же Тойота и предупреждает в своем бережливом производстве, что нельзя фокусироваться на формальных инструментах, нужна комплексная работа, в том числе с людьми. И я с этим полностью согласен.

По QR-коду и ссылке ниже доступна подробная статья с иллюстрациями и видео.

Глава 3. Бережливое производство и 6 сигм

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

Бережливое производство (lean production, lean manufacturing) — подход к управлению, в основе которого лежит постоянное стремление к совершенству и устранению потерь. Разработала этот подход Тойота более 40 лет назад, и он стал одним из залогов ее успеха и мирового лидерства. В 1990-х бережливое производство спасло Porshe от банкротства, а сейчас оно лежит в основе производственной системы любой мировой корпорации.

В последние десятилетия суть концепции наложилась на «6 сигм» и получилось «lean+6 sigma».

Для более глубокого погружения рекомендую прочитать «Дао Toyota. 14 принципов менеджмента ведущей компании мира» Джефри Лайкера и пройти небольшой курс «Бережливое производство. Базовый курс» от Дальневосточного Федерального Университета. Все необходимые ссылки вы найдете в статье по QR-коду.

Прежде чем мы приступим к теории, приведу три практических примера применения этого инструмента в цифровизации.

Пример 1

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

Пример 2

С помощью стандартизации формы отчета и автоматизации расчетов необходимых коэффициентов стоимость отчета в одной компании снизилась с 3000 до 300 рублей. Как? За счет устранения потерь на излишнюю обработку.

Пример 3

Еще в первой книге я рассказывал про систему оценки знаний. При понимании принципов бережливого производства через неделю использования системы появились рекомендации по оптимизации ее работы для снижения трудозатрат на 70—80%! А это ежегодная экономия до 500 тысяч рублей, ведь больше не нужен отдельный человек, занимающийся только одной системой. А ведь зачастую большие корпоративные ИТ-решения так и работают. Например, в другом случае пришлось так же нанимать отдельного человека, чтобы отдать ему работу в 1С, иначе начальник производства и мастер только и могли что заниматься проводками. Именно поэтому крайне важно в автоматизации, цифровизации (разбор разницы между этими понятиями есть в первой книге) и оптимизации бизнес-процессов активно использовать бережливое производство.

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

4 принципа

Бережливое производство имеет в основе четыре принципа.

1. Определите ценность конкретного продукта для потребителя

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

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

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

Без этого мы рискуем внедрять изменения и системы, которыми никто не захочет пользоваться, и они превратятся в просто дорогие игрушки.

2. Определите поток создания ценности для этого продукта (от сырья до готового изделия, от заказа до поставки, от концепции до выпуска продукции)

Здесь надо знать всю производственную цепочку. Для этого есть ряд инструментов. В моделировании бизнес-процессов есть нотации VAD, SIPOC. В управлении продуктом есть CJM (карта клиентского пути) и СX (опыт пользователя). Об этих инструментах мы тоже поговорим чуть позже.

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

Ну, какой смысл внедрять роботизацию на производстве, если клиент должен ждать подтверждения заказа неделю и ответить на 100 дополнительных вопросов, при этом само производство и так занимает 1—2 дня?

3. Обеспечьте непрерывное течение потока создания ценности продукта

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

4. Стремитесь к совершенству

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

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

14 ДАО

14 Дао Тойота — основные «заповеди» производственной системы Тойота и бережливого производства. Это что-то вроде 10 заповедей из Библии, которые позволяют реализовать ключевые принципы.

ДАО разбиты на 4 раздела:

— Философия долгосрочной перспективы;

— Правильный процесс дает правильные результаты;

— Добавляй ценность организации, развивая своих сотрудников и партнеров;

— Постоянное решение фундаментальных проблем стимулирует непрерывное обучение.

Раздел I. Философия долгосрочной перспективы.

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

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

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

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

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

Раздел II. Правильный процесс дает правильные результаты.

Принцип 2. Процесс в виде непрерывного потока способствует выявлению проблем.

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

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

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

Это самая частая проблема у руководителей отделов в работе с подчиненными. Многие такие руководители, по сути, «передасты» — они только перекидывают задачи свыше исполнителю. У сотрудника накапливается по 40—50 неотработанных задач, он пытается сделать все, скачет с задачи на задачу, и в итоге не делает ничего. А как показывает практика, если ограничивать количество рабочих задач до трех, то производительность вырастает до 50%. Во-первых, человек не перепрыгивает с одной задачи на другую (процесс погружения мозга в задачу занимает 20—40 минут), во-вторых, он имеет хоть какое-то разнообразие и вариативность, это и защищает психику, и позволяет не зависнуть на одной проблеме.

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

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

Принцип 4. Распределяй объем работ равномерно (хейдзунка): работай как черепаха, а не как заяц.

Знакома ситуация геройства и пословицы «то пусто, то густо»? В японской философии это называется Мура. И одна из задач бережливого производства — сделать загрузку равномерной, без авралов в конце месяца и бесконечных геройств. И современные системы планирования, в том числе ERP, MES и APS, о которых мы говорили в первой книге, в этом помогут. Ну, и доски Канбан тоже, если мы научимся смотреть на процесс и постоянно его оптимизировать.

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

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

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

Если мы говорим про производство, то инструмент Дзидока (оборудование с машинным зрением или сложной автоматикой) — фундамент для «встраивания» качества.

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

Принцип 6. Стандартные задачи — основа непрерывного совершенствования и делегирования полномочий сотрудникам.

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

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

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

Необходимо фиксировать накопленные знания, например, проводить обзор проектов, выявлять и стандартизировать лучшие подходы и методы. При этом надо поощрять за совершенствование этих стандартов. Вообще, постоянное совершенствование — основное кредо бережливого производства. Но чтобы что-то улучшать, это надо сначала описать и зафиксировать. Иначе будет хаос со всеми вытекающими последствиями. И для ИТ это тоже более чем актуально. Творческие ребята очень не любят стандартизировать свою работу, но увы, надо через «не хочу».

Принцип 7. Используй визуальный контроль, чтобы ни одна проблема не осталась незамеченной.

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

При этом, по возможности, необходимо сокращать объем отчетов до одного листа, даже если речь идет о важнейших финансовых решениях. Для этого есть даже инструмент «Отчет А3».

Принцип 8. Используй только надежную, испытанную технологию.

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

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

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

Помочь с этим может отбор цифровых технологий и решений с учетом TRL (ISO 16290:2013) или УГТ (уровень готовности технологии) и УГП (уровень готовности производства) по ГОСТ Р 58048—2017. УГТ — это насколько технология, которую мы хотим внедрить у себя, зрелая. А УГП — это насколько наше производство готово к созданию инновационного продукта. Так, технология имеет 9 уровней готовности:

— УГТ1: Основные принципы технологии изучены и опубликованы;

— УГТ2: Концепция технологии и ее применения сформулирована;

— УГТ3: Критические функции или характеристики подтверждены аналитическим и экспериментальным путем;

— УГТ4: Компонент или макет испытан в лабораторных условиях;

— УГТ5: Компонент или макет испытан в условиях, близких к реальным;

— УГТ6: Модель системы/подсистемы или прототип продемонстрирован в условиях, близких к реальным;

— УГТ7: Прототип системы продемонстрирован в условиях эксплуатации;

— УГТ8: Реальная система завершена и квалифицирована в ходе испытаний и демонстрации;

— УГТ9: Реальная система подтверждена путем успешной эксплуатации (достижения цели).

Готовность производства имеет 10 уровней:

— УГП1: Определены основные факторы, влияющие на производство;

— УГП2: Определена концепция производства;

— УГП3: Подтверждена производственная концепция;

— УГП4: Достигнута возможность изготовления технических средств в лабораторных условиях;

— УГП5: Достигнута возможность изготовления прототипов компонентов систем в соответствующих производственных условиях;

— УГП6: Достигнута возможность изготовления прототипов систем или подсистем в соответствующих производственных условиях;

— УГП7: Достигнута возможность изготовления систем, подсистем или их компонентов в условиях, близких к реальным;

— УГП8: Испытана пилотная производственная линия, достигнута готовность к началу мелкосерийного производства;

— УГП9: Успешно продемонстрирована возможность мелкосерийного производства, подготовлена база для полномасштабного производства;

— УГП10: Продемонстрировано полномасштабное производство, внедрена практика бережливого производства.

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

Раздел III. Добавляй ценность организации, развивая своих сотрудников и партнеров.

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

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

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

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

Принцип 10. Воспитывай незаурядных людей и формируй команды, исповедующие философию компании.

Принцип 11. Уважай своих партнеров и поставщиков, ставь перед ними трудные задачи и помогай им совершенствоваться.

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

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

Раздел IV. Постоянное решение фундаментальных проблем стимулирует непрерывное обучение.

Принцип 12. Чтобы разобраться в ситуации, надо увидеть все своими глазами (генти генбуцу).

Как же часто я видел истории, когда ТОПы доверяли своим менеджерам и отчетам в компьютере. Вот один практический пример. Основатель компании был выходцем из производства. Еженедельно он ходил на производство. И в итоге люди понимали, что их работа важна, были мотивированы, и он обладал достоверной информацией.

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

Если использовать это правило в сочетании с качественным, автоматизированным сбором данных, прозрачной аналитикой, то этой проблемы можно избежать.

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

Принцип 13. Принимай решение, не торопясь, на основе консенсуса, взвесив все возможные варианты; внедряя его, не медли (немаваси).

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

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

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

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

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

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

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

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

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

Чтобы реализовать этот принцип, необходимо:

— как только процесс стабилизировался, использовать инструменты непрерывного совершенствования;

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

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

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

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

Муда, мура, мури и виды потерь

Муда, мура, мури — странные слова, неправда ли? При этом суть их проста.

Давайте разберемся с этими основными понятиями.

Муда — это потери двух видов:

1. Действия, не создающие ценность, но без которых невозможно обойтись. Например, транспортировка, оформление документов — их невозможно удалить из процесса, но необходимо стремиться сокращать, скажем, автоматизацией подготовки обязательной отчетности. В моем опыте был случай, когда с помощью обычного Экселя получилось снизить трудозатраты на обязательный и никому не нужный отчет с 8 часов в месяц до 30 минут.

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

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

Все это тоже порождает потери — брак, ожидание, лишние запасы, необходимость переделки.

Мури — перегрузка людей или оборудования.

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

Эти три «М» представляют собой единую систему.

Часто корень проблем — «Мура», так как неравномерность приводит к перегрузке «Мури», которая в свою очередь порождает множество других потерь («Муда»).

Напомню, что цель цифровизации, автоматизации и трансформации — снижение потерь, в основном, в работе с информацией. И, прежде чем инициировать какой-то проект, надо понять, какие потери мы хотим устранить.

1. Перепроизводство

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

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

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

2. Ожидание

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

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

3. Запасы

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

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

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

4. Излишняя транспортировка

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

Причины возникновения — нерациональное использование производственных / офисных площадей, лишние промежуточные зоны хранения, неудобное размещение оборудования, неоптимизированные бизнес-процессы.

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

5. Излишнее перемещение людей

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

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

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

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

6. Брак

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

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

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

7. Излишняя обработка

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

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

Если мы еще раз вернемся к статистике проектного и продуктового управления, то лишь 16% продуктов оказываются полностью успешными. Почему?

Один из факторов — излишние количество возможностей в продуктах. Только 20% заложенного функционала востребовано регулярно, 30% — изредка, а 50% — практически никогда. Чтобы было еще нагляднее, давайте вспомним современные приложения, например, банковские. Чем вы действительно пользуетесь? А стало ли удобнее использовать ваше банковское приложение в сравнении с тем, что было лет 5 назад? Лично мне нет. Микросервисные решения становятся все более функциональными, но менее удобными и востребованными. А ведь их разработка стоит денег.

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

8. Неиспользованный человеческий потенциал

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

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

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

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

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

Ключевые инструменты

Kaizen

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

Чтобы это работало, необходимо:

— постоянно собирать обратную связь и внедрять изменения, а если они неприменимы, то надо объяснять инициатору, что именно не так;

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

Это не только улучшает процессы, но и мотивирует сотрудников.

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

Примеры:

1. Во время производства может возникать брак или не весь заказ получается изготовить (не успели, не пришли компоненты). В итоге упаковщики долго объясняют детали начальнику производства, а он — отделу планирования и продаж.

Решение от упаковщиков — ставить номер у каждой детали в самом чертеже. Реализация в 1С — пару дней.

Результат:

— планировщики просто отдают отчет и чертежи

— планировщик сразу знает, что надо перезаказать, и говорит, когда придет недостающая деталь;

— отдел продаж ясно понимает, когда будет готов заказ.

2. Обратная связь от операторов.

Изменив расположение расходников, удалось снизить время на переналадку между заказами на 50%: просто стало не нужно идти в другой конец цеха, по пути еще и задевая другие заказы.

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

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

Хорошо, не все сотрудники, но 10—15% активных новаторов способны все перевернуть. Именно их и надо выделять и обучать системному подходу.

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

Система Канбан

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

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

7 шагов практического решения проблем

В бережливом производстве есть инструмент «7 шагов практического решения проблем».

В его рамках используется также 2 инструмента — 5W1H для оценки ситуации и «5 почему» для определения корневых причин и выстраивания причинно-следственных связей.

В 5W1H надо ответить на 6 вопросов:

— Кто столкнулся с проблемой (who)?

— Что случилось (what)?

— Когда (when)?

— Где (where)?

— Почему это надо было сделать (why)?

— Как возникла проблема, в результате каких действий (how)?

А далее работаем через «5 почему». Я впервые столкнулся с этим инструментом в одном проекте, где работали с ИКЕА: при поставке бракованной продукции, тебя заставляют провести расследование и оформить его в формате «5 почему».

Суть инструмента — необходимо 5 раз ответить на вопрос «Почему это произошло?», чтобы дойти до системных причин. И чем более оцифрованы бизнес-процессы и все этапы, тем проще, быстрее и эффективнее проводить такой анализ.

Пример такого алгоритма.

Проблема: товар пришел с царапинами, при этом на выходном контроле все было отлично.

— Шаг 1. Почему это происходит? Потому что изделия повреждаются в пути, царапаясь друг о друга.

— Шаг 2. Почему оно повреждается в пути? Потому что транспортировка идет на машине и возможны боковые перегрузки.

— Шаг 3. Почему во время транспортировки на машине упакованный груз все равно повреждается? Потому что технология упаковки не обеспечивает должную защиту.

— Шаг 4. Почему технология упаковки не обеспечивает защиту во время транспортировки? Потому что технология упаковывания имеет недостатки.

— Шаг 5. Почему технология упаковки имеет недостатки? И вот тут имеется разветвление. Первый вариант — раньше не было выходного контроля, и все списывалось на подразделение, никто не проводил расследование причин. Второй — раньше компания не имела дела с такой доставкой, и эта технология упаковки не была отработана.

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

В цифровизации 7 шагов решения проблем — ключевой инструмент бережливого производства. Цифровизация без сбоев ПО, отказов оборудования, конфликтов невозможна, и нужно уметь решать эти задачи: локализовывать и определять проблему, формулировать ее, выявлять причины ее возникновения, готовить идеи по решению, выбирать лучшее и действовать. Понимание и владение этим инструментом нужно формировать массово у сотрудников. Банально для того, чтобы они могли сформулировать и описать свою проблему для техподдержки, а не писали что-то из разряда: «Добрый день, не работает 1С». Это сэкономит уйму времени и денег. Потому, что даже если вы решите внедрять в техподдержку искусственный интеллект, то он ничего не поймет из такого запроса.

При этом без описанных и выстроенных процессов эффективность семи шагов и «5 почему» будет радикально снижаться. Как вы поймете, в каком процессе проблема? А главное, что вы будете менять, чтобы она не повторилась? Забегая вперед, обозначу еще один инструмент — «6 сигм». Он нужен для того, чтобы вы понимали границы управляемости вашего процесса и не бежали перестраивать всю организацию после каждого чиха.

5S — система наведения и поддержания порядка

5S — инструмент в экосистеме бережливого производства, метод, который направлен на:

— повышение эффективности операционки;

— устранение накопившегося хлама и мусора, в том числе в ИТ-решениях, и исключение его появления в дальнейшем;

— сокращение потерь на поиск ответов на вопросы «где находится инструмент?», «как получить к нему доступ?»;

— улучшение корпоративной культуры через изменение условий и формирование новых привычек.

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

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

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

5S алгоритм:

1. Сортировка: все предметы на рабочем месте разделяются (сортируются) на нужные и ненужные. Ненужные предметы удаляются с рабочего места. В ИТ так же: все лишнее убирается с рабочего стола системы.

2. Соблюдение порядка: предметы раскладываются по местам так, чтобы ими было легко и удобно пользоваться. Здесь мы говорим про UX-дизайн.

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

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

5. Совершенствование: разрабатывается система постоянного совершенствования предыдущих шагов и рабочего места. Но без стандартов и «точек отсчетов» все свалится в хаос.

Этот инструмент хорошо помогает и в проектировании интерфейсов цифровых решений, в том числе для оптимизации. Например, некоторые ребята регулярно мониторят, какие функции наиболее востребованы, и выносят их на первое место. А что теряет актуальность, порой вообще вырезается из системы. Повторюсь, в ИТ-системах лишь 20% функционала используется регулярно, 30% иногда, а 50% — вообще мусор.

Это не полный список инструментов бережливого производства. Есть еще:

— TQC — всеобщий контроль качества

— TQM — всеобщее управление качеством

— TPM — всеобщий уход за оборудованием

— Just-in-time — точно вовремя

— Отчет А3

Подробнее о них вы сможете прочитать по QR-коду или ссылке.

Недостатки бережливого производства

— Проблемы поставок сырья и ресурсов

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

— Репутационные потери

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

— Высокие затраты

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

— Сопротивление сотрудников

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

6 сигм

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

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

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

Правило 3 сигм

Так что за «сигмы» такие, о чем речь?

Сигма (σ) — буква греческого алфавита, которой в математике обозначают стандартное отклонение, то есть, когда показатели не соответствуют этому отклонению, они являются аномалией.

Правило 3 сигм гласит (в упрощенной формулировке): практически все значения и результаты, которые можно считать нормальными для этого процесса, лежат в интервале +- 3 сигм от среднего значения. Если погрузиться в расчеты, то получается, что все нормальные для процесса результаты будут в этих 3-х сигмах с вероятностью 99,73%.

Алгоритм расчета 6 сигм:

— Складываем все измеренные значения и рассчитываем среднее арифметическое значение.

— Считаем разность между максимальным и минимальным значением, например, за месяц.

— Считаем такую же разность за еще, например, 5 месяцев.

— Считаем среднее арифметическое этой разницы за 6 месяцев.

— В контрольных картах Шухарта (ГОСТ Р 50779.42—99) находим показатель d2, и берем значение для выборки, в нашем примере это 6 месяцев, значит d2 = 2,534.

— Берем нашу среднюю разницу между максимум и минимум и делим на d2.

— Получаем сигму.

— Теперь от среднего значения из пункта 1 откладываем 3 сигмы вправо и влево. Получаем 6 сигм, которые показывают границы нашего управляемого процесса. Что не внутри — это отклонения. Выясняем причины и работаем с ними. А если нас не устраивают границы процесса, работаем системно.

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

Вот практический пример из моей практики.

Что есть на входе: таблица с данными о бурении скважин. Записей в ней около двухсот.

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

Что ж, давайте пройдемся по простому алгоритму:

— Делаем небольшую табличку, в которой считаем продолжительность ключевых периодов.

— Рассчитываем основные показатели.

— Дальше строим графики Парето (с некоторой очисткой от аномалий), смотрим, какое в среднем ожидание между бурением и освоением (простой).

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

— Определяем причины отклонений, выпадающих за границы процесса, в том числе используя методику «5 почему». Определяем необходимость внесения изменений в процессы (например, закупка ЗИП).

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

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

— Согласно графику Парето, мы увидели, что в более чем 75% случаев ожидание находилось в пределах до 73 дней, а в 85% случаев — до 154 дней. Конечно, лучше оптимально провести расчет сигм, но и в текущем варианте видны границы управляемости процесса. Соответственно, для первого приближения можно использовать средние арифметические.

— Мы не имеем информации о глубинах скважин и не можем оценить эффективность рабочего процесса. Однако мы можем сопоставить время простоя между окончанием бурения и началом освоения. Так, средний срок ожидания от момента окончания бурения до начала освоения — 76 дней. При этом среднее ожидание начала освоения превышает средний срок освоения более чем в 3,5 раза и сопоставим по времени со всем процессом бурения. Суммарно потери ожидания составляют 42% времени от всего цикла с момента начала бурения до окончания освоения. Это генерирует как упущенную прибыль, так и прямые потери.

— Причина — системные проблемы процесса планирования, необходим детальный аудит.

— Возможные ограничения системы:

— система контроля и оповещения о прохождении технологических этапов;

— отсутствие системы прогнозирования завершения этапов бурения;

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

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

Lean Six Sigma

Lean Six Sigma — гибрид, сочетающий японскую и американскую концепции:

— Бережливое производство (Lean) — сокращение потерь и ускорение процессов, стандартизация и постоянное развитие, работа с людьми и обдумывание;

— 6 сигм (Six Sigma) — повышение качества продукции и лояльности клиентов; основа — анализ информации, измеримые показатели.

Вообще, я как инженер по базовому образованию считаю, что наилучшие решения — некие гибриды. Нет чистых методологий, которые бы полностью были применимы к жизни. Невозможно использовать какой-либо инструмент на 100%, это становится избыточным и слишком дорогим удовольствием. Расчет буровых скважин, приведенный выше, у меня занял один вечер. В результате я получил понимание проблемы. Можно было бы и глубже погрузиться, потратить 2—3 вечера на аналитику, но изменился бы от этого конечный результат? Вряд ли. А это уже потери в бережливом производстве — излишняя обработка.

Резюме 3 главы

Конечно, здесь не все инструменты перечислены, и в той же концепции 6 сигм можно глубже рассмотреть контрольные карты Шухарта, DMAIC, DMADV, какие есть роли у персонала (зеленые, черные пояса, мастера и т.д.), а в бережливом производстве — SIPOC и Poka-yoke, «Дом TPS» (инструменты и принципы), но как мне кажется, для тебя, мой читатель, это будет перебором. Ты — не исполнитель, а руководитель. А значит, конкретные инструменты должны знать твои люди, а ты должен понимать, как это работает, чтобы уметь правильно ставить задачи и делегировать, контролировать и спрашивать результат.

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

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

Если все же интересно глубже погрузиться, то QR-код и ссылка приведут к соответствующей статье.

Глава 4. Проектное управление

Введение

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

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

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

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

Вот об этом и поговорим.

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

По моим личным наблюдениям из-за некачественного управления страдает абсолютное большинство проектов. Допустим, вы верно определили, куда надо внедрять IT, саму технологию, ключевые эффекты, но вот начинается внедрение и…

Если быть откровенным, то именно с проектного управления начинался мой путь в цифровизации, и именно это направление менеджмента я осваивал наиболее глубоко. В итоге у меня есть опыт работы как со стартапами, так и с гигантами: ЛУКОЙЛ, Газпром, Минэнерго, Mazda-Sollers. И я могу с уверенностью сказать, что в промышленности проектами у нас управлять не умеют: выбирают неверные орг. структуры, методологии, фокусируются на формальных инструментах, не прорабатывают цели, задачи, доступность ресурсов, риски… Но не думайте, что мы такие одни. Вот к каким выводам о причинах неудач в проектах пришла Standish Group после изучения более 50 000 проектов во всем мире:

— Недостаток ресурсов.

Это вообще типовая история — давайте инициируем проект, а как реализовать, разберемся потом. Так, у меня был проект в одной корпорации, где участвовало 7500 человек, который мы сопровождали с помощью Exсel. Нужно ли рассказывать об этом веселом приключении, и о том, какого качества данные там были?

— Нереальные сроки.

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

— Ошибки формулирования целей.

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

— Недостаточно детальное планирование.

Если подумать, то это является первопричиной для всех остальных пунктов.

— Низкое качество взаимодействия внутри команды.

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

— Изменение целей в ходе проекта.

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

Статистика проектного управления

Прежде всего хочу привести диаграмму со статистикой проектного управления.

Причем, если глубже погрузиться в исследования, то с 1990-х по начало 2000-х динамика была положительной, а потом все застопорилось. Даже по отраслям ситуация не отличается значительно.

Ну, и на закуску — зависимость успешности от масштаба и методологии.

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

Еще интереснее выглядит статистика превышения сроков и перерасходов.

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

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

При этом компетенция проектного управления становится все более обязательной, игнорировать ее нельзя, и вот почему:

— доля проектов в ВВП, например, Великобритании, за 100 лет увеличилась с 5 до 35%;

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

— по некоторым прогнозам, к 2030 году до 60% рабочего времени руководителя топ-уровня будет уходить на проекты;

— при этом, согласно рекомендациям стандартов и по моим наблюдениям, ошибки, допущенные и не устраненные в начале проекта, могут его гарантированно похоронить. Я проходил и через мертвые проекты, и вытаскивал «проблемные». Стоимость одинаковых изменений растет с 10 условных рублей на стадии инициации и планирования до 10000 при запуске в эксплуатацию. При этом возможности по исправлению ошибок уменьшаются. Поэтому современные методики предусматривают до 30—40% времени от всего проекта на его планирование и проработку рисков.

Возможные подходы и стандарты к управлению проектами

В мире и, в частности, в России существует несколько стандартов и подходов к управлению проектами:

1. Стандарты про компетенции руководителя:

— стандарт ICB от IPMA (Международная ассоциация управления проектами);

— стандарт НТК от СОВНЕТ, который является переводом ICB;

2. Стандарты, выстраивающие процессы:

— PMBOK от PMI

— ISO 21500 от ISO является конспектом PMBOK (100 страниц вместо 500+)

— P2M от PMAJ — и про проекты, и про программы. Ориентирован на ценности, которые должны получить по итогам реализации.

— Prince2, разработанный авторами ITIL, стандарта по управлению ИТ услугами.

— наш ГОСТ Р — короткая версия PMBOK. Отвечает на вопрос «что надо сделать?».

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

Если упростить, то подходы к реализации проектов можно разделить на:

— каскадные;

— гибридные;

— гибкие.

В свою очередь гибкие подходы тоже можно разложить также на 3 типа: итеративные, инкрементальные, итеративно-инкрементальные.

При этом, согласно различным исследованиям, в жизни в основном (60—70%) применяют гибридные методики. Чистого подхода очень мало, и это нормально, ведь невозможно создать универсальный инструмент на все случаи жизни.

Как выбрать правильный подход?

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

Это модель Кеневин (Cynefin framework), которая выделяет пять типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).

1. Простая система

Характеристика: причинно-следственные связи ясны и однозначны.

Что делаем: берём лучшие практики.

Порядок действий: Осознай — Классифицируй — Реагируй.

Примеры: повторяющиеся и относительно простые проекты, такие как укладка тротуара во дворе, проведение вебинара.

Использовать можно любой «каскадный» стандарт. Главное — не обольщаться простотой и не пренебрегать планированием и точками контроля.

2. Сложная система

Характеристика: причинно-следственные связи существуют, но не всегда очевидны.

Что делаем: используем хорошие практики и стандарты. Здесь не существует единственной «лучшей практики», но есть множество «хороших практик».

Порядок действий: Осознай — Проанализируй — Реагируй.

Примеры: внедрение ERP-системы, реконструкция производственной линии.

Здесь необходимо соблюдать требования PMBOK, Prince2, P2M, работать с заинтересованными сторонами и рисками.

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

3. Запутанная система

Характеристика: причинно-следственные связи не ясны. Схожие действия приводят к разным результатам из-за внешних факторов.

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

Порядок действий в такой среде: Исследуй — Осознай — Реагируй.

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

Это территория Agile и Scrum. Здесь не подходят четкие технические задания. Необходима гибкость и осознание рисков, отступление от жестких требований.

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

Это одна из причин проблемности внедрения ИТ в крупных компаниях. Все делается по бумаге, с ограничениями бюджетов. В итоге приходят к неудобным и дорогим в содержании системам и отсутствию бюджета на доработку, что объясняется следующими тезисами:

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

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

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

4. Хаотичная среда (кризис, инновации)

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

Порядок действий в такой среде: Действуй — Осознай — Реагируй.

Что делаем: первый шаг в условиях хаоса — это Действие. Цель — уменьшение хаоса. Затем необходимо ощутить результат этого действия и прореагировать для перевода системы из хаотического состояния в запутанное или упорядоченное. На проверку гипотез просто нет времени, в хаотических системах все происходит невероятно быстро.

Результат зависит от грамотности, смелости и инновационности мышления конкретных управленцев.

5. Беспорядочная среда

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

Типы организационных структур

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

— Слабая — проектов много, но они небольшие, без рутины, не критичны для компании. Или же всего один проект, который условно забирает 10—20% ресурсов компании. Если смотреть по модели Киневин, это подходит для простых систем. Такая структура особо требовательна к проработке плана коммуникаций между участниками и к получению обратной связи от менеджера проекта, который обычно не является высоким руководителем.

— Сбалансированная — средние проекты, которые могут забирать 20—50% ресурсов компании. Если смотреть по модели Киневин, то это сложные и запутанные системы. Можно применять и в хаотичных структурах, но надо оценивать проект. Например, внедрение ERP или отдельных цифровых проектов.

— Сильная — стратегические проекты, где цена ошибки высока для компании, и требуется большое количество ресурсов (более 50%). Это, например, программы по трансформации, комплексной автоматизации, внедрение систем бережливого производства и так далее. Здесь крайне важно прорабатывать этап инициации и планирования, делать короткие контрольные точки между этапами и сохранять гибкость.

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

Методологии реализации проектов

PMBOK

PMBOK (Project Management Body of Knowledge). По-русски, это «свод знаний о проектном управлении». Классификатор процессов (до 2021 года), который говорит, что и когда надо исполнить, чтобы проект достиг заявленных целей.

Этот свод — результат труда американцев в их желании создать универсальную инструкцию. Они хотели уйти от человеческого фактора в управлении и сделать так, чтобы любой, взяв эту инструкцию, мог реализовать проект. По этому своду проводит сертификацию PMI (Project Management Institute — Институт управления проектами).

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

PMBOK — наиболее распространенная методология, которую можно использовать в большинстве проектов.

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

При этом, сейчас еще актуальна шестая версия PMBOK, но в 2021 вышла седьмая. В ней идет переход к более гибкому управлению. Стандарт больше не говорит, что делать и когда, а дает инструменты и подсказки, предлагая руководителям самостоятельно определять свои действия.

Это стало ответом на неопределенность и нестабильность современного так называемого VUCA-мира:

— Volatility (нестабильность) — постоянные изменения окружающей среды, запросов клиентов.

— Uncertainty (неопределённость) — практически невозможно что-то прогнозировать и планировать. Теперь стратегическое планирование охватывает не 3-5-10 лет, а 1—2 года. Это следствие политических конфликтов, войн, эпидемий.

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

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

Но в мировой повестке примерно с 2016 года появилась новая аббревиатура — BANI:

— Brittle (хрупкий) — любая система легко и быстро ломается.

— Anxious (тревожный) — постоянные изменения, которыми невозможно управлять и под которые необходимо постоянно подстраиваться, ломая свои планы.

— Nonlinear (нелинейный) — одни и те же действия приводят к разным результатам.

— Incomprehensible (непостижимый) — невозможность ориентироваться в бесконечном потоке противоречивой информации.

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

Вернемся же к нашей теме, PMBOK. Лично мое мнение таково, что упрощение в новой версии опасно. Если смотреть на ситуационную модель лидерства (о ней поговорим чуть позже), то такой подход актуален для компаний, где уже есть опыт проектного управления. Если же мы говорим про молодые компании без каких-либо компетенций, то им как раз нужны четкие и директивные инструкции. Ту же зависимость я вижу в своей практике: чем ниже уровень компетенций у клиентов, тем больше они хотят, чтобы ты их провел за руку, а лучше — сделал вообще все сам. Даже если ты распишешь, как все устроено, какие есть механизмы и инструменты, для них ценнее понятный и четкий алгоритм: возьми палку, подойди к пальме, ударь по банану. И именно поэтому я пришел к осознанию, что для кардинальной смены в проектном управлении нужен цифровой советник, который будет говорить, что и как делать, и параллельно обучать, чтобы в итоге формировать компетенции.

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

— инициацию;

— планирование;

— исполнение;

— мониторинг и контроль;

— завершение.

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

Под каждую стадию необходимо выполнить определенные процессы.

Наиболее частые причины проблем — непроработанные этапы инициации и планирования. Нет четких критериев успешности, не проработаны риски, коммуникации. Из-за них и появляется большая часть тех 70% проблемных и неудачных проектов. В нынешней неопределенности крайне важно на стадии планирования заложить 20—30% на форс-мажоры (главный постулат риск-менеджмента), а ряд практиков из ИТ вообще считает, что до 50%.

При этом указанные выше группы процессов не строго привязаны к этапам проекта. Процессы инициации есть и на стадии закрытия проекта (инициация закрытия, сбора документов и т.д.)

Также PMBOK подразумевает управление:

— Интеграцией.

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

— Содержанием.

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

— Сроками.

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

— Стоимостью.

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

— Качеством.

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

— Человеческими ресурсами.

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

— Коммуникациями.

Планируются коммуникации, распространяется информация, создается отчетность по исполнению, происходит управление участниками проекта.

— Рисками.

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

— Поставками.

Планирование покупок и контрактов, запрос информации у поставщиков, подбор поставщиков, администрирование и закрытие контрактов.

Резюме

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

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

Если же говорить про сам подход, то я бы рекомендовал молодым компаниям начать с шестой версии, немного подрасти «ментально», а дальше переходить к седьмой версии стандарта. Или же найти консультанта, который поможет сразу пройти путь построения проектной культуры по седьмой версии стандарта. Тут вопрос ресурсов: времени и денег — чего у вас больше.

PRINCE 2

Скажу честно, в России я этот подход не встречал. Он у нас не особо распространен, но это не значит, что знать о нем не надо.

PRINCE2 (PRojects IN Controlled Environments — проекты в контролируемых средах) — наиболее директивный метод управления проектами. Он делает акцент на обязательности всех инструментов (процессов, тем, принципов) и опускает важность soft skills (лидерство, работа с мотивацией и так далее). Все как у нас любят менеджеры — акцент на инструментах и системе с игнорированием личных качеств руководителя. Ключевая же задача стандарта, по задумке создателей, обеспечивать правильной информацией в правильное время правильных людей для принятия правильных решений.

Но и он уже ориентируется на AGILE. Например, выдаются сертификаты PRINCE2 Agile Foundation и PRINCE2 Agile Practitioner.

Главное отличие от PMBOK, объясняющее, какие части процесса могут включаться в зависимости от ситуации, что нужно на входе процесса, что в результате, какие нужны инструменты, заключается в том, что PRINCE2 предполагает строгую последовательность шагов для ряда повторяющихся процессов. Хорошо ли это? Все зависит от ситуации и команды. Кроме того, столь строгий подход не отличается высокой результативностью. Я считаю, что строгость и директивность нужна там, где низкое качество персонала и не предполагается работа по его развитию.

PRINCE2 базируется на 7 принципах, 7 темах, 7 этапах.

7 принципов:

— Постоянная оценка целесообразности

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

— Учет предыдущего опыта

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

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

Это же подтвердилось и в исследовании Дмитрия Ирешева из СберМаркета. Ознакомиться с исследованием можно по QR-коду и ссылке.

— Определенные роли и обязанности.

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

— Управления по стадиям.

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

— Управление по исключениям.

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

— Фокус на продукте.

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

— Адаптация к внешним условиям.

Проектная команда должна понимать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта. Бесполезно, например, в стартапе внедрять все правила, а в корпорации пренебрегать необходимой документацией.

7 тем:

Это направления, которые позволяют реализовать 7 принципов, и поэтому их описание пересекается с принципами. Вы без проблем сможете сопоставить их.

— Оценка экономического обоснования.

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

— Организация.

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

— Управление качеством.

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

— Планы работ.

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

— Анализ и управление рисками проекта.

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

— Управление изменениями содержания.

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

— Принятие решений.

По сути, это мониторинг проекта с установленными метриками и сценариями принятия решений «если, то»: как идет проект, какие отклонения есть, достигнем ли целей и так далее.

7 этапов:

Если посмотреть внимательнее, то это те же пять стадий проекта из PMBOK.

— Начало.

Назначается руководитель проекта, определяется продукт проекта, его характеристики. В PRINCE руководитель проекта должен заниматься «техническими» деталями и отчитываться перед управляющим комитетом (УК). А УК осуществляет общее руководство проектом, отвечает за успех и за то, чтобы руководитель вел проект согласно выбранному курсу, «политики партии».

— Инициация.

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

— Управление.

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

— Контроль.

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

— Реализация.

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

— Управление ограничениями.

Определяем, достигаем ли установленных к продукту проекта критериев.

— Завершение.

Ретроспективный обзор проекта и его результатов, подготовка отчета для УК.

Ключевые роли:

— Заказчик — человек, оплачивающий выполнение проекта.

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

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

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

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

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

Резюме

PRINCE2:

— не гарантирует соблюдение сроков или бюджета, сокращение издержек или увеличение прибыли;

— гарантирует прозрачный учет и управление рисками проекта;

— формализует возможности оперативного получения данных с необходимой детализацией;

— способствует повышению производительности работ в рамках унифицированных форматов управленческих документов.

Как видим, этот стандарт не сильно отличается от PMBOK. В основном отличия чисто «косметические» (больше этапов, меньше областей управления), однако акцент смещен в сторону еще большей директивности процесса.

P2M

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

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

P2M делает акцент на том, какую ценность мы создаем для потребителя продукта. Учит нас понимать, кому и для чего нужен продукт проекта. И этим он максимально приближается к современному тренду — продуктовому управлению и гибкому Agile.

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

PMBOK (5 редакция, самая распространенная у нас): временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов указывает на определенное начало и окончание.

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

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

Основной документ P2M — руководство по управлению инновационными проектами и программами предприятий. Найти его можно легко в сети.

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

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

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

Японцы относят P2M к третьему поколению стандартов:

— 1 поколение

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

— 2 поколение

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

— 3 поколение

Здесь акцент на изменении окружения проекта, работе с клиентами, поиске решений сложных миссий всей компании и программы. Именно к этому поколению и относят японцы P2M. Я бы отнес сюда также Agile/Scrum и 7-е поколение PMBOK.

Для определения миссии используется метод 6W1H (Who, What, When, Why, How, Which and Whom) с ответами на вопросы:

— Кто менеджер программы?

— Что будет главной проблемой и ее решением?

— Когда будет начало и окончание программы?

— Почему она создаётся? Как она будет реализована?

— Который из планов будет реализован?

— Кому будет выгоден результат?

В итоге будет краткий план управления программой:

— Описание: как программа направлена на выполнение общей миссии компании, и как будем реагировать и адаптироваться к внешним изменениям.

— Общее представление: разбор специфичных элементов программы и проектов.

— Общие основы: установка главной цели программы

— Управление интеграцией: создание ценностей компании и общая оптимизация управления в ней.

Чем надо управлять в проекте:

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

— финансами: создание и подготовка базы, обоснований для привлечения необходимых для проектов денег;

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

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

— ресурсами: необходимые для проекта ресурсы и их распределение (материалы, люди, информационные и финансовые ресурсы, интеллектуальные ресурсы и т.д.);

— информацией: подготовка и обработка поступающей информации в течение проекта;

— коммуникациями: проработка матрицы коммуникаций, в том числе на основе полученного ранее опыта;

— рисками: осуществление контроля и реакции на каждый риск (об этом поговорим отдельно);

— отношениями: принципы и методы управления отношениями между стейкхолдерами;

— ценностями: сбор знаний, опыта и источников, предоставляющих ценности (например, типовые корпоративные или проектные активности) для проектов;

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

Основные принципы, применяемые при работе:

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

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

— Действия участников команды должны быть взаимосвязанными.

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

— Обязательно наличие ментального пространства для всех участников команды (в Японии это пространство называется «Ба» — платформа), в котором идет постоянное взаимодействие и обмен идеями.

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

Компетенции, для достижения ценности и создания нового продукта:

— Осознание миссии программы

— Наличие новаторских идей

— Стратегическое мышление

— Координаторские способности

— Ориентированность на результат

— Навыки взаимоотношений

— Способность укладываться в заданные сроки

Резюме

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

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

Подробнее о классических подходах, с видео и большим количеством иллюстраций, можно посмотреть статью по QR и ссылке.

AGILE

Сейчас Agile разрекламирован, и многими позиционируется чуть ли не как панацея от всего и вся, а точнее как универсальный ответ на VUCA-мир.

Так что же такое Agile, действительно ли это волшебная таблетка? Не совсем. Это подход к реализации проектов с помощью коротких отрезков (спринтов) по 1—4 недели и подготовки небольших частей «общего» продукта — инкрементов. И как мы видим, если проект относительно простой, с понятными целями и задачами, то водопадный подход окажется быстрее и дешевле. Но если мы в ситуации запутанной или хаотичной системы, то лучше идти наощупь маленькими шагами. Такой подход позволяет раньше увидеть проблему и минимизировать стоимость ошибки.

Неопределенность может быть связана:

— с новым продуктом и требованиям к нему;

— с заказчиком/потребителем, с тем, чего же он хочет и что ему надо на самом деле.

Еще одна отличительная черта Agile, особенно в продуктовом управлении — создание MVP, т.е. тестовой версии товара, услуги или сервиса с минимальным набором функций, которая несет ценность для конечного потребителя. Подробнее будет в главе о продуктовом управлении.

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

Agile целесообразен в основном для запутанных систем модели Киневин или как элемент гибрида в сложных системах.

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

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

Манифест Agile выделяет четыре ценности:

1. Люди и взаимодействие важнее процессов и инструментов.

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

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

2. Работающий продукт важнее исчерпывающей документации.

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

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

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

3. Сотрудничество с заказчиком важнее согласования условий контракта.

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

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

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

4. Готовность к изменениям важнее следования первоначальному плану.

Это продолжение предыдущего пункта. Собственно, сам подход через короткие интервалы — это и есть принцип Agile. При создании новых цифровых продуктов без этого никуда.

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

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

Есть и принципы.

— Главный приоритет — удовлетворять запросы клиентов.

— Готовность изменять требования к конечному продукту даже под конец проекта.

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

— Поддерживать сотрудничество между командой и заказчиком в течение всего цикла разработки.

— В команде должны быть мотивированные профессионалы (но помним про закон Йеркса-Додсона, гласящий, что наилучшие результаты достигаются при средней интенсивности мотивации).

— Обеспечивать непосредственное взаимодействие между исполнителями.

— Измерять прогресс только через рабочий продукт.

— Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы).

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

— Стараться сделать рабочий процесс и конечный продукт максимально простыми и понятными.

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

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

Из принципов рождается главный инструмент — Scrum, и становится все более популярным Канбан (им посвящены следующие разделы).

Из принципов появились и признаки Agile-команды:

— команда в Agile — профессионалы с высоким уровнем экспертности в своем деле (программирование, услуги, производство и т.п.);

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

— состоит из 5—9 человек;

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

— все члены взаимозаменяемы, команда кросс-функциональна. Любой участник может выполнять любую из задач, которые команда берет в работу. Но в сложных проектах это редко, и, как правило, есть «Т-компетенции»: когда участник глубоко разбирается в своей профильной деятельности (вертикальная черта в «Т») и средне — в смежных областях (горизонтальная черта), может при необходимости помочь или заменить другого участника;

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

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

Минусы и ограничения (мое мнение):

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

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

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

— Agile не любит ограничений по срокам и финансам, а оплата почасовая… Если слабый руководитель, высокая текучка, низкий уровень команды, то вы получите черную дыру средств и непонятную перспективу получения результата.

Резюме

У меня были как удачные проекты по Agile-философии, так и нет.

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

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

SCRUM

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

Основные роли, которые предусмотрены:

— Владелец продукта

Это человек, который отвечает за успех всего продукта / результата. Он ведет бэклог (список задач, ранжированный по степени их важности).

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

— Команда

Это исполнители, создающие продукт. Желательно наличие у всех членов команды более одной компетенции. То есть согласованность внутри команды достигается за счет понимания каждым участником области работы остальных коллег ввиду наличия компетенций в их областях. Размер такой команды — от 5 до 9 человек.

— Scrum-мастер

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

Он может использовать любые вариации: чистый Скрам, Kanban, Lean Startup или микс из разных подходов.

Кроме того, есть дополнительные роли:

— Пользователи

— Стейкхолдеры (они вовлечены только во время обзорного совещания по отрезку)

Основные процессы, которые помогают организовывать работу:

— Планирование спринта

Проходит перед началом каждого отрезка. Цель — определить объем работ, который команда возьмет в ближайший спринт (отрезок).

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

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

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

— Ежедневная летучка

Ежедневная планерка (Daily SCRUM), которая проводится в одно и то же время. Помните совещания на производствах? Этот инструмент вообще обязателен для всех. Он выстраивает точки контроля, позволяет лучше планировать день, повышает уровень дисциплины (я так полностью исключил опоздания на производстве).

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

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

— Разработка

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

— Обзор спринта

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

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

— Ретроспектива

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

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

Я рекомендую следующую структуру проведения встречи:

— Новости и актуальная информация для синхронизации команды;

— Что сделано за неделю / спринт;

— Что планируется на следующую неделю /спринт;

— Риски: снялись, реализовались, возникли.

Основные документы и элементы, которые рождаются в процессе работы:

— Бэклог продукта

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

— Бэклог спринта

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

В бэклог спринта должны попадать только такие элементы, которые удовлетворяют трем параметрам: они являются четкими, проверяемыми и осуществимыми. Четкость означает одинаковое понимание участниками команды сути задачи. Проверяемость означает наличие возможности проверить, выполнена ли задача. Осуществимость означает возможность полностью выполнить эту задачу за один спринт.

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

— Инкремент продукта

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

Резюме

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

К сожалению, когда дело касается гибких методологий, все думают, что раз они гибкие, то можно их использовать частично. Но, как гласит японское правило СЮ-ХА-РИ, надо обучаться последовательно, и, если у вас нет опыта и базы, придерживаться всех правил.

Многие же компании попадают в еще одну ловушку: в требованиях к вакансиям указывают опыт 3—5 лет и думают, что этот человек уже сам все может адаптировать и применять. Увы, даже если он эксперт экстра-класса, то ваша культура его съест. Нужно, чтобы люди прошли этот путь именно в вашей компании.

KANBAN

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

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

Канбан очень гибок. Его можно интерпретировать достаточно свободно. Но одно из главных его условий — ограничение рабочих задач на каждой стадии (Work in progres). Во-первых, это защита от «запасов» и возникновения потерь, во-вторых, это отличная визуализация узких мест, в-третьих, это увеличивает производительность, работая на уровне психологии (так наше сознание не переключается с задачи на задачу, выполняя работу до конца и быстрее). Хорошо этот инструмент разобрал Максим Дорофеев в своих «Джедайских техниках».

Пример выше — не единственный метод визуализации рабочего процесса.

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

Основные принципы:

— Опора на существующие методы работ

Канбан начинается с существующих методов работы и стимулирует в них улучшения.

— Предварительная договорённость о проведении важных изменений

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

— Уважение к существующему порядку, ролям и обязанностям

— Поощрение инициативы

Для проведения системных изменений Канбан предполагает шесть этапов.

— Визуализация

— Ограничение количества незавершенной работы

— Управление потоком

— Делать правила явными

Прозрачность правил — основной тезис. Об этом я еще скажу в главе про практики регулярного менеджмента. У меня всегда на доске есть колонка с правилами.

— Внедрение циклов сбора обратной связи.

Сбор обратной связи реализуется через:

— ревью стратегии;

— операционное ревью;

— ревью рисков;

— ревью сервиса поставки;

— собрание по пополнению;

— канбан-митинг;

— собрание планирования поставки.

— Совместное улучшение, эволюция на основе экспериментов.

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

Этот подход можно легко применять совместно со Scrum. По сути, Скрам-доска является Kanban-доской.

Резюме

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

Scrumban

Что ж, теперь мы из теории переходим к реальности, в которой редко используются чистые подходы, зато процветают гибриды. Разница между Scrum и Kanban заключается в планировании и включении задач в работу. В Scrum это итерации длиной в 1—4 недели и фиксированный объем спринта. В Kanban задачи можно добавлять каждый день. Главное — визуализация и ограничение количества рабочих задач.

Еще интересная аналогия: Scrum — автобус, Канбан — маршрутка. Увидев её, я улыбнулся во весь рот.

Из желания совместить эти две философии и научить команды основам бережливого производства появился Scrumban — Scrum с «вытягивающей системой» или более гибкий Scrum. Никакого формализованного документа по этому гибриду нет. По сути, это результат экспериментов разных компаний, когда все естественным путем приходят к одному и тому же.

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

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

От Скрама тут унаследованы церемонии (планирование спринта, ежедневные летучки, обзор, ретроспектива) и петли обратной связи.

Практические черты Scrumban:

— стандартный размер итераций в проекте;

— сохраняются все этапы из скрама: планирование, планерки, ревью и ретроспективы;

— при планировании спринта учитывается тот факт, что к проработанным задачам могут добавиться дополнительные требования или что-то неучтенное;

— большие задачи разбиваются на рабочие, примерно одинакового размера, и приоритезируются;

— есть ограничение количества задач в процессе работы;

— чёткие роли не указаны, они вводятся по необходимости;

— в бэклог проекта / продукта попадают только те задачи, которые кем-то заказаны;

— бэклога спринта нет. Фокус на равномерных и коротких отрезках, частом анализе своей работы и оптимизации процессов;

— задачи не назначаются членам команды руководителем группы или менеджером проекта;

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

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

— на ретроспективах команда, в первую очередь, работает над снижением времени цикла.

Кому больше всего подходит Scrumban:

— сервисные проекты технического обслуживания;

— событийная работа;

— удалённые команды, которые работают над запуском новых продуктов;

— исследования (R&D);

— тестирование и развёртывание продукта;

— компании, где есть проблемы с чистым Scrum, то есть почти все.

Резюме

Примерно к этому подходу приходят все команды и компании. Как показывают и инженерная практика, и наблюдение за средой, и управленческий опыт — нет чистых стандартов и инструментов. Всегда появляются их гибриды. И Скрамбан — один из них. Я люблю делать Канбан базовым инструментом для всех, а для проектных команд уже подбирать тот подход, который подходит для них, и если мы работаем в условиях неизвестности, то Скрамбан очень хорош.

Работа с рисками

Как думаете, в чем разница между новичками в управлении проектами и опытными руководителями? В их акцентах.

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

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

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

Думаю, теперь нет вопросов, почему опытные руководители проектов делают упор на стадии инициации и планирования и могут отдать им до 30—40% времени проекта. Те же самые рекомендации есть и в PMBOK.

При этом, как показало исследование «Проектного управления в России 2022», проведенное руководителем проектного офиса СберМаркет Дмитрием Ирешевым (QR и ссылка были в начале главы), в компаниях любят заниматься планированием, использовать трекеры задач, но не делать обзоры и учиться на ошибках. У нас нет культуры постоянного совершенствования, в том числе через структурирование полученного опыта и повышение качества планирования.

И именно руководитель должен это знать и подавлять свое желание «давай быстрее-быстрее, надо вчера было». Ну, или применять Agile и идти короткими итерациями (отрезками), быть готовыми свернуть проект в любой момент и забыть об убытках, прививать культуру обучения и развития. Помните ДАО Тойоты? Все идет от головы, никакие наемные менеджеры не изменят вашу культуру, если вы, конечно, разом не замените 90% команды.

Давайте приведу еще один пример из практики, после которого я решил выйти из проекта.

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

При этом мы четко понимали, что через пару месяцев приедет новое оборудование, которое займет 30% цеха. И мое предложение было простым — не заниматься сейчас тратой времени и ресурсов, а заняться планированием будущей цеховой логистики. Потратить эти 1—2 месяца на проработку вариантов, сбор обратной связи от ребят в цеху, чтобы было и функционально, и удобно. А когда оборудование придет, мы просто поставим его, дадим новые схемы, нанесем разметку и быстро вернемся к работе.

Но руководитель всего проекта и директор направления захотели вернуться к привычному режиму: руки делают, голова думает потом. То есть сейчас потратить 2—3 недели на маркирование зон и обучение персонала, а когда оборудование придет, то уже заняться перестановкой. В общем, из-за накопившихся разногласий (этот пример — не единичный) мы попрощались. Что стало в итоге через три месяца? Просрочка и хаос вернулись, ведь голова стала думать, как раньше. Поэтому я в своей работе всегда и начинаю с работы с основателем и первым лицом, иначе все впустую.

Есть телевизионное шоу «На ножах», где Константин Ивлев проводит различным заведениям антикризисное управление и уходит. Когда его спросили: «А сколько из этих заведений живы и развиваются через год?», он ответил, что таких около 30%. И ответ здесь тот же — мышление руководителя не поменялось.

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

Вернемся к нашей теме и практическому примеру. Как думаете, к каким последствиям мог привести такой подход, без планирования и проработки? Были бы простои и хаос. А что, если заранее его распланировать, проработать основные риски? Правильно, можно сэкономить деньги и время.

Основные виды рисков

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

Глобальные или системные риски:

— Политические — изменение политической ситуации в стране и мире.

— Природные риски — экологические катастрофы или стихийные бедствия.

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

— Экономические — изменения в налоговой системе, санкции против государства, потери из-за нестабильности курсов валют и т. п.

Частные, или локальные риски:

— Производственные — производственные и управленческие ошибки и ограничения, в том числе невыполнение плана продаж, сокращение объёмов производства.

— Финансовые — недополучение прибыли от проекта, неликвидности продукции

— Рыночные — нестабильность ситуации на рынке, например, спрос, ценовая политика компании, конкурентная борьба

Еще одна классификация приведена ниже.

Общий алгоритм работы с рисками

Среди документов, на которые можно опираться в работе с рисками, хочу выделить ГОСТ Р ИСО 31000—2019. Он предполагает следующий алгоритм обработки риска:

Выявление и оценка риска

Выявлять (идентифицировать) риски можно при помощи:

— ретроспективного анализа

— анализа текущего проекта

— анализа возможных событий

Ретроспективный анализ прошлых проектов.

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

И даже если вы работаете по Agile, это все равно полезно, ведь постепенно вы научитесь качественно планировать и учитывать наиболее критические риски, что будет неплохим бонусом по сравнению с конкурентами. Да, возможно, вы будете брать даже меньше проектов, но они будут приносить больше прибыли, чем проблем.

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

Анализ текущего проекта

Тут изучаем входную информацию о проекте:

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

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

— есть ли карта стейкхолдеров, оценено ли их влияние и план работы с ними;

— есть ли поддержка от первых лиц;

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

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

Анализ возможных событий

Это самое сложное направление — моделирование будущего. Тут применяются сложные математические и экспертные подходы: SWOT, мозговые штурмы, метод сценариев, интервью, диаграммы Ишикавы, деревья отказов и перечни-подсказки (PESTLE, SPECTRUM, TECOP), а также всевозможные методы моделирования.

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

Возможные стратегии работы с рисками

Исключение

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

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

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

Минимизация

Это наиболее распространенная стратегия. Её задача — заранее проработать риск и минимизировать вероятность его наступления и/или тяжести последствий.

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

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

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

Принятие

Здесь все просто — до наступления риска предполагается «ничего не делать». Однако совсем ничего не делать — это не управление рисками. Тут есть два варианта — активное и пассивное принятие.

Активное — формируется резерв времени и денег на устранение последствий материализации риска. Так, самое распространенное правило для более-менее понятных проектов — заложи резерв 30—35% на различные форс-мажоры и непредвиденные расходы. Но здесь есть два ограничения:

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

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

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

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

Делегирование

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

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

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

Инструменты принятия решений

Матрица рисков

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

Упрощенная версия — 3х3:

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

Есть также и более крупная версия — 5х5.

Соответственно, из этого рождается следующий алгоритм:

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

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

— для зеленой зоны вполне приемлема стратегия принятия.

Анализ «галстук-бабочка»

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

Алгоритм построения

— В центре — название риска;

— Слева — причины возникновения риска;

— Справа — возможные последствия;

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

Дальше идут снова математические методы моделирования, которые я разбирать не буду, ибо вряд ли вы будете ими пользоваться, но перечислю:

— Моделирование методом Монте-Карло — метод математического моделирования событий с помощью случайных величин и факторов;

— Байесовский анализ и сеть Байеса — использование статистических методов для расчета условной вероятности наступления события;

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

Недостатки текущих подходов к оценке и выявлению рисков

Итак, мы погрузились в работу с рисками. Это очень сложное направление с большим набором инструментов. В чем общая проблема всего направления работы с рисками?

— Высокая сложность математических методов.

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

— Высокие трудозатраты.

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

— Субъективность.

Многие методы крайне зависимы от личности эксперта и/или аналитика. Но к чему приводит человеческий фактор и какие типовые ловушки бывают?

— эффект «репрезентативности» — переоценка надежности малых выборок, неслучайный характер выборки;

— эффект «наглядности» — переоценка «понятных», запоминающихся рисков;

— эффект «эгоцентризма» — ориентация на собственный опыт, а не на данные;

— эффект «консерватизма» — жесткость сложившегося мнения о каких-либо событиях;

— эффект «края» — недооценка высоко вероятных событий и переоценка маловероятных (при этом слишком малая вероятность может вообще не восприниматься);

— эффект «Монте-Карло» — стремление установить связь между двумя последовательными событиями, в том числе это можно назвать апофенией;

— конформизм — это следование правилам, установкам и нормам группы под влиянием реального или воображаемого давления;

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

А теперь посмотрим, что мы видим в жизни? Здесь приведу результаты опроса с Телеграмм канала Михаила Софонова.

Как, думаете, у нас принято работать с рисками? Есть ли вообще культура работы с рисками?

Короткий ответ — нет. Я практически никогда не видел качественной работы в этом направлении: ее либо нет, либо она формальная.

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

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

— на старте проекта, в стадии инициации и планирования, прорабатывались основные риски и стратегии работы с ними;

— в реализации проектов велся хотя бы дневник с записями всех событий и сработавших рисков;

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

Новое решение

К чему в итоге мы приходим? Во-первых, появляются глобальные инициативы вроде ESG. Подробнее об этом направлении мы уже говорили в первой книге. Во-вторых, начинают появляться цифровые инструменты на основе искусственного интеллекта. Я сейчас, в 2023 году, работаю над своим цифровым советником для управления проектами. Это не трекер типа Jira и не система управления проектами типа Advanta. Это именно система поддержки принятия решений, формирования культуры проектного управления без привязки к конкретному программному обеспечению.

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

Как в целом решается вопрос проектного управления? Если мы говорим про крупные компании и корпорации, то там есть некий стандарт или внедрена какая-то ИТ-система, в работоспособность которых менеджеры свято верят.

Однако невозможно создать понятный стандарт на все виды проектов. Сколько я не видел таких примеров, это, как правило, огромная бумажка, которую 99% сотрудников не читали или читали, но не поняли. А проектов все больше и больше, и хоть какими-то навыками проектного управления обладают только 10% от всех, кто в них задействованы.

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

Если же говорить про молодые компании и стартапы, то они говорят «мы Agile», ставят какой-то трекер задач и все.

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

Кроме того, и в Agile есть элементы, которые надо соблюдать:

— вести обучение по итогам каждого проекта: какие риски сработали, какие не учли, как можно планировать;

— управлять ожиданиями клиента, то есть держать с ним связь, привлекать к оценке промежуточных этапов, снимать нереализуемые «хотелки»;

— выполнять принятые на себя обязательства;

— постоянно оптимизировать процессы.

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

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

Также клиенты не любят, когда в план заложены огромные запасы времени / бюджета, под которые подгоняется содержание работы.

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

Так что же такое Agile? Добро или зло? Это инструмент, в котором фокус умственной работы смещается на заключительные этапы проектов, а не начало.

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

А как его применять — зависит от вас. Атомной энергией тоже можно обеспечить мир, а можно и уничтожить все живое.

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

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

При этом уже сейчас существуют цифровые решения для оценки рисков. Например, RISKGAP. Причем это российский продукт, и мы планируем интегрировать эту систему в наше решение.

В чем же плюс цифровых систем?

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

— возможность влиять на всю систему / культуру в компании;

— автоматизированный учет опыта;

— объективность и непредвзятость;

— возможность отслеживания тенденций и систематизации «внешнего» опыта;

Но есть и минусы:

— необходимы большие данные для качественного обучения систем — высокая сложность;

— недоверие пользователей / сотрудников;

Резюме 4 главы

Проектное управление — само по себе сложное направление менеджмента, которое освоено еще очень слабо.

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

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

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

— компьютер должен быть в корпоративной сети (в крупных компаниях именно так);

— компьютер должен быть доменным;

— в AD системе не должно быть ошибок и так далее.

И в итоге из-за этих «но» все будет работать через коленку, а вам все равно придется делать инструкции и заходить на корпоративный портал обходными путями. Пока будут выполнены все «но», пройдет 1—2 года. Поэтому лучше эти эволюционным путем — сначала сделать пилот в одном подразделении с классическим входом через логин и пароль, возможно, с добавлением двухфакторной авторизации (через дополнительное СМС с кодом). После пилота собрать все ошибки, отработать и масштабировать на остальные подразделения. А когда все условия идеальной модели будут выполнены, уже заниматься бесшовными входами и интеграциями.

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

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

Инициация

— Определены цели проекта (коммерческие, маркетинговые, технические, производственные, операционные) и его границы, в том числе сроки и бюджет.

— Определены эффекты, критерии успешности и установлены целевых показатели (метрики).

— Проведена оценка технической и ресурсной (деньги, технологии, компетенции) возможности реализации.

— Выявлены главные заинтересованные лица, их интерес и отношение к проекту, степень влияния.

— Определены ограничения проекта / ключевые риски, в том числе вероятности наступления и тяжесть последствий.

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

— Оценена потребность во внешних поставщиках.

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

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

— Подготовлен устав проекта.

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

Планирование

— Подготовлено техническое задание, в котором описан продукт проекта и ключевые требования к нему и его качеству, метрики.

— Определен подход к реализации проекта и поставке продукта.

— Определена потребность в доработках типового решения (для проектных продаж).

— Определена структура работ (какие работы необходимы и в какой последовательности, как они взаимосвязаны).

— Подготовлен календарно-сетевой план (работы разбиты по времени).

— Подготовлен план потребности и обеспечения ресурсами, определены источники ресурсов, подготовлен финансовый план (если необходимо).

— Определена модель реагирования на риски.

— Определены зоны ответственности участников проектной команды.

— Подготовлен план коммуникаций и отчетности (кто, с кем, когда, о чем, в каком формате и виде, через какой канал коммуникации).

— Подготовлен план внедрения изменений.

— Подготовлен план работы с внешними поставщиками.

Реализация и контроль

— Ведется контроль исполнения плана проекта и отклонений по срокам, объемам/содержанию, бюджету.

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

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

— Контролируется исполнение плана внедрения изменений.

— Ведется дневник коммуникаций.

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

— Идет управление командой и внутренними взаимоотношениями.

— Фиксируются все запросы на изменения.

Завершение

— Подготовлена рабочая документация.

— Подписаны закрывающие документы.

— Проведена оценка проекта участниками команды, руководителем проекта, клиентом/спонсором, конечным пользователем продукта и куратором.

— Проведена ретроспектива проекта (что реализовано хорошо, что плохо, какие риски и что дополнительно нужно учесть на стадиях инициации и планирования в следующий раз).

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

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

Устав проекта

Начальные условия (Project Background)

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

Цели и ожидания проекта (Project Objectives / Expectations)

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

Содержание и результаты (Scope and deliverables)

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

Ключевые требования и характеристики (Requirements and Characteristics)

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

Важно указать, какую документацию, информацию, доступ к системе заказчика и т. п. мы хотим получить до начала и/или по ходу проекта.

Орг. структура и коммуникация (Organizational Structure & Communication)

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

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

Сроки выполнения проекта

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

Допущения и ограничения, основные риски

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

Вообще устав / паспорт проекта довольно гибкий инструмент. Вот пример необходимого минимума.

— Краткое наименование проекта

— Дата начала проекта и завершения проекта

— Цели проекта

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

— Объем / границы проекта

— Главные риски/ограничения проекта

— Необходимые материальные ресурсы и компетенции команды

— Основные участники команды проекта Исполнителя (менеджер проекта, техническая реализация, куратор)

— Участники проекта со стороны Заказчика (кто платит, кто отвечает за проект, пользователь продукта проекта)

А вот пример типового, относительно крупного проекта.

— Аннотация

— Терминология

— Полное наименование проекта

— Краткое наименование проекта

— Дата начала проекта и завершения проекта

— Цели проекта

— Предпосылки проекта

— Благоприятствующие связи с другими проектами

— Препятствующие связи с другими проектами

— Критерии оценки успешной реализации проекта, в том числе метрики

— Требования к продукту проекта

— Ожидаемые эффекты проекта

— Объем/границы проекта

— Необходимые материальные ресурсы

— Менеджер и стейкхолдеры проекта

— Организационная схема реализации проекта

— Функциональная ответственность участников проектной команды

— Коммуникации проекта

— Перечень этапов работ и их результатов

— Риски проекта

— Решение проблем проекта

И чем крупнее и сложнее проект, тем больше и подробнее должен быть устав/паспорт.

Еще вам помогут следующие рекомендации.

— Подход управления выбирается под конкретный проект. Невозможно создать универсальный инструмент. И успешные компании, по исследованиям, используют именно такой подход.

— Большое внимание уделяется подготовке к запуску проекта: инициации и планированию. Определите миссию и создаваемую ценность, сочетание со стратегией, цели, критерии успешности, заинтересованных лиц, риски. Стадии инициации и планирования самые опасные и критичные, на них может уходить до 30—40% времени проекта. Лучше прежде подумать, чем делать, а не сначала сделать, а потом бегать и думать: «кого наказать?».

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

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

— Сейчас эпоха гибридов и поиска баланса «гибкость — эффективность — соблюдение бюджетов и сроков».

— Актуальный тренд — ориентация на создание ценности для потребителя, создание комплексных продуктов.

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

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

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

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

— структура нормативно-справочной информации;

— оцифровка данных, модель данных и последующая аналитика;

— уход от ручного ввода данных в пользу интернета вещей, автоматизации и RPA;

— создание правил работы с данными, критерии их качества (каких правил надо придерживаться);

— определение показателей, которые будем использовать для принятия решений после внедрения IT.

Глубже погрузиться в это направление можно в цикле статей по QR или ссылке.

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

Например, решили запустить B2B-портал для закупок запчастей к производственному механизму. Помимо того, что надо сделать все, чтобы этот портал заработал, необходимо еще и продумать ценностное предложение: понять, что именно нужно вашим дилерам, какие товары наиболее востребованы, то есть провести анализ того, что у механизма обычно ломается, возможно, внедрить датчики для сбора данных и формирования цифрового двойника. Тогда вы сможете создать B2B-портал, на котором всегда будут в доступе наиболее востребованные запчасти, и клиенту будет выгоднее ехать к вам. А дилер сможет продавать контракты полного жизненного цикла. Но это уже вопрос продуктового управления и новых бизнес-моделей.

Завершу главу еще одним практическим наблюдением. Игнорирование инструментов и основных задач проектного управления в цифровизации — всегда залог провала. Например, те же доработки и изменения в 1С проходят месяцами, а то и годами. Все из-за того, что изначально игнорируется планирование, описание границ проекта и задач, разделение зон ответственности, а потом идет бесконечный сдвиг сроков и непонимание, в чем проблема и сколько еще нужно сделать, какой нужен бюджет. И неважно, какого размера компания: стартап это или гигант — ситуация настолько типична, что пугает.

Глава 5. Практики регулярного менеджмента: инструменты для быстрого эффекта

Введение

Классическая теория менеджмента к практикам регулярного менеджмента относит:

— управленческое планирование;

— делегирование полномочий;

— работу с обратной связью подчиненных;

— организацию совещаний;

— работу с кадрами и решения относительно людей;

— оценку эффективности работы сотрудников;

— развитие кадров.

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

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

Ключевые инструменты

SMART-задачи

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

— S — Specific / конкретность, четкость

Задача должна быть четкой и понятной, без принципа «додумывай сам». Обычно формулировки вроде «это и так понятно» или «ну, подумай сам» — это повод усомниться. Как правило, за этим скрывается банальная недоработка руководителя: либо поленился, либо не знает. И даже если мы говорим про ситуации неопределенности и Agile, то нам никто не мешает четко формулировать свои задачи и гипотезы. В принципе, гипотезы и отличаются от идей проработанностью и ясностью.

— M — Measurable / измеримость

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

— А — Achievable / достижимость

Задача должна быть достижимой. Помню, в одной компании, где я работал, руководство хотело захватить чуть ли не 100% российского рынка, выдавив мировых гигантов (Shell, Mobil, Total). Результат — до сих пор (спустя 8 лет) почти никто не знает об их продукции. Если вы будете ставить невыполнимые задачи, то очень скоро люди просто начнут уходить.

— R — Relevant / релевантность

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

— T — Time bound / ограниченность во времени

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

По моему личному опыту, использование лишь одного этого инструмента повышает производительность на 50—200%. Зависит от слаженности команды, категории зрелости сотрудников, структурированности текущей работы.

Этот инструмент очень хорошо помогает экономить мыслетопливо, которому посвящена целая книга Максима Дорофеева «Джедайские техники».

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

Вам самим комфортно играть в «принеси то, не знаю, что, не знаю, когда, и не задавай глупых вопросов», а потом еще и получать наказание, если неправильно угадал?

Управление по целям и Kanban

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

Какой выбрать инструмент — без разницы. Я люблю Trello, как вы уже догадались, за простоту. Но можно использовать и Битрикс, и Джиру, и что угодно. Главное — придерживаться нескольких правил:

— Для каждой задачи / цели должны быть сроки и ответственные исполнители.

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

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

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

— Ведите обсуждения внутри карточек задач.

— Перенос сроков обязательно сопровождайте комментарием о причинах.

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

Категории зрелости

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

Итак, суть инструмента очень проста. Есть 4 категории зрелости сотрудников и 4 метода работы с ними.

4 категории зрелости работников:

— Не может и не хочет (R1)

— Хочет, но не может (R2)

— Может, но не хочет (R3)

— Хочет и может (R4)

Определить уровень не так уж сложно. Им соответствуют 4 стиля управления:

— Авторитарный (S1)

— Наставничество (S2)

— Продажа идей (S3)

— Делегирование (S4)

Эффект SMART-задач зависит от зрелости персонала. На 1 и 2 уровне зрелости это обязательно к применению, инструмент даст крайне высокий прирост. На 3 и 4, казалось бы, эффект не так очевиден, но даже самому зрелому сотруднику нужно понимать, что от него ожидают. Иначе, как я говорил, он будет тратить огромное количество энергии на «расшифровку», а в итоге выгорит и просто уйдет.

Ограничение количества рабочих задач

Наткнулся я на этот инструмент в книге Максима Дорофеева «Джедайские техники» (глава 4.3.5). Этот человек для меня вообще стал открытием 2020 года.

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

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

И кстати, этот инструмент очень тесно связан с теорией ограничения систем (ТОС). Автор ТОС, Элиаху Голдратт, при работе с Израильскими ВВС выявил интересную закономерность: когда на каждого из самых умных инженеров приходилось 50 задач, то средний срок решения 1 проблемы был 135 дней. После того, как списку «входящих» поставили лимит в 3 задачи, срок решения 1 проблемы стал 30 дней.

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

— В 2 раза увеличилось количество завершенных дел в месяц на каждого следователя. Соответственно, и очередь из дел сократилась на 50%.

— Повысилось качество работы: исчезли возвраты из прокуратуры на доследование, 50% дел стали закрываться в досудебном порядке.

— Ушел стресс и конфликты в работе.

Да, применение современных цифровых инструментов позволяет лучше и легче отслеживать задачи, минимизировать риски срыва сроков, быстрее между ними переключаться. Но есть ограничение в нашей психике: мы — не производственный конвейер, и нам нужно от 20 до 40 минут на включения в задачу, а когда нас отвлекают, это может быть больно. Вот вы знаете людей, способных виртуозно и безошибочно все организовывать? А главное, быть настолько психологически устойчивыми, чтобы не начать делать все сразу или не начать переключаться между задачами в хаотичном порядке. Лично я сам себя не раз ловил на этой ошибке.

Идеальность выполнения всех задач

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

Но давайте зададимся вопросом, а много ли великого мы творим каждый день? Не открою Америку, если скажу, что 80% вашей работы оказывается в ведре. При этом, думаю, многие знают, что последние 10% результата даются труднее всего и могут съесть до 50% всех ресурсов на задаче. И далеко не всегда они создают критичную ценность. Проще говоря, порой последние 10% — потери на излишнюю обработку.

А теперь представьте, сколько усилий вы тратите впустую, когда заставляете подчиненных делать все идеально? Лично меня очень демотивировала ситуация, когда я старался, выискивал ошибки, готовил обоснования, а в итоге 90% этой работы уходило в помойку. Думаю, подобное знакомо многим.

Какое же решение? Выделите те самые 20% важной работы и требуйте ее идеального выполнения. Остальное вполне можно делать на 90%, результат будет тот же, а успевать станете больше.

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

— не сделана совсем;

— сделана, но не может быть принята;

— сделана на минимально требуемом уровне;

— сделана хорошо, но можно еще улучшить;

— сделано отлично.

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

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

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

Стандартизация и шаблоны

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

На стандартизацию операций делается упор и в методике 5S. Через этот инструмент вы получаете отправную точку к закреплению опыта и дальнейшему совершенствованию, снижению потерь. Причем стандартизация может быть банальным чек-листом к задаче.

Шаблоны же позволят выполнять текучку на необходимые для успешности 80—90% процентов и сократить трудозатраты в 2 раза. Как итог — приемлемый результат с минимумом усилий.

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

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

Делегирование

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

Ранее мы обсудили такие инструменты как SMART-задачи, категории зрелости работников, шаблоны и стандарты, выстраивание точек контроля и управления по целям.

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

— Полномочия

— Ресурсы

— Ответственность

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

Проведение совещаний

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

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

В первой книге мы уже обсуждали пример, как оптимизация лишь одного совещания позволила снизить неэффективные затраты в небольшой компании на 500 тысяч рублей в год. Я предлагаю его вспомнить. Это было рядовое совещание по планированию производства и отгрузок. В нем ежедневно участвовало 3 человека, продолжительность около 1,5 часов. Средний ФОТ (зарплата + НДФЛ + социальные налоги) на 1 сотрудника составлял около 100 000 рублей в месяц, среднее количество рабочих часов в месяц — 164,3.

Простая арифметика говорит о том, что 1 час рабочего времени сотрудника обходится бизнесу в 608,7 рублей. Итого: 608,7*1,5*3 = 2 739 рублей на 1 совещание. В году около 247 рабочих дней, в результате получаем 676 506 рублей в год. Немало, правда ли? Но что же мы сделали?

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

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

После всех этих манипуляций совещания стали занимать 20—25 минут и двух человек. Теперь бизнесу все это стоит: 608,7*0,4*2*247= 120 279 рублей! То есть прямой эффект более 556 тысяч рублей в год. И это без внедрений дорогих решений. А главное — люди стали заниматься целевой работой.

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

— Подготовка.

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

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

Совещание должно проводиться в заранее определенное время по заранее определенной структуре.

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

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

2. Проведение совещания.

Четко придерживайтесь заранее определенной повестки.

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

Используйте модератора, который будет управлять дискуссией.

Саму структуру обсуждения рекомендую следующую:

— результаты предыдущего отчетного периода, причины невыполнения плановых показателей;

— план на этап/неделю, риски, чего не хватает, что будете делать превентивно, а что при наступлении негативного события;

— ответы на вопросы, дополнительные новости или форс-мажорные задачи;

— завершение.

3. После совещания.

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

— что решили по каждому вопросу, какие действия предпринимаете;

— кто ответственный;

— какие сроки.

Это закрепление принятых решений для исключения всяких «я не так понял» или «я не знал / не услышал». Резюме рассылается ВСЕМ заинтересованным и ответственным.

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

Итоги

Мы рассмотрели ряд простых инструментов:

— SMART-задачи;

— Управление по целям, использование Kanban-методики и цифровых сервисов;

— Ситуационное управление на основании уровня зрелости работников;

— Ограничение количества задач;

— Неидеальное выполнение «красных задач»;

— Стандартизация и шаблоны;

— Делегирование;

— Проведение совещаний.

Внедрение этих инструментов может повысить результативность на 50—300%, в зависимости от изначального уровня продвинутости системы управления. Зачем это? Чтобы делать больше полезного и продвигаться по службе или вовремя уходить домой и уделять время своему хобби и семье. Или и то, и другое.

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

А если их сочетать с цифровыми инструментами, то это может радикально изменить вашу рутину.

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

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