скачать книгу бесплатно
· Перед переходом к обсуждению вопросов повестки убедитесь, что ключевые участники присутствуют на совещании, повестка и материалы были доступны всем, а также что участники встречи знакомы друг с другом. Если необходимо, отведите 3-5 минут совещания на представления участников, а также время на ознакомление с материалами, не предоставленными заранее.
· Во время встречи модератор встречи должен следить за тем, что время, отведенное на каждый из вопросов, соблюдается участниками обсуждения. Следите за тем, что участники не погружаются в чрезмерные детали или не уходят от основной темы обсуждения. В подобной ситуации продуктивно прервать обсуждение и предложить провести отдельную встречу в кругу необходимых участников по отдельно взятому вопросу и/или перенести обсуждение в переписку. Не стесняйтесь прерывать участников.
· На совещаниях следите за тем, чтобы все участники имели возможность выразить свою позицию. Если вам как модератору не хватает мнения отдельного участника, спросите его напрямую, а не ждите, пока он выскажется первым. Следите за тем, чтобы одни участники не «давили» других на встрече и соответствующим образом модерируйте дискуссию. Старайтесь поддерживать комфортную и открытую среду для свободного обмена мнениями.
· В английском языке применительно к публичным выступлениям и переговорам используется выражение «less is more»: выражайте свои мысли максимально емко, избегайте слов-паразитов, деталей, не имеющих прямое отношение к предмету обсуждения. Это же правило применимо к слайдам презентаций и написанию документов. Следование данному принципу позволит донести ваши мысли для наибольшего количества участников и удерживать дискуссию в рамках повестки.
Этап 3. Окончание совещания
· За 3-5 минут до окончания совещания модератор встречи должен провести итоги совещания, резюмировать достигнутые договоренности и следующие шаги, с указанием сроков и исполнителей. Если по итогам совещания остались открытые / неохваченные вопросы, предложите дополнительные необходимые встречи и определите список участников – зачастую на таких встречах не требуется участие полного круга участников первоначального совещания. Если уточнение информации может пройти без обсуждения, предложите перенос данного вопроса в переписку и договоритесь о дальнейших шагах после уточнения вопроса. После окончания встречи в тот же или на следующий рабочий день продублируйте достигнутые договоренности в письме участникам встречи в формате, использующемся в компании (протокол встречи, email, реестр договоренностей) и укажите время, в течение которого участники встречи могут дать свои дополнения/исправления в случае искажения модератором договоренностей.
ПРИМЕРЫ ОШИБОК
• Время встречи превышает плановое
• Не назначен ответственный за ведение встречи
• Документы не отправлены участникам до встречи
• В приглашении не указаны вопросы для обсуждения
• Не определен ответственный за фиксацию договоренностей по встрече
• После окончания встречи отсутствует четкое понимание следующих шагов
ОСНОВНЫЕ РЕКОМЕНДАЦИИ
• Репетиция. Многие ораторы тратят десятки часов на репетицию выступления
• Используйте команду. Приглашайте коллег, расскажите им ваш доклад, они окажут незаменимую помощь
• Подготовка заметок к выступлению. Это не зазорно, лучшие ораторы используют заметки
• Перед выступлением подготовьте четкий план с вопросами на обсуждение. Во время обсуждения вопросы, не относящиеся к теме, можно перенести на отдельную встречу, чтобы сэкономить время присутствующих
В моей практике были проекты, на которых количество совещаний доходило до тысячи. Для крупных кроссфункциональных проектов рекомендую вести реестр всех совещаний. Использование реестра помогает быстро ориентироваться в достигнутых договоренностях. Шаблон такого реестра представлен ниже (см. Таблица 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. Предоставить методы и инструменты реализации проектов повышения операционной эффективности, которые применяются международными компаниями.
История развития методологии повышения операционной эффективности
