Текст книги "PRO реформы. Универсальные инструменты управления изменениями в компании"

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

Чек-лист для самопроверки

К концу этой стадии вы должны:

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

■ иметь документ, формализующий требования к кандидату;

■ составить список претендентов из вашей команды, которые годятся на эту роль;

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

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

Детальное проектирование предстоящих изменений

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

● тщательный анализ того, что предстоит сделать, с учетом информации, полученной на предыдущих этапах;

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

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

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

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

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

Итак, у вас есть общая концепция проекта трансформации, вы провели анализ, кто «за» и кто «против» и почему, собрали необходимые аргументы и понимаете, кто и по каким причинам вас может поддержать. Есть человек, который будет вести этот проект и персонально отвечать за успехи и неудачи. Теперь самое время положить на бумагу весь проект. Один мой коллега любил говорить: «Глупость написанная становится явной». Так и в любом проектировании изменений. Как только вы начнете составлять документ и описывать предстоящие изменения и последовательность их осуществления, у вас сразу же возникнет несколько развилок и вопросов. На этом этапе на качественно другом уровне можно анализировать, какие практические решения будут представлять реальные проблемы при их претворении в жизнь. Если вы детально разберете процесс осуществления отдельных этапов предстоящей трансформации, то это позволит выбрать оптимальный путь достижения цели с минимальным количеством «резких шагов», вызывающих отчаянное сопротивление. Конечно, невозможно найти маршрут, путь по которому был бы гладким и безболезненным. Любое изменение – это отказ от старого и проектирование нового, а это всегда вызывает противодействие. Однако моя практика показывает, что задуматься и найти такую траекторию изменений, которая позволяла бы избежать одновременного противостояния по нескольким ключевым трансформационным процессам, чрезвычайно полезно. Когда придет время управлять процессом внедрения изменений, наличие нескольких открытых фронтов приведет к существенным затратам времени и ресурсов. Подумайте, в какие моменты предстоящего проекта неизбежны конфликты, и подстрахуйте себя, спланировав к этим датам конкретные быстрые победы (quick wins). Почувствуйте себя режиссером захватывающего боевика и посмотрите варианты развития сюжета.

Анализ действующей бизнес-модели с учетом предстоящих изменений в системе управления

Конечно, начинать надо с анализа того, что конкретно представляет собой текущее состояние трансформируемого объекта. Разберитесь детально. Отлично работает метод, когда всем сотрудникам организации предлагается в течение четырех недель заполнять на ежедневной основе «лист учета рабочего времени» (time sheets) с четким указанием осуществляемой функции или задачи, времени выполнения этой функции или задачи и «заказчика», то есть того, в чьих интересах выполнялась работа. К сожалению, в большинстве компаний, особенно крупных, сотрудники живут по принципу «день прошел, и слава богу», «процесс – это жизнь, а результат – это смерть». Эффективность этого метода определяется в том числе и длительностью эксперимента. В одной из компаний, где по моей инициативе был запущен такой анализ, только на четвертой неделе сотрудники перестали искусственно придумывать, что конкретно они делали, и начали честно писать «перенос канцелярских принадлежностей – 2 часа». Такого рода анализ очень полезен для понимания избыточности численности, эффективности тех или иных процессов, начиная с дублирования или выполнения несвойственных функций и заканчивая принципами взаимодействия на стыках процессов. В свое время во время анализа полученных данных из таких «листов учета рабочего времени» мы даже ранжировали сотрудников по критерию «нужен в новой структуре / не нужен», «работоспособен / ленив и хитер» и т. д.

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

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

Понимание, какой вклад вносят сотрудники в достижение целей организации, – это важный обязательный шаг для анализа проблем, неэффективностей и других изъянов действующей модели бизнеса. Посмотрите на то, как устроены процессы, кто за что отвечает, во что обходится тот или иной функционал, где создается основная ценность бизнеса, а где шестеренки крутятся вхолостую. Когда вы погрузитесь в детали, то вам откроется много интересного. Как устроены низовые процессы, руководство чаще всего и не подозревает, особенно если это компания, которая работает десятки лет. Многое, что формировалось с первых дней ее существования, продолжает сохраняться под напластованиями новых управленческих конструкций. Получив бесценный материал, характеризующий ситуацию как она есть (as is), можно приступать к проектированию целевой модели (as to be).

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

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

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

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

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

Целевыми стратегическими показателями, положенными в основу программы реструктуризации, были сохранение доли атомной генерации в текущей корзине выработки электроэнергии на российском рынке в размере 17 % и создание конкурентоспособного продукта для строительства атомных станций на международном рынке (сроки, цена, технологические решения). С учетом графика выбытия действующих атомных блоков и возможности продления ресурса определился необходимый объем ввода новых мощностей до 2030 г. Сразу же были поставлены задачи по разработке нового типового блока со сроками строительства 60 месяцев, определенными фиксированными технологическими и ценовыми параметрами. Наметился предполагаемый график закладки новых блоков. Исходя из сроков строительства и количества строительных площадок, были сделаны расчеты и спроектированы параметры для предприятий, занимающихся добычей сырья, обогащением, фабрикацией, изготовлением тепловыделяющих элементов. Разработали также требования к проектным институтам и шаблоны для различных профессиональных компетенций, необходимых для реализации программы как для российского, так и для международного рынка. Сложив всю картинку и аккуратно подсчитав показатели на входе и выходе каждой подсистемы в общей бизнес-модели, стало видно разрывы в производительности отдельных элементов, а следовательно, и целевые параметры для их внутренней трансформации.

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

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

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

