Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.
«Упра­вле­ние сложными ли­чно­стя­ми в проектной группе»
Татьяна Шаньгина:
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная. Практический опыт доказывает справедливость концепции Уильяма Зиска о...

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

Управление программами (Введение)

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

Управление программами (Введение)

Докладчик: Аксель Ферст

Я работаю с SAP уже 15 лет, и 12 из них — в консалтинге, проекты были в разных странах мира, в том числе и в России — в 1993 году. Сейчас я занимаюсь разработкой программного обеспечения, внедрением, как консультант, и также выступаю в роли менеджера программ. На основе некоторых моих проектов я постараюсь убедить вас, что бюрократия — это не всегда плохо, в плане отчетности она может быть очень полезной.

Наша жизнь — это большой проект и программа, но мы бесспорно на IT-аспектах пытаемся сфокусироваться.

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

Программа и проект: общее и отличия

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

Такой подход за последние годы, однако, немного изменился, сместился в практическую сторону, что позволяет понять, что в каждой конкретной компании лучше реализовывать в ближайшей перспективе. IT обеспечивает поддержку такому подходу, то есть, выбирает путь и обсуждает это с бизнесом. Управление программами — стратегия, а проекты — часть стратегических программ. Проекты включаются туда, но не имеют такой стратегической важности, как программы — по крайней мере, в трактовке, которой придерживается SAP.

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

Это более конкретная информация. Менеджер проекта может управлять крупным проектом. Один проект с отдельными подпроектами — по‑прежнему проект. Уровень программы предполагает руководство отдельными проектами, но в новой роли — если вы программный менеджер, вы работаете на другом уровне, с другими людьми. Программный менеджер отвечает перед комитетом, работает с руководителями, например, SAP. С точки зрения ресурсов, он оперирует всем объемом ресурсов, доступных на уровне компании, а не отдельного проекта.

Знания — это тоже важный момент. Не каждый проектный менеджер является хорошим программным менеджером, потому что объем знаний, который на уровне программы требуется, отличается от проектного уровня. Поэтому вы должны развиваться и становиться из проектного менеджера программным менеджером, приобретать знания. Каждый день в вашей жизни перед вами встает много вопросов.

Если вы программный менеджер в процессе внедрения SAP, то эта тема является очень важной. Как программный менеджер вы 50 % уделяете решению политических вопросов. Управление пакетом проектов — это одно дело, но если вы программный менеджер, вы должны решать политические вопросы, уметь отвечать перед руководителями, перед стейкхолдерами, перед комитетами, защищать важные интересы. А как проектный менеджер вы обычно этого не делаете. Хороший проектный менеджер не может или иногда просто не должен быть вовлечен в управление программами и принимать участие в решении политических вопросов.

Как я уже сказал, программный менеджер должен управлять решениями, чтобы получать выгоды — новую ценность для организации. Если выгоды нечетко обозначены, если вы не понимаете, какие выгоды вы получаете, реализуя эту программу, стоит об этом задуматься — как определить данные выгоды и как их достигнуть. Вы должны поддерживать руководителей компании и заручиться их поддержкой — например, финансовой. Если мы соберем все запросы от бизнеса, например, на новый год и для их реализации потребуется 120 млн евро, а выделяют только 80, ваша задача — составить четкий, аргументированный финансовый прогноз, обосновывающий, что целесообразно все же выделять 120 млн. Другой вопрос, что в начале года делается одно, а остается в конце года совсем другое. Всегда эти вещи отличаются. Например, вместо 120 млн все‑таки получаете только 80 миллионов, но и эту сумму в течение года освоить не удается. Меняются требования, теряются ресурсы.

