Руководство по внедрению управления проектами

От авторов

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

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

Вместо
предисловия

«Что первично: софт или процессы?»

 По роду своей деятельности мне часто приходится
сталкиваться с вопросом: а нужно ли программное обеспечение для старта проектного управления в компании? Вопрос непростой и
очень важный. Ведь начиная изменения в управлении, невозможно на 100% быть уверенным в их
успехе. А программное обеспечение,
как правило, требует вложений, и безотлагательных.

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

—                  
решить, какие процессы вы хотите внедрить;

—                  
попробовать их внедрить;

—                  
удалить то, что не работает;

—                  
добавить то, чего не хватает;

—                    
утихомирить явных противников;

—                  
обеспечить поддержку сторонников.

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

PMBok (англ. Project
Management Body of Knowledge) – свод профессиональных знаний по управлению проектами.

Все логично, красиво
и…
абсолютно не сработало у меня.

Объясню, почему.

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

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

 Программный   продукт, который делает                             управление эффективным

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

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

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

 Технологии решают все

 В вопросе использования программного продукта я не
хочу ставить под сомнение профессионализм тех преподавателей и известных учебных
центров, в которых
я училась. Но я понимаю, чем они
руководствовались. Действительно, если говорить о мировой практике, которая
сконцентрирована в PMBoK, то мы должны следовать золотому правилу: «7 раз
отмерь – один раз отрежь». Только для современного мира его нужно
немного преобразовать.

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

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

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

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

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

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

 Пошаговое руководство к
действию

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

Шаг 1. Определите тот перечень процессов, которые
вам необходимы на старте. В этой книге мы как раз рассказываем о
самых основных, которые и помогли мне в моем успешном опыте

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

Шаг 3. Зафиксируйте бюджет, который
вы можете использовать для покупки
программного продукта. Он может быть частью
экономического обоснования внедрения КСУП или это может быть решением
руководства.

КСУП – корпоративная система управления проектами. Аналог в российском ГОСТ: Система менеджмента проектной деятельности.

Шаг 4. Посмотрите решения на рынке и
выберите в соответствии с вашим бюджетом. Для старта вам необходимо: 

·                  
решение, которое поддерживает требования к вашим
процессам и уровню автоматизации – оно должно
уметь делать все, без чего вы не представляете свою работу;

·                  
простое решение, чтобы
ваши сотрудники могли
быстро понять, как в нем работать – дружественный интерфейс и возможность самостоятельного быстрого
обучения;

·                  
решение, позволяющее автономно его перенастраивать

– чтобы не тратить средства на программирование и кастомизацию (экономия
на работе ИТ-специалистов и заказной разработке);

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

·                  
решение, которое используют крупные игроки – гарантия того,
что что кто-то
до вас уже «наступил на все
грабли».

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

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

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

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

 Рекомендации к использованию материала

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

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

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

Заказчик
проекта – лицо, которое является владельцем результатов
проекта, определяет (утверждает) требования к ним и является их основным
приемщиком. Например, начальник отдела логистики может являться заказчиком проекта по переоборудованию складов, а
директор торговой компании может являться заказчиком внедрения ERP-системы.

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

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

Глава     1.      Зачем     бизнесу                  проектное управление?

1.1.               
Чтобы выжить, нужно уметь меняться

 Каким одним сводным понятием можно охарактеризовать
внешнюю среду современного бизнеса? Мой ответ – изменения. А каким словом можно охарактеризовать
внутреннюю среду организации, которая хочет соответствовать рынку и быть впереди
конкурентов? Догадались? Точно – изменения. Оно включает в себя гибкость, постоянное
изучение клиентов, улучшение процессов, вывод на рынок новых продуктов/услуг
и так далее.

«Нужно
бежать со всех ног, чтобы только оставаться на месте, а
уж чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» © Льюис Кэррол, «Алиса в стране чудес».

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

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

1.2.             
Проекты как основной источник дохода

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

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

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

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

Руководители проектов в такой компании точно знают, как
реагировать на риски, какие следующие шаги в проекте, какие
вопросы требуют немедленного решения. Исполнители ориентируются на четкий и
согласованный с ними план исполнения, эскалируют вопросы и получают ответы
вовремя. А заказчики… Скорее всего, заказчики
довольны, что работают с таким партнером, который знает свое дело и умеет
эффективно управлять проектом для получения наилучшего результата.

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

Кейс.
Агрохолдинг, 15 000 сотрудников

КОМОС ГРУПП – один из крупнейших российских агрохолдингов.

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

Отклонения по некоторым проектам доходили до 100% как по срокам, так и по
бюджету. Финансовый директор холдинга решил взять ситуацию под контроль и захотел знать ФИО каждого ответственного за срыв сроков проектов. 

Через 2
года средние отклонения по срокам и бюджетам проектов составляли не более 10% при портфеле
проектов в 4 млрд
руб.

 1.3.             
Проекты как средство конкурентной борьбы

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

«Алиса в стране чудес». Ведь
если
не
думать
о
том, как
стать

номером один на
рынке, то рано или поздно придется решать вопросы выживания.

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

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

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

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

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

Теперь представьте, вы вкладываете свои 10 млн руб. (бюджет
портфеля проектов). Вы хотели бы получить гарантию, что деньги к вам вернутся и желательно с
процентами? Конечно, но как это обеспечить? Как
гарантировать, что проекты будут реализованы именно так, как
мы задумали, и в указанные сроки? 

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

Кейс. Банк,
входящий в ТОП-50 российских банков

Татфондбанк входит в 50 крупнейших банков
России, около 3000 сотрудников, 94 подразделения и филиала. В сентябре 2013 года
было принято решение о создании
офиса управления проектами. На тот момент
отклонения по срокам проектов составляли до 100%. В банке посчитали, что если хотя бы один
проект (выпуск нового банковского продукта) благодаря выстроенной системе
закончится на один месяц раньше, то полученная прибыль
окупит инвестиции в создание проектного офиса и внедрение ИСУП.

Сказано – сделано. В 2015 году отклонения по срокам проектов уже варьировались в пределах от 5 до 15%, а к началу 2016 года подошли с
нулевым отставанием. Вот у кого стоит поучиться проектному управлению, что мы, кстати,
и делаем. 

1.4.             
Резюмируя главу

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

Глава    2.    Что    такое                «Управление          по результатам»?

2.1.             
Почему ручное управление проектами не работает?

 ·                  
Несмотря на большое
количество проектов, компании
не достигают своих стратегических целей.

·                  
Результаты проектов не используются, а проекты часто
затягиваются в бесконечную деятельность без результата.

·                  
На уровне отделов
– люди перегружены, а продвижение вперед – незаметно.

Почему это происходит?

Диалог
с собственником крупной компании:

«У нас сейчас есть отдельная система управления задачами,
еще раньше мы задачи учитывали в системе документооборота. Но, к сожалению, это не принесло
нам особой пользы… То, что задача зафиксирована в отдельной системе
не дает никакой
гарантии, что она
будет сделана».

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

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

Какие именно? Рассмотрим
далее.

2.2.           
Процессы регулярного менеджмента для управления по результатам

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

2.2.1.                          
Какие основные шаги нужно выполнить для получения результата?

Мы предлагаем использовать единый
и универсальный подход:

Шаг 1. Сформулируйте конкретные измеримые результаты и
требуемый срок их получения.

Шаг 2. Определите ответственных за получение результатов, согласуйте
их обязательства по получению результатов.

Шаг 3. Регулярно
контролируйте статус получения результатов.

Шаг 4. Предоставьте возможность ответственным вносить
предложения по изменениям и своевременно реагируйте на озвученные риски.

Шаг 5. Определите лиц, способных оценить подготовленные
результаты для применения в ваших целях.

Шаг 6. Определите мотивацию ответственных в соответствии с
полученными результатами и сроками их передачи.

Общий вид этого
процесса показан на рисунке 1.

 Рис. 1. Модель управления по
результатам

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

2.2.2.                    
Как это
работает на уровне программы или портфеля проектов?

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

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

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

Ежеквартально или
раз в полугодие собирается информация по исполнению плана и представляется
высшему руководству.

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

 2.2.3.              
Как это работает
на уровне управления проектом?

 На уровне управления проектом, в первую очередь, утверждаются
цели и результаты проекта, которые фиксируются в Уставе проекта. На основании
Устава определяются планы получения контрольных результатов – фиксируются
промежуточные результаты и сроки их получения.

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

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

2.2.4.              
Как это
работает на уровне ежемесячного плана
отдела

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

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

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

 2.3.           
Что такое «Система управления
проектами»?

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

Корпоративная система управления проектами (далее – КСУП), если говорить простым языком, представляет собой три основных
элемента:

·                  
свод правил, разработанных для управления проектами;

·                  
выделенные   подразделения, которые осуществляют контроль
за исполнением таких правил;

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

Основой КСУП является информационная система управления проектами (далее
ИСУП), которая ведет
участников проектной деятельности по процессу, сводит
необходимую информацию для контроля
соблюдения правил и хранит данные о
проектах.

Также неотъемлемыми частями
КСУП являются нормативные документы (регламенты, методики, шаблоны
и т.п.), система
мотивации и система обучения персонала. В общем
виде структура КСУП
представлена на рисунке 2.

Рис. 2. Корпоративная система
управления проектами

 Построение такой системы
является непростой задачей. И чем более зрелой является компания с
точки зрения обеспечивающих элементов, тем более сложной является построение КСУП.

С чего начать? 

Для построения КСУП нужно начать с простых, но
твердых шагов.

Шаг 1. Определите процессы проектного
управления, которые, прежде всего, должны
контролироваться системой.

Шаг 2. Определите
правила выполнения этих процессов.

Шаг 3. Назначьте
ответственных за контроль правил.

Шаг 4. Обучите персонал правилам.

Шаг 5. Подготовьте
информационную систему.

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

Будьте про-активны:

·                  
чего-то не хватает – добавляйте процессы;

·                  
что-то не работает
– корректируйте правила
и обучайте персонал;

·                  
слишком много ручных   операций – донастраивайте информационную систему.

 2.4.           
Основные процессы управления проектами

 Какие процессы, прежде всего, нужно настроить для улучшения управляемости проектов и получения эффекта масштаба?

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

Рис. 3. Группы процессов управления
проектами

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

Первоочередные процессы для
управления по результатам:

1)              
Определение целей и старт проекта;

2)              
Создание и утверждение плана работ;

3)              
Исполнение работ и подготовка отчетности;

4)              
Организация регулярных коммуникаций;

5)              
Оценка выполнения и принятие решений;

6)              
Приемка результатов и оценка;

