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

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ру­ко­во­ди­те­ли проектных групп - это тоже менеджеры»
Ildar Minnkhmetov:
чем тот же самый scrum не годиться как фреймоворк, на базе которого можно строить процесс управления группой? тогде серам мастером и будет РГ. канбан доска с трудоемкостью напоминает работу со...
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.

База знаний

Введение в управление программами

Предыдущая Следующая
Просмотров 1764 Комментариев 0

Аксель Фёрсте

Управлением программами в SAP я занимаюсь уже два года, а в целом мой опыт внедрения решений SAP начался в 2000 году и включает в себя различные программы и проекты, в том числе – BI-системы и другие системы на базе SAP HANA. Исходя из своего опыта и опыта моих коллег, я расскажу о том, что такое управление проектами, программами, каковы выгоды и факторы успешного управления программами. Мы поговорим о различных типах программ и особенностях управления ими, о сфере ответственности, разберемся в разнице между проектами и программами. Поговорим о жизненном цикле управления программой внедрения SAP, о рисках неудачи и том, как использовать передовой опыт, чтобы этого избежать.

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

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

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

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

Управление программами подразумевает участие во многих проектах. Вы, как руководители программ, взаимодействуете с руководителями проектов, а они, в свою очередь – со своими командами, коллективами. В программе может быть 10-15 проектов. Например, в будущем году у меня будет две программы, всего 20 проектов. Это интересная задача. Поэтому, конечно же, нужно иметь очень сильную поддержку, авторитет и сильную команду.

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

Выгоды от управления программой

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

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

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

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

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

Управление рисками

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

Приведу пример из практики SAP. В 2011 году у нас в SAP Global IT велось 259 проектов, в рамках 1-2 стратегических программ. Ресурсов было очень много, однако нам приходилось работать по 12-16 часов в день. В прошлом году наше руководство заявило, что так продолжаться не может, и они реорганизовали структуру. С одной стороны, появилось больше программ, с другой – проекты должны быть сгруппированы в рамках этих программ, как под «зонтиками». Мы предполагаем, что у нас будет не более 20 программ, и сейчас находимся в переходном периоде, в процессе реструктуризации наших проекгов. 12 программ мы реализовали в этом году и видим, что ситуация улучшается.

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

Управление программами и факторы успеха

При определении стратегии и бизнес-цели, исходя из которых, будет строиться программа, руководство всегда применяет подход «сверху вниз», выдвигая ключевые стратегические причины, по которым мы создаем нашу программу и реализуем в рамках ее проекты. Но нужно также определять возможности бизнеса поддерживать программы. Программы – это всегда сочетание бизнеса и IT. Мы начинаем проекты в том случае, если видим бизнес-выгоды, можем сформировать ключевые показатели эффективности.
Следующий шаг – разобраться, достаточно ли возможностей у корпоративных IT для того, чтобы помочь реализовать данный проект. Мы в SAP сейчас работаем именно над такой задачей: в прошлом году начали проект по переводу нашей собственной ERP-системы на платформу HANA. Мы пытаемся определить, можно ли использовать для этого наш стандартный процесс либо для достижения целей бизнеса его нужно будет изменить. Например, при переходе на HANA 70% клиентского кода не используется. Возникает вопрос: почему? Почему пишется так много кода, выполняется так много доработок, которые затем не используются? В последние годы мы поняли, что инновационный подход очень важен. Наши клиенты, наш бизнес уже не хочет больше использовать стандартные возможности, отчеты два раза в год.

Рекомендация

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

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

Рекомендация

Очень важно оценивать уже проведенные программы, извлекать из них уроки. Можно ли по-другому, эффективнее использовать ресурсы? У нас за 5 месяцев было потрачено, условно говоря, 500 ресурсов. 50 из них были задействованы в других программах, то есть мы пользовались и чужими ресурсами, преодолевая противодействие, недопонимание, в конечсном итоге – достигая результата, необходимого компании.

Управление стейкхолдерами

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

Рекомендация

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

Обычно программы формируются на основании стратегии организации. А наполнение программ как раз и составляют проекты. Обычно это относится к сквозному процессу: первый контакт, заключение сделки, подсчет маржи и финансирование различных проектов, где необходимо управлять проектами в рамках программы более правильно и точно. Если вы не хотите реализовывать 5-6 отдельных проектов, то вы должны это организовывать в рамках одной программы.

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

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

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

Несколько слов о ролях. Менеджер программы – это основное контактное лицо. Он должен четко коммуницировать с бизнесом, объясняя, что создается в рамках IT, какие у нас ожидания от совместной работы с бизнесом, что нам необходимо согласование и одобрение задач бизнесом, чтобы через пару месяцев не возникла ситуация, что мы делаем не то, что компании нужно.

Рекомендация

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

Проект-менеджер отвечает за свой проект, является лидером своего коллектива и обеспечивает коммуникацию, он также является основным контактным лицом для руководителя программы. Если, например, в компании ведется 10-12 проектов и 300 человек в них задействовано, нельзя со всеми побеседовать, на это просто не хватит времени. Поэтому проект-менеджер должен владеть всей информацией о состоянии проекта и о том, что можно изменить.

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

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

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

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

Запуск программы: вы должны определить масштаб программы: вы должны понять, от чего зависят ваши проекты. Если вы начинаете новую программу из 12 проектов, очень важно понять эти проекты. Возможно, это специфика SAP: мы не можем просто управлять своей программой. Необходимо четко понимать ваш бизнес, основные цели, а не просто управлять своей командой. Если вы этого не понимаете, значит, вы занимаете не свое место. Невзирая даже на то, что бизнес не должен разбираться, ваша специфика – в деталях создать план рисков и оптимальную систему управления рисками.

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

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

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

Как я уже говорил, можно оптимизировать те вещи, которые не используются. Например, код, 70% которого не используется. За этим могут стоять существенные выгоды. Это очень важная область, которая требует внимания.

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

Факторы неудачи

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

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

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

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

Идеального количества участников команды нет: все зависит от масштаба, от времени, от количества коллег, которые вам требуются, чтобы этот проект реализовать. Если у вас есть один человек, который все знает и у которого очень хороший набор навыков, выбирайте его. Но вряд ли вы добьетесь успеха, потому что человек не может работать 24 часа в сутки – ему спать нужно, чтобы не сгореть на работе и отдыхать. 5 человек для небольшого проекта – это оптимальная численность команды. С точки зрения проекта, важно правильно распределить обязанности и иметь возможность правильно перемещать ресурсы между проектами. Также необходимо, чтобы у вас была единая точка контакта.

Почему необходимо использовать управление программами? Реализация программы может быть очень сложной: она идет многие годы, в разных регионах, задействует самые разные бизнес-процессы. К примеру, мы работаем в США, Индии, Китае и Германии над одним и тем же процессом, который нужно правильно организовать и синхронизировать.

АКСЕЛЬ ФЁРСТЕ
SAP

Аксель Фёрсте руководит стратегическими программами SAP Global IT. Он работает в SAP с 2000 года. Аксель обладает богатым опытом по управлению программами и проектами по всему миру. В 2012 году он присоединился к команде SAP Global IT, где он руководил самым первым внедрением HANA. В 2013 году Аксель возглавил программу Services Industry, а в апреле этого года он возглавил первый в мире проект по миграции системы SAP ERP на платформу HANA, которая была запущена в продуктив уже в Августе 2013 года.