Сразу хочу закинуть небольшой тезис. Тема очень неизвестная. Долгое время это было нашим конкурентным преимуществом, и сейчас мы решили выпустить статью. Почему? Потому что у нас немного меняется стратегия: тему по GRC мы будем популяризировать. Раньше у нас это работало внутри.
На кого рассчитана данная статья? На очень опытных специалистов, сеньоров, которые, в принципе, знают все основные теоретические базы в управлении проектами и ищут для себя какие-то новые подходы, решения, которые помогут им взлететь еще выше.
Но эта тема может быть интересна и начинающим: для того, чтобы понять, в каком треке, в каком векторе сейчас лучше развиваться. Потому что сейчас идут очень большие изменения и с точки зрения методологии, и с точки зрения возможностей автоматизации. А к этому как раз и привязан наш подход.
И еще один важный момент. Я не ставлю себе задачу в одной статье рассказать все нюансы работы с подходом. Сейчас самое главное – понять, что кроме известных инструментов есть еще целый океан пока не освоенных, но эффективных возможностей. И мы с вами можем из этого океана почерпнуть то, что каждый считает для себя нужным, использовать это уже в своей работе и найти что-то полезное.
Стратегия выхода на рынок и партнерская программа
О причине подготовки статьи. Зачем мы вообще вышли с нашей, можно сказать, кулуарной темой?
Дело в том, что сейчас по нашей стратегии мы в качестве вендора будем выводить на рынок новые программные решения. Скоро мы запустим нашу партнерскую программу.
Суть в чем? Мы ставим себе целью, чтобы наши заказчики получали не только лучшие программные решения с точки зрения GRC. Это решение еще должно быть классно внедрено, чтобы заказчик получил конечный положительный результат.
Поэтому сейчас мы поняли, что компании, которые мы рассматриваем в качестве партнеров, такого бэкграунда, как у нас, не имеют. Значит, мы будем передавать им свои наработки, свои лучшие практики.
И здесь мы поняли, что у нас есть неосознанные компетенции. Мы ими владеем, но они у нас не формализованы, поэтому передать их мы не можем. И моя статья – это одна из ступенек такой формализации. Но думаю, что вам всем будет интересно что-то для себя в этом увидеть.
Что такое GRC и его основная цель
Несколько слов о том, для каких целей вообще разрабатывался GRC, что это такое и как вы можете использовать его у себя.
Вот классическое определение, которое дано авторами. «GRC подход направлен на обеспечение уверенности в надежном достижении целей проекта в условиях неопределенности и в соответствии с требованиями и лучшими практиками».
На самом деле для нас важно понимать, что основная цель использования GRC – это обеспечение уверенности в надежном достижении целей. Причем неважно, чьих именно целей.
Классический GRC разрабатывался для достижения целей крупных корпораций. Но сейчас мы научились использовать эти же подходы для надежного достижения целей в проектах. В принципе, их можно использовать и для достижения цели каждого сотрудника.
То есть здесь работает принцип фракталов, когда в листике можно увидеть прообраз ветки, в ветке – прообраз дерева и так далее. В этом смысле система достаточно универсальная.
Мы с вами знаем треугольник проектного управления: сроки, стоимость и качество работ. Обычно, когда я с кем-то разговариваю, все говорят, что нельзя сразу совместить все три грани. Если мы делаем быстро и качественно, это обязательно будет дорого. Обязательно выйдем за бюджет или еще что-то случится.
Как раз GRC и направлен на то, чтобы эти три грани совместить, чтобы они достигались так, как было запланировано изначально.
И несколько слов по статье. Вначале у меня будет несколько изображений по теории, а потом я расскажу кейсы: как мы вообще со всем этим работаем.
Сложность подхода и объем знаний
GRC формулируется очень просто. Трехбуквенных обозначений во фреймворках и подходах много.
-
G – Governance (Управление)
-
R – Risk (Риски и возможности)
-
C – Compliance (Соответствие)
Казалось бы, все просто. На самом деле за этим простым определением стоит очень сложная система.
GRC был разработан и впервые опубликован в 2021 году. Для понимания: базовое руководство – это Красная книга GRC. Она насчитывает 256 страниц. Причем там очень убористый, мелкий текст, много графиков, систем и так далее.
Я еще вхожу в сообщество AC GRC и еженедельно получаю их дайджесты по кейсам, по новым методологиям. И сейчас хочу сказать: хотя мы считаем себя лидерами практики использования GRC в управлении проектами, у себя мы применяем, наверное, процента два-три от того, что вообще можем применять, исходя из того, что я получаю.
Но даже эти 2–3% помогают нам быть лидерами с точки зрения трудозатрат, экономии времени и надежности.
Здесь сразу возникает закономерный вопрос. Это все интересно, глобально. Но на чем необходимо сделать фокусировку прямо сейчас, в ваших проектах, чтобы начать использовать все это на практике? Давайте перейдем к конкретике.
Адаптация принципов GRC под проекты
Те же самые три определения – управление, риск и соответствие – мы у себя в компании перевели именно под наши проекты, с которыми работаем.
Опять же, по принципу фрактальности: правила, которые разработаны для крупных корпораций, мы перевели в свои проекты. До корпораций им далеко, но тем не менее у них тоже есть свои цели, бюджеты и требования к качеству.
Давайте посмотрим, как мы в итоге адаптировали эти принципы.
В управлении мы делаем фокус на том, что в принципе может помешать нашей настроенной работе. Мы управляем только ограничениями и блокерами.
В рисках мы сделали фокус на том, что на начальном этапе занимаемся идентификацией и оценкой рисков. Плюс у нас есть целая система работы с инцидентами. Об этом я расскажу дальше, потому что в самом начале все запланировать невозможно, каким бы специалистом ты ни был.
А соответствие мы для себя приняли как соответствие нашим лучшим практикам: тем наработкам, которые показали себя с положительной стороны, которые мы закрепляем и будем развивать дальше. Это принцип так называемого кайдзен.
Мы эти принципы поняли, и опять возвращаемся к прикладному применению. А как эти принципы можно увязать в нашей конкретной ситуации в управлении? У каждого из вас есть какие-то управленческие сложности в управлении проектами. Не бывает, чтобы все было гладко. И что с этим теперь делать?
Здесь нам необходимо перейти как раз к описанию нашего теоретического блока. Это еще одно ноу-хау, без которого эти принципы остаются красивыми лозунгами, которые можно повесить на стену, но сами по себе они работать не будут.
Давайте посмотрим теоретический блок, с которым мы работаем.
Здесь четыре основных теоретических блока подхода, с которыми в своих проектах работаю лично я. Но мы еще используем – отрывочно, но используем – инструменты, например, из всеобщего управления качеством, из бережливого производства Lean. Есть принципы непрерывного совершенствования кайдзен. Мы все это берем.
То есть, несмотря на такой большой блок, GRC как раз тем и полезен для нас в наших проектах, что он выполняет так называемую оркестрацию. Из всех этих подходов, фреймворков и так далее он выделяет самое полезное и добавляет что-то свое.
Парадокс нагрузок и теория идеального инструмента
Предвижу небольшой вопрос: как мне, перегруженному проектами и задачами, не спящему ночами, дополнительно навалить на себя еще работу со всем этим, а по итогу снизить свои трудозатраты, повысить качество и все остальное?
То есть у нас здесь возникает логическое противоречие. И по этому поводу как раз получается парадоксальное противоречие. Я хотел бы привести пример нашего соотечественника, который эту проблему решает.
Здесь я привел две формулировки из теории решения изобретательских задач. Кто не знает, автором этой теории является Генрих Саулович Альтшуллер. Кстати, первую публикацию этой теории он выпустил в 1956 году. Газета была бакинская, точно не помню, как она называлась – газета или журнал. То есть это достаточно давно.
Но здесь нам важно следующее. У нас есть две формулировки. Первая – наше противоречие. Мы можем сформулировать его следующим образом: «На меня, как руководителя проектов, наваливается дополнительное требование и выполнение кучи всяких процессов, а у меня почему-то начинает освобождаться от этого время». То есть это противоречие. Должно быть наоборот.
И есть небольшой ответ, который я потом буду подтверждать в рамках статьи. Почему это произошло у нас? Потому что GRC-подход предоставляет нам наборы идеальных инструментов. И сразу вопрос: а что это за идеальные инструменты такие? Читаем определение Альтшуллера.
В нашем случае идеальный инструмент – это когда я получаю экономию своего времени за счет системного изменения в управлении проектами. И докручиваю дальше: проект сам выполняет работу без моего участия за счет использования ресурсов системы, которую мы построили с помощью GRC.
Звучит классно. Как это применить на практике – вообще непонятно.
Практический кейс: дашборд и риск-ориентированное управление
Давайте перейдем к кейсам и посмотрим, как мы работаем с точки зрения этих определений.
Вот так выглядит наш модуль риск-ориентированного управления, с которым я работаю. Он разработан на базе 1С:Документооборот. Всем вполне знакомый интерфейс.
Сейчас я расскажу, как с помощью этого модуля могу, во-первых, принимать решения на основе данных, во-вторых, экономить свое время, а в-третьих, обеспечивать надежность и качество достигаемых результатов.
Свой рабочий день я начинаю с такого дашборда. Что он мне говорит, когда я его открываю? Тут сразу видно, что в моих проектах прямо сейчас происходит не так.
В наших проектах все, что нужно контролировать, – приход на работу, выполнены ли все договоренности, проведены ли все коммуникации и так далее – делается автоматически. Технически об этом потом расскажем отдельно.
И я, приходя на работу, сразу вижу, сколько инцидентов у меня уже закрыто системно. Что такое «закрыто системно», тоже расскажем отдельно. Также вижу, сколько инцидентов требует моего внимания как руководителя для принятия системных мер.
То есть такой простенький дашборд на самом деле помогает мне фокусироваться на главном: на том, что прямо сейчас мешает нашей проектной устойчивости.
Далее смотрю показатели внутреннего контроля: какие конкретно сбои из всего этого требуют моей реакции прямо сейчас.
У себя мы можем прописать любой набор контроллеров, исходя из перечня возможных рисков, которые определяем на этапе планирования, а потом добавляем еще по мере работы с инцидентами и процессами. То есть мы все это обвешиваем контролями.
Причем сейчас у нас упор именно на опережающие метрики, чтобы узнать об угрозе наступления рисков заранее. Какой смысл узнавать о риске, когда он уже случился? Он уже произошел. Мы стараемся не лечить кариес, а проводить профилактику: чаще чистить зубы.
С этим дашбордом, кстати, достаточно работать раз в неделю, может быть, кому-то даже раз в месяц.
Данный дашборд показывает общий тренд изменения ситуации. Здесь у нас отдельно идет количество сбоев – это даже количество сработанных отрицательных контролей. А зелененькие столбики – это потери по ним.
Можно, конечно, пойти дальше. Если мы смотрим эту аналитику по классике data-driven management, то есть управления на основе больших данных, можно взять, например, классические статистические модели Деминга по выявлению вариаций или контрольные карты Шухарта для поиска аномалий, систему «Шесть сигм» и так далее. Все это можно сюда включить, и мы будем понимать, что идут какие-то негативные тенденции. Но на самом деле мне на моем уровне вполне достаточно этого. Я примерно уже начинаю улавливать, какие у нас идут макротренды, где что меняется и так далее. Могу подвязать это к тем процессам, которые мы проводили.
В принципе, сейчас для аналитики этого вполне достаточно.
Ежедневная работа со сбоями и системные корректирующие мероприятия
А вот эту сводку я смотрю уже ежедневно. Это мой основной рабочий документ. Здесь я уже могу увидеть детализацию сбоев с их оценкой потерь. И именно здесь начинаю решать и оперативные, и корректирующие вопросы.
Проработка таких системных корректирующих мероприятий, с одной стороны, дает возможность идти путем непрерывных улучшений. То есть мы постоянно, чуть-чуть улучшаемся каждый день. А с другой – просто не утонуть в махине проектов, регламентов, систем, стандартов и так далее.
Мы понимаем, что все описать просто невозможно. И в качестве описания регламентов, по которым будем потом работать и в которых закрепляем наши лучшие практики, мы в первую очередь концентрируемся либо на том, что может пойти не так, либо на том, что уже когда-то шло не так, и мы это зафиксировали.
Здесь важно понять два момента, которые отличают наш подход от большинства традиционных.
В соответствии с GRC-подходом руководителю не нужно вмешиваться в процесс, если нет конкретных сбоев. Как на заводе ремонтная бригада сидит, играет в домино, если станок нормально работает. Она туда не лезет. И здесь у нас то же самое.
Второй важный момент: мероприятия по работе со сбоем с целью его системного устранения в будущем как раз и являются моей первоочередной работой. То есть я работаю уже со стратегией, с будущим. Это как раз и есть управление через риски.
Интеграция системы и ответ на парадокс
На самом деле возможности нашего решения достаточно широкие. Здесь приведена система интеграции нашего GRC с ERP. Это я говорю для понимания того, что при желании автоматизировать можно фактически все. В ERP у нас ведется огромное количество внутренних показателей: и по трудозатратам, и по распределению ресурсов, и по финансовой эффективности. Все это в итоге выводится в дашборде руководителя проекта.
Ну и ответ на вопрос, который стоял у нас в самом начале: как происходит так, что на нас наваливается куча дополнительных процессов, а время почему-то освобождается?
Мы посмотрели формулировку Альтшуллера и возвращаемся к ней. Здесь можно сказать, что, с одной стороны, мы добавляем себе дополнительные процессы по GRC-подходу. С другой – у нас освобождается время как раз за счет того, что мы не выполняем действия, которые фактически уже потеряли свою ценность, потому что мы перестроили систему контроля, анализа и подходов к принятию решений.
То есть ответ на вопрос следующий: мы просто поменяли систему.
На самом деле смена такой культуры управления проектами – очень сложный процесс. Дальше, уже за рамками статьи, мы будем обсуждать как сделать так, чтобы все инциденты фиксировались, как сделать так, чтобы коллектив именно погружался в проработку лучших практик и соблюдал их. Там много-много нюансов, мы набили себе много шишек на этом.
Но тем не менее, если это реализовано, мы с вами уже переходим в системное изменение, когда система начинает выполнять вашу работу и разгружает вас процентов на 80.
Простые шаги для старта: три направления
Если бы я впервые услышал такую концепцию, я бы, наверное, подумал: «А какие простые шаги я мог бы сделать, чтобы начать применять GRC у себя? Просто попробовать без всех этих модулей и всего остального?»
На самом деле все просто и системно. Достаточно сфокусироваться на трех направлениях, про которые нам и говорит GRC: управление, риски и соответствие. И постараться обеспечивать в своих проектах достижение именно этих целей.
Я вспоминаю анекдот про мышей и сову. Сова посоветовала мышкам, чтобы на них не нападали хищники, стать ежиками. Мышки вначале обрадовались: «Классно, мы будем ежиками, нас не будут есть». А потом спрашивают: «А как нам стать ежиками?» Сова отвечает: «Слушайте, я стратег, я вам дала идею. Как вы ее будете реализовывать – это уже ваше дело».
И чтобы нам тоже не оказаться в моменте, когда мы проговорили стратегию, а как все это реализовывать – непонятно, я хочу сказать: за четыре года в рамках реализации этого подхода мы уже сформировали свои внутренние фреймворки и методики. И некоторыми из них я с вами поделюсь.
Я предлагаю сначала по каждому из этих трех направлений делать три простых действия. Начать хотя бы с этого, а дальше уже потихонечку набирать вес.
Примерно так же мы будем работать и с нашими будущими партнерами, когда будем передавать им свои компетенции по лучшим практикам управления проектами.
Самое первое действие – проектное управление, G.
Цель: обеспечить четкость целей, управляемость хода проекта и
оперативность стейкхолдеров.
-
Проводить регулярную синхронизацию с ключевыми участниками проекта (владелец продукта, заказчик, разработчики), фиксируя статус и блокировщиков.
-
Обновлять и согласовывать план проекта с учетом приоритетов и изменений – в виде дорожной карты, бэклога или спринт-плана.
-
Поддерживать прозрачную систему отчетности: статус задач, выполнение этапов, отклонения – чтобы все соответствовало, где сейчас проект.
На самом деле в перечне, который я написал, нет ничего нового, чего не содержалось бы в других подходах к проектному управлению. Но здесь важен сам принцип фокусировки.
В своих проектах мы фокусируемся именно на этих трех пунктах, что и позволяет нам не распылять свое внимание и время. Потому что всегда есть куча дел, а мы должны обязательно фокусироваться. И здесь у нас должна быть определенная дисциплина: ни в коем случае не уходить в сторону.
Второе – R, риски. Это как раз риск-ориентированное действие внутри проекта.
Цель: предотвратить проблемы до того, как они станут критическими, и снизить стресс в команде и у клиентов.
-
На старте сбора проекта и зафиксировать список опасных рисков (в сроки, зависящие от внешних команд, доступов и т. д.).
-
На спринте или итерации проверяется актуальность контролируемых уже рисков и возможность возникновение новых – на основе обратной связи и наблюдения.
-
Для основного риска – кому заранее подготовить план действий: куда писать, что делать, какие ресурсы подключаются.
Практика такой проработки, с одной стороны, дает готовность к быстрым реакциям по исправлению ситуации. То есть у нас всегда есть план Б. И этот план у нас есть либо на этапе планирования, либо на этапе отработки контрольных точек.
А с другой стороны, благодаря этим трем действиям, с которыми я рекомендую работать каждый день, у руководителя проекта уже вырабатывается определенный фокус. Появляется предвидение возможных будущих проблем: или за счет наблюдения, или за счет опережающих метрик, которые мы ставим себе. И вы, в принципе, тоже можете научиться их ставить.
Ну и третье – C, соответствие.
Цель: сделать так, чтобы проект не «завалился» на этапе приемки, сопровождения или аудита.
-
Уточнить у заказчика и информировать внутреннюю команду (IB, DevOps, архитектура), какие есть обязательные требования к проекту с максимальной детализацией.
-
Встроить эти требования в план проекта и чек-листы к этапам (релизам, приемке, сдаче).
-
Фиксировать все необходимые согласования и отклонения от стандартов в доступном виде (в задачах и электронной почте), чтобы не приходилось «вспоминать, кто что разрешил».
Работа с соответствиями в наших проектах на самом деле делится на две части. Первая часть, которая описана, – это ориентирный результат, который мы ожидаем от проекта. Это работа с ожиданиями заказчика и так далее.
Но у нас еще есть соответствие самих процессов исполнению наших внутренних стандартов, наших лучших внутренних практик. Потому что мы понимаем: без контроля качества процессов невозможно прийти к качеству результатов. Из пластилина не сделаешь пулю. Поэтому мы работаем с пластилином в самом начале, а потом у нас получаются классные пули.
Ключевые принципы
И в заключение – небольшая шпаргалка с нашими принципами проектного управления.
На самом деле, не построив системную работу по этим четырем составляющим, наверное, с вероятностью 90% у нас с вами никогда не получится выйти из череды постоянных форс-мажоров и начать работать системно. Эти четыре пункта как раз можно повесить в качестве лозунга на стену. И с ними надо работать в первую очередь.
Эволюция GRC и цифровой ассистент на базе ИИ
Напоследок у меня будет такое изображение, за которое меня, скорее всего, наругают. Там слишком много мелких букв. Но это изображение я делаю для тех, кому данная тема в принципе интересна. Я его привожу просто для понимания масштаба GRC и того, в какую сторону этот подход движется.
На сегодняшний момент существует шесть версий GRC. В своей работе я, например, в разных вариациях использую первые четыре версии. По заголовку примерно понятно, о чем идет речь.
И мы сейчас начали использовать еще и небольшой элемент пятой версии. То есть в наш модуль GRC, который был в начале, мы встроили цифрового ассистента на базе искусственного интеллекта. Вы знаете, это экономит массу времени.
Давайте посчитаем, что у вас как будто есть человек, который прочитал все ваши задачи по всем сотрудникам, все протоколы ваших совещаний за все время, все ваши стандарты. Он все помнит, и в любое время дня и ночи любой обратившийся – например, наш специалист по какому-то возражению – тут же получает ответ от этого цифрового ассистента: «Слушай, у нас сравнение функционала такое-то, конкурентные преимущества такие-то. Кстати, дополнительную информацию можешь посмотреть там».
Представьте себе, как это разгружает руководителей проектов, к которым обычно стоит череда желающих либо переложить свою проблему, либо узнать что-то новое и действительно рабочее, чего человек не знает.
Вот такой цифровой ассистент, как раз пятая версия, и способствует одному из прорывных подходов. Помните, я вам рассказывал, что процессов у нас стало больше, а своего времени я трачу меньше? Мы перерабатываем систему. И вы ее тоже можете переработать.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.