И последнее, стратегические задачи и управление. Я поклонник, откровенно скажу, бюрократии. Объясню, почему это не звучит плохо, что это хорошо, это облегчает вам жизнь. В некоторых проектах такая бюрократия не нужна — у вас работает 10‑15 человек, и в этом объеме нет необходимости каждую неделю своему программному менеджеру отчитываться и предоставлять информацию, которая у него и так есть. Но уровень отчетности для менеджера, который управляет программами, совсем другой, нежели для проектного менеджера. Поэтому в компании SAP часто бывает так, что нам нужно предоставить множество различных данных — и это, безусловно, необходимо выполнить. А это возможно только в том случае, если она у вас консолидирована, и вы ею правильно управляете. Поэтому в рамках программы необходимо устанавливать базовые концепции бюрократии — то есть, четко объяснить, что и в каком формате вы хотите получать, с какой частотой, в каком формате. Вначале это вызывает много дискуссий, но если не поставить эту работу сразу на должный уровень, в течение года возникает масса проблем с тем, чтобы в нужный момент получить конкретную информацию и организовать этот процесс.

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

Программа или проект — как различить?

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

Как, например, определить количественно бенефиты, выгоды реализации, как определить параметры эффективности. А как создать эффективные KPI, как измерять качество? Есть ведь способы измерять качество, нужно это уметь определять. И, кстати, возникает конфликт интересов, конфликт стейкхолдеров. То есть анализ стейкхолдеров, этих заинтересованных лиц, очень важен — даже не взирая на то, что все стейкхолдеры важны, одни из них важнее, чем другие. И об этом тоже нужно помнить.

Отчетность, которая предоставляется, не всегда хороша для практического использования — так что же с этим делать? Просто согласиться с этим, работать с ней или все‑таки создать собственную, эффективную систему отчетности? Выбирайте оптимальное решение, потому что не все то, что вам дается по умолчанию, хорошо. Например, если шаблон для отчетности недостаточно хорош, создайте другой, который облегчит вашу жизнь, который может также удовлетворить потребности ваших стейкхолдеров. И, кстати, такая дискуссия и в SAP у нас постоянно идет. Как формировать отчетность для руководителей и менеджеров? Как выбрать максимально оптимально простой шаблон, который будет содержать в себе самую актуальную информацию? Необязательно Excel использовать для этих целей, важно создать такой шаблон, который был бы оптимален и удобен.

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

Всегда на первом шаге нужно уметь разобраться с этой ситуацией и потом уже работать и менять ее, где можно менять. Например, реализация ERP на HANA, я подключился к этому проекту, когда он был эскалирован. Я был программным менеджером, и мы должны были в середине августа активировать проект. Это было обязательным условием. Другие варианты даже не рассматривались, и оставалась одна-две недели до поставленного срока, хотя были проблемы во многих областях проекта. В этой ситуации не было смысла говорить о проблемах, нужно было придумать решение. Идеально никогда не бывает, всегда что‑то идет не так, поэтому нужно просто оптимальный баланс соблюдать, чтобы вы двигались в правильном направлении.

Для успеха нужен не только компетентный программный менеджер, но и хороший модератор, руководитель-модератор — его задача состоит в том, чтобы управляющий комитет получал отчеты, где статус задач оптимален, не допускать перевеса проблемных или просроченных задач. Кроме того, нужна хорошая команда, которая бы вам подчинялась, работала с вами. Чтобы у вас менеджеры проектов тоже хорошо делали свое дело, а вы, как программный менеджер, пользовались бы их поддержкой. Потому что если они не хотят делать свою работу так, как надо, если настрой — работать с 9 до 5 и потом «умывать руки», хотя нужно иной раз и до 7 остаться, если не хотят вас поддерживать в сложные времена, у вас будут проблемы. Вы, как модератор, как руководитель должны руководить ими так, чтобы, в конечном счете, были довольны проектные менеджеры. Они довольны — вы довольны. Если они дополнительную работу делают, экстрамилю, так сказать, проезжают, как мы выражаемся по‑английски — нормально. А если этот подход не работает — плохо будет вам. Даже если вы сверхурочно будете работать, ничего у вас лично с этим не получится, потому что один в поле не воин, особенно когда речь идет о программах, которые мы обсуждаем.