Разработка согласованного по разным процессам плана-графика изменений с перечнем мероприятий, сроков и ответственных

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

В результате у вас на столе должен оказаться рабочий продукт, содержащий:

● план-график;

● ключевые точки;

● критический путь.

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

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

В процессе реализации разных этапов проекта по управлению внедрением изменений вам, скорее всего, будет требоваться разный объем внутренних и привлеченных ресурсов. Это естественно. Одни процессы трансформируются легко, на других команда зависает. Многое также зависит от опыта и квалификации менеджеров следующего уровня в вашей команде. К тому моменту, когда сложится общий план-график с декомпозицией до конкретных работ по трансформации отдельных процессов, вы должны для себя определить не только «критический путь», но и выделить группу наиболее важных и трудоемких задач. Часть таких задач может лежать не на «критическом пути», но возможные осложнения и задержки при их осуществлении могут стать для вас весьма неприятным сюрпризом в процессе исполнения проекта. Безусловно, на стадии планирования вам не удастся выделить все такие процессы и задачи. Но я советую задуматься об этом и зафиксировать очевидных кандидатов в этот перечень. Это поможет вам при проектировании системы управления рисками проекта. Но самое главное – при распределении ответственности среди членов команды и наделении их дополнительными ресурсами вы точно будете знать, на какие задачи поставить наиболее способных подчиненных.

Чек-лист для самопроверки

К концу этой стадии вы должны:

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

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

■ разработать согласованный по разным проектам план-график изменений с перечнем мероприятий, сроков и ответственных;

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

Создание «управленческой обвязки» проекта

После того как детальное проектирование трансформации завершено, надо разработать управленческие процедуры и форматы отчетности для осуществления мониторинга и принятия необходимых управленческих решений. Это абсолютно рутинный и понятный управленческий шаг, однако отсутствие такого управленческого набора перед запуском проекта может привести к серьезным неприятностям в будущем. Здесь я хочу еще раз напомнить, что после вступления проекта в фазу реализации количество непредвиденных проблем и вопросов, по которым вам придется ежедневно принимать решения, будет нарастать как снежный ком. Многие менеджеры в такой обстановке попадают в ловушку «несистемных решений». Это особенно опасно при управлении процессом внедрения изменений в сложных системах. Естественно, когда та или иная текущая проблема начинает тормозить весь график, ее необходимо быстро решать. Руководитель проекта / отдельного направления принимает конкретное решение, представляющееся ему наиболее подходящим в этой ситуации. Однако с учетом дефицита времени и степени погруженности в общую концепцию проекта (а не его отдельных частей) такие решения зачастую носят субъективный характер. Более того, поскольку отдельное решение на этом этапе реализации проекта не было предусмотрено в исходном план-графике, его принимают очень быстро и далее о нем забывают. Но совершенно очевидно, что при отсутствии заранее сформированной процедуры обсуждения проблемы (привлечение специальной команды – принятие решения – фиксация принятого решения – анализ влияния принятого решения на общую процессную модель) велика вероятность принятия неоптимального решения. Выясниться это может много позже, и, вполне вероятно, придется «откручивать» назад существенную часть сделанной работы, причем по многим процессам. Мне приходилось попадать в ситуацию, когда на определенном этапе управления сложным проектом внедрения изменений выяснялось, что в дочерних подсистемах, общая процессная модель которых должна быть одинакова, на определенном этапе менеджеры осуществляли несколько последовательных «настроечных» корректировок, приводящих к совершенно разным результатам. Самое интересное, что, оглядываясь назад, уже никто не может вспомнить, кто именно, по каким причинам и когда принимал решение.

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

К основным рекомендуемым процедурам относятся следующие:

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

● процедура согласования и внесения изменений в исходные проектные модели;

● процедура проверки целостности и непротиворечивости принимаемых решений;

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

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

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

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

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

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

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

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

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

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

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

● анализ кросс-влияний предлагаемой корректировки на другие элементы общей бизнес-модели;

● анализ трудоемкости осуществления корректировки;

● обязательное внесение корректировок в общую бизнес-модель одновременно с их осуществлением.

Я не устаю повторять, что максимальный объем подготовительной работы, включая разработку процедур, шаблонов отчетности, форматов описания проблем, надо сделать до начала проекта. Потом будет не до формализации. Когда менеджеры вашей команды примутся по своему усмотрению и с учетом своего понимания решать проблемы и вносить корректировки в исходную модель, то «боржоми пить будет уже поздно». Заготовьте заранее несколько шаблонов, заставляющих тех, кто будет принимать решения, сначала оценить причины возникновения проблем, а потом попытаться найти несколько вариантов их решения. Это важно, так как впоследствии позволит анализировать, в каких местах общей бизнес-модели следует вносить изменения, будем ли перестраивать процесс, в котором возникли проблемы, или, может быть, потребуются корректировки всех прямо и косвенно связанных с ним процессов. Обязательно должна быть формализована процедура «посоветуйся с коллегой» или «вынеси на общее совещание проектного офиса». Выбирая окончательный вариант для предстоящей корректировки, надо руководствоваться не только критериями оптимизации текущей задачи, но и пониманием влияния ее на общую бизнес-модель.

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

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

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

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

Процедура проверки целостности и непротиворечивости принимаемых решений

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

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