7)              
Мотивация персонала.

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

Однако этого процесса не указано в приведенной выше последовательности. Почему?

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

Глава 3. Проектный офис

3.1.             
Что такое и для чего нужен Проектный
офис?

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

Для начала давайте
определим понятие «Проектный офис», которое и
будем использовать в этой книге, для этого обратимся к международным стандартам. Во избежание путаницы договоримся, что не
будем разделять понятия «Проектный офис» и «Офис управления проектами», и будем
употреблять оба понятия как синонимы
друг другу.

Проектный офис – организационная структура, которая стандартизирует
процессы руководства проектами и способствует обмену ресурсами, методологиями,
инструментами и методами. Степень ответственности Проектного офиса может
варьироваться от оказания поддержки в управлении проектами до прямого
управления одним и более проектами (@PMBoK Guide 5th). 

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

Для понимания разделим понятие на
три основные группы:

1)  
Корпоративный Проектный офис (далее КПО) –
самостоятельное постоянное структурное подразделение, отвечающее за поддержку и развитие корпоративной системы проектного управления в масштабе организации. КПО –
владелец процессов проектного управления в организации.

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

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

То есть все три направления создаются для достижения разных целей и несут
совсем разные эффекты:

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

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

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

Каждая группа отличается уровнем управления, подчинения, составом персонала, функциями и полномочиями. Если говорить о структуре подчинения, то эти три
направления можно определить так: 

Вид           Проектного офиса	Управление	Подчинение решениям	Состав
Корпоративный	Первое лицо	Проектный комитет	Проектный директор
			Методологи ПУ Контролеры Администрато ры ИСУП
Управляющий	Руководитель направления бизнеса (директор по ИТ, директор                          по продажам, директор                          по консалтингу                            и т.п.)	Корпоративн ый Проектный офис	Проектный директор Руководители проектов
Администрирую щий	Руководитель проекта/програм мы	Корпоративн ый Проектный офис Управляющи й Проектный офис	Администрато ры проектов

 Функции и полномочия Управляющего и Администрирующего Проектных офисов
всегда зависят от конкретного направления бизнеса (его специфики, внешних
требований к его продуктам, уровню компетенций и т.п.) или конкретного
проекта/программы (плана его коммуникаций, состава участников, методов
выполнения работ и пр.). Поэтому в этой книге мы будем говорить о
наиболее значимом в процессе построения КСУП варианте
– Корпоративном Проектном
офисе (КПО). Далее по тексту будем его называть Проектным офисом, подразумевая именно корпоративный вариант.

Основное назначение такого
варианта Проектного офиса это:

—       
Разработка    единых    стандартов     управления (процессы, методики,
формы, шаблоны);

—       
Центр координации проектов, реализуемых разными
функциональными подразделениями;

—       
Основной источник независимой информации о ходе
выполнения проектов («общая картина» выполнения проектов для руководства);

—       
Центр компетенции, консультаций и наставничества (методологическая
и организационная помощь руководителям проектов и программ);

—       
Центр аналитики и мониторинга (своевременная
информационная поддержка принятия решений для руководства).

 3.2.           
Цели и функции
Корпоративного Проектного офиса

 У многих компаний
возникает логичный вопрос:
если модель управления по результатам известна, внедрены основные процессы управления и внедрена
информационная система, заменит ли это необходимость создания Проектного офиса? Конечно, нет. Давайте
разбираться в этом.

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

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

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

—       
наведение порядка;

—       
централизация и стандартизация управления;

—       
совершенствование процессов проектного
управления;

—       
обучение персонала методам управления
проектами;

—       
повышение ценности от реализации проектов.

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

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

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

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

—       
Повышение удовлетворенности   от   управления проектами (сверху – руководство и снизу – проектные команды);

—       
Сокращение отклонений от плановых сроков/бюджетов по
типовым проектам;

—       
Снижение          сроков           принятия решений             по проектам/программам;

—       
Повышение   уровня    компетентности    персонала методом управления проектами;

—       
Сокращение сроков   подготовки   отчетности   по портфелю проектов.

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

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

Если говорить о наиболее популярных функциях ПрОф, которые
он, чаще всего, выполняет, и целях, на которые они направлены, то можно
выделить следующие: 

Функция	Выгоды/цели
Разработка                            и развитие методологии управления	Снижение конфликтов относительно процедур управления, повышение скорости процессов управления, снижение рисков и повышение компетенций управления
Формирование сводной отчетности                           по портфелю проектов для топ- менеджмента	Повышение скорости получения информации о статусе выполнения проектов, снижение рисков ресурсных конфликтов, повышение скорости принятие                                решений,                                 повышения удовлетворенности заинтересованных сторон
Контроль корректности использования методологии	Снижение управленческих ошибок, повышение уровня компетентности персонала, снижение рисков
Контроль достижения проектных целей	Рост количества проектов с достигнутыми целями,         повышение                       удовлетворенности заинтересованных сторон
Обеспечение (организация) Проектного комитета	Повышение скорости принятия решений, снижение уровня конфликтов между заинтересованными сторонами проекта, повышение                                                    удовлетворенности заинтересованных сторон, снижение рисков принятия решений
Настройка                            и поддержка ИСУП	Снижение затрат на управление, снижение рисков человеческого фактора, снижение уровня просрочки выполнения проектных работ, повышение                                                    удовлетворенности заинтересованных сторон
Обучение проектного персонала	Повышение уровня компетентности персонала методом управления проектами
Подготовка данных                         для мотивации проектного персонала	Снижение уровня конфликтов между участниками проектных команд, повышение уровня удовлетворенности заказчиков проектов

Приведенные функции являются основой построения КСУП, но, конечно, не
покрывают все ее потребности. При построении процессов управления функции
должны быть дополнены. Примером декомпозиции функций может быть конкретизация
функций ПрОф для базовых процессов управления по результатам: 

	Этап                         модели управления                                 по результатам	Функция Проектного офиса
1	Установка                            целей. Фиксация результатов	—      Организация и модерирование совещаний для разработки Устава проекта; —      Подготовка первой версии Устава; —      Согласование Устава проекта относительно используемой формы (должен быть единый шаблон), соответствие цели требованиям SMART, формулировка контрольных точек;
		— Контроль         сроков                          процесса инициации             проекта              и информирование заинтересованных лиц о просрочке.
2	Формирование                                    и утверждение плана	—      Контроль согласования плана по форме и содержанию: формулировка контрольных точек, согласование результатов и сроков с исполнителями и приемщиками, утверждение выделения ресурсов; —      Сохранение плана в ИСУП.
3	Сбор   отчетности            по выполнению	—      Обеспечение сбора регулярной отчетности по проектам на уровне Руководителей проектов: ·                  актуализация         статуса выполнения задач; ·                  предоставление рисков и прогнозов         выполнения контрольных точек высокого уровня; ·                  предоставление требуемой информации о выполнении этапов и фаз; ·                  учет движения денежных средств; —      Подготовка сводной отчетности по портфелю для топ-менеджмента; —      Подготовка сводной отчетности для Кураторов и спонсоров проектов; —      Обеспечение коммуникаций проектных команд: регулярное проведение проектных совещаний, фиксация протокола.
4	Оценка выполнения и принятие решений	—      Сбор вопросов для принятия решения; —      Организация регулярных заседаний Проектного комитета и подготовка требуемых отчетов, а также фиксация решений и контроль их исполнения;
		—  Информирование заинтересованных сторон о принятых решениях.
5	Приемка результатов	—      Согласование итогового отчета проекта относительно используемой формы (должен быть единый шаблон), фиксация отклонений, анкетирование Заказчика по удовлетворенности проектом; —      Проведение анализа выполнения проекта для фиксации лучших практик; —      Архивация документов проекта.
6	Расчет                   мотивации ответственного	— На основании утвержденных правил и на основании данных итогового отчета подготовка данных для расчета                                     материального вознаграждения или определения иных форм мотивации.

Пример процессов под контролем Проектного офиса представлен на рисунке ниже. 

Пример процессов с контролем Проектного
офиса

3.3.           
Состав Корпоративного Проектного офиса

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

—       
Коммуникации – способность договариваться о правилах,
выявлять ключевую информацию, формулировать итоги совещаний и т.п.;

—       
Анализ и расчеты
– способность рассчитывать экономическую целесообразность проектов или решений в проектах,
рассчитывать доходность компании, выявлять требуемые статьи затрат или дохода;

—       
Документирование – способность создания понятных и
полных документов для сотрудников и руководства (регламенты, методики, шаблоны
и формы);

—       
Настройка ИСУП – способность настраивать существующие
ИТ-инструменты под потребности процессов проектного управления, в том числе
отчеты, представления и дашборды,
реквизиты и справочники, печатные формы
и другое;

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

Исходя из представленных компетенций для ПрОф важно
выделить несколько ключевых ролей:

·       
Руководитель проектного офиса (Проектный директор)

·       
Методолог

·       
Администратор проектов/программ

·       
Администратор ИСУП

·       
Другие роли:

o        
Тренер

o        
Менеджер по ресурсам

o        
Координатор программ

o        
Координатор портфеля

o        
Аналитик

3.3.1.                                             
Роль:     руководитель       Проектного офиса (Проектный директор)

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

Как правило, функциями этой роли
являются:

—       
Контроль соответствия проектов целям
организации;

—       
Контроль процессов управления портфелем и программами;

—       
Организация и контроль
процесса приоритезации портфеля;

—       
Обеспечение     представления     сводной отчетности         по исполнению портфеля;

—       
Контроль     применения    корпоративной методологии                          и инструментов управления;

—       
Контроль сроков и качества ключевых
проектов;

—       
Обеспечение Проектного комитета и руководителей
портфеля/программ необходимой информацией для принятия решений;

—       
Организация работы ПрОф.

3.3.2.            
Роль: методолог Проектного офиса

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

Основные функции методолога:

—       
Формирование корпоративных стандартов и методологии их
применения, в том числе описание процессов проектного управления;

—       
Интеграция инструментов управления проектами с другими
системами менеджмента;

—       
Проектирование корпоративной базы знаний по проектам;

—       
Разработка корпоративной системы отчетности;

—       
Выполнение аудитов проектов;

—       
Внутреннее обучение и сертификация.

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

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

3.3.3.            
Роль: администратор проектов/программ

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

Основные функции администратора
проектов/программ:

—       
Поддержка процессов проектного управления, обеспечение
корректности документов и процедур;

—       
Соблюдение   корпоративной    методологии (консультации руководителя)
при выполнении отдельного проекта;