Помните, конечная цель — это достижение результата. Но есть и другие вещи, которые нужно принять во внимание. Весь этот круг, который изображен на слайде. Часто многие компоненты не принимаются во внимание, когда мы говорим об управлении программами. И во всех этих параметрах требуется поддержка, ведь вы же не сможете это сделать самостоятельно. Именно тут подключается правильная бюрократия, PMO так называемое, управление пакетами проектов. Если эти параметры присутствуют, с ними нужно разобраться. И чем сложнее программа, тем сложнее это все организовать на персональном уровне.

В ERP на HANA у нас 120 таких показателей, так что там больше 20 проектов подключено, и, естественно, с каждым проектным менеджером каждую неделю не поговоришь и не спросишь: «Есть ли у тебя риски? Есть ли проблемы, вопросы?». На это уйдет слишком много времени. Поэтому важно выстроить правильные отношения. Такого рода программы реализуются с помощью специальных автоматизированных инструментов, чтобы можно было понять, каковы самые сложные вопросы, каковы риски, как эти риски снизить.

Подписались ли люди, ответственные за те изменения, которые они просят реализовать? Потому что если вы не сможете это сделать, они придут к вам и скажут: «Вы не сделали! На что вы потратили мои деньги? Вы вышли за рамки бюджета, за рамки проекта, временные рамки проекта, качество страдает!» И единственный ремень безопасности, как мы это называем, это такие документы с подписями начальства, которые можно предъявить участникам комитета, чтобы они поняли, что это они несут ответственность за такие изменения. Так что нужны инструменты и структура для всего этого.

Помните, в октябре я подключился в эскалированную программу? Да, нужно было отвечать перед советом. И по моим оценкам это была не программа, а проект, однако очень важный, так как он касался выплаты зарплат руководителям. Если они деньги не получат, будут проблемы. Я подключился к этому решению и сказал: «Где отчеты? Где масштаб? Как вы этим всем управляете? Где команда? Где коллектив? Кто важный? Кто важные участники коллектива?». И на каждый из вопросов я ответа не получил. Я не получил ни документов по масштабу, ни по отчетности, не увидел правильно организованной структуры. Самые важные вещи, основы отсутствовали. Поэтому я сказал: «Для меня крайне важно, чтобы эти вещи были сделаны с самого начала. Если требуется полчаса, 10 минут для того, чтобы это поднять, сделайте это. Потому как если вам кажется, что это напрасная трата времени в начале, в конце это поможет вам просто банально выжить, если вы выходите на другой уровень, и если вы будете использовать правильную структуру. Если ее не будет, что вы предъявите руководителям для проверки, документы, например? Если его ожидает список документов, 100 документов, это база, это основа, и она должна присутствовать, и она должна быть структурированной. Вот это очень важная вещь для меня, с этого я всегда начинаю».

Интеграция графиков и расписаний работы. Кстати, я в PowerPoint часто пользуюсь функцией «План программы». И вы можете сделать так, чтобы у вас были шаблоны и инструменты для того, чтобы рассмотреть графики и расписание программы, получить эту информацию своевременно и иметь расписание доступное. Многие менеджеры в «SAP» не используют Microsoft Project, им достаточно данных инструментов.

Лидерство очень важно. Как лидер вы должны помочь вашим руководителям проектов, как лидер ответить на их вопросы, чтобы они получили поддержку тогда, когда это требуется. Бывают ситуации, когда менеджер программы идет к менеджеру проекта и говорит: «Так, это твоя задача, сделай, выполни ее». Ваша задача, как программного менеджера — помочь вашим проектным менеджерам, если они приходят к вам и говорят: «У нас есть проблема, что с ней делать?» Они просят помощи, и ваша работа, ваша задача — помочь им, обучить их, дать совет, выступить для них наставником, коучем. Один из таких проектных менеджеров работал по 12‑14 часов в день постоянно, и я его спросил: «Зачем?» Он сказал: «Ой, так много работы!» Я сказал: «Окей, а как вы с этой работой вообще справляетесь?» Выяснилось, что он все делал самостоятельно, не делегировал ответственности своим линейным менеджерам — кстати, я активно пользуюсь делегированием, менеджеры проектов должны постоянно этим пользоваться. Если у вас есть так называемые роли и ответственности, которые можно делегировать, используйте это для того, чтобы вопросы решались, и не пытайтесь объять необъятное самостоятельно.

