Лучшие практики управления компаниями
ПРИМЕРЫ ОШИБОК
• Время встречи превышает плановое
• Не назначен ответственный за ведение встречи
• Документы не отправлены участникам до встречи
• В приглашении не указаны вопросы для обсуждения
• Не определен ответственный за фиксацию договоренностей по встрече
• После окончания встречи отсутствует четкое понимание следующих шагов
ОСНОВНЫЕ РЕКОМЕНДАЦИИ• Репетиция. Многие ораторы тратят десятки часов на репетицию выступления
• Используйте команду. Приглашайте коллег, расскажите им ваш доклад, они окажут незаменимую помощь
• Подготовка заметок к выступлению. Это не зазорно, лучшие ораторы используют заметки
• Перед выступлением подготовьте четкий план с вопросами на обсуждение. Во время обсуждения вопросы, не относящиеся к теме, можно перенести на отдельную встречу, чтобы сэкономить время присутствующих
В моей практике были проекты, на которых количество совещаний доходило до тысячи. Для крупных кроссфункциональных проектов рекомендую вести реестр всех совещаний. Использование реестра помогает быстро ориентироваться в достигнутых договоренностях. Шаблон такого реестра представлен ниже (см. Таблица 13):
Таблица 13 – Шаблон единого реестра совещаний по проекту
2.7.8. Запросы на изменения
Если консультант сталкивается с задачами, которые не входили в основной договор, то необходимо рассчитать дополнительный объем работ. Для этого используется шаблон запроса на изменения. Этот инструмент взят из ИТ-проектов по доработке информационных систем заказчика. Если во время разработки выясняется, что нужен новый функционал, отсутствующий в изначальных функционально-технических требованиях, то разработчики оценивают дополнительные работы. Такой же подход используют при реализации проектов управленческого консультирования.
Для эффективного управления запросами на изменения используется файл с автоматическим расчетом затрат на выполнение требования с учетом вовлечения сотрудников компании в зависимости от ставок (стоимости) привлекаемых позиций консультантов (см. Рисунок 13).
Рисунок 13 – Иллюстрация шаблона для расчета запросов на изменения
2.7.9. Управление рисками
Во время реализации сложных проектов всегда встает вопрос управления внутренними и внешними рисками. Это отнюдь не формальная процедура и каждый уважающий себя руководитель проекта должен ее выполнять на совесть. Чтобы сделать изменения управляемыми, хорошие менеджеры регулярно оценивают потенциальные риски проекта и разрабатывают решения. Плохие менеджеры игнорируют риски. Серьезное отношение к управлению рисками приходит с опытом. Когда понимаешь, что на самом деле можно было заранее предвидеть реализованный риск и успеть принять соответствующие меры. На консалтинговых проектах обычно риски выражаются в сдвиге сроков ИТ-разработок из-за недооцененного функционала, ухода ключевых членов команды, неконтролируемого разрастания бюджета из-за некорректной оценки объема работ на начальном этапе. В крупных компаниях управлением рисками занимаются целые подразделения, которые отслеживают влияние различных событий на репутацию компании на рынке, снижение влияния производственной деятельности на окружающую среду, прорабатывают различные сценарии реагирования на политические и внешнеэкономические риски.
Для управления рисками мы разработали и используем специальный инструмент – матрицу рисков и контрольных процедур проекта (см. Рисунок 14).
Рисунок 14 – Иллюстрация шаблона для реестра рисков проекта
Каждый риск оценивается по трем критериям:
• Вероятность возникновения риска – насколько вероятно возникновение риска на проекте.
• Влияние на проект – на сколько реализованный риск оказывает влияние на эффективность проекта
• Оценка риска общая рассчитывается на основании произведения баллов по вероятности и критичности возникновения рисков.
Данная матрица используется для приоритизации и последующей разработки решений, соразмерных каждому риску. Это означает, что мы никогда не забываем знаменитый принцип Макиавелли: «Цель должна оправдывать средства». На практике мы применяли матрицу при реализации крупных трансформационных проектов, когда нужно было внедрять новые бизнес-процессы на тысячах пользователей и учитывать возможные риски остановки процесса на каждом из этапов, выбирали ИТ-систему для крупной нефтехимической компании России и необходимо было учитывать риски наложения санкций и запретов на использование облачных решений, реструктуризировали производство на заводе и необходимо было учитывать риски временного ухудшения качества производственных показателей.
2.7.10. Управление задачами клиента
Чтобы организовать системный контроль над исполнением задач, необходимо вести единый реестр задач клиента и консалтинговой компании. По мере реализации проекта неизбежно будут возникать дополнительные задачи, для контроля исполнения которых важно поддерживать единый реестр в актуальном состоянии (см. Таблица 14).
Таблица 14 – Шаблон реестра всех задач проекта
Единый реестр задач позволяет систематизировать работу по многочисленным задачам крупного проекта:
1. Вести полный учет всех задач по проекту.
2. Приоритизировать работу по наиболее важным из множества задач.
3. Контролировать сроки исполнения задач.
4. Своевременно выявлять сложности на проекте для принятия управленческих решений.
Также структурируют работу с клиентом и играют роль единого реестра задач облачные инструменты, такие как Trello, Jira, YandexTracer.
2.7.11. Организация работы над ошибками
Не секрет, что ошибаются все. Хорошие консультанты работают над своими ошибками, плохие – нет. Самое страшное – это допускать повторение своих ошибок. На лучших проектах существует инструмент по работе с ошибками – сессии, на которых определяются причины и проговариваются решения. Такие сессии проводятся без записей, потому что на них по-честному обсуждаются все проблемы и подводные камни, с которыми сталкиваются компании, а записи рождают риски.
В 2013 г. в московском офисе Accenture новый руководитель практики management consulting ввела практику: каждый руководитель проекта и его команда докладывали о результатах выполненного проекта. С тех пор я взял себе это на вооружение. Материалы для такого собрания специально не готовили, показывали презентации с проекта «как есть». Цель сессии – поделиться опытом с другими руководителями и командами, рассказать про проблемы, с которыми столкнулись, и показать решения, которые принимались.
В EY существует практика knowledge sharing session (KSS). Практика представляет собой проведение регулярных совещаний (не реже, чем один раз в квартал) с участием всех команд консалтинга. В рамках сессии готовятся презентации по реализованным проектам по стандартной форме, и с ними выступают команды, реализовавшие проект.
Они включают:
• содержание проекта, чтобы были понятны масштаб и предметное поле (1 слайд);
• выработанный подход, который позволил достичь результата (1–2 слайда);
• «находки» (findings) – «ноу-хау», которые были реализованы в проекте и должны тиражироваться на всю консалтинговую практику;
• выученные уроки (lessons learned) – ошибки, которые совершила команда, способы их митигации или предотвращения, о которых должна знать вся практика во избежание повторения другими командами.
Подобные сессии – это и формирование базы знаний, и обучение подходам, и знакомство консультантов с другими командами.
В крупнейшей в мире компании, специализированной на рынке платформ электронной коммерции и публично-облачных вычислений подобные сессии проходят при участии клиентов, где клиенты (на дружеских началах) рассказывали про свои задачи, приоритеты, ожидания. Менеджеры по продажам, в свою очередь, могли задавать вопросы и так готовиться к собственным продажам определенных ИТ-решений с уклоном на аудиторию (CIO, CTO, CMO и другие).
2.8. Закрытие проекта
2.8.1. Сбор данных по бенчмаркам
Во время исполнения проекта у вас есть доступ к информации клиента и возможность собирать ее для продажи и реализации будущих проектов. Очень плохо, если по завершении проекта вы не знаете, как организованы смежные функции у вашего клиента. Плохо, если такое знание есть, но остается только у ваших руководителей в голове, когда не организован процесс передачи информации последующим командам.
Правило хорошего тона: собрать и структурировать всю первичную и обработанную информацию от членов команды в единую базу знаний, предварительно почистить данные для соблюдения политик конфиденциальности и удалить всю персональную информацию.
2.8.2. Оформление результатов проекта
Результаты проекта – это фундамент любой консалтинговой практики. На основе результатов прошлых проектов формируются новые коммерческие предложения, обучаются новые команды, черпаются идеи и гипотезы для новых проектов. Поэтому время, затраченное на описание результатов проекта и перевод на английский (общепринятый язык), – одна из лучших инвестиций в практику и себя.
Оформляйте результаты работ сразу по окончании проекта, а лучше в процессе, так как потом может не оказаться времени.
Best-in-class (лучший в своем РОДЕ) итоговый набор документов включает:
1. Оформленное на одной странице «резюме для руководства» в типовой структуре, которое позволит быстро вспомнить, о чем проект и может ли он быть полезен. Оно сэкономит массу времени за счет того, что не надо листать весь дек на 300 слайдов. Оформляйте результаты проекта в одном формате, чтобы потом можно было быстро собрать их для демонстрации потенциальному клиенту. Рекомендованная структура:
• Описание ситуации.
• Что было сделано?
• Подход к решению.
• Достигнутый результат.
2. Краткая версия презентации позволяет организовать обучение новой команды, быстро погрузиться в подход, найти нужных людей и понять образ результата.
Типовая структура презентации:
• План проекта (верхнеуровневый).
• Организационная структура.
• Основные направления на проекте, результаты по этим направлениям.
• Подходы.
• Команда, вовлеченная в проект.
3. Структурирование архива. Обычно в команде консультантов 3–5 человек, но иногда 10–15. При этом проект всегда состоит из нескольких модулей. Вся команда и модули накапливают огромное количество информации, которая потенциально может понадобиться для бенчмаркингов и обучений. Важно провести ревизию и:
– удалить всю информацию с персональными данными;
– санитизировать клиентские данные;
– удалить все промежуточные или временные файлы;
– разложить все файлы по папкам. На этом этапе вам очень поможет, если вы в самом начале зафиксировали для всех консультантов единую структуру папок. Теперь их останется только пересобрать.
Рисунок 15 – Иллюстрация шаблона для фиксирования результатов проекта
2.8.3. Предложения по допродажам
Критерием успешной реализации текущего проекта является дополнительная продажа нового проекта. Как правило, когда «экватор» проекта уже пройден, мы ищем возможности для потенциальных проектов и готовим предложения, которые обсуждаем с руководителем практики. Обычно партнеры внутри команды организовывают сессии («мозговые штурмы»), на которых формируется длинный список потенциальных направлений. Идеи появляются на базе информации, полученной во время работы. Иногда клиент сам говорит о болевых точках. Но главное – это пересечение на стыке глубокого понимания повестки клиента, рынка и точек развития клиента.
Также многое зависит от того, частная или государственная компания, от отношения менеджмента к консультантам (не является секретом распространенное мнение собственника: «Я вам плачу огромные бонусы, чтобы вы работали сами, а не нанимали консультантов»), цикла смены руководства. В любом случае хорошие партнеры умеют управлять этими факторами и получать проекты не от тендерной команды (см. Рисунок 16).
Рисунок 16 – Иллюстрация шаблона для реестра «opportunities» проекта
2.9. Одиннадцать правил консультанта
Мы наблюдали, как приходили ребята из индустрии и становились хорошими консультантами, драйвили наш бизнес. И замечали тех, кто не становился. Вот список правил поведения, которые, насколько нам известно, отличают хорошего консультанта от плохого. Не нужно переспрашивать у вашего руководства по каждому правилу: «Действительно ли это нужно делать?». Просто следуйте им.
Выводы и рекомендации
В данном разделе вы увидели отражение боли и разочарования исполнителей (бизнес-консультантов), примеры ошибок, с которыми сталкиваются руководители компаний при достижении своих целей в развитии бизнеса, а также практические советы о том, как лучше управлять проектами для своей компании.
Раздел содержит описание примеров основных инструментов, применяемых на любом консалтинговом проекте.
В совокупности с принципами из первого раздела книги «КУЛЬТУРА РАБОТЫ» я убежден, что описанные в разделе практики помогут не опустить руки, столкнувшись с низкими стандартами, некомпетентным руководством и начальниками отделов, занимающих свои места с единственной целью – сохранить благоприятное для себя положение вещей, позволит организовать эффективную работу вашей организации вне засисимости от ее бизнес-модели, будь это крупная корпорация и ее задачи повышения прибыли, управления университетом и задачи по развитию его популярности и престижности среди абитуриентов, управление больницей и задачи повышения качества ее обслуживания и выручки, управление библиотекой и задачи повышения ее привлекательности для клиентов.
3. Повышение операционной эффективности
Работая в консалтинге, большую часть проектов я реализовал в области повышения операционной эффективности и считаю, что это самый интересный вид деятельности – когда ты, консультант, кризис-менеджер или новый руководитель, приходишь в новую компанию, проводишь диагностику, определяешь «узкие места» и разрабатываешь комплексную программу повышения эффективности бизнеса. Затем видишь, как твои изменения меняют процессы и влияют на результат и как меняется отношение сотрудников к производимым изменениям.
Договоры на проекты повышения операционной эффективности, как правило имеют структуру оплаты, основанную на success fee и составляют от 5 до 10% увеличенной за период проекта прибыли компании-заказчика. Стоимость проекта на моей практике варьировалась от 50 до 450 млн руб., отдельные крупные проекты достигали и 1 млрд руб. Срок реализации таких проектов, в зависимости от объемов работ, составлял от 3 до 15 месяцев.
В данном разделе мы хотим поделиться инструментами и подходами, которые будут полезны специалистам, ответственным за достижение показателей операционной эффективности компании, либо позволят руководителям максимально быстро выстроить программу повышения эффективности ее ключевых бизнес-процессов.
Информация по лучшим практикам и методологии представлена в разделе с описанием бизнес-кейсов, которые помогут дать представление о применении инструментов повышения операционной эффективности.
Цель раздела – показать лучшие практики повышения операционной эффективности бизнес-процессов компании и дать краткие комментарии по используемым инструментам.
Задачи:
1. Описать основные ошибки в организации эффективных производственных систем и выделить их «предвестников».
2. Предоставить обзор референтных моделей выстраивания производственных системм, а также процесса постоянного совершенствования.
3. Предоставить методы и инструменты реализации проектов повышения операционной эффективности, которые применяются международными компаниями.
История развития методологии повышения операционной эффективности
Методологию Lean Production разработала Toyota на основании методологий Total Quality Management и Zero Defects [20]. Методологию Six Sigma разработала Motorola, стандартизировав подход DMAIC. Консалтинговая компания George Group объединила эти две методологии в подход LSS (Lean Six Sigma) и начала оказывать консалтинговые услуги по проектам повышения операционной эффективности. Позже компания была выкуплена Accenture.
В основе методологии лежат 8 видов потерь, исключив которые можно сократить общее время исполнения любого процесса, а также уменьшить затраты [6, 8]:
• Запасы (материалы/продукты, ожидающие начала процесса).
• Движения (излишние движения, вызванные в том числе слабой эргономикой).
• Ожидания (задержки в процессе, вызванные согласованиями, остановками на ремонт).
• Перепроизводство (производство сверх необходимого).
• Избыточное качество (предоставление услуг или продуктовых характеристик больших, чем клиент готов платить за них).
• Дефекты/переделки (корректирование ошибок).
• Люди (недостаточное использование квалификации своих сотрудников).
Термин «Sigma», греческий символ δ – используется для оценки вариативности процесса, как индикатор количества ошибок. «Six Sigma» предполагает сокращение до 3,4 ошибки на 1 миллион (или 99,9997%) (см. Таблица 15)
Таблица 15 – Количество ошибок в зависимости от «уровня сигма»
От своих студентов я часто слышал вопрос: «Почему 99,9% недостаточно?». Чтобы ответить на этот вопрос, в классической литературе приводятся следующие примеры:
Объединенные Lean Production и Six Sigma вместе дают мощный инструментарий для повышения операционной эффективности любой компании. Для обучения высококлассных специалистов существует система сертификации специалистов LSS. Чтобы показать серьезность подхода к подготовке специалистов LSS приведем описание длительности курсов и их стоимости (см. Таблица 16):
Таблица 16 – Обучение LSS
1 Бралась информация со следующих учреждений: www.purdue.edu/leansixsigmaonline/payment/; www.sixsigmacouncil.org/six-sigma-certifications/; Стоимость курсов указана средняя и может быть выше или ниже в зависимости от формата обчения (онлайн или очное), состава преподавателей, наличия практики, бренда или ценовой политики обучающей организации.
2 Информация из www.hh.ru
Приведем примеры использования LSS в банковской индустрии. Конкретно на примере Сбербанка, где Герман Греф реализовал настоящую революцию с приходом в Сбербанк в 2007 г.
Мало кто знает, что у Сбербанка был КПЭ «5 минут» – любой клиент должен выйти из отделения банка через 5 минут с выполненной услугой. Давайте посмотрим на отдельные решения, узнаваемые для простого клиента банка, которые были реализованы, и насколько эффективными они оказались (см. Таблица 17).
Таблица 17 – Примеры внедрения инструментов LSS в банковской индустрии
Традиционный подход к управлению компанией состоит в фокусировке внимания на управлении 20% основных ресурсов, которые добавляют основную стоимость конечному продукту, либо услуге компании. Lean production фокусируется на работе с операциями, которые не добавляют ценности конечному продукту (устанение потерь), в том числе исключая операции, которые не важны для клиента и за которые клиент не готов платить. Six sigma фокусируется на улучшении качества за счет сокращения вариативности процесса, большое количество переделок выпускаемого продукта/услуги, низкое качество конечного продукта, заметное в промышленных масштабах. LSS учитывает методологию обоих направлений и фокусируется на постоянном совершенствовании всей системы.
Внедрение проектов повышения операционной эффективностиРеализуя множество проектов, мы сталкивались со следующими способами организации постоянного повышения операционной эффективности компании, как со стороны консультанта, так и внутри компании:
1. Инициатива идет от первого лица компании. Отдельная структура по развитию в компании отсутствует. Владельцы процессов (руководители) выполняют изменения. Обычно программа сопровождается массовыми увольнениями руководителей, которые не поддерживают переход к новой системе работы. Эта модель описывается во многих книгах как самая успешная и обеспечивающая лучший результат за счет полного контроля и абсолютной мотивации [63].
2. Самостоятельная работа руководителей. Инициатором изменений является отдельная структура (отдел развития). Первое лицо спрашивает по результатам изменений с директоров направлений. Директора отвечают за исполнение программы изменений, разработанной отделом развития, и запрашивают методическую поддержку. Наличие отдельной структуры создает владельцам процессов соблазн заниматься исключительно планом производства, а все, что связано с оптимизацией, поручить соответствующему отделу.
3. Самостоятельная работа структуры развития. Отдел развития является инициатором изменений, а также выполняет изменения, насильно вклиниваясь в деятельность руководителей, которых волнует только выполнение плана производства. Первое лицо лишь дает разрешение на деятельность по развитию, не вникая в процесс улучшений. Затем первое лицо компании спрашивает результаты по деятельности в сфере улучшений с отдела развития, а не с владельцев процессов. В процесс изменений первое лицо не погружается совершенно. Предполагается, что в такой структуре есть небольшая команда внутреннего консалтинга, которая что-то подкручивает, помогает, ускоряет. Первое лицо освобождается от забот по повышению операционной эффективности, полагаясь на эту команду. Руководитель внутреннего консалтинга изучает, как все устроено, выступает с предложениями по неким перестроениям процессов. В случае если там попадается что-то дельное, то сверху директорам направлений будет приказано реализовывать эти предложения. Если корпоративная культура развита, если собрана команда руководителей, заинтересованных в развитии бизнеса, а не в получении бонусов, тогда отдел развития улучшает процессы без участия первого лица. Отдел показывает выгоды директорам направлений, а они меняют свои процессы, чтобы все становилось эффективнее. Оптимизаторы должны убедить директоров, что предложения нужные и важные, тогда они их выполняют. А если изменения не внедряются, значит, плохо убеждали, или мероприятия не были проработаны до конца.
Это самая распространенная и самая неэффективная модель, которую мы встречали на большинстве предприятий, – отдел развития представляют перед коллективом так: «Представляю вам оптимизатора. Он будет повышать вот такие показатели». Но потом отдел развития услышит от сотрудников:
– «Не отвлекайте нас от выполнения плана производства».
– «Мое дело – собирать узлы, а не думать за вас».
– «Я из-за вас не успеваю делать свою работу, от которой зависит моя премия».
– «Если я усовершенствую процесс, то мне порежут трудоемкость, а я этого не хочу».
Развитие в такой структуре можно футболить сколько угодно: не приходить на совещания, не отвечать на письма, не давать запрашиваемую информацию, откладывать встречи.
Чтобы понять, почему так происходит, надо ответить на вопрос: «Кому выгодно что-то улучшать?». Зарплату от этого, скорее всего, не прибавят. Из-за этого работа по улучшению всегда будет факультативной, а начальники будут нехотя уделять этой деятельности свой ресурс.
Отдел развития может сделать блестящий пас, но гол все равно забивает первое лицо. Отдел развития может сделать блестящий пас, но гол все равно забивает первое лицо. Без значительного воздействия вертикали власти действительно важные изменения не делаются. Это воздействие выражается в том, какие вопросы и кому первое лицо задает на ежедневном совещании. Если вопросы касаются только выполнения плана производства, то и выполнять будут только его. Если во главу угла ставить выполнение плана, то владельцы процессов будут этим планом прикрываться вечно, уклоняясь от развития и состояние системы не сдвинется. А если сказать директорам, чтобы они занимались системой улучшений, но только тогда, когда это не повредит заказам, найдут ли они для этого хоть секунду? Каждый из начальников всегда может найти для себя занятие поважнее.