Меня зовут Андрей Коптелов, я бизнес‑архитектор и преподаватель, в этом материале хочу рассказать о целеполагании и проектном управлении во взаимосвязи, о том, как драйвера приводят к появлению целей, цели приводят к старту проектов, а исполнение проектов приводят к реальным изменениям в организации. Часто именно тут мечты акционеров и руководителей организации часто сталкиваются с суровой реальностью.
Можно ли жить без дерева целей? Наверное, да. Но если компания хочет трансформироваться, без целей — никуда. Можно выделить два подхода к целеполаганию.
Первый вариант: компания не ставит перед собой целей измениться, она просто финансовые цели распределяет по функциональным подразделениям.
Например, «Обеспечить сохранение показателей прибыли в будущем году» или «Сократить затраты на 20%». Это рабочая практика, применяемая во множестве российских организаций.
Второй вариант: компания ставит перед собой задачу трансформироваться, поэтому ставятся цели трансформации, это про выход на новые рынки, про создание новых продуктов, про техническое перевооружение. Именно во втором случае нужно понимание бизнес‑архитектуры, ведь именно ее придется изменять для достижения целей.
Для этого необходимо не только декларировать цели, но и связывать поставленные цели с проектами, а проекты синхронизировать с деятельностью, которая подлежит изменениям, например, с картой способностей организации или реестром бизнес‑процессов.
Кстати, важный момент при определении целей — это анализ внешних драйверов. Цель не должна висеть в вакууме и быть вызвана только экспертным мнением акционера и руководителей. При постановке целей неплохо понимать влияние на организацию внешних драйверов: рыночных трендов, санкций, технологических инноваций, состояния рынка труда, изменившегося поведения клиентов.
Драйвер — это один из самых недооцененных объектов при анализе корпоративной архитектуры. Понимание внешних драйверов — это ключ к правильной стратегии организации, можно называть это «преимуществом согласованности» организации с внешним миром: если ваши цели синхронизированы с внешними драйверами, вы будете изменять компанию для обеспечения соответствия внешней среде. Если нет — рискуете потратить ресурсы на то, чтобы плыть «против ветра». Простая матрица «внешний драйвер — цель» часто отлично показывает этот разрыв.
Как строить дерево целей?
Есть классический подход: детализация «сверху‑вниз», от миссии организации к конкретным целям, задавая вопрос: «Что это значит?». Двигаемся с детализацией целей до тех пор, пока не определим ответственных за все цели. Как только определили ответственного за цель — останавливаемся — нам главное зафиксировать цели на ответственных и дальше уже работать с ответственными над достижением поставленных целей.
Есть классические правила формулировки целей — SMART:
конкретность;
измеримость;
достижимость;
релевантность;
временные сроки.
Все они важны при формулировке целей, но, по мне, релевантность — ключевой критерий при определении ответственного за цель. Цель должна быть поставлена тому, кто на нее может влиять. Нет смысла ставить обеспечивающему персоналу цель по выручке — он на нее никак не влияет.
Кто должен владеть деревом целей?
По‑хорошему, это зона ответственности подразделения стратегического управления, но если такого подразделения в организации еще нет, то бизнес‑ или корпоративный архитектор вполне может взять на себя роль владельца дерева целей. Есть примеры, когда корпоративные архитекторы разворачивали управление по целям в компаниях, а потом передавали этот артефакт бизнесу, оставляя под своим методологическим присмотром.
Теперь перейдем к тому, как цели превращаются в инициативы или проекты. Ведь цель — это не просто текст в реестре. Если цель про изменения, она должна запускать проекты, создающие новые продукты, меняющие существующие процессы и информационные системы. При этом нужно понимать, а сможем ли мы изменить соответствующие процессы и информационные системы в поставленные нам сроки и с существующим ресурсом.
Да, чуть не забыл, в качестве измерителя цели можно использовать объект «Достижение» или в его качестве ключевой показатель результативности, который позволит оцифровать цель и принять решение о том, что цель достигнута.
Вспоминается проект по трансформации в одной организации.
Акционер сказал: «Ожидаем результат проектов трансформации через месяц». При анализе бизнес‑архитектуры было обнаружено, что поставленная цель влияет на десять процессов, а эти процессы поддержаны пятью информационными системами. При этом статистика прошлых изменений показала, что срок изменения одного процесса с поддерживающими его информационными системами — минимум четыре месяца. Месяц для всей трансформации — это нереально. По‑хорошему, при анализе связанности целей и проектов с бизнес‑способностями, процессами и информационными системами можно дать прогноз реальных сроков достижения поставленных руководством целей и требуемых ресурсов. |
Перейдем к инициативам
Инициатива — это общий термин для любой активности, которую мы запускаем для достижения цели. В зависимости от организации это может быть проект, программа, набор задач или поручений. В больших компаниях, как правило, инициативы — это проекты или даже программы проектов, управляемые проектным офисом. Как уже сказано ранее, цели детализируем до ответственного, а уже он должен создать проект, и дальше этот проект попадает в реестр проектов в проектном офисе.
Если проанализировать реестр целей и реестр проектов через построение матрицы их влияния друг на друга, то сразу найдется множество «находок». Если есть цель без проекта, то как ее достигают? Если есть проект без цели, то почему он существует? Когда начинаете анализировать цели и проекты в связке, то рассогласования вылезают наружу. Это и есть работа бизнес‑архитектора — выявлять и устранять разрывы.
Теперь о проектном управлении
Проектный офис бывает централизованный, когда руководители проекта находятся внутри этого подразделения, или методический, когда в проектном офисе определяется методология с шаблонами, а руководители проектов находятся внутри подразделений. По мне, при внутренних изменениях руководитель проекта — самая тяжелая должность.
В проекте руководителю проекта приходится возглавить инициативу, которую никто никогда не решал, при этом экспертизы в компании может не быть, как и необходимых исполнителей с требуемыми компетенциями. При этом часто именно руководитель проекта при детальном планировании определяет всю ту деятельность, которую необходимо трансформировать.
Если считать, что все изменения, направленные на достижение цели, собираются в проекты, то для понимания объема изменений нужно связать объекты деятельности, например, бизнес‑процессы с проектами.
В идеале в организации должна быть матрица, в которой видны, какие проекты изменяют какие процессы или бизнес‑способности, а также на каких из них сходится несколько проектов, которые, возможно, содержат противоречивые требования к изменениям. Самый простой вариант — это электронная таблица, где по горизонтали бизнес‑процессы, по вертикали проекты, а на пересечении — атрибут, показывающий, что в рамках того или иного проекта будут изменены указанные процессы.
Вспоминается одна компания розничной торговли, в которой одна программа проектов была направлена на импортозамещение в ИТ, и ИТ‑команда переводила региональные подразделения с зарубежных систем на российские, а другая программа проектов была направлена на сокращение затрат, при этом из‑за несогласованности программ почти десяток региональных подразделений сначала «переехали» на новую систему, после чего были закрыты в связи с сокращением затрат. И в случае синхронизации этих программ можно было сэкономить много ресурсов компании. |
Поговорим о способности организации к изменению
В большинстве компаний есть такой объект управления, как бизнес‑процесс, в корпоративной архитектуре можно увидеть такие артефакты, описывающие деятельность, как карта бизнес‑способностей и цепочки добавленной ценности. Все это взгляды на деятельность с разных точек зрения.
При планировании изменений организации через постановку целей и определение сроков связанных с ними проектов нужно понимать, возможно ли вообще изменить деятельность организации в означенные сроки. Для этого неплохо было бы собирать статистику изменений на каждом из объектов управления, например, бизнес‑процессе.
С учетом того, что во некоторых организациях есть понимание, какие информационные системы поддерживают какие процессы, хотя бы в виде матрице поддержки «процесс‑информационная система», можно замахнуться на оценку реальных сроков изменений, например, если статистика изменения процесса показывает, что средний срок его изменения один год, то странно ожидать от него других сроков изменений, или если информационная система выпускает один релиз раз в полгода, то это тоже нужно учитывать при планировании.
Отдельная тема — это синхронизация циклов планирования объектов управления, например, если бэклог информационной системы на следующий релиз уже закрыт, то все инициативы по изменению процесса будут ждать следующего цикла.
Я часто называю бизнес‑ и корпоративных архитекторов «менеджером по связям с реальностью». Иногда приходится находиться на стратегических сессиях, где обсуждается, куда компания будет двигаться в следующую пятилетку, при том, что за прошлую пятилетку компания никуда не сдвинулась, так как способность изменения ее процессов, информационных систем и компетенций персонала стремится к нулю. Но менеджеры не хотят смотреть назад, ведь впереди их ждут очередные «красивые» цели, которые опять будут не выполнены или просто формально закрыты в очередной стратегический цикл.
Построение связей между внешними драйверами, целями, достижениями, проектами, процессами, бизнес‑способностями и информационными системами с анализом статистики изменений деятельности позволяет оценить согласованность, масштабность и возможное время изменений для достижения поставленных целей. Такая взаимосвязь превращает систему целеполагания из лозунгов для руководителей в систему управления изменениями с обратной связью по результатам и накоплением статистики для принятия решений в будущем.
Как всё это влияет на ИТ‑ландшафт?
Всё просто. Во‑первых, через постановку целей и инициацию проектов в компании определяются приоритеты по изменению деятельности, а значит, по созданию или доработке информационных систем, во‑вторых, понимая, какая деятельность, например, процессы, чаще меняется, можно проектировать ИТ‑ландшафт соответствующим образом.
Например, если деятельность обеспечивающая, меняется редко и к тому же не влияет на конкурентные преимущества организации, то и циклы изменений поддерживающих эти процессы информационных систем могут быть дольше, а значит никакого Agile и собственной разработки, в этом случае информационные системы можно использовать шаблонные с рынка.
Если деятельность постоянно меняется, как правило для обеспечения конкурентных преимуществ организации, то и информационные системы должны строиться с учетом этого с опорой на платформы — конструкторы и собственные разработки для обеспечения высокой скорости изменений (Time‑To‑Market). Тут и Agile‑подходы могут быть полезны и инновации.
В качестве выводов:
Дерево целей — это компас, но компас бесполезен, если он не синхронизирован с картой реальности: связывайте цели с драйверами.
Нужно понимать масштаб планируемых изменений в организации, поэтому цели нужно связать с проектами, которые в свою очередь связать с процессами или бизнес‑способностями организации.
Для понимания возможности организации к изменениям необходимо сначала накапливать статистику по фактическим изменениями процессов и информационных систем в организации.
Изменения становятся ключевой способностью организации, поэтому нужно системно этим управлять, улучшая способность объектов управления, например, процессов к изменениям, и синхронизируя циклы изменения объектов.
Корпоративная архитектура нужна не для того, чтобы аккуратно описать компанию в моделях, а для того, чтобы заранее видеть, где цели не взлетят, проекты начнут конфликтовать, а ИТ-ландшафт упрётся в собственные ограничения. Именно на этом и строится курс «Корпоративный архитектор».
Если хочется копнуть тему глубже, за пределы дерева целей и общих рассуждений про трансформацию, посмотрите эти открытые уроки. Они про ту часть архитектурной работы, где стратегия должна превратиться в набор реальных изменений, а сами изменения — пройти через людей, процессы и организационные ограничения.
30 апреля в 19:00. «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения».
Записаться14 мая в 19:00. «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров».
Записаться