В конечном счете, тот менеджер смог оптимизировать свое рабочее расписание и начал работать, как нормальный человек, 8‑10 часов. И использует специальные механизмы, которые помогают ему в этом. Стоит этот вопрос всегда обсуждать, менеджеры проектов должны иметь возможность с менеджером программы эти вопросы обсуждать и после такого обсуждения решать свои задачи более эффективно.

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

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

Бизнес обязательно должен протестировать все произведенные изменения, перепроверить все, что получилось в результате реализации жизненного цикла программы. Часто мы говорим про такой параметр, как agility, то есть умение быстро реагировать на изменения и менять проект, рабочий подход. Это лишь только одна часть проблемы: если меняется IT, и бизнес тоже должен меняться быстрее и иметь больший уровень agility. Бизнес тоже должен иметь изрядную долю гибкости для того, чтобы реализовывать результат каждый месяц, проверять это каждый месяц регулярно, постоянно, чтобы они постоянно участвовали в проектах. И тестировали бы это не один раз, а регулярно, и могли давать оптимальный результат. И вы должны определять лучший подход для того, чтобы развивать программу дальше.

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

Если вы четко определили ваши требования, вы должны их разделить на части, которыми можно будет управлять. И дальше нужно обязательно понять риски и уметь управлять этими рисками. Для этого нужно выбрать специальный инструментарий, это, бесспорно, будет разумно.

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

Управление программами

Коммуникация — тема, которую обязательно нужно подробно рассматривать. Я считаю, что коммуникация — это одна из важных задач программного менеджера, его задача: осуществить прозрачную коммуникацию и правильный мониторинг. Я поклонник этого подхода, потому что использование правильных структур, шаблонов, процедур сильно помогает и облегчает жизнь. Часто вам требуется поддержка, и ее можно получить с помощью хорошо налаженной системы коммуникации управления рисками. Если у вас 20 рабочих потоков и 20 менеджеров, которые с вами работают, многие из них должны оказывать вам такую поддержку.

Вообще, создание PMO, создание ОУП — это не только использование Excel и распоряжение бюджетом, сводный мониторинг бюджетов и графиков портфеля проектов, это нечто большее. Это очень важный вопрос координации.

Это примеры того, как мы организуем свои программы. У нас есть организационная стратегия, которая задает нам 70 % портфеля наших проектов. Многие программы реализуются долго — например, циклами по году и более, потому что бюджет выделяется на один год. Многие программы реализуются многие годы. Например, «HR Goes Cloud» или «ERP на HANA». Если у вас имеются нужные основы, вы сможете и с более крупными программами справиться тем же самым коллективом сотрудников. Мы это использовали в самых разных программах, работали с самыми разными проектами.

Что касается организации программы и ролей в этой организации — все зависит от вашей работы, от задачи, которую вы преследуете. Например, если это слияние и поглощение или программа управления изменениями (в частности, ERP на HANA), все зависит от того, как все структурировано, то есть не все роли обязательны в программе. В SAP, например, есть выделенный коллектив программных архитекторов — архитекторов по решениям, которые работают с общей архитектурой программы. Чем больше изменений, тем важнее их роль для реализации программы: они создают направление командам, коллективам архитекторов, которые отвечают за каждый поток по отдельности. И дальше у нас есть управляющие комитеты, совет консультантов по технической части и комитет. Это необходимая бюрократия, о которой я говорил, потому что всех этих людей нужно информировать, и все они хотят получать информацию по‑разному. Информация должна быть одинаковая, но шаблоны для предоставления этой информации каждому подразделению должны использоваться разные.

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

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

