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

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

Мероприятия

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

Управление программами: когда бюрократия помогает

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

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


Анна Леммниц

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

Ключевые PMO процессы поддерживаются рядом документов, поэтому в ресурсах PMO мы обязательно публикуем templates (шаблоны), положения, статус репорта, шаблоны для управления рисками. Эти документы и параметры доступа к ним мы отправляем проект-менеджерам, Workstream лидерам из PMO. Таким образом мы добиваемся того, чтобы все использовали один и тот же шаблон, одни и те же инструменты и способы коммуникации с руководителями.

Следующий шаг – создание плана проекта, определение ключевых точек. Мы исходим из цели проекта и определяем, в каких точках будем проверять – насколько успешно к ней продвигаемся. Задача руководителя PMO – контролировать, периодически проверять это расписание, при необходимости – корректировать его. Мы используем свой формат SAP Jam и разные share drives, document room.

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

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

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

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

У каждой задачи должен был владелец (owner): иначе невозможно узнать, кто за эту задачу отвечает, если что-то не работает. Нужно четко расписать, кто именно, согласовать это с участниками вашей команды и руководством, зафиксировать это.

Например, у нас был проект по переводу ERP-системы на HANA. В конце августа топ-менеджмент задался вопросом, возможно ли запустить в октябре новые функции, которые на тот момент только разрабатывались в системе SAP. От меня требовалось создать так называемый flat-plan. Вот пример такого расписания. Его можно сделать в любом формате, который у вас используется.

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

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

При планировании всегда исходите из конечной цели проекта и планируйте крупными вехами. Вы должны всегда выполнять «Quarter and Close», ставить конечную цель, ставить вехи, которые вы должны достигать и проходить.

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

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

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

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

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

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

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

Невозможно определить все риски в самом начале. Процессы управления рисками ведутся на проектном и на программном уровнях. Определяете риски и помещаете их в Risk log. Есть такой инструмент в SAP, который называется Giro, где фиксируются эти риски. Вы их либо принимаете, либо отвергаете, и для этого у нас принято проводить еженедельное совещание. Какова вероятность наступления такого риска и его последствия? Какова процедура предотвращения и снижения серьезности риска? Для программы перевода ERP на HANA основная сложность была c ранним внедрением и с сохранением свободных ресурсов. Следующий этап – мониторинг рисков на проектном уровне: разрешимы ли они на данном уровне или могут повлиять на всю программу. За такими рисками я должна следить, как руководитель программы. Определение рисков на программном уровне определялось также на еженедельных совещаниях.

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

Обсуждая статус программы со старшими руководителями, информируйте их только о программных рисках, не о проектных рисках. Программных рисков может быть довольно много: от трех до шести.

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

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

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

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

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

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

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

Я могу вам дать еще один пример. Когда я работала в SAP Consulting, была одна программа, в которой я принимала участие. Риск-менеджмента (управление рисками) там не было. Знаете, что произошло? Появилась какая-то экселевская табличка и все руководители могли писать туда о своих рисках, проблемах, о способах их предотвращения, но топ-менеджмент об этом не знал – информация эта топ-менеджменту не предоставлялась. Через неделю все запланированные даты по устранению рисков были отложены. То есть не было это сделано вовремя. Потом клиент сказал: «Ну хорошо, сделаем это на следующей неделе». А на следующей неделе все проекты оказались в красной зоне и клиенту пришлось понести очень большие затраты для того, чтобы вернуться в зеленую зону: пришлось нанимать дополнительный персонал и так далее. То есть в конечном счете лучше таких ситуаций не допускать. Это мой стиль руководства. Я лучше изначально предупрежу руководство. Я люблю ночью спать нормально, а не просыпаться от кошмаров.

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

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

Если бы я пришла и сказала, что, например, не смогу сделать запланированную интеграцию с Sybase из-за того, что возник новый, более крупный проект по переводу ERP на HANA, я бы там на работе больше не появилась никогда, я так думаю. Это не те люди, которым нужно об этом говорить. Но зато своим непосредственным руководителям и своей команде нужно об этом сказать, нужно предупредить, что могут быть проблемы. Когда у людей есть это знание, они могут действовать, могут принимать меры и разработать аргументацию для высшего руководства.
Когда вы начинаете работать над риском? Когда риск становится проблемой? Либо есть какая-то процедура проактивного влияния на этот риск до того, как он стал проблемой? И если это действительно два разных подхода, то в какой пропорции работаете? Стратегия минимизации рисков очень важна, но не всегда можно предотвратить превращение риска в проблему: нужно эту проблему брать и думать над тем, как ее разрешать. Предотвращение превращения риска в проблему требует использования специальной стратегии минимизации рисков и максимально ранней их идентификации. Именно поэтому мы каждую неделю встречаемся и это обсуждаем. Нужно оценить следующие возможности: оставить ли ситуацию развиваться дальше или начать с ней бороться уже сейчас. В обоих случая важно правильно оценить затраты. Допустим, если не бороться с данным риском сейчас, он превратится в проблему – каких затрат потребует ее разрешение? Если же начать бороться с ним прямо сейчас, не допуская перерастания в проблему – во сколько это обойдется? То есть детально проработать два подхода, которые должны выбирать проектные и программные менеджеры. Для управления проектами вы можете использовать файлы Excel, Power Point – все, что вам привычно и удобно. Но их нужно обновлять часто, минимум раз в неделю, к обеду пятницы. Вы должны вести специальный журнал запросов об изменениях.

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

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

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

Биографическая справка:
Аня Леммниц работает в SAP с 2000 года. Она отвечает за стратегические проекты
SAP Global IT. Аня обладает богатым опытом по управлению программами и проектами по всему миру. В 2011 году она присоединилась к команде SAP Global IT где она возглавляет стратегическую программу «процессная и системная интеграция» по слиянию с компанией Sybase, где интеграция 27 различных компаний была завершена в июне 2013 года. Параллельно Аня занималась интеграцией приобретенной компании Ariba, а также участвовала в проекте по миграции ERP на платформу HANA.