—       
Организация регулярных обязательных коммуникаций (с
Заказчиком, командой, поставщиками и т.п.) и подготовка для этого необходимой отчетности;

—       
Поддержка документооборота;

—       
Актуализация базы знаний.

3.3.4.                
Роль: администратор информационной системы управления проектами

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

Основные функции администратора
ИСУП:

—       
Предоставление   доступа   к   информационному ресурсу                   (в
соответствии с политикой безопасности);

—       
Настройка функционала системы;

—       
Обеспечение технической поддержки (первая линия);

—       
Проведение обучения по использованию;

—       
Взаимодействие с вендором для развития системы
(обсуждение технических заданий
на развитие функционала, устранение дефектов,
установка обновлений и т.п.).

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

3.3.5.             
Дополнительные роли

В зависимости от задач ПрОф, а также требований
заинтересованных сторон возможно выделение других ролей.
Если в компании ведутся
сложные программы или
существует несколько крупных
портфелей (бизнесов) целесообразно выделить администраторов портфелей, которые
обеспечат централизацию информации по проектам, представят топ-менеджерам
нужные данные, организуют необходимые в рамках методологии коммуникации и принятие решений.
Если компании важно
строго контролировать ресурсы, то возможно выделение отдельного
менеджера по ресурсам, который сможет отслеживать план по использованию
ресурсов (например, бюджета), контролировать риски перерасхода, своевременно
выявлять экономию и информировать о ее наличии, организовывать принятие
согласованных решений о перераспределении ресурсов. Для многих компаний
важной функцией ПрОф является умение расчета экономической целесообразности
идей, а также отслеживание экономического эффекта для реализованных проектов. В развитых
Проектных офисах, как
правило, существует собственный тренер по
проектному управлению, который регулярно организует учебные курсы и
сертификацию для проектных команд, ведь команда проекта – временное объединение
людей, для которых важно понимать используемые методы и уметь их применять.

 3.4.           
Принципы построения эффективного Проектного офиса

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

Посмотрим на
проблему с позиции двух самых заинтересованных сторон (ролей) проектного
управления и возможных заказчиков ПрОф: со стороны топ-менеджмента и со стороны Руководителя проекта и
членов его команды.

Топ-менеджмент, прежде всего, ожидает от ПрОф возможности простого и
быстрого понимания статуса управления. Например, своевременного обнаружения
существующих рисков для возможности повлиять ни них. С другой стороны,
топ-менеджмент ожидает трансляцию и исполнение корпоративных стандартов,
чтобы управление проектами в организации было четким, слаженным,
прогнозируемым. Если после завершения процесса внедрения КСУП у высшего
руководства не появляется четкой картины, как управляются проекты, количество
реализованных рисков не сокращается, нет понимания по принятым решениям, а от сотрудников
поступают жалобы о трудно применимых процессах, которые тормозят получения
важных результатов, – такой ПрОф будет не нужен,
и топ-менеджмент никогда
не будет его союзником.

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

Такую картину
можно изобразить на простой схеме:

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

1.    
Правильно провести проект внедрения
КСУП. Именно проект – с фиксацией целей, результатов, планом коммуникаций,
реестром рисков и прочими приемами
управления.

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

3.  
Использовать информационную систему управления
проектами в соответствии с уровнем зрелости проектного управления, сложностью
проектов и компетенциями пользователей.

4.  
Разработать единую систему мотивации для Руководителей
проектов/программ и сотрудников Корпоративного Проектного офиса.

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

Ответы на
некоторые из этих вопросов мы и постарались раскрыть в нашей книге. 

Глава 4. Построение процессов
проектного управления

4.1.             
Определение целей и результатов

 4.1.1.                
Решение о проекте основано
на целях компании

Определение целей и результатов проекта, его границ и
условий происходит (и должно происходить) еще на прединвестиционной фазе.
Тогда, когда решение о проекте еще только готовится. Уже тогда важнейшей
работой Заказчика или инициатора проекта является четкая формулировка возможных
выгод от проекта, определение значимых результатов, которые обеспечат
достижений поставленных стратегических или тактических целей. Ведь решение о
целесообразности проекта и выделении для его выполнения необходимых ресурсов
должно строиться на четком осознании выгод проекта и сравнении этих выгод с другими предложениями (проектами). Именно
конкуренция между целями проектов в связке с пониманием влияния
проектов на выполнение задач
топ-менеджмента может обеспечить лучший подбор объектов для инвестиций.

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

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

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

Как взаимодействуют эти участники? В чем основной интерес каждого из них?

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

2.  
Заказчик. Именно
Заказчик, чаще всего, является инициатором проекта, и именно он собирает
доказательства необходимости проекта: обосновывает его выгоды, защищает перед руководством его целесообразность, готовит технико- экономическое
обоснование (окупаемость). Тот, кто заказывает проект, отвечает перед Куратором
за достижение бизнес-выгод проекта и за отдачу выделенных инвестиций
(ресурсов). Получается, что Куратор выделяет необходимые ресурсы за то, что Заказчик обязуется
вернуть их в виде выгод проекта.

3.  
Руководитель проекта. Руководитель проекта отвечает перед Заказчиком за поставку требуемых результатов, их качество
и расходование выделенных ресурсов. То есть Заказчик
должен четко определить требуемые результаты и сформулировать конкретные
критерии их качества для гарантированной приемки. Изменение требований к результатам проекта
лежит в зоне ответственности Заказчика, а просрочка поставки
утвержденных результатов, перерасход бюджета или их несоответствие содержанию и описанным критериям качества

– в зоне ответственности Руководителя.

Кратко такое взаимодействие можно
изобразить на схеме:

 

 Как легко заметить
из схемы, все взаимодействие построено исходя из достижения именно
бизнес-целей компании (стратегических или тактических), а не конкретного Заказчика. Куратор утверждает цели проекта в соответствии именно
с выполнением стратегии, Заказчик на основе утвержденных целей формулирует результаты и отвечает за достижение бизнес-выгод при их использовании, а Руководитель
отвечает за поставку результатов в соответствии с требованиями Заказчика.

—       
Куратора: выделить необходимые ресурсы;

—       
Заказчика:   достичь    бизнес-выгод   (окупить выделенные ресурсы);

—       
Руководителя проекта: получить необходимые результаты.

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

Основные
разделы Устава:

—       
Суть проекта, причины его инициации;

—       
Цели проекта, их влияние на бизнес-цели компании;

—       
Основные результаты проекта
и сроки их получения;

—       
Выделяемые ресурсы: финансовые, материальные, трудовые;

—       
Требуемый срок завершения всего проекта;

—       
Риски и допущения проекта;

—       
Основные ответственные стороны;

—       
Что-то другое важное,
о чем стоит договориться «на берегу».

 Основные
согласующие стороны Устава:

—       
Заказчик проекта;

—       
Куратор проекта;

—       
Руководитель проекта;

—       
Ключевые     участники      (исполнители     и пользователи результатов);

—       
Владельцы ресурсов (например, руководитель финансовой
службы, функциональные руководители основных участников);

—       
Сотрудники, ответственные за контроль достижения целей
проекта (например, за мониторинг выполнения
бизнес-плана и других показателей проекта);

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

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

 4.1.3.                   
Три шага определения проекта для достижения цели

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

1.         
Цель проекта: для изменения каких
показателей бизнеса запущен проект, какое измеримое
изменение необходимо и когда планируется получение выгод;

2.         
Результаты: что, когда и в каком размере (объеме)
должно быть получено по итогам проекта;

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

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

 4.1.4.              
Правила определения целей

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

Когда не стоит
принимать решение о запуске проекта:

·       
Обоснование необходимости выполнения строится только на искусстве убеждения и красноречии Заказчика;

·       
Цель сформулирована общими словами: «повышение
эффективности», «автоматизация»,           «оптимизация»,

«модернизация», «преимущества»,
«снижение рисков»;

·       
Проект не подкреплен объективными доказательствами
необходимости (договорами, документами, независимыми оценками и т.д.);

·       
Нет понимания будущих изменений в цифрах.

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

Критерии SMART:

·       
Specific (конкретные) – определите используемые в
компании показатели, которые должны измениться после выполнения
проекта (чистая прибыль, количество клиентов, снижение расходов на
обслуживание, средняя оценка качества продукции и т.п.);

·       
Measurable (измеримые) – определите, на сколько и по какой шкале должен измениться показатель, кто может его замерить,
есть ли инструмент для измерения, нужно ли их создавать в проекте;

·       
Attainable (достижимые)
– сформулируйте, за счет чего планируется достигнуть цели, какие результаты
планируется получить;

·       
Realistic (реалистичные) – убедитесь, что
выполнение проекта позволит достичь желаемой
цели, опишите альтернативы;

·       
Time-bounded (ограниченные сроки) – определите
период по наступлению/окончанию которого должна быть достигнута цель. Цель
может звучать как «к ДД.ММ.ГГГГ» или «в течение квартала после завершения
проекта» или «на момент завершения
проекта» или «в течение года после запуска оборудования» и т.д.

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

 4.1.5.              
Как договариваться о результатах

 В зависимости от компетенции, опыта,
взглядов, выгоды Заказчика или Руководителя проекта, каждый
из них будет
понимать продукт (или
результат) проекта по-своему. Это
мина замедленного действия, которая ожидает завершения работ. А в момент
завершения могут выявиться скрытые требования к результатам, обнаружиться разное
понимание одних и тех же формулировок, что может привести к задержкам завершения работ, переделкам, трате дополнительных ресурсов и разного рода другим конфликтам.
К сожалению, совсем избежать таких конфликтов не получится, но сократить их,
уменьшить риск их возникновения можно, если формулировать результаты правильно.

Недостаточно    сформулировать    результаты    общими                              словами:

«внедренная система», «готовое здание», «заключенный контракт»,

«доставленный груз».

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

Что для этого стоит предусмотреть:

1.    
Выделить отдельный раздел Устава с описанием ключевых
результатов:

—    
определение      конкретных       артефактов (документов, материалов,
результатов) и их статуса;

—     установка правил приема и передачи;

—    
назначение ответственных за подготовку и приемку.

2.  
Описать правила формулировки результата. Например, всегда формулировать результат: что
должно появиться, где, совершенный вид, прошедшее число. Эффективнее прописать правила непосредственно в форме
Устава, чтобы при заполнении Руководитель проекта и Заказчик могли увидеть
правила и их применять.

3.  
Определить рамки для снижения рисков
заинтересованности. Например, зафиксировать, что ответственным за
приемку результата не может быть подчиненный Руководителя проекта или, тем
более, сам руководитель. Или жестко прописать, что ответственным может быть
только владелец продукта или Заказчик.