И в заключение — о ролях и ответственности. Чем отличается по ним программный менеджер от проектного? Программный работает со спонсорами, руководителями, с членами управляющего комитета, работает с клиентом, с командой, обеспечивает коммуникацию с бизнесом, в IT и в командах. Я еще раз подчеркну, что у всех участников должна быть такая информация, потому что плохая коммуникация часто ведет к проблемным моментам и к неудачам. Надо, чтобы команда была скоординирована, чтобы информация была доступна. Можно это, кстати, было сделать на флипчартах, расписать главные параметры, к которым можно было подойти и проверить. Если этого не будет, все пойдете в разные стороны, невзирая на то, что работаете в одной команде. И для программного менеджера нужно сделать так, проектные менеджеры им должны быть скоординированы так, чтобы они все шли в одном направлении. Важно, чтобы команды понимали отчетность, прогресс. Это не очень приятная задача, но этим обязательно нужно заниматься, управлять достижениями, решением сложных вопросов. Зачастую многие не в курсе того, что на данный момент в проекте является приоритетным, когда нужно это реализовать, и каковы проблемы. И человек, который этим всем руководит — ключевая фигура, потому что это именно его задача — такую информацию искать, предоставлять и двигать программу вперед.

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

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

Цикл управления программами в SAP немногим отличается от аналогичных циклов в других компаниях. У нас есть фаза подготовительная, которая начинается обычно в ноябре-декабре: проверяются требования бизнеса, определяется, когда это нужно сделать. Дальше — фаза инициации программы: распределение проектов, формирование команд. Многие программы будут длиться больше года, и часто будет оптимизироваться бюджет: если не используется полностью, может быть сокращен. Если этот проект многолетний, и на следующий год планируется только программа на следующий год, без двух предварительных этапов. Дальше определяете ценность программы, реализуете эту программу, получаете выгоды для бизнеса и завершаете ее. Но моя рекомендация — не завершать программы в конце года, потому что, как правило, в это время нужно готовиться к запуску новых программ. Закрытие программы — это не так важно, как этап планирования новой, потому что для закрытия не требуется никакой помпезности, больших усилий — просто пройти через определенные ворота качества, чтобы увидеть, что — да, действительно, бизнес реализовал этот проект или эту программу с определенными KPI, и понять — что достигнуто, а что — нет.

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

Откуда берутся неудачи

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

Поэтому вы должны сделать так, чтобы ваши участники программы не работали по 20 часов в день, потому что они тогда очень бюстро «перегорят» и выйдут из строя.

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

Основные причины неудачных проектов:

• Плохой анализ плана и ресурсов.

• Политические вопросы.

• Нереалистичные ожидания.

• Расплывчатые требования, неполные и постоянно меняющиеся.

• Плохая внутренняя коммуникация

Почему важно использовать управление программами?

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

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

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

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

Если есть запросы на изменение, к ним нужно относиться серьезно, потому что они всегда касаются и бюджета, и качества, и времени. Нельзя использовать те же самые временные рамки, чтобы сделать вдвое больше запланированного. Если да, можно, то, значит, что‑то было запланировано неправильно. Если вы постоянно получаете запрос на изменение от бизнеса и говорите «да, это можно, это можно, это можно», — в определенный момент возникает вопрос: а вы изначально что запланировали, если все возможно? Вы же постоянно получаете запрос на изменение, и вы все время говорите, что все возможно, это не проблема. Значит, изначально вы составили план неправильный. Вы должны работать над тем, что хочет в результате иметь бизнес. Если они не уверены в этом, не делайте ничего. Да, вначале это делать сложно. Но потом, когда вы заставляете, в конечном счете, бизнес задумываться о том, что они хотят получить, это существенно экономит и ваше время.