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

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Упра­вле­ние сложными ли­чно­стя­ми в проектной группе»
Татьяна Шаньгина:
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная. Практический опыт доказывает справедливость концепции Уильяма Зиска о...
«Год спустя: что не­о­бхо­ди­мо знать о портфеле продуктов компаний SAP и SAP Business Objects»
Дмитрий Воронин:
1) Не совсем понятно, по поводу переименования SAP NetWeaver BI в SAP NetWeaver BW, т. к. по другим источникам информации, BW в последующем стали считать частью BI. 2) Желательно было-бы дать...

Мероприятия

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

Управление программами: «Почему бюрократия помогает?»

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

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

Управление программами: «Почему бюрократия помогает?»

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

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

Если у вас не создана оптимальная техническая инфраструктура, быстро возникают проблемы: она нужна для работы команд, должны быть карты доступа, ноутбуки, все остальное. Это задача, кстати, для ОУП — все организовать, и чем крупнее компания, тем более забюрократизирован такой процесс, на это требуется достаточно много времени. В проекте по переводу SAP ERP на HANA мы привлекали около 60 дополнительных сотрудников, которым нужно было организоваьт доступ, выделить ноутбуки, помещение предоставить — на это все требуется время, и это тоже нужно учитывать, что не сразу этот вопрос решается.

Также важно понимать, откуда будут браться исходные данные — из PowerPoint, Excel или других систем? Этот вопрос должен быть решен специалистами по управлению программами и проектами, и созданная структура должна получить одобрение руководства на самом начальном этапе проекта. В SAP мы планируем работу на первые полгода и потом смотрим, что необходимо будет в проекте дорабатывать в последние два квартала. В таком режиме мы решаем сначала самые важные, высокоприоритетные задачи. Это гибкий подход, который используется при работе над стандартными проектами. Нужно осуществлять мониторинг таких вещей более регулярно.

Проектный план подразумевает ответственность проект-менеджера, но ее рамки достаточно стандартны: делать все по расписанию, по графику, определять ключевые вехи проекта. То есть нужно обеспечить надежное планирование реализации проекта. Например, 8 релизов в год — с точным обозначением времени их выхода. В определенных проектах и программах у нас 12 вариантов реализации планируется на следующий год, на них нужно сконцентрироваться и собрать эти проекты воедино. И чем больше неопределенностей, тем хуже — нужно всегда скоординировать план А и план Б, это задача проектного менеджера.

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

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

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

Мы для этого разработали целый инструмент, который позволяет очень быстро, меньше чем за две минуты оценить риск, его возможное влияние на систему и сроки наступления этого влияния, кто «владелец» этого риска. Часто программный менеджер говорит: «Чтобы внести дополнительный риск и его описать, требуется слишком много времени!». А с другой стороны, говоришь: «Если риск есть, нужно его оценить, если этого не сделать, это слишком опасно».

Вот что всегда нужно бизнесу говорить: «Если я об этом риске не знаю, и если он возникнет, независимо от его масштаба — наше отрудничество будет под угрозой». Если это высокоопасный риск, то его статус нужно проверять, по крайней мере, раз в неделю и смотреть, какова его вероятность, какова динамика. И этим должен заниматься ОУП, используя определенные метрики. Если шкала до 12 доходит — можем риск не рассматривать; все, что выше 12 — рассматриваем; все, что выше 16 — направляем все внимание, регулярно к нему возвращаемся, еженедельно беседуем с людьми, ответственными за эту зону риска. Это должен взять на себя ОУП. Если риск, например, есть, но пока еще не наступил, я об этом проинформирую комитет только в том случае, если у него вероятность очень высокая, и он может появиться в определенных обстоятельствах. И тогда нужно принимать меры по его предотвращению и передавать информацию об этом риске руководящим сотрудникам компании, руководству компании и информировать о том, какие меры были приняты. Я не хочу обсуждать риски на управляющем комитете, потому что это всегда создает плохой имидж. Поэтому лучше проактивно должны эти риски рассмотреть и предотвратить.

Есть очень хороший инструмент, который позволяет вам не только IT-риски покрыть, но и бизнес-риски и определить, кто отвечает за проблемную область. Например, если не работает regression-тест, IT не занимаются тестированием, это риск. А кто ответственный? Business Program Manager. И ему можно задать вопрос — почему тестирование не проводится. Этот инструмент помогает вообще всем, а не только айтишникам.

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

Риск существует, он от вас не зависит, но если он наступит — мы знаем, что сделаем то и это. Если это делать более оптимальным образом, то даже можно оценить эти риски и увидеть: наступление этого риска обойдется в 160 тысяч, если митигирую риск — обойдется в 80 тысяч. Но нужно ли тратить деньги на снижение степени риска, если цена вопроса — 10 миллионов? В конечном счете, обойдется в 20 тысяч, я с этим готов смириться. То есть это не так дорого мне будет стоить. То есть все нужно посчитать и прикинуть финансы, правильно оценить риски.

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

Процесс выглядит следующим образом. В определенный момент времени нужно определить, что вы будете делать с риском, с проблемным вопросом. Поднять этот вопрос наверх, реализовать решение, о котором все должны знать, и закрыть вопрос. Так что все зависит от того, будете вы выносить этот вопрос на более высокий уровень или нет, ожидаете ли вы возможности того, что кто‑то на вышестоящем уровне разрешит этот вопрос. Если да, то тогда я эскалирую это вопрос. Иногда просто выбора нет. В прошлом году, когда мы занимались проектом по переходу на HANA, 60 важных ресурсов были сняты с других программ. Архитекторы, программные специалисты, на их работе это сказалось. Это проблемные были для них вопросы, но это решение было в целом для компании, так что тут, в такой ситуации, пострадали некоторые вовлеченные лица. Другое дело, что этот процесс‑то был сделан максимально прозрачным. Так что к таким методам тоже можно прибегать.

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

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

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

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

Это пример того, кто кому и по каким вопросам отчитывается, с какой частотностью, с какой частотой. Руководящий комитет проводится ежеквартально. Есть инструменты подобного рода для управления изменениями — они обсуждаются с бизнесом: в каком формате предоставлять отчет о состоянии, анализ получаемых выгод. Возможно, руководителей программ и проектов имеет смысл знакомить только с экономической выгодой. Это не так‑то сложно, просто на это они должны тратить чуть больше времени, но если они это будут делать регулярно и качественно, то получат четкое видение, на каком уровне развития программа находится. Также отчет делается по задачам — соблюдение сроков, рамок бюджета. Управление основано на временных рамках, бюджете, затратах — есть индикатор затрат, индикатор прогресса — и таким образом вы можете добиться нужного результата.

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

У нас существует инструмент управления документацией — Solution Manager, в частности, для того, чтобы с этим работать, поэтому очень важно иметь единую структуру. Может быть, общая папка у вас будет или другое решение — в любом случае, эта информация должна находиться в одном месте. Основная информация обязана храниться в одном месте, которое можно было бы легко проверить, спросить: «Где документы?» — «Там». Такую структуру можно создать один раз и копировать, использовать в разных программах. Чаще всего такой подход и используется.

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

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