4.  
Прописать полномочия ПрОф для контроля соблюдения правил
и утвердить их на уровне формального документа (Приказа, Положения и т.п.).

5.   
Провести учебный курс для Руководителей проектов, где
выработать навык корректной формулировки целей и результатов. И объяснить им
риски некорректной формулировки, чтобы снизить
сопротивление.

 Примеры корректной формулировки результатов:

Результат	Правила приемки	Ответственный
В           организации внедрена     система управления клиентами (CRM)	Не менее трех филиалов подтвердили промышленную эксплуатацию                                               системы (система                                    регулярно используется,                                   критичных ошибок нет).	Директор                       по продажам
Запущена рекламная кампания	Рекламный блок на тему нового продукта запущен не менее, чем на трех радиостанциях, сайте компании и Instagram	Руководитель отдела продаж
Здание     сдано                  в эксплуатацию	Заказчик подписал акт приемки в соответствии со СНиП	Заказчик

 4.1.6.              
Включение мотивации на результат

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

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

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

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

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

Итак, что же
такое критерий успеха и как его определить?

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

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

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

4.  
Если критериев несколько, должно быть определено, как делится
премиальное вознаграждение (премия за результат). Например, для каждого
критерия определяется доля из премиального фонда проекта.

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

6.  
Критерий должен быть интересен Заказчику проекта, и он
готов платить за выполнение критерия.

7.   
Критерий должен быть выполним Руководителем проекта.
Он готов терять существенный бонус, если не выполнит его. То есть он должен
оценить критерий на выполнимость и понимать
свою ответственность за него.

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

1.    
Критерии     успеха     формулирует     Заказчик проекта         и согласовывает с Руководителем проекта.

2.  
Критерии отвечают на вопрос: как я (Заказчик) пойму, что этот продукт сделан хорошо?

3.  
Наиболее   весомый   критерий    должен   отражать главный результат или
выгоду проекта.

4.  
Премиальный    фонд    за    выполнение критериев           успеха определен на старте проекта
и зафиксирован в Уставе.

5.   
За выполнение критериев каждый исполнитель получает не
менее 15% от текущего дохода.

6.   Критериев успеха не должно
быть более пяти.

Результат	Критерий успеха
В            организации внедрена      система управления взаимоотношениями с клиентами (CRM).	За период опытной эксплуатации системы зарегистрировано не более трех критичных замечаний от пользователей. За период опытной эксплуатации простой системы составил не более двух часов.
Запущена рекламная кампания.	За первые 2 недели работы рекламной кампании зарегистрировано не менее 15 заявок на поставку.
Здание     сдано                  в эксплуатацию.	Комиссия оценила комфорт в среднем не менее чем на 8 баллов из 10 по параметрам: чистота окон чистота подъездов  скорость лифтов комфорт паркинга

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

 4.1.7.               
Шаги для старта управления по целям

 ·       
Утвердите правила формулировки цели по SMART.

·       
Утвердите правила формулировки результатов и критериев
успеха.

·       
Разработайте шаблон Устава проекта и снабдите его
простой инструкцией по заполнению.

·       
Определите ответственность Проектного офиса за соблюдение корпоративных стандартов
оформления Устава и его согласования.

·       
Проведите обучение Заказчиков и Руководителей проектов.

·       
Наделите полномочиями Проектный офис не допускать к
рассмотрению проекты с нарушением установленных правил.

 4.2.         
Управление проектами по контрольным точкам

 4.2.1.              
Почему планирование по-старому не работает?

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

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

 4.2.2.            
Какова суть метода
контрольных точек?

 Основная идея метода состоит в том, что
вместо контроля процесса исполнения проекта Руководство компании
концентрируется на контроле своевременной поставки ключевых результатов. Таким
образом, в фокусе всегда остается требуемый результат, успешность
выполнения оценивается на основании отклонения сроков его получения, а
его приемка качества делегируется квалифицированному специалисту или
непосредственно оценивается Заказчиком.

При таком подходе отчетность для Руководства
максимально прозрачна и не требует изучения лишней информации. Контроль
получения плановых результатов дает понимание движения проекта и не позволяет
откладывать проблемы «на потом». Для Руководителей проектов и
исполнителей работ такой подход гарантирует политику невмешательства в
непосредственные работы и четкое понимание в необходимой отчетности.

Метод контрольных точек
позволяет:

·                  
планировать в категории «результатов»;

·                  
не испытывать иллюзий «поднажмем-успеем»;

·                  
разделить контроль на несколько уровней и
минимизировать лишнее вмешательство в руководство
работами.

4.2.3.                     
Какие шаги должно сделать Руководство для применения метода?

 ШАГ 1. Определить конкретные
поставко-ориентированные результаты (далее – Продукты проекта), которые должны
быть сформированы или произведены проектом и требуемые сроки их поставки. При этом срок поставки
действительно должен быть важен и обоснован.

Продукты – конечные конкретные измеримые результаты проекта, полученные в ходе выполнения работ и передаваемые заказчику. 

ШАГ 2. Согласовать срок с исполнителями, определить их ответственность за подготовку результатов
именно к этому сроку. Не
должно быть двоякого понимания срока или ответственности: конкретная дата, один ответственный, один измеримый результат.

ШАГ 3.   Определить   того,    кто   может   подтвердить,    что результат     получен,     измерен,     его     качество            соответствует
заявленному, и его можно применить для достижения ваших
целей или для целей проекта (Приемщиков).

ШАГ 4. Определить того, кто
независимо может контролировать выполнения контрольных точек и правила контроля.

Такой же подход может распространяться и на
Руководителя проекта, и на руководителей отдельных блоков
работ. На основании понимания Продуктов проекта и требуемых сроков
их поставки Руководитель проекта определяет требуемые промежуточные результаты (подпродукты), а также
разрабатывает видение требуемых сроков их получения. Определяются
исполнители и приемщики результатов. Таким образом, продуктовая декомпозиция может спуститься до уровня небольших групп и охватить все промежуточные результаты, которые требуют контроля. Общий вид
декомпозиции продуктов проекта представлен на рисунке 4.

 

Рис. 4. Декомпозиция продуктов
проекта

 4.2.4.            
Что такое контрольная точка?

 Контрольная точка (КТ) — это конкретный проверяемый результат
проекта, который должен появиться в установленный срок.

КТ фиксирует:

·                  
срок – когда должен быть получен результат;

·                  
ответственного – кто ответственен за его получение;

·                  
приемщика – кто подтвердит, что результат
соответствует требованиям к нему, и его можно применить для целей проекта.

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

·                  
прошедшее время;

·                  
совершенный вид;

·                  
страдательный     залог    (отвечать     на вопрос                    «Что сделано?»).

Например, не «Тестирование продукта», а
«Тестирование
продукта завершено». Ведь тогда стремиться нужно будет не к процессу «Тестирование продукта», а к завершению тестирования.

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

Примеры контрольных точек:

 

	Результат	Срок	Ответственны й	Приемщик
1	Заключен контракт          с поставщиком ….	01.10.2017	Иванов А.Ю.	Воскресенская С.М.
2	Поставлено оборудование для монтажа	09.08.2017	Галикбаров Р.С.	Шубин П.Л.
3	Запущена пилотная линия производства …	10.02.2018	Сафин М.Б.	Верховой В.В.

  

 4.2.5.            
Какими бывают контрольные точки?

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

Уровень 0. Вехи

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

Контроль таких результатов выполняет сотрудник
высокого уровня (Генеральный директор, заместитель Генерального директора) или специальное подразделение (Проектный офис). При
достижении вехи для руководства компании делается демонстрация результата и на
ее основе выносится вопрос о продолжении или остановке проекта.

Уровень 1. Критические

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

Как и для вех, контроль получения этих результатов
выполняется на высоком уровне. Отклонение сроков достижения таких
результатов рассматривается Первым лицом или специальным органом – Проектным комитетом. А при достижении
результатов Руководитель проекта обязан привлечь Заказчика к приемке или
представить ему полученные результаты.

Уровень 2. Ключевые

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

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

Уровень 3. Оперативные

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

Могут быть и более низкие уровни – все
зависит от масштаба проекта, размера команды, числа
результатов, которые можно и нужно контролировать.

Общее представление планирования контрольных точек
представлено на рисунке 5.

Рис. 5. Планирование по контрольным
точкам

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

На каждом уровне контрольные точки должны быть
формально утверждены.

Утверждение предполагает:

·                  
Документ несет в себе силу, которую принимает и
руководитель, и исполнитель.

·                  
Все    заинтересованные    стороны    имеют доступ                                     к
утвержденному документу.

·                  
Пересмотр контрольных точек выполняет тот же орган, который их утвердил.

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

4.2.6.            
Часто задаваемые вопросы

 

	Вопрос	Ответ
1	Кто                          должен сформулировать                                  КТ высокого уровня?	Контрольные точки 0 и 1 уровня ответственен сформулировать Заказчик проекта. Если у Заказчика нет требований к срокам кроме финального срока передачи результата, значит Руководитель проекта ответственен за определение КТ своего уровня и контроль проекта будет осуществляться только на основе Базового плана.
2	Могут ли сроки КТ быть жестко спущены сверху?                                Как производится                                  их планирование?	Для КТ высокого уровня так и бывает в большинстве случаев. Есть заранее определенные         условия                                   получения результатов или, как минимум, срок завершения проекта. При подписании Устава Руководитель проекта дает свое согласование этих сроков. Таким образом, КТ высокого уровня планируются «на бумаге», без использования ИСУП.
3	А что делать РП, если топ просит сделать в два раза быстрее? Как обосновывать свою позицию?	Руководитель проекта может обосновать отказ от исполнения срока на основании архива проектов (если он есть) или построить Базовый план с обоснованными сроками,          из          которого       логично просматриваются                                                 промежуточные
		результаты, которые требуется получить в
		проекте.   Также  можно  поднять                  вопросы
		качества и зафиксировать уровень качества
		в Уставе, если ради сокращения срока он
		сильно снижен.
4	Как       Руководителю проекта             согласовать	В       случае       отказа          функциональных руководителей           выполнять        сроки
	«навязанный» сверху план    по    срокам   с	контрольных  точек  более  низких уровней выполняется     эскалация     на                            Куратора
	функциональными подразделениями? Ему это делать в ИСУП или на бумаге?	проекта, ищутся альтернативы (в том числе, со снижением качества), или производится запрос на корректировку сроков КТ более высокого уровня. Разработка планов после подписания Устава производится только в ИСУП.
5	Сколько  уровней                 КТ должно быть?	Количество уровней КТ зависит и от зрелости компании, и от масштаба проекта. На первых шагах применения метода в компании мы рекомендуем использовать не более 2 уровней КТ: КТ в Уставе (вехи и критические результаты) и Базовом плане. Если компания зрелая и выстроила культуру управления по контрольным точкам, то последний уровень КТ устанавливается для рабочей группы не более 5 человек, и срок получения промежуточных результатов не должен превышать 2 недели.

  

Базовый план – согласованный с заинтересованными сторонами
и утвержденный к реализации перечень результатов со сроками их приемки.

4.2.7.             
Кейс крупного
банка

 Председатель
Правления поставил задачу «Создать первый в мире мобильный банк на технологии блокчейн».

Блокчейн – это общее понятие, которое не основано именно на управлении проектами. В данном случае, это пример названия проекта.

Для    контроля   исполнения   проекта   были разработаны следующие контрольные результаты:

 

 Через месяц Руководству были представлены итоги
конкурса по выбору
поставщиков и заключен контракт на работы. Поскольку согласования условия
контракта были затянуты, контрольная точка по согласованию дизайна не была выполнена в срок, что
отразилось
на премировании участников проекта. Зато следующий результат – «Запущены в
пилотном режиме 5 страниц нового сайта» – был представлен ранее
срока и получил
высокую оценку.

 4.3.                     
Регулярная отчетность как         основной инструмент управления

4.3.1.              
А нужна ли отчетность?

 Применение метода контрольных точек не означает, что
от результата к результату проект является черным ящиком. Отсутствие
отчетности по проекту несет в себе всем известные риски:

·                  
нет понимания статуса – текущего положения проекта
относительно его планов;

·                  
нет понимания движения по проекту, важно своевременно
информировать заинтересованные стороны о достижениях, даже небольших;

·                  
нет понимания возникающих проблем и рисков.

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

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

Какие отчеты нужны?

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

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

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

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

 4.3.2.            
Отчеты для Руководства

 Для проектирования отчетов Руководству важно соблюсти
меру – отчетов не должно быть много и каждый отчет не должен быть
слишком объемным.

Основными отчетами для
Руководства являются:

·                  
Отчет о статусе проекта;

·                  
Диаграммы контрольных точек;

·                  
Прогнозы выполнения контрольных точек;

·                  
Отчет по контролю бюджета портфеля.

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

Основная информация, требуемая
в этом отчете:

• Краткая    информация    о    проекте    –                   Заказчик, Руководитель проекта, сроки
  выполнения, бюджет;

• Перечень   утвержденных    контрольных   точек и зафиксированные отклонения;

• Существующие   риски    и    прогнозы                   отклонения контрольных точек;

• Последние решения по проекту;

• Важные данные
  по проекту по запросу Руководства. 

Пример такого отчета
представлен на рисунке 6.

Рис. 6. Отчет о статусе проекта

2.       
Диаграмма
контрольных точек – карта проектов с отметкой плановых результатов и статуса их
получения.
В данном случае, на основании метода контрольных точек
Руководство видит только два состояния результата – получен/не получен.

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

Сводная диаграмма представлена
на рисунке 7.

Рис. 7. Сводная диаграмма КТ

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

Пример диаграммы одного проекта
на рисунке 8.

Рис. 8. Диаграмма КТ одного проекта 

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

Пример отчета представлен на
рисунке 9.

Рис. 9. Прогнозы и риски выполнения
КТ

4.        
Отчет для
контроля превышения бюджета – для Руководства важно регулярно (например, раз в квартал) делать
представление по степени расходования средств
проектов.

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

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

Пример такого отчета
представлен на рисунке 10.

Рис. 10. Отклонение
расходования бюджета по программе проектов 

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

Какие дополнительные отчеты
нужны Руководителю:

·                  
Отчет о статусе задач;

·                  
Отчет по выполнению задач;

·                  
Бюджет доходов и расходов по статьям.

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

Пример задач с заполненным
статусом представлен на рисунке 11.

Рис. 11. Иерархическая
структура работ и статусы задач

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

Если Руководитель проекта работает в непосредственной
близости от команды, такие отчеты излишни. Но если команда распределена, есть
удаленные сотрудники, или у Руководителя проекта на контроле
два,
три, пять проектов – такие отчеты необходимы.

Текстовый отчет по одной задаче, срок исполнения которой не
превышает двух недель, как правило, краткий и
состоит из двух блоков:

·                  
«Что сделано?» – кто, когда,
и какой результат получил.

·                  
«Что предстоит сделать?» – кто, к какому сроку, и что
конкретно должен сделать.

Анализировать отчет становится простой задачей. Исчезает
необходимость просмотра переписки, анализа переданных документов, дополнительного запроса
сроков и т.д. А из поля «Что предстоит?» автоматически
могут быть сформированы задачи проекта    на    следующий   отчетный    период   для                  контроля               их
выполнения.

Пример отчета представлен на
рисунке 12.

Рис. 12. Отчет по выполнению задач 

 3.   
Бюджет доходов и расходов по статьям – классический отчет для управления финансами. Этот отчет используют как
финансисты предприятий, так и Руководители проекта. Данный отчет является ежедневным инструментом контроля поступления и расходования средств и позволяет
руководителю проекта своевременно устранить риски превышения бюджета. Основная
сложность использования такого отчета – обеспечить связь между системой
учета транзакций (бухгалтерией) и системой управления проектом (ИСУП).

Пример отчета представлен на
рисунке 13.

Рис. 13. Бюджет доходов и расходов по
статьям 

4.3.4.                    
Как организовать эффективный процесс сбора достоверной отчетности?

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

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

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

Пример такой формы представлен
на рисунке 14.

Рис. 14. Форма сбора
отчетности по выполнению задач

Руководитель проекта, со своей стороны, имеет монитор
для отслеживания нарушений и может решить единичные вопросы лично.

 4.3.5.            
Часто задаваемые вопросы

  

	Вопрос	Ответ
1	Как               заставить Руководство смотреть отчетность               по проектам?	Отчетность по проектам для Руководства, если Руководство не является прямым Заказчиком                                  проекта,                                  должна представляться на специальном комитете, в обязанности которого входит контроль за выполнением проектов. Ответственность за подготовку такой отчетности лежит на Проектном офисе.
2	Должно                    ли Руководство работать в      информационной системе?	Такой     обязанности     нет      –                иногда руководство готово                  использовать современные технологии, а иногда нет. Но необходимо,  чтобы    любая                         отчетность, сформированная для   руководства,                                была получена на основании ИСУП.
3	Что      делать,                если исполнители            задач отказываются заполнять   отчеты   в системе,                   но присылают      отчеты «по     старинке»    на почту?	Проектный офис с помощью ИСУП должен регулярно                        формировать      отчеты                        о дисциплине         по                               предоставлению отчетности.      Нарушения                           дисциплины должны приравниваться к неисполнению должностных обязанностей.
4	Можно  ли               избавить исполнителей               от заполнения   отчетов, если      Руководитель проекта все время с ними контактирует и не нуждается в этих отчетах?	Конечно, но в этом случае Проектному офису нужно организовать аналогичный сбор краткой информации по исполнению проектов. В этом случае на еженедельной основе    Руководители   проектов                будут фиксировать  полученные  результаты                         и планы на будущий период. Такой отчет будет полезен как Заказчикам проектов, так    и    самим    руководителям,          чтобы структурировать свою работу.
5	Сколько         времени должно        занимать предоставление отчетности                        у Руководителя проекта?	Если говорить о рекомендуемом минимуме, который мы описали, то на каждый проект у руководителя проекта будет уходить 10 минут в неделю. В отчет войдет определение прогнозов и рисков по контрольным точкам верхнего уровня и краткое описание проделанной работы и планов на следующий период.

 4.4.      
Эффективные
коммуникации в короткие
сроки

4.4.1.              
«Посидели, поговорили, разошлись…»

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

 4.4.2.            
Коммуникации с
Заказчиком

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

ШАГ 1. Планирование коммуникаций.

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

·                  
по каким дням недели доступен Заказчик;

·                  
в какое время и сколько по продолжительности будет
встреча;

·                  
очно или удаленно он сможет участвовать;

·                  
каким образом Руководитель проекта будет передавать
Заказчику повестку.

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

Шаг 2. Проведение
коммуникаций на основе данных ИСУП.

Регулярные коммуникации с Заказчиком должны
основываться на отчетности ИСУП, например, диаграмме контрольных точек. Тогда
перед глазами всегда будут плановые результаты
и их сроки, полученные результаты или их отклонения. Сама
повестка встречи для Заказчика может
основываться на:

·                  
информировании о статусе получения результатов (какие получены, какие в стадии
приемки, что предстоит получить в ближайшее время);

·                  
информировании о текущих рисках и проблемах, фиксации
следующих шагов для разрешения проблем (определения требуемых экспертов,
назначение задач для   анализа, согласование времени для         проведения
совещаний и решения проблем);

·                  
информирование о принятых решениях;

·                  
сбор   предложений и   пожеланий или согласование времени для проведения таких совещаний.

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

ШАГ 3. Фиксация протоколов.

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

 4.4.3.            
Коммуникации
Руководителя проекта с командой

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

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

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

Типовая повестка совещания с
командой проекта:

·                  
статус проекта (какие контрольные точки выполнены, какие в
процессе приемки,
какая следующая);

·                  
риски и проблемы проекта – Руководитель
проекта озвучивает результаты отчета или опрашивает участников о том, какие риски
им известны;

·                  
принятые решения – Руководитель проекта информирует о
том, какие
решения приняты относительно проекта руководством, какие новые требования
предоставлены Заказчиком, и сразу согласовывает участников, время и продолжительность совещания для их обсуждения;

·                  
благодарности и поздравления.

 4.4.4.               
Как проводить
совещания с командой проекта за 15 минут?

 Для организации регулярных коротких коммуникаций можно дать несколько эффективных рекомендаций.

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

Целями могут быть:

·                  
единое понимание командой проекта статуса, проблем
и рисков;

·                  
единое понимание следующих шагов;

·                  
доведение особо важной/срочной информации;

·                  
согласование        состава        участников, даты                        и продолжительности требуемых совещаний;

·                  
укрепление команды.

·                  
Целью не должно являться:

·                  
выработка решений, влияющих на цели, содержание и
сроки проекта или контрольных точек;

·                  
наказания за просрочку или ошибки;

·                  
обсуждение проблем и поиск причин
просрочки сроков.

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

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

 4.4.5.            
Часто задаваемые вопросы

 

	Вопрос	Ответ
1	Как    организовывать короткие коммуникации,          если команда                         проекта большая – 30, 50, 100 человек?	В больших проектах участников разделяют на небольшие группы по 5-7 человек, назначают       руководителя       группы     и организовывают       мини-совещания      по группам. Руководитель проекта проводит регулярные совещания только с исполнителями, которые подчиняются непосредственно ему или с руководителями групп.
2	Как можно сократить время                                для согласования протоколов совещаний                                     с Заказчиками?	Нужно подводить итоги совещания по окончанию, проговаривая принятые решения и устанавливать короткие сроки для согласования – пока принятые решения еще актуальны.
3	Могут ли в проекте быть только мини- совещания?	Нет, в проекте должны быть различные форматы совещаний, в том числе обсуждение проблем и поиск решений. С Заказчиком совещания должны быть более продолжительными, чтобы Заказчик мог задать свои вопросы, обсудить интересующие его темы. Но с точки зрения регулярных совещаний с командой – как плановые могут быть только короткие.
4	Как                   выдержать короткое совещание в 15 минут, если в проекте обнаружена проблема, и все участники готовы ее обсудить?	Если все участники мини-совещания являются участниками совещания по решению проблемы, для решения проблемы достаточно информации, и у всех участников есть время для обсуждения, можно завершить повестку мини-совещания и начать совещание по решению проблемы.
5	Можно ли отменить мини-совещание, если в проекте аврал?	Как правило, в период аврала потребность в коммуникациях – определения требуемых к выполнению задач, обмена статусами, единого понимания проблем значительно выше, чем в период стабильной работы. В таких случаях мини-совещания проводят ежедневно или дважды в день, чтобы лучше скоординировать работу группы.

4.5.             
Принятие решений на высоком уровне и оценка деятельности

 4.5.1.               
Должно ли
Руководство включаться в управление проектами?

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

Если говорить о выполнении проектов в непроектных
компаниях, то Руководство не всегда хочет и может из-за
недостатка времени включаться в управление такими проектами. Это
связано с несколькими причинами:

·                  
основной доход компании не связан с выполнением этих проектов;

·                  
продукты таких проектов требуют специализированных
компетенции для их оценки;

·                  
большинство проектов поставляют результаты для
совершенствования операционного цикла и достигают своих целей спустя
продолжительное время после завершения проекта;

·                  
проекты слишком различны по структуре работ и
получаемым результатам, поэтому управление требует больших усилий.

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

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

 4.5.2.                     
Проектный комитет как важнейший элемент регулярного менеджмента

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

Основными задачами комитета, как
правило, являются:

·                  
утверждение стандартов, методик
и правил управления проектами и изменений к ним;

·                  
утверждение целей проектов в соответствии со
стратегией организации;

·                  
утверждение результатов проектов (Контрольных точек
высокого уровня), достаточных для достижения проектных целей;

·                  
разрешение конфликтов на уровне РП, Куратора и
Заказчика по содержанию, срокам и бюджету проектов;

·                  
утверждение требуемых изменений результатов проектов;

·                  
разрешение конфликтов по использованию трудовых и материальных ресурсов в соответствии с
приоритетами проектных целей;

·                  
остановка или отмена проектов в связи с изменением
стратегического видения.

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

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

 4.5.3.            
Как проводить Проектный комитет

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

–       
это своеобразная демонстрация требований Руководства к качеству управления.

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

Основные правила проведения
комитета:

·                  
Одно из первых правил проведения – регулярность.
Именно             через регулярные        совещания    по портфелю проектов, которые проходят в один и тот же определенный день и в одно и
то же время, Топ- менеджмент может ясно и четко донести до всех сотрудников
важность Проектного управления и свою приверженность ему. Зафиксируйте день недели, время и помещение для регулярного совещания.

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

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

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

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

·                  
Важно фиксировать повестку комитета. Для отражения статуса проектов может использоваться онлайн отчет из ИСУП, который заранее обозначит членам
комитета текущие проблемы и риски, которые зафиксировала система (см. рис. 9).

·                  
Все решения комитета должны быть не просто
зафиксированы в протоколе, а найти свое отражение в работах проектов. Проектный
офис должен контролировать проникновение решений комитета на тактический
уровень управления.

Помимо общих правил управления совещаниями, есть
рекомендации, характерные именно для проведения Проектного комитета. Рассмотрим
их:

·                  
Главная задача Руководства – грамотное принятие решений, а не поиск нужной
информации. Не усложняйте требования к
материалам. Определите простой набор индикаторов для вопросов, например, «зеленый»-«желтый»-«красный», который сразу обозначит зоны для информирования,
внимания и углубленного рассмотрения.

·                  
Начинайте    с     «зеленых»   проектов     и отпускайте

Руководителей проектов после доклада. Так вы сэкономите их время.

·                  
Проблемные проекты рассматривайте в конце. Не
пытайтесь на совещании решить проблему если она серьезна, лучше
назначьте отдельное совещание. Задача комитета – зафиксировать факт проблемы, оценить ее
серьезность и определить, кто нужен
для ее решения.

·                  
Характер деятельности Топ-менеджмента и Руководителей
проектов может мешать стабильному присутствию на совещании. Правила организации
должны максимально обеспечивать кворум. По возможности, используйте системы
web-конференций для дистанционно удаленных участников.

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

·                  
Собирайте оценки по качеству совещания от его
участников, особенно первое
время. Так вы сделаете его максимально полезным на основе
полученной обратной связи.

4.5.4.            
Часто задаваемые вопросы
 

	Вопрос	Ответ
1	Как взаимодействуют Проектный офис и Проектный комитет?	Проектный офис подчиняется Проектному комитету и является его «правой рукой». Даже если у комитета есть собственный секретарь, Проектный офис отвечает за корректность подготовки            материалов                                     заседания, своевременную рассылку требуемой отчетности, а также построение онлайн отчетов в ИСУП для демонстрации их непосредственно на комитете.
2	Кто должен быть на ПК: Топ-менеджмент или                                  Заказчики проектов? А если они не совпадают – у нас много заказчиков, их всех    звать     на              этот комитет? Или если у нас    Топ-менеджмент (Генеральный директор)   не             всегда является             Заказчиком проектов, нужно ли его приглашать на ПК?	Обязательными участниками комитета для рассмотрения статуса проектов являются утвержденные члены комитета и Руководители проектов. Если на комитете рассматривается                                              отдельный                                              запрос, требующий высокоуровневого решения, тогда на комитет приглашается Заказчик проекта. Генеральный директор участвует в комитете, если он является Председателем или Заказчиком проекта, по которому сформирован запрос для принятия решения.
3	Как        часто                нужно проводить ПК?	Частота   проведения   Проектного                    комитета должна                         соответствовать                    потребности в скорости  решения тех  вопросов, которые на нем рассматриваются. Если рассматриваются еженедельные      вопросы      управления,                              а комитет     проходит     редко     –    это                       будет тормозить       управление.     Если                             комитет проходит      часто,     а      вопросы      для                          его рассмотрения накапливаются медленно – это снизит мотивацию Руководства. Регулярно отслеживайте статус проектов, эти вопросы можно рассматривать ежемесячно, ежеквартально или раз в две недели, в зависимости от темпов ваших проектов.
4	Сколько                               времени должен                               длиться комитет?	Стандартное время для проведения комитета –     от получаса до полутора часов. Не стоит делать более длительные заседания. Следуйте следующим правилам: ·        Останавливайте обсуждения, которые не служат целям комитета. ·        Определите формат для рассмотрения вопросов. ·        Определите регламентное время рассмотрения «зеленых», «желтых» и «красный» проектов. ·        Если вы не укладываетесь в определенное время, то должно назначаться дополнительное заседание.
5	Что делать, если проект                                требует решения Руководства, а комитет будет только через две недели? Останавливать работы?	1.          Определите уровень рисков, которые требуют внепланового заседания: запрос клиента или внешнего Заказчика, требования государственного регулятора, выгода или угроза с лимитом (например, от решения зависит выгода в 1 млн руб.). Тогда секретарь сможет организовать совещание для экстренного решения. 2.    Сформируйте перечень вопросов, которые можно решать заочно. Тогда вы сможете экономить время очного совещания и ускорить ответ Руководителям проектов по текущим и наиболее частым вопросам.

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

4.6.      
Закрытие проекта и анализ результатов

 4.6.1.              
Как правильно выполнить закрытие проекта

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

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

·                  
что   и   в   каком   количестве   является результатами
проекта;

·                  
решения по   урегулированию вопросов (как           должно использоваться,
какие ограничения эксплуатации и т.п.);

·                  
решение о вводе в промышленную эксплуатацию;

·                  
приемочная комиссия;

·                  
итоговые параметры проекта и их отклонения от уставных
значений (продолжительность, бюджет, использованные ресурсы);

·                  
оценка     удовлетворенности     Заказчика: качеством, результатом, управлением проекта;

·                  
оценка качества управления проектом от Проектного
офиса.

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

На основании данных отчета может быть рассчитана
проектная премия. Также данные по отклонениям проекта должны
попадать в отчетность Проектного офиса и являться одним из показателей его деятельности.

Например, один из показателей эффективности
Проектного офиса может быть сформулирован так: «проекты по развитию производственных
линий должны выполняться с отклонением срока завершения не более 7%».

 4.6.2.            
Какие последние действия Руководителя проекта?

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

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

4.6.3.            
Часто задаваемые вопросы

	Вопрос	Ответ
1	Как             фиксировать отклонение                     срока проекта, если в ходе проекта       срок       был перенесен                     по объективным причинам,                не зависящим                                           от Руководителя проекта?	В      этом      случае       все       равно         нужно зафиксировать    отклонение         проекта         как факт. Применение мотивации для команды проекта           или           учет                            показателя эффективности          Проектного                                           офиса возможно с оговоркой на обстоятельства переноса   срока,   которые    должны                       быть также зафиксированы в итоговом отчете.
2	В каком формате делается итоговый отчет – текст, таблица или презентация?	Для Заказчика лучше делать презентацию результатов, особенно если Заказчик – лицо высокого   ранга.  Но   остальные итоговые данные   должны   быть   зафиксированы в текстовом    или    табличном   варианте                         по единому шаблону.
3	Что       делать,      если Заказчик отказывается принимать результаты?	Руководитель      проекта      должен                                    либо зафиксировать                                    формальный    запрос                                    на изменение,  либо,   если    имеются                            факты расхождения     итогового      результата      с требованиями           Устава,                             выполнить доработку. В остальных случаях требуется проводить    переговоры    с                          привлечением Кураторов проекта.
4	Нужно       ли        делать анализ       результатов, если проект типовой?	Для типовых проектов анализ результатов наиболее важен, так как они выполняются чаще других. Но форма анализа может быть упрощена     –    например,                     сформирована стандартная       анкета       с                                 возможными вопросами.
5	Имеет        ли                      смысл анализировать исполнение     проекта, если                        проект уникальный и никогда более          не          будет повторен?	Анализ проекта должен выполняться в любом случае. Знания об уникальном проекте или его продукте должны быть зафиксированы, чтобы можно было и повторить проект, и использовать эти знания в других проектах.

Вместо послесловия

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

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

Источник http://www.advanta-group.ru/

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

ВСЁ, ЧТО ДЕЛАЕТСЯ КОМПАНИЕЙ ДЛЯ ЕЁ КЛИЕНТОВ, ЕСТЬ ПРОЦЕССЫ.

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

Управлять процессами – это значит:

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

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

Чтобы заложить основу системы управления процессами в вашей компании, вам нужно осуществить проект длительностью от 2 до 4 месяцев.

Настоящее методическое руководство есть пошаговое описание проекта внедрения основных элементов процессного подхода.

Результатами этого проекта станут:

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

Следуйте нашей “дорожной карте”, и вы построите структурированные, управляемые бизнес-процессы.

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

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

Далее мы идентифицируем процессы, разрабатывая спецификации каждого процесса, которые содержат все основные параметры процессов.

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

После того как все основные процессы компании определены, можно переходить к разработке должностных обязанностей сотрудников, определению показателей деятельности (KPI), разработке регламентов.

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

Методическое руководство основано на материалах мастер-проекта “Создание системы управления процессами”

ЧТО ТАКОЕ ПРОЦЕССЫ?

Начнем с определения.

Процесс – это устойчивая, целенаправленная, последовательность действий, преобразующих ресурсы (входы) в некоторые продукты (выходы), представляющие ценность для потребителя.

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

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

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

Определим основные понятия, связанные с процессами.

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

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

Для уточнения сущности процессного подхода обсудим аспекты управления, выходящие за его пределы.

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

На самом деле это не только невозможно, но и вредно.

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

Известный исследователь организационных систем Генри Минцберг называет процессные методы управления «стандартизацией деятельности».

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

1. Прямая координация. Начальник отдает приказы подчиненным и контролирует их исполнение. Так функционируют подразделения вооруженных сил.
2. Взаимное согласование. Решения вырабатываются в ходе взаимодействия равноправных членов команды. Это принцип функционирования инновационных, творческих коллективов.
3. Стандартизация целей. Сотруднику ставятся цели; средства их достижения он выбирает самостоятельно. Так действуют дивизиональные подразделения компаний, руководители которых обладают высокой степенью самостоятельности.
4. Стандартизация квалификации. Методы и приемы работы отрабатываются в ходе обучения специалиста. В своей трудовой деятельности, отличающейся высокой сложностью, сотрудник действует самостоятельно. Так работают хирурги, адвокаты, преподаватели, консультанты.
5. Корпоративная идеология. Всех сотрудников компании объединяют общие ценности, понимание единых целей и идеологических установок. Поэтому каждый сотрудник в своей деятельности руководствуется своим пониманием того, как «правильно» поступать в той или иной ситуации. На таких принципах построена деятельность миссионеров религиозных организаций и разведчиков, находящихся на вражеской территории.

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

ПРОЦЕССНЫЙ ПОДХОД К УПРАВЛЕНИЮ

Что такое процессный подход к управлению, в чем его особенность?

Это понятие, также как и понятие «процесс», определено в системе менеджмента качества. Процессный подход состоит в том, чтобы

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

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

“ДОРОЖНАЯ КАРТА” СОЗДАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЦЕССАМИ

Задачу, которую мы здесь рассматриваем, можно сформулировать по-разному.

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

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

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

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

Огромное количество неудачных проектов в области «организационного строительства» объясняется именно тем, что работа велась без «архитектурного проекта» с нарушением СНИП (строительных норм и правил).

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

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

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

Следующий шаг – разработка организационной концепции. Это своего рода, «архитектурный проект» нашей организационной системы. Он определяет структуру и взаимосвязь процессов, а также основные центры ответственности и их функции по обслуживанию процессов.

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

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

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

Каждый этап этой “дорожной карты” мы подробно рассмотрим далее.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

ИДЕНТИФИКАЦИЯ СТРАТЕГИИ

Мы начинаем путь к построению системы управления бизнес-процессами с идентификации маркетинговой стратегии компании.

Казалось бы, при чем здесь стратегия, когда мы говорим о процессах? Давайте разберемся.

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

• кого именно мы обслуживаем, кто наши клиенты?
• в чем заключаются потребности клиентов?
• в каких компонентах наши продукты и услуги должны превосходить то, что делают конкуренты?

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

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

Говоря об идентификации маркетинговой стратегии, мы предполагаем, что ее не придется разрабатывать “с нуля”, что руководство компании имеет определенные представления о долгосрочных целях и направлениях развития бизнеса. Эти представления необходимо произнести вслух, обсудить с управленческой командой и зафиксировать на бумаге. В этом и состоит процесс идентификации стратегии.

Обычно маркетинговая стратегия представляет собой документ, объемом 5-10 страниц, определяющий целевые сегменты рынка, ключевые конкурентные отличия, методы привлечения клиентов, принципы организации продаж и обслуживания потребителей.

В материалах мастер-проекта “Создание системы управления процессами” дается подробное описание стратегии маркетинга, разработанной в ходе одного из проектов iTeam.

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

ОРГАНИЗАЦИОННАЯ КОНЦЕПЦИЯ

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

Организационная концепция включает пять элементов.

• Состав основных бизнес-процессов верхнего уровня.
• Краткое описание процессов верхнего уровня, характеризующее их содержание, входы, выходы и исполнителей.
• Карта процессов, показывающая второй и, возможно, третий уровень бизнес-процессов.
• Схема центров ответственности за выполнение бизнес-процессов, как прототип организационной структуры компании.
• Краткое описание функций, выполняемых центрами ответственности.

Определив процессы верхнего уровня, составляем их концептуальное описание. Это второй элемент организационной концепции. Структура описания состоит из следующих элементов.

1. Клиенты процесса – те, кто получает выгоду от процесса и использует его результаты. Процесс создается и совершенствуется в интересах клиентов, которых он обслуживает. Именно ориентация на клиента является главной ценностью процессного подхода.
2. Цели процесса – изменения, значимые для клиентов, которые осуществляются в ходе выполнения процесса. Определение целей процесса должно отвечать на вопрос: «Что изменяет процесс?». Например, цель процесса закупок в торговой компании состоит в обеспечении определенного уровня наличия товаров на складе. Наличие товаров – это состояние запасов, критически важное для клиента процесса – подразделения продаж.
3. Результаты процесса– создаваемые на выходе процесса продукты или услуги, которыми пользуются клиенты процесса. Например, для торговой компании результатом процесса закупок является поступление товаров на склад. Необходимо различать цели и результаты процесса. Цели – это то, что изменяется, а результаты – это то, что производится, создается.
4. Ресурсы процесса– деньги, информация, материальные ресурсы, поступающие на вход процесса, используемые для производства результатов (продуктов и услуг).
5. Поставщики процесса– лица и организации, предоставляющие ресурсы, необходимые процессу.
6. Исполнители процесса– названия ролей (должностных позиций) исполнителей процесса, участвующих в производстве результатов. Здесь нужно использовать не имена сотрудников, а позиции в организационной структуре. Если для какого-либо процесса нет соответствующего исполнителя в структуре компании, то следует использовать условное название роли, которое в дальнейшем, после уточнения организационной структуры, может быть уточнено.
7. Владелец процесса– название должности руководителя, ответственного за достижение целей процесса, имеющего полномочия изменять процесс.
8. Показатели процесса– критерии, используемые для измерения результативности, эффективности, качества и производительности процесса.
9. Содержание процесса– краткое описание действий, осуществляемых в ходе процесса в объеме нескольких предложений.
10. Структура процесса– перечень процессов второго уровня, из которых состоит описываемый процесс.

После завершения работы над организационной концепцией у нас имеется все необходимое для построения карты основных процессов компании, пример которой приведен на схеме. Она отражает состав процессов верхнего уровня (показаны зеленым цветом) и составляющие их процессы второго уровня (показаны желтым цветом).

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

В материалах мастер-проекта “Создание системы управления процессами” содержится подробные примеры описания процессов верхнего уровня и центров ответственности.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

ОРГАНИЗАЦИОННАЯ СТРУКТУРА

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

Главное назначение организационной структуры – обслуживание бизнес-процессов. Именно для этого она существует.

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

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

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

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

Как описать организационную структуру компании?

Описание организационной структуры должно включать следующие элементы:

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

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

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

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

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

ИДЕНТИФИКАЦИЯ ПРОЦЕССОВ

Следующий пункт нашей “дорожной карты” – идентификация процессов.

Идентификацией процесса мы называем составление спецификации в форме таблицы, в которой указаны все основные характеристики процесса. Рассмотрим составление такой спецификации на примере процесса приемки автомобиля в автосервисе.

1. Название процесса

Процесс называется “Прием автомобиля от клиента”.

1. Краткое описание процесса

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

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

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

1. Клиент процесса

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

В данном случае клиентом процесса, очевидно, является автовладелец, обратившийся в автосервис. Именно он обслуживается в этом процессе.

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

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

1. Цели процесса

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

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

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

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

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

Теперь обсудим интересы компании в этом процессе. Компании нужны:

• Лояльный клиент, который удовлетворен сервисом настолько, что будет не только постоянным посетителем, но и станет рекомендовать компанию своим знакомым,
• Доходы от продажи услуг клиенту; желательно, чтобы клиент, в ходе обсуждения его проблем с мастером-приемщиком приобрел дополнительные услуги, представляющие для него ценность,

Таким образом, мы определили цели всех заинтересованных сторон в этом процессе.

1. Результат процесса

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

Для компании немалое имеет значение такой результат, как сумма заказа.

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

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

1. Показатели процесса

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

• Удовлетворенность клиента обслуживанием. Способы измерения: (1) прямой опрос клиентов по телефону – сплошной или выборочный, (2) число жалоб на работу мастера-приемщика, (3) число благодарностей за работу мастера-приемщика. Может использоваться любой из этих показателей или их совокупность.
• Удовлетворенность мастера производственного участка качеством наряд-заказа. Способ измерения: оценка наряд-заказа, подготовленного мастером-приемщиком по критериям отсутствия ошибок, наличию деталей, срокам выполнения.
• Средний чек.

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

1. Ресурсы процесса

Есть два вида ресурсов – расходуемые в ходе выполнения процесса и возобновляемые ресурсы. К первому типу относятся, например, материалы, используемые в производстве, или деньги. Ко второму – оборудование, программное обеспечение, разнообразные инструменты и т.п.

Одним из “входов” в рассматриваемый процесс является запись клиента на посещение автосервиса. Без этого процесс не может выполняться.

Для составления наряд-заказа необходима информация о наличии автозапчастей и материалов.

Для определения сроков выполнения работ нужна информация о загрузке производственного участка.

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

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

1. Поставщики процесса

• Запись клиентов на ремонт осуществляет диспетчер автосервиса в процессе приема заявок.
• Поставщиком информации о наличии запчастей является отдел снабжения; при этом информация о запасах содержится в автоматизированной системе.
• Согласование сроков ремонта проводится с мастером производственного участка.
• Обслуживание компьютерной техники и программного обеспечения обеспечивает ИТ-служба сети автосервиса.

1. Исполнители процесса

Исполнителем процесса является мастер-приемщик.

1. Владелец процесса

Владелец процесса – это должностное лицо, ответственное за достижение целей процесса, имеющее полномочия и ресурсы для проведения изменений, совершенствование процесса.

В рассматриваемом примере владельцем процесса является руководитель автосервиса.

***

Итак, мы идентифицировали процесс, определив все его ключевые параметры.

Что это нам дает? Когда мы проделаем эту работу со всеми основными процессами компании, мы создадим надежную основу для построения системы управления процессами.

1. Будут точно определены все основные процессы компании и связи между ними.
2. Поскольку в каждом процессе определены исполнители, нетрудно будет составить должностные обязанности для сотрудников, участвующих в ряде различных процессах.
3. Ясность целей и показателей процессов позволяет нам установить показатели деятельности (KPI) для сотрудников, являющихся исполнителями процессов.
4. Установление связи между процессами и исполнителями позволяет внести коррективы в организационную структуру компании в части разграничения функций, ответственности и полномочий должностных лиц и подразделений.

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

В материалах мастер-проекта “Создание системы управления процессами“  имеется шаблон спецификации бизнес-процесса.

ОПИСАНИЕ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ СОТРУДНИКОВ

Теперь, опираясь на результаты структурирования и идентификации процессов, мы перейдем к разработке должностных обязанностей сотрудников.

Исходными данными для этого служат спецификации процессов, которые содержат всю необходимую нам информацию:

• Исполнитель процесса,
• Краткое описание процесса,
• Цель процесса,
• Результаты процесса,
• Показатели процесса.

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

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

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

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

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

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

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

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

ОПРЕДЕЛЕНИЕ СОСТАВА КОМПЕТЕНЦИЙ СПЕЦИАЛИСТОВ

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

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

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

Нам будут нужны первая и вторая колонка этой таблицы. Вместо остальных колонок добавим три новые: “Знания”, “Навыки”, “Личные качества”. Таким образом, у нас есть список процессов, в которых участвует сотрудник, краткое описание этих процессов и три колонки, которые нужно заполнить, последовательно рассматривая каждый процесс.

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

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

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

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

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

Успешное выполнение функций в рассматриваемом процессе требует таких личных качеств, как организационные и аналитические способности, настойчивость, инициатива.

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

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

ОПРЕДЕЛЕНИЕ ПРОФИЛЯ ДОЛЖНОСТИ

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

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

Документ «Профиль должности» имеет следующую структуру:

• Общие знания,
• Предметные знания,
• Навыки,
• Личные качества,
• Ценности,
• Функциональные обязанности,
• Области ответственности.

Рассмотрим содержание каждого раздела.

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

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

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

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

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

Следующий раздел “Ценности”. Требования к ценностям сотрудников не выводятся из бизнес-процессов. Это категория высшего порядка – выше бизнес-процессов и стратегии, поскольку ценности руководят выбором целей и стратегии. Состав ценностей един для всей компании, но в крупных компаниях большие подразделения могут в чем-то отличаться по составу ценностей.

Определение ключевых ценностей и их утверждение в коллективе – задача лидера.

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

Раздел “Функциональные обязанности” формируется из описания функций исполнителя процессов. Эта информация переносится в профиль должности из перечня компетенций.

В разделе “Область ответственности” указываются ключевые показатели, за которые должен отвечать сотрудник. Для специалиста по развитию сети СТО такими показателями являются:

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

Интересно, что последняя позиция из бизнес-процессов не вытекает. Если мы посмотрим показатели бизнес-процессов нижнего уровня, там нет такого показателя – “лояльность клиентов”. Тогда откуда он взялся в описании областей ответственности? Он появился из стратегии, из понимания того, какой “храм” строит эта компания.

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

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

Этот пример показывает, что нельзя правильно определить цели процессов, не понимая стратегии, в которой эти процессы действуют.

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

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

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

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

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

***

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

• Разработка ключевых показателей деятельности (KPI),
• Внедрение системы вознаграждения на основе KPI,
• Разработка регламентов бизнес-процессов,
• Разработка инструкций для исполнителей процессов
• Рекомендации по управлению проектом внедрения процессного подхода.

***

Пошаговое практическое руководство по внедрению процессного подхода к управлению дает мастер-проект “Создание системы управления процессами” 

Он содержит подробное описание каждого этапа этого проекта, а также шаблоны документов, создаваемых в ходе проектирования бизнес-процессов.

Далее вы можете ознакомиться с подробным описанием нашего мастер-проекта.

ИНФОРМАЦИЯ О МАСТЕР-ПРОЕКТЕ “СОЗДАНИЕ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЦЕССАМИ”

В состав мастер-проекта входят:

• 14 мастер-классов
• 60 шаблонов документов
• индивидуальные консультации

Приобретая мастер-проект, вы получаете:

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

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

Результат мастер-проекта — работающая система управления процессами и обученные сотрудники, способные самостоятельно вести работу по совершенствованию процессов.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: Александр Кочнев

Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Managment Institute, квалификация Project Managment Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

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

Чем характеризуется проект внедрения КСУП

Внедрение проектного управления – особый вид организационных проектов с ИТ-составляющей. Результаты такого проекта можно разбить на 4 группы:

• построение организационной структуры;
• подготовка персонала;
• внедрение процессов (документов, методов; методические рекомендации по внедрению проектного управления);
• внедрение информационной системы управления проектами. 

 А типовой план и контрольные точки можно представить так:

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

• сопротивление сотрудников вводимым изменениям;
• несоблюдение (или неверное толкование) правил, отказ от использования документов;
• сбои в работе новой системы подотчетности;
• недостаток мотивации для работы по-новому;
• весь спектр проблем внедрения программного продукта.

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

Обзор проектной деятельности

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

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

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

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

На мой взгляд, подобных результатов можно ожидать на двух группах проектов:

1. группы небольших регулярных проектов;
2.  крупных проектов стратегического характера.

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

Обзор коротких регулярных проектов

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

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

Основные этапы такого процесса:

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

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

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

Обзор крупных проектов стратегического характера

Вторая группа проектов – это совсем другая история. Если вам удастся выявить и внедрить инструменты, которые наладят работу с экстра-важными проектами компании, то вас поддержат самые ценные заказчики КСУП – Первое лицо и топ-менеджмент. Именно поэтому обследование этой сферы так интересно.

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

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

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

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

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

Как внедрить информационную систему управления проектами, чтобы она «взлетела»?

А чего особенного именно в ИСУП?

Если вы приняли решение внедрить систему управления проектами – а особенно, если вы делаете это впервые, то наверняка задаетесь вопросом: как сделать все правильно, минимизировать ошибки, прийти именно к тому результату, который ожидаете?

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

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

С ИСУП все не так однозначно: эффекты от внедрения наступают далеко не сразу, видны не на всех уровнях управления, в умах пользователей возникают сомнения, а нужно ли это все, ведь работали как-то раньше, и неплохо работали.

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

К чему будем стремиться?

Если настройки и обучения мало, то когда в таком случае можно считать внедрение завершенным?

Критерии успешности вашего проекта могут быть сформулированы по-разному (кстати, обязательно их сформулируйте!), но есть одна, на мой взгляд, обязательная цель: все процессы управления проектами выполняются на регулярной основе и с использованием системы.

Это наша программа-минимум. Более сильный критерий – оптимально выстроенные процессы. А вот признаки, по которым можно определить достижение этой цели:

• настроенные процессы способствуют достижению целей компании;

• пользователи принимают систему и регулярно в ней работают;

• задействован необходимый и достаточный набор инструментов.

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

Что может пойти не так?

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

Нет опыта внедрения => нет уверенности в результате

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

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

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

Система не отвечает вашим ожиданиям

Допустим, вы предполагали, что система даст вам инструмент для оценки рисков методом Монте-Карло, но в какой-то момент узнаете, что в закупленном ПО такой инструмент отсутствует, а доработка либо невозможна, либо увеличивает бюджет проекта вдвое.

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

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

Появляются новые требования

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

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

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

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

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

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

Пользователи саботируют систему

Мы уже отметили выше, что вовлечь пользователей в ИСУП несколько сложнее, чем в многие другие информационные системы.

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

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

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

Система заработала, но ее использование стало снижаться

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

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

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

О подходах к внедрению

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

Мы у себя в компании также делим проекты внедрения на два крупных типа (названия их условны и не претендуют на академическую правильность).

Классический проект

Он подразумевает последовательное выполнение всем известных этапов: обследование, проектирование, настройка/разработка, тестирование, обучение, опытная эксплуатация.

Такие проекты занимают много времени и достаточно затратны с точки зрения бюджета. Существенную долю трудозатрат (иногда более 50%) поглощает документирование. Внутри этапов часто применяется итерационное планирование, однако общая последовательность этапов фиксирована: нельзя приступить к проектированию, пока не закончено обследование и т.д.

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

Но в тех случаях, когда жестких правил не определено, мы обычно предлагаем идти другим путем.

Итерационное внедрение

Проект делится на типовые функциональные блоки, например, такие:

• сроки и коммуникации (база, без которой не получится стартовать)

• идеи

• риски

• финансы

• ресурсы

• целевые показатели

• предконтрактная деятельность

Блоки запускаются в работу друг за другом, и внутри каждого выполняется такая последовательность работ:

• сбор и обработка данных

• настройка прототипа системы

• обучение пользователей, апробация прототипа

• корректировка и ввод в эксплуатацию

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

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

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

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

Вместо заключения

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

• без внедрения – «не взлетит»;

• двигайтесь постепенно, не пытайтесь объять необъятное;

• больше работайте с людьми – от топ-менеджеров до конечных исполнителей.

Удачи!