Текст
                    в практике
современной
компании
ОЛИМП
БИЗНЕС

Москва ЗАО «Олимп—Бизнес» 2006
Г. Л. Ципес, А.С.Товб в практике современной компании ОЛИМП БИЗНЕС scan: The Stainless Steel Cat
УДК 658.512.012(083.84) ББК 65.290-2 Ц671 Главы 1, 5 написаны А. Товбом и Г. Ципесом; главы 2, 3, 4, 6 и разделы 7.3, 7.4 — Г. Ципесом; разделы 7.1, 7.2 — Г. Циперманом и Г. Ципесом; раздел 7.5 — Г. Циперманом, раздел 7.6 — А. Товбом Общая редакция — А. Товб и Г. Ципес Ципес Г. Л., Товб А. С. Ц671 Менеджмент проектов в практике современной компании. — М.: ЗАО «Олимп—Бизнес», 2006. — 304 с.: ил. ISBN 5-9693-0054-3 Менеджмент проектов широко применяется во всем мире как инстру- мент, позволяющий повысить эффективность бизнеса, обеспечить его устой- чивость, прибыльность, конкурентоспособность — в общем, все то, что назы- вается успехом. Вызовы времени, требования сегодняшнего бизнеса находят свое отражение и в практике менеджмента проектов, но вместе с тем новые возможности, предлагаемые современным менеджментом проектов, извест- ны пока только узкому кругу специалистов. Как изменились методы управления проектами в таких признанных об- ластях, как строительство и информационные технологии? Как применять управление проектами в топливной энергетике, телекоммуникациях, на транс- порте, в государственном управлении? Какие методологии являются ключе- выми для управления проектами в этих индустриях? Почему управление проектами сегодня не следует отделять от других управленческих конту- ров — управления процессами, продуктами, стратегического управления? Ответы на эти и другие вопросы, основываясь на обобщенном опыте нескольких десятков проектов, дают признанные специалисты и популяр- ные авторы. Доступность изложения даже сугубо специальных вопросов, опыт и профессионализм авторов позволяют рекомендовать эту книгу широ- кому кругу специалистов и руководителей как практическую энциклопедию современного менеджмента проектов. УДК 658.512.012(083.84) ББК 65.290-2 Охраняется Законом РФ об авторском праве. Воспроизведение всей книги или ее части в любом виде воспрещается без письменного разрешения издателя. ISBN 5-9693-0054-3 © Г. Ципес, А. Товб, Г. Циперман, 2006 © ЗАО «Олимп—Бизнес», оформление, 2006 Все права защищены.
Содержание Предисловие......................................................XIII Предисловие авторов..............................................1 Глава 1. Тенденции развития современного менеджмента проектов................................з 1.1. Управление проектами сегодня.................................5 1.2. Традиционная методология управления проектами..............................................7 1.3. Динамичный менеджмент проектов..............................11 Неопределенность в проекте...................................12 Границы проекта..............................................16 Кросс-культурная интеграция..................................18 Модели управления проектами..................................18 Модель PMI................................................18 Стандарт PRINCE2..........................................19 Системная модель СОВНЕТ...................................20 Модели ICB IPMA и НТК СОВНЕТ..............................20 Гповальный стандарт компетенции, основанный на выполнении........................................................... 21 Модели «Третьей волны»....................................23 Смежные методологии..........................................25 Сбалансированная система показателей (Balanced Scorecard)......................................25 Управление знаниями (Knowledge Management).................................25 v
VI Содержание Организационное развитие (Organization Development)..........................................26 Управление процессами (Process Management)............................................. 26 Модели зрелости ................................................... 27 Проектный офис и управление портфелями.................................28 1.4. Резюме................................................................29 Литература................................................................ 30 Глава 2. Проекты и стратегия. Проекты, программы и портфели проектов на предприятиях топливно-энергетического комплекса........................................................37 2.1. Краткий обзор методологии.............................................39 Проекты, программы и портфели проектов............................... 39 Офис проекта...........................................................40 Стратегический офис проектов .......................................41 Офис управления проектом.............................................................. 43 Офис проектов подразделения........................43 Сбалансированная система показателей ....................................... 44 2.2. Предприятие топливно-энергетического комплекса как проектно-ориентированная компания......................................47 2.3. Управление комплексными проектами на добывающем предприятии ТЭК............................................. 47 2.4. Управление портфелями проектов на транспортном предприятии ТЭК.............................................53 Проекты транспортного предприятия ТЭК.................................. 53 Соответствие проектов стратегическим целям компании.........................................55 Цели и критические факторы успеха...................................55 Обеспеченность проектов ресурсами......................................56 Процедуры управления портфелем проектов................................57 Процедура формирования портфеля проектов............................57 Процедура мониторинга и анализа исполнения проектов.................59 Оценки и критерии......................................................61 Технический проектный офис.............................................65 2.5. Управление целевыми программами в управляющей компании холдинга ТЭК .......................................66 Организационное планирование ........................................................ 66
Содержание VII Формальная координация организационных мероприятий.......................................67 От координации — к управлению ...................................................... 69 Заинтересованные стороны в программе.............................72 Состав органов управления программой............................74- Органы принятия технических решений......................................... 76 2.6. Резюме.............................................................77 Литература...............................................................78 Глава 3. Проекты и процессы. Оператор связи как проектно-ориентированная компания.........................81 3.1. Краткий обзор методологии...........................................83 Процессы и проекты — туда и обратно.................................83 Процессы как проекты................................................84 Проекты как процессы......................................................................... 89 Гармонизация процессного и проектного подходов в деятельности компании...........................................91 Этап 1. Структурирование операционной деятельности компании........................... 92 Этап 2. Создание механизмов реализации процессов в проектной форме.........................92 Этап 3. Создание механизмов унифицированного выполнения проектов...........................93 Выводы..............................................................94 3.2. Причины и предпосылки внедрения проектного управления в телекоммуникационной компании.....................................94 3.3. Особенности организации проектов подключения.....................................................98 Перераспределение ответственности.......................................... 98 Формирование проектных групп.......................................100 Система мотивации..................................................102 3.4. Управление проектами подключения..................................105 Формализованная среда управления проектами ......................... 105 Процедуры управления проектами.....................................106 Шаблоны управленческих документов..................................115 3.5. Критерии оптимизации процессов подключения........................119 «Как покончить с нехваткой монтеров?»..............................120
VIII Содержание 3.6. Дальнейшее развитие проектного подхода.......................124 От проектов подключения — к проектам обслуживания запросов...........................124 У ровень первичной обработки запросов........................................ 124 У.................................ровень инициализации проектов.............................125 У....................................ровень исполнения проектов.............................. 125 Стратегия внедрения проектного подхода................................. 126 Литература........................................................128 Глава 4. Проекты и продукты. Проектные и продуктовые группы в транспортной компании...........................................129 4.1. Краткий обзор методологии....................................131 Продуктовый подход...........................................131 Проекты в жизненном цикле продукта...........................133 4.2. Продуктовая структура транспортной компании..................134 4.3. Процессы жизненного цикла продукта...........................137 Структура жизненного цикла продукта..........................137 Организация процессов........................................139 Продуктовый цикл как программа...............................140 4.4. Продуктовые группы...........................................142 Организация продуктовых групп................................142 Система мотивации в продуктовых группах......................143 Эволюция продуктовых групп...................................144 4.5. Внедрение продуктового подхода...............................145 Стратегии внедрения..........................................145 Стандарт управления продуктами................................................ 147 Литература.........................................................150 Глава 5. Проекты и стандарты. Стандарт управления проектами строительной компании.............................................151 5.1. Краткий обзор методологии....................................153 Управление проектами — искусство, наука, ремесло..............153 Система управления проектами.................................155 Структура системы управления проектами.....................156
Содержание IX Внедрение системы управления проектами.................................................158 5.2. Управление проектами в строительных компаниях....................................................161 5.3. Политика управления проектами.........................................163 Классификация строительных проектов....................................164 Жизненный цикл проекта.................................................167 Функциональные роли и ответственность участников проекта...................................................................... 168 5.4. Операционный стандарт.................................................171 Структура операционного стандарта......................................171 Процедуры управления проектами.........................................173 Стандарт исполнителя................................................173 Стандарт заказчика..................................................178 Гармонизация стандартов участников проекта ................................................................... 181 5.5. «Большой стандарт для маленькой компании».....................................................186 Параметры организации..................................................187 Характеристика компании.............................................187 Персонал............................................................187 Причины начала работ по созданию стандарта управления проектами........................188 Первый этап — изучить и попробовать....................................188 Стратегия внедрения проектного подхода..............................188 Бюджет первого этапа................................................189 Внутренние консультанты.............................................190 Пилотные проекты....................................................191 Результаты первого этапа............................................191 Второй этап — разработать и внедрить...................................191 Задачи второго этапа ..................................................................... 191 Участники второго этапа проекта.....................................192 Содержание работ....................................................193 Бюджет второго этапа................................................193 Результаты второго этапа............................................193 5.6. Управление проектами в строительстве — технология или философия?...................................................194 Девелоперский проект................................................194 Сервисная модель строительного проекта..............................195 «Ценность за деньги»...................................................................... 195 Литература..................................................................196
X Содержание Глава 6. Проекты и деньги. Бюджетирование и финансирование проектов в органах государственного управления.............199 6.1. Краткий обзор методологии........................... 201 Бюджетирование, ориентированное на результат...........201 Социальная и экономическая эффективность государственных расходов ......................................................... 203 Логико-структурный подход..............................204 6.2. Структура целевой программы...........................205 6.3. Оценка выполнения целевых программ....................206 У..............................ровень базовых показателей..........................209 У......................................ровень измерителей..................................209 У..........................ровень комплексных показателей......................213 6.4. Финансовое управление проектами целевой программы ....214 Особенности финансового управления государственными программами..........................214 Формирование бюджета программы.........................215 Финансовый анализ проекта..............................217 Финансовый аудит проекта............................. 219 Финансовый отчет для Инвестора.........................219 Литература............................................... 222 Глава 7. Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов..........................223 7.1. Краткий обзор методологии........................... 225 ИТ-служба — партнер по бизнесу или «агент влияния»?..................................225 Корпоративная стратегия и стратегия ИТ-службы..........226 Стратегическая карта ИТ-службы.........................228 Ключевые показатели деятельности ИТ-службы.............229 А кому сейчас легко?...................................233 7.2. Политика в проектах внедрения корпоративных информационных систем.........................235 Политические риски проектов внедрения корпоративных информационных систем...................235
Содержание X! Вовлечение, убеждение, принуждение......................................236 Рубежи сопротивления....................................................239 Уровень операционного персонала......................................239 Уровень руководителей среднего звена.................................240 Уровень высших менеджеров .......................................................... 242 Уровень генерального директора.......................................243 Как это будет работать..................................................243 Программа действий для СЮ...............................................244 7.3. ИТ-проекты и персонал компании.........................................244 Человек или ресурс?..................................................244 Кадровые вопросы в стратегии компании...................................245 Чего мы ждем от своих сотрудников....................................245 Как оценивать работу сотрудников.............................................. 246 Как помочь сотрудникам выполнять возложенные на них задачи........................................247 Управление персоналом в переходный период, связанный с внедрением информационных технологий............................................247 Оценка персонала.....................................................247 Компенсация и мотивация..............................................247 Психологическое сопровождение проектов .................................. 248 7.4. ИТ-проекты в портфелях и программах....................................248 7.5. Управление ИТ-проектами в холдинге: подходы и рекомендации.......................................................253 Типы управления ИТ в холдинге...........................................253 Жесткая централизация................................................253 Децентрализованная структура.........................................254 Мягкая централизация.................................................255 Политика информатизации.................................................256 Общие процессы управления...............................................257 Управление инвестициями.............................................................. 257 Управление ИТ-проектами..............................................259 Управление ресурсами............................................... 260 Управление закупками...................................................................... 260 7.6. Повесть о настоящем проекте............................................261 Предпосылки проекта.....................................................261 Участники проекта и их цели .......................................................... 264 Роли и распределение ответственности....................................264 Команда проекта.........................................................266 Предметная область......................................................266 Управление проектом.....................................................267
XII Содержание Основные проблемы и факторы успеха проекта.....268 Уроки управления сложным комплексным ИТ-проектом...............270 Литература.........................................271 Заключение.........................................273 Список таблиц......................................278 Список иллюстраций.................................280 Послесловие........................................283
Предисловие Управление проектами — практическая область менеджмента, с по- мощью которой можно существенно повысить эффективность организа- ции деятельности и качество работ. Преимущество технологии управ- ления проектами заключается в том, что она может быть использована наряду с имеющимися инструментами управления и не требует сущест- венных преобразований в структуре и процессах компании. Управление проектами применимо к любой сфере бизнеса, в лю- бой отрасли и для решения практически любой задачи. Создание ново- го продукта, открытие розничной точки реализации, разработка нового месторождения нефти, внедрение системы управления предприятием, строительство здания — все эти виды деятельности могут рассматри- ваться как проекты. А значит, перед менеджментом компаний открыва- ются бесконечные возможности для усовершенствования этих видов деятельности с использованием проверенных на практике и отрабо- танных механизмов, шаблонов и технологий. Данная книга написана консультантами-практиками на основе мно- голетнего проектного опыта. Это не теория, а подробное описание применения новейших методик проектного управления на примере проектов в таких отраслях, как ТЭК, телекоммуникации, транспорт, строительство, информационные технологии. В книге использован опыт выполнения проектов компанией IBS. IBS — проектная организация, для которой проекты — это способ ведения бизнеса. На основе собственного опыта мы можем с уверен- ностью заявлять, что проектный подход значительно повышает управ- ляемость компании. За счет чего? Мы не только знаем в любой момент времени, чем занимается каждый из консультантов, над каким проек- том он работает и какие задачи решает. Мы можем точно определить, какого типа проекты нам выгодно выполнять, а какие — нет, какие из проектов находятся в зоне риска с точки зрения их безубыточности, а какие — высокомаржинальны. Эта информация позволяет оператив- но принимать управленческие решения, с помощью которых можно эффективно распределить ресурсы, избежать потерь и увеличить при- XIII
XIV Предисловие быль. Проектный подход к управлению позволит вашей компании до- биться таких же результатов. Опыт, представленный в данной книге, поможет понять возможные области применения технологий проектного менеджмента, а также оценить эффективность предлагаемых методик. Приведенные приме- ры проектов настолько детализированы, что могут быть использованы как руководство. Книга «Менеджмент проектов в практике современной компании», изданная в серии «Библиотека IBS», будет полезна не только профес- сиональным и начинающим менеджерам проектов, но и руководите- лям, стремящимся повысить эффективность деятельности компании. Надеемся, что книга ответит на многие ваши вопросы в области приме- нения технологий проектного менеджмента и поможет вам в построе- нии проектного управления в компании. Дмитрий Садков, Директор Департамента управленческого консалтинга IBS
Предисловие авторов Мир управления проектами меняется на наших глазах. Стремительно раздвигаются границы управления проектами, зафиксированные сво- дом знаний PMBOK®Guide в начале 90-х годов прошлого века. Эти изменения возникают в ответ на вызовы времени, на требования сего- дняшнего бизнеса. И вместе с тем новые возможности, предлагаемые современным менеджментом проектов, известны пока довольно узко- му кругу специалистов. Книга, которую вы держите в руках, написана консультантами. Наше основное занятие — искать и предлагать заказчику те формы ведения бизнеса, которые обеспечат этому бизнесу устойчивость, прибыльность, конкурентоспособность — в общем, все то, что называется успехом. В арсенале консультанта всегда есть много разных идей и подходов; среди них ведение бизнеса с помощью проектов — только одно из воз- можных решений. Но это очень мощное решение, в котором гармонично сочетаются философия, методология и инструментарий управления. Мы постарались раскрыть две важные тенденции в современном менеджменте проектов. Во-первых, это расширение сферы примене- ния проектного управления, вовлечение в нее новых сфер (отраслей) экономики. Во-вторых, это совместное использование управления про- ектами с другими управленческими технологиями, их взаимопроник- новение. К сожалению, пока в России потенциал управления проектами, несмотря даже на моду на эти слова, еще очень сильно недооценен. «У нас все это и так есть!», «Нам это не подходит!», «У нас это никогда не будет работать!» — вот возражения, которые нам часто приходилось слышать. Эти три стадии сопротивления (и именно в такой последо- вательности) приходится преодолевать, внедряя методы проектного управления в различных компаниях. По своему жанру эта книга «книга кейсов». Каждая глава посвя- щена проектам в одной сфере деятельности и тем методологиям, ко- торые, на наш взгляд, являются ключевыми для управления проектами в данной сфере. Все примеры, рассмотренные в этой книге, — это 1
2 Предисловие авторов обобщенный опыт нескольких десятков проектов, в которых нам при- шлось участвовать в последние годы. Каждая глава книги снабжена списком использованных источни- ков. Многие из авторов этих книг, статей и докладов являются наши- ми коллегами по профессиональным организациям, просто друзьями. Им мы хотим выразить нашу искреннюю благодарность. Их работы, внимание к нашим публикациям, советы оказали большое влияние на позиции и подходы авторов. Особо мы хотим отметить нашего друга и соавтора нескольких раз- делов этой книги Григория Ципермана (директора по консалтингу IBS). Его профессиональный взгляд на проекты в области информационных технологий был нам абсолютно необходим. Мы хотим поблагодарить и других сотрудников компании IBS, участ- вовавших в проектах, материалы которых использованы в этой книге: Е. Гельфанда, А. Сошнина, А. Савича, Д. Марчука, И. Холкина, Г. Ко- зина, С. Болховитинова, А. Дыльнову, С. Самощенкова, О. Тарасенко, Н. Воробьеву, Е. Терентьева и многих других. И главные слова благодарности — нашим родным и близким, кото- рые пережили уже вторую книгу в нашем исполнении. Григорий Ципес, Главный консультант IBS Александр Товб, Вице-президент СОВНЕТ
Глава 1 Тенденции развития современного менеджмента проектов
Содержание главы 1 1.1. 1.2. 1.3. Управление проектами сегодня............................ Традиционная методология управления проектами............ Динамичный менеджмент проектов........................... Неопределенность в проекте............................................................. Границы проекта ................................................................................... Кросс-культурная интеграция............................. Модели управления проектами........................................................... Модель PMI............................................ Стандарт PRINCE2 ..................................... Системная модель СОВНЕТ............................... Модели ICB IPMA и НТК СОВНЕТ.......................... Гповальный стандарт компетенции, основанный на выполнении Модели « Третьей волны» ................................................ Смежные методологии.............. Сбалансированная система показателей (Balanced Scorecard) .... Управление знаниями (Knowledge Management)............ Организационное развитие (Organization Development)... Управление процессами (Process Management)............ Модели зрелости ............................................................................ Проектный офис и управление портфелями................... Резюме................................... 1.4. Литература ..5 .. 7 11 12 16 18 18 18 19 20 20 21 23 25 25 25 26 26 27 28 29 30 1.1. Управление проектами сегодня Возникшее в развитых странах около 50 лет назад как самостоятельная сфера профессиональной деятельности, управление проектами (или ме- неджмент проектов к настоящему времени стало признанной во всем мире профессиональной дисциплиной, а в последнее время и модным направлением менеджмента в современной рыночной экономике. Ме- тодология и средства управления проектами широко используются во всех сферах проектно-ориентированной деятельности. В наше время уже нет ни одного серьезного проекта, который осуществляется вне рамок идеологии и без использования современного инструментария управления проектами; нет ни одной известной в мире компании, не использующей в своей практике соответствующие методы и средства. За последние десятилетия в условиях взрывного развития так называ- емой новой экономики2 и глобализации менеджмент проектов сформиро- вался как новая управленческая культура и стал своеобразным мостом в цивилизованном бизнесе и деловом сотрудничестве стран и организаций с разной историей развития, традициями, экономикой и культурой. По несколько устаревшим оценкам Project Management Institute (PMI) [3], сегодня свыше 15 млн специалистов и практиков во всем мире вовлечено в проектную деятельность, проекты составляют 25% величины ежегодного мирового валового продукта (около 14 трлн дол.). Профессиональное мировое сообщество включает (по состоянию на март 2006 г.) более 300 тыс. специалистов по управлению проекта- ми, работающих практически во всех сферах проектной деятельности и принадлежащих к глобальной сети профессиональных международ- 1 Мы употребляем оба определения как абсолютно эквивалентные, предпочитая, по возможности, избегать англицизмов. В целях более ясного изложения и четкого понимания в начале главы приводим оба определения, а далее по тексту употреб- ляем их произвольно. Более детальные рассуждения о терминологии можно найти в работах [1] и [2]. 2 Под «новой экономикой» мы понимаем современную глобальную «экономику зна- ний», «информационную экономику», «экономику высоких технологий», а вовсе не экономику финансовых «мыльных пузырей», которую часто и, на наш взгляд, не совсем верно называют «новой экономикой». 5
6 Глава 1 ных и национальных организаций. Из них 217 724 человека (среди них 72% — из США и Канады) являются членами PMI, около 60 тыс. — члены 40 национальных ассоциаций, входящих в International Project Management Association (IPMA), около 40 тыс. — члены других профес- сиональных организаций, свыше 250 тыс. человек — сертифицирован- ные профессионалы по управлению проектами, в том числе 184 815 че- ловек (среди них 61% — из США и Канады) имеют дипломы Project Ma- nager Professional (РМР) и 806 человек — Certified Associate in Project Management (САРМ) по программе PMI, около 50 тыс. — по четырех- уровневой сертификационной программе IPMA и более 20 тыс. — по японской, австралийской, новозеландской и южноафриканской нацио- нальным системам сертификации. Основатель и президент Российской ассоциации управления про- ектами «СОВНЕТ» академик В. И. Воропаев пишет: «Методология и средства управления проектами (УП) широко используются во всех сферах проектно-ориентированной деятельности, в том числе и в госу- дарственном управлении развитых стран. В последние годы правитель- ства таких стран, как США, Великобритания, Германия, Австрия, Япо- ния, Франция, Австралия, Бразилия, Мексика и др., все чаще приме- няют в своей повседневной деятельности методы и средства УП. Так, например, практически каждый чиновник правительства США исполь- зует на своем персональном компьютере программные средства УП в составе набора стандартных пакетов программ. В Министерстве обо- роны США к управлению проектами допускается только персонал, прошедший специальную подготовку и получивший сертификаты про- фессионалов по управлению проектами (РМР). Средства УП активно применяются не только для управления федеральными проектами и программами, но и для осуществления управленческих функций внут- ри правительственного аппарата. Управление проектами сегодня — один из важнейших механизмов рыночной экономики. В наиболее развитых странах он используется практически на всех проектах. Так, в Японии методология управления проектами и программами (Р2М) положена в основу государственной стратегии социально-экономического развития страны. По данным Японской ассоциации управления проектами (JPMF), все инвестици- онно-строительные проекты оцениваются и реализуются с помощью технологий управления проектами, в России же — не больше 1,5—2% от их общего количества. По данным Международной ассоциации управ- ления проектами (IPMA), использование современной методологии и инструментария УП позволяет сэкономить порядка 20—30% времени и около 15—20% средств, затрачиваемых на осуществление проектов и программ. В России же, где организационная система и методы управ- ления гораздо слабее, чем на Западе, эффект от внедрения УП оказы- вается еще более значительным» [4, с. 7].
Тенденции развития современного менеджмента проектов 7 Причина столь высокой популярности управления проектами, преж- де всего, в его успешности. Завершить достаточно сложный проект успешно по современным меркам (в рыночном, социальном, общест- венном понимании успешности) невозможно без профессионального управления. Именно поэтому управление проектами стало в последнее время признанной во всем мире методологией предпринимательской деятельности. Профессионалы порой даже говорят, что управление проектами «обрекает» проект на успех. Разумеется, это некоторое пре- увеличение — только «правильное» управление «правильными» проек- тами приводит к успеху. Управление проектами, основанное на проверенных на практике методах и средствах, профессиональной терминологии и этике, опыте мощных национальных и международных организаций, развитых стан- дартах, системах сертификации, научных исследований, публикаций и образования, превратилось в эффективное средство общения и дело- вого сотрудничества компаний и стран с разной историей развития, традициями, экономикой и культурой. Оно позволяет получить конку- рентное преимущество в бизнесе, государственном и общественном развитии. В этой главе кратко представлено наше понимание сути, состояния и тенденций развития современного управления проектами как профес- сиональной дисциплины в связи с наиболее актуальными аспектами его практического применения в бизнесе, обществе и государственных структурах 1. 1.2. Традиционная методология управления проектами Современное управление проектами в силу своей относительной мо- лодости, синтетического характера и постоянного развития пока еще не стало «канонизированной» профессиональной дисциплиной — ко- дификация знаний не завершена, поэтому возможны различные интер- претации, толкования и трактовки даже того, что мы называем «клас- сическим или традиционным управлением проектами». В переводной литературе это терминологическое и понятийное разнообразие усугуб- ляется неточностями перевода и редактирования, которые по вполне понятным причинам редко бывают достаточно качественными. Традиционно под управлением проектами понимается область ме- неджмента, охватывающая те сферы производственной деятельности 1 Более полно наши взгляды по данному вопросу отражены в работах [5—7]. При этом мы ни в коем случае не пытаемся подменить справочные и учебные пособия по управлению проектами. Для углубленного изучения рекомендуем читателям це- лый ряд таких книг [8—18].
8 Глава 1 компании, в которых создание продукта или услуги реализуется как уникальный комплекс взаимосвязанных целенаправленных мероприя- тий при определенных требованиях (ограничениях), касающихся сро- ка, бюджета и характеристик ожидаемого результата. Графическое изо- бражение этого «тройного (или тройственного) ограничения» в виде так называемого золотого треугольника стало своеобразным символом классического понимания методологии управления проектами. Наличие этих ограничений предъявляет специальные требования к организации и методам управления, суть которых состоит в концентра- ции полномочий и ответственности за проект в целом в руках одного человека (руководителя проекта) и создании команды, в той или иной степени отчуждаемой на время его исполнения от постоянных подраз- делений компании. Проект становится объектом управления — цент- ром затрат и прибылей, что позволяет организовать учет человеческих, материальных и финансовых ресурсов и выстроить систему мотива- ции, базирующуюся на конкретных результатах участников проекта. Наибольшее внимание обычно уделяется процессам управления проектами в следующих функциональных областях: • Управление предметной областью проекта (содержанием и гра- ницами) — определение целей, результатов и критериев оценки успешности проекта (в сфере ИТ, особенно в проектах разра- ботки программных продуктов, часто называют управлением конфигурацией). * Управление проектом по временным параметрам — разбиение проекта на группы работ и отдельные работы; определение последовательности выполнения, продолжительности и распи- сания работ — календарного плана проекта; контроль измене- ний календарного плана проекта. • Управление проектом по стоимостным параметрам — определе- ние видов и количества ресурсов (люди, оборудование, матери- алы); определение стоимости ресурсов и работ; учет и контроль расходов и доходов, а также изменений бюджета. • Управление качеством — определение стандартов качества, от- носящихся к проекту, способов достижения требуемого уровня качества и мероприятий по обеспечению качества; контроль ка- чества. • Управление персоналом — распределение ролей, ответственности и отношений координации и субординации персонала проекта; построение организационных и ресурсных диаграмм; подбор человеческих ресурсов; создание и совершенствование команды проекта.
Тенденции развития современного менеджмента проектов 9 • Управление коммуникациями — определение источников и по- требителей информации внутри и вне проекта, сроков и перио- дичности предоставления информации, способов доставки ин- формации; описание видов распространяемой информации; управление процедурами распространения информации в ходе реализации проектов. • Управление проектными отклонениями: ♦ Управление рисками — выявление событий, которые могут повлиять на проект; определение зависимостей возможных результатов проекта от наступления рисковых событий; выра- ботка стратегий работы с рисками; планирование, осущест- вление и контроль мероприятий, связанных с реагированием на риск. ♦ Управление проблемами — выявление возникающих вопро- сов (функциональных, технических, затрагивающих бизнес и др.), их анализ, принятие и исполнение решений, формаль- ное закрытие и мониторинг проблем проекта. ♦ Управление изменениями — выявление возникающих моди- фикаций ранее согласованных параметров, их анализ, приня- тие и исполнение решений, формальное закрытие и монито- ринг изменений проекта. * Управление контрактами — определение требуемых товаров и услуг, потенциальных продавцов; поддержание формализован- ных отношений с продавцами. Таким образом, учитывая «тройственное ограничение» проекта, облас- ти управления проектом, а также организационные, программные и технические решения, обеспечивающие возможность успешной и эф- фективной работы управленческого персонала проекта, модель проек- та может быть представлена в виде так называемой пирамиды успеха (см. рис. 1.1 [2], приведен с изменениями). Общие «рецепты» управления проектами на первый взгляд просты и понятны, поскольку основаны на структурированном опыте и здра- вом смысле. Проект надо начать с постановки и согласования цели, спланировать путь ее достижения, выполнить предусмотренные рабо- ты и успешно закончить проект, достигнув запланированной цели. Но в реальной жизни редко удается следовать плану или реалистично за- планировать уникальную деятельность. Поэтому управление проектами предполагает постоянный контроль исполнения проекта, выявление отклонений фактического хода выполнения от запланированного, при- нятие корректирующих действий вплоть до согласованной корректи- ровки параметров проекта — сроков, бюджета, даже целей.
10 Глава 1 Достижение результата Соблюдение Соблюдение сроков лимита затрат Соответствие требованиям v результатам Управление Управление Управление Управление содержанием временем стоимостью качеством Управление . УпРавление Управление Управление Управление . коммуника- г- г- г- персоналом 1 рисками изменениями контрактами Организационные и технические решения Стандарт управления проектами: Концепция, Методика, Операционный стандарт Автоматизированный комплекс управления проектами: пакеты прикладных программ календарно-ресурсного планирования, управления документами, управления персоналом и т. д. Рисунок 1.1. «Пирамида успеха» — методология управления проектом Фазы управления 1 проектом соответствуют традиционным фазам управленческого цикла: • Инициация — санкционирование начала проекта или очеред- ной стадии его жизненного цикла. • Планирование — определение наилучшего способа действий, ресурсов и средств для достижения целей стадии жизненного цикла проекта с учетом складывающейся обстановки. 1 В литературе часто можно встретить термины «стадии процесса управления» или «группы процессов управления», что, на наш взгляд, не столь удачно для элементов процессов управления, повторяющихся на разных стадиях жизненного цикла про- екта и при управлении всеми функциональными областями проекта. Часто встре- чающийся термин «фазы жизненного цикла», на наш взгляд, также не слишком удачен для не повторяющихся во времени и, как правило, не существующих одно- временно элементов жизненного цикла проекта. Поэтому мы используем вместо него термин «стадии жизненного цикла».
Тенденции развития современного менеджмента проектов 11 • Выполнение — реализация плана стадии жизненного цикла про- екта (от выдачи задания до получения результата). • Контроль — выявление отклонений фактического выполнения стадии жизненного цикла проекта от запланированного и при- нятие корректирующих действий. • Закрытие — завершение и закрытие проекта или стадии жиз- ненного цикла проекта. Взаимосвязи процессов управления проектами и их реализация по фазам управления представлены на рисунке 1.2 [2] (воспроизведено с изме- нениями). 1.3. Динамичный менеджмент проектов Название этого раздела мы позаимствовали у нашего друга В. Михеева, который вот уже три года проводит проектные мастерские (workshops), посвященные актуальным вопросам современного менеджмента про- Рисунок 1.2. Процессы управления проектом
12 Глава 1 ектов, объединенные этим названием [19]. На одной из этих встреч ее участниками, в том числе и авторами этой книги, были сформулиро- ваны и проранжированы наиболее важные тенденции развития совре- менного менеджмента проектов. В качестве основных тенденций развития современного управле- ния проектами были выделены следующие (перечисляем в порядке убывания важности): 1. Неопределенность в проекте — повышенное внимание к неопре- деленности в проекте и способам ее устранения или снижения. 2. Границы проекта — стремление к расширению традиционных границ проекта и включению в зону ответственности менеджера проекта целого ряда пред- и постпроектных работ. 3. Кросс-культурная интеграция — взаимодействие и наложение американского, европейских, австралийского и азиатских под- ходов к управлению проектами. 4. Модели управления проектами — взаимодействие и взаимопро- никновение различных моделей управления проектами — про- цессной, системной, организационно-деятельностной — и раз- витие соответствующих стандартов. 5. Смежные методологии — широкое использование смежных управ- ленческих методологий и технологий в практике менеджеров проектов. 6. Модели зрелости — настойчивые попытки стандартизации про- ектной деятельности компаний в форме моделей зрелости. 7. Проектный офис и управление портфелями — переход интереса к проектным офисам и управлению портфелями в чисто практи- ческую плоскость. В данном разделе мы рассматриваем эти тенденции и комментируем их, опираясь на работы ведущих зарубежных и российских специалис- тов, опубликованные в последние годы в различных изданиях или пред- ставленные на международных и российских форумах, посвященных управлению проектами. Неопределенность в проекте Повышенное внимание к неопределенности в проекте и способам ее устранения или снижения, на наш взгляд, является ответом современ- ного менеджмента проектов на первоочередные ожидания бизнеса. По крайней мере, мы неоднократно сталкивались именно с такой пози-
Тенденции развития современного менеджмента проектов 13 цией высших руководителей и акционеров, которые рассматривают воз- можность появления подобных способов как важнейшее преимуще- ство проектного подхода. Теоретической базой для развития этого подхода является инсти- туциональная экономика, называющая «неопределенность» главной причиной возникновения трансакционных издержек (один из основопо- ложников этой теории Р. Коуз был удостоен Нобелевской премии по экономике). Источником неопределенности являются поведение участ- ников проекта и их взаимоотношения: «ограниченная рациональность», «оппортунистическое поведение», «специфичность активов» (нерав- ноправие позиций). Факторы неопределенности рассматриваются как специфические риски, методы управления которыми до недавнего вре- мени не были разработаны. Первые решения, направленные на снижение неопределенности, появились в области так называемого контрактанта. Они состоят в том, что тип контракта и стиль работы в проекте определяются исходя из структуры неопределенности. Р. Тернер [20] рассматривает различные подходы участвующих в проектном контракте сторон (Заказчика и Исполнителя) и показы- вает, что путь к успеху в проектах высокой неопределенности лежит в создании и отражении должным образом в контракте того, что мы назвали бы атмосферой конструктивного партнерства. Это означает, что контракт должен являться средством гармониза- ции интересов сторон путем обеспечения: • соответствующих общим целям стимулов; • гибкого и дальновидного управления в условиях неопределен- ности; • снижения трансакционных издержек; • наличия необходимых мер предосторожности. Р. Тернер предложил развернутую классификацию контрактов, исполь- зуемую как инструмент управления неопределенностью, и стратегию выбора типа контракта, учитывающую следующие параметры: • сложность проекта (простой, масштабный, сложный, многоэтап- ный и т. д.); • ответственность за риск (отвечает только Заказчик, только Ис- полнитель или обе стороны); • природа неопределенности в проекте (источники рисков в про- дукте проекта, в методе создания продукта, в управлении проек- том, разнообразные источники рисков).
14 Глава 1 Для сложных проектов и программ Д. Домбкинс рассматривает исполь- зование специальной технологии контрактинга — Governance Con- tracting™, основой для разработки которой послужил подход Integrated Alliancing™, применяемый на уровне бизнес-планирования [21 ]. Ана- лиз развития контрактинга за период 1989—2001 гг. позволяет разде- лить традиционные контракты и так называемые контракты отноше- ний. В качестве условной границы служит появление в 1994 г. конт- рактов типа партнерства. Причину развития форм контрактинга автор видит в усложнении отношений сторон при реализации все более слож- ных проектов и программ в условиях постоянно растущей неопреде- ленности делового окружения. Governance Contracting™ сдвигает фокус от управления проектом к управлению бизнесом или программой; эта технология обеспечивает основу для долговременных отношений сторон, необходимых для успеш- ной реализации масштабных программ, развития зрелости организа- ций, таких, например, как государственно-частные партнерства (Public/ Private Partnership, PPP). Governance Contracting™ включает пять стадий отбора Исполните- ля, подготовки и заключения контракта: 1. Выражение первоначального интереса сторон. На этом этапе по различным вопросникам проверяют зрелость, компетентность и деловую культуру потенциальных Исполни- телей, но их не спрашивают о применении этих возможностей в проекте. Также проводятся специальные мероприятия по ин- формированию потенциальных Исполнителей о намерениях Заказчика. 2. Запрос на Предложение. Потенциальным Исполнителям предлагают разработать Пред- ложение, которое в технологии Governance Contracting™ назы- вается Бизнес-планом и по своему содержанию и детализации соответствует развернутому Технико-коммерческому предложе- нию (ТКП). По этому документу Заказчик должен оценить, как потенциальный Исполнитель сможет применить к конкретному проекту свои возможности, подтвержденные на предыдущем этапе. 3. Обсуждение Бизнес-плана. Обсуждение проводится в форме совместных проектных семи- наров (проектных мастерских) с каждым из потенциальных Ис- полнителей, в ходе которых в реальной ситуации можно оце- нить уровень их компетентности и деловой культуры.
Тенденции развития современного менеджмента проектов 15 4. Окончательный выбор лучшего предложения. По результатам проектных семинаров потенциальные Исполни- тели получают возможность модифицировать свои Бизнес-пла- ны. Производится выбор лучшего из представленных предложе- ний. В результате этой стадии качество Бизнес-плана отобранного Исполнителя значительно повышается благодаря большему со- ответствию запросам Заказчика. 5. Заключительные переговоры. Выбранный Исполнитель и Заказчик совместно работают над Бизнес-планом, согласовывая его положения для заключения контракта. Важнейшим результатом стадии является достиже- ние взаимной ответственности за проект, что служит основой для создания впоследствии общих (интегрированных) проект- ных команд и органов управления. Вопросы перспектив институализации и внедрения методологий контр- актинга на российском рынке затрагиваются в работах В. Ананьина и его соавторов [22—24]. В работе [22] рассматриваются несколько типов ИТ-проектов, име- ющих различные уровни неопределенности, — создание нового про- дукта (инновационный проект), вывод известного продукта на новый рынок, типовое внедрение системы стандартной функциональности. На примере этих проектов анализируются зависимости эффективности типов контрактов и стилей управления проектом от уровня неопреде- ленности в проекте. Анализ сложных ИТ-проектов, приведенный в работе [24], показы- вает, что трудозатраты на поиск взаимоприемлемого решения могут достигать 70% от всей трудоемкости проекта. Причина в том, что За- казчик, как правило, не может четко формулировать цели и ставить задачи. Ему можно в этом помочь, но полностью сделать это за него невозможно. То, что сложный ИТ-проект начинается с размытых це- лей и не имеет четких границ, — не исключение, а правило. Несмотря на то что при заключении контракта стороны стараются детально про- писать все условия, права и обязанности, контракт все равно, по сущест- ву, остается рамочным, а в деталях порой даже противоречивым. Часто выполнение плановых проектных работ и переговорный процесс идут параллельно. Нечеткий контракт в ИТ-проекте часто воспринимается как недо- статок. Тем не менее в юридической практике такие контракты — нор- мальная ситуация. Здесь накоплен огромный опыт работы по прави- лам с соблюдением баланса интересов участников в условиях неопре- деленности. Юридическое право рассматривает контракты в основном
16 Глава 1 между юридическими лицами. Теория институциональной экономики пошла дальше, распространив понятие контракта (соглашения) на фирму, экономические и даже социальные институты. В рамках ин- ституциональной теории деятельность любой организации рассматри- вается как сеть соглашений между ее участниками. ИТ-проект можно также рассматривать как развивающуюся сеть соглашений. При этом соглашения начинают формироваться задолго до появления самого юридического контракта, например когда заключается протокол о намерениях. Далее сеть соглашений развивается по горизонтали — в рамках одного уровня управления и по вертикали — между уровнями управления. Горизонтальные соглашения могут заключать: спонсоры проекта — партнерские и юридические соглашения; руководители проекта — по- ложения об организации проекта; специалисты проектной группы — протоколы, планы, рабочая документация. Горизонтальные соглаше- ния дополняются по вертикали управления поручениями и приказами. Предметами соглашения могут быть не только используемые ресурсы или получаемые результаты, но также и работы, требования, статьи бюджета проекта и даже его цели, границы и намерения. Баланс интересов сторон достигается за счет соблюдения фунда- ментальных принципов права: 1) в рамках соглашения права и обязанности должны быть сбалан- сированы; 2) должна обеспечиваться преемственность соглашений. Дисбаланс соглашений рождает издержки или риски, которые также могут стать объектом соглашений: определяются их владельцы и ком- пенсационные схемы. Специалисты предлагают использовать контрактный подход не как альтернативный, а как дополняюший существующий арсенал методо- логий управления проектами. Он позволяет использовать богатую юри- дическую практику управления сложными контрактами. Границы проекта Стремление к расширению традиционных границ проекта и включе- нию в зону ответственности менеджера проекта целого ряда предпро- ектных и постпроектных работ стало настоятельной необходимостью по мере усложнения проектов и их контекста во всех отраслях бизнеса и областях применения проектных подходов. Вопрос границ проекта — это вопрос ответственности. Кто отве- чает за достижение целей проекта в самом широком смысле (не только
Тенденции развития современного менеджмента проектов 17 за «тройное ограничение»)? Предпроектные работы связаны, главным образом, с принятием решения о запуске проекта и его параметрах. Что относить к предпроектным работам, а что к собственно проекту*, трактуется различными стандартами по-разному. Анализ этих подходов применительно к ИТ-проектам приведен Е. Зиндером в работе [25]. Радикальное решение вопроса о границах проекта предлагается в современной японской методологии Р2М, выстроенной в соответствии с базовой японской философией «найти решение сложной проблемы». Методология Р2М сфокусирована на том, чтобы создать ценности для предприятий любого вида деятельности (коммерческих или общест- венных) в результате последовательной реализации их миссии через воплощение стратегии в программах и входящих в них проектах. Основ- ная особенность методологии Р2М может быть выражена как «опреде- ляемое миссией управление проектами или программой», которое опре- деляется сложностью решения проблемы в условиях взаимодействия между технической системой и моделью бизнеса. В рамках традицион- ного, классического управления проектами это динамическое взаимо- действие не могло быть глубоко рассмотрено и отражено в логике управ- ления. Методология Р2М положила начало решению этого вопроса за счет уникального подхода к управлению программами. Разработчики Р2М полагают, что при реализации обычных проек- тов менеджер проекта сосредоточивает свое внимание на том, как во- время и не превышая сметных затрат поставить изделие или предоста- вить услугу [26]. При этом все, что происходит за пределами сферы действий менеджера, обычно его не интересует. Поэтому его возмож- ности выбора ограничены только на уровне работ, а оценки — структу- рой показателей освоенного объема. Однако при переходе к оценкам владельца (спонсора) проекта следует к этому добавить необходимость смягчения рисков и создания ценностей проекта (программы) в том, что касается творчества (креативности), нестабильности среды, чрез- вычайных ситуаций и широты интерфейсов. Роль владельца проекта чем-то напоминает роль пилота, управляющего аэробусом. В сложных проектах и программах требуется больше значимых ин- дикаторов для оценки эффективности по целям, процессу, заинте- ресованным лицам и проблемным вопросам по всем отраслям. В мето- дологии Р2М для оценки проектов применяется «сбалансированная система показателей», предложенная Д. Нортоном и Р. Капланом (см. раздел 2.1). В методологии Р2М главная идея управления проектами и про- граммами — это создание новой ценности (инновация), а интеграция — самая важная часть структуры управления. При этом, как пишет К. Бре- дилле, методология Р2М предусматривает гибкую и легко приспосаб-
18 Глава 1 ливаемую систему взглядов, а не только «единственный и лучший спо- соб» ведения дела, закрепленный в западной парадигме рационального позитивизма [27]. Кросс-культурная интеграция Для успеха проектов, выполняемых в современных условиях глобали- зации, абсолютно необходимой является кросс-культурная интеграция, состоящая в конструктивном взаимодействии американского, европей- ских, австралийского и азиатских подходов к управлению проектами и в достижении синергетического эффекта от их взаимного наложения. Национальные и культурные особенности проявляются и в подходах к управлению проектами. Японцы одними из первых не только призна- ли этот факт, но и зафиксировали его на уровне методологии Р2М. Сравнительный анализ американского и китайского (КНР) под- ходов приведен в монографии [28]. Особенности работы проектных команд (в том числе и «виртуальных» — пространственно-распре- деленных) в мультикультурной среде рассматриваются в исследова- ниях [29] и [30]. О том, как различие культур в проекте может приво- дить не только к конфликтам и кризисам, но и порой даже к «войнам», можно узнать из работ В. Михеева (см. [31, 32]), в одной из которых представлен интересный взгляд на мужское и женское начала в проект- ной команде. «Выравнивание» и гармонизация различных подходов — задача еже- годных открытых встреч Global Forum ведущих представителей нацио- нальных школ и международных профессиональных организаций, про- водимых параллельно со всемирными конгрессами IPMA [87]. Модели управления проектами Одной из важнейших тенденций современного менеджмента проектов является взаимодействие и взаимопроникновение различных моделей управления проектами — процессной, системной, организационно-дея- тельностной (менеджерской). Все упомянутые модели развиваются и не отменяют друг друга, опыт конкретных проектов показывает плодотворность их совместного ис- пользования. Рассмотрим упомянутые модели более детально на осно- ве анализа соответствующих им основных рамочных стандартов. Модель PMI С середины 1980-х гг. PMI последовательно развивает в своих стандар- тах и в последнее время эффективно продвигает во всем мире простую в понимании, ясную и весьма действенную процессную модель управле-
Тенденции развития современного менеджмента проектов 19 ния проектами, расширив ее и на управление портфелями проектов и программами. Всего в мире напечатано уже около 2 млн экземпляров Руководства к Своду знаний по управлению проектами (РМ ВОК® Guide) (в рамках трех изданий), осуществлен его официальный перевод на восемь наиболее распространенных в мире языков, включая и русский [18]. Многие эксперты отмечают относительное падение качества по- следних стандартов PMI по сравнению со стандартами PMI средины 90-х годов прошлого века. На наш взгляд, это может объясняться как ограничениями положенной в основу стандартов PMI процессной мо- дели, так и неизбежными издержками стремления к универсализации (в смысле «всеохватности») стандартов, которой можно достичь только за счет соответствуюших обобщений и унификации положений стан- дартов в ущерб учету «тонких» особенностей предмета стандартизации. К сожалению, мы вынуждены обратить внимание читателей на низкие оценки авторитетными экспертами из разных стран качества соответ- ствующих переводов PMBOK®Guide; увы, таковы многие оценки и упомянутого перевода на русский язык. Процессный подход послужил основой для создания IPMA стандар- та ISO/TQ 10006:1997 [33], получившего впоследствии статус ГОСТ Р. Само наличие такого рамочного стандарта, придавшего ряду важных положений процессной модели управления проектами статус стан- дарта де-юре, очень важно для управления проектами как профессио- нальной дисциплины, хотя сам этот стандарт по своей форме, статусу и качеству не может быть использован ни как свод знаний, ни как основа для профессиональной сертификации, ни как стандарт пря- мого действия. Стандарт PRINCE2 Самого серьезного внимания, по нашему мнению, заслуживает бри- танский стандарт PRINCE2 (PRojects IN Controlled Environment). Этот стандарт первоначально был создан в 1989 г. для управления британ- скими государственными проектами в области информационных и теле- коммуникационных технологий. К настоящему времени этот стандарт в версии 1996 г., обновленный в 2002 г., стал де-факто всемирно при- знанным стандартом — структурированным процессом управления про- ектами в различных отраслях. PRINCE2 позиционируется авторами как процессный подход к управлению проектами, обеспечивающий легко адаптируемое и масштабируемое средство для управления любы- ми типами проектов. Каждый процесс в проекте определяется вместе с ключевыми входными и выходными данными, а также со специфиче- скими целями и предпринимаемыми действиями. Выделяются шесть последовательных дискретных основных процессов, соответствующих
20 Глава 1 частям жизненного цикла проекта, начиная от старта проекта и заканчи- вая его закрытием, и два процесса, обеспечивающих шесть основных, — планирование и руководство. Последние имеют сквозной характер и продолжаются в течение всего проекта. В каждом из процессов пре- дусмотрены более детальные подпроцессы (всего 45). Имеются также шесть так называемых компонентов: часть из них — документы, а часть — процессы. И наконец, стандарт PRINCE2 описывает три ме- тодики — планирование, основанное на продукте; обзоры качества; управление изменениями. Руководство по стандарту 1 представляет со- бой ясно написанный и легко читаемый документ, состоящий из основ- ного текста, четко структурированных перечней вопросов, диаграмм процессов и иногда советов и подсказок. Процессы, их взаимодействие, компоненты, методики, формы вход- ных/выходных документов, соответствующие функциональные роли описаны в стандарте очень подробно, что позволяет найти почти все необходимое для создания конкретного корпоративного стандарта или стандарта для выполнения отдельного проекта. Существует и развива- ется система сертификации специалистов по стандарту PRINCE2. Системная модель СОВНЕТ Научные и методологические основы системных моделей управления проектами [34] получили дальнейшее развитие в работах академиков В. И. Воропаева, В. Н. Буркова, С. Д. Бушуева и их учеников [9—11, 35, 36]. На системных моделях основаны подходы, на которых строятся такие фундаментальные работы, как исследование [8]. Авторы данной книги также выстраивали свои методологические подходы к управле- нию проектами, используя как основу так называемую «системную модель СОВНЕТ» [2]. Модели ICB IPMA и НТК СОВНЕТ К организационно-деятельностным (менеджерским) моделям управ- ления проектами можно отнести принятую и развиваемую IPMA мо- дель International Competence Baseline (ICB) [37]. Для образующих IPMA национальных организаций модель ICB служит основой в формализа- ции знаний по управлению проектами и смежным областям при под- готовке Национальных требований к компетентности (НТК), таких как НТК СОВНЕТ [35]. НТК являются базой для подготовки к проводи- мой национальными ассоциациями международной четырехуровневой сертификации профессиональных менеджеров проектов по системе IPMA. Характерной особенностью модели ICB является ее достаточно 1 Существует пока только на английском языке.
Тенденции развития современного менеджмента проектов 21 высокая открытость, которая позволяет национальным ассоциациям вносить в нее собственные специфические элементы, в частности НТК СОВНЕТ построены в значительной степени на основе упомянутой выше «системной модели СОВНЕТ». В 2006 г. вышла новая версия модели ICB, и, соответственно, ско- ро начнется работа над новой версией НТК СОВНЕТ. Авторы этой книги принимают определенное участие в соответствующих коллек- тивных действиях. Однако следует упомянуть, что ни мнение СОВНЕТ как национальной ассоциации, ни наше мнение не являются един- ственными и не всегда разделяются коллегами и находят воплощение в итоговых документах. Новая версия ICB содержит описание системы четырехуровневой сертификации IPMA в соответствии со стандартом ISO/IEC 17024 и системы знаний по управлению проектами, программами и портфеля- ми проектов в виде 45 элементов профессиональной компетентности. Эти элементы разделены на три группы: • технические — 20 элементов, имеющих отношение к содержа- нию деятельности по управлению проектами; • поведенческие — 15 элементов, относящихся к персональным взаимоотношениям отдельных личностей и групп в деятельно- сти по управлению проектами; • контекстуальные — Ю элементов, определяющих взаимодействие управления проектами и окружения проекта (организационного, делового, политического, социального и т. п.); как особенно важ- ное выделяется взаимодействие с постоянной или родительской организацией. Анализ модели 1СВ и ее развития можно найти в работах М. Уайдмана [34] и С. Бушуева [38], а также в статье соавторов новой версии ICB 3.0 Дж. Коха и Г. Кнопфеля [85]. Гповальный стандарт компетенции, основанный на выполнении В середине 90-х годов прошлого века в международном профессио- нальном сообществе сложилась инициативная группа (Global Perfor- mance Based Standards for Project Management Personnel Initiative — GPBSPMPI) по разработке глобальных стандартов по управлению про- ектами. В своей деятельности GPBSPMPI опиралась на поддержку ряда международных (PMI, IPMA) и национальных ассоциаций, а также нескольких десятков спонсоров — коммерческих компаний, прави- тельственных агентств и образовательных учреждений.
22 Глава 1 Главной целью группы является разработка единых, международ- но-признанных стандартных критериев оценки квалификации мене- джеров проектов по их деятельности. Этот подход позволяет обеспе- чить полную прозрачность и унификацию оценок профессиональной компетентности менеджеров проектов в условиях глобализации миро- вой экономики, что, в свою очередь, даст неоспоримые преимущества самим специалистам по управлению проектами. Деятельность рабочей группы имеет следующие основные цели: • разработка стандарта, ориентированного на профессиональную деятельность менеджеров проектов и позволяющего сделать оцен- ку их квалификации абсолютно прозрачной. Это означает, что должны быть сформулированы определенные критерии оценки работы менеджеров проектов, которые будут унифицированы для разных стран; • поддержка локальных инициатив по разработке стандартов, ко- торые будут развиваться в контексте рамочного стандарта, пред- лагаемого рабочей группой; • формирование взаимного уважения и признания профессиональ- ных квалификаций организациями и национальными ассоциа- циями по управлению проектами. Одна из задач стандарта — обеспечить менеджерам проектов возможность работать в разных странах без повторной сертификации ’. Стандарт компетентности, основанный на выполнении, описывает роль менеджера проекта в компании. Стандарт определяет, что должен уметь делать менеджер такой квалификации, каким критериям качества долж- но соответствовать выполнение им своих обязанностей, а также ка- ковы внешние условия, в которых будет оцениваться квалификация менеджера проектов, что позволяет учесть различия требований в раз- ных отраслях. Смысл такого стандарта — в едином описании условий проверки, рассмотрения и оценки, уровней и содержания приемлемых фактических результатов работы, которые должны продемонстрировать 1 Здесь имеется в виду стремление к унификации сертификационных требований различных национальных (Великобритания, Австралия, Новая Зеландия, ЮАР, Япония и др.) и международных (IPMA и PMI) систем сертификации на базе соз- даваемого GPBSPMPI стандарта. Многие эксперты не считают сертификацию PMI международной по статусу — де-юре, хотя, на наш взгляд, она фактически уже является (и во все большей степени становится) глобальной и может называться международной — де-факто.
Тенденции развития современного менеджмента проектов 23 профессионалы на своих рабочих местах при выполнении стандарти- зованных элементов профессиональной деятельности. Работу GPBSPMPI организует и координирует известный специа- лист профессор Л. Крауфорд [39]; в ней участвуют также выдающиеся специалисты X. Танака, М. Ишикура, С. Охара, к которым в послед- ние годы присоединился и основной автор PMBOK®Guide 1996 г. изда- ния В. Дункан [40]. В 2005 г. GPBSPMPI была переименована в GAPPS (Global Alliance for Project Performance Standards), как мы поняли, с главной целью — сосредоточиться не только на разработке и развитии стандартов, но и на их эффективном продвижении. В настоящее время завершена разработка части стандарта, опреде- ляющей квалификацию старшего менеджера проекта (senior project manager). От человека, находящегося на данной позиции, напрямую зависит результат проекта. Это означает, что его финансовое возна- граждение соответствует степени успешности проекта. Он несет ответ- ственность за тот продукт, который должен быть предоставлен клиенту в результате выполнения проекта. Наконец, это менеджер, который работает в сложной динамической среде и должен учитывать интересы всех участников проекта. В стандарте определяются такие единицы компетентности старшего менеджера проектов, как управление запус- ком и закрытием проекта, развитием проектного плана и ресурсами проекта, взаимоотношениями с заинтересованными участниками, юри- дическими проблемами и др. В сентябре 2005 г. стандарт был представлен отечественным экс- пертам, состоялось его публичное обсуждение. Общее мнение: доку- мент весьма высокого качества, при условии качественного перевода он может наряду с другими перечисленными выше рамочными стандар- тами служить хорошей основой для создания корпоративных стандартов управления проектами и для подбора и профессионального развития менеджеров проектов. Использование этого стандарта для профессио- нальной сертификации менеджеров проектов в нынешних условиях представляется весьма проблематичным. Мы полагаем, что достигну- тые в ходе разработки этого стандарта конкретные результаты явля- ются реальными и высокими достижениями, а поэтому могут и долж- ны быть учтены при совершенствовании существующих систем серти- фикации PMI и IPMA. Модели «Третьей волны» В мире управления проектами постоянно идут интенсивный поиск, исследования и разработки новых идей, подходов и моделей. Заметным явлением стала публикация ряда совместных работ В. Ми- хеева и Д. Пеллса [41—43], где они всесторонне рассматривают разви- тие и современное состояние профессионального менеджмента проек-
24 Глава 1 тов и программ. В его развитии они выделяют три последовательные «волны» в соответствии с господствующими на разных исторических этапах управленческими парадигмами: • 1950—1970-е гг. — «Первая волна» — «техническая парадигма»; • 1980—1990-е гг. — «Вторая волна» — «менеджерская парадигма»; • 2000—... гг. — «Третья волна» — «фенотиповая парадигма». Менеджмент проектов «Третьей волны» рассматривается как стратеги- ческий ресурс организации, как мощная зрелая «трансформационная технология, которая может облегчить достижение чего угодно, если это будет определено как проект, ...как своего рода профессиональный инструмент для осуществления мечты». Более глубоко с этим подхо- дом можно познакомиться в новой книге В. Михеева [44]. Яркой иллюстрацией моделей «Третьей волны» являются интерес- ные работы целой группы специалистов из Германии и Швейцарии — М. Сайниша и его последователей — Т. Хубера, О. Вернера и С. Рие- тикера [45—47]. Эти специалисты считают, что традиционные модели менеджмента проектов сконцентрированы на выполнении отдельных проектов и должны быть расширены в корпоративном и социальном контексте для обеспечения необходимых современному бизнесу конкурентных преимуществ, достигаемых путем реализации стратегии через портфе- ли проектов и программ. Предлагается так называемая модель М. Сай- ниша, или «модель управления проектами 2-го порядка» (РМ2) [45]. Традиционный менеджмент проектов, или «модель управления проек- тами 1-го порядка» (РМ1), при этом является интегральной частью РМ2, которая основана на использовании отдельных методов и подхо- дов естественных и социальных наук, таких как теория эволюции и теория хаоса, теория самоорганизации, теория систем, теория позна- ния, когнитивная психология и т. п. В работе Т. Хубера, О. Вернера эта модель реализована в виде так называемой пирамиды виртуозного менеджмента проектов [46]. Эта модель включает три уровня: • инструментальный, • процессный, • мыслительный; и четыре стороны (четыре мира — по М. Сайнишу): • классический менеджмент проектов («мир твердых фактов»); • управление сложностью (система перекрестных связей);
Тенденции развития современного менеджмента проектов 25 • управление человеческим фактором (психология, обучение, со- циология); • культура (базовые модели мышления, отношения). В работе С. Риетикера [47] модель М. Сайниша, предназначенная для управления отдельным проектом, дополнена подходами, основанными на идеях известного современного австрийского теоретика менеджмента Ф. Малика, на теории открытых систем и на унаследованных IBM от PriceWaterhauseCoopers проверенных методологиях Component Business Modeling (CBM) и Seven Keys to Success™. При этом особое внимание уделено отношениям между проектной и родительской организация- ми. В результате предлагается новая методология KEY-9, которая долж- на рассматривать проекты как часть полной корпоративной системы, а менеджмент проектов — как неотъемлемую часть управления и эф- фективно создавать благоприятную для проектов рабочую окружаю- щую среду. Смежные методологии Широкое и плодотворное использование в практике менеджеров про- ектов получили смежные управленческие методологии и технологии. Перечислим только основные из них. Сбалансированная система показателей (Balanced Scorecard) Применение этой методологии породило радикальную идею перехода от классического «тройного ограничения» (Triple Constraint) к «четы- рехстороннему ограничению» (Quadruple Constraint). К ограничениям по срокам (on-time), стоимости (on-budget), характеристикам резуль- тата (on-quality) добавилось ограничение по соответствию стратегии (on-strategy), что позволило связать как цели, так и результаты выпол- няемых проектов развития с миссией и стратегией предприятия (см. [48, 49]). Управление знаниями (Knowledge Management) Применение этой методологии направлено на инновации в части со- блюдения «тройного ограничения», что позволяет выполнять проекты быстрее, дешевле и лучше [50]. Использование методологии управле- ния знаниями дает возможность построить в проектах временную, так называемую обучающуюся организацию, эффективно учитывать опыт прошлых проектов, оптимально организовать работу с проектной до- кументацией. Повышение эффективности от совместного использова-
26 Глава 1 ния управления проектами и управления знаниями достигается за счет идентификации и анализа требуемых и доступных знаний, а также за счет планирования и контроля мероприятий по развитию знаний как нематериального актива, имеющего особую ценность. При интеграции методологий управления проектами и управления знаниями учитыва- ются различные аспекты организационной культуры, особенности ком- муникаций, технологии, процессов управления и т. п. Совместное при- менение управления проектами и управления знаниями необходимо для достижения совершенства в управлении проектами. Организационное развитие (Organization Development) Применение этой методологии совместно с методологией совершен- ствования процессов разработки программного обеспечения дало воз- можность управлять поведением сотрудников, вовлекаемых в проект [51]. Внедрение этих методологий направлено на повышение эффек- тивности организации сверху вниз путем изменения поведения отдель- ных работников и групп и включает следующие основные процессы: постановку целей, планирование мероприятий, разрешение возника- ющих проблем, внешние и внутренние коммуникации, лидерство, рас- смотрение результатов и поведения и т. д. С помощью консультантов по процессам оказывается помошь сотрудникам для того, чтобы они сами решали свои проблемы, а также осуществляется так называемый коучинг, изменяющий поведение сотрудников. Для продвижения методологии в компании используются различ- ные формы — тренинги, семинары, учебные курсы. Совместное при- менение методологии интеграции знаний (Knowledge Integration, KI) и методологии совершенствования процессов разработки программного обеспечения в корпорации TIS не только позволило повысить эффек- тивность работы, но и создало предпосылки для глубокого внутренне- го и внешнего единства работников и организации во всех аспектах. Управление процессами (Process Management) По утверждению Э. Ферна, рост современного производства невозмо- жен без кастомизации производимого продукта под индивидуальные требования каждого отдельного клиента, что фактически стирает грань между проектом и процессом (см., например, [53]). Каждый процесс становится настолько особенным, что есть смысл реализовывать его в проектной форме. В. Кремзер предложил внедрить некий вид гибкой, процессно-ори- ентированной организации управления проектами, которая наилучшим образом подходит для ограниченных возможностей малого бизнеса [52].
Тенденции развития современного менеджмента проектов 27 Специальные усилия должны быть предприняты, чтобы интегриро- вать, насколько это возможно, процессы управления проектом в раз- витие бизнес-процесса основной операционной деятельности. Весьма глубокий анализ и конкретные практические рекомендации по организации, анализу, оценке зрелости, реинжинирингу и управле- нию бизнес-процессами в проектно-ориентированной компании даны Р. Гаррейсом [54]. Его вывод таков: чем более зрелой является проект- но-ориентированная компания в управлении бизнес-процессами, тем более стабильные и хорошие результаты она получит при управлении проектами и программами. Исходя из собственного опыта мы пришли к выводу, что для мно- гих производственных задач невозможно заранее определить, какая форма их решения окажется более эффективной — процессная или проектная [55]. Если ситуации, когда нужно делать подобный выбор, из исключения становятся правилом, возникает необходимость, во-пер- вых, формализовать процедуры принятия этих решений и, во-вторых, обеспечить саму возможность одновременного существования обеих этих форм управления в компании. Первое достигается за счет разработки системы четких критериев, позволяющих определить в каждом конкретном случае, какая именно форма является более эффективной, и за счет правильного распреде- ления прав и ответственности между владельцами процессов и мене- джерами проектов, которым передается управление отдельными про- цессами. Второе достигается, прежде всего, за счет построения гибких организационных структур матричного типа, что, в свою очередь, сра- зу же предъявляет специальные требования и к системе бюджетирова- ния, и к системе учета, и ко многим другим контурам управления в компании. Описанные подходы во многом послужили основой для реализации нами описанных в главах 3, 4 и 5 этой книги конкретных «кейсов». Интеграция информационных систем управления проектами с раз- личными программными приложениями (ERP, CRM, SCM, PLM, PDM и т. п.), усиливающаяся в последнее время, может быть также отнесена к использованию в управлении проектами различных смежных управ- ленческих методологий и технологий. Часто эта интеграция предусмат- ривается наличием в составе соответствующего приложения модуля управления проектами. Модели зрелости В последнее десятилетие вслед за успехом в индустрии информацион- ных технологий моделей зрелости СММ (Capability Maturity Model) и CMMI (Capability Maturity Model Integrated) предпринимались настой-
28 Глава 1 чивые попытки стандартизации проектной деятельности компаний в форме моделей зрелости. Разными авторами был предложен целый ряд таких моделей (см., например, [56—58]). В декабре 2003 г. PMI завершил разработку стандарта ОРМЗ (Organizational Project Management Maturity Model), и он поступил в свободную продажу. На сегодняшний день накоплен уже значитель- ный опыт его практического применения во всем мире, в том числе и в России (см. [59—62]). По общему мнению экспертов, стандарт и соответствующий инст- рументарий имеют практическую ценность на российском рынке — в первую очередь для внутренних оценок уровня зрелости проектной организации с целью совершенствования практики управления проек- тами. Несколько завышенных ожиданий в профессиональной среде (возникших по аналогии с эффектом от появления СММ и CMMI), которые предшествовали появлению ОРМЗ, ни сам стандарт, ни его инструментарий пока не оправдывают. Проектный офис и управление портфелями Эти темы стали популярными в России в начале 2000-х гг. В послед- ние несколько лет мы наблюдаем переход интереса к проектным офи- сам и к управлению портфелями в чисто практическую плоскость. Хотя сегодня тема проектного офиса менее популярна, но она по-прежнему пользуется устойчивым интересом. С точки зрения мето- дологии эту тему можно считать практически исчерпанной с выходом книг [63] и [64]. На первый план выходят конкретный опыт, опенки и статистика, необходимые для решения двух главных вопросов: какую модель проектного офиса использовать в компании и в каких случаях, как измерить успех создания проектного офиса? На эти вопросы отве- ты можно найти в работах [61, 65—69]. Тема управления портфелями проектов и программами по-преж- нему пользуется значительным интересом. На первый план выходят конкретный опыт постановки управления портфелями проектов и про- граммами в компаниях, его оценка, сравнительные достоинства ис- пользования тех или иных инструментальных средств — Artemis, Prima- vera, MS Project, IBM Rational Portfolio Manager — и прикладных про- граммных решений, построенных на их базе, таких, например, как Opus Magnum Enterprise Management [86]. Современный опыт управления портфелями проектов и программами широко представлен в статьях в журналах и докладах на конференциях и симпозиумах последних лет [70—74]. В качестве фундаментального справочного пособия по управ- лению портфелями можем рекомендовать монографию [75].
Тенденции развития современного менеджмента проектов 29 1.4. Резюме Мы кратко рассмотрели суть, состояние и тенденции развития совре- менного менеджмента проектов, использовав все доступные нам источ- ники, для того, чтобы представить читателю наш взгляд на современ- ное управление проектами как на зрелую профессиональную сферу, имеющую, как считает В. Воропаев (4|: • сложившиеся и выверенные практикой концепции, теорию, ме- тодологию и развитые технологии; • признанные международные и национальные стандарты и дру- гие нормативно-методические документы; • развитый мир профессиональных публикаций, конференций и конгрессов; • богатый рынок профессиональных программных приложений; • развитый рынок профессиональных услуг; • современные системы образования, включая различные програм- мы сертификации профессионалов; • обширные области применения в современном обществе; • растущую популярность и значение. Часто у наших потенциальных заказчиков возникает простой вопрос глобального для профессионалов характера: «А зачем вообще нужно управлять проектами?» Надеемся, что часть ответа читатель найдет в оригинальном материале последующих глав нашей книги. А в этой главе процитируем результаты опроса, проведенного Volkswagen Coa- ching GmbH ProjektManagement. В опросе участвовал 261 профессио- нал из разных стран мира [76]. Причины для внедрения управления проектами опрошенные видят в: • возрастании сложности проектов — 27%; • увеличении числа проектов — 25%; • ужесточении требований к срокам — 23%; * конкуренции и требованиях рынка — 11%; • требованиях к качеству продукта — 9%; * мотивации персонала — 4%; • новом руководстве — 1%. На рисунке 1.3 представлены ключевые факторы успешного примене- ния современного управления проектами, по мнению тех же опрошен-
30 Глава 1 Организационная Программные средства Поддержка Практическое использование 27% Рисунок 1.3. Ключевые факторы успешного применения управления проектами ных. Интересно следующее: только 1% опрошенных полагают, что управление проектами внедряется из-за нового руководства, в то вре- мя как 37% опрошенных считают ключевым фактором успеха поддержку руководством внедрения управления проектами. Характерно также и то, что мотивация персонала — это определяющий фактор внедрения управления проектами по мнению только 4% опрошенных, а квали- фикация персонала залог успеха внедрения — по мнению 19% опро- шенных. И самое главное — программные средства назвали ключевым фактором успеха всего 5%, а практическое использование управления проектами — 27% опрошенных. Особое внимание в этой главе мы уделили тенденциям развития профессионального менеджмента проектов, стремясь показать практи- ческую ценность этой профессиональной дисциплины для современного бизнеса, общественного и государственного управления. В последу- ющих главах книги мы предметно, на конкретных «кейсах», покажем, как часть этих тенденций и в первую очередь такие, как расширение традиционных границ проекта, использование смежных методологий, проектный офис, управление портфелями и программами, нашли при- менение в нашей практической деятельности по реализации подходов современного менеджмента проектов в различных отраслях. Литература 1. Михеев В., Товб А. Стандарты для современных проектов // Директор ин- форм. службы. 2002. № 10.
Тенденции развития современного менеджмента проектов 31 2. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. 2-е изд. М.: ЗАО «Олимп—Бизнес», 2005. 3. PMI Project Management Fact Book. 2nd ed. Wiley, 2001. 4. Воропаев В. Управление проектами в современном обществе // Управле- ние проектами. 2005. № 1(1). 5. Товб А., Ципес Г. Управление проектами Ц Управленческий консультант. Настольная книга руководителя. Киев: ТзОВ «БУК,» 2005. 6. Товб А., Ципес Г. Управление проектами // ComputerWorld Россия. 2002. № 37. 7. Товб А., Ципес Г. Основные тенденции развития современного менеджмента проектов // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21-22 апреля 2004 г. М.: ФОСТАС, 2004. 8. Арчибальд Р. Управление высокотехнологичными программами и проекта- ми / Пер. с англ, под ред. А. Д. Баженова М.: ДМК Пресс, 2004. 9. Баркалов С., Воропаев В. и др. Математические основы управления проек- тами / Под ред. В. Н. Буркова М.: Высшая школа, 2005. 10. Разу М., Воропаев В. и др. Управление программами и проектами. 17-мо- дульная программа для менеджеров «Управление развитием организации». Модуль 8. М.: ИНФРА-М,1999. 11. Бовтеев С., Ефременко В., Рыбное Е., Фролов В. Управление проектами в строительстве. СПб.: С.-Петерб. гос. архитект.-строит, ун-т, 2004. 12. Мазур И., Шапиро В. и др. Управление проектами. Справочник для про- фессионалов. М.: Высшая школа, 2001. 13. Грей К., Ларсен Э. Управление проектами / Пер. с англ. М.: Дело и Сервис, 2003. 14. Грашина М., Дункан В. Основы управления проектами. СПб.: Питер, 2006. 15. Мартин П., Тейт К. Управление проектами / Пер. с англ. СПб.: Питер, 2006. 16. Дитхелм Г. Управление проектами / Пер. с нем. М.: Бизнес-пресса, 2005. 17. Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами / Пер. с англ. М.: Вильямс, 2003. 18. Руководство к Своду знаний по управлению проектами. 3-е изд. РМВОК® Guide. М.: р. m. Office, 2004. 19. Динамичный менеджмент проектов / Под ред. В. Михеева. Рукопись. 20. Turner R. Farsighted project contract management incomplete in its entirety // 17-й Всемир. конгресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 21. Dombkins D. Governance Contracting — Leading the Way // 17-й Всемир. кон- гресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 22. Ананьин В. Устойчивость управления П-проектами в условиях неопреде- ленности // Управление проектами. 2005. № 1(1)—2(2).
32 Глава 1 23, Ананьин В. Разработка и реализация корпоративной IT-стратегии как пере- говорный процесс // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС. 2004. 24. Ананьин В., Шишкин А. Контрактный подход в управлении ИТ-проекта- ми // 17-й Всемир. конгресс по управлению проектами, Москва. 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 25. Зиндер Е. Управление проектами создания систем электронной экономи- ки: особенности, возможности и стандарты // 17-й Всемир. конгресс по управлению проектами, Москва. 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 26. Охара Ш. Путем Р2М // Директор информ, службы. 2003. № 12. 27. Бредшие К. Р2М: по направлению к новой парадигме управления проекта- ми и программами // Управление проектами. 2005. № 3(3). 28. Chen Р., Partington D. How culture-sensitive is project management? A cor on of Chinese and Western project managers’ conceptions// 17-й Все игр :юн- гресс по управлению проектами. Москва, 4—6 июня 2003 г. М.: СОВНЕТ. 2003. 29. Mdkilouko М. Multicultural project management // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 30. Забродин Ю., Коликов В.. Саруханов А. Управление нефтегазостроительны- ми проектами. М.: Экономика. 2004. 31. Михеев В. Мужское и женское в проектах // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 32. Михеев В. Войны в проектах // Сб. трудов IV Всерос. практ. конф. «Стандар- ты в проектах современных информационных систем», Москва. 21—22 ап- реля 2004 г. М.: ФОСТАС, 2004. 33. ИСО/TQ 10006:1997 (Е). Менеджмент качества. Руководство качеством при управлении проектами (l-я ред. 15.12.1997 г.)./ Пер. с англ. ISO/TQ 10006:1997 (Е) (1st ed. 1998). М., 1999. 34. Уайдман М. Моделирование в управлении проектами // Управление про- ектами. 2005. № 1(1). 35. Алешин А., Воропаев В., Любкин С. и др. Управление проектами: Основы профессиональных знаний, национальные требования к компетентности специалистов по управлению проектами / Под науч. ред. В. И. Воропаева. М.: СОВНЕТ - КУБС, 2001. 36. Воропаев В., Секлетова Г. Системный подход к управлению проектами и программами // Управление проектами. 2005. № 3(3). 37. ICB-IPMA Competence Baseline Version 3.0. IPMA Ed. Committee: Caupin G., Knopfel H., Koch G., Pannenbacker K., Perez-Polo F., Seabury C. Van Haren Publishing, Zaltbommel-NL. 2006. 38. Бушуев С. Развитие систем знаний и технологий управления проектами // Управление проектами. 2005. № 2(2).
Тенденции развития современного менеджмента проектов 33 39. Крауфорд Л. Стандарты управления проектами: глобальная перспектива // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 40. Дункан В. Управление проектами: взгляд в будущее // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г. 41. Pells D., Mikheev V. Beyond maturity — how modern project management can turn dreams into reality ,// 19th IPMA World Congress, New Delhi, 13—16 No- vember 2005. 42. Пелле Д., Михеев В. «Третья волна» — новая управленческая парадигма профессионального Менеджмента проектов и программ. Как современ- ный Менеджмент проектов может преобразовать бизнес, организацию и людей // Управленческий консультант. Настольная книга руководителя. Киев: ТзОВ «БУК», 2005. 43. Пелле Д., Михеев В. «Третья волна» — новая парадигма менеджмента про- ектов // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17-18 мая 2005 г. 44. Михеев В. Н. Динамичный менеджмент проектов «Третьей волны» для управ- ляющих проектов и программ. Рукопись. 45. Saynisch М. Mastering complexity and changes in projects, economy and society by project management 2d order (PM-2) // 19th IPMA World Congress, New Delhi. 13-16 November 2005. 46. Huber T, Werner O. Reducing Project Complexity by a Morphological Approach // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 47. Rietiker S. Enterprise project orientation reconsidered elements of a project-con- scious management // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 48. Walker D. Norrie J. Using The Balanced Scorecard To Improve Project Manage- ment Practice // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 49. Ципес Г. Ключевые показатели деятельности в проектно-ориентированной компании // Директор информ, службы. 2003. № 5. 50. Anantatmula V. Improving the performance of project management through know- ledge management // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 51. Takinaka Е., Shinoda М., Toshinari S., Hasegawa К. Application of organization development to software process improvement in a major is industry in Japan. Detailed analysis of the results from ticket 21 // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 52. Kremser W. Project management — the way to process management? // 17-й Все- мир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003.
34 Глава 1 53. Fern Е. Six steps to the future. How mass customization is changing our world // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. 54. Gareis R. Business process management: a new dimension in the maturity model of the project-oriented company // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 55. Tsipes G., Tovb A. Processes and projects: there and back again // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 56. Ibbs C. W., Young-Hoon Kwak. The benefits of Project Management: financial and organizational rewards to corporations. Project Management Inst. Education Foundation, 1997. 57. Керцнер Г. Стратегическое планирование для управления проектами с ис- пользованием моделей зрелости / Пер. с англ. М.: Компания «АйТи»; ДМК Пресс, 2003. 58. Harpham A., Hinley D. Just how mature is your organization at Project Mana- gement? // 17-й Всемир. конгресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 59. Баженов А., Арефьев О. ОРМЗ: ожидания, факты, перспективы // Сб. тру- дов IV Всерос. практ. конф. «Стандарты в проектах современных инфор- мационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 60. Полковников А., Белозеров А. Модели оценки зрелости проектного менедж- мента в компании: опыт и перспективы применения для развития корпо- ративной системы управления проектами // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21-22 апреля 2004 г. М.: ФОСТАС, 2004. 61. Суркис А. Корпоративное управление проектами: основные участники внед- рения и поддержки // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 62. Мильман С., Самбук А. Количественное управление проектами // Сб. тру- дов IV Всерос. практ. конф. «Стандарты в проектах современных инфор- мационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 63. Crawford J.K. The Strategic project office. A guide to improving organizational performance. N. Y.: Marcel Dekker, 2002. 64. Кендалл Дж., Роллинз С. Современные методы управления портфелями проектов и офис управления проектами. Максимизация ROI / Пер. с англ. М.: ЗАО «ПМСОФТ», 2004. 65. Касаткин А. Управление проектами — решение проблемы взаимодействия и необходимое условие повышения эффективности бизнеса // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информаци- онных систем», Москва, 21-22 апреля 2004 г. М.: ФОСТАС, 2004. 66. Королев Д., Субботин А. Реализация интересов Заказчика в программах и проектах создания корпоративных информационных систем // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информаци- онных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004.
Тенденции развития современного менеджмента проектов 35 67. Гришина М.Н., Семенков И.Г. Организационно-структурные вопросы реа- лизации внутренних проектов организации // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 68. Ньюэлл М. Проектный офис // Директор информ, службы. 2002. № 1. 69. Сантосус М. Служебная дисциплина: зачем нужен проектный офис // Ди- ректор информ, службы. 2003. № 12. 70. Duncan W. Enhancing IT support for corporate strategy through project portfolio management // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 71. Самощенков С., СошнинА., Ципес Г. Программы и проекты в органах госу- дарственного управления // Сб. трудов IV Всерос. практ. конф. «Стандар- ты в проектах современных информационных систем», Москва, 21—22 ап- реля 2004 г. М.: ФОСТАС, 2004. 72. Ципес Г. Проекты, портфели проектов и программы на предприятиях топ- ливно-энергетического комплекса // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г. 73. Трубицын Ю., Полковников А. Построение системы управления корпора- тивной программой информатизации в интересах заказчика // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информаци- онных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 74. Кельманзон А., Зенин С., Каляное Г. Система управления программами ра- бот и ИТ-проектами НК ЮКОС // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТАС, 2004. 75. Dye L.D., Pennypacker J.S. Project portfolio management: selecting and prioritizing projects for competitive advantage. 1st ed. Center for Business Practices PM Solutions. West Chester PA. 1999. 76. Shmidt K. Project Management world study: international Project Management — state and trend. Volkswagen Coaching GmbH ProjektManagement, 2004. 77. Вигдорович M. Вопросы организации проектной работы в коммерческом (финансовом) учреждении // http://www.iteam.ru/articles.php?pid=6&tid= 2&sid=35&id=380. 78. Моррис П. Нерелевантность управления проектами как профессиональной дисциплины // Управление проектами. 2005. № 3(3). 79. Morris Р. How effectively can Project Management bodies of knowledge contribute to managing projects successfully? // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 80. Ohara S. Profiling mission driven management for complex projects or program. Explaining the new framework and its background // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 81. Танака X. Комплексное управление мультипроектами в подрядных орга- низациях // Управление проектами и программами. 2006. № 2(6).
36 Глава 1 82. Tanaka Н. The changing landscape of Project Management // Project Management World Today. 2005. March. 83. Воропаев В. Управление проектами в России. М.: Алане, 1995. 84. Любкин С., Товб А., Огнева М.А. 19-й Всемир. конгресс по управлению проектами IPMA-2005 // Управление проектами и программами. 2006. № 1(5). 85. Кох Дж., Кнопфель Г. Международные требования к компетентности спе- циалистов по управлению проектами: IPMA Competence Baseline (ICB), версия 3.0 // Управление проектами. 2006. № 3(7). 86. IBM и партнеры помогают управлять российским бизнесом — Opus Magnum Enterpise Management // Инновации в технологиях и бизнесе. IBM. 2006. № 1. 87. Пелле Д. 15-й Глобальный форум по управлению проектами // Управление проектами и программами. 2006. № 2(6).
Глава 2 Проекты и стратегия. Проекты, программы и портфели проектов на предприятиях топливно-энергетического комплекса
Содержание главы 2 2.1. Краткий обзор методологии............................................39 Проекты, программы и портфели проектов...............................39 Офис проекта.........................................................40 Стратегический офис проектов......................................41 Офис управления проектом..........................................43 Офис проектов подразделения.......................................43 Сбалансированная система показателей.................................44 2.2. Предприятие топливно-энергетического комплекса как проектно-ориентированная компания................................47 2.3. Управление комплексными проектами на добывающем предприятии ТЭК........................................47 2.4. Управление портфелями проектов на транспортном предприятии ТЭК......................................53 Проекты транспортного предприятия ТЭК................................53 Соответствие проектов стратегическим целям компании..................55 Цели и критические факторы успеха.................................55 Обеспеченность проектов ресурсами....................................56 Процедуры управления портфелем проектов..............................57 Процедура формирования портфеля проектов..........................57 Процедура мониторинга и анализа исполнения проектов...............59 Оценки и критерии....................................................61 Технический проектный офис...........................................65 2.5. Управление целевыми программами в управляющей компании холдинга ТЭК..................................66 Организационное планирование.........................................66 Формальная координация организационных мероприятий...................67 От координации — к управлению........................................69 Заинтересованные стороны в программе ......................................................... 72 Состав органов управления программой..............................74 Органы принятия технических решений...............................76 2.6. Резюме...............................................................77 Литература................................................................78
2.1. Краткий обзор методологии Проекты, программы и портфели проектов Контур управления проектами в современной компании, как правило, охватывает все основные горизонты планирования деятельности пред- приятия — стратегическое, среднесрочное (тактическое) и оператив- ное планирование. Оперативное планирование осуществляется на уровне отдельных мероприятий, которые могут быть объединены в проекты. Проекты, таким образом, рассматриваются как совокупности взаимосвязанных мероприятий, предназначенных для достижения поставленных целей с установленными требованиями к качеству результата в течение задан- ного времени и при фиксированном бюджете. Проект разбивается на стадии жизненного цикла, т. е. логически взаимосвязанные работы, в процессе завершения которых достигается один из основных результатов проекта. Жизненные циклы проектов в различных сферах деятельности су- щественно различаются. При определении стадий жизненного цикла проекта следует учитывать следующие соображения: • стадии жизненного цикла должны соответствовать принятым стандартам (международным, государственным, отраслевым) для проектов с подобными характеристиками; • каждая стадия жизненного цикла должна завершаться достиже- нием одного из основных результатов проекта, определенных в системе целей и результатов проекта; • разбиение на стадии должно обеспечить потребности в плани- ровании и контроле работ по проекту для всех подразделений и организаций, вовлеченных в проект. Группа проектов и различных мероприятий, связанных общей целью и условиями выполнения, может быть объединена в программу. Управле- ние проектами, объединенными в рамках одной программы, требует 39
40 Глава 2 координации по достигаемым результатам. Кроме проектов программа может включать элементы рутинной (операционной) деятельности. Формирование программ осуществляется на основе стратегического плана развития, включающего систему целей, количественные показа- тели достижения этих целей и мероприятия, позволяющие обеспечить достижение требуемых значений показателей. Примерами возможных программ служат мероприятия по совер- шенствованию системы управления предприятием в различных функ- циональных областях деятельности: • повышение эффективности производственных процессов; • совершенствование системы финансового управления; • оптимизация транспортной и складской логистики. Для удобства управления проекты могут объединяться не только в про- граммы, но и в портфели проектов. При этом в рамках одного порт- феля проекты могут быть не связаны по своим целям. Удобство управления может пониматься самым различным образом. Например, одним из возможных принципов образования портфелей является группировка проектов по исполняющим их подразделениям (управлениям, отделам). При этом достигается возможность более гиб- кого манипулирования человеческими ресурсами, поскольку они при- надлежат общему центру ответственности за все проекты портфеля и обладают близкими профессиональными компетенциями. Возможны и другие подходы к формированию портфелей проек- тов, например на основе общности применяемых инструментов и тех- нологий (например, изменение деловых процессов и процедур, изме- нение организационных структур, внедрение информационных тех- нологий). В этом случае возникает задача формирования центров ответственности за портфели проектов «поверх» постоянной организа- ционной структуры. Исходя из принятых в компании подходов к формированию про- грамм и портфелей определяется структура объекта управления в сис- теме управления проектами (СУП). Результаты этого структурирования позволяют определить, в состав какого портфеля и какой программы входит каждый проект (см., например, табл. 2.1). Офис проекта Сколько проектных офисов нужно вашей компании? Ответ на этот вопрос не столь очевиден, как может показаться на первый взгляд, поскольку за модным сегодня термином «проектный офис» (Project
Проекты и стратегия. Проекты, программы и портфели проектов... 41 Таблица 2.1. Структура портфелей и программ Программы Портфели^'''. проектов Повышение эффективности производственных процессов Совершенство- вание системы управления финансами Оптимизация транспортной и складской логистики Изменение деловых процессов и процедур Проекты Проекты Проекты Изменение организационных структур Проекты Проекты Проекты Внедрение информационных технологий Проекты Проекты Проекты Office) скрываются несколько разных понятий из области управления проектами. На рисунке 2.1 воспроизведена схема из книги К. Кроу- форда [1], на которой изображены основные типы офисов проектов. Стратегический офис проектов Основными задачами стратегического офиса проектов являются: • обеспечение трансляции стратегии компании на операционный уровень реализации изменений, • обеспечение эффективной реализации проектов компании. Чаше всего, говоря о проектных офисах, имеют в виду именно этот элемент организационной структуры компании (называемый иногда также Службой управления проектами), ориентированный на решение принципиальных вопросов в области корпоративного развития. На этот орган возлагаются обязанности по созданию и развитию корпоратив- ной культуры управления проектами, по управлению конкретными проектами, но главное — в его задачу входят обеспечение и контроль соответствия проектов, реализуемых в компании, ее стратегическим целям и ресурсным и техническим возможностям. Преимущества стра- тегического офиса достигаются за счет создания и использования еди- ной методологии и технологии управления всеми проектами компании. Подробнее о функциях и структуре стратегического офиса проекта можно прочесть в работах [2, 3].
42 Глава 2 Исполнительный директор Информа Спсозции ц1<онныс Финансы технологии Разработка Внедрение Поддержка Уровень 3 Стратегический офис проектов Уровень 2 Офис проектов подразделения (офис портфеля проектов) Уровень 1 Офисы управления отдельными проектами Рисунок 2.1. Проектные офисы в организационной структуре компании При всей очевидной полезности стратегического проектного офиса по этому поводу имеет смысл вспомнить предостережение М. Ньюэл- ла: «Общий офис проектов — это хорошая идея, но, как и все хорошие идеи, ее надо использовать осторожно. Мы не должны поддаваться на провокации внешне привлекательных идей, не должны создавать и использовать общий офис проектов за счет принесения в жертву само- стоятельности и независимости руководителей проектов. Главное — мы не должны забывать те коренные причины, которые привели к возникновению управления проектами как отдельной профессиональ- ной сферы деятельности» [4, с. 45]. И еще одно замечание по поводу стратегических офисов. Статисти- ка, приведенная в статье [5], показывает возрастание эффективности стратегических проектных офисов по мере их «возмужания». Однако эти данные относятся к компаниям, для которых проекты являются средством осуществления внутренних изменений и поэтому не состав- ляют существенной части ее деятельности. Для компаний же, осуще- ствляющих свою деятельность преимущественно в проектной форме, скорее, можно говорить об обратной тенденции, характерной, напри- мер, для крупных российских системных интеграторов. Проектный
Проекты и стратегия. Проекты, программы и портфели проектов... 43 офис, сыграв очень важную роль на начальном этапе становления кор- поративной культуры управления проектами, постепенно теряет свое значение. За проектным офисом остаются в основном функции учет- ного характера, а вся методологическая работа передается в службу качества. Различные формы проявления этой тенденции описаны в статье [6] на примерах компаний «АйТи», «Вымпелком» и др. Офис управления проектом Гораздо реже эксперты упоминают (но при этом гораздо чаще исполь- зуют) офисы отдельных проектов, под которыми подразумевается ин- фраструктура, включающая помещение, системы компьютерных, комму- никационных и информационных технологий, стандарты и регламен- ты, необходимые для реализации функций управления проектом и обес- печения конфиденциальности информации. Например, практика IBS состоит в том, что отдельный офис открывается для каждого крупного проекта, причем предпочтительно на территории заказчика. Такой под- ход, с одной стороны, дисциплинирует исполнителей, а с другой — повышает доверие заказчиков к проекту. Офис управления проектом является, таким образом, временной организационной структурой, соз- даваемой на период выполнения проекта. Об организации офиса управ- ления проектом можно подробнее прочесть, например, в работе [7]. Задача офисов управления проектами такая же, как и у стратегиче- ских офисов проектов: повысить эффективность выполнения проектов. Только механизмы повышения эффективности здесь другие. Преиму- щества офиса проекта достигаются за счет использования выделенного помещения, оргтехники и вспомогательного оборудования, благодаря чему все исполнители находятся рядом и под контролем, облегчается оперативное решение локальных вопросов и проблем, упрощаются ком- муникации внутри команды проекта. Офис проектов подразделения Еще один вид проектных офисов — это офисы, создаваемые для управ- ления группами проектов, выполняемых на общем пуле ресурсов (на- пример, проекты одного подразделения). Основная задача этих офи- сов — эффективное управление ресурсами подразделения, занятыми в реализации проектов: снижение продолжительности «ресурсных раз- рывов» — периодов нехватки ресурсов, снижение периодов простоя ресурсов. Офис проектов подразделения вполне может и не оформляться как организационная единица; в этом случае функции ресурсного плани- рования и учета затрат ресурсов распределяются между руководством подразделения, руководителями проектов и техническим персоналом подразделения.
44 Глава 2 Сбалансированная система показателей Успех реализации программ и портфелей проектов во многом зависит от того, насколько грамотно сформирован их состав. В качестве инст- рументов формирования программ и портфелей мы рассматриваем ключевые показатели деятельности (КПД) и методику Balanced Scorecard (BSC), подробно описанные, например, в работах [9—11]. Применение этих инструментов позволяет сформировать объектив- ную систему критериев и оценок и обеспечить координацию различ- ных уровней управления предприятием при принятии решений как в части текущей бизнес-деятельности, так и в части реорганизации дея- тельности предприятия. Такое использование КПД требует формирования системы целей предприятия. Применительно к методике сбалансированных показа- телей эти цели должны формулироваться в терминах бизнес-целей, критических факторов успеха, функциональных целей и мероприятий (действий), необходимых для достижения успеха. [Бизнес-цель] Бизнес-цели — приоритетные стратегические направления развития бизнеса пред- приятия, определяющие условия успешного его существования на рынке в сред- несрочной и долгосрочной перспективе. [Критический фактор успеха] Критический фактор успеха (КФУ, Critical Success Factor) соответствует той кон- кретной области деятельности предприятия, которая оказывает определяющее влияние на то, будет ли достигнута конкретная бизнес-цель. [Функциональная цель] Функциональные цели определяют направления развития предприятия на раз- личных уровнях управления в различных областях деятельности. Они позволяют конкретизировать и сбалансировать направления усилий с использованием раз- личных перспектив. Как правило, используются четыре перспективы — финансы, клиенты (внешние или внутренние), бизнес-процессы, инновации и персонал. [Стратегическая карта] Стратегическая карта — это графическое или табличное представление совокуп- ности бизнес-целей, КФУ и функциональных целей и связей между ними. [Ключевой показатель деятельности] Ключевой показатель деятельности (КПД — Key Performance Indicator, KPI) — коли- чественный индикатор, позволяющий измерять степень достижения успеха в кон- кретной области деятельности предприятия. Каждый КПД ставится в соответствие конкретной функциональной цели. [Целевое значение ключевого показателя деятельности] Целевое значение ключевого показателя деятельности — числовое значение КПД, фактическое достижение которого означает достижение успеха в соответству- ющей области деятельности в заданном временном периоде.
Проекты и стратегия. Проекты, программы и портфели проектов... 45 [Измеритель] Измеритель — это простой (обычно учетный) показатель, значение которого фор- мируется непосредственно при реализации бизнес-процессов и используется для вычисления одного или нескольких КПД. [Стратегические инициативы] Стратегическая инициатива соответствует конкретному мероприятию (или группе мероприятий), которое необходимо реализовать для того, чтобы было обеспе- чено достижение целевого значения одного или нескольких КПД. Построенное на основе перечисленных терминов дерево целей позво- ляет определить взаимосвязи КПД с различными уровнями управления предприятием (стратегическим, тактическим и оперативным). Общая модель этих взаимосвязей приведена на рисунке 2.2. Стратегический уровень Основные цели компании на текущем этапе ее развития бизнес-цели Тактический уровень Области деятельности компании, критичные с точки зрения достижения бизнес-целей Критические факторы успеха Показа гели достижения цели Ключевые показа гели деятельности Оперативный уровень Мероприятия, которые необходимо провести для достижения целевых значений КПД Действия Измерители Стратегические оценки Количественные индикаторы, позволяющие измерять степень достижения цели Тактические оценки Количественные агрегированные показатели, позволяющие анализировать текущую ситуацию в компании Оперативные оценки Корпоративная оперативная отчетность Бизнес-процессы Подразделения, функции, документы Проблемы Рисунок 2.2. Взаимосвязь КПД с различными уровнями управления
46 Глава 2 Таким образом, важнейшей составной частью стратегии развития бизнеса предприятия является определение для каждой из сформу- лированных целей ключевых показателей деятельности (КПД), с по- мощью которых: • анализируется динамика движения к этой цели; • устанавливается факт достижения цели. При проектировании КПД рекомендуется соблюдать следующие основ- ные принципы: • Набор КПД должен быть ограничен — не более двух-трех биз- нес-целей, не более трех-четырех КФУ на бизнес-цель и не бо- лее трех—шести КПД на КФУ. • Набор КПД должен быть сбалансированным, не должен замы- каться на одной области и должен охватывать как финансовые результаты, так и отношения с клиентами, производственную деятельность, обучение и развитие персонала. • Структура КПД должна обеспечивать возможность выбора уровня детализации или разреза представления информации. Для этого могут использоваться интегральные оценки, формируемые на основе многих, возможно, разнородных простых показателей (измерителей). Среди характеристик, которые должны быть определены для каждого показателя, следует выделить следующие: • алгоритм расчета (формула) с использованием измерителей; • оценочные шкалы (для показателей и/или измерителей, значе- ния которых определяются экспертным путем); • регламент вычисления измерителей и показателя в целом, вклю- чая период вычисления и привязку к конкретным функциям бизнес-процессов; • разрезы для анализа; • целевое значение показателя; • факторы влияния и риски, а также соответствующие им меро- приятия. Процедуры, связанные с получением значений измерителей, вычисле- нием КПД и формированием отчетов, должны быть встроены в биз- нес-процессы и привязаны к их конкретным шагам (функциям).
Проекты и стратегия. Проекты, программы и портфели проектов... 47 2.2. Предприятие топливно-энергетического комплекса как проектно-ориентированная компания Строго говоря, предприятия топливно-энергетического комплекса (ТЭК) нельзя считать проектно-ориентированными компаниями. Их деятельность, приносящая непосредственный доход предприятию (до- быча, транспортировка, переработка и распределение углеводородов), осуществляется в рамках технологических и деловых процессов, не требующих, как правило, применения проектного управления. Однако получение этих доходов невозможно без создания, поддержки и раз- вития необходимой инфраструктуры, включая скважины, хранилища, трубопроводы и т. д. Объем этих вспомогательных работ столь значи- телен, а влияние качества и своевременности их выполнения столь велико, что, на наш взгляд, современное предприятие ТЭК можно смело относить к классу проектно-ориентированных компаний. Невозможно в одной главе охватить все аспекты применения мето- дов проектного управления в таких гигантских корпорациях, какими являются, как правило, вертикально интегрированные холдинги ТЭК. Поэтому свою основную цель мы видим в рассмотрении типовых под- ходов к применению проектного управления на различных предприя- тиях ТЭК, основываясь на собственном опыте участия в подобных проектах. Мы выделили три основных направления анализа: • Предприятия ТЭК, занятые разведкой и добычей. Для этих пред- приятий наибольший интерес представляет тема управления комплексными проектами (например, поиск, разведка, обустрой- ство месторождения). • Транспортные предприятия ТЭК. Здесь принципиально важной является тема формирования оптимального портфеля инвести- ционных проектов и управления портфелями проектов (таких, как портфели ИТ-проектов, строительных проектов и т. д.) • Головная (управляющая) компания холдинга ТЭК. Для управ- ляющих компаний с точки зрения проектного менеджмента наи- более характерна деятельность по управлению целевыми про- граммами, реализуемыми в различных областях деятельности всех предприятий холдинга (например, сертификация предприятий холдинга по ISO 9000, внедрение унифицированных систем управления документами и т. д.). 2.3. Управление комплексными проектами на добывающем предприятии ТЭК Основные процессы предприятия ТЭК, занятого разведкой и добычей углеводородов, определяются жизненным циклом месторождения (см. рис. 2.3).
48 Глава 2 v:-- i. • - » .• iB • „ 1.. — геофизиче- — опреде- — опреде- — движение — останов ские работы ление ление нефти/газа скважины — моделиро- контуров, конфигу- от забоев — восстанов- вание мощности рации на поверх- ление — поисковое бурение месторож- дения размещения скважин, ность — подготовка территории — выработка очередности газа к транс- — оценка рекомен- бурения портировке запасов даций — установ- — останов — лицензиро- по вводу ление скважин вание — лицензиро- вание режимов работы — исследо- вания Рисунок 2.3. Жизненный цикл месторождения Внешний вид этого цикла порождает аналогии с жизненными цикла- ми других объектов (информационной системы, здания, продукта или услуги и т. д.), включающими: • инвестиционную стадию, направленную на создание объекта; • стадию эксплуатации объекта, направленную на извлечение до- хода; • стадию ликвидации объекта. Как правило, подавляющий объем работ на первой и третьей стадиях выполняется в проектной форме. Работы на второй стадии проводятся в основном в рамках соответствующих технологических процессов, однако значительный объем работ, связанных с реконструкцией, модер- низацией и ремонтом объекта, может и должен выполняться в проект- ной форме. Таким образом, жизненный цикл любого объекта (в том числе месторождения) может быть представлен как серия проектов, направленных на реализацию отдельных стадий, этапов и других более мелких элементов жизненного цикла. А если исходить из концепции девелопмента, то его можно представить даже одним так называемым развивающимся проектом [12]. Однако на этом аналогии с другими объектами и их жизненными циклами оказываются исчерпанными, поскольку масштаб работ, вы- полняемых добывающими предприятиями ТЭК, делает достаточно сложной и задачу объединения разнородных работ в проекты, и задачу организационного оформления этих проектов.
Проекты и стратегия. Проекты, программы и портфели проектов... 49 Примером комплексного проекта добывающего предприятия мо- жет служить совокупность работ, выполняемых при поиске нового месторождения. Основным содержанием этих работ является проведе- ние комплекса геолого-геофизических мероприятий, по результатам которых принимается решение о проведении дальнейших работ в соот- ветствии с жизненным циклом месторождения. Все эти мероприятия выполняются непосредственно командой проекта, основную часть кото- рой составляет экспедиция, проводящая собственно полевые работы. Однако основные процессы жизненного цикла месторождения невоз- можно реализовать без поддержки со стороны вспомогательных процес- сов. В частности, для комплексного проекта «Поиск месторождения» на его различных этапах придется привлекать специалистов в таких областях, как: • закупки и снабжение, • транспортное обеспечение, • управление кадрами, • построение и анализ моделей скважины, • проектирование и строительство, • юридическое обеспечение. Организационная структура предприятий ТЭК выстроена по функцио- нальному принципу, поэтому реализация процессов в этих областях осуществляется соответствующими профильными подразделениями предприятия. Это означает, что часть работ, непосредственно влия- ющая на успешность выполнения комплексного проекта, вынужденно выпадает из зоны влияния руководителя проекта, оставаясь при этом в зоне его ответственности. Организация этой части работ полностью является прерогативой функциональных руководителей соответству- ющих подразделений. Возможно (но не обязательно), эти работы, в свою очередь, будут организованы как проекты, которые станут под- проектами комплексного проекта «Поиск месторождения». Возможная декомпозиция работ комплексного проекта «Поиск мес- торождения» приведена на рисунке 2.4. Здесь комплексный проект разбит на пять последовательно выполняемых проектов — проведение геофизических работ, изучение нефтеносных (газоносных) зон, поис- ковое бурение, оценка запасов, лицензирование. Для каждого проекта выделено три категории работ: • работы, выполняемые непосредственно командой проекта (на- пример, региональные геофизические работы); • отдельные работы, выполняемые по поручению руководства проекта, профильными подразделениями, ответственными за
50 Глава 2 Проекты Лицензирование Подготовка документов 1 Экспертиза документов Оценка запасов Подготовка исходных данных Уточнение моделей Поисковое бурение , Подготовка площадей к бурению мто экспедиции Выделение транспорта Экспертиза договоров Формирование экспедиции Проектирование скважин Строительство скважин Изучение нефтеносных зон Проведение полевых работ МТО экспедиции । Выделение транспорта Формирование экспедиции Построение моделей Г еофизические работы Проведение полевых работ МТО экспедиции । Выделение транспорта Формирование экспедиции Комплексный проект РАБОТЫ Работы команды проекта Закупки и снабжение Транспортное обеспечение Юридическое обеспечение Управление персоналом Проектирование Стро ител ьство Моделирование иинецеЬ’еебЬ’оц Х1янч1гифоби raxoged MHHairata'cedti’ou Х1чнч1гифойи Hixaodu Рисунок 2.4. Состав работ комплексного проекта «Поиск месторождения»
Проекты и стратегия. Проекты, программы и портфели проектов... 51 соответствующий бизнес-процесс (например, заказ и доставка оборудования); • комплексы работ, которые выделяются в самостоятельные под- проекты и выполнение которых возлагается на профильные подразделения, ответственные за соответствующий бизнес-про- цесс, или субподрядчиков (например, построение моделей, проек- тирование, капитальное строительство). Таким образом, участниками комплексных проектов добывающего пред- приятия ТЭК являются многие подразделения, которые занимаются планированием проектов и подпроектов и контролем хода их реализа- ции, обеспечивают проекты финансовыми, материально-технически- ми и человеческими ресурсами, выполняют научно-исследовательские, опытно-конструкторские, проектно-изыскательские и строительные работы. В такой ситуации одним из ключевых элементов в организа- ции проекта является создание таких органов управления проектом, которые позволяют осуществлять планирование, мониторинг, конт- роль, анализ проекта и вырабатывать сбалансированные управленче- ские решения, учитывающие мнение всех заинтересованных сторон на разных уровнях ответственности. Один из вариантов подобной организационной структуры для про- екта «Поиск месторождения» показан на рисунке 2.5. Верхний уровень управления представлен куратором комплексного проекта, осуществляющим общее управление. Кураторами комплекс- ных проектов назначаются менеджеры верхнего звена — уровня на- чальника или заместителя начальника управления. Например, курато- ром комплексного проекта «Поиск месторождения» может быть назна- чен заместитель начальника Управления геологоразведочных работ. На этом уровне решаются вопросы взаимодействия проектной команды с подразделениями предприятия, вовлеченными в работы по проекту. Средний уровень управления представляет руководитель комплекс- ного проекта. Он осуществляет оперативное управление ходом проекта по всем его направлениям. Руководителями комплексных проектов назначаются сотрудники профильных подразделений компании, обла- дающие необходимыми навыками и компетенциями. Например, руко- водителем комплексного проекта «Поиск месторождения» может быть назначен один из ведущих сотрудников Отдела поисково-разведоч- ных работ. Нижний уровень управления представлен руководителями проектов, входящих в состав комплексного проекта. Они отвечают за выполне- ние конкретных работ и качество результатов. Руководителями этого уровня назначаются специалисты профильных подразделений компа-
52 Глава 2 Кур error комплексного проект»'* Рисунок 2.5. Органы управления комплексного проекта «Поиск месторождения»
Проекты и стратегия. Проекты, программы и портфели проектов... 53 нии, обладающие необходимыми навыками и компетенциями. Напри- мер, руководителем проекта «Поисковое бурение» может быть назна- чен один из ведущих сотрудников Производственного отдела бурения. Руководители проектов осуществляют непосредственное взаимодействие с профильными подразделениями предприятия и сторонними компа- ниями, вовлеченными в работу по проекту. Процессы и соответствующий им набор процедур управления про- ектами для добывающего предприятия ТЭК выглядят достаточно тра- диционными: • Запуск проекта — определение объема работ, формирование организационной структуры проекта, определение основных этапов проекта, формирование календарно-ресурсного плана, планирование контроля и отчетности. • Выбор подрядчика и заключение контракта (для работ, на вы- полнение которых привлекается сторонняя компания) — фор- мирование запроса на проведение работ, анализ предложений и выбор подрядчика, подготовка, согласование и утверждение контракта. • Мониторинг и анализ исполнения проектов — сбор информа- ции и формирование отчетов по объемам выполненных работ в натуральном выражении и в процентах к общему объему работ, по расходованию финансовых средств, по отклонениям по сро- кам и бюджету от планов. • Управление отклонениями — анализ, мониторинг и принятие решений по рискам, проблемам и изменениям в проектах. • Завершение проекта — анализ результатов проекта, расформиро- вание рабочих групп и административное завершение проекта. 2.4. Управление портфелями проектов на транспортном предприятии ТЭК Проекты транспортного предприятия ТЭК Деятельность транспортного предприятия ТЭК, выполняемая в проект- ной форме, может быть сведена к нескольким основным категориям проектов: • консалтинговый проект — разработка концепций, методик, орга- низационно-распорядительных и нормативно-методических до- кументов, реализация организационно-структурных изменений;
54 Глава 2 • ИТ-проект — разработка и внедрение информационных систем (инфраструктура, оборудование, программное обеспечение); • строительный проект — строительство, реконструкция и капи- тальный ремонт зданий и сооружений; • проект установки и наладки технологического оборудования; • учебно-образовательный проект — организация и проведение обучения сотрудников. Как правило, во всех этих проектах само предприятие выступает толь- ко в качестве заказчика, а функции исполнителя (и вместе с ними — основные обязанности по управлению проектами) передаются сторон- ним организациям-подрядчикам '. Поэтому для самого предприятия на первый план выходят вопро- сы, связанные с управлением портфелями проектов (см. рис. 2.6): • Формирование системы критериев и оценок для обеспечения жизнеспособного и сбалансированного портфеля проектов, учи- тывающего стратегические цели предприятия, инвестиционную привлекательность и риски проектов. • Формирование состава портфеля проектов на основании систе- мы критериев и оценок и с использованием формализованных процедур. • Мониторинг и анализ исполнения проектов и подготовка отче- тов и рекомендаций, относящихся к изменению как состава портфеля, так и системы критериев и оценок. Изменения в составе портфеля Формирование портфеля проектов Определение критериев и оценок Анализ и выработка рекомендации Изменения в системе критериев и оценок Рисунок 2.6. Процессы управления портфелем проектов 1 Безусловно, это не отменяет полезности и даже необходимости внедрения на транс- портном предприятии ТЭК методов проектного управления на уровне отдельных проектов.
Проекты и стратегия. Проекты, программы и портфели проектов... 55 Соответствие проектов стратегическим целям компании Цели и критические факторы успеха Учитывая тот факт, что главной целью транспортного предприятия ТЭК является организация надежной, бесперебойной и эффективной транс- портировки продукта, можно выделить два основных направления его развития (критические факторы успеха). • Производственный потенциал Повышение способности предприятия обеспечивать бесперебой- ную подачу продукта потребителям за счет снижения аварийно- сти, эффективного использования резервов, диспетчеризации транспортных потоков и внедрения передовых технологий. Сюда же могут быть отнесены вопросы, связанные с увеличением объ- емов транспортировки продукта за счет ввода новых мощно- стей, создания инфраструктуры и технических условий для по- требления продукта в регионе. • Организационный потенциал Повышение профессионального уровня управленческого и тех- нического персонала, рост его заинтересованности в общем успе- хе предприятия, а также освоение и внедрение современных управленческих технологий, включая ИТ-поддержку. В качестве основы для построения системы целей может быть исполь- зована методология BSC. Однако необходимо учитывать специфику транспортного предприятия, являющегося, как правило, дочерней ком- панией в холдинге. Эта специфика состоит в том, что, во-первых, фи- нансовые цели при всей их важности не являются определяющими для деятельности предприятия и, во-вторых, транспортное предприятие сла- бо связано с внешними клиентами (например, газотранспортное пред- приятие получает продукт от добывающего предприятия и передает его распределяющему предприятию — и все это происходит внутри холдинга). В силу этого наиболее приоритетными должны быть при- знаны цели в области бизнес-процессов и инноваций. Наличие системы целей, соответствующих этим целям показателей и стратегических инициатив, которые, собственно, и являются при- оритетными объектами инвестиций и позволяют решать целый ряд задач управления портфелем проектов, среди которых наиболее важными являются следующие: • упорядочение выделения инвестиций на различные цели биз- неса;
56 Глава 2 • получение обоснования того, что при существующих внутрен- них возможностях предприятия и внешних обстоятельствах пред- лагаемые инвестиционные программы и проекты могут быть реализованы; • исключение субъективности из процесса принятия решений по выделению инвестиций; • идентификация инвестиций, программ и проектов, которые следует ускорить, приостановить или прекратить; • обоснованное, оперативное балансирование и реструктурирова- ние портфеля инвестиционных проектов предприятия в случае возникновения соответствующих (прежде всего, экономических) предпосылок. Обеспеченность проектов ресурсами Важнейшей составляющей системы критериев и оценок является определение возможности обеспечить проекты необходимыми ресур- сами (финансовыми, человеческими, техническими, технологически- ми и т. д.). При решении данного вопроса, на наш взгляд, необходимо разделить ответственность за принятие решения по включению проек- та в портфель. За содержательную сторону вопроса (соответствие стратегии) должно отвечать то подразделение предприятия, в интересах которого реализу- ется проект, иначе — Функциональный заказчик. Именно Функцио- нальный заказчик должен обосновать необходимость реализации проек- та, подтвердить его соответствие стратегическим целям предприятия. За ресурсную сторону ответственность должно нести то профильное подразделение, которое будет реализовывать проект (своими силами или с привлечением сторонних исполнителей). Эта роль соответствует роли Генерального заказчика. В соответствии с этим разделением ответственности всю совокуп- ность инвестиционных проектов предприятия можно представить в виде матрицы (см. рис. 2.7). Каждый столбец содержит проекты, взаимо- связанные между собой общими целями программы развития пред- приятия. Каждая строка соответствует совокупности проектов, связан- ных между собой общими используемыми технологиями, компетенция- ми, людьми, — именно их мы и рассматриваем в качестве портфелей проектов 1. 1 Особенно важно, на наш взгляд, что при подобном подходе к формированию порт- фелей проектов достаточно четко может быть определен ответственный за весь портфель — конкретное управление или даже отдел предприятия.
Проекты и стратегия. Проекты, программы и портфели проектов... 57 Группировка и координация по целям — несет ответственность Функциональный заказчик Программы Портфели Повышение эффективности производственных процессов Совершенствование системы управления финансами Другие программы Строительные проекты Проекты Проекты Проекты ИТ-проекты Проекты Проекты Проекты Проекты обучения Проекты Проекты Проекты Консалтинговые проекты Проекты Проекты Проекты Проекты по оборудованию Проекты Проекты Проекты Рисунок 2.7. Структурированное представление проектов предприятия Процедуры управления портфелем проектов Все процедуры управления портфелем проектов так же, как и процеду- ры управления отдельными проектами, должны осуществляться в соот- ветствии с формализованной процедурой, входящей в состав операцион- ного стандарта управления проектами предприятия. Ниже приведены две основные процедуры этого раздела стандарта. Процедура формирования портфеля проектов В обобщенном виде процедура формирования портфеля проектов мо- жет включать следующие шаги (см. рис. 2.8). Шаг 1. Функциональный заказчик готовит Предложение о запуске про- екта. Предложение должно содержать описание целевых потребностей предприятия, ради которых выполняется проект, формальные требова- ния к продукту проекта (ИТ-системе, зданию или сооружению и т. д.), а также расчет оценок по всем критериям, приведенным ниже в таб- лице 2.2. Шаг 2. Представитель Генерального заказчика проводит экспертизу Предложения, продумывает основные концептуальные решения и сов- местно с Функциональным заказчиком уточняет оценки проекта.
58 Глава 2 Функциональный заказчик Рисунок 2.8. Процедура формирования портфеля проектов Шаг 3. Технический проектный офис 1 выполняет формальный конт- роль Предложения на соответствие его операционному стандарту пред- приятия. Шаг 4. Технический проектный офис вычисляет формальные ранги проектов, формирует сводный документ по всем Предложениям и пере- дает его лицу, принимающему решения (руководителю направления). 1 О Техническом офисе проектов см. ниже в данном разделе.
Проекты и стратегия. Проекты, программы и портфели проектов... 59 Шаг 5. Лицо, принимающее решение, визирует Предложение. Решение о запуске проекта может быть изменено после получения лимитов. Шаг 6. Технический проектный офис, получив решение о запуске про- екта, вносит всю необходимую информацию в информационную сис- тему календарно-ресурсного планирования. Шаг 7. Генеральный заказчик в рамках своих полномочий корректиру- ет свой портфель (по срокам и ресурсам) в соответствии с получен- ными лимитами. Процедура мониторинга и анализа исполнения проектов В обобщенном виде процедура мониторинга и анализа исполнения проектов включает следующие шаги (см. рис. 2.9). Шаг 1. Исполнитель (внешний или внутренний) готовит Отчет о ста- тусе проекта, содержащий информацию об объемах и стоимости вы- полненных работ. Исполнитель Рисунок 2.9. Процедура мониторинга и анализа проектов
60 Глава 2 Шаг 2. Представитель Генерального заказчика согласует Отчет и пере- дает его в Технический проектный офис для ввода в информационную систему (шаг 5). Шаг 3. В случае необходимости Генеральный заказчик оформляет Акты приемки-сдачи работ и передает их в Технический проектный офис для ввода в информационную систему (шаг 5) и в финансовую служ- бу для осуществления оплаты работ внешним исполнителям. Шаг 4. Финансовая служба осуществляет оплату выполненных работ внешним исполнителям. Шаг 5. Технический проектный офис вводит отчеты в информацион- ную систему. Шаг 6. Технический проектный офис формирует отчеты по отдельным проектам и сводные отчеты — по группам проектов в требуемых раз- резах. Традиционная отчетность по отдельным проектам включает: • объем выполненных работ в натуральном выражении и в про- центах к общему объему работ; • расходование финансовых средств; • отклонения по срокам и бюджету от планов. Отчетность по группам проектов может включать: • сводный отчет по использованию ресурсов в разрезе подразде- лений; • сводный отчет о выполнении различных портфелей проектов. В контексте стратегического менеджмента проектов отчетность долж- на содержать все показатели выполнения проектов, используемые для оценки их приоритетов. На основании анализа этих показателей могут быть изменены существенные параметры проектов, что, в свою оче- редь, может повлиять на их ранги. Все подобные решения, включая пересмотр рангов проектов и изменение состава портфелей проектов, должны приниматься в соответствии с формализованной процедурой управления отклонениями, входящей в состав операционного стандар- та управления проектами предприятия.
Проекты и стратегия. Проекты, программы и портфели проектов... 61 Оценки и критерии Для оценки проектов при принятии решений о начале или продолже- нии реализации проектов или их приостановки могут приниматься во внимание различные группы критериев. Приведем в качестве примера несколько групп критериев. Наиболее важной для транспортного предприятия ТЭК является группа стратегических критериев: • Соответствие целям предприятия — показывает, в какой степе- ни проект привязан к конкретным целям предприятия. Этот показатель может оцениваться через количество целей и их важ- ность. • Влияние — показывает, в какой степени данный проект оказы- вает влияние на достижение целей предприятия. Степень влия- ния определяется изменением значения ключевого показателя деятельности, соответствующего цели. Если таких целей и пока- зателей несколько, берется средневзвешенное значение. • Срочность — определяет период времени, по истечении которо- го последствия проблемы, решаемой данным проектом, станут критичными для деятельности предприятия. Вторая группа критериев относится к финансовой сфере. Здесь могут использоваться такие традиционные показатели, как период окупае- мости, чистая приведенная стоимость, доля инвестиций в общем ин- вестиционном портфеле и т. д. И наконец, третья важная группа — это рисковые критерии. Здесь необходимо выделить риски ограниченных ресурсов. Для некоторых видов проектов (например, для ИТ-проектов) весьма важными явля- ются также риски новизны предлагаемых решений и связанные с ними риски сопротивления внутри предприятия. Итоговый ранг проекта рассчитывается по формуле: Z (фхрф !=Нп где: К — вес критерия, Р — оценка критерия по пятибалльной шкале, i — порядковый номер критерия, п — количество критериев. Примеры описания критериев оценки проектов приведены в таб- лице 2.2.
Таблица 2.2. Описание критериев оценки проектов № (•) Критерий Вес критерия (К) Описание критерия Шкалы для оценок критерия (Р) Стратегические критерии 1 Соответствие целям предприятия 2 Привязывает проект к конкретным целям в стратегической карте предприятия 5 — соответствует трем и более целям 3 — соответствует двум целям 1 — соответствует одной цели 0 — не соответствует ни одной цели 2 Влияние 2 Показывает, в какой степени данный проект оказывает влияние на достижение целей предприятия. Степень влияния определяется изменением значения ключевого показателя деятельности, соответствующего цели. Если таких целей и показателей несколько, берется среднее значение 5 — повышает значение КПД более чем на 10% 4 — повышает значение КПД от 7 до 10% 3 — повышает значение КПД от 5 до 7% 2 — повышает значение КПД от 3 до 5% 1 — повышает значение КПД до 3% 0 — не повышает значение КПД 3 Срочность 3 Определяет период времени, по истечении которого последствия проблемы, решаемой данным проектом, станут критичными для деятельности предприятия 5 — до полугода 4 — от полугода до года 3 — от года до трех лет 1 — свыше трех лет 0 — проблемы не могут стать критичными Финансовые критерии 4 Период 1 Определяет период времени, за который чистый денежный поток сравняется с первоначальными инвестициями: [Период окупаемости] = = [Объем инвестиций в проект] / / [Ожидаемый ежегодный денежный приток (экономия)] 5 — до полугода 4 от полугода до года 3 — от года до двух лет 2 — от двух до трех лет 1 — от трех до пяти лет 0 — свыше пяти лет 5 Чистая приведенная стоимость (NPV) 1 Определяет прибыль за период с учетом текущей стоимости годовых чистых денежных притоков, рассчитываемой с применением коэффициента дисконтирования: [Чистая приведенная стоимость] ™ = Enot [Ожидаемый ежегодный денежный приток (экономия)]/] 1+ Е)* - - Xnot [Объем инвестиций в проект] / /(1+ Е)‘, где Е — коэффициент дисконтирования, t — количество лет 5 — NPV свыше 50 млн руб. 4— NPV от 10 до 50 млн руб. 3 — NPV от 5 до 10 млн руб. 2 NPV от 1 до 5 млн руб. 1 — NPV от 0 до 1 млн руб. 0 — NPV отрицательная 6 Доля инвестиций 3 Определяет стоимость проекта в процентах к общему объему инвестиций предприятия: [Доля инвестиций] = = [Объем инвестиций в проект] / / [Общий объем инвестиций] х 100% 5 — менее 3% 3 — от 3 до 10% 1 — от 10 до 20% 0 — более 20% Рисковые критерии 7 Конфликт ресурсов 1 Определяет время, на которое занимаются стратегические (ограниченные) ресурсы предприятия с интенсивностью более 50% 5 — до двух недель 3 — от двух до десяти недель 1 — от 10 до 25 недель 0 — более 25 недель
64 Глава 2 Таблица 2.2. (окончание) со н 2 го го I о Описание критерия Определяет вероятность того, что результаты проекта будет невозможно использовать из-за сопротивления различных категорий персонала предприятия по причинам изменения технологических и управленческих процессов, перераспределения сфер ответственности и влияния и т. д. Вес критерия (К) Cxi г- Критерий Риск новизны Сопротивление внутри предприятия № (i) со СП
Проекты и стратегия. Проекты, программы и портфели проектов... 65 Технический проектный офис Большой объем необходимых, но рутинных операций по поддержке управления портфелем проектов делает необходимым создание специа- лизированного подразделения, обеспечивающего поддержку деятельно- сти руководства проектов и рабочих групп — Технического проектного офиса (ТПО), Целью создания ТПО является организация инфраструктуры (вклю- чая помещение, системы компьютерных, коммуникационных и ин- формационных технологий, стандарты и регламенты), позволяющей реализовывать функции управления проектами и обеспечивать кон- фиденциальность информации. Далее в качестве примера приведено Положение о Техническом проектном офисе (упрощенный вариант). Положение о Техническом проектном офисе (ТПО) 1. Основные задачи ТПО В части централизованного планирования и контроля исполнения работ по раз- личным проектам: • Построение единой информационной модели, содержащей плановые показа- тели работ, фактические данные о ходе работ, документы, отражающие ре- зультаты или статус работы. • Обеспечение многопользовательского доступа к информации о ходе работ в соответствии с полномочиями пользователей. • Предоставление пользователям функциональных возможностей управления проектом, обеспечиваемых соответствующими пакетами прикладных программ. В части информационного сопровождения проектов: • Поддержка мониторинга хода работ по проектам. • Формирование единой базы данных документов и управление документами проектов. • Организация и поддержка электронного офиса как единой Intranet-сети, соз- дание и наполнение информационного портала проекта. В части нормативно-методического сопровождения проектов: • Разработка и согласование необходимых распорядительных документов, рег- ламентирующих деятельность участников проектов (положений, инструкций, процедур, шаблонов управленческих документов). • Поддержка регламентов деятельности и взаимодействия участников проектов, в том числе на уровне технологий управления деловыми процессами. 2. Организационная структура ТПО: • начальник ТПО; • системный администратор; • администратор информационного портала; • администратор системы управления проектом;
66 Глава 2 • аналитики; • операторы. 3. Должностные обязанности сотрудников ТПО Начальник ТПО руководит текущей работой и несет персональную ответствен- ность за деятельность офиса. В сферу его ответственности входят: • регистрация и отслеживание выполнения планов работ по проектам; • регистрация объемов выполненных работ; • подготовка отчетов о выполненных работах и информирование участников про- екта о ходе работ; • документирование и контроль проектных отклонений, включая риски, пробле- мы и изменения; • ведение библиотеки проекта, включая проектную и управленческую докумен- тацию, а также корреспонденцию; • решение вопросов материально-технического обеспечения ТПО. Системный администратор ТПО несет ответственность за работоспособность программно-аппаратного комплекса системы управления проектом. В его функ- ции входят: • создание учетных записей и паролей пользователей; • резервное копирование и восстановление баз данных. Администратор информационного портала несет ответственность за разра- ботку и функционирование порталов проектов. В его функции входят проектиро- вание содержания портала, разработка программного обеспечения, публикация информации. Примечание: позиции системного администратора и администратора информа- ционного портала могут быть переданы на аутсорсинг подразделениям или сто- ронним организациям, осуществляющим поддержку и сопровождение информа- ционных систем предприятия. Администратор системы управления проектами поддерживает общекорпора- тивную информацию в рамках системы — ресурсные пулы, перечни реализуемых проектов, архивы проектной документации и т. д. Аналитики ТПО отвечают за разработку и корректировку организационно-распо- рядительной и нормативно-методической документации проектов. Операторы ТПО обеспечивают ввод и корректировку информации по планам, отчетам и связанным документам. 2.5. Управление целевыми программами в управляющей компании холдинга ТЭК Организационное планирование Большинство российских холдингов ТЭК в настоящее время построе- но на принципах жесткого централизованного управления. Это делает похожей деятельность управляющей компании холдинга ТЭК (как по своей функциональной направленности, так и по форме реализации)
Проекты и стратегия. Проекты, программы и портфели проектов... 67 на деятельность федеральных министерств (комитетов, служб). Это относится и к используемому механизму управления целевыми про- граммами. Традиционно таким механизмом является организационное планирование, в ходе которого определяется совокупность мероприя- тий, которая и составляет целевую программу. Хорошо известны общие проблемы традиционных схем организа- ционного планирования: • Отсутствие единой методологии и технологии планирования порождает разрыв между стратегическим уровнем планирова- ния и уровнем конкретных мероприятий. Положения стратегий и программ неадекватно трактуются на уровне исполнителей. • Сложные структурные связи между мероприятиями делают сис- тему планов непрозрачной. Руководство холдинга не имеет воз- можности соотнести выполняемые работы с общей стратегией развития. • Показатели эффективности реализации программ носят фор- мальный характер, а процесс их вычисления является сложным и трудоемким. Наличие этих проблем приводит к снижению эффективное г.' управ- ления и контроля реализации целевых программ в целом и составля- ющих их мероприятий. Административный ресурс по управлению эти- ми процессами очень быстро оказывается исчерпанным. Это порож- дает необходимость разработки и применения специальных методов и средств для поддержки процессов планирования и контроля деятель- ности различных подразделений управляющей компании холдинга. Далее представлены два подхода к решению проблем организаци- онного планирования на уровне управляющей компании холдинга с применением традиционных методов управления проектами. Формальная координация организационных мероприятий Структура планов холдинга, как правило, охватывает несколько го- ризонтов планирования — оперативного, среднесрочного, стратеги- ческого — и замыкается на финансовых планах (пример возможной структуры планов приведен на рисунке 2.10). Процедура формирова- ния планов традиционно выглядит следующим образом: подготовка предложений — снизу вверх, доведение планов до исполнителей — сверху вниз. Отметим, что на пути предложений есть несколько про- межуточных инстанций, таких как Управление капитального строи-
68 Глава 2 Задачи на год Целевая прея рамма Г одовой финансовый план Уровень стратегического планирования Уровень ! среднесрочного планирования Уровень Полугодовой организационный план оперативного планирования Планы работы управлений Рисунок 2.10. Структура организационных планов тельства дочерней компании и профильное подразделение управля- ющей компании холдинга. Для поддержки работы всего этого механизма в управляющей ком- пании холдинга создается организационная структура, задачей которой является координация на постоянной основе всех проектов развития, планируемых и реализуемых в холдинге. Будем в дальнейшем называть эту структуру Координатором. На Координатора ложится ответствен- ность как за формирование плана организационных мероприятий, так и за контроль его исполнения. С точки зрения планирования организационных мероприятий Ко- ординатор решает следующие задачи: • сбор заявок на выполнение работ в рамках целевых программ развития; • формирование и взаимоувязка мероприятий планов разного уров- ня (вертикальные связи); • формализация и учет взаимосвязей различных мероприятий по срокам, ресурсам и т. д. (горизонтальные связи). С точки зрения контроля исполнения организационных мероприятий Координатор решает такие задачи: учет использования материальных, финансовых и человеческих ресурсов;
Проекты и стратегия. Проекты, программы и портфели проектов... 69 • оповещение о задержках, переносе сроков и выполнение других контрольных функций; • формирование текущей и аналитической отчетности. Процессы управления целевой программой могут быть описаны в виде совокупности регламентов и процедур, определяющих порядок дей- ствий и зоны ответственности должностных лиц, связанных с исполне- нием целевых программ (см. табл. 2.3). Для управления этими процес- сами могут использоваться традиционные средства календарно-ресурс- ного планирования, однако специальное внимание должно уделяться вопросам управления документами и соблюдению принятых деловых процедур. Отметим, что Координатор осуществляет только формальную под- держку процессов управления целевыми программами, не вникая в содержательную сторону вопросов и не принимая управленческих ре- шений. С точки зрения современного менеджмента проектов такой подход может показаться архаичным. И тем не менее эта традицион- ная управленческая культура органов государственного управления является весьма живучей и, насколько нам известно, продолжает ис- пользоваться в современных компаниях ТЭК. Но все это не отменяет необходимости управления целевыми программами по существу. К рас- смотрению этого вопроса мы и переходим. От координации — к управлению Чтобы проиллюстрировать методы, которые могут применяться в хол- динге для управления целевыми программами, рассмотрим в качестве примера целевую программу создания корпоративной интегрированной информационной системы, охватывающей различные функциональ- ные направления деятельности и различные уровни управления. Целевая программа создания корпоративной интегрированной информационной системы Структура системы включает две группы компонентов: • взаимосвязанные функциональные (специализированные) прикладные подсис- темы, обеспечивающие решение прикладных задач в деятельности холдинга (соответствующие проекты представлены на рисунке 2.11 в качестве вертикаль- ных составляющих структуры программы); • инфраструктурные компоненты (сети, коммуникации, программная, информа- ционная и организационная инфраструктура) (соответствующие проекты пред- ставлены на рисунке 2.11 в качестве горизонтальных составляющих структуры программы).
Таблица 2.3. Регламент управления целевой программой Уровень Подразделение — Стратегическое планирование Среднесрочное планирование Оперативное планирование Исполнение и контроль Руководство холдинга • Согласование и утверждение целевой программы • Согласование и утверждение плана на год • Анализ эффективности исполнения целевых программ и мероприятий Координатор программы • Формирование целевой программы • Формирование проекта плана на год • Формирование проектов полугодового плана • Взаимоувязка планов разного уровня • Контроль исполнения работ • Подготовка сводных и аналитических отчетов для руководства холдинга Ответственный исполнитель • Подготовка предложений к целевой программе • Подготовка предложений к плану на год • Подготовка предложений для полугодового плана • Подготовка отчетов по выполненным работам Исполнитель • Детальное планирование • Исполнение работ • Фиксация факта и объема выполнения работ Специализированные проекты Система управления проектами /' Корпора- тивный банк данных Интеграционных проект Интеграционный проект Интеграционный проект Интеграционный проект Интеграционный проект Бухгалтерский учет Интеграционный ) (Интеграционный проект проект у Интеграционный проект Экономика и финансы Интеграционный проект Интеграционный )/ Интеграционный проект проект Интеграционный ц Интеграционный) (Интеграционный )( Интеграционных проект АД. проект проект z Интеграционный) Г Интеграциог проект проект Материально- технические ресурсы Поставки Геология и геофизика Оперативно- диспетчерское управление Системо- технический проект Рисунок 2.11. Структура целевой программы
72 Глава 2 Функциональные подсистемы не вступают в непосредственное взаимодействие между собой. Эффект единой системы достигается через интеграцию функцио- нальных подсистем в общую инфрастуктуру. Задачи интеграции решаются путем создания ряда специальных (интеграционных) компонентов. В рамках соответ- ствующих проектов разрабатываются механизмы взаимодействия локальных ин- формационных и технических компонентов, используемых в функциональных под- системах, и общей инфраструктуры. Интеграционную пару составляют функциональная подсистема и инфраструк- турная подсистема: • Интеграция функциональной подсистемы в информационную инфраструктуру предполагает определение состава данных, которыми обмениваются функцио- нальная подсистема и корпоративный банк данных, а также разработку меха- низмов этого обмена. • Интеграция функциональной подсистемы в системотехническую инфраструк- туру предполагает определение моделей и протоколов передачи информации, стыковку информационных потоков, согласование вопросов функционирова- ния отдельных общесистемных компонент и прикладных сервисов. • Интеграция функциональной подсистемы в организационную инфраструктуру предполагает разработку необходимых отраслевых стандартов и руководящих документов, формирование организационных структур управления проектом, ор- ганизацию их взаимодействия с аналогичными структурами по другим проектам, организацию согласованного планирования и контроля исполнения работ. Интеграционные проекты представлены на рисунке 2.11 как элементы пересече- ния функциональных и инфраструктурных проектов. Стратегия создания системы состоит в параллельном и согласованном по- строении функциональных подсистем и развитии ее инфраструктуры. Полный цикл разработки функциональной подсистемы включает выполнение проекта по раз- работке собственно функциональной подсистемы (функциональный проект), а также выполнение проектов по ее интеграции в организационную, информаци- онную и системотехническую инфраструктуры (интеграционные проекты). Реализация функциональных проектов, как правило, включает три стадии — научно-исследовательские работы (НИР), опытно-конструкторские работы (ОКР) и проектно-изыскательские работы (ПИР). Для ускорения работ возможно и даже целесообразно «перекрытие» этих стадий по срокам выполнения. На рисунке 2.12 показана возможная схема синхронизации проектов, связанных по времени до- стижения тех или иных результатов. Столь развернутый пример приведен с единственной целью — пока- зать, что проблемы, возникающие при реализации масштабных про- грамм, вряд ли можно решить путем формальной раздачи поручений и проставления «галочек». Заинтересованные стороны в программе Сложности управления подобными программами, прежде всего, свя- заны с большим количеством заинтересованных сторон, выполняющих различные роли в проектах программы. Можно выделить несколько типовых ролей участников проектов: • Инвесторы — финансируют программу. • Генеральный заказчик — осуществляет заключение договоров с Исполнителями на выполнение работ по проекту, учет и конт-
Проекты и стратегия. Проекты, программы и портфели проектов... 73 Системнотехническая интеграция 2006 г. Разработка функциональной подсистемы Организационная интеграция |( Интеграция функциональной подсистемы i (интеграционные проекты) i Информационная интеграция 2005 г. Рисунок 2.12. Принципиальная схема синхронизации функциональных и интеграционных проектов роль хода работ, оценку качества результатов работ в соответ- ствии с условиями договоров, а также приемку работ и доку- ментации. Функциональные заказчики — определяют содержательную по- становку задач проекта, осуществляют консультирование по этим
74 Глава 2 задачам в ходе выполнения проекта и участвуют в согласовании и приемке результатов работ Исполнителей. • Исполнители — сторонние организации или подразделения пред- приятий холдинга, выполняющие работы по проекту. • Эксплуатирующие организации — подразделения управляющей компании или дочерних предприятий холдинга, принимающие в эксплуатацию компоненты системы. Рассмотренный в данном разделе пример посвящен программе созда- ния корпоративной информационной системы. Практика показывает, что реализация подобных проектов неизбежно нарушает сложившийся баланс интересов различных подразделений предприятия. (То же са- мое можно сказать о любой масштабной программе преобразований, приводящих к серьезным изменениям системы управления компании.) Попытка изменения этого баланса в ту или иную сторону в приказном порядке, как правило, к успеху не приводит, поскольку не заинтересо- ванные в успехе стороны имеют достаточно возможностей для сколь угодно долгого затягивания процесса. Поэтому должен быть предусмотрен механизм, обеспечивающий выработку и реализацию сбалансированных управленческих решений на всех уровнях управления программой. В качестве такого механизма может выступать специально создаваемая иерархическая организаци- онная структура управления программой, в которой представлены все заинтересованные участники проектов. Состав органов управления программой При формировании органов управления программой необходимо со- блюдать следующие принципы: • В органах управления программой должны быть представлены все заинтересованные участники программы как со стороны пред- приятия, так и со стороны Подрядчика. • Статус должностных лиц, делегируемых в органы управления проектами, должен быть достаточным для принятия решений, необходимых для выполнения той проектной роли, на которую назначено конкретное должностное лицо (Директор проекта, Руководитель проекта, Координатор и т.д.). Принципы формирования организационных структур программы, учи- тывающие необходимость сбалансированного представительства всех участников программы, проиллюстрированы в таблице 2.4. Принципы
Проекты и стратегия. Проекты, программы и портфели проектов... 75 Таблица 2.4. Принципы формирования органов управления программами Уровень управления Участники Уровень стратегического руководства (Руководящий комитет) Уровень оперативного управления (Группа управления) Уровень технического руководства Инвестор Совет директоров Председатель Руководящего комитета — — Генеральный заказчик Куратор Директор проекта Руководитель проекта от Заказчика Координатор проекта Руководители групп Функциональные заказчики Подразделения, в интересах которых реализуется проект Члены Руководящего комитета Эксперты Эксперты Подрядчики Генеральный подрядчик Директор проекта от Подрядчика Руководитель проекта от Подрядчика Главный конструктор Руководители групп Специалисты Субподрядчики Главные конструкторы Руководители направлений Специалисты Эксплуатирующие организации Подразделение Заказчика — Эксперты подбора должностных лиц на проектные роли в соответствии с необхо- димым статусом в различного типа проектах проиллюстрированы в таблице 2.5.
76 Глава 2 Таблица 2.5. Статус должностных лиц, входящих в органы управления программой Роль в проекте Сложность проекта Высокая Средняя Низкая Член Управляющего совета Топ-менеджер Заместитель начальника управления — Директор проекта Топ-менеджер Начальник отдела Начальник отдела Руководитель проекта Начальник отдела Заместитель начальника отдела Главный специалист Координатор Старший Старший Старший проекта инженер инженер инженер Руководитель группы Главный специалист Главный специалист Эксперт Ведущий специалист Специалист Специалист Деятельность организационных структур программ и проектов и отдельных должностных лиц, участвующих в них, должна быть регла- ментирована приказами, положениями, инструкциями и другими организационно-распорядительными документами, типовые варианты которых следует включить в операционный стандарт управления про- ектами и программами предприятия. Органы принятия технических решений Самостоятельную проблему представляет необходимость постоянного согласования решений технического характера, принимаемых при раз- работке отдельных компонентов системы. Здесь может оказаться недо- статочным согласование решений на уровне различных разработчиков (Совета Главных конструкторов). В тех случаях, когда принимаемые решения должны быть согласованы с общекорпоративными решения- ми в области информационных технологий, для их экспертизы может привлекаться постоянно действующий в холдинге или специально соз- данный Экспертный совет (или его аналог). Экспертиза качества предла- гаемых проектных решений может проводиться на этом уровне также и при возникновении конфликтных ситуаций. Обе взаимосвязанные вертикали принятия решений представлены на рисунке 2.13. Отметим, что в рамках этой структуры есть место и
Проекты и стратегия. Проекты, программы и портфели проектов... 77 Рисунок 2.13. Организационная структура управления целевой программой для Координатора, который может исполнять функции Технического проектного офиса при Руководящем комитете программы. Некоторые специальные моменты, связанные с формированием организационных структур управления проектами и программами, можно также найти в работах [3, 13]. 2.6. Резюме Мы рассмотрели несколько примеров применения методов управле- ния проектами на предприятиях ТЭК. У каждого из этих предприятий есть особенности, определяющие те или иные приоритеты при внедре- нии управления проектами. Принципиально важным вопросом управления проектами добыва- ющего предприятия ТЭК является структуризация работ с целью пра-
78 Глава 2 вильного формирования комплексных проектов, проектов и подпро- ектов и определения ответственных лиц и правил их взаимодействия при реализации проектов. В то же время процедурные вопросы управ- ления проектами могут быть решены в рамках традиционных подходов к формированию операционного стандарта управления проектами пред- приятия (см., например, [3]). Для транспортного предприятия ТЭК приоритетными являются вопросы управления портфелями проектов. Их решение возможно толь- ко с использованием механизмов стратегического управления пред- приятием, позволяющих принимать обоснованные решения по фор- мированию портфелей инвестиционных проектов. Соответственно, операционный стандарт управления проектами транспортного пред- приятия ТЭК кроме традиционных разделов, связанных с управлени- ем отдельными проектами, должен содержать регламенты формирова- ния и мониторинга портфеля проектов, а также описание критериев оценок проектов. Наконец, приверженность идеологии жесткого централизованного управления в холдингах ТЭК делает необходимым использование в управляющих компаниях современных методов управления целевыми программами. При этом возникает опасность конфронтации этих ме- тодов с традиционной культурой организационного планирования. Возможные решения данной проблемы лежат в области организации и разумной регламентации совместной деятельности всех заинтересован- ных участников проектов и программ. Отметим, что к теме управления целевыми программами мы еще вернемся в главе 6 этой книги. Литература 1. Crawford J. К. The Strategic Project Office. N. Y.: Marcel Dekker, 2002. 2. Кендалл Дж., Роллинз С. Современные методы управления портфелями проектов и офис управления проектами. Максимизация ROI / Пер. с англ. М.: ЗАО «ПМСОФТ», 2004. 3. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003. 4. Ньюэлл М. Проектный офис // Директор информ, службы. 2002. № 1. 5. Сантосус М. Служебная дисциплина: зачем нужен проектный офис // Ди- ректор информ, службы. 2003. № 12. 6. Антропова Т. Проект как форма жизни // BusinessWeek Россия. 2005. № 4, 17 октября. 7. Мазур И., Шапиро В. и др. Управление проектами. Справочник для про- фессионалов. М.: Высшая школа, 2001. 8. Ципес Г. Сколько проектных офисов нужно вашей компании // Директор информ, службы. 2003. № 12.
Проекты и стратегия. Проекты, программы и портфели проектов... 79 9. Каплан Р., Нортон Д. Сбалансированная система показателей. М.: ЗАО «Олимп—Бизнес», 2003. 10. Каплан Р., Нортон Д. Организация, ориентированная на стратегию. М.: ЗАО «Олимп—Бизнес», 2004. 11. Каплан Р., Нортон Д. Стратегические карты. М.: ЗАО «Олимп—Бизнес», 2005. 12. Забродин Ю., Коликов В., Саруханов А. Управление нефтегазостроительны- ми проектами. М.: Экономика, 2004. 13. Циперман Г. Н., Ципес Г. Л. Проектное управление для СЕО. Практические рекомендации // iBUSINESS. 2001. № 2. 14. Самощенков С., Сошнин А., Ципес Г. Программы и проекты в органах госу- дарственного управления // Сб. трудов IV Всерос. практ. конф. «Стандар- ты в проектах современных информационных систем», Москва, 21—22 ап- реля 2004 г. М.: ФОСТАС, 2004. 15. Ципес Г. Проекты, портфели проектов и программы на предприятиях топ- ливно-энергетического комплекса // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17-18 мая 2005 г. 16. Ципес Г. Предприятие ТЭК как проектно-ориентированная компания // Директор информ, службы. 2005. № 11.

Глава 3 Проекты и процессы. Оператор связи как проектно-ориентированная компания
Содержание главы 3 3.1. Краткий обзор методологии.............................................83 Процессы и проекты — туда и обратно...................................83 Процессы как проекты..................................................84 Проекты как процессы..................................................89 Гармонизация процессного и проектного подходов в деятельности компании.............................................91 Этап 1. Структурирование операционной деятельности компании...............................92 Этап 2. Создание механизмов реализации процессов в проектной форме..............................92 Этап 3. Создание механизмов унифицированного выполнения проектов................................93 Выводы................................................................94 3.2. Причины и предпосылки внедрения проектного управления в телекоммуникационной компании.......................................94 3.3. Особенности организации проектов подключения..........................98 Перераспределение ответственности.....................................98 Формирование проектных групп.........................................100 Система мотивации....................................................102 3.4. Управление проектами подключения.....................................105 Формализованная среда управления проектами...........................105 Процедуры управления проектами.......................................106 Шаблоны управленческих документов .................................. 115 3.5. Критерии оптимизации процессов подключения.......................... 119 «Как покончить с нехваткой монтеров?»................................120 3.6. Дальнейшее развитие проектного подхода...............................124 От проектов подключения — к проектам обслуживания запросов............124 У..................................ровень первичной обработки запросов..............................124 У ровень инициализации проектов ..................................................................... 125 У...........................................ровень исполнения проектов.......................................125 Стратегия внедрения проектного подхода...............................126 Литература................................................................128
3.1. Краткий обзор методологии Процессы и проекты — туда и обратно Сегодня распространены два основных взгляда на проекты в компа- нии: проекты как форма осуществления основной деятельности ком- пании и проекты как эффективная форма реализации изменений в компании. Соответственно, и компании можно разделить на проект- но-ориентированные, реализующие свою основную деятельность в фор- ме коммерческих проектов, и не проектно-ориентированные, которые если и используют проекты, то в основном как инструмент внутрен- него развития. Однако такое разделение является достаточно условным, посколь- ку, пытаясь повысить эффективность тех или иных операций, ком- пания стихийно приходит к замене регулярных процессов проектами (к сожалению, часто в суррогатных формах). И наоборот, пытаясь по- высить эффективность реализации проектов, компания приходит к взгляду на проект как на типовой регулярно повторяющийся процесс, который может быть стандартизован, несмотря на уникальные цели и условия его реализации. Таким образом, можно отметить следующие, на наш взгляд, неиз- бежные тенденции в деятельности самых разных компаний: • В определенный момент может возникнуть необходимость рас- сматривать любой процесс как проект. Примеры: пилотные прогоны новых процессов или процессов, видоизменившихся после реинжиниринга; опасность срыва срока выполнения опе- раций при высокой цене потерь; обслуживание запросов VIP-кли- ентов и т. д. • У любой компании, реализующей проекты, рано или поздно возникает потребность представления проекта как унифициро- ванного процесса, связанная с необходимостью стандартизации подходов к выполнению разнотипных и разномасштабных про- ектов и повышения их эффективности. 83
84 Глава 3 Однако процессный и проектный подходы предъявляют разные, часто противоположные требования к различным аспектам системы управ- ления компанией, таким как организационная структура, учетная по- литика, персонал, система мотивации и т. д., что создает серьезные барьеры на пути эффективного управления проектами компании. Гармоничное совмещение процессного и проектного подходов тре- бует от компании определенного уровня зрелости, поскольку, как мы увидим далее, такое совмещение возможно только на базе целой сис- темы формализованных стандартов и внутрикорпоративных отноше- ний. Это, в свою очередь, означает появление у компании как немед- ленных расходов на реорганизацию системы управления компании, так и последующих расходов на «владение» двумя параллельными (про- цессным и проектным) контурами управления. Идти или не идти на эти расходы — это, на наш взгляд, не вопрос области деятельности компании или ее размера. Это вопрос долго- срочной стратегии развития компании, цена которого — эффектив- ность бизнеса и возможность успешного существования компании на рынке. Данная глава посвящена анализу возможностей совмещения про- цессного и проектного подходов в организации деятельности компании и практическим аспектам их гармонизации. Процессы как проекты Прежде всего убедимся в том, что сама постановка вопроса о реали- зации процессов в проектной форме не лишена смысла. Для этого рассмотрим классификацию бизнес-процессов, построенную на двух основаниях: возможности изменения продуктовой линейки компании и возможности «настройки» продуктов под требования потребителя (см. рис. 3.1). В соответствии с этой классификацией выделим четыре основные группы процессов и проиллюстрируем на примерах возмож- ности применения проектов при исполнении этих процессов. Сегмент 1. Ограниченные возможности изменения продуктовой ли- нейки и «настройки» продуктов. В этот сегмент помещены компании, производящие продукт, ори- ентированный на удовлетворение неизменной, возникающей много- кратно потребности. Процессы выстраиваются в соответствии с техно- логией производства и являются уникальными для каждого бизнеса. Границы процессов в основном определяются положениями о подразде- лениях. На рисунке 3.2 подобные процессы рассматриваются на примере таксопарка.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 85 Возможность «настройки» продуктов под потребителя Рисунок 3.1. Классификация бизнес-процессов Обеспечение \ Поддир* агие закупки \ гохни-к ского комплектующих) сос-ояния и расходных / ппока материалов / , .томобильи * -------------/ Нрг.ем и обслужи• 83НИС заказов Процессы, в которых возникает потребность в проектном управлении Рисунок 3.2. Бизнес-процессы таксопарка Как правило, в рамках этих процессов решаются рутинные повто- ряющиеся задачи. Однако можно смело предположить, что осущест- вление сложного ремонта или обслуживание важного клиента вполне может потребовать изменения устоявшихся процедур и тогда возник- нет необходимость организации проекта.
86 Глава 3 Критерием выбора формы деятельности (процессной или проектной) в этих случаях должна быть экономическая целесообразность. В расчет должны приниматься и возрастающие при применении проектного подхода затраты, и возможная упущенная выгода при срыве работ или потере клиента. Сегмент 2. Ограниченные возможности изменения продуктовой ли- нейки и значительные возможности «настройки» продуктов. В этот сегмент, прежде всего, попадают компании, производящие продукт, потребление которого носит растянутый во времени, возоб- новляемый характер. Эти компании стремятся как можно более полно удовлетворять требования конкретных клиентов, поэтому бизнес-про- цессы ориентированы на поддержание отношений с клиентом и носят сквозной характер. Структура процессов практически не зависит от вида бизнеса. Границы процессов определяются стадиями взаимоотно- шений с клиентами. На рисунке 3.3 подобные процессы проиллюст- рированы на примере оператора связи. Здесь целесообразность применения проектного подхода, так же как и в предыдущем случае, связана с технической сложностью решае- мой задачи и значимостью клиента. Во многих случаях, особенно при работе с корпоративными клиентами, и подготовка контракта, и его реализация, и последующая работа с запросами и претензиями сущест- венно более эффективно могут осуществляться в проектной форме (см. подробнее в работах [3, 4]). Сегмент 3. Значительные возможности изменения продуктовой линей- ки и ограниченные возможности «настройки» продуктов. В этот сегмент входят компании, оперативно реагирующие на из- менения спроса и адаптирующие свою продуктовую линейку к реаль- ным требованиям рынка в целом. Бизнес-процессы соответствуют Рисунок 3.3. Бизнес-процессы оператора связи
Проекты и процессы. Оператор связи как проектно-ориентированная компания 87 жизненному циклу продукта, поэтому структура процессов не зависит от вида бизнеса. На рисунке 3.4 эти процессы проиллюстрированы на примере авиаперевозчика, продуктами которого являются перевозки пассажиров по определенным маршрутам. Применение проектного подхода может оказаться целесообразным на всех этапах жизненного цикла, связанных с разработкой и внедре- нием продукта (т. е. за исключением продаж и сопровождения). Сегмент 4. Значительные возможности изменения продуктовой линей- ки и «настройки» продуктов. В этот сегмент попадают компании, ориентированные на создание уникального продукта для каждого клиента, как используя имеющуюся продуктовую линейку, так и дополняя и развивая ее. Бизнес-процессы соответствуют жизненному циклу создаваемого объекта (информаци- онной системы, сооружения и т. д.). На рисунке 3.5 эти процессы про- иллюстрированы на примере строительного объекта. Как правило, компании данного сегмента являются проектно-ориен- тированными, т. е. значительную часть своей деятельности осуществля- ют в проектной форме, а все этапы жизненного цикла объекта, за исклю- чением эксплуатации, объединяются в один или несколько проектов. Все рассмотренные группы процессов представляются нам доста- точно универсальными L Действительно, с точки зрения структуры процессов (и возможностей применения проектного подхода) таксо- парк вполне можно заменить гостиницей, оператора связи — пенси- онным фондом, авиаперевозчика — разработчиком стандартного про- граммного обеспечения. Можно сделать и еще более сильное утверждение: в деятельности каждой компании в той или иной степени присутствуют несколько, а то и все четыре рассмотренные группы процессов. Поясним это утверждение на примере многопрофильных ИТ-компаний. Процессы первой группы характерны для всех ИТ-служб в той части их обязан- ностей, которая относится к сопровождению и поддержке функцио- нирования информационных систем. Процессы второй группы — для подразделений, предоставляющих услуги аутсорсинга в области ИТ. Подразделения, специализирующиеся на производстве стандартного программного обеспечения, используют процессы продуктового цик- ла. И наконец, системные интеграторы обычно ориентируют свои биз- нес-процессы на жизненный цикл информационных систем. 1 Авторы не стремились к исчерпывающему охвату всех возможных видов процессов и сознательно ограничились рассмотрением только тех процессов, в которых реа- лизуется основная деятельность компаний.
88 Глава 3 2 s S. s х га 4 х S о а Ё X X X “ о g ф О (П аз га S о $п. ф I «Л» с с о Q. X 'Г q * С с а аз §2 л о О а S о с X к СС X га 3^ I * X X X & о ® О а ° с ГОрЫХ Е О s к ф ; s s .. О Я 1 Z h- о О ¥ П ! zf | §5 £ а ф га о о а ” “ е С S 1 г п 38 ст 8 у S аз Рисунок 3.5. Бизнес-процессы строительной компании
Проекты и процессы. Оператор связи как проектно-ориентированная компания 89 Проекты как процессы Представление проекта в виде совокупности процессов хорошо знако- мо специалистам в области менеджмента проектов по широко извест- ному стандарту PMBOK®Guide PMI (см [5]). Однако рамочный ха- рактер этого стандарта не позволяет выстроить процессы управления проектами на уровне компании с необходимой степенью детализации. Еще более сложно вписать эти процессы в контекст внутрикорпора- тивных отношений с учетом особенностей организационной структу- ры, принципов координации и субординации, правил делопроизвод- ства и т. д. Единственный путь к представлению проекта как унифицирован- ного процесса лежит через создание корпоративного стандарта управ- ления проектами, включающего такие элементы, как регламенты и положения (в том числе принципы учета трудозатрат и мотивации), процедуры выполнения проектов, ролевые инструкции персонала про- екта, шаблоны управленческих документов. Подробную информацию о принципах создания корпоративного стандарта управления проектами можно найти в работе [6]. Здесь же мы ограничимся лишь кратким описанием именно процессов, реали- зуемых при выполнении проектов и представляемых в стандарте в форме процедур. С точки зрения методологии управления проектами, общее множе- ство возможных процессов управления проектами может быть пред- ставлено в виде трехмерного пространства, изображенного на рисун- ке 3.6 [6] Каждая точка этого «пространства» представляет собой элементар- ный процесс управления. Например, «планирование рисков на стадии разработки системы» или «контроль качества проектирования систе- мы». Для удобства описания и исполнения процессы управления про- ектами должны быть сгруппированы по некоторым принципам и пред- ставлены в виде формализованных процедур. Возможны различные принципы группировки в соответствии с осями «пространства» про- цессов управления проектов: • «принцип абсциссы» — по стадиям жизненного цикла проекта; • «принцип ординаты» — по функциям управления; • «принцип аппликаты» — по фазам управления. 1 В качестве примера взяты стадии жизненного цикла проекта создания информаци- онной системы.
90 Глава 3 Содержание и границы Функции управления Рисунок 3.6. «Пространство» процессов управления проектом Суть принципов формирования процедур управления проектами со- стоит в следующем (на примере «принципа ординаты»): • Все функции, описываемые внутри процедуры, относятся строго к одной функции управления (например, управление отклоне- ниями). • Взаимодействие данной функции с другими функциями (напри- мер, с функцией управления стоимостью проекта) описывается путем ссылок на соответствующие процедуры, которые могут быть построены по «принципу ординаты» (например, процеду- ра управления стоимостью), «принципу аппликаты» или «прин- ципу абсциссы». • Содержание процедуры должно охватывать вопросы управления в рамках этой функции (например, управление отклонениями) на всех стадиях жизненного цикла проекта и при осуществле- нии всех фаз управления. Возможны и комбинированные подходы. Например, в качестве основ- ного принципа может применяться группировка процессов по фазам управления, а для ряда процессов, имеющих принципиальное значе-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 91 ние, например для становления культуры управления проектами, — группировка по функциям управления: • фаза инициализации описывается процедурой «Принятие реше- ний о запуске проектов»; • фаза планирования — процедурами «Выбор подрядчика и заклю- чение контракта» и «Запуск проекта»; • фазы выполнения и контроля — процедурой «Мониторинг и анализ исполнения проектов»; • фаза завершения — процедурой «Завершение проекта»; • функция управления отклонениями (риски, проблемы, измене- ния) — процедурой «Управление отклонениями». По отношению к процедурам управления проектами и процедурам, описывающим исполнение процессов, которые не имеют отношения к проектам, должны применяться единые правила поддержки и исполь- зования. Так, если в компании действует система менеджмента каче- ства, процедуры управления проектами должны быть оформлены в со- ответствии с ее требованиями, механизмы их пересмотра должны быть строго регламентированы, а правильность исполнения должна подвер- гаться регулярному аудиту. Гармонизация процессного и проектного подходов в деятельности компании Одним из серьезных препятствий на пути внедрения проектного управ- ления является неизбежно сопровождающий его передел сфер влия- ния в компании как на среднем, так и на высшем уровне руководства. Раньше все было просто: функциональный руководитель отвечал за решение конкретных задач, он выстраивал соответствующие процессы и ставил людей на их выполнение. Теперь оказывается, что ту же са- мую задачу можно в принципе решать по-другому и, возможно, это будет эффективнее. Но при этом «права собственности» на часть про- цесса или на некоторые отдельные формы реализации процесса долж- ны перейти к другим людям — от функциональных руководителей к руководителям проектов. Чтобы подобные «передачи управления» не приводили к заметным политическим потрясениям в компании, долж- ны быть определены формальные правила сосуществования процесс- ной и проектной деятельности. Другой фактор, о котором необходимо помнить в связи с гармони- зацией процессного и проектного подходов, состоит в том, что для руководителя проекта велик соблазн организовать управление так, как
92 Глава 3 удобно именно ему, — задачи-то уникальны. Но если каждый руково- дитель будет действовать по этому принципу, в организации наступит хаос, особенно если учесть необходимость параллельного существова- ния в компании двух управленческих культур (процессной и проект- ной). Решение здесь, как отмечалось выше, заключается в создании корпоративного стандарта, определяющего набор процедур управления и единых правил их поддержки и использования, безотносительно к тому, процессную или проектную деятельность они регламентируют. Исходя из этих соображений мы видим три основных этапа в про- цессе обеспечения гармоничного сочетания процессной и проектной деятельности в компании. Этап 1. Структурирование операционной деятельности компании Содержанием этапа является формальное описание организацион- но-функциональной структуры бизнес-процессов (реализуемых функ- ций, исполнителей). Возможно, в ходе формализации будет проведена определенная реструктуризация: устранены избыточные или дублиру- ющиеся функции, добавлены недостающие функции, перераспреде- лена ответственность. Это особенно важно с учетом того, что результа- том этапа станет базовый вариант процесса, который впоследствии будет сравниваться с вариантами, появляющимися в результате более ра- дикальных изменений. В ходе данного этапа должен быть также определен единый центр ответственности за процесс — владелец процесса. Именно это лицо (или группа лиц), ответственное за ход и результат всего процесса в целом, и будет впоследствии принимать решения о том, в какой именно фор- ме выполнять конкретные реализации данного процесса. Этап 2. Создание механизмов реализации процессов в проектной форме С х • : -анием данного этапа являются: • Построение альтернативных вариантов реализации процессов. Для процессов, по которым существующая практика является неудовлетворительной, разрабатываются варианты их оптими- зации на основе применения проектного подхода. Критериями оптимизации могут быть формальные ограничения процессов, такие как время исполнения, используемые ресурсы, качество результата и другие показатели, определяющие соответствие процессов бизнес-целям компании. Некоторые принципиаль- ные моменты, связанные с выполнением этого этапа, более по- дробно описаны в работе [7].
Проекты и процессы. Оператор связи как проектно-ориентированная компания 93 • Адаптация системы управления компании к выполнению проектов. Наиболее серьезные изменения приходятся на область органи- зационной структуры компании. Речь идет о постоянных (офис управления проектами) и временных (проектные команды) орга- низационных единицах, которые вовлекаются в работу над проек- тами или специально создаются для нее. Другими возможными последствиями, вытекающими из изменения организационной структуры, являются изменение системы бюджетирования ком- пании, принципов подбора и мотивации персонала и т. д. • Формирование регламентов взаимодействия владельцев процессов с руководителями проектов. Решение о применении проектного подхода принимается, как мы упоминали выше, владельцем процесса. Однако принятие этого решения и привлечение для исполнения проекта выделен- ного руководителя вовсе не снимает ответственности за процесс с его владельца. Именно он определяет методологию и техноло- гию решения задачи, выделяет необходимых специалистов и, возможно, контролирует их работу с содержательной стороны. За руководителем проекта остаются вопросы оперативного управления. Однако объем делегируемых ему полномочий мо- жет варьироваться очень широко и зависит как от специфики решаемых задач, так и от традиций корпоративной культуры. В принципе во взаимоотношениях этих двух ключевых фигур регламентировать можно очень многое — разделение ответствен- ности, правила «передачи управления» проектным командам, выделение ресурсов, решение спорных вопросов. Но не меньшее (если не большее) влияние на успех совмещения процессной и проектной деятельности оказывает дух сотрудничества, т. е. то, что регламентации поддается в очень малой степени. Этап 3. Создание механизмов унифицированного выполнения проектов Именно на этом этапе должен быть поставлен полноценный знак ра- венства между процессами и проектами. Проекты утрачивают ореол исключительности, их реализация становится обыденным, рутинным делом. Процессы, возникающие в ходе исполнения проектов, структури- руются и описываются в форме процедур. У этих процессов появля- ется свой владелец, отслеживающий их эффективность, правильность исполнения, отвечающий за развитие. В качестве владельца процессов управления проектами обычно выступает Офис управления проектами или иная, аналогичная по функциям служба компании (см. об этом
94 Глава 3 подробнее в разделе 2.1, а также в работах [6, 8]). Если такая специали- зированная структура в компании не создается, функции поддержания корпоративного стандарта управления проектами могут быть возложе- ны на Службу качества. Выводы Для многих производственных задач, с которыми сталкиваются совре- менные компании, невозможно заранее определить, какая форма их решения окажется более эффективной — процессная или проектная. Если ситуации, когда нужно делать подобный выбор, из исключений становятся правилами, возникает необходимость, во-первых, форма- лизовать процедуры принятия подобных решений и, во-вторых, обес- печить саму возможность одновременного существования обеих этих форм управления в компании. Первое достигается за счет: • разработки системы четких критериев, позволяющих определить в каждом конкретном случае, какая именно форма является бо- лее эффективной; • правильного распределения прав и ответственности между вла- дельцами процессов и менеджерами проектов, которым переда- ется управление отдельными экземплярами этих процессов. Второе достигается, прежде всего, за счет построения гибких орга- низационных структур матричного типа, что сразу же предъявляет спе- циальные требования и к системе бюджетирования, и к системе учета, и ко многим другим инструментам управления в компании. Особую роль в гармонизации процессной и проектной деятельно- сти компании может сыграть разработка корпоративного стандарта управления проектами с использованием методов и стандартов мене- джмента качества. Именно с позиций менеджмента качества стано- вится наиболее очевидным, что процессы и проекты — это всего лишь две стороны одной медали. 3.2. Причины и предпосылки внедрения проектного управления в телекоммуникационной компании Говоря о проектах в телекоммуникационной компании, чаще всего имеют в виду проекты развития и модернизации телекоммуникаци- онной инфраструктуры. Многие крупнейшие компании этой отрасли успешно внедрили стандарты и системы управления подобными про-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 95 ектами — Центральный телеграф [9], Казахтелеком [10], Deutsche Telekom Group [11] и др. Гораздо меньше известно о принципах орга- низации так называемых «клиентских» проектов, т. е. проектов, на- правленных на удовлетворение каких-либо потребностей конкретных клиентов. Именно об этих проектах, являющихся инструментом повы- шения эффективности традиционных процессов телекоммуникацион- ных компаний, и пойдет речь далее. В основе традиционной организационной структуры телекоммуни- кационной компании лежит иерархическая функциональная модель. Управление в компании, построенной по этой модели, реализуется через систему менеджмента (административного управления); ключевым эле- ментом последней являются менеджеры среднего звена — начальники подразделений, в непосредственном подчинении которых находятся сотрудники компании. Административное управление далеко не всегда эффективно, по- скольку руководитель подразделения часто бывает вынужден нести ответственность за конечный результат процесса, имея лишь ограни- ченные рычаги влияния и только на отдельных этапах этого процесса. В такой ситуации становится естественным стремление линейных ру- ководителей сконцентрировать в своих руках как можно больше пол- номочий и, соответственно, ответственности, чтобы увеличить возмож- ности своего влияния на достижение конечного результата. Вследствие этого у подразделений появляются непрофильные зада- чи, что усложняет управление и оттягивает ресурсы подразделения. Одновременно возникают «пограничные конфликты», ухудшающие климат в коллективе, порождающие конкуренцию подразделений и приводящие к серьезным затруднениям при реализации сквозных биз- нес-процессов. В результате ответственность за результат вынужденно сосредоточивается у высшего руководства компании. Устранение этих недостатков возможно при переходе к матричной организационной структуре и внедрении методов проектного управ- ления. При этом «спорные» функции вместе с реализующими их спе- циалистами передаются из зоны ответственности функционального руководителя в зону ответственности руководителя проекта. Матричная организационная структура предполагает формирова- ние на базе постоянных функциональных подразделений компании временных коллективов, которые создаются под определенную цель или под проект для решения какой-либо конкретной задачи и пользу- ются при этом определенной свободой в организации своей работы. Возможные подходы к внедрению проектного управления в теле- коммуникационной компании мы будем демонстрировать на примере деятельности по продаже продуктов (услуг) компании. Главным содер- жанием этой деятельности является создание уникальных продуктов
96 Глава 3 (услуг) под требования конкретных клиентов, используя имеющуюся продуктовую линейку и возможности кастомизации (настройки) про- дуктов. Характеризуя процесс создания конечного результата, в работе [12] отмечается, что в нем принимают участие специалисты различных подразделений компании — продавцы, инженеры, экономисты. При- чем для достижения результата в короткие сроки их работа должна быть максимально скоординированной (см. рис. 3.7). Обычно организационная структура телекоммуникационной компа- нии в значительной степени ориентирована на ту или иную операци- онную модель телекоммуникационного бизнеса. Например, организа- ция Tele Management Forum предлагает модель ТОМ (Telecom Opera- tions Model) — общеотраслевую рамочную модель процессов телеком- муникационной отрасли. ТОМ-модель предлагает универсальную (в смысле независимости от конкретной организации, технологии или содержания услуг) клас- сификацию процессов, с одной стороны, по уровням управления, а с другой — по определенным областям деятельности, которые правиль- нее всего определить как функциональные (см. рис. 3.8). Ориентация на подобные модели выражается в том, что функцио- нальные подразделения сформированы по «горизонтальному» принципу в соответствии с уровнями управления операционной модели. В то же время бизнес-процессы носят сквозной характер и затрагивают все уровни модели. В совокупности два этих факта приводят к тому, что для выполнения любого процесса, в том числе процесса продажи, тре- буется множество «передач управления» и согласований между подраз- делениями. Минимизировать издержки указанного усложнения процесса управ- ления можно только путем концентрации ответственности за весь про- цесс в одних руках. А это диктует необходимость создания специализи- рованных (постоянных или временных) подразделений, ориентиро- ванных на исполнение конкретных процессов. Возможность этого и предоставляет проектный подход, рассматривающий создание продукта или услуги как уникальный комплекс взаимосвязанных целенаправ- ленных мероприятий при определенных требованиях к срокам, бюд- жету и характеристикам ожидаемого результата. В соответствии со сквозными телекоммуникационными бизнес-про- цессами проектные структуры должны формироваться по «вертикально- му» принципу. Они должны создаваться для выполнения конкретных работ (проектов), иметь детальный план работ, собственный бюджет и систему мотивации. В состав команды проекта включаются сотрудни- ки функциональных подразделений и/или специалисты, привлекаемые на временной основе. Применение проектного подхода приводит, таким образом, к мат- ричной структуре компании, в которой функциональные подразделе-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 97 Рисунок 3.8. Формирование проектных структур
98 Глава 3 ния «пересекаются» с проектными группами, что полностью согласу- ется с ТОМ-моделью. Изменения при внедрении проектного управления могут состоять не только в использовании временных коллективов, но и в создании новых постоянных структурных единиц в штатном расписании компа- нии, таких, например, как Проектный офис или Служба управления проектами. Этим службам должны быть делегированы функции управ- ления портфелем проектов и, в частности, планирование ресурсов в масштабах компании в целом. 3.3. Особенности организации проектов подключения Перераспределение ответственности Опыт показывает, что наиболее серьезными проблемами бизнес-про- цессов телекоммуникационной компании являются: • неоправданно большой объем согласований и стремление к пере- кладыванию ответственности на смежные структуры или выше- стоящие уровни управления; • слабая организация планирования и учета использования тру- довых ресурсов. Эти проблемы также (и даже в еще большей степени) характерны и для процессов продаж. Решение этих проблем возможно только на основе сбалансированной системы распределения прав и ответственности меж- ду лицами, осуществляющими административное и проектное управ- ление. Матричная модель предоставляет необходимые возможности для создания такой системы применительно к процессам продаж. В этой модели появляются две новые роли — ресурсный менеджер и мене- джер проекта (см. рис. 3.9), что позволяет снять с руководителя под- разделения часть задач (и ответственности) и тем самым освободить его для управления решением профильных задач подразделения. В част- ности, профильными задачами Службы продаж являются: поиск и кон- сультирование потенциальных клиентов, проведение предварительных переговоров, ведение клиентов (анализ их потребностей, предложение новых услуг компании и т. д.). Все задачи, связанные с подготовкой и реализацией технических решений, необходимых для предоставления клиенту доступа к приобре- таемым им услугам, передаются в зону ответственности менеджеров про- ектов. Решаться данные задачи должны в рамках соответствующих проектов продаж. При этом часть работ в проектах продолжают вы-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 99 !’• (.урскыи Менеджер нрогч I а г1 < >/i р а з д о л е н и я Формирование единого расписания и ресурсного плана проектов Решение ресурсных конфликтов Выполнение текущих плановых непроектных работ Обучение персонала Формирование корпоративных методологий, базы знаний Выполнение проекта в запланированные сроки Соблюдение планового бюджета проекта Соблюдение требований к качеству работ Рисунок 3.9. Распределение ролей в проектно-ориентированной компании поднять менеджеры по продажам (например, заключение договоров, координация работ по установке на уровне контактов с клиентом). Но, повторим, ответственность за судьбу проекта в целом несет не руково- дитель Службы продаж, а менеджер проекта. Учитывая большое количество реализуемых проектов и то, что одни и те же специалисты могут быть задействованы в нескольких проектах одновременно (и это могут быть не только проекты продаж), должно применяться управление проектами на двух уровнях: • На нижнем уровне менеджер проекта обеспечивает управление отдельными проектами. В его компетенцию входит организация работ в рамках определенных сроков и бюджета. • На верхнем уровне обеспечивается управление портфелем проек- тов. Его осуществляет менеджер ресурсов, планирующий исполь- зование материальных и человеческих ресурсов как для опреде- ленных категорий проектов, так и по всем проектам компании в целом. Позиция ресурсного менеджера в компании является весьма значимой. Можно выделить два этапа эволюции его роли. На первом этапе внед- рения проектного подхода ресурсный менеджер в большей степени занят вопросами диспетчеризации ресурсов, их оптимального распределе-
100 Глава 3 ния и оперативного перераспределения. На втором этапе ресурсному менеджеру делегируются полномочия по решению ресурсных кон- фликтов, определению реальных потребностей компании в трудовых ресурсах, а также формированию требований к специализации и ква- лификации этих ресурсов. Если на первом этапе ресурсный менеджер выполняет чисто техниче- ские задачи, то на втором в его компетенцию попадают вопросы, реше- ние которых находится в прямой зависимости от интересов бизнеса. Формирование проектных групп Как отмечалось выше, основным преимуществом проектного подхода (с точки зрения повышения эффективности процессов продаж) явля- ется сокращение количества передач управления и ответственности между функциональными подразделениями путем максимального со- средоточения функций в «одних руках», а именно в руках Проектной группы (или команды проекта). В состав Проектной группы включаются все специалисты, необхо- димые для выполнения работ. Исключение должны составлять специа- листы подразделений, которые связаны с проектом в малой степени (например, оказывающие разовые консультации), и функции, которые по тем или иным причинам не могут быть отчуждены от специализи- рованных подразделений. Анализ с этих позиций участников проекта продаж, например, поз- волил сделать следующие выводы: • Целесообразно включать в состав команды проекта подключения клиентов — менеджера по продажам, необходимых специалис- тов инженерно-технических служб и служб оперативно-техни- ческого управления. • Нецелесообразно включать в состав такой команды специалис- тов финансовой и юридической служб, отдела материально-тех- нического снабжения. На рисунке 3.10 приведена возможная схема формирования коман- ды проекта подключения с участием специалистов постоянных подраз- делений компании. Менеджерами проектов назначаются менеджеры отдела управления проектами проектного офиса, роль ресурсного ме- неджера исполняет директор Проектного офиса. Такая система планирования и учета трудовых ресурсов в сочетании с системой мотивации позволяет добиться объективного отражения трудозатрат, поскольку завышение трудозатрат приведет к снижению размера премии, а занижение — к пересмотру (в сторону уменьшения) штатной численности подразделений.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 101
102 Глава 3 Для сотрудников, выполняющих определенную работу, которая от- носится к проекту, но не включенных в команду проекта, планирова- ние и учет рабочего времени осуществляются в рамках их постоянной деятельности руководителями соответствующих подразделений. Соот- ветственно, и затраты ложатся не на бюджет проекта, а на бюджет подразделения. Своевременное и качественное выполнение своих обя- занностей этими сотрудниками должно обеспечиваться системой рег- ламентов (см. об этом ниже), а также мотивацией, в том числе и от проектов продаж. В принципе планирование ресурсов для подобных проектов, хотя и является довольно сложным в техническом плане, может быть пол- ностью автоматизировано, поскольку с большой степенью точности можно прогнозировать период и объем занятости технических специа- листов. На рисунке 3.11 этот тезис иллюстрируется укрупненным рег- ламентом выполнения проектов подключения с указанием конкрет- ного времени привлечения тех или иных специалистов L Система мотивации Принципиальным преимуществом проектного подхода является воз- можность оценивать реальный вклад каждого участника проекта и при- менять справедливую и обоснованную систему поощрений, привязы- вая их не к общим финансовым результатам компании, а к результатам конкретных работ. При этом система мотивации по проектам не отме- няет, а дополняет общую систему мотивации компании. Размер премии участников проекта вычисляется на основе следу- ющих факторов: • время, отработанное сотрудником в проекте; • почасовая ставка сотрудника; • роль, которую сотрудник выполняет в проекте; • оценка вклада, даваемая менеджером проекта. При таком подходе каждый сотрудник сосредоточивается на достиже- нии результата в каждом проекте, поскольку только его работа (а не результаты деятельности всей компании) обеспечивает ему получение премии. Часть прибыли от проекта идет также на премирование под- разделений, делегировавших своих специалистов в проект. Это позво- ляет выровнять мотивацию к выполнению проектных и непроектных работ (см. рис. 3.12). 1 Более подробно см. раздел 3.4.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 103 Рисунок 3.11. Привлечение сотрудников компании на различных этапах проекта
104 Глава 3 Бюджет проекта Прибыль компании Пр> 1.ичч;ч.ч»л.>. Ьг>нд пропктI 50% !-рег.|И-тп>ныи Фонд подразделении 50% Распределяет руководитель проекта Критерии распределения: • Доля участия • Качество работы Распределяет руководитель подразделения Команда проекта Сотрудники, занятые на постоянных работах подразделения Рисунок 3.12. Схема премирования в проектно-ориентированной компании Внедрение системы проектной мотивации может осуществляться в три этапа. • Целью первого этапа является повышение заинтересованности сотрудников компании во внедрении проектного подхода. На этом этапе размер премии по проекту подключения фикси- руется в начале проекта и определяется исходя из трудоемкости проекта. Размер премии в проектах должен значительно (более чем на 40%) превосходить среднюю по компании премию. Пре- мия выплачивается только в случае выполнения проекта в за- данный срок и в рамках запланированного бюджета. • Целью второго этапа является внедрение методов проектного учета. На этом этапе премия выплачивается исходя из экономии бюд- жета проекта, определяемой на основании учетных данных о выполнении работ (разницы планового бюджета и реальных за- трат).
Проекты и процессы. Оператор связи как проектно-ориентированная компания 105 • Целью третьего этапа является внедрение полномасштабного использования мотивационных механизмов (как от экономии, так и от прибыли). На этом этапе часть премии выплачивается по схеме второго этапа, а дополнительная премия — исходя из реального трафи- ка подключенного клиента в течение трех месяцев после под- ключения. 3.4. Управление проектами подключения Формализованная среда управления проектами Переход к унифицированному выполнению проектов возможен толь- ко на основе создания корпоративного стандарта управления проек- тами, включающего такие элементы, как политика управления про- ектами (в том числе принципы учета трудозатрат и мотивации), проце- дуры выполнения проектов, ролевые инструкции персонала проекта, шаблоны управленческих документов (см. рис. 3.13). Подробную информацию о принципах создания корпоративного стандарта управления проектами можно найти в работе [6]. В главе 4 эти принципы подробно рассмотрены на примерах строительных и инжиниринговых компаний. Дсг.--пьш- О ИИ-тру!". Шаблоны докумоч гов Рисунок 3.13. Структура корпоративного стандарта управления проектами
106 Глава 3 Ключевым элементом формализованной среды проектов подключе- ния является описание бизнес-процесса подключения, которое исполь- зуется в качестве скелета процедуры управления проектами этого типа. В таблице 3.1 приведены структура и возможное содержание стандарта управления проектами подключения клиентов, а в таблице 3.2 — до- полнительные разделы стандарта, определяющие порядок взаимодей- ствия проектных групп с постоянными подразделениями компании. Процедуры управления проектами В данном разделе приведен пример построения сквозной процедуры, охватывающей весь проект. В дополнение к ней могут разрабатываться рабочие инструкции, детализирующие отдельные положения процеду- ры. Соответствующий пример приведен ниже. Процедура управления проектом цифрового подключения клиента 1. Список сокращений МП — менеджер проекта; МПр — менеджер по продажам; КП — координатор проекта; ПГ — проектная группа; РМ — ресурсный менеджер. 2. Схема реализации проекта подключения Необходимым условием начала проекта подключения клиентов является появле- ние Запроса на подключение. Запрос на подключение формируется МПр со ста- тусом «предварительный запрос» по результатам предварительных переговоров с клиентом и утверждается РМ. Запрос на подключение должен содержать предварительные данные о кли- енте, его требования и желаемые даты подключения. Результатом стадии оценки возможности подключения и условием начала работ по стадии установки является Технический отчет о возможности подключения и Договор на оказание телекоммуникационных услуг. 3. Описание деятельности на стадии оценки возможности подключения 3.1. Открытие работ по оценке возможности подключения Начальный этап работ стадии оценки возможности подключения (и проекта под- ключения в целом) предусматривает последовательное выполнение следующих действий (шагов).
Проекты и процессы. Оператор связи как проектно-ориентированная компания 107 Таблица 3.1. Структура стандарта управления проектами Содержание документов Регистрация Запроса на подключение Назначение менеджера проекта Формирование команды проекта Формирование детального графика Планирование загрузки ресурсов i Определение бюджета проекта, включая строительство 1 сети и поставку оборудования Управление отклонениями (рисками, проблемами, изменениями) Заказ оборудования Учет рабочего времени и финансовых затрат Контроль статуса проекта Контроль качества подключения Контроль использования ресурсов Оформление технической документации Оформление договора Отчетность по ключевым показателям деятельности 1 Инструкции, которые формируются автоматически по детальным описаниям процедур, хранящимся в репозитарии бизнес-процессов Документы раздела Открытие проекта Планирование проекта Исполнение проекта Контроль проекта Завершение проекта 1 Ресурсный менеджер Менеджер по продажам Менеджер проекта Раздел стандарта I 0? S Ф х I и £ 51 Н " з z ф 5 о о Sf ф Фо о о е; о. О. О. Оф ЕС О. С
о Таблица 3.1. (окончание) Раздел стандарта Документы раздела Содержание документов Шаблоны документов Управленческие документы Запрос на подключение План проекта подключения Оперативный календарный план Заявка на проведение сверхурочных работ Наряд на выполнение работ по подключению Отчет о статусе проекта Отчет об использовании ресурсов Претензия клиента План проекта по устранению неисправностей Наряд на выполнение работ по устранению неисправностей Отчет об устранении неисправностей Коммерческие документы Договор Соглашение об уровне качества обслуживания Счет Технические документы Схема подключения Спецификации оборудования Таблица 3.2. Дополнительные разделы стандарта управления проектами Раздел стандарта Документы раздела Содержание документов Регламенты взаимодействия Взаимодействие со службой продаж Получение заказов и специальных условий (скидки, сроки исполнения) Формирование по запросу отчетов о статусе проекта Формирование отчета о возможности подключения Формирование отчета о подключении Взаимодействие с юридической службой Экспертиза и согласование соглашения об уровне обслуживания Взаимодействие с финансовой службой Формирование запросов и получение отчетов по кредитной истории клиента Экспертиза и согласование договоров Передача счетов Взаимодействие со службой материально-технического обеспечения Передача заказов на материалы и оборудование Формирование запросов и получение отчетов по статусу поставки Дополнения в должностные инструкции Директор инженерно-технической службы Директор службы продаж Дополнения, которые описывают обязанности и права должностных лиц, появляющиеся в связи с внедрением проектного подхода (например, порядок выделения сотрудников в проекты и их отзыва из проектов)
110 Глава 3 Шаг 1. Регистрация проекта по подключению РМ на основании Запроса на подключение открывает проект по подключению клиента и присваивает ему регистрационный номер, после чего по согласованию с директором отдела эксплуатации назначает МП/КП. Соответствующая инфор- мация фиксируется в Запросе на подключение. Регистрация проекта подключения должна быть осуществлена в день получе- ния Запроса на подключение. Шаг 2. Формирование плана проекта МП формирует техническое решение. Решение о способе подключения принимает- ся на основании данных Заказчика и имеющейся в компании информации о тех- нической возможности подключения по адресу клиента. В случае необходимости для формирования технического решения может собираться технический совет. МП совместно с МПр формируют План проекта подключения, определяющий следующие компоненты проекта: • возможные технические решения; • коммерческое предложение; • предполагаемый состав работ проекта; • предполагаемые закупки оборудования и материалов; • предложения по срокам исполнения. РМ согласует План проекта. Формирование Плана проекта должно быть осуществлено в течение одного дня с момента открытия проекта. Шаг 3. Согласование технического решения с Заказчиком МПр проводит презентацию технического решения у Заказчика. По результатам презентации с учетом замечаний Заказчика МПр и МП корректируют План про- екта и дополняют его следующими разделами: • требования к персоналу; • риски проекта; • план коммуникаций внутри и вне компании с указанием контактных лиц. На основании уточненного Плана проекта дополняется Запрос на подключе- ние, после чего ему присваивается статус «запрос на оценку технической воз- можности подключения». Шаг 4. Формирование ключевых показателей деятельности по проекту (КПД) Формируются значения следующих КПД или их составляющих: • оценка перспективности клиента (ответственный — МПр); • прогноз затрат по проекту (ответственный — МП); • прогноз времени реализации проекта (ответственный — МП); • прогноз использования рабочего времени персонала (ответственный — МП). 3.2. Планирование работ по оценке возможности подключения Этап планирования работ на стадии оценки возможности подключения преду- сматривает последовательное выполнение следующих действий (шагов). Шаг 1. Формирование проектной группы РМ с использованием вновь поступивших (или скорректированных в части ресурс- ных требований) Планов проектов формирует персональный состав ПГ, исходя из потребностей в ресурсах всего портфеля заказов и предусматривая возможность использования одной и той же команды проекта для выполнения нескольких про- ектов подключения. Состав ПГ фиксируется в Плане проекта.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 111 Формирование проектной группы осуществляется в день получения Плана проекта. Шаг 2. Решение ресурсных проблем В случае возникновения ресурсных проблем (отсутствие необходимого количества квалифицированного персонала, появление незапланированных работ и т. д.) РМ готовит Заявку на проведение сверхурочных работ, в которой обосновывает необ- ходимость их проведения, численность персонала и объем работ. Заявка со- гласовывается руководством компании и становится после этого неотъемлемой частью Плана проекта. Шаг 3. Формирование оперативного календарного плана РМ, исходя из сформированных составов команд проекта и территориального расположения заказчиков, формирует (корректирует) ежедневный почасовой Опе- ративный календарный план на неделю. При формировании плана должны быть оптимизированы маршруты передвижения ПГ. Шаг 4. Формирование КПД Формируются значения следующих КПД или их составляющих: • уточненный прогноз затрат по проекту (ответственный — МП); • уточненный прогноз времени реализации проекта (ответственный — РМ); • уточненный прогноз утилизации персонала (ответственный — РМ). 3.3. Выполнение работ по оценке возможности подключения Этап выполнения работ стадии оценки возможности подключения осуществля- ется на основании Оперативного календарного плана и предусматривает после- довательное выполнение следующих действий (шагов). Шаг 1. Организация выезда ПГ к Заказчику МП согласует с Заказчиком время работы ПГ и передает ответственному испол- нителю ПГ Запрос на подключение не позднее даты, предшествующей дню про- ведения работ. Шаг 2. Оценка возможности подключения на месте ПГ на территории Заказчика проводит необходимые работы по оценке возможности цифрового подключения, подключения по медному кабелю и/или радиодоступа. В случае невозможности проведения работ (отсутствие доступа на террито- рию, отсутствие контактных лиц и т. д.) ответственный исполнитель ПГ обязан немедленно связаться с МП. Последний должен обеспечить возможность проведе- ния работ либо сообщить о невозможности проведения работ РМ с целью немед- ленного внесения изменений в Оперативный календарный план. Шаг 3. Согласования и бронирования По результатам оценки возможности подключения на месте специалисты ПГ осу- ществляют необходимые согласования и бронирования: • согласование наличия, бронирование и тестирование медных пар; • согласование возможности прокладки оптоволоконного кабеля по существу- ющим трассам; • оформление заказа и получение технических условий; • оформление запроса о предоставлении линейной емкости, бронирование но- меров телефонов и комплектов абонентского доступа. Шаг 4. Оформление результатов оценки По результатам оценки, согласований и бронирований специалисты ПГ готовят Заключения о возможности подключения с указанием сроков и стоимости проведе- ния работ. В случае необходимости дооборудования готовятся соответствующие спецификации. Заключения передаются МП.
112 Глава 3 МП формирует согласованный пакет документов, содержащий окончатель- ное техническое решение. Шаг 5. Подготовка Договора МПр совместно с МП готовят проект Договора. Проект Договора согласуется и утверждается в соответствии с инструкцией процедуры согласования и оформле- ния договоров на предоставление телекоммуникационных услуг. МПр осуществляет контроль прохождения Договора у заказчика и внесение необходимых изменений. Шаг 6. Формирование КПД Формируются значения следующих КПД или их составляющих: • уточненная оценка перспективности клиента (ответственный — МПр); • уточненный прогноз затрат по проекту (ответственный — МП); • уточненный прогноз времени реализации проекта (ответственный —- РМ); • уточненный прогноз использования рабочего времени персонала (ответствен- ный — РМ). 3.4. Контроль работ по оценке возможности подключения В ходе выполнения работ по оценке возможности подключения контролируются три основных параметра. Время исполнения МП ежедневно фиксирует и оценивает отставание по времени исполнения работ: • отставание 0% — оценка 5; • отставание 0-10% — оценка 4; • отставание 10-30% — оценка 3; • отставание более 30% — оценка 2. Ресурсы проекта МП ежедневно фиксирует и оценивает превышение расхода рабочего времени: • превышение 0% — оценка 5; • превышение 0-10% — оценка 4; • превышение 10-30% — оценка 3; • превышение более 30% — оценка 2. Коммуникации МП ежедневно оценивает возникающие проблемы коммуникаций внутри коман- ды проекта, со смежными организациями, с заказчиком: • нет проблем — оценка 5; • отсутствие связи в пределах одного часа — оценка 4; • отсутствие связи в пределах одного дня — оценка 3; • отсутствие связи более одного дня — оценка 2. По результатам оценки основных параметров проекта МП готовит Отчет о статусе проекта и подает его в Отдел качества. 3.5. Завершение работ по оценке возможности подключения Этап завершения работ стадии оценки возможности подключения предусматри- вает последовательное выполнение следующих действий (шагов). Шаг 1. Оформление управленческой документации РМ готовит Отчет об использовании ресурсов на стадии оценки технической воз- можности подключения.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 113 Шаг 2. Формирование КПД Формируются значения следующих КПД или их составляющих: • затраты на стадии оценки технической возможности подключения (ответствен- ный — МП); • время реализации стадии оценки технической возможности подключения (от- ветственный — РМ); • использование рабочего времени персонала на стадии оценки технической воз- можности подключения (ответственный — РМ). Значения КПД включаются в План проекта и помещаются в хранилище данных. 4. Описание деятельности на стадии установки 4.1. Открытие работ по установке Начальный этап работ стадии установки предусматривает последовательное вы- полнение следующих действий (шагов). Шаг 1. Формирование обновленного Плана проекта На основании Технического отчета о возможности подключения МП формирует обновленный План проекта, определяющий следующие компоненты проекта: • состав работ проекта; • требования к персоналу; • план коммуникаций внутри и вне компании с указанием контактных лиц; • необходимые закупки оборудования и материалов; • предложения по срокам исполнения и составу ПГ для стадии установки. РМ согласует План проекта. Формирование обновленного Плана проекта должно быть осуществлено в день подписания Договора. Шаг 2. Формирование КПД Формируются значения следующих КПД или их составляющих: • прогноз затрат по проекту (ответственный — МП); • прогноз времени реализации проекта (ответственный — РМ); • прогноз использования рабочего времени персонала (ответственный — РМ). 4.2. Планирование работ по установке Этап планирования работ стадии установки совпадает с соответствующим эта- пом стадии оценки возможности подключения. 4.3. Выполнение работ по установке Этап выполнения работ стадии оценки возможности подключения осуществля- ется на основании Оперативного календарного плана и предусматривает после- довательное выполнение следующих действий (шагов). Шаг 1. Организация выезда ПГ к Заказчику МП согласует с Заказчиком время работы ПГ и выписывает наряд на выполнение работ, который передается ответственному исполнителю ПГ не позднее даты, предшествующей дню проведения работ. Шаг 2. Выполнение работ ПГ на территории Заказчика проводит необходимые работы по установке. Ответ- ственный исполнитель ПГ закрывает наряд у представителя Заказчика. В случае невозможности проведения работ (отсутствие доступа на терри- торию, отсутствие контактных лиц и т. д.) бригадир ПГ обязан немедленно свя-
114 Глава 3 заться с МП. Последний должен обеспечить возможность проведения работ либо сообщить о невозможности проведения работ РМ с целью немедленного внесе- ния изменений в Оперативный календарный план. Шаг 3. Формирование КПД Формируются значения следующих КПД или их составляющих: • уточненный прогноз затрат по проекту (ответственный — МП); • уточненный прогноз времени реализации проекта (ответственный — РМ); • уточненный прогноз использования рабочего времени персонала (ответствен- ный — РМ). 4.4. Контроль работ по установке Контроль работ стадии установки совпадает с соответствующим этапом стадии оценки возможности подключения. 4.5. Завершение проекта Этап завершения работ стадии установки (и всего проекта) предусматривает вы- полнение следующих действий. Шаг 1. Согласование и утверждение технической документации МП организует согласование с Заказчиком и утверждение Технического отчета об установке. Шаг 2. Оформление управленческой документации РМ готовит Отчет об использовании ресурсов на стадии установки. Шаг 3. Формирование КПД Формируются значения следующих КПД или их составляющих: • затраты на стадии установки (ответственный — МП); • время реализации стадии установки (ответственный — РМ); • использование рабочего времени персонала на стадии установки (ответствен- ный — РМ). Инструкция по взаимодействию менеджера проектов с руководителями ресурсных подразделений в ходе выполнения проектов подключения 1. Цели взаимодействия Целями взаимодействия являются: • выделение в проект подключения специалистов, адекватных задачам проекта, на требуемый для решения этих задач период; • учет времени, затраченного специалистами в проектах подключения. 2. Список сокращений МП — менеджер проекта; РРП — руководитель ресурсного подразделения. 3. Порядок выделения специалистов в проект Основанием для выделения специалистов в проект является запрос МП (состав- ная часть Плана проекта подключения), содержащий следующую информацию: • специализация сотрудника; • требования к квалификации;
Проекты и процессы. Оператор связи как проектно-ориентированная компания 115 • требуемое количество сотрудников данной специализации и квалификации; • время занятости (с указанием планируемого календарного периода с точностью до часов). На основании этой заявки РРП обязан: • выделить конкретных специалистов требуемой квалификации на указанный период; • если существуют ресурсные проблемы, предложить альтернативные периоды выделения специалистов (в пределах одного-двух рабочих дней); • если это невозможно, дать мотивированный отказ в выделении персонала. МП и РРП обязаны в максимальной степени содействовать разрешению возника- ющих ресурсных проблем на своем уровне. Если это оказывается невозможным, МП передает проблему на рассмотрение руководству компании. Специалист, выделяемый в проект, переходит в подчинение МП. По согласо- ванию с МП специалисту могут быть поручены задачи из других проектов, если их выполнение совместимо (территориально и по требуемому времени) с выполне- нием задач пилотного проекта. О работе, выполненной в рамках пилотного проекта, специалист отчитывает- ся непосредственно перед МП. Согласованное время занятости специалиста в проекте не может быть изме- нено МП или ППР в одностороннем порядке. Также не могут быть осуществлены в одностороннем порядке замена или отзыв специалиста. Все эти вопросы долж- ны решаться по взаимному согласию РРП и МП. 4. Порядок учета рабочего времени После завершения проекта подключения (стадии проекта подключения) МП обя- зан заполнить Отчет об использовании ресурсов, в котором указывается время, затраченное на выполнение проекта каждым специалистом. Объем затраченного времени должен соответствовать фактически отрабо- танному времени и не превышать запланированного времени (с учетом последу- ющих согласованных изменений). Должен осуществляться раздельный учет по проектам, выполняемым одновременно. Некачественное или неполное исполнение работ специалистами может явиться основанием для незачета или неполного зачета потраченного времени. В этом случае МП должен согласовать Отчет об использовании ресурсов с РРП. Шаблоны управленческих документов Важнейшей особенностью применения проектного подхода в телеком- муникационной компании является необходимость исполнения боль- шого количества однотипных небольших проектов. В этих случаях особенно целесообразно создание типовых шаблонов управленческих документов, ориентированных на максимальную экономию усилий ме- неджеров по их заполнению. В данном разделе приведены примеры двух таких специализированных шаблонов — План управления проек- том подключения клиентов телекоммуникационных компаний (см. табл. 3.3) и Отчет об использовании ресурсов в проектах подключения (см. табл. 3.4).
116 Глава 3 Таблица 3.3. План управления проектом цифрового подключения клиента телекоммуникационной компании Дата составления И^ИЩИИИИ >.и.о Должно Ресурсный ме сгь Реда1 Подп сция ись 1 Дата Утвердил чеджер Составил Менеджер проекта Согласовал Менеджер по продажам Наименование клиента Сведения о клиенте Категория клиента Крайне значимый Весьма значимый Стандартный клиент Предложение по срокам подключения от « » 200 г. до « » 200 г. Адрес подключения Организация Контактные nt Должность . Ф.И.О. ; Телефон Парамет Параметры заказа ры зака 1 за 2 Услуги : 4 5 Подключение по прямому проводу Подключение через радиодоступ Подключение через PCM/PGS Подключение до точки местной сети Номера {компании} по данному адресу №т/ф-линий, предоставленных для уплотнения За счет переключения номера Организация новой серийной группы Заведение в серийную группу
Проекты и процессы. Оператор связи как проектно-ориентированная компания 117 Возможные технические решения Содержание коммерческого предложения Предполагаемый состав работ Предполагаемые закупки материалов и оборудования Наименование Количество Поставщик Требования к персоналу проекта Персональный госчав Специализация Специалист по организации установок Квалифи- иЯШШЯ Кол-во со г рудников Время ЗЗНЯТОС! 1'1 ФИ.О . Специалист по развитию абонентской сети Специалист по бронированию Специалист по органи- зации радиодоступа Специалист по подготовке линейных данных Специалист по станци- онным сооружениям Специалист по линейным сооружениям Риски проекта Название риска Вероятное 1ь риска Недостаточная информированность о технических условиях клиента Слабая заинтересованность клиента Противодействие со стороны смежных организаций Недостаток рабочей силы Запаздывание в поставках
118 Глава 3 Таблица 3.4. Отчет об использовании ресурсов Per. № проекта Тип проекта Подключение Устранение неисправности Расследование Дата открытия проекта « » 200 г. Дата начала работ « » 200 г. Наименование клиента Управленческий персонал Должность Ф.И.О. ; Количество затраченных часов Всего 1-я стадия 2-я стадия Менеджер по продажам Менеджер проекта Координатор проекта Технический пер сонал Должность Ф.И.О. Количество затраченных часов Всего 1-я стадия 2-я стадия Специалист по организа- ции установок Специалист по развитию абонентской сети Специалист по бронированию Специалист по органи- зации радиодоступа Специалист по подготовке линейных данных Специалист по станцион- ным сооружениям Специалист по линейным сооружениям Ф.И.О. Должность Подпись Дата Утвердил Ресурсный менеджер Согласовал Менеджер проекта
Проекты и процессы. Оператор связи как проектно-ориентированная компания 119 3.5. Критерии оптимизации процессов подключения Как отмечалось выше, решение о применении проектного подхода должно приниматься исходя из объективных критериев. В данном раз- деле мы рассмотрим в качестве примера систему таких критериев, по- лученную на основании формализации бизнес-стратегии телекомму- никационной компании. Система ключевых показателей деятельности для проектов подключения 1. Показатели финансовых результатов • Рентабельность по продуктам: [Рентабельность продуктов] = [Сумма доходов от реализации продукта за календар- ный период] / [Сумма затрат на выполнение процесса по созданию, внедрению и со- провождению продукта за календарный период]. • Доля затрат на развитие сети в общих расходах: [Доля затрат на развитие сети] = ([Сумма прямых затрат на развитие сети за кален- дарный период] + [Сумма затрат, отнесенных на развитие сети в проектах подключе- ния за календарный период]) * 100% / [Сумма общих затрат за календарный период]. 2. Показатели отношений с клиентами • Качество обслуживания клиентов: [Качество обслуживания клиентов] = (Р1 * [Удобство оформления] + Р2 х [Условия и формы оплаты] + РЗ х [Время обработки заявки]) / (Р1 + Р2 + РЗ). • Доля отказов от подключения из-за отсутствия технической возможности: [Доля отказов] = [Количество отказов] х 100% / [Количество заявок на подключение]. • Перспективность клиентов: [Перспективность клиента] = К1 х [Оценка объема трафика клиента], где К1 (от 0 до 1) — рисковый коэффициент, учитывающий вероятность оплаты предоставленных услуг. • Гибкость тарифной политики: [Гибкость тарифной политики] = (П1 х [Конкурентоспособность базового тарифа] + + П2 х [Оперативность изменения текущих тарифов]) / (П1 + П2). 3. Показатели организации процессов • Эффективность использования ресурсов: [Использование рабочего времени] = [Рабочее время, затраченное сотрудниками в рамках проектов подключения] / [Общий фонд рабочего времени]. • Качество услуг: [Качество услуг] = (М1 х [Количество претензий по услуге за календарный период] + + М2 х [Количество отказов от услуги за календарный период]) * 100% / ((М1 + М2) х х [Общее количество условных линий, обслуживаемых в календарном периоде]). Для каждого показателя определены целевые значения и период вычисления (см. рис. 3.14).
120 Глава 3 Отношения с клиентами 2. Доля расходов на развитие сети 20% (год) 15% 4. Доля отказов (месяц) 3. Качество обслуживания клиентов (квартал) 5. Перспективность клиентов (месяц) 20% 1. Рентабельность продуктов (квартал) Финансовые результаты 6. Гибкость тарифной политики 4 е (квартал) 7. Утилизация (неделя) 40-90% 8. Качество услуг (квартал) Внутренняя организация Рисунок 3.14. Система ключевых показателей для процессов подключения Сбор информации и расчет этих показателей должны осуществляться в рамках процесса или, если процесс осуществляется в форме проекта, в рамках проекта подключения. Это означает, что в процедуру управ- ления проектом, рассмотренную в разделе 3.4, должны быть встроены функции, обеспечивающие получение плановых, прогнозных и факти- ческих значений этих показателей. Регламент расчета показателей, соответствующий рассмотренной выше процедуре, приведен в таблице 3.5. «Как покончить с нехваткой монтеров?» Характерное название для своей статьи придумал журналист «Коммер- санта», описывая положение дел в одной телекоммуникационной ком- пании: «Как покончить с нехваткой монтеров?» В ней, в частности, указывается: «Еще год назад менеджер по продажам в компании при- носил новый контракт, получал за него бонус, после чего бежал искать нового клиента. А затем представители по продажам стали отвечать за то, чтобы подписанный контракт был надлежащим образом реализо- ван. Тот, кто привел клиента, выступал и координатором проекта по его подключению. Вернее, его „толкачом": он бегал по отделам, от которых зависит техническая сторона дела, и всех теребил. Но функ- циональные отделы бонусов не получают — только премии по итогам года, а у начальников отделов полномочий гораздо больше, чем у ме-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 121 неджера по продажам. Поэтому бизнес-процесс получался слишком персонализированным: все зависит от личных отношений, а чувства команды — нет. В каждом подразделении есть очень сильные мене- джеры, но они разобщены и не готовы помогать друг другу. В эксплуа- тационном отделе, например, работает 80 человек, и при этом вечная проблема — не хватает монтеров» [13, с. 184]. Вопрос нехватки монтеров кроме глобального и отчасти риториче- ского звучания имеет еще одну совершенно конкретную сторону. Успеш- ность проектно-ориентированной компании в значительной степени зависит от того, насколько хорошо используются человеческие ресур- сы [14, 15]. При использовании матричных организационных структур усложняются как распределение ресурсов, так и процедуры управления. Именно поэтому важнейшим показателем является степень использо- вания рабочего времени персонала в проектах (утилизация). Утилизация показывает эффективность использования ресурсов и сигнализирует либо о слабой загрузке персонала и необходимости по- вышения качества ресурсного планирования, либо, наоборот, о необ- ходимости привлечения дополнительных рабочих ресурсов. Формула для вычисления утилизации достаточно тривиальна, а слож- ности с ее расчетом лежат в области сбора необходимых исходных дан- ных. И несмотря на то, что планирование и учет ресурсов являются одним из краеугольных камней управления проектами, в реальной прак- тике наладить учет рабочего времени в проектах не так-то просто. Попроектное планирование и учет рабочего времени, консолидация плановых и учетных данных в масштабах всей компании, анализ инфор- мации в различных аспектах (подразделения, направления деятельно- сти, типы проектов) требуют применения полноценных инструментов управления ресурсами. Высокая вероятность конфликтов ресурсов при уровне утилизации выше 70—80% обусловливает необходимость использования четких процедур функционирования команды проекта — от процессов ее фор- мирования и роспуска до процедур учета и отчетности. Очевидно, эти процессы и процедуры не могут замыкаться внутри проекта и должны затрагивать более общий контекст корпоративных отношений. Вот несколько рецептов на тему, как получить объективное значе- ние утилизации. Для этого надо: 1. Создать условия, понуждающие сотрудника подавать сведения о собственной занятости в проектах, например, не считать неуч- тенное время затраченным в проектных работах (со всеми выте- кающими последствиями в части оплаты работ и мотивации). 2. Исключить обстоятельства, затрудняющие подачу сведений. Про- цедура регистрации рабочего времени должна быть максималь-
122 Глава 3 Таблица 3.5. Формирование измерителей и показателей Стадии определения возможности подключения Открытие Планирование Исполнение Контроль Рентабельность по продуктам Сумма затрат на выполнение процесса по созданию, внедрению и сопровождению продукта Определяются нормативные значения затрат по категориям на обе стадии проекта Рассчитываются прогнозные значения затрат по различным категориям для обеих стадий проекта Учитываются фактические значения затрат данной стадии по различным категориям Фактические значения затрат данной стадии согласуются с РМ Доля затрат на развитие сети Сумма затрат, отнесенных на развитие сети в проектах подключения Качество обслуживания Удобство оформления Условия и формы оплаты Время обработки заявки Определяется нормативное значение времени обработки заявки Определяется прогнозное время обработки заявки Фиксируется начальное время обработки заявки Доля отказов Количество отказов — — Фиксируется факт отказа на стадии оценки возможности подключения — Количество заявок на подключение Фиксируется факт поступления заявки — — — Перспективность клиентов Оценка трафика клиента Фиксируется предварительная оценка трафика клиента — — —
Проекты и процессы. Оператор связи как проектно-ориентированная компания 123 в проектах подключения Стадии подключения Завершение Открытие Планирование Исполнение Контроль Завершение Фиксируются плановые и фактические значения затрат Рассчиты- ваются уточненные прогнозные значения затрат по различным категориям для стадии установки Учитываются фактические значения затрат данной стадии по различным категориям Фактические значения затрат данной стадии согласуются с РМ Фиксируются фактические значения затрат Рассчиты- вается и фиксируется фактическое значение затрат Фиксируется оценка, базирующаяся на фактическом времени оформления договора Фиксируется оценка, базирующаяся на фактических условиях оплаты Фиксируется конечное время обработки заявки Определяется прогнозное время подключения Фиксируется начальное время подключения Фиксируется конечное время подключения Фиксируется факт отказа в процессе заключения договора — Фиксируется факт отказа на стадии оценки возможности подключения — — — — — — — — — — — — — — Фиксируется уточненная оценка тра- фика клиента
124 Глава 3 Таблица 3.5. (окончание) Стадии определения возможности подключения Открытие Планирование Исполнение Контроль Гибкость тарифной политики Конкуренто- способность базового тарифа Фиксируется предварительное решение по тарифу Эффективность использования ресурсов Рабочее время, затраченное сотрудниками в рамках проектов подключения Определяются нормативные значения затрат Рассчитываются прогнозные значения затрат времени сотрудников по обеим стадиям Учитываются фактические значения затрат данной стадии по различным категориям Фактические значения затрат данной стадии согласуются с РМ но упрощена, не следует занимать сколь-нибудь существенного времени сотрудников и требовать специальных знаний (напри- мер, в области использования программных средств). 3. Создать механизмы, препятствующие завышению затрат рабо- чего времени. Например, можно выдавать исполнителям зада- ния с указанием планового времени, рассчитанного на основании обоснованных нормативов, и/или начислять премии по проек- там в зависимости от экономии их бюджетов. 4. Создать механизмы, препятствующие занижению затрат рабо- чего времени. Например, можно поставить в прямую зависи- мость от утилизации как штатную численность подразделений, так и зарплату отдельных специалистов. 3.6. Дальнейшее развитие проектного подхода От проектов подключения — к проектам обслуживания запросов Мы полагаем, что не только подключение клиентов, но значительная часть иной деятельности телекоммуникационной компании по обслу- живанию клиентов может выполняться в проектной форме. При этом может реализовываться многоуровневая система обработки запросов клиента. Уровень первичной обработки запросов Первичная обработка запросов осуществляется в единой точке входа для всех запросов клиентов (как телефонных, так и письменных), на-
Проекты и процессы. Оператор связи как проектно-ориентированная компания 125 Стадии подключения Завершение Открытие Планирование Исполнение Контроль Завершение Фиксируется фактический тариф, предостав- ленный клиенту Фиксируются плановые и фактические значения затрат Определяются нормативные значения затрат Рассчитываются прогнозные значения затрат времени сотрудников по обеим стадиям Учитываются фактические значения затрат данной стадии по различным категориям Фактические значения затрат данной стадии согласуются РМ Фиксируются плановые и фактические значения затрат пример Центром обработки запросов, который выполняет следующие действия: • принимает, классифицирует и фиксирует запрос клиента; • в простых случаях — находит решение и доводит его до клиента; • в сложных случаях — переадресует запрос в соответствии с его классификацией в один из центров компетенции. Уровень инициализации проектов Центры компетенции (по качеству услуг и обслуживания) и отдел про- даж выполняют углубленное изучение запроса клиента. При этом они: • классифицируют запрос; • выполняют диагностику и консультации с профильными под- разделениями компании; • в простых случаях — находят решение и доводят его до клиента; * в сложных случаях — инициируют проект определенного вида, соответствующий потребностям клиента. Уровень исполнения проектов Запросы клиента выполняют проектные команды, формируемые под каждый отдельный запрос. Различаются следующие виды проектов: • проекты подключения; • проекты по устранению неисправностей;
126 Глава 3 • проекты по расследованию причин низкого качества обслужи- вания. Общая схема проектной деятельности телекоммуникационной компа- нии по обслуживанию запросов клиентов приведена на рисунке 3.15. Стратегия внедрения проектного подхода Стратегия внедрения проектного подхода в телекоммуникационной компании должна быть определена в трех измерениях — проекты, люди и организационная структура. В краткосрочной перспективе наиболее ответственным является вопрос, какие проекты должны быть выбраны в качестве пилотных. Выбор пилотных проектов может осуществляться с учетом категории проектов (подключение/обслуживание/расследование) и их сложности (простые/сложные). Важнейшим направлением внедрения проектного подхода является формирование штата профессиональных менедже- ров проектов. Этот процесс может выглядеть как естественный отбор на основе анализа выполненных проектов. Первоначально в качестве менеджеров проектов используются сотрудники функциональных под- разделений компании. В дальнейшем из их числа выделяются будущие профессиональные менеджеры проектов. И наконец, принципиальным стратегическим вопросом является осуществление изменений организационной структуры компании, основ- ным вектором которых является переход к сильной матричной струк- туре. В рамках этой структуры создается отдельное подразделение — Проектный офис, в который переводится весь персонал управления проектами (менеджеры, координаторы, администраторы и т. д.). Отметим главные преимущества такого подхода: • Независимость менеджеров от функциональных руководителей обеспечивает возможность объективных оценок хода проекта и вклада отдельных подразделений в его реализацию, исключает негативные факторы, связанные с давлением на менеджера про- екта по административной линии. • Прямое подчинение Проектного офиса высшему руководству компании позволяет построить систему обеспечения качества управления проектами, включая механизмы мониторинга, экс- пертизы и аудита проектов. • Существование Проектного офиса как отдельного функциональ- ного подразделения обеспечивает возможность развития профес- сиональной компетентности сотрудников в области управления проектами, создание корпоративной методологии.
Проекты и процессы. Оператор связи как проектно-ориентированная компания 127 Рисунок 3.15. Проекты обслуживания запросов
128 Глава 3 Литература I. Tovb A., Tsipes G. Processes and projects: There and back again // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 2. Ципес Г., Товб А. Процессы и проекты — туда и обратно // Директор ин- форм. службы. 2006. № 7. 3. Ципес Г. Оператор связи как проектно-ориентированная компания // Ди- ректор информ, службы. 2004. № 12. 4. Ципес Г. Оператор связи как проектно-ориентированная компания // Сис- темные проблемы надежности, качества, информационных и электронных технологий. Информационные бизнес-системы. Материалы Междунар. конф, и Рос. науч, школы. Ч. 3. М.: Радио и связь, 2004. 5. Руководство к Своду знаний по управлению проектами. 3-е изд. РМВОК® Guide. М.: p.m.Office, 2004. 6. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003. 7. Гельфанд Е., Савич А., Циперман Г., Ципес Г. Бизнес-процессы: будни опти- мизации // Директор информ, службы. 2003. № 4. 8. Кендалл Дж., Роллинз С. Современные методы управления портфелями проектов и офис управления проектами. Максимизация ROI / Пер. с англ. М.: ЗАО «ПМСОФТ», 2004. 9. Мартиросян В., Валишев Р., Сизов М., Либерзон В. Опыт внедрения кор- поративного управления проектами на Центральном телеграфе // 17-й Все- мир. конгресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 10. Урбанович В. Опыт создания системы управления проектами в ОАО «Ка- захтелеком» // 17-й Всемир. конгресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 11. Seitz D. An Integrated Design Approach for High Performance Project Management Systems at Deutsche Telekom Group // 19th IPMA World Congress, New Delhi, 13—16 November 2005. 12. Королев С., Савич А. Системы управления деятельностью телекоммуника- ционных компаний // Информкурьерсвязь. 2004. № 11. 13. Управленческий консалтинг. Путеводитель по рынку профессиональных услуг. М.: Коммерсант XXI; Альпина Паблишер, 2002. 14. Ципес Г.Л. Ключевые показатели деятельности в проектно-ориентирован- ной компании // Директор информ, службы. 2003. № 5. 15. Tsipes G. То manage projects through key performance indicators // 18th IPMA World Congress, Budapest, June 2004.
Глава 4 Проекты и продукты. Проектные и продуктовые группы в транспортной компании
Содержание главы 4 4.1. Краткий обзор методологии..................................... Продуктовый подход............................................ Проекты в жизненном цикле продукта............................ 4.2. Продуктовая структура транспортной компании .................. 4.3. Процессы жизненного цикла продукта............................ Структура жизненного цикла продукта........................... Организация процессов......................................... Продуктовый цикл как программа................................ 4.4. Продуктовые группы............................................ Организация продуктовых групп................................. Система мотивации в продуктовых группах....................... Эволюция продуктовых групп.................................... 4.5. Внедрение продуктового подхода................................ Стратегии внедрения........................................... Стандарт управления продуктами................................ Литература......................................................... 131 131 133 134 137 137 139 140 142 142 143 144 145 145 147 150
4.1. Краткий обзор методологии Продуктовый подход Общей тенденцией бизнеса компаний в условиях рыночной экономи- ки является переход от приоритета производства, преследующего цель снижения издержек, к приоритету потребностей клиента, обеспечивае- мых за счет улучшения характеристик продукта и увеличения усилий по его продвижению на рынок. Изменяющиеся приоритеты бизнеса должны поддерживаться на уровне организации бизнес-процессов компании (см. рис. 4.1). По- скольку в рыночных условиях успех компаний в значительной степени определяется качеством разработки и оперативностью вывода на ры- нок новых продуктов, своевременной адаптацией продукта к измене- ниям внешних условий (рыночной ситуации, появлению новых техно- логий и т. д.), эффективность реализации именно этих процессов яв- ляется одним из важнейших факторов успеха. Основными ограничениями для компаний, которые делают упор на создание и продвижение технологически сложных продуктов, обьино являются организационная структура и бизнес-процессы, плохо при- способленные для быстрого реагирования на запросы клиентов и опе- ративной разработки соответствующих этим запросам продуктов. Одним из признанных способов осуществления быстрых и эффек- тивных технологических изменений и решения вопросов координации и ориентации организации на сопровождение продукта в течение всего его жизненного цикла является продуктовый подход. Он известен под названием Integrated Product and Process Development (IPDD) и по- дробно описан в открытых материалах Министерства обороны США (см., например, [1]). Отличительными особенностями продуктового подхода являются: • соответствие структуры бизнес-процессов компании жизненно- му циклу продукта, включающему этапы маркетинговых исследо- ваний, проектирования, разработки и внедрения, продвижения продукта на рынок и продажи, сопровождения продукта; 131
132 Гпава 4 Рисунок 4.1. Эволюция приоритетов бизнеса
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 133 • реализация полного продуктового цикла в рамках единой про- граммы, обладающей всеми необходимыми атрибутами — опре- делением содержания работ, графиком и стоимостью их выпол- нения и т. д.; • использование продуктовых групп, обеспечивающих возможность концентрации в единой команде всех необходимых специалис- тов, рационального распределения и контроля ресурсов, моти- вации сотрудников на результат. Таким образом, при переходе к продуктовой организации бизнес-про- цессы компании реорганизуются в соответствии с жизненным циклом продуктов. Кроме того, изменяется структура ответственности долж- ностных лиц компании: наряду с владельцами процессов появляются владельцы продуктов, на которых ложатся обязанности по совершен- ствованию продуктов, осуществлению быстрых технологических измене- ний, а также решение вопросов координации и ориентации компании на сопровождение продукта в течение всего жизненного цикла. Проекты в жизненном цикле продукта Грамотное применение продуктового подхода, по утверждению его ав- торов, обеспечивает снижение сроков разработки и вывода на рынок новых продуктов, затрат на разработку и производство продукта, раз- личного рода рисков, а также улучшение качества как процессов, так и конечного продукта. Бросается в глаза полное совпадение преимуществ, достигаемых за счет применения продуктового и проектного подходов. Между тем вопросам взаимосвязи продуктов и проектов в литера- туре по менеджменту проектов большого внимания традиционно не уделяется. В последней редакции стандарта PMBOK®Guide появилось лишь несколько строк о взаимосвязи жизненных циклов продукта и проекта (см. [2]). При этом роль проектного подхода в рамках продук- тового трактуется очень узко. В полном соответствии с пониманием продукта как результата проекта проектному подходу отводится место лишь на стадии разработки продукта. Нам представляется, что такой подход резко ограничивает реальные возможности применения проект- ного подхода в продукто-ориентированных компаниях. В главе 3 на примере бизнес-процессов оператора связи показано, что в проектной форме могут выполняться различные этапы жизненного цикла продукта. Это означает, что проектный и продуктовый подходы неизбежно будут использоваться совместно. А это, в свою очередь, приводит к необходимости гармонизации этих подходов. В компании Hella, имеющей более чем столетнюю историю созда- ния продуктов в области автомобильной промышленности, управле-
134 Глава 4 ние проектами рассматривается как механизм, связывающий воедино три основных фактора успеха компании — инновационные подходы, креативный персонал и гибкие процессы совершенствования продук- тов [3]. Принцип гармонизации проектного и продуктового подходов в компании Hella сформулирован следующим образом: стандарты управ- ления продуктами отвечают на вопросы «Что нам придется сделать?» и «Когда нам придется это сделать?», в то время как стандарты управле- ния проектами отвечают на вопрос «Как это нужно делать?». Одной из важных проблем, возникающих при гармонизации про- ектного и продуктового подходов, является необходимость определе- ния места проектных организационных структур внутри продуктовых. И те и другие являются структурами матричного типа. И те и другие представляют собой временные структуры, создаваемые на период, соответственно, реализации проекта или существования продукта. Проект, по определению, имеет ограниченное время реализации. Продуктовый же цикл такого ограничения не имеет. В нем требуется долговременная ассоциация необходимых специалистов с продуктовой группой. Это означает, что участники проектных групп, реализовывав- ших отдельные фазы жизненного цикла продукта, скорее всего, и дальше будут привлекаться к работе в продуктовой группе. Этот тезис можно проиллюстрировать следующим примером. В ра- боте [4, с. 28] описывается ситуация, традиционно возникающая после завершения проекта внедрения в компании ERP-системы *. «ERP — это что угодно, только не временная работа, которую можно выпол- нить и забыть» — это слова бизнес-специалистов компании, которые, будучи вовлеченными в проект, оказались связанными с ним на все время существования этой системы в компании. Иными словами, факти- чески они составили устойчивую продуктовую группу, ассоциирован- ную с ERP-системой, которая трактуется в данном случае как продукт, предназначенный для внутренних нужд компании. В еще большей сте- пени это относится к ИТ-специалистам компании. Таким образом, проектная группа естественно перерастает в продук- товую, а та, в свою очередь, может стать постоянным подразделением компании или даже выделиться в самостоятельную компанию. 4.2. Продуктовая структура транспортной компании В качестве продукта транспортной компании (на примере авиапере- возчика) мы рассматриваем организованную услугу по пассажирской или грузовой авиаперевозке, имеющую точно определенные потреби- 1 ERP-система — программное обеспечение планирования ресурсов предприятия.
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 135 тельские свойства и конкретные условия ее предоставления. Из двух возможных подходов к формированию продуктовой линейки, пред- ставленных на рисунке 4.2, в данной книге взят вариант, в котором продукт представляет собой перевозку по определенному маршруту, входящему в сезонное расписание. В принципе продуктовая структура компании, особенно с учетом проектов внедрения ERP-систем, может быть гораздо более сложной. Кроме бизнес-продуктов, ориентированных на внешнего клиента, в ней могут присутствовать и продукты, предназначенные для внутрен- него использования. К таким внутренним продуктам относятся, на- пример, различные платформенные (программные, технологические или технические) продукты. Продуктовую группу бизнес-продукта должны в основном состав- лять специалисты, владеющие содержательной стороной сопровожде- ния продукта. В группу включаются также специалисты технических служб, обеспечивающие поддержку продукта на платформенном уров- не. И наоборот, в продуктовую группу внутреннего продукта должны в основном входить технические специалисты, дополненные специалис- тами, владеющими содержательной стороной. В результате возникает пересечение продуктовых групп, показанное на рисунке 4.3. «Вертикальные» продукты — это продукты, создаваемые в рамках основной деятельности компании и предназначенные для внешнего клиента (бизнес-продукт). К «вертикальным» продуктам авиапере- возчика относятся различные маршруты. У телекоммуникационной компании это могут быть, например, предоставление услуг по ана- Рисунок 4.2. Варианты формирования продуктов авиаперевозчика
136 Глава 4 Рисунок 4.3. Продуктовая структура транспортной компании
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 137 логовой и цифровой связи, предоставление доступа в Интернет, про- ведение видеоконференций, услуги карточного доступа к ресурсам ком- пании и др. «Горизонтальные» продукты — технологические решения, разраба- тываемые в компании или предоставляемые сторонними организация- ми, обеспечивающие информационную поддержку бизнес-процессов компании. К «горизонтальным» продуктам авиаперевозчика могут быть отнесены сезонное расписание, корпоративная отчетность, системы Front Office и др. 4.3. Процессы жизненного цикла продукта Структура жизненного цикла продукта Типовая структура жизненного цикла продукта включает следующие стадии (см. рис. 4.4): • Маркетинговые исследования — от анализа потребностей рын- ка до формулирования идеи продукта. • Проектирование, разработка и модернизация — от принятия решения о создании/модернизации продукта до получения го- тового продукта. • Внедрение продукта — подготовка технической и организаци- онной инфраструктуры к производству продукта. • Продвижение продукта на рынок — представление продукта потенциальным клиентам, партнерам и другим контрагентам. • Продажи продукта с применением различных каналов сбыта. • Производство и сопровождение — оказание проданной услуги и исполнение сопутствующих обязательств. Основной задачей маркетинговых исследований является поиск пер- спективных направлений бизнеса. С этой целью осуществляются мо- Маркетинг говые \ исследо- / вания / Проекти- \ рование \ и разра- / ботка / Внедрение j Продви- \ жение \ на рынок / Продажи \ продукта / Произ- \ водство \ и сопро- / вождение / t Рисунок 4.4. Типовая структура жизненного цикла продукта
138 Глава 4 ниторинг и анализ состояния рынка авиаперевозок, выявление новых тенденций на рынке авиаперевозок и направлений развития конкурен- тов, определение новых потребностей пассажиров. Результатами мар- кетинговых исследований являются идеи по модернизации старых и по внедрению новых маршрутов. Эти идеи детально прорабатываются на этапе проектирования и раз- работки (или модернизации) маршрутов. На этом этапе уточняются требования к маршруту и разрабатывается технико-экономическое обо- снование с учетом возможных соглашений со стратегическими партне- рами. После «защиты» маршрута осуществляются его внесение в сезон- ное расписание и систему бронирования, разработка и утверждение тарифов, цен и условий по маршруту. На этапе внедрения маршрута проводятся планирование слотов под маршруты, обеспечение сервиса компании в аэропортах и поставок для маршрута, подготовка технической и иной информации, обучение и подготовка персонала авиакомпании. На этапе продвижения маршрута на рынок осуществляется реклам- ная кампания. Партнерам предоставляется необходимая информация о маршруте, проводятся консультации для агентов. Процесс продаж включает: • планирование объемов продаж; • бронирование мест в системе — прием заявки и предложение дополнительных услуг, проверку предварительного бронирова- ния, информирование клиента об изменении в бронировании, разработку и предложение альтернативных вариантов; • оформление авиаперевозочных документов; • организацию и исполнение агентских продаж; • контроль, учет и анализ результатов продаж. Производство и сопровождение перевозки предполагают: • планирование перевозки — подготовку информации о плани- руемой загрузке воздушного судна, составление суточного пла- на работы операционного центра на следующие сутки; • подготовку перевозки — сбор информации о готовности к обес- печению рейса, получение разрешений на выполнение рейса, оперативное изменение расписания, планирование приема гру- за, формирование заказа бортового питания на рейс, экипажей, полетного задания и бортовой документации;
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 139 • исполнение авиаперевозок и оперативное управление — обслу- живание пассажиров, обслуживание грузов, работу в ситуациях сбоя, работу с претензиями пассажиров; • учет и контроль суточного плана и выполнения смежниками обязательств, анализ производственной деятельности. В таблице 4.1 представлены основные процессы авиаперевозчика в разрезе как этапов жизненного цикла продукта, так и традиционных составляющих управленческого цикла. Организация процессов С точки зрения организации работы в рамках продуктового подхода выделяются две ключевые роли — владельцы продуктов и владельцы процессов. Владельцы продуктов обеспечивают поддержку всего жизненного цикла продукта и отвечают за потребительские свойства продукта, со- блюдение сроков и бюджета разработки продукта и его эффективность при реализации на рынке. Владельцы продуктов возглавляют продук- товые группы, реализующие основную деятельность, которая дает ком- мерческий результат (маркетинг, разработку, внедрение, продажу и исполнение перевозок). Деятельность владельцев продуктов, которые являются своего рода «внутренними коммерсантами», должна соответствовать маркетинговой стратегии компании, в частности представлениям об оптимальной сети маршрутов, структуре парка воздушных судов, ожидаемых финансо- вых результатах и т. д. Вместе с тем владельцы продуктов обязаны со- блюдать регламент бизнес-процессов как на уровне жизненного цикла продукта, так и на уровне детальных процессов. Все отклонения от регламента бизнес-процессов, обусловленные конкретными особенно- стями продукта или рыночными обстоятельствами, должны согласо- вываться с соответствующими владельцами процессов. Владельцами процессов, составляющих жизненный цикл продукта, являются руководители функциональных подразделений, которые обес- печивают методологическую и технологическую поддержку процессов, необходимых при реализации отдельных этапов жизненного цикла продуктов. В зону ответственности владельцев процессов входят все виды ресурсного обеспечения перевозок (материально-техническое обеспечение, информационные технологии, финансы, персонал, сер- вис воздушного судна, безопасность, качество и т. п.). Владельцы про- цессов отвечают также за качество работы специалистов, выделенных подразделением в продуктовую группу, и за соблюдение ими техноло- гии бизнес-процессов.
140 Глава 4 Таблица 4.1. Структура основных процессов авиаперевозчика Жизненный цикл Управленческии\^^ ЦИКЛ Маркетинговые исследования Проектирование, разработка и модификация продукта Целеполагание, прогнозирование и планирование Разработка маркетинговой стратегии Планирование маркетинговых мероприятий Выработка требований к продуктам Оценка возможности улучшений Планирование сроков, персонала и финансов Исполнение, оперативное управление Мониторинг рынка Оценка продуктов Разработка предложений Разработка проектов расписания,тарифов и цен Ввод в действие, изменения расписания и его оптимизация Контроль и учет исполнения Контроль выполнения стратегии и маркетинговых планов Контроль сроков и качества маршрутов и расписания Анализ результатов Анализ процесса и результатов маркетинговой деятельности Анализ процесса и результатов разработки продуктов и составления расписания Продуктовый цикл как программа На владельца продукта, таким образом, ложится общая, в том числе финансовая, ответственность за вновь создаваемый продукт. Он фак- тически становится во главе сквозной программы, охватывающей все стадии жизненного цикла продукта, а успешность реализации этой программы будет оцениваться конечными коммерческими показате- лями (например, показателями продаж продукта). С точки зрения управления программой создания продукта основ- ными для владельца продукта являются вполне традиционные для про- ектного подхода задачи: определение основных характеристик продук-
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 141 Внедрение продукта Продвижение продукта на рынок Продажи продукта Производство и сопровождение Планирование слотов под маршруты Прогнозирование исправности парка воздушных судов Разработка плана мероприятий по продвижению продуктов, рекламе и PR Разработка плана продаж авиаперевозок Планирование деятельности по организации и управлению авиаперевозками Внесение рейсов в системы бронирования Информирование о маршруте Консультирование агентов и подготовка персонала Организация сервиса в аэропортах Проведение мероприятий (рекламных акций, PR-кампаний) Осуществление процесса продаж собственных и агентских авиаперевозок Исполнение авиаперевозок и оперативное управление Контроль сроков и качества внедрения продуктов Контроль исполнения плана мероприятий по продвижению продуктов Контроль и учет продаж Контроль процессов авиаперевозок и качества обслуживания Анализ процесса и результатов внедрения продуктов Анализ результатов мероприятий по продвижению продуктов Анализ результатов продаж Анализ выполненных авиаперевозок та и его структурных элементов, формирование и контроль единого бюджета программы, определение и контроль ключевых вех, форми- рование продуктовой группы (возможно, с привлечением субподряд- ных организаций), анализ и управление рисками. Именно владелец продукта принимает решение о запуске отдель- ных проектов в рамках этой программы как на стадиях первоначально- го создания продукта, так и позднее, на стадии производства и сопро- вождения, когда возникает необходимость модификации продукта или снятия его с производства. Он же несет общую ответственность за успеш- ное завершение этих проектов.
142 Глава 4 4.4. Продуктовые группы Организация продуктовых групп Продуктовая группа — это организационно оформленная многофунк- циональная команда по созданию, внедрению и сопровождению про- дукта, которая формируется на все время его существования и возглав- ляется владельцем продукта. Как уже отмечалось, целью образования продуктовой группы яв- ляется повышение эффективности деятельности компании в области разработки новых продуктов за счет обеспечения долговременной (на протяжении всего жизненного цикла) ассоциации с этим продуктом специалистов, отвечающих за его создание, эксплуатацию и разви- тие. Поэтому в состав группы целесообразно включать всех необходи- мых для ее деятельности специалистов из различных подразделений компании. Специалисты могут привлекаться на постоянной или временной основе: • «постоянные» специалисты участвуют в работе продуктовой груп- пы регулярно на условиях полной занятости и являются ядром группы; • «временные» специалисты участвуют в работе продуктовой груп- пы по мере возникновения необходимости и могут привлекаться к работе на условиях как полной занятости в течение какого-то периода времени, так и неполной занятости (причем они могут одновременно сопровождать несколько продуктов). Часть работ, связанных с жизненным циклом продукта, тем не менее может выноситься за рамки продуктовой группы и исполняться посто- янными подразделениями компании. Главным образом это относится к этапам продажи и сопровождения продуктов. В этом случае владелец продукта должен обеспечить осуществле- ние следующих действий: • передачу исполнителю необходимых технологий и обучение спе- циалистов; • авторский надзор за соблюдением технологии; • мониторинг и анализ результатов деятельности этих подразде- лений по своему продукту.
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 143 Система мотивации в продуктовых группах Система мотивации в продуктовых группах должна обеспечить реше- ние двух основных задач: • повышение заинтересованности специалистов в работе продук- товых групп; • повышение заинтересованности подразделений (владельцев ресурсов) в выделении сотрудников для работы в продуктовых группах. Для решения этих задач в бюджете продукта образуется фонд мате- риального поощрения, формируемый за счет отчислений от реализации продукта (услуги). Размер отчислений первоначально определяется в биз- нес-плане продукта. В дальнейшем размеры отчислений могут быть изме- нены руководством компании по представлению владельца продукта. Часть фонда материального поощрения используется для мотива- ции сотрудников продуктовой группы. Размер поощрения определяет- ся, исходя из ставки специалиста, его реальной занятости в работах по продукту, и может корректироваться владельцем продукта. Оставшаяся часть фонда расходуется на материальное поощрение подразделений — владельцев ресурсов. Размер поощрения подразделе- ния определяется как сумма поощрений всех специалистов этого под- разделения, занятых в работах по продукту. Направления использова- ния этих средств определяются руководителем подразделения, в том числе на повышение квалификации сотрудников, премии сотрудни- кам и руководителям. Основанием для премирования продуктовых групп должна быть фор- мализованная система оценок, ориентированная на бизнес-цели компа- нии. Такая система оценок может включать следующие показатели: • финансовую эффективность сети маршрутов; • эффективность инвестиций в новые маршруты; • спрос на маршрут; • эффективность продаж; • коэффициент загрузки воздушных судов; • оперативность внедрения новых маршрутов; • удовлетворенность клиента полученной услугой и т. д. Для оценки деятельности продуктовых групп могут применяться также системы показателей, приведенные в таблице 4.2 в формате сба- лансированной системы показателей.
144 Глава 4 Таблица 4.2. Сбалансированная система показателей для продуктового подхода Критические факторы ^-^успеха Перспективы'\. Ориентация на удовлетворение клиента Учет требований и возможностей рынка Снижение издержек Финансы Объем дебиторской задолженности Финансовая эффективность продукта Продуктивность использования капитала Клиенты Полезность услуги для клиента Лояльность клиентов Адекватность предложения услуги потребностям рынка Привлекательность рынка Бизнес-процессы — Коэффициент оперативности выхода на рынок Продуктовая утилизация ресурсов Инновации и персонал — — Формирование корпоративного знания Эволюция продуктовых групп Естественное направление эволюции продуктовой группы — это ее оформление в самостоятельное структурное подразделение компании или выделение в отдельную компанию холдинга (особенно если про- дукт оказывается успешным). Но вновь возникающее подразделение является кросс-функциональным по своей сути, что приводит к проти- воречиям, связанным с его подчиненностью. По этой причине процес- сы образования и эволюции продуктовых групп должны быть хорошо структурированы и не должны носить стихийный характер. На рисунке 4.5 показан процесс образования продуктовых групп в результате успешного создания нового продукта компании. Сотрудни- ки проектной группы, реализовывавшей первые стадии продуктового цикла, сохраняют связь с продуктом, оставаясь пока в своих функцио- нальных подразделениях и работая по продукту неполное время. На рисунке 4.6 представлен процесс образования продуктовой груп- пы и последующей ее эволюции в постоянное структурное подразде- ление компании, в котором собраны все специалисты, необходимые
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 145 «Вертикальные» продуктовые группы Проект разработки новой услуги Продажа, сопровождение и развитие услуги Проектная группа IHJ П;.и>Д7кгова-,> ||,чи'ч «Горизонтальные» продуктовые группы Рисунок 4.5. Образование продуктовых групп Разработка системы Эксплуатация и развитие системы корпоративной —к корпоративной отчетности отчетности м—/ .-„..„г,- ЯП Продуктовая Служба технический Проектная группа ,: ...’ ।рупна поддержки Рисунок 4.6. Эволюция продуктовых групп для эксплуатации и развития продукта (в данном случае внутреннего продукта, используемого в компании, — Системы корпоративной от- четности). 4.5. Внедрение продуктового подхода Стратегии внедрения При всех отмеченных достоинствах продуктового подхода нельзя не принимать во внимание и трудности, с которыми сталкивается внед- ряющая его компания.
146 Глава 4 Эти трудности являются, как это часто бывает, продолжением до- стоинств подхода: • необходимость постоянного контроля использования ресурсов и их учета, что приводит к дополнительным затратам; • высокие требования к квалификации, личным и деловым каче- ствам работников, входящих в продуктовые группы; • возможность возникновения конфликтных ситуаций между ру- ководителями продуктовых групп и руководством компании, вызванных самостоятельностью владельцев продуктов. Учитывая все это, а также то обстоятельство, что внедрение продукто- вого подхода ведет к серьезной реорганизации бизнес-процессов и орга- низационной структуры компании, представляется целесообразным выделять пилотную фазу внедрения. Рассмотрим два возможных вари- анта пилотных стратегий. Стратегия пилотных этапов заключается в том, что в качестве пи- лотного объекта внедрения выбирается один из этапов жизненного цикла продукта и внедряются процессы, соответствующие этому эта- пу, по всем продуктам компании. Преимущество этого варианта состоит в том, что сроки пилотно- го проекта ограничены рамками одного этапа и эффект внедрения мо- жет проявиться достаточно быстро. К его недостаткам можно отнести сложность тиражирования опыта пилотного проекта на остальные эта- пы жизненного цикла продукта в силу существенных различий этих этапов. Стратегия пилотных продуктов предполагает, что в качестве пилот- ного объекта внедрения выбирается один из продуктов компании и для него внедряются процессы всех этапов жизненного цикла. В слу- чае применения этой стратегии представляется целесообразным вы- брать в качестве пилотного продукта один из вновь разрабатываемых продуктов компании. Преимущество этой стратегии состоит в том, что опыт пилотного проекта легко тиражируется на любые другие продукты компании. Однако эффект внедрения при такой стратегии проявляется только по достижении заключительного этапа жизненного цикла. Необходимо отметить, что применение этой стратегии подразуме- вает использование специальных инструментов продуктового подхода уже на фазе пилотного внедрения. Речь, прежде всего, идет о необхо- димости создания продуктовой группы по пилотному продукту.
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 147 Стандарт управления продуктами Основным содержанием стандарта управления продуктами является описание процессов продуктового цикла (см. табл. 4.1). Если в каче- стве формы реализации этих процессов применяются проекты (а для большинства этапов жизненного цикла продукта это является естест- венной и эффективной формой), то в процедуры должны быть включе- ны соответствующие элементы проектного управления — календарное и ресурсное планирование, управление рисками, изменениями и т. д. Внедрение продуктового подхода также требует специальных норма- тивно-распорядительных документов, таких как Положение о продукто- вых группах (как общий документ компании) и, возможно, Положение о продуктовых группах по конкретным продуктам. Эти документы должны регламентировать следующие вопросы: • задачи и функции продуктовой группы на всех стадиях жизнен- ного цикла продукта; • порядок формирования продуктовой группы, привлечения и освобождения специалистов; • порядок взаимодействия продуктовой группы с постоянными структурными подразделениями компании; • задачи, права, обязанности и ответственность членов продук- товой группы (ролевые инструкции). Использование продуктовых групп требует изменений в системе бюдже- тирования компании, учитывающих роль таких групп в качестве цент- ра затрат и центра прибыли, а также изменений в системе мотивации. Работы по созданию института продуктовых групп заключаются в основном в подготовке необходимых нормативно-распорядительных документов. Перечень и состав соответствующих работ приведены в таблице 4.3. Положение о продуктовой группе (извлечения) 1. Общие положения 1.1. Продуктовая группа — это организационно оформленная многофункциональ- ная команда по созданию, внедрению и сопровождению продукта, которая фор- мируется на все время существования продукта (услуги). 1.2. Целью организации продуктовых групп является максимизация финансовых результатов деятельности компании. Эта цель достигается путем специальной (продуктовой) организации процессов создания, внедрения и сопровождения продуктов при концентрации в составе продуктовой группы всех необходимых
148 Глава 4 Таблица 4.3. Этапы работ в области создания института продуктовых групп № Этап работ Содержание работ Ответственный 1 Разработка типового документа «Положение о продуктовой группе» Формулирование целей продуктовой группы Определение функций и задач продуктовой группы на различных стадиях жизненного цикла продукта Разработка регламентов взаимодействия продуктовой группы со структурными подразделениями компании Определение принципов формирования продуктовой группы, планирования и учета рабочего времени Задачи, права и ответственность руководителя и членов продуктовой группы Директор по персоналу 2 Разработка системы продукто- ориентированного бюджетирования Формирование типового бюджета продукта Определение правил взаиморасчетов продуктовых групп и постоянных подразделений компании Финансовый директор 3 Разработка системы мотивации Разработка нормативов трудозатрат Разработка правил формирования премиального фонда по продуктам Определение принципов мотивации членов продуктовых групп Определение принципов мотивации сотрудников, не занятых в продуктовых группах Директор по персоналу Финансовый директор специалистов, введении системы рационального распределения и контроля ресур- сов, мотивации сотрудников по результату и делегировании всех необходимых полномочий и ответственности Руководителю продуктовой группы. 1.3. Управление продуктовой группой осуществляет Руководитель группы, назна- чаемый на должность и освобождаемый от нее Генеральным директором. 1.4. В продуктовую группу может быть включен любой специалист компании неза- висимо от того, в каком подразделении он работает. Состав группы может ме- няться, но предпочтительной является долговременная ассоциация специалис- тов с продуктом.
Проекты и продукты. Проектные и продуктовые группы в транспортной компании 149 1.5. По продуктовому признаку управляющий персонал компании разделяется на три категории: владельцы ресурсов (руководители структурных подразделений), владельцы продуктов (руководители продуктовых групп) и администрация. 1.6. Координацию деятельности продуктовых групп по отношению к общей стра- тегии компании осуществляет Координационный совет по продуктам. В обязан- ности совета входит наблюдение, контроль и координация действий продуктовых групп для достижения ими стратегических целей в соответствии с факторами успеха и заданными ключевыми показателями деятельности компании. Совет дей- ствует на постоянной основе по утвержденному Генеральным директором регла- менту. Руководителем Координационного совета по должности является замес- титель Генерального директора по развитию. В состав Координационного совета входят по должности заместители Генерального директора по направлениям дея- тельности компании и Главный технолог по продуктам. 2. Принципы формирования продуктовой группы, планирование и учет рабочего времени 2.1. Формирование продуктовой группы осуществляет Руководитель продуктовой группы, направляя запросы на выделение ресурсов в соответствующие подраз- деления Компании. Запрос должен содержать указание специализации и квали- фикации ресурса, периоды использования и предполагаемую загрузку. Основаниями для запроса ресурсов могут являться: 2.2. На стадии маркетинговых исследований — решение Генерального директора или Координационного совета по продуктам о поиске новых направлений развития. На стадии бизнес-планирования — решение Координационного совета по про- дуктам о разработке бизнес-плана. На стадии планирования проекта создания продукта/услуги —- решение Коорди- национного совета по продуктам о начале работ. На последующих стадиях — утвержденный план создания и бюджет продукта. 2.3. Руководители подразделений (владельцы ресурсов) должны выделить тре- буемый ресурс или дать мотивированный отказ. При возникновении конфликтов ресурсов проблема может быть вынесена на рассмотрение Координационного совета по продуктам, решение которого является окончательным. 2.4. Выделенный ресурс не может быть отозван из продуктовой группы в одно- стороннем порядке без согласия Руководителя продуктовой группы. 2.5. Для каждого члена продуктовой группы составляется график его работы в продуктовой группе. Учет рабочего времени сотрудников ведется Руководителя- ми проектов, реализуемых в рамках жизненного цикла продуктов. Отчеты о рабо- чем времени заполняются еженедельно и утверждаются Руководителем продук- товой группы и руководителями соответствующих подразделений Компании — владельцев ресурсов. 3. Задачи членов продуктовой группы 3.1. Задачи Руководителя продуктовой группы: • Формирование идеи нового продукта. • Формирование системы мотивации сотрудников продуктовой группы. • Формирование определения продукта/услуги с подробным описанием его по- требительских свойств. • Формирование состава работ по созданию/модификации продукта, определе- ние их приоритетности, объемов, последовательности и длительности. • Формирование состава продуктовой группы. • Формирование укрупненного календарного плана и бюджета.
150 Глава 4 3.2. Задачи Руководителя проекта: • Формирование и контроль плана-графика проекта. • Организация и координация работ по проекту. • Распределение ресурсов в проекте, учет и контроль их использования. • Оперативное реагирование на отклонения по ходу проекта. 3.3. Задачи специалиста по маркетингу: • Установление проблем и потребностей клиентов. • Определение емкости и структуры рынка. • Анализ экономической эффективности продукта. • Определение первичных потребительских функциональных требований к про- Дукту/услуге. • Разработка требований к содержанию и внешнему виду рекламной продукции. • Проведение презентаций. • Определение каналов сбыта, возможных посредников. Литература 1. DoD Guide to integrated product and process development Office of the Under Secretary of Defense (Asquisition and Technology). Washington, DC 20301 3000. February 5, 1996. http://www.amet.gov/Library/OFPP/BestPractices/pbsc/ library/dod-guide-to-integrated.pdf. 2. A Guide to the Project Management body of knowledge (PMBOK®Guide). 3d ed. PMI, 2004. 3. Reitz S., Deihl C. Product development process: the chance for global stan- dardization and synchronization of development activities 11 18th IPMA World Congress, Budapesht, June 2005. 4. Кох К. Самая главная команда // Директор информ, службы. 2001. № 5.
Глава 5 Проекты и стандарты. Стандарт управления проектами строительной компании
Содержание главы 5 5.1. Краткий обзор методологии................................153 Управление проектами — искусство, наука, ремесло..........153 Система управления проектами..............................155 Структура системы управления проектами.................156 Внедрение системы управления проектами....................158 5.2. Управление проектами в строительных компаниях.............161 5.3. Политика управления проектами............................163 Классификация строительных проектов.......................164 Жизненный цикл проекта....................................167 Функциональные роли и ответственность участников проекта...168 5.4. Операционный стандарт....................................171 Структура операционного стандарта.........................171 Процедуры управления проектами............................173 Стандарт исполнителя...................................173 Стандарт заказчика.....................................178 Гармонизация стандартов участников проекта.............181 5.5. «Большой стандарт для маленькой компании»................186 Параметры организации................................... 187 Характеристика компании................................187 Персонал...............................................187 Причины начала работ по созданию стандарта управления проектами........................................ 188 Первый этап — изучить и попробовать.......................188 Стратегия внедрения проектного подхода.................188 Бюджет первого этапа...................................189 Внутренние консультанты................................190 Пилотные проекты.......................................191 Результаты первого этапа...............................191 Второй этап — разработать и внедрить......................191 Задачи второго этапа...................................191 Участники второго этапа проекта........................192 Содержание работ.......................................193 Бюджет второго этапа...................................193 Результаты второго этапа...............................193 5.6. Управление проектами в строительстве — технология или философия?.....................................194 Девелоперский проект...................................194 Сервисная модель строительного проекта.................195 «Ценность за деньги»...................................195 Литература196
5.1. Краткий обзор методологии Управление проектами — искусство, наука, ремесло Любая система (биологическая, социальная, производственная, инфор- мационная) в процессе своего существования претерпевает определен- ные изменения, связанные с внешними и внутренними факторами. Сегодня, когда успешность компании во многом определяется тем, насколько организация ее бизнеса соответствует быстро изменяющим- ся условиям, необходимы методы и средства, которые позволяют осу- ществлять такие изменения целенаправленно. Проект как особая форма реализации изменений предполагает, что эти изменения должны быть реализованы в рамках определенных огра- ничений по срокам, стоимости и качеству. Наличие этих ограничений предъявляет специальные требования к методам управления, в частно- сти требование о концентрации полномочий и ответственности за весь проект в целом в руках одного человека — Руководителя проекта и создании команды проекта, отчуждаемой на время исполнения проек- та от подразделений компании. Проект становится центром затрат и прибыли, что позволяет организовать учет человеческих, материаль- ных и финансовых затрат и выстроить систему мотивации, базиру- ющуюся на результатах конкретных проектов. Деятельность многих компаний в самых разных областях осущест- вляется в проектной форме. В то же время известно, что даже в не слишком сложных проектах возникают проблемы. Характерные внеш- ние их проявления — это недовольство заказчика и собственного руко- водства, срыв сроков, превышение смет, конфликты внутри команды проекта и др. Профилактика и преодоление этих проблем являются важнейшими составляющими деятельности управленческого персона- ла проекта и должны поддерживаться соответствующими стандартами, методологией и инструментальными средствами. 153
154 Глава 5 Таким образом, как и любой другой вид профессиональной дея- тельности, деятельность по управлению проектами порождает разви- тие самостоятельного рынка продуктов и услуг. Примеры некоторых из них приведены на рисунке 5.1. Управлять проектами должны профессионалы, но количество насто- ящих профессионалов в этой области в России относительно невелико и очевидно отстает даже от осознанного спроса. Носителями искусства управления проектами являются конкретные личности, в которых со- единены определенные человеческие качества, опыт и знания. Далеко не каждая компания, которая реализует проекты, связанные с ее биз- нес-деятельностью, имеет (или даже может себе позволить иметь) в своем штате подобных специалистов. Такая услуга, как предоставле- ние персонала управления проектами (менеджеров проектов), доста- точно широко распространена в мире. Она существует и в России, хотя здесь привлечение профессионала извне чаще бывает экстренной мерой, применяемой в условиях кризиса в проекте. Важнейшими элементами, влияющими на развитие и формирование данного сегмента рынка, являются такие продукты, как обучающие Рисунок 5.1. Структура бизнеса управления проектами
Проекты и стандарты. Стандарт управления проектами строительной компании 155 курсы и сертификационные программы. Очевидно, при прочих равных условиях предпочтение будет отдано сертифицированным специалис- там по управлению проектами и консалтинговым компаниям, распола- гающим такими специалистами. К настоящему времени накоплен значительный опыт по методоло- гии управления проектами, основными областями которого призна- ются управление по временным и стоимостным параметрам, управле- ние персоналом, рисками, изменениями и т. д. Продукты и услуги в научно-методическом секторе рынка предлагаются в разнообразных формах — от учебной литературы до специализированных программ- ных средств, от отдельных образовательных программ до сертифика- ции по национальной и международным программам. Хотя от менеджеров проектов зависит многое, но, безусловно, не все. Для успешной и эффективной работы менеджера и всей команды проекта должны быть созданы определенные условия, позволяющие в полной мере реализовать их возможности. Важно, чтобы существу- ющие обычно по отдельности методические, инструментальные и иные средства, необходимые для успешного управления проектом, были объ- единены в одну систему, в рамках которой задачи менеджера и коман- ды проекта могут решаться с наибольшей эффективностью. Другими словами, требуется создание и обеспечение эксплуатации интегриро- ванной системы управления проектами (СУП). Система управления проектами В проектной форме может осуществляться деятельность компании в самых разных областях. К ним относятся, например: • строительство, реконструкция и капитальный ремонт зданий и сооружений; • установка и наладка оборудования; • внедрение информационных технологий; • проведение работ исследовательского и методологического ха- рактера; • обучение и т. д. Кроме того, как мы отмечали в предыдущей главе, в проектной форме часто целесообразно выполнять и некоторые задачи операционного характера в рамках стационарных технологических или деловых процес- сов. Это относится к ситуациям, когда реализуются пилотные прогоны новых или изменившихся процессов, а также к случаям, когда имеют- ся риски срыва сроков и цена возможных потерь достаточно высока.
156 Глава 5 Многие компании в принципе ориентированы на деятельность в проектной форме. К ним относятся, например, строительные и инжини- ринговые компании, консалтинговые компании, системные интегра- торы и т. д. Выбор такой формы существования определяется характе- ром бизнеса компании и, прежде всего, предполагает получение дохо- дов за счет создания для клиентов уникальных продуктов или оказания им уникальных услуг. Во всех случаях реализуемые в компаниях проекты кроме различ- ной направленности имеют существенные различия в масштабах, дли- тельности, сложности, стоимости и т. д. Из этого следует необходи- мость систематизации всего многообразия проектов компании, рас- смотрения их как взаимосвязанных элементов, образующих специфи- ческие объекты управления — программы, комплексные проекты и портфели проектов. Практика показывает, что успешная реализация проектов в запла- нированные сроки, в рамках установленного бюджета и в соответствии с техническими спецификациями и требованиями к качеству возмож- на только в рамках формализованной проектной среды, поддерживае- мой ясной и четкой методикой управления проектами. В качестве та- кой среды рассматривается СУП, представляющая собой механизм выработки и реализации сбалансированных решений на всех уровнях управления проектами. Этот механизм позволяет обеспечить эффек- тивность управления и координацию выполнения работ по проектам на основе единой методологической и программно-технической базы. Структура системы управления проектами Для обеспечения поддержки деятельности участников проекта СУП предлагает комплекс решений, охватывающих организационные, ме- тодические и технические вопросы (см. рис. 5.2). Методические решения, разрабатываемые при внедрении СУП, касаются следующих аспектов проектной деятельности: • общей методологии управления программами, портфелями про- ектов и отдельными проектами компании; • принципов и методов формирования программ и портфелей про- ектов на основании объективных критериев, позволяющих оце- нить степень соответствия проектов стратегии компании, их финансовую привлекательность, возникающие риски и т. д.; • операционного стандарта управления проектами, включающего регламенты взаимодействия участников при выполнении проек- тов, процедуры управления проектами и шаблоны управленче- ских документов.
Проекты и стандарты. Стандарт управления проектами строительной компании 157 Организационные решения, разрабатываемые при внедрении СУП, представляют собой: • изменение организационной структуры, включая создание но- вых организационных структур (таких, например, как проектный офис) и/или изменение функций существующих подразделений для организации поддержки функционирования СУП; • изменения и дополнения к существующей организационно-рас- порядительной документации компании, определяющие поря- док использования СУП. Технические решения, разрабатываемые при внедрении СУП, предпо- лагают выполнение следующих работ: • разработка и внедрение автоматизированной СУП на базе про- мышленного пакета календарно-ресурсного планирования и, возможно, с привлечением дополнительных программных средств в смежных областях, таких, например, как управление докумен- тами и деловыми процессами;
158 Глава 5 • подготовка необходимого комплекта технической документации; • обучение сотрудников компании, связанных с реализацией про- ектов. Более полную информацию о структуре СУП и составе работ по ее созданию можно получить в работах [3, 4]. Внедрение системы управления проектами Довольно часто в литературе можно встретить описание отрицательно- го опыта внедрения СУП (см., например, [7, 8]). В этих публикациях авторы размышляют над действительно насущными и болезненными проблемами и описывают вполне узнаваемые ситуации, возникающие на предприятиях при внедрении средств автоматизации управления проектами. Представляется, что значительное количество подобных проблем связано с концентрацией внимания на ИТ-составляющих СУП в ущерб ее остальным составляющим. Действительно, информационные технологии не могут сами по себе решить проблемы управления проектами (и шире —- управления пред- приятиями). В этом смысле пессимизм авторов вполне обоснован. Именно поэтому нам хотелось бы взглянуть на эту проблему под не- сколько иным углом и привести некоторые соображения, вытекающие из представлений о СУП как о целостной системе продуктов и ин- струментов, в которой ИТ-продукты не всегда занимают ведущее по- ложение. Если трактовать СУП только как пакет программ, то с ее внедрени- ем проблем как раз и не возникает. Кто-то получает только красивые графики, а кто-то ведет проекты. Подчеркнем, что количественный перевес в пользу первой группы, даже значительный, вовсе не означает провала внедрения. Каждый получает то, что ожидал, в меру своих действительных потребностей. Если же мы рассматриваем СУП как полноценную методологиче- скую, организационную и, безусловно, инструментальную среду, то ста- новится очевидным, что говорить нужно не столько о проблемах внед- рения, сколько о проблемах выбора продукта. Если ответственные лица организации не понимают современных принципов проектного управления, то внедрение пакета календарного планирования мало чем им поможет, хотя внедрен он будет, скорее всего, вполне успешно. Просто изначально им нужно было покупать другой продукт, например PMBOK®Guide, или выписывать «тренера» по управлению проектами.
Проекты и стандарты. Стандарт управления проектами строительной компании 159 Если в компании не выстроены процессы управления проектами, не определены роли их персонала, не сформированы принципы сосу- ществования проектной и операционной деятельности, то все управ- ление проектами сведется к эпизодическому использованию на отдельно взятых рабочих местах пакета календарного планирования как одного из многих офисных приложений. В этом случае, как и в описанном выше, компания изначально нуждалась в совершенно другом продук- те, а именно в системе управления проектами с хорошо проработан- ной организационной составляющей. ИТ-компонент в этой СУП вполне может появиться только на финальной стадии и, кстати, может вооб- ще не включать пакет календарного планирования и базироваться ис- ключительно на системе управления документами или системе управ- ления бизнес-процессами. Для руководства компании принципиально важно, чтобы проекты выполнялись в рамках единой методологии и проходили некоторые формальные этапы и стадии. Должны также выполняться общие для компании правила проектного учета затрат. Соответствующие прин- ципы и процедуры включены в систему качества компании и внедря- ются директивными методами. Стратегия же автоматизации управле- ния проектами учитывает исторически сложившиеся подходы и лич- ные пристрастия «полевых» менеджеров и линейных руководителей и в значительной степени определяется ими. Развернутое представление технологии создания и внедрения СУП дано на рисунке 5.3. Эта технология предполагает определенную этап- ность, позволяющую проводить изменения постепенно, постоянно оценивая достигнутые результаты и внося необходимые коррективы. Мы выделяем две очереди создания СУП. Первая очередь включает следующие этапы. • Этап 1. Адаптация общей методологии управления проектами к реалиям конкретной компании. Разработка концепции автома- тизированной системы управления проектами —- создание фор- мализованной функциональной модели, определение объема автоматизации, определение основных требований к обеспечи- вающим компонентам моделей. • Этап 2. Разработка рекомендаций по приведению организаци- онной структуры компании в соответствие с проектной органи- зацией работ. • Этап 3. Разработка операционной части корпоративного стан- дарта управления проектами — пакета регламентов, процедур, инструкций и шаблонов управленческих документов. • Этап 4. Выбор программной платформы управления проекта- ми — определение требований и предпочтений будущих пользо-
160 Глава 5 Рисунок 5.3. Технология создания СУП
Проекты и стандарты. Стандарт управления проектами строительной компании -161 вателей, апробация альтернативных продуктов на задачах Заказ- чика, обоснование выбора продукта. Разработка и/или внедре- ние инструментария календарно-ресурсного планирования. • Этап 5. Разработка программы обучения, инструкций для пользо- вателей. Обучение руководителей среднего звена методологии управления проектами с последующей сертификацией. Вторая очередь включает следующие этапы. • Этап 6. Разработка контрольно-мотивационных механизмов выполнения проектных работ. • Этап 1. Выбор программной платформы управления докумен- тами в проектах. Разработка и/или внедрение инструментария управления проектной документацией и управленческими до- кументами проектов. • Этап 8. Выбор программной платформы управления деловыми процессами в проектах. Разработка и/или внедрение инструмен- тария поддержки процедур управления проектами. • Этап 9. Создание механизмов контроля качества управления проектами — организационных структур, процедур аудита, мо- ниторинга, экспертиз проектов. • Этап 10. Подготовка системы управления проектами к серти- фикации по стандартам ISO 9000. 5.2. Управление проектами в строительных компаниях Наверное, никого не нужно убеждать, что строительство является од- ной из тех областей деятельности, в которых применение методов про- ектного управления дает наиболее ощутимые результаты. Причем уже применение такого базового инструмента, как оптимизация сетевого графика работ, обеспечивает очень значительный эффект. И вместе с тем даже этот абсолютно необходимый инструмент управления строи- тельными проектами применяется далеко не всегда успешно, не гово- ря уже о других методах проектного управления, внедрение которых затрагивает многие организационные устои компании. Рассматривая проблемы, возникающие при внедрении проектного управления в строительных компаниях, непосредственный участник событий так описал их в одной из публикаций: «Система управления проектами никому не нужна, от нее требуются только красивые графи- ки, но и они никак не используются. Мне приходилось разговаривать со многими руководителями. Все до единого говорили, что в условиях
162 Глава 5 России современные технологии управления работать не будут. Такой ответ говорит о многом, например о том, что люди не хотят работать по-новому. Лучше бесконтрольно делать что хочется, чем под жестким контролем и то, что надо» [8, с. 38]. Нельзя сказать, что за время, прошедшее с публикации процитиро- ванной статьи (а это уже почти пять лет), ситуация так уж сильно изменилась в лучшую сторону. И это тем более обидно, что, как мы уже отметили, внедрение даже наиболее устоявшихся, традиционных методов проектного управления дает ощутимый положительный эф- фект в строительных проектах. Итак, имеет место заметный разрыв между методологией и практи- кой управления строительными проектами, и этот разрыв неизбежно приводит к определенному разочарованию практиков в методологии. Анализируя современное состояние управления проектами в строи- тельной отрасли, П. Моррис утверждает: «В промышленном строитель- стве управление проектами является общепризнанной практикой, но, тем не менее, не считается главной профессиональной дисциплиной. В строительстве зданий и гражданском строительстве управлению про- ектами придают еще меньшее значение, считая его в лучшем случае продолжением управления на стройплощадке или оценки затрат» [9, с. 10]. Один из существенных факторов, тормозящих полномас- штабное внедрение методов проектного управления в строительстве, по мнению П. Морриса, состоит в том, что реальная деятельность по управлению проектами в строительстве обычно включает в себя более широкую предметную область по сравнению с традиционной моделью PMBOK®Guide, а именно управление стратегическими, техническими и коммерческими вопросами. Речь, таким образом, должна идти о том, что управление проекта- ми необходимо внедрять как полноценный управленческий контур, затрагивающий и вопросы стратегического управления, и организаци- онную структуру компании, и ее финансовую структуру, и систему бюджетирования, и систему управления персоналом, и систему менедж- мента качества, а также многое другое, включая, конечно, и информа- ционные технологии. А это невозможно без создания корпоративных норм и культуры управления проектами и закрепления их в форме стандарта компании. Наиболее полное воплощение эта идея нашла в концепции тоталь- ного менеджмента проектов (ТРМ) строительной компании, предло- женной в работе [11]. Эта концепция предполагает оптимизацию всех участков реализации проектов компании: формирование сбаланси- рованного портфеля контрактов (жизнеспособных, прибыльных, спо- собствующих росту компании), достижение высокой прибыльности, достижение высокой производительности операций и повышение спо-
Проекты и стандарты. Стандарт управления проектами строительной компании 163 собности подразделений минимизировать риски благодаря структури- рованному контролю и регулированию операций. Не претендуя на полноту охвата темы, мы хотим выделить три мо- мента, которые, на наш взгляд, являются принципиальными с точки зрения структуры и содержания стандарта управления проектами стро- ительной компании. Прежде всего, в стандарте должны быть отражены вопросы, свя- занные с адаптацией исторически сложившихся организационных струк- тур строительных компаний к методам проектного управления. Диа- пазон возможных решений здесь может быть достаточно широким. Ре- шение, которое в минимальной степени затрагивает традиционный уклад компании, — это организация проекта как «конвейера», в кото- ром роль руководителя проекта ограничивается функциями координа- ции действий различных подразделений. А наиболее радикальным спо- собом является переход к гибкой матричной структуре. Кроме того, в значительной степени возможна и необходима стан- дартизация календарно-ресурсного планирования проектов вплоть до формирования типовых календарных планов для основных видов про- ектов компании. Основой для их построения могут служить строитель- ные нормативы и технологии, позволяющие точно определять состав и последовательность выполнения работ, а также их продолжительность и стоимость. Наконец, обязательно должны отражаться в стандарте специфиче- ские особенности именно строительных проектов, связанные с нали- чием многочисленных сторон, чьи интересы лежат в области защиты окружающей среды, прав граждан, прямо или косвенно затрагиваемых проектом, и т. д. Здесь стандарт управления проектом может опираться на специальное приложение к «Руководству к своду знаний по управ- лению проектами — PMBOK®Guide 2000» [12]. Корпоративный стандарт управления проектами включает целый ряд документов, которые последовательно детализируют представле- ние о том, как, в какой последовательности, в какие сроки, с исполь- зованием каких документов следует выполнять те или иные действия в процессе управления проектами. Общая структура корпоративного стан- дарта управления проектами приведена в разделе 3.4 на рисунке 3.13. Рассмотрим далее принципы построения и примеры некоторых из этих документов. 5.3. Политика управления проектами Основополагающий документ, определяющий принципы управления проектами в компании, называют по-разному — концепция, методи- ка. Нам самым правильным представляется называть такой документ
164 Глава 5 политикой, поскольку основным назначением этого документа явля- ется разграничение сфер ответственности различных подразделений и отдельных должностных лиц компании при осуществлении деятельно- сти, реализуемой в проектной форме. Мы рассмотрим три основные составляющие политики управления проектами — классификацию про- ектов, жизненные циклы проектов, функциональные роли и ответствен- ность участников проектов. Классификация строительных проектов Как правило, строительная компания выполняет проекты, различаю- щиеся по географическому признаку, видам применяемых и/или внед- ряемых технологий, сложности, масштабности и продолжительности выполняемых работ и т. д. Исходя из этих (и некоторых других) реаль- ных особенностей проектов, могут быть формализованы правила управ- ления проектами компании во всех функциональных областях. В полном виде правила управления проектами касаются следующих аспектов, хотя необходимо отметить, что этот список далеко не исчер- пывающий: • Содержание и границы проекта — цели и задачи проекта, основ- ные результаты, критерии оценки того, что работа или ее часть выполнена. • Ключевые вехи проекта — основные события проекта и план их достижения, возможно, с использованием структуры декомпо- зиции работ. • Плановый бюджет проекта — постатейные сметы расходов и доходов с привязкой к календарным срокам проекта. • Организационная структура проекта — ответственность и поря- док взаимодействия участников, роли и обязанности ключевых фигур проекта. • Управление проектной документацией — структура, среда хра- нения и процедура создания и сопровождения библиотеки до- кументов проекта, перечень шаблонов документов. • Управление отклонениями — процедуры работы с рисками, с возникающими проблемами и изменениями, формы соответству- ющих документов. • Обеспечение качества — перечень и регламенты проведения мероприятий, направленных на обеспечение качества как ре- зультатов проекта (продукта), так и процессов управления про- екта и выполнения работ.
Проекты и стандарты. Стандарт управления проектами строительной компании 165 • Контроль и отчетность — регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчет- ности. • Предположения и ограничения — предпосылки, на основе ко- торых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание начальных рисков. • Требования и стандарты — перечень нормативных и регламен- тирующих документов или их отдельных положений, которые следует соблюдать в ходе выполнения работ проекта. Чтобы дать систематизированное представление обо всех объектах СУП и формализовать правила реализации проектов, все проекты компа- нии должны быть классифицированы. Более подробную информацию об использовании классификации проектов при формализации мето- дов управления проектами можно найти в работе [3]. В качестве наиболее важных для строительных и инжиниринговых компаний оснований классификации выделим следующие 1. Назначение (результат) проекта — исследование возможностей строительства, разработка проектной документации, строитель- ство (реконструкция, капитальный ремонт, новое строительство), монтаж оборудования. Эта классификация определяет все виды проектов компании, имеющие принципиально различающиеся жизненные циклы и подходы к документированию, управлению качеством, стандартизации. Отметим, что строительная компания может реализовывать не только строительные проекты, но, например, и внутренние про- екты развития, которые могут относиться к самым различным областям (ИТ, HR, финансы и т. д.). Безусловно, в стандарте управления проектами строительной компании должно быть уделено внимание и этим проектам, однако они не являются предметом рассмотрения данной книги. 2. Источник финансирования проекта — средства заказчика, соб- ственные средства, кредитование, средства сторонних заказчи- ков и партнеров. Классификация определяет виды проектов, различающиеся процедурами планирования и выделения фи- нансовых средств, контроля и отчетности. 1 Авторы благодарят компании «СитиИнвестСтрой» и Project Management Company (PMC) (СПб) за разрешение использовать материалы корпоративного стандарта управления проектами.
166 Глава 5 3. Роль компании при выполнении проекта — генеральный заказ- чик, субподрядчик, генподрядчик, управляющая компания. Клас- сификация определяет виды проектов, различающиеся правилами формирования и управления бюджетом проекта, процедурами контроля и отчетности, организационной структурой. 4. Масштабность проекта — комбинация стоимости и длительно- сти проекта (см. табл. 5.1). Классификация определяет виды про- ектов, различающиеся уровнем вовлекаемых должностных лиц, степенью формализации процедур управления, требованиями к управленческой отчетности. 5. Сложность проекта — комбинация производственных, техноло- гических и организационных параметров проекта (см. табл. 5.2). К технологическим параметрам относится новизна реализуемых решений, к организационным — количество различных заинте- ресованных сторон, вовлекаемых в реализацию проекта. Клас- Таблица 5.1. Классификация проектов по масштабности " —-____^Стоимость Длительность —— Низкая стоимость Средняя стоимость Высокая стоимость Низкая продолжительность Малый Средний Средний Средняя продолжительность Малый Средний Крупный Большая продолжительность Средний Крупный Крупный Таблица 5.2. Классификация проектов по сложности Заинтересо- ванные ^\сторо- Новизна^\ны Одна или две заинтересованные стороны От трех до пяти заинтересованных сторон Более пяти заинтересованных сторон Стандартное решение Низкая сложность Низкая сложность Средняя сложность Модернизи- рованное решение Низкая сложность Средняя сложность Средняя сложность Известное на рынке решение Средняя сложность Высокая сложность Высокая сложность Новое решение Средняя сложность Высокая сложность Высокая сложность
Проекты и стандарты. Стандарт управления проектами строительной компании 167 сификация позволяет выделить виды проектов, различающихся с точки зрения организационной структуры, — количество уров- ней управления, уровень вовлекаемых должностных лиц, необ- ходимость привлечения экспертов. Классификация может быть дополнена производственными па- раметрами, учитывающими, например, количество видов работ (по СНиПам). Тогда результирующую сложность проекта нуж- но будет представлять трехмерной матрицей свертки. Кроме рассмотренных выше могут использоваться и другие классифи- кации, определяющие различия проектов уже не по внутренним пара- метрам, а по их позиционированию в компании. Например, приоритет проекта, определяемый на основании ряда внешних и внутренних эконо- мических и политических факторов, может учитываться при обеспече- нии финансовыми, материальными, трудовыми ресурсами. Описание общих подходов к классификации проектов, в том числе в строитель- ной сфере, можно найти в работе [13]. Жизненный цикл проекта Напомним, что жизненный цикл проекта рассматривается как набор логически взаимосвязанных работ, в процессе завершения которых достигается один из основных результатов проекта. При формирова- нии жизненного цикла строительного проекта естественно отталки- ваться от жизненного цикла объекта строительства. Этот жизненный цикл включает формирование концепции объекта, проектирование, строительство и эксплуатацию. Исходя из этого, традиционный жизненный цикл строительного проекта должен включать следующие стадии (см. рис. 5.4): • Исследование возможностей — анализ вариантов и формирова- ние концепции объекта, предпроектный анализ, разработка и утверждение стратегии строительства. Эта, по сути, предпроект- ная стадия для подрядных организаций часто выполняется как Рисунок 5.4. Стадии жизненного цикла строительного проекта
168 Глава 5 самостоятельный (маркетинговый) проект, результатом которого являются коммерческие предложения или тендерная докумен- тация, содержащая концепцию объекта и другую необходимую информацию. • Планирование и проектирование — разработка проектно-смет- ной документации, подготовка детальных календарно-ресурсных планов, формулирование условий и положений контрактов, за- ключение контрактов с подрядчиками и субподрядчиками. Раз- работка проектно-сметной документации также может быть са- мостоятельным (но уже коммерческим) проектом для таких подрядчиков, как проектный институт. • Производство — создание объекта, осуществление необходимых поставок, строительно-монтажные работы, пуско-наладочные ра- боты, тестирование инженерных систем и т. д. • Ввод в эксплуатацию — приемо-сдаточные испытания, ввод в промышленную эксплуатацию, обслуживание. Более детальный взгляд на проект позволяет выделить в нем компонен- ты, относящиеся непосредственно к строительству и монтажу оборудо- вания, а также к другим областям, прямо или косвенно затрагиваемым проектом (примеры декомпозиции работ в строительных проектах мож- но найти, например, в работе [14]). Такая детализация позволяет, в свою очередь, выделить ключевые события (вехи) проекта и взаимо- связи между ними. В результате появляется возможность изобразить жизненный цикл проекта в менее схематичном виде, отразить в нем реальные причинно-следственные связи, возможности параллельного выполнения работ. Отметим, что жизненный цикл объекта не ограничивается указан- ными стадиями. Поэтому многие современные подходы к управлению проектами в строительстве исходят из существенно расширенного пред- ставления о жизненном цикле строительного проекта, включая в него стадию стратегической проработки, а также и стадии, следующие за сдачей объекта (эксплуатация, реконструкция, ликвидация). Об этом мы поговорим подробнее далее в этой главе (см. раздел 5.6). Функциональные роли и ответственность участников проекта В разделе 2.5 кратко описаны основные роли участников проектов — Инвестора, Генерального заказчика, Функционального заказчика, Ис- полнителя, Эксплуатирующих организаций. Рассмотрим некоторые из этих ролей более подробно применительно к строительным проектам.
Проекты и стандарты. Стандарт управления проектами строительной компании 169 • Генеральный заказчик В соответствии с законодательством РФ в строительных проек- тах эта роль отводится заказчику-застройщику, в функции кото- рого входят *: ♦ получение и оформление исходных данных для проектиро- вания объектов строительства и реконструкции; ♦ техническое сопровождение проектной стадии; ♦ оформление разрешительной документации на строительство и реконструкцию; ♦ обеспечение освобождения территории строительства; ♦ обеспечение строительства материалами и оборудованием; ♦ организация и управление строительством; ♦ координирование деятельности проектных, строительно-мон- тажных, специализированных и других организаций, осущест- вляющих проектирование, строительство и реконструкцию объектов. • Функциональный заказчик Обычно в роли функционального заказчика выступает действу- ющий или будущий владелец здания. Его задача состоит в опре- делении осуществимых, жизнеспособных и экономически вы- годных результатов проекта. • Исполнители Работы по созданию проектно-сметной документации и специ- фикаций выполняет субподрядная проектная организация (De- signer, Архитектор), а работы, непосредственно связанные со строительством, — строительная организация (Constructor, Инже- нер) 1 2. Поставки материалов и конструкций, основного и вспомо- гательного оборудования осуществляются поставщиками. Общую ответственность за выполнение всего комплекса проектных и изыскательских работ по объекту несет Генеральный проектиров- щик (Генеральный подрядчик). Применительно к строительным проектам стандарты выделяют еще две принципиально важные группы заинтересованных сторон — регу- лирующие органы и общественность [12]. 1 См. www.glossary.ru. 2 Здесь английские варианты названий даны по документу [12], а соответствующие русские — по работе [14].
170 Глава 5 • Регулирующие органы К регулирующим органам относятся международные, государст- венные, местные органы власти, осуществляющие надзорные и разрешительные функции в отношении различных существен- ных аспектов строительства зданий и сооружений. Как правило, участие этих регулирующих органов в проекте строго регламентировано. Пример подобного регламента для подготовки инвестиционных документов проекта приведен в работе [14]. Впечатляет список согласующих инстанций, опре- деленный этим регламентом: ♦ Комитет по строительству, ♦ городская Инвестиционно-тендерная комиссия, ♦ городской Центр государственного санитарно-эпидемиоло- гического надзора, ♦ городское Управление инвентаризации и оценки недвижи- мости, ♦ Комитет по градостроительству и архитектуре, ♦ Комитет по государственному контролю, использованию и охране памятников истории и культуры, ♦ Комитет по земельным ресурсам и землеустройству, ♦ Комитет по управлению городским имуществом, ♦ Управление оформления сделок с недвижимостью, ♦ Комитет по энергетике и инженерному обеспечению, ♦ территориальный орган местной администрации, ♦ Управление садово-паркового хозяйства. Интересно отметить, что, несмотря на то, что все профессио- нальные строители знают о неизбежности этих согласований, очень часто в календарные планы не закладываются достаточ- ные или хотя бы адекватные временные резервы. • Общественность Общественность — это организованные группы граждан или отдельные граждане, чьи интересы в той или иной степени мо- гут пострадать в процессе или после завершения строительного проекта. Влияние общественности на строительные проекты в современном обществе постоянно возрастает и сказывается на всех его существенных аспектах — сроках реализации, стоимо- сти, конструктивных решениях и т. д. вплоть до полной оста- новки проекта.
Проекты и стандарты. Стандарт управления проектами строительной компании 171 При реализации проектов создания крупных общественно значимых объектов представители регулирующих органов и общественности мо- гут включаться непосредственно в состав команды проекта на уровне стратегического руководства и координации (координационный совет или общественный совет). 5.4. Операционный стандарт Структура операционного стандарта Структура операционного стандарта определяется двумя основными факторами: отраслевые и корпоративные нормы управления проекта- ми определяют перечень разделов стандарта (в работе [3] мы их называли микрошаблонами), а принятые классификации проектов — содержание этих разделов. Именно эти микрошаблоны и должны использоваться при формировании формализованной среды каждого конкретного про- екта, которая включает набор процедур и документов, применяемых именно в этом проекте. В таблице 5.3 приведен фрагмент структуры операционного стан- дарта управления проектами строительной компании, опирающегося на классификаторы, рассмотренные в разделе 5.3. Для каждой отмеченной ячейки в стандарте должны присутство- вать типовые шаблоны каждого элемента соответствующей классифи- кации. Рассмотрим, как это выглядит на практике, на примере органи- зационной структуры проекта. Как видно из таблицы 5.3, на состав стандарта в части организаци- онной структуры проекта влияют практически все основные парамет- ры проекта. Таким образом, чтобы понять, какие именно шаблоны должны появиться в этом разделе, необходимо рассмотреть отдельные элементы организационной структуры проекта. Поскольку большая часть этих элементов в том или ином аспекте уже упоминались в этой книге, ограничимся здесь только их перечис- лением: • органы управления проектом на разных уровнях (руководящий комитет, группа управления проектами) — временные структур- ные единицы, осуществляющие функции стратегического и опе- ративного управления проектом; • должностные лица компании, привлекаемые к управлению про- ектом; * экспертные структуры — постоянные или временные структур- ные единицы, осуществляющие экспертизу технических решений;
172 Глава 5 Таблица 5.3. Фрагмент структуры операционного стандарта управления строительными проектами Приоритет проекта ''у *^у Сложность проекта ^у Масштаб- ность проекта ^у ^у Роль компании ^у Источник финанси- рования Назначение проекта ^у Классификации Разделы~~~^г1роектов стандарта Содержание и границы проекта Ключевые вехи проекта Плановый бюджет проекта Организационная структура проекта Управление проектной документацией Управление отклонениями Обеспечение качества Контроль и отчетность Предположения и ограничения Требования и стандарты
Проекты и стандарты. Стандарт управления проектами строительной компании 173 * рабочие группы — постоянные или временные структурные еди- ницы, выполняющие определенные объемы работ в соответствии со своей специализацией. Примеры шаблонов, необходимых для каждого из этих элементов, при- ведены в таблице 5.4, а примеры их содержания — в таблице 5.5. Пред- ставленный в этих таблицах фрагмент операционного стандарта охва- тывает вопросы, связанные с формированием только одного (хотя и очень важного) документа — Плана управления проектами. Но по та- кому же принципу могут формироваться и остальные элементы фор- мализованной среды проекта. Процедуры управления проектами Одним из важнейших элементов формализованной среды проекта яв- ляются процедуры управления проектом. Общий подход к их форми- рованию описан в разделе 2.1, а в данном разделе рассмотрен вопрос о том, как эти принципы могут быть применены в строительных проек- тах. Отметим, что каждый из основных участников строительного про- екта видит его по-разному. В соответствии с этим видением формиру- ются и процедуры управления проектом. Стандарт исполнителя Для исполнителей (проектировщиков, строителей, инжиниринговых компаний) характерен технологический взгляд. Поэтому и процедуры часто выстраиваются по жизненному циклу' проекта. При таком подхо- де на уровне формальной процедуры фиксируются значимые этапы проекта, определяются сроки их исполнения и результаты. Рассмотрим подобный подход к формированию процедур управле- ния проектами на примере стандартов двух компаний. Процедуры стан- дартов обеих компаний, несмотря на некоторые внешние отличия, следуют за жизненным циклом строительного проекта. Процедура управления проектом строительной компании «СитиИн- вестСтрой» (Санкт-Петербург)1 определяет три стадии: • Маркетинговая стадия охватывает все действия компании, на- чиная от момента первых контактов с потенциальным заказчи- ком до момента заключения договора на выполнение проект- ных и строительных работ. • Стадия проектирования регламентирует действия исполнителя и субподрядчиков в процессе разработки и согласования проект- ной документации. 1 Краткая характеристика компании «СитиИнвестСтрой» дана в разделе 5.5.
Таблица 5.4. Состав микрошаблонов раздела «Организационная структура проекта» Элементы организационной структуры Классификации проектов Назначение проекта Источник финансирования Масштабность проекта Сложность проекта Приоритет проекта Органы управления проектом на разных уровнях Состав органов управления проектами (п р едета в ит ел ьст во заинтересованных сторон) Структура органов управления проектом (простая, иерархическая) Состав органов управления проектами (уровень представительства заинтересованных сторон) Должностные лица, привлекаемые к управлению проектом Требования к статусу лиц, осуществляющих руководство проектом (должность в организации) Требования к квалификации управленческого персонала (сертификаты, опыт работы по управлению проектами) Рабочие группы Структура команды проекта (маркетинговая группа,группа проектирования, строительная группа) Ролевые составы рабочих групп Требования к квалификации исполнителей (сертификаты, профессиональный опыт) Экспертные структуры Требования к квалификации экспертов (сертификаты, профессиональный опыт) Таблица 5.5. Микрошаблоны подраздела «Состав рабочих групп» Роль в проекте Должность в компании Маркетинговый проект Проект по проектированию Строительный проект Куратор Коммерческий директор Главный инженер Начальник производственной службы Руководитель проекта Сотрудник маркетингового отдела — Сотрудник производственной службы Главный архитектор — Главный инженер проекта Главный инженер проекта Менеджер строительства — Начальник участка Эксперты по проектированию Сотрудник отдела проектирования — Сотрудник отдела проектирования Технический эксперт Сотрудник производственной службы Сотрудник производственной службы — Проектировщик — Сотрудник отдела проектирования. Субподрядчики Субподрядчики Строители ___ — Субподрядчики Экономист Сотрудник сметного отдела Сотрудник сметного отдела Сотрудник финансового отдела Юрисконсульт Сотрудник юридической службы Сотрудник юридической службы Сотрудник юридической службы
176 Глава 5 • Стадия строительства регламентирует процессы выполнения строительно-монтажных работ; процессы взаимодействия с за- казчиком, поставщиками и субподрядикам; процессы оформле- ния исполнительной документации и сдачи объекта. Внутри каждой стадии процедура структурирована по фазам управле- ния — инициализация, планирование, выполнение, закрытие. В от- дельный блок внутри каждой стадии вынесены функции управления проектом — контроль сроков и бюджета, отчетность и анализ, управ- ление рисками и изменениями. Немного иначе выглядит процедура управления проектами в ком- пании «Телекомстрой» (Санкт-Петербург)Общая схема процедуры, используемой при реализации инжиниринговых проектов в компании «Телекомстрой», приведена на рисунке 5.5. Отметим, что эта процеду- ра включена в систему менеджмента качества компании [15]. Рисунок 5.5. Схема процедуры управления инжиниринговым проектом На стадии инициализации формируются предварительное техни- ческое решение и оценочный бюджет проекта, которые трансформи- руются затем на предварительной стадии в коммерческое предложение и договор с заказчиком. Проектирование, производство работ и ввод объектов в эксплуатацию отнесены к исполнительской стадии. На за- ключительной стадии выполняется формальное завершение работ, вклю- чая финансовые расчеты и заключение дополнительных соглашений. Ниже приведен пример общего перечня вопросов, которые должны быть отражены в стандарте строительной компании (пример дан для строительной стадии проекта). 1 Компания «Телекомстрой» специализируется на проектировании, поставке, монта- же и последующем техническом обслуживании телекоммуникационного оборудо- вания. В компании работает около 200 специалистов разного профиля, одновре- менно выполняется до 40 проектов.
Проекты и стандарты. Стандарт управления проектами строительной компании 177 Содержание процедуры управления строительным проектом на стадии строительства 1. Фаза инициализации: • формирование Устава проекта на строительной стадии; • определение структуры и состава команды проекта со стороны Исполнителя; • выделение специалистов в команду проекта в соответствии с принятыми в ком- пании процедурами; • назначение ответственных лиц за контроль строительства со стороны Заказ- чика; • формирование инфраструктуры проекта (офис проекта, проектные папки и т. д.). 2. Фаза планирования: • формирование детального плана производства работ; • выбор субподрядчиков и поставщиков, заключение договоров; • формирование графика поставки материалов и комплектующих; • разработка состава исполнительной документации, ППР, технических карт; • разработка графиков поступления и расходования финансовых средств, бюд- жета проекта. 3. Фаза выполнения: Шаг 1. Получение проектной документации: • контроль поступающей проектной документации; • уточнение и корректировка в случае необходимости проектной документации; • передача проектной документации на строительные объекты. Шаг 2. Проведение подготовительных работ: • получение площадки Заказчика для начала подготовительных работ по проекту; • подготовка строительной площадки для начала строительных работ, организа- ция условий труда на объектах; • организация технического надзора проводимых работ; • формирование набора необходимых журналов по СНиП, а также журналов для проведения внутреннего контроля работ. Шаг 3. Обеспечение материалами и оборудованием: • формирование заявок на материалы и оборудование; • формирование заявок и счетов на оплату материалов и оборудования, конт- роль оплаты; • организация доставки, приемки и хранения материалов и оборудования. Шаг 4. Проведение строительных работ: • выдача заданий, контроль выполнения строительных работ непосредственны- ми исполнителями работ, субподрядчиками; • формирование обязательной отчетности по проекту (КС2 и КСЗ, Форма учета и списания материалов), формирование заявок на материалы, заявок на изме- нения в проекте; • осуществление технического надзора за строительством, за качеством прово- димых работ и качеством используемых материалов;
178 Глава 5 • формирование замечаний, анализ ошибок, внесение изменений в проектную документацию; • разработка, контроль и утверждение исполнительной документации. 4. Фаза завершения: Шаг 1. Сдача объекта: • формирование пакета исполнительной документации и сдача его Заказчику; • организация и проведение внутренней сдачи объекта; • устранение замечаний по результатам внутренней сдачи объекта; • сдача объекта Заказчику; • проведение рабочей, государственной комиссии. Шаг 2. Закрытие проекта: • проведение окончательных расчетов с субподрядчиками и поставщиками; • анализ результатов проекта, сдача документации в архив; • расформирование команды проекта. Необходимо отметить, что стандарт управления проектами строитель- ной компании в очень многих вопросах обречен носить рамочный харак- тер. Связано это с тем, что, являясь стороной подчиненной, исполнитель обязан принимать правила игры, которые диктует каждый конкретный заказчик в каждом конкретном проекте. Однако те процессы, которые лежат на стороне исполнителя, имеет смысл описать с максимальной степенью детализации вплоть до определения типовых регламентов, т. е. с установкой стандартных сроков выполнения работ и проведения согласований, а также с указанием конкретных подразделений и долж- ностных лиц, вовлекаемых в проект. Стандарт заказчика Для Генерального заказчика характерен иной подход к управлению строительными проектами. Это отличие особенно заметно на крупных проектах с большим количеством участников. В этих случаях часто наиболее эффективным способом реализации проекта является созда- ние подразделения (или даже отдельной компании), занимающейся исключительно управлением этим проектом. Будем далее называть та- кое подразделение Отделом управления проектом. Отдел управления проектом, по сути дела, представляет собой ко- манду управления проектом. В его состав входят руководитель проекта (в должности начальника отдела), его заместители по проектированию и строительству, а также менеджеры по отдельным функциональным направлениям: • менеджер по контролю графиков работ, который отвечает за выдачу заданий и учет выполненных работ;
Проекты и стандарты. Стандарт управления проектами строительной компании 179 • менеджер по учету затрат, который ведет учет всех видов ресур- сов (финансовых, материальных, человеческих); • менеджер по поставкам материалов и оборудования; • менеджер по коммуникациям, который занимается организацией всех внутренних и внешних согласований. Таким образом, роль сотрудника в проекте становится его должностью в компании; за сотрудником закрепляются определенные функции (функ- ции управления проектом!), а его деятельность в проекте может напря- мую регламентироваться должностными инструкциями. Именно поэто- му стандарт управления проектами Генерального заказчика естествен- ным образом выстраивается вокруг функций управления проектами. Нельзя забывать о том, что некоторые функции управления проек- том пересекаются с зонами ответственности других функциональных подразделений компаний. Среди таких областей пересечений выделим, прежде всего, финансы, поставки, документы (см. рис. 5.6). Проект- ные процедуры, соответственно, должны четко регламентировать вза- имодействие подразделения, управляющего проектом, с постоянными функциональными подразделениями компании (с финансовым управ- лением, управлением материально-технического снабжения, юриди- ческим отделом и т. д.). На рисунке 5.7 приведен пример подобной процедуры (представ- ленной в форме календарного плана), описывающей маршрут согласо- Рисунок 5.6. Зоны ответственности в строительном проекте
180 Глава 5
Проекты и стандарты. Стандарт управления проектами строительной компании 181 вания проектно-сметной документации (ПСД). Процесс описан с точ- ки зрения менеджера по коммуникациям, осуществляющего коорди- нацию процесса выпуска проектно-сметной документации. В процесс вовлечены также: • подрядная организация, разрабатывающая ПСД (Проектиров- щик); • Управление капитального строительства, осуществляющее конт- роль ПСД на предмет соответствия требованиям функциональ- ных заказчиков (УКС); • Отдел экспертизы проектов, выполняющий техническую экс- пертизу решений, предложенных Проектировщиком (ОЭП), и др. В зоне ответственности Генерального заказчика лежат также некото- рые процессы, относящиеся к характерным именно для строительной отрасли областям знаний. В документе [12] определены четыре такие области — охрана труда (ОТ) и промышленная безопасность (ПБ), охра- на окружающей среды, финансирование проекта, работа с претензия- ми. Эти области хотя и описаны в стандартах PMI, но не являются столь широко известными, как традиционные области знаний, опреде- ленные PMBOK®Guide. И вместе с тем ни в одном строительном про- екте нельзя обойти перечисленные четыре области (см. рис. 5.8, 5.9, 5.10 и 5.11). Для реализации соответствующих функций в Отделе управления проектом должны быть предусмотрены штатные единицы (менеджер по ОТ и ПБ, менеджер по экологии и т. д.). Должностные инструкции для этих позиций могут напрямую следовать соответствующим разде- лам PMBOK®Guide Г Гармонизация стандартов участников проекта Итак, мы установили, что стандарты управления строительными про- ектами Заказчика и Исполнителя могут существенно различаться. Но для успешного и эффективного совместного использования этих стан- дартов они должны быть гармонизированы. Выделим два уровня гар- монизации — идеологический и технологический. На идеологическом уровне гармонизация стандартов означает, что Заказчику должна быть обеспечена возможность реализации всех про- цедур его стандарта, в том числе в части функций, выполняемых на стороне Исполнителя. Из этого не следует, что Исполнитель обязан 1 Вопросы управления стоимостью более полно и с учетом российских особенностей представлены в работах [16, 17].
\\ Планирование мероприя1ий по ОТ и ПБ // Выполнение мероприятий по ОТ и ПБ у Администрирование \ \ и отчетность \ / по ОТ и ПБ / • Анализ опасностей и угроз по ОТ и ПБ • Обеспечение персональными средствами защиты • Ведение журналов проверок, формирование отчетов • Отбор субподрядчиков по обеспечению ОТ и ПБ • Установка защитного оборудования по проверкам • Регистрация обучения • Разработка системы поощрений за обеспечение ОТ и ПБ • Периодические проверки строительных механизмов и оборудования • Установка средств предупреждения (плакаты и пр.) • Обучение и инструктаж по ОТ и ПБ • Проверки ОТ и ПБ • Расследование происшествий • Медицинское обеспечение и инструктажа • Ведение журналов регистрации происшествий, болезней и травм • Ведение фото-, видео- и аудиозаписи • Оформление документов по расследованию происшествий • Проверки на употребление наркотиков и алкоголя Рисунок 5.8. Обеспечение охраны труда и промышленной безопасности \\ \ \ \ Планирование мероприятий Анализ и оценка состояния \, Контроль состояния по охране окружающей среды // окружающей среды / окружающей среды • Идентификация и оценка • Повторное использование • Управление качеством рисков, связанных с охраной и утилизация материалов ° Управление рисками> окружающей среды * Аудит мероприятий по охране связанными с охраной • Анализ и выбор окружающей среды окружающей среды альтернативных способов . Обучение и инструктаж проведения строительных п0 охране окружающей среды работ • Анализ лучших отраслевых практик и передового опыта • Анализ возможных сценариев (определение и фиксация на диаграммах причинно-следственных связей) • Анализ требований заинтересованных сторон проекта Рисунок 5.9. Обеспечение охраны окружающей среды Глава 5 Проекты и стандарты. Стандарт управления проектами строительной компании 183
Планирование проектного финансирования Управление проектным финансированием Администрирование и бухгалтерский учет • Финансовый анализ проекта (изучение финансовых потоков и возможных источников финансирования) • Разработка оптимальной маркетинговой стратегии проекта и формирование финансового плана • Анализ чувствительности финансового плана • Определение возможных дополнительных источников финансирования • Тестирование финансового плана, проведение предварительных переговоров с потенциальными кредиторами • Учет поступлений и расходов, анализ их отклонений от бюджета проекта • Проведение внутренних и внешних финансовых аудитов • Анализ и прогнозирование финансовых потоков • Финансовые отчеты для заинтересованных сторон • Фиксация поступлений и расходов в соответствии с планом счетов проекта в бухгалтерской системе • Бухгалтерская отчетность Рисунок 5.10. Обеспечение финансирования проекта Идентификация претензии Оценка возможных потерь Предотвращение потерь Разрешение претензий • Определение соответствия положениям контракта • Юридическая оценка последствий • Документирование, включая фото- и видеоматериалы, рисунки, показания свидетелей и т. д. • Оценка объема возможных дополнительных работ • Оценка претензий в стоимостном выражении • Применение процедур контрактного права (поиск прецедентов) • Оценка последствий для графика дальнейших работ • Обеспечение ясности основных положений контракта • Обеспечение обоснованности графика проекта • Проверка возможностей реализации проектных решений • Регламентация информационных потоков • Установление партнерских отношений • Качественное документирование • Совместное управление изменениями • Предварительная проверка подрядчиков • Проведение переговоров заинтересованных сторон • Привлечение посредников (независимых арбитров) • Разбирательство в суде • Оценка стоимости юридического разрешения претензий Рисунок 5.11. Обеспечение работы по претензиям Глава 5 Проекты и стандарты. Стандарт управления проектами строительной компании 185
186 Глава 5 коренным образом менять собственный стандарт, поскольку (как мы отмечали выше) стандарт Исполнителя именно в рассмотренных раз- делах обычно носит рамочный характер. Гармонизация стандартов до- стигается в рамках специального соглашения, заключаемого Заказчи- ком и Исполнителем на время выполнения конкретного проекта, — Устава проекта. На технологическом уровне гармонизация стандартов означает, что всем участникам проекта должна быть обеспечена возможность полу- чения информации в согласованном формате, в согласованные сроки, с заданной надежностью и достоверностью. Для больших проектов эта задача может решаться только с использованием информационных тех- нологий. Пример такой системы можно найти в работе [18], где рассматри- вается проект строительства завода сжиженного природного газа, в котором применялась подобная информационная система. В ней была предусмотрена автоматизация самых разных функций как в области управления проектами, документами и поставками, так и в области инжиниринга и строительства. Это обеспечивало интеграцию информа- ции во времени, т. е. передачу ее по всем этапам жизненного цикла объекта. К системе были подключены все основные участники проек- та — владелец завода, головной офис проекта, стройплощадки, парт- неры по инжинирингу, поставщики, лицензиары, что позволяло ин- тегрировать информацию в пространстве. 5.5. «Большой стандарт для маленькой компании» Своим названием эта глава обязана статье Бориса Летучего, в которой он утверждает: «Хотелось бы подчеркнуть, что даже в небольшой (а может быть, именно в небольшой) компании внедрение проектного управления и внутренних стандартов является насущной необходи- мостью и может в значительной мере способствовать успеху деятель- ности» [19, с. 46]. Довольно распространенным заблуждением является представление о стандарте управления проектами как о вещи в хозяйстве, безусловно, полезной, но слишком обременительной для бюджета компании. В дан- ном разделе, опираясь на реальный опыт не очень большой строитель- ной компании «СитиИнвестСтрой» из Санкт-Петербурга, мы показы- ваем, как действительно полезный результат в области стандартизации управления проектами можно получить, оперируя относительно неболь- шими суммами. В основе раздела — совместный доклад, сделанный заказчиком стан- дарта и исполнителем работ по его созданию [20].
Проекты и стандарты. Стандарт управления проектами строительной компании 187 Параметры организации Характеристика компании 1 Основные виды деятельности: • Управление строительными проектами, инжиниринговые услу- ги, осуществление функций Генерального подрядчика и Заказ- чика на строительство, проектирование зданий и сооружений I и II уровней ответственности в соответствии с государствен- ным стандартом. • Архитектурное проектирование, весь комплекс общестроитель- ных и отделочных работ, укрепление и гидроизоляция фунда- ментов, фасадные работы. • Оборудование промышленных бетонных полов, кровельные ра- боты, благоустройство территории, ландшафтный дизайн. • Защита от коррозии строительных конструкций и оборудования; декоративные полимерные покрытия и покрытия специального назначения, бетонные полы и полы с упрочненным верхним слоем, работы по благоустройству территорий. Заказчики — это организации различного профиля, включая промыш ленные предприятия и складские комплексы, банки, бизнес-центры, автомобильные салоны, торговые и спортивно-оздоровительные комп- лексы, учебные заведения и медицинские учреждения. Персонал Численность административного и инженерно-технического персонала (без учета численности производственных бригад) составляет 67 чело- век, в том числе: • административно-управленческий персонал — 9 человек; • производственно-технический и сметный отдел — 7 человек; • производственно-строительный отдел — 16 человек; • финансовый отдел — 9 человек; • архитектурно-проектное бюро — 8 человек; • отдел снабжения, комплектации и автотранспорта — 9 человек; • административно-хозяйственный отдел — 6 человек; • подразделение полимерных покрытий — 3 человека. 1 Данные по состоянию на июнь 2005 г.
188 Глава 5 Численность производственных рабочих в период строительного сезо- на (апрель—ноябрь) — до 500 человек. К работам на объектах на момент разработки стандарта было при- влечено девять субподрядных организаций. Работы велись по 13 строи- тельным объектам. Причины начала работ по созданию стандарта управления проектами Быстрый рост объемов строительно-монтажных работ, а также коли- чества возводимых объектов в течение последних лет определил необ- ходимость структурных изменений. На момент начала проекта пробле- мы управления в компании еще не стали проблемами производства и сдачи объектов. Точнее сказать, компания компенсировала свои управ- ленческие ошибки, расходуя дополнительные ресурсы (управленческие, материальные, финансовые, временные) для успешного завершения объекта. Для этих целей либо использовались ранее накопленные ре- сурсы, либо финансовые результаты переносились на новые проекты, в целом обеспечивая общую ликвидность компании. В общем, компания находилась «на подъеме», действующая струк- тура обеспечивала устойчивую производственную деятельность, а вы- сокая оперативная загрузка руководства не позволяла отвлекаться на разработку перспектив. В такой ситуации для многих менеджеров ком- пании целесообразность изменений не была очевидной. А у акционе- ров и топ-менеджеров, понимающих необходимость изменений, не было уверенности в необходимости перехода именно к проектно-ориенти- рованной структуре. Тем не менее было принято решение о начале работы по внедре- нию проектного управления. Первый этап — изучить и попробовать Стратегия внедрения проектного подхода Задание на проект было сформулировано следующим образом. Группа строительных компаний реализует собственную программу перехода на проектно-ориентированную систему управления. Реализация про- граммы осуществляется в несколько этапов. По окончании каждого этапа принимается решение о продолжении программы. Цель — внед- рение технологии управления строительными проектами в соответствии с лучшими практиками и международными стандартами. Прежде всего из высшего руководства компании был утвержден куратор проекта, который и должен был предложить компании цели и содержание изменений, а также оптимальный алгоритм перехода к новой структуре.
Проекты и стандарты. Стандарт управления проектами строительной компании 189 Для решения этой задачи было введено ограничение по времени — 6 месяцев. Это тот срок, в течение которого должны быть либо получе- ны существенные результаты, либо принято решение о закрытии про- екта. Вторым важным ограничением стал бюджет, который было ре- шено минимизировать (см. ниже). Третьим ограничением было то, что процесс создания и внедрения стандарта не должен вносить дисбаланс в работу компании. Первый этап предполагалось осуществить в течение 6 месяцев. Для этого было решено создать команду из 4—5 человек, состоящую из: • руководителя технологической части проекта; • двух менеджеров проектов, которым отводилась роль внутренних консультантов по управлению проектами; • двух (в дальнейшем — больше) менеджеров строительных про- ектов. Бюджет первого этапа Основные статьи затрат первого этапа проекта приведены в таблице 5.6. Одним из главных ограничений бюджета было стремление минимизи- ровать затраты на заработную плату выделенного персонала проекта. Таблица 5.6. Смета затрат проекта по внедрению системы управления проектами (первый этап) Оборудование Кон-во План Цен.-’, дол Всего, дол. Организация канала 1 1 000 1 000 Сетевое оборудование 1 500 500 Сервер 1 2 500 2 500 Компьютер РМ-менеджера 2 800 1 600 Источник бесперебойного питания 1 750 750 ИТОГО 6 350 Заработная плата Кол-во 3/п. дол.в месяц Всего з/п, дол. Системный администратор СИС 1 350 2 100 РМ-менеджер 2 195 2 340 IT-консультант 1 200 1 200 ИТОГО 5 640 Прочие затраты Внешние консультанты, семинары, литература, неучтенные затраты 3 000 ВСЕГО РАСХОДЫ 14 990
190 Глава 5 Внутренние консультанты Исходя из ограничений бюджета «профиль» внутреннего консультанта был сформирован следующим образом: • возраст — 21—23 года; • образование — высшее техническое (можно привлекать студен- тов старших курсов), желательно в области управления строи- тельством; • опытный пользователь ПК, желательно знание пакетов MS Project; • количество и пол — два человека, мужчина и женщина; • комбинаторное мышление, т. е. способность к восприятию про- цесса (задачи) в целом и его реализации (решения) с помощью детализации на отдельные (вложенные) подзадачи с последова- тельным их выполнением; • низкие стартовые материальные претензии. Предполагаемая зар- плата на первые полгода — 100 дол. в месяц плюс премии (с пре- миями — до 200 дол.); • высокая работоспособность, в том числе при использовании компьютера; • обучаемость, в том числе самообучаемость; * знание технического английского (желательно, так как много литературы на английском языке); • высокая организованность, внутренняя дисциплина, пунктуаль- ность, аккуратность в делопроизводстве (бюрократ в хорошем смысле слова) в сочетании с амбициями руководителя-специа- листа. Как минимум стремление получить перспективную спе- циальность, способность в дальнейшем работать удаленно в любом регионе. Условия работы и ожидания результатов: • Рабочий день ненормированный (ежедневная самостоятельная работа по плану), письменные отчеты руководителю по каждо- му выполненному заданию. • Участие в подготовке докладов и презентаций о ходе исполне- ния программы. • Создание MS Project-шаблонов стандартных строительных про- цессов и ведение на их базе управления реальными строительны- ми работами. Разработка и оптимизация процесса управления проектом средствами MS Project. Выработка проектов управленче- ских решений для руководителей работ и генерального директора.
Проекты и стандарты. Стандарт управления проектами строительной компании 191 Исходя из этих требований и условий было решено взять на роль внут- ренних консультантов студентов, обучить их и учиться вместе с ними. Обязательным условием работы внутренних консультантов было состав- ление ежедневных и сводных еженедельных отчетов об изученном мате- риале. Полученные отчеты использовались в дальнейшем для обучения других сотрудников компании. Важным обстоятельством являлась правильная мотивация сторон. Компания в виде письменных отчетов получила подробную инфор- мацию по управлению проектами начального уровня на доступном язы- ке. Она минимизировала финансовые риски, имея возможность пре- кращения проекта в любой момент. Наконец, в случае успешного за- вершения этапа компания за минимальные деньги получала молодых специалистов (уровня секретаря проекта). Студенты получили современную профориентацию, возможность найма по окончании вуза на работу в компанию, добавку к стипендии в размере 100—150 дол. в месяц. После завершения курса самостоятельного обучения студенты были направлены на сертифицированные курсы. Со студентами были за- ключены договора, в которых оговаривались условия финансирования их образования и ответственность сторон после прохождения учебы. Пилотные проекты Результаты подготовки внутренних консультантов были признаны по- ложительными, и затем была начата собственно работа но внедрению методов проектного управления на реальных (пилотных) проектах. В рабочие группы в качестве секретарей проектов были включены внут- ренние консультанты, которые вели учет деятельное ш по строитель- ству объектов в стандарте MS Project и готовили проекты решений для руководителей проектов. Результаты первого этапа Ограничение по срокам (6 месяцев) было соблюдено. Однако, как ока- залось, при более четкой постановке задачи возможно сокращение сро- ков этого этапа до 30%. Ограничения по бюджету оказались даже перевыполнены. Эконо- мия бюджета составила более 30%. Второй этап — разработать и внедрить Задачи второго этапа Задачи второго этапа были сформулированы следующим образом: • разработать и реализовать программу обучения и сертификации высшего управленческого персонала, менеджеров среднего зве-
192 Глава 5 на, а также всех сотрудников, принимающих непосредственное участие в проектах; • разработать и внедрить с помощью внешнего консультанта стан- дарт предприятия по управлению проектами. В качестве базового курса обучения управленческого персонала была выбрана программа, основанная на стандарте ANSI PMI PMBOK®Guide 2000. Для выработки у сотрудников единого понимания управления проектами и подхода к его внедрению в компании была заказана спе- циальная трехдневная программа тренинга, состоявшая из одноднев- ного мастер-класса и двухдневной проектной мастерской, посвящен- ных углубленному рассмотрению вопросов создания и использования корпоративного стандарта по управлению проектами. Затем был прове- ден специальный курс обучения, направленный на подготовку к про- фессиональной международной сертификации IPMA, и осуществлена сертификация сотрудников на уровни В, С и D. К моменту завершения обучения в компании сложилась следующая ситуация: * Сформировалось понимание необходимости и желание реализо- вать свой, уникальный путь перехода к управлению проектами на основе стандарта. • Была подготовлена команда достаточно образованных в проект- ном управлении менеджеров, в том числе высшего звена. • Были сформированы достаточные в долгосрочном плане риско- вые ресурсы. • Появилось понимание возможностей и специфики работы кон- сультантов и образовательных учреждений, предлагающих услу- ги в области управления проектов. Далее было принято решение о начале собственно разработки стан- дарта. Участники второго этапа проекта Для разработки собственного корпоративного стандарта была создана группа из четырех участников: I. Сама компания как заказчик стандарта. В компании была соз- дана рабочая группа из ведущих специалистов и руководителей. 2. Независимые эксперты по управлению проектами, привлечен- ные заказчиком для формирования заданий консультантам, экс- пертизы и приемки выполненных работ.
Проекты и стандарты. Стандарт управления проектами строительной компании 193 3. Консультант — основной разработчик стандарта, выбранный на конкурсной основе. 4. BAS programme (программа поддержки консалтинга Европейского банка реконструкции и развития) — консультирование и финан- совая поддержка (финансирование части стоимости проекта). Содержание работ По результатам анализа организационной структуры компании, вы- полняемых проектов, регламентов взаимодействий внутри компании и документооборота были разработаны: • классификация проектов; • предложения по изменению организационной структуры ком- пании для обеспечения ее соответствия проектной ориентации; • регламенты проведения проектов; • роли и ролевые инструкции участников проектов; • шаблоны жизненных циклов проектов; • глоссарий; • состав проектного документооборота. Затем были разработаны нормативно-методические документы, вклю- чая положения, должностные инструкции по организационной струк- туре, а также шаблоны управленческих документов проекта. Кроме того, были проведены тренинги для сотрудников компании по использова- нию стандарта. Вторая стадия завершилась разработкой постановки задачи для внед- рения информационной системы по управлению проектами. Общая продолжительность второго этапа составила 5 месяцев. Бюджет второго этапа Основные статьи затрат второго этапа проекта приведены в таблице 5.7. Одним из главных ограничений бюджета было стремление оптимизи- ровать затраты на услуги внешних консультантов за счет приглашения заказчиком независимых экспертов по управлению проектами (для повышения качества формирования заданий внешним консультантам), экспертизе и приемке выполненных работ. Другим ограничением яв- лялось стремление минимизировать затраты времени ведущих специа- листов и руководителей, выделенных в состав рабочей группы. Результаты второго этапа Ограничение по срокам (5 месяцев) было соблюдено, а ограничения по бюджету оказались даже перевыполнены. Экономия бюджета со- ставила более 50%.
194 Глава 5 Таблица 5.7. Смета затрат проекта по внедрению системы управления проектами (второй этап) Статья Кол-во На человека, дол. в месяц Всего, дол. Независимые эксперты 2 500 5 000 Консультанты 3 1 000 15 000 Обучение 16 сотрудников 16 13 000 Сертификация 16 сотрудников 16 12 000 Оценка затрат членов рабочей группы (в среднем 20% рабочего времени) 5 500 5 000 ВСЕГО РАСХОДЫ 50 000 А главное, как раз после осуществления второго этапа создания и внедрения стандарта управления проектами (мы уверены, что именно поэтому) эта не очень большая компания выиграла тендер на роль управ- ляющей компании в строительстве большого промышленного объекта (стоимостью 15 млн дол.), осуществляемого западным инвестором. 5.6. Управление проектами в строительстве — технология или философия? В заключение главы стоит вернуться к вопросу об «интеллектуальной ценности» (по выражению П. Морриса) управления проектами для строительной отрасли. Как отмечает целый ряд авторов, сегодня меня- ется восприятие ценности объектов недвижимости [9, 21, 22]. Причем эти перемены происходят в сознании всех участников соответствующего рынка. В итоге меняется и отношение к той ценности, которую управ- ление строительными проектами может добавить к стоимости объекта недвижимости. А следовательно, меняется и подход к управлению строи- тельными проектами. Девелоперский проект Авторы монографии по управлению нефтегазостроительными проек- тами обращают внимание на одну важнейшую их особенность: «Созда- ние строительного объекта никогда не является окончательным ре- зультатом, после которого никаких следов от проекта не остается» [23, с. 91]. Следующим шагом в логической цепочке их рассуждений явля- ется необходимость отказа от взгляда на проект как на деятельность, направленную на достижение разовой конечной цели. В противовес традиционным «терминальным» проектам авторы книги предлагают
Проекты и стандарты. Стандарт управления проектами строительной компании 195 включать в рамки единого проекта не только создание объекта, но и его последующее развитие в процессе эксплуатации. В таком «развивающемся» проекте далеко не все конечные цели определены заранее. Их появление часто связано с внешними обсто- ятельствами, в частности с теми (но не только), на которые указал П. Мор- рис (см. цитату в разделе 5.2). Например, появление новых технологий может потребовать модернизации оборудования, а стремление к эф- фективности - привести к перепрофилированию и перепланировке здания. А завершается такой проект только вместе с завершением жиз- ненного цикла объекта. Эти выводы находят подтверждение в реальной сегодняшней практи- ке инвестиционно-строительной деятельности, основанной на концеп- ции девелопмента, когда цель состоит не в том, чтобы создать объект, а в том, чтобы создать объект, который будет приносить как можно боль- шую прибыль в течение максимально возможного периода. А раз так, то традиционный строительный проект является лишь частным случаем проекта девелоперского, жизненный цикл которого кроме упомянутых выше стадий включает также стадии эксплуатации и ликвидации (при- меры подобных жизненных циклов можно найти в работе [12]). Сервисная модель строительного проекта Авторы этой модели устанавливают прямые зависимости между харак- теристиками создаваемого объекта недвижимости и стратегическими потребностями будущего владельца здания, такими как необходимость обновления системы управления, организационной структуры, реин- жиниринга, слияний и поглощений и т. д. [21]. При этом объект недви- жимости рассматривается как будущий ресурс управления, а целью управления строительным проектом объявляется «обеспечение буду- щей ценности, ожидаемой клиентами». Сервисная модель ориентирована, прежде всего, на «ценность в виде информации», т. е. на накопление знаний, которые необходимы для создания услуг уже на стадии эксплуатации объекта. Таким образом, знания становятся самостоятельным источником ценности. В соответ- ствии с этим формируются и главные инструменты сервисной модели. В области компетенций и навыков управленческого персонала это управ- ление системами проекта, информацией, отношениями, ценностью и целями проекта; в области технологий — автоматизированное управ- ление объектами недвижимости. «Ценность за деньги» Следует отметить, что наиболее последовательно новые подходы в управ- лении строительными проектами реализуют сторонники методологии Р2М, к которым, кстати, относятся и авторы сервисной модели. Яв-
196 Глава 5 ляясь по форме рамочным стандартом, Р2М, по сути, представляет собой философскую доктрину, способ мышления, позволяющий ре- шать сложные проблемы, реализовывать инновационные идеи [25, 26]. Глубину отличий Р2М от традиционных подходов к управлению про- ектами можно оценить уже по одному факту: роль контекстных огра- ничений в Р2М выполняют сложность проблемы, ценность результата и сопротивление среды, в которой реализуется проект, а вовсе не при- вычные время, деньги и качество. Новые возможности, открываемые подходом Р2М, описаны в ра- боте [22] на примере одной из японских строительных компаний — Sunagogumi (о. Хоккайдо). Отталкиваясь от ключевой миссии граж- данского строительства, которая состоит в «создании ценностей за день- ги», и учитывая реальное положение на строительном рынке Японии, компании удалось на корпоративном уровне сформулировать основ- ные задачи, от успешного решения которых в каждом проекте зависит итоговый успех компании. Эти задачи выглядят следующим образом: • Получение выгоды от строительства даже при проектах ограни- ченного масштаба. • Получение выгоды даже от реализации малорентабельных про- ектов. • Сотрудничество с теми, кто осуществляет продажи. • Сотрудничество с представителями центральных властей. • Поддержка контактов с местным населением. Эти формулировки, несмотря на их внешнюю декларативность, позво- лили точно сфокусировать усилия, направив их на конкретные участ- ки сопротивления внутренней (проблемное поведение персонала) и внешней (специфическое отношение местных жителей, организаций и властей) среды. Интересная деталь: для устранения проблемного поведения персо- нала проекта был рекомендован метод критической цепи, редко ис- пользуемый в Японии. Это лишний раз подчеркивает, что применение конкретного инструментария в проектах не должно быть самоцелью, а должно вытекать из целей и задач, зафиксированных на уровне корпо- ративной стратегии. Литература 1. Ципес Г. Л. Система управления проектами: интеграционный подход // Директор информ, службы. 2000. № 12.
Проекты и стандарты. Стандарт управления проектами строительной компании 197 2. Ципес Г. Система управления проектами организации // Интеграл. 2003. № 4(12). 3. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003. 4. Товб А., Ципес Г. Менеджмент проектов в практике современной компа- нии // Управление проектами и программами. 2006. № 2(6). 5. Товб А., Ципес Г. Управление проектами // ComputerWorld Россия. 2002. № 37. 6. Товб А., Ципес Г. Управление проектами // Управленческий консультант. Настольная книга руководителя. Киев: ТзОВ «БУК», 2005. 7. Никитенко С. Ароматы кухни внедрения СУП // Директор информ, служ- бы. 2001. № 4. 8. Полуэктов Д. Взлет и падение менеджера — хронология одного проекта // Директор информ, службы. 2001. № 9. 9. Моррис П. Нерелевантность управления проектами как профессиональной дисциплины // Управление проектами. 2005. № 3(3). 10. Ципес Г. Л. Еще раз о СУПе и кухне // Директор информ, службы. 2001. № 6. 11. Танака X. Комплексное управление проектами в подрядных организа- циях // Управление проектами и программами. 2006. № 1(5). 12. Construction extantion to a guide to the Project Management body of knowledge. PMBOK®Guide - 2000 Ed. PMI, 2003. 13. Арчибальд P. Глобальная система категоризации проектов: необходимость и предлагаемый подход, применение на практике и описание текущего состояния проекта разработки системы // Управление проектами. 2005. № 1(1)—2(2). 14. Бовтеев С., Ефременко В., Рыбное Е., Фролов В. Управление проектами в строительстве. СПб.: С.-Петерб. гос. архитект.-строит, ун-т, 2004. 15. Колесников А. Менеджмент качества проектов при создании телекоммуни- кационных систем // Междунар. симпозиум «Управление проектами: Биз- нес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г. 16. Дорожкин В. Ценообразование и управление стоимостью в строительстве. Воронеж: Изд-во им. Е. А. Болховитинова, 2003. 17. Дорожкин В. Управление стоимостью — приоритетная сфера деятельности в системе управления проектами // Управление проектами. 2005. № 1(1). 18. Ишикура М. Интеграция современного управления проектами и програм- мами и инжиниринга на примере завода сжиженного природного газа Qatargas // Управление проектами. 2005. № 1(1). 19. Летучий Б. Большой стандарт для маленькой компании // Директор ин- форм. службы. 2001. № 7. 20. Мариничев Ю., Габов В. Опыт создания стандарта управления проектами строительной компании // Междунар. симпозиум «Управление проекта- ми: Бизнес. Идеи. Практика», С.-Петербург, 17-18 мая 2005 г.
198 Глава 5 21. Танака К. Создание ценностей в строительной отрасли: новая сервисная модель для рынка «обновленного» строительства // Управление проектами. 2005. № 4(4). 22. Охара Ш., Кишира Ю. Применение методологии Р2М в гражданском строи- тельстве и анализ результатов // Управление проектами. 2005. № 1(1). 23. Забродин Ю., Коликов В., Саруханов А. Управление нефтегазостроительны- ми проектами. М.: Экономика, 2004. 24. Ципес Г., Товб А. Рецензия на книгу «Управление нефтегазостроительными проектами» // Управление проектами. 2005. № 4(4). 25. Охара Ш. Путем Р2М // Директор информ, службы. 2003. № 12. 26. Ohara Sh. Program and Project Management for innovation of enterprises. JPMCC, 2002.
Глава 6 Проекты и деньги. Бюджетирование и финансирование проектов в органах государственного управления
Содержание главы 6 6.1. Краткий обзор методологии....................................201 Бюджетирование, ориентированное на результат..................201 Социальная и экономическая эффективность государственных расходов...................................203 Логико-структурный подход.....................................204 6.2. Структура целевой программы..................................205 6.3. Оценка выполнения целевых программ...........................206 У....................................ровень базовых показателей................................209 У............................................ровень измерителей........................................209 У................................ровень комплексных показателей............................213 6.4. Финансовое управление проектами целевой программы............214 Особенности финансового управления государственными программами...............................214 Формирование бюджета программы................................215 Финансовый анализ проекта.....................................217 Финансовый аудит проекта......................................219 Финансовый отчет для Инвестора................................219 Литература........................................................222
6.1. Краткий обзор методологии Бюджетирование, ориентированное на результат В главе 2 мы обсуждали вопросы взаимосвязи проектов со стратегией компании. В общеметодологическом плане приведенные соображения приводят к расширению традиционного «тройственного» ограничения проекта и превращению его в «квадратичное» или «пирамидальное» ограничение (см. рис. 6.1). Это означает, что кроме прямых результа- тов проекта его инициаторов должны заботить, причем в первую оче- редь, и более отдаленные эффекты, а именно эффекты, связанные с достижением стратегических целей компании. Соблюдение четвертого ограничения на формальном уровне можно контролировать, только если в компании есть формализованная стратегия и определены основ- ные приоритеты и соответствующие количественные показатели. Время Качество результата А . .. Стоимость Стратегия Качество результата Время Стоимость Рисунок 6.1. Ограничения проекта Возможность контроля соответствия проектов стратегии является особенно важной для государственного сектора. В работе [1] отмеча- ется, что для стран с развитой демократией это связано главным обра- зом с тем, что налогоплательщики хотят знать, на что идут их деньги, 201
202 Глава 6 выступают за обеспечение прозрачности использования государственных ресурсов. Добавим к этому, что в нашей стране внедрение подобных механизмов позволит сломать порочную практику «освоения средств» без учета целесообразности затрат. Для решения именно этой задачи в министерствах и ведомствах используются целевые программы. Казалось бы, в чем проблема? Це- левая программа потому и целевая, что мероприятия, включенные в ее состав, соответствуют неким конечным целям. Однако на практике часто оказывается, что цели, формулируемые на верхнем уровне влас- ти, не соответствуют реальным ожиданиям налогоплательщиков. Кроме того, механизмы организационного планирования, тради- ционно применяемые в государственных структурах, порождают раз- рыв между стратегическим уровнем планирования и уровнем конкрет- ных мероприятий, не обеспечивают адекватной трактовки целей на уровне исполнителей. Ситуация осложняется еше и тем, что для мас- штабных программ социально-экономических преобразований харак- терны специфические факторы, делающие эти связи еще менее про- зрачными. Анализируя программу пенсионной реформы в Швеции, Я. Эклоф выделяет несколько таких факторов [2]: • заинтересованные стороны часто имеют конфликтующие инте- ресы; • временные рамки проектов часто являются нереалистичными, а выделяемые ресурсы — недостаточными; • последствия проектов не всегда достаточно полно анализируют- ся, в том числе прямое или косвенное, положительное и отри- цательное влияние; • внешние факторы приводят к изменениям «правил игры» уже во время выполнения проектных работ. Методология бюджетирования, ориентированного на результат1 (БОР — performance budgeting), появилась как инструмент, позволяющий ре- шать эти и другие проблемы через определение жесткой взаимосвязи между понесенными затратами и конкретными стратегическими целя- ми, тактическими задачами и ожидаемыми социально-экономическими результатами деятельности государственных организаций [4, 5]. 1 В русскоязычной литературе применяются также термины «бюджетирование по результатам» и «программно-целевой подход».
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 203 Социальная и экономическая эффективность государственных расходов Следующий вопрос состоит в том, как, имея хорошую стратегию, реали- зовать ее на практике. Как отмечено в работе [5], одним из критиче- ских факторов успеха при внедрении БОР является создание системы показателей социальной и экономической эффективности государствен- ных расходов. Под социальной эффективностью (effectiveness) понимается дости- жение определенного социального результата в расчете на единицу затрат. Социальные результаты являются конечными результатами (out- comes) исполнения целевой программы, а показатели социальной эф- фективности (effectiveness/outcomes indicators) определяют степень достижения общественно значимых целей. Под экономической эффективностью (efficiency) понимается объем выпуска товаров (услуг) на единицу затрат. Соответствующие резуль- таты являются прямыми результатами (outputs) деятельности, а пока- затели определяют либо объем услуг (показатели выпуска — output indi- cators), либо издержки на единицу выпуска (экономическая эффектив- ность — efficiency indicators). Естественно, расчет показателей эффективности невозможен без учета затрат. Для этой цели служат показатели затрат (input indicators), дающие количественную оценку используемых человеческих, матери- альных и финансовых ресурсов. Необходимость введения этих групп показателей объясняется тем, что главные показатели — показатели социальной эффективности — являются «отложенными». Иными словами, возможность замерить ре- альный социальный эффект от реализации программы появляется спустя весьма значительное время, после того как понесены затраты. Это означает, что при формировании целевой программы мы долж- ны позаботиться о том, чтобы каждое мероприятие, включаемое в со- став целевой программы, в той или иной степени приближало нас к конечной стратегической цели. На этапе формирования программы это будет всего лишь гипотезой, но желательно, чтобы это была макси- мально обоснованная гипотеза. Однако даже если эта гипотеза в прин- ципе верна, реальный вклад мероприятия в достижение стратегиче- ских целей будет зависеть от того, насколько успешно оно выполнено. Поэтому для каждого мероприятия должна даваться оценка его выпол- нения. Соответствующие показатели, являясь «отложенными» для кон- кретного мероприятия, становятся «опережающими» для программы в целом и позволяют оценивать успешность реализации программы, не дожидаясь ее завершения (разумеется, при условии, что первоначаль- ные гипотезы верны).
204 Глава 6 Логико-структурный подход Управление каждым отдельным проектом, реализуемым в рамках це- левой программы, требует особых подходов, которые учитывают нали- чие высокоуровневых целей, необходимость подтверждения достижений, а также специфические риски, возникающие вследствие упомянутых выше допущений и гипотез. Совокупность этих факторов представляет собой так называемую логико-структурную схему проекта, вокруг ко- торой выстраивается вся система управления проектом. Процесс формирования логико-структурной схемы проекта, сфор- мулированный в методике управления, ориентированного на результат (Results Based Management, RBM) [1], состоит в том, что мы соотносим результаты проекта, различающиеся по значимости и времени их по- лучения, с иерархией целей проекта, отвечая на вопросы: • Как мы будем достигать ожидаемого результата (наши затраты и действия)? • Что мы произведем? • Что мы получим в результате этих инвестиций? • Почему мы это сделали? Более подробное описание логико-структурного подхода (Logical Frame- work Approach, LFA) и опыт его применения в проектах, реализуемых в России при участии таких международных организаций, как Всемир- ный банк, ТАСИС и др., можно найти в работе [6]. Сравнение БОР и RBM/LFA, представленное в таблице 6.1, наглядно показывает, что эти методики оперируют одними и теми же понятия- Таблица 6.1. Иерархия целей и результатов в программах и проектах Уровень планирования Результаты программы (по методике БОР) Результаты проекта (по методике RBM/LFA) Долгосрочные цели Прогресс в приоритетных областях государственной политики Отдаленные последствия реализации проекта Среднесрочные цели Конечные результаты программы, получаемые как общий результат реализации программы Изменения в организации или обществе, ради реализации которых были предприняты инвестиции Краткосрочные цели Прямые результаты программы, получаемые как результат реализации отдельных мероприятий Непосредственный продукт проекта, получаемый в результате совершенных в проекте действий и понесенных затрат
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 205 ми и должны использоваться совместно. При этом БОР работает как инструмент планирования и последующего контроля, a RBM/LFA — как инструмент управления проектами в рамках целевых программ. 6.2. Структура целевой программы Одной из серьезных проблем планирования государственных расходов является непрозрачность причинно-следственных связей между мероприя- тиями, осуществление которых запланировано для выполнения такти- ческих задач. Традиционным инструментом преодоления этой пробле- мы являются целевые программы. Однако механическое объединение мероприятий в целевую программу, возможно, помогает управлять их реализацией, но само по себе ничего не дает с точки зрения принятия решений по выделению средств на те или иные мероприятия. Каким же требованиям должна отвечать целевая программа, чтобы решения по ее финансированию были максимально обоснованными? С точки зрения методологии БОР принципы формирования целевых программ звучат достаточно просто: — в программе должны в максимальной степени объединяться схо- жие виды бюджетных услуг; — программа должна предусматривать оказание только тех бюд- жетных услуг, которые необходимы для достижения программ- ной цели; — одинаковые бюджетные услуги, как правило, не должны повто- ряться в разных программах. Сложность состоит, однако, в том, что взаимосвязи между целями, задачами и мероприятиями являются объективно сложными. Далеко не всегда возможно выстроить простую и понятную древовидную струк- туру программы, в которой бюджетные услуги аккуратно «раскладыва- ются» в разные ячейки на нижнем этаже иерархии. И вместе с тем соблазн строить такие «деревья» очень велик — даже в тех случаях, когда подобная модель искажает реальную картину мира. Результатом подобного искажения, как правило, становится появление в различ- ных разделах программы очень близких по звучанию и смыслу меро- приятий. А это, собственно, и порождает возможность произвольных трактовок положений программы, нецелевого расходования средств, «перетягивания одеяла на себя» и т. д. На наш взгляд, решение по структуре целевой программы в каждом конкретном случае должно быть абсолютно индивидуальным и ни в коем случае не должно следовать изначально заданному канону, даже
206 Глава 6 если в качестве такового выступает столь распространенная иерархи- ческая модель. Примером другого (неиерархического) подхода служит структура программы, при формировании которой используется не одно основа- ние для классификации мероприятий (как это было бы в иерархиче- ской структуре), а два — стратегические цели программы и области деятельности (функции) государственного органа, отвечающего за реа- лизацию программы. Как отмечалось выше, в структуре целевой программы, построен- ной с использованием методологии БОР, конкретные цели должны увязываться с прямыми и конечными результатами, достигаемыми в результате исполнения этой программы. Структура целевой програм- мы, представленная в форме таблицы, дает наглядное представление о соответствии целей и результатов и позволяет точно определить, на какие мероприятия и с какими целями расходуются бюджетные сред- ства (см. рис. 6.2). Поясним этот подход на примере муниципальной целевой програм- мы поддержки малого предпринимательства (МП). В таблице 6.2 приведены основные социально значимые результа- ты программы в привязке к конечным потребителям, в качестве кото- рых выступают как субъекты малого предпринимательства (СМП), так и просто граждане, занятые в сфере малого предпринимательства или потребляющие производимые здесь продукты и услуги. В таблице 6.3 перечислены области деятельности структурного под- разделения (департамента поддержки малого предпринимательства), отвечающего за реализацию целевой программы, и те прямые резуль- таты его деятельности, которые непосредственно влияют на достиже- ние стратегических целей программы. В число прямых результатов входят системы, документы, инфор- мационные ресурсы, методологии, которые производятся для исполь- зования государственными структурами и субъектами малого предпри- нимательства. При этом предполагается, что эти продукты помогут достижению конечных результатов, к которым отнесены новые возмож- ности бизнеса, которые получают субъекты малого предприниматель- ства, — защищенность, доступ к ресурсам, доступ к государственным заказам и т. д. Итоговая структура целевой программы поддержки малого пред- принимательства представлена в таблице 6.4. 6.3. Оценка выполнения целевых программ Оценка выполнения целевых программ является гораздо более слож- ной задачей, чем может показаться после поверхностного знакомства с
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 207 Рисунок 6.2. Матричная структура целевой программы
208 Глава 6 Таблица 6.2. Конечные результаты программы поддержки малого предпринимательства Стратегические цели Внешний потребитель Социально значимые (конечные) результаты Обеспечение нормативно-правовой поддержки МП СМП Снижение уровня административных барьеров Упорядочение деятельности контролирующих и инспектирующих органов Совершенствование финансового обеспечения СМП Расширение возможностей доступа СМП к источникам финансирования и другим услугам в финансовой сфере Совершенствование методов имущественной поддержки МП СМП Расширение возможностей и повышение эффективности использования государственного имущества в деятельности СМП Поддержка МП в области подготовки кадров Г раждане Формирование класса цивилизованных предпринимателей Поддержка производственной деятельности СМП СМП Г раждане Расширение возможностей доступа СМП к госзаказам Демонополизация рынков и пресечение недобросовестной конкуренции Таблица 6.3. Прямые результаты программы поддержки малого предпринимательства Области деятельности (процессы) департамента Прямые результаты Управление процессами жизненного цикла СМП Формализация деловых процессов в области МП Развитие инфраструктуры МП Расширение адресной поддержки объектов инфраструктуры МП Мониторинг и анализ сферы МП Повышение качества управления финансовыми потоками и инвестициями Разработка и внедрение информационных технологий в сфере МП Формирование типовой информационной среды для СМП
Проекты и деньги. Бюджетирование и финансирование проектов в органах. 209 методологией БОР. Рассмотрим некоторые подходы к решению этой задачи на основе системы показателей целевой программы, представ- ленной на рисунке 6.3. Уровень базовых показателей К базовому уровню отнесены показатели прямого и конечного резуль- татов. Интересно сравнить показатели, предлагаемые методологией БОР и методологией BSC, рассмотренной в разделе 2.1. Напомним, что методология BSC предлагает четыре группы показателей — финансо- вые показатели, клиентские показатели, показатели бизнес-процессов, показатели инноваций и персонала. Основное отличие государственного сектора состоит в том, что госу- дарственные организации, обслуживая граждан, не преследуют коммер- ческих интересов, т. е. клиентская составляющая в их деятельности превалирует над финансовой. Однако этот факт не отменяет финансо- вой составляющей, поскольку кроме клиентов, которые получают го- сударственные услуги, у государственных организаций с\ шсств\ ю г еше и клиенты, оплачивающие эти услуги, — само государство или сторон- ние инвесторы. И интерес последних лежит, главным образом, в обла- сти эффективного использования финансовых средств. Клиентские показатели, ориентированные на получателей государ- ственных услуг, фактически и являются показателями социальной эф- фективности целевых программ. В отличие от этого показатели, ори- ентированные на плательщиков, характеризуют процессы оказания государственных услуг и относятся, таким образом, к группе показате- лей экономической эффективности. Также в эту группу входят и пока- затели бизнес-процессов, показатели инноваций и персонала (см. табл. 6.5). На рисунке 6.3 показаны основные взаимосвязи между указанны- ми группами показателей. На показатели конечного результата влияют в первую очередь показатели основных процессов. Влияние показате- лей обеспечивающих процессов (таких, как управление ИТ, персона- лом и т. д.) на показатели конечного результата можно оценивать как напрямую, так и косвенно —- через влияние на показатели основных процессов. Уровень измерителей Для расчета базовых показателей требуется большой объем измери- телей — простых (обычно учетных) показателей, значения которых фор- мируются непосредственно при реализации различных функций в де- ловых процессах. Основным источником значений измерителей явля- ются статистические данные. Однако могут использоваться и другие источники информации о различных аспектах деятельности организа-
210 Глава 6 Таблица 6.4. Структура целевой программы Области доятольности департамента Нормативно- правовое обеспечение Финансы Стратегические цели Имущество Управление процессами жизненного цикла СМП • Совершенство- вание процессов регистрации и предоставления отчетности СМП • Формализация процессов предоставления финансовой поддержки • Упрощение и формализация процессов предоставления имущественной поддержки Развитие инфра- структуры МП • Создание объектов инфраструктуры, обеспечивающих предоставление нормативно- правовых услуг (в том числе колл-центров, центров безопасности) • Создание объектов инфраструктуры, обеспечивающих предоставление услуг в области планирования, управления финансами, бухгалтерии • Создание объектов инфраструктуры, обеспечивающих предоставление имущественных услуг (технопарки, лизинговые фирмы, бизнес-инкубаторы, производственно- технические центры) Мониторинг и анализ сферы МП • Формирование и организация ведения реестров СМП, проверяющих органов и проверок • Сбор и анализ данных о необходимых финансовых ресурсах (заявок СМП) • Планирование инвестиций и кредитов • Учет, контроль и анализ движения и целевого использования кредитов • Формирование и ведение реестра нежилых помещений, предаваемых Москомимуще- ством в фонд поддержки МП • Формирование и ведение реестра государственного имущества, которое может быть передано СМП Разработка и внедрение информа- ционных технологии в сфере МП • Создание информационных ресурсов в правовой сфере МП • Создание информационных ресурсов в сфере финансирования МП • Создание типовых конфигураций финансовых программных пакетов • Создание информационных ресурсов в сфере предоставления недвижимости для СМП Коночные результаты • Снижение уровня администра- • Расширение возможностей • Расширение возможностей (outcomes) тивных барьеров • Упорядочение деятельности контролирующих и инспектирующих доступа СМП . к источникам финансирования и другим услугам в финансовой и повышение эффективности использования государственного И муниципального г органов ’ ' имущества в деятельности СМП
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 211 программы поддержки СМП Образование и кадры Производственная деятельность Прямые результаты (Outputs) • Формализация процессов аккредитации учреждений делового образования и учебных и образо- вательных программ • Совершенствование процессов размещения муниципального заказа с целью облегчения доступа к нему СМП деловых процессов . в сфере МП • Создание объектов инфраструктуры, обеспечивающих предоставление услуг в области подготовки кадров для МП (обучающие, рекрутинговые, издательские, научно-методические центры) • Создание объектов инфраструктуры, обеспечивающих предоставление производственно- технологических услуг (хостинг) • Типовые организационно- функциональные ... структуры объектов инфраструктуры МП и организационно^ распорядительные документы - • Системы адресной поддержки объектов инфраструктуры. • Сбор и анализ данных по подготовке кадров для МП • Планирование мероприятий по подготовке кадров для МП • Сертификация качества производственных процессов • Учет, контроль и анализ деятельности СМП по выполнению государственного и муниципального заказа io:z> принятия решений в области развития сферы МП . финансовыми потоками и инвестиционными процессами • Создание информационных ресурсов в области обучения и подбора кадров • Разработка дистанционных обучающих систем • Создание информационных ресурсов по деятельности СМП • Создание объединенной дистрибьюторской торговой площадки СМП, объединенной закупочной площадки СМП OlEZ> • Единый информа- ционный портал • Типовая IT-стратегия малого: предприятия .• Типовая корпоративная информационная система малого предприятия • Формирование класса цивилизованных предпринимателей • Расширение возможностей доступа СМП к государствен- ным и муниципальным заказам • Демонополизация рынков и пресечение недобросовестной конкуренции
212 Гпава 6 Рисунок 6.3. «Дорожная карта» системы показателей целевой программы
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 213 Таблица 6.5. Показатели БОР и BSC Показатели БОР Показатели BSC Показатели социальной эффективности Клиентские показатели получателей государственных услуг Показатели экономической эффективности Клиентские показатели получателей государственных услуг (финансовые показатели) Показатели бизнес-процессов Показатели инноваций и персонала ции, например результаты выборочных тематических исследований (с использованием анкетирования, интервью и фокус-групп), техни- ческие обзоры и т. д. Уровень комплексных показателей Наиболее серьезная проблема возникает при попытке получить обоб- щенные оценки деятельности органов государственного управления по реализации целевой программы и объективное представление о фак- тическом влиянии, которое оказывают реализуемые мероприятия и получаемые прямые результаты на достижение конечных результатов программы. Как мы отмечали выше, наличие тех или иных зависимостей между прямыми и конечными результатами чаще всего является гипотезой, по- строенной экспертным путем в процессе формирования целевой програм- мы. Правильность этой гипотезы необходимо постоянно подтверждать в ходе выполнения целевой программы, поскольку именно на основа- нии этой гипотезы выделяются инвестиции в рамках программы. Сложность задачи состоит еще и в том, что, даже если фактически достигаемые значения показателей конечного результата значительно отличаются от прогнозируемых, это еще совсем не обязательно озна- чает, что неверна исходная гипотеза. Возможно, имели место внешние обстоятельства разового характера, которые внесли временные возму- щения в динамику показателей. Средняя и низкая точность прогноза означает, что при формирова- нии целевой программы была неверно оценена значимость тех или иных факторов, влияющих на успешность достижения конечных ре- зультатов. Возможно, с течением времени в ходе выполнения програм- мы появились новые факторы влияния, не учтенные ранее. В случае если эти факторы влияют на точность прогноза и если предполагается, что они не носят временного характера, может потребоваться пере- смотр и корректировка комплексного показателя. Более того, должен
214 Глава 6 быть проведен дополнительный анализ причинно-следственных свя- зей, что может привести к изменению структуры целевой программы и состава показателей. Таким образом, комплексные показатели этой группы не дают точ- ной локализации проблемы (ответа на вопрос «Почему конкретно не достигнуты ожидаемые результаты выполнения целевой программы?»), но сигнализируют о ее появлении и ограничивают область поисков возможного решения. Для формирования полной картины комплексных показателей следу- ет отметить также важность получения оценок вклада в реализацию целевых программ отдельных деловых процессов и/или подразделений организации. 6.4. Финансовое управление проектами целевой программы Особенности финансового управления государственными программами К проектам, осуществляемым в рамках государственных целевых про- грамм, как уже отмечалось, предъявляются повышенные требования с точки зрения прозрачности и возможностей контроля и учета использо- вания финансовых средств. Эти требования еще более ужесточаются, если к финансированию программ привлекаются внешние инвесторы, такие, например, как Всемирный банк. Каждая из инстанций, контролирующих выполнение программы (инвесторы, отраслевые министерства и т. д.), привносит собственные требования, нормативы и методические указания в правила формиро- вания, исполнения и контроля бюджета проекта, которыми должны руководствоваться исполнители. Другая важная особенность финансирования целевых программ отмечена в работе [7]. Она состоит в том, что для целевых программ принят годичный цикл финансирования, в то время как бюджет про- екта должен определяться на весь срок его выполнения, что соответ- ствует и методологии БОР, и требованиям Всемирного банка, и, ко- нечно, методологии управления проектами. Эти особенности оказывают существенное влияние на процессы, реализуемые в рамках целевых программ, и заставляют под несколько иным утлом взглянуть на такие основные задачи управления стоимостью проектов, как: • формирование бюджета программы в целом и отдельных про- ектов;
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 215 • финансирование проектов, включая учет фактических затрат, поступлений, формирование отчетности о состоянии стоимости и финансирования проекта; • анализ и регулирование стоимости проектов и программы в це- лом, включая проведение финансовых аудитов. Рассмотрим основные процессы, в рамках которых решаются задачи управления стоимостью проектов в составе целевых программ. Формирование бюджета программы Основными целями процесса формирования бюджета проекта являются: * ежегодное определение потребностей в финансировании отдель- ных областей проекта и расчет плановых затрат по проекту в контексте конкретных направлений работ, исполнителей и ис- точников финансирования; • формирование плана финансирования проекта, описывающего финансовые потоки проекта с указанием сроков поступления и расходования финансовых средств; • формирование плана счетов проекта, являющегося основой для авторизации затрат по проекту, учета расходов и финансового анализа. Потребность в финансировании определяется на основе оценки стои- мости ресурсов, необходимых для выполнения конкретных задач с уче- том календарного плана. Ресурсы, которые должны быть запланированы в проекте и учтены в его бюджете, относятся к следующим основным категориям: • рабочее время исполнителей; • финансовые средства; • средства производства и производственные мощности; • оборудование и материалы. План финансирования представляет собой требования к инвестору, детализированные по статьям затрат в привязке к календарным перио- дам. Основываясь на этих данных, план финансирования устанавли- вает уровень ежемесячных (ежеквартальных) расходов по программе и соответствующий ему уровень финансирования, необходимый для вы- полнения всех проектов в ее составе.
216 Глава 6 План счетов проектов позволяет не только формализовать процеду- ры учета затрат по проекту и гармонизировать их с требованиями бухгал- терского учета и отчетности, но и определить внутри проекта центры ответственности за конкретные виды затрат. Необходимо выделить три стадии формирования бюджета: • Предварительный бюджет формируется на предконтрактной ста- дии для проведения конкурса или тендера по выбору исполни- теля. • Рамочный бюджет формируется на стадии заключения контрак- та и определяет весь объем финансирования проекта. • Годовой бюджет формируется на каждый год реализации проек- та и определяет объем финансирования на планируемый год в пределах рамочного контракта. Основанием для осуществления финансового планирования являются план проекта и заявки подрядчиков на финансирование работ в пла- нируемом году. Предварительный бюджет проекта формируется в соответствии с требованиями Всемирного банка или иного инвестора и определяет все основные составляющие стоимости в разбивке по видам деятель- ности (см. табл. 6.6). Рамочный бюджет проекта формируется в виде сметы расходов как приложение к протоколу согласования цены. Комплект документов, определяющих структуру бюджета проектов, может быть различным в зависимости от отраслевых требований. Например, в соответствии с требованиями и методическими рекомендациями Министерства эко- номического развития и торговли России он включает [8]: • протокол согласования цены; • смету расходов (см. табл. 6.7); • расшифровку затрат по статье «Материалы»; • расшифровку расходов по статье «Специальное оборудование»; • расшифровку затрат по статьям «Основная заработная плата», «Дополнительная заработная плата», «Отчисления на социальные нужды»; • расшифровку затрат по статье «Командировочные расходы»; • справку о размере накладных расходов к структуре цены; • расшифровку затрат по статье «Прочие прямые расходы»; • расшифровку затрат по статье «Затраты по работам, выполняе- мым сторонними организациями и предприятиями» (структура аналогична смете расходов) (см. табл. 6.7).
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 217 Таблица 6.6. Структура бюджета проекта Составляющая Ц6НЫ Разбивка цены Виды деятельности Всего 1 2 3 4 Оплата труда Основной штат Местный персонал Консультанты Всего Возмещаемые расходы Международные перелеты Разные транспортные расходы Суточные Местные транспортные расходы Аренда помещения, жилья, канцелярских услуг Всего Разные расходы Расходы на связь Составление, копирование отчетов Оборудование: автомашины, компьютеры и т. д. Программное обеспечение Всего Всего Ежегодный бюджет проекта формируется в виде сметы расходов, ана- логичной смете рамочного бюджета с разбивкой расходов по кварта- лам и месяцам. Финансовый анализ проекта Целью процесса финансового анализа проекта является контроль вы- полнения плана работ и финансирования проекта для решения следу- ющих задач: • сопоставления затрат с предусмотренным бюджетом и опреде- ления отклонений от бюджета; • принятия необходимых корректирующих мер при отклонении от бюджета. Учет затрат осуществляется на постоянной основе как на уровне от- дельных задач, так и на более высоких проектных уровнях, в том числе
218 Глава 6 Таблица 6.7. Смета расходов № Наименование статей расхода Сумма, тыс. руб. 1 Материалы 2 Специальное оборудование (только для проектов, финансируемых по статье «НИОКР») 3 Основная заработная плата 4 Отчисления на социальные нужды 5 Программное обеспечение (только для проектов, финансируемых по статье «Прочие нужды» или «Инвестиции») 6 Накладные расходы 7 Командировочные расходы 8 Прочие расходы Итого НДС (только для проектов, финансируемых по статье “Прочие нужды или “Инвестиции.:) Итого с НДС (только для проектов, финансируемых по статье «Прочие нужды» или «Инвестиции») на уровне проекта в целом. Необходимо учитывать следующие виды расходов: • реальные прямые затраты (труда, материалов и др.), понесен- ные в текущем периоде; • расходы будущих периодов, которые еще не отражены в бухгал- терской документации, но необходимость которых уже выявлена; • «запоздалые» расходы, к которым относятся затраты предыду- щих периодов, по тем или иным причинам (административные ошибки, позднее представление счетов-фактур и т. д.) попавшие на текущий календарный период. Для финансового анализа используется информация о плановом и фактическом состояниях проекта и бюджета проекта. Результатом процесса финансового анализа является Отчет о фи- нансовом анализе проекта, содержащий следующие разделы: • основные финансовые показатели проекта (в качестве таких показателей могут выступать, например, хорошо известные по- казатели освоенного объема [9, 10]);
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 219 • необходимые корректирующие меры, принятие которых нахо- дится в компетенции руководителя проекта; • предлагаемые изменения в бюджете, которые необходимо выне- сти на рассмотрение вышестоящих инстанций. Финансовый аудит проекта Целью данного процесса является проведение проверки соответствия про- екта процедурам и правилам финансирования контрактов по проекту. Основными задачами процесса являются: • проверка бухгалтерской отчетности и платежно-расчетной до- кументации, относящейся к проекту; • подтверждение достоверности данных, содержащихся в отчетах и иных документах проекта, выявление фактов нарушения по- рядка ведения бухгалтерского учета; • проверка соблюдения требований законодательства при совер- шении финансово-хозяйственных операций при осуществлении проекта. Проведение финансового аудита проекта осуществляется с привлече- нием аудиторской компании, выбираемой по согласованию с предста- вителем инвестора. При финансовом аудите проекта изучаются: • документы, связанные с финансированием контрактов по проекту; • бухгалтерские документы. Результатом данного процесса является аудиторский отчет о проекте. Проведение финансового аудита должно осуществляться ежегодно, а также по завершении проекта. Финансовый отчет для Инвестора Целью данного процесса является предоставление финансовой отчет- ности по проекту Инвестору. В отчете должны отражаться затраты по проекту на уровне проекта в целом и на промежуточных уровнях структуры работ (этапах про- екта) и соотношение реальных и установленных бюджетом затрат. Отчет должен включать следующую информацию: • сведения о выполненных работах и прогнозируемом объеме ра- бот;
220 Глава 6 • фактически израсходованные финансовые средства и прогнози- руемые платежи по видам затрат; • поступления и платежи по источникам финансовых средств; • сравнение плановых и прогнозируемых платежей и поступлений. В отчет должны также включаться еще не отраженные в бухгалтерской документации прогнозируемые расходы будущих периодов. Исходными данными для этого процесса являются показатели пер- вичных финансовых документов и сведения о трудозатратах, связанных с выполнением работ проекта. Результатом данного процесса является ежеквартальный (периодичность может варьироваться для разных про- ектов) отчет для Инвестора. Пример структуры финансового отчета приведен в таблице 6.8. Таблица 6.8. Форма финансового отчета проекта ФИНАНСОВЫЙ ОТЧЕТ ПРОЕКТА Наименование организации-исполните пя Менеджер проекта: Ф.И.О., e-mail Составлен: ДД.ММ.ГГ Наименование проекта Отчет о ходе проекта с ДД.ММ.ГГ. по ДД.ММ.ГГ. Общее описание состояния проекта В этом разделе менеджер проекта должен дать общую оценку проекта. 1. Исполнение этапов проекта Этапы Старт Финиш (план/факт) (план/факт) Текущее состояние Ответственный Причина ПТ1Л nniinillin Этап 1 Этап ... 2. Исполнение бюджета этапов проекта Этапы План счетов проекта План Факт Прогноз План/Прогноз Этап 1 Материалы Специальное оборудование Основная заработная плата Отчисления на соцнужды Программное обеспечение Накладные расходы Командировочные расходы Прочие расходы Итого Платежи Итого Поступления Поступления — Платежи — _
Проекты и деньги. Бюджетирование и финансирование проектов в органах... 221 Этап ... Материалы — Специальное оборудование Основная заработная плата Отчисления на соцнужды Программное обеспечение Накладные расходы Командировочные расходы Прочие расходы Итого Платежи Итого Поступления Плгтип FltAMIACl fln’lTPWM 1 1 V* 1 у 1 U 1V* ПИЯ IIJIcllv* Лх 3. Исполнение бюджета проекта План счетов проекта Этапы План Факт Прогноз План Прог но ч Материалы Этап 1 Этап ... Итого:. Специальное оборудование Этап 1 Этап ... Итог о: Основная заработная плата Этап 1 Этап ... Итого: Отчисления на соцнужды Этап 1 Этап ... Итого Программное обеспечение Этап 1 Этап ... Итого: Накладные расходы Этап 1 Этап ... Итого: Командировочные расходы Этап 1 Этап ... Итого:. Прочие расходы Этап 1 Этап ...
222 Глава 6 Литература 1. Scott G. Result-based management and public/private partnership // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петер- бург, 17-18 мая 2005 г. 2. Ekluf J.A. Project Management in large socio ethical reform programs (with examples from Swedish experience) // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г. 3. Самощенков С., Сошнин А., Ципес Г. Программы и проекты в органах госу- дарственного управления // Сб. трудов IV Всерос. практ. конф. «Стандар- ты в проектах современных информационных систем», Москва, 21—22 ап- реля 2004 г. М.: ФОСТАС, 2004. 4. Бюджетирование, ориентированное на результат: цели и принципы. Эко- рис-НЭИ. 2002. 16 с. (www.nei.ru) 5. Бюджетирование, ориентированное на результат: международный опыт и возможности применения в России. Центр фискальной политики, 2002. 59 с. (www.nei.ru) 6. Позняков В. Проектное управление в международных организациях, рабо- тающих в России // Управление проектами. 2005. № 3(3). 7. Сошнин А. Применение методов проектного управления при подготовке и реализации федеральных целевых программ // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г. 8. Требования и методические рекомендации организациям — исполните- лям государственных контрактов в рамках ФЦП «Электронная Россия (2002—2010 годы)». Мин-во экон, развития и торговли РФ, 31 мая 2004 г. 9. Арчибальд Р. Управление высокотехнологичными проектами. М.: ДМК Пресс, 2002. 10. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003.
Глава 7 Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов
Содержание главы 7 7.1. Краткий обзор методологии...........................................225 ИТ-служба — партнер по бизнесу или «агент влияния»?.................225 Корпоративная стратегия и стратегия ИТ-службы.......................226 Стратегическая карта ИТ-службы......................................228 Ключевые показатели деятельности ИТ-службы..........................229 А кому сейчас легко?................................................233 7.2. Политика в проектах внедрения корпоративных информационных систем.....................................235 Политические риски проектов внедрения корпоративных информационных систем..............................235 Вовлечение, убеждение, принуждение..................................236 Рубежи сопротивления................................................239 У......................................ровень операционного персонала..................................239 У.................................ровень руководителей среднего звена.............................240 У............................................ровень высших менеджеров........................................242 У.......................................ровень генерального директора...................................243 Как это будет работать..............................................243 Программа действий для СЮ...........................................244 7.3. ИТ-проекты и персонал компании......................................244 Человек или ресурс?..............................................244 Кадровые вопросы в стратегии компании...............................245 Чего мы ждем от своих сотрудников................................245 Как оценивать работу сотрудников.................................246 Как помочь сотрудникам выполнять возложенные на них задачи.......247 Управление персоналом в переходный период, связанный с внедрением информационных технологий.................247 Оценка персонала.................................................247 Компенсация и мотивация..........................................247 Психологическое сопровождение проектов...........................248 7.4. ИТ-проекты в портфелях и программах.................................248 7.5. Управление ИТ-проектами в холдинге: подходы и рекомендации..........253 Типы управления ИТ в холдинге.......................................253 Жесткая централизация............................................253 Децентрализованная структура.....................................254 Мягкая централизация.............................................255 Политика информатизации ................................................................................. 256 Общие процессы управления...........................................257 Управление инвестициями..........................................257 Управление ИТ-проектами..........................................259 Управление ресурсами.............................................260 Управление закупками.............................................260 7.6. Повесть о настоящем проекте.........................................261 Предпосылки проекта.................................................261 Участники проекта и их цели.........................................264 Роли и распределение ответственности................................264 Команда проекта.....................................................266 Предметная область..................................................266 Управление проектом.................................................267 Основные проблемы и факторы успеха проекта..........................268 Уроки управления сложным комплексным ИТ-проектом....................270 Литература...............................................................271
7.1. Краткий обзор методологии ИТ-служба — партнер по бизнесу или «агент влияния»? Эта глава посвящена применению проектного управления в ИТ-инду- стрии. Но рассматривать мы будем не деятельность разработчиков про- граммного обеспечения, поставщиков оборудования и системных инте- граторов, а ИТ-проекты с позиции заказчика, т. е. компании, в интересах которой эти проекты реализуются. Прежде всего нас интересует роль в этих проектах ИТ-службы компании. Сегодня широкое распространение получил взгляд на ИТ как на неотъемлемую часть любого бизнеса. И в этом смысле ИТ-служба стано- вится одним из ключевых подразделений компании, которые факти- чески несут ответственность за конечные результаты ее деятельности. Однако существует и другой взгляд. Часто ИТ-служба воспринимается как «агент влияния» ИТ-индустрии, оттягивающий на себя финансовые средства и другие ресурсы компании, необходимые для решения иных, более значимых вопросов. Именно поэтому столь необходимо правиль- ное позиционирование в обшекорпоративном контексте и ИТ-проек- тов, и, более широко, ИТ-службы. Главной составляющей этого контекста, по нашему мнению, явля- ется корпоративная стратегия, которая устанавливает основные при- оритеты компании в бизнесе и различных функциональных областях, в том числе в области ИТ. На основе этих приоритетов должны строиться стратегия ИТ-службы, ее цели, задачи и показатели деятельности. Стра- тегические установки определяют все существенные параметры функ- ционирования ИТ-службы. А достижение этих параметров возможно только при использовании адекватных форм управления ИТ. Таким образом, можно выделить три основных взаимосвязанных уровня функционирования ИТ-службы компании — уровень целепо- лагания, уровень исполнения и уровень управления (см. рис. 7.1). Рас- смотрим эти уровни подробнее. 225
226 Гпава 7 Корпоративная стратегия Уровень целеполагания Стратегия определяет параметры процессов Уровень исполнения Требования к процессам определяют способы управления Уровень управления Управление ИТ Стратегия ИТ-службы Рисунок 7.1. Уровни функционирования ИТ-службы Корпоративная стратегия и стратегия ИТ-службы Совокупность целей и задач ИТ-службы составляет функциональную стратегию компании в области ИТ, которая развивает и дополняет кор- поративную стратегию в части, касающейся ИТ. Таким образом, от- правной точкой для формализации деятельности ИТ-службы является корпоративная стратегия компании, в которой должны присутствовать цели, достижение которых возможно только (или преимущественно) с использованием ИТ. Именно это позволяет обоснованно формировать цели и задачи ИТ-службы, объемы ее работ и требования к результа- там. Примеры подобных целей рассмотрены в разделе 7.2 (см. табл. 7.4). Следующим шагом является построение функциональной страте- гии ИТ-службы, содержащей как цели, ориентированные на развитие бизнеса компании в целом, так и специфические цели развития ИТ. В этой стратегии должны быть отражены две формы деятельности ИТ-службы — проекты по развитию ИТ-инфраструктуры компании и процессы оказания ИТ-услуг внутренним клиентам. Проектная форма деятельности ИТ-службы, как правило, регламентируется стандартами в области разработки и внедрения информационных систем (ГОСТ 34
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 227 [1], ISO 15288 [2] и т. д.). Процессы оказания ИТ-услуг могут регули- роваться соглашениями о качестве предоставляемых услуг. Однако и в том и в другом случае цели и задачи ИТ-службы должны соответство- вать стратегии компании в области повышения ее организационного потенциала и финансовой эффективности. В общем виде обе эти формы деятельности описываются принципа- ми CobIT Framework [3] и связанными с ними процессами ITIL. В со- ответствии с ними формирование целей ИТ-службы определяется оцен- ками ее деятельности со стороны клиентов. Можно выделить три основные группы клиентов и соответству- ющие их интересам цели ИТ-службы (см. рис. 7.2): • Высшие менеджеры заинтересованы в повышении управляемос- ти предприятия. • Интерес менеджеров среднего звена связан с обеспеченностью предприятия эффективными и надежными инструментами, необ- ходимыми для решения бизнес-задач. • Наконец, все сотрудники предприятия заинтересованы в удов- летворительной работе ИТ. Цели и задачи в области развития ИТ должны соответствовать стратегии Внутренний клиент — высшие менеджеры предприятия Внутренний клиент — менеджеры среднего звена Внутренний клиент — персонал предприятия Рисунок 7.2. Цели верхнего уровня функциональной стратегии ИТ-службы
228 Глава 7 Стратегическая карта ИТ-службы Цели верхнего уровня (клиентские цели) детализируются по несколь- ким областям, в рамках которых осуществляются конкретные мероприя- тия по развитию ИТ и обслуживанию клиентов. Это, прежде всего, области, определяемые принципами CobIT Framework, — планирова- ние и организация ИТ, приобретение и внедрение ИТ, сопровождение и поддержка ИТ, мониторинг ИТ. Рассмотрим эти области более подробно и выделим те процессы, в которых применяются или могут применяться методы управления про- ектами. Планирование и организация ИТ (группа ПО) включает процессы определения стратегического плана развития ИТ, отвечающего биз- нес-требованиям и обеспечивающего оптимальный баланс функцио- нальных возможностей, качества и стоимости ИТ. Реализация страте- гических замыслов должна быть спланирована, согласована и поддер- жана соответствующей организационной и ИТ-инфраструктурой. Процессы группы ПО должны включаться в обще корпоративный контур стратегического управления в той его части, которая относится к стратегическому менеджменту проектов (в данном случае — ИТ-про- ектов). Необходимо отметить, что помимо объективных стратегиче- ских показателей при планировании и организации ИТ-проектов очень сильна политическая составляющая как следствие реакции отдельных влиятельных людей и группировок на предполагаемые результаты про- ектов, которые не соответствуют их личным целям. Проектирование и внедрение ИТ (группа ПВ) включает процессы идентификации, разработки и/или приобретения ИТ-решений, пред- лагающих эффективные методы удовлетворения требований клиентов. ИТ-решения должны быть внедрены и интегрированы в бизнес-про- цессы. Соответствующая деятельность реализуется в форме традиционных проектов, в которых ИТ-служба играет роль заказчика и координатора проекта. Эксплуатация и сопровождение ИТ (группа ЭС) включает процессы обработки данных прикладными системами, предоставление требуе- мых информационных сервисов, обеспечение безопасности и непре- рывности бизнеса, обучение и техническую поддержку. Мониторинг ИТ (группа М) включает процессы надзора на регуляр- ной основе за процессами управления ИТ, а также независимый конт- роль со стороны внутренних и внешних аудиторов. Цели, направленные на улучшение основных процессов деятельно- сти ИТ-службы, дополняются целями, связанными с достижением по- зитивных изменений в деловых и личных качествах, компетентности, квалификации, заинтересованности сотрудников этого подразделения.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 229 В таблице 7.1 приведен возможный вариант стратегической карты ИТ-службы, в которой для каждой цели дана ссылка на соответству- ющую ей группу процессов СоЫТ (в скобках). Ключевые показатели деятельности ИТ-службы На следующем этапе для каждой цели, включенной в стратегическую карту, разрабатываются один или несколько показателей, позволяющих оценить степень достижения соответствующей цели, а также совокуп- ность стратегических инициатив, позволяющих вывести значения этих показателей на запланированный уровень. При этом сами эти показатели часто становятся критериями оцен- ки качества оказания ИТ-услуг и входят в соглашения о качестве предо- ставляемых услуг. В то же время совокупность стратегических инициа- тив используется для формирования портфеля ИТ-проектов, а сбаланси- рованная система показателей — как система критериев, позволяющих оптимизировать этот портфель в первую очередь с точки зрения дости- жения стратегических целей организации. Приведем примеры некоторых важных показателей деятельности ИТ-службы, которые непосредственно относятся именно к реализа- ции ИТ-проектов. Как партнер по бизнесу ИТ-служба несет прямую ответственность за эффективность предлагаемых решений. Важнейшим итоговым фи- нансовым показателем здесь является возврат на инвестиции (ROI) в ИТ. Однако учитывая несовершенство методик расчета этого показа- теля в области ИТ, для оценки эффективности ИТ-решений целесооб- разно использовать и другие показатели. Обычно в качестве таких показателей выступают прямые или кос- венные показатели удовлетворенности клиентов. Например, это может быть количество (или доля) бизнес-процессов, производительность которых после автоматизации достигла запланированного уровня, или изменение количества «критических» инцидентов, связанных с ИТ, которые привели к невозможности принятия управленческих решений в обусловленные сроки. Наконец, существует группа показателей, характеризующих про- цессы реализации ИТ-проектов. Здесь можно выделить показатели качества и показатели результативности. Как пример показателя каче- ства реализации ИТ-проекта может выступать экспертная оценка соот- ветствия внедряемого ИТ-решения критериям выбора, учитывающая характеристики ИТ-решения, его производителя и процесса внедре- ния. К показателям результативности можно отнести отклонение от плановых сроков и стоимости внедрения ИТ-сервисов. В таблице 7.2 рассмотренные выше показатели связаны с целями, для измерения которых они могут быть использованы. Для сравнения
Таблица 7.1. Стратегическая карта ИТ-службы Финансы Обеспечить максимальную отдачу от вложений в ИТ (ПО5) Клиенты Повысить управляемость предприятия Обеспечить предприятие эффективными и надежными инструментами,необходимыми для решения бизнес-задач Обеспечить удовлетворенное гь персонала работой ИТ-службы С о ь 1 т Планирование и организация Оценивать и управлять ИТ-рисками (ПО9) Понимать и предвосхищать потребности клиентов (ПО1) Поддерживать партнерские отношения с клиентами (ПО4) Проектирование и внедрение Разработать и поддерживать систему регламентов и процедур (ПВ4) Разрабатывать и реализовывать эффективные ИТ-решения (ПВ1, ПВ2) Повысить эффективность ИТ-инфраструктуры (ПВЗ) Эксплуатация и сопровождение Обеспечить руководству непрерывный доступ к целостной, надежной, непротиворечивой, стратегической и оперативной информации, необходимой для принятия управленческих решений (ЭС4) * Повысить эффективность отношений с поставщиками ИТ-услуг (ЭС2, ЭСЗ) Обеспечить эффективное консультирование пользователей (ЭС7) Снизить время реагирования на запросы в ИТ-службу (ЭС7, ЭС9) Мониторинг Обеспечить непрерывный контроль качества ИТ-услуг (М1, М2, М3, М4) Люди Повысить проактивность персонала (ПО7) Повысить квалификацию ИТ-персонала (ПО7) Повысить мотивированность ИТ-персонала (ПО7) Примечание. Процессы СоЫТ: П04 — определить стратегический план ИТ; ПО5 — определить организацию и взаимоотношения ИТ; ПО7 — управлять инвестициями в ИТ; ПО9 — управлять персоналом; ПВ1 — оценивать риски; ПВ2 — определять решения по автоматизации; ПВЗ — приобретать и поддерживать прикладное программное обеспечение; ПВ4 — приобретать и поддерживать технологическую инфраструктуру; ЭС1 — разрабатывать и поддерживать процедуры; ЭС2 — управлять услугами сторонних организаций; ЭСЗ — управлять производительностью; ЭС4 — обеспечить непрерывность услуг; ЭС7 — обучать пользователей; ЭС9 — управлять конфигурацией; М1 — проводить мониторинг процессов; М2 — оценивать адекватность внутреннего контроля; М3 — получать независимые гарантии; М4 — обеспечивать независимый аудит. 230 Глава 7 Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов
232 Глава 7 Таблица 7.2. Ключевые показатели проектной деятельности ИТ-службы № Функциональные цели Показатели Комментарии 1 Обеспечить максимальную отдачу от вложений в ИТ-инфра- структуру ROI в ИТ 2 Повысить управляемость предприятия Индекс критических инцидентов Индекс показывает изменение количества инцидентов, связанных с ИТ, которые привели к невозможности принятия управленческих решений в обусловленные сроки 3 Обеспечить предприятие эффективными и надежными инструментами, необходимыми для решения бизнес-задач Процент автоматизи- рованных бизнес-процессов Под автоматизированными понимаются те процессы, производительность которых оценена руководителями бизнес-подразделений не ниже «удовлетворительно» 4 Выявлять и формализовать потребности клиентов Процент автоматизи- рованных бизнес-процессов Показатель оценивает уровень полезности ИТ-решений с точки зрения автоматизации стратегически важных процессов предприятия 5 Разрабатывать и реализовывать эффективные ИТ-решения Отклонение от плановых сроков внедрения ИТ-сервисов Оценивается фактическое исполнение работ по внедрению ИТ-сервисов по сравнению с плановыми заданиями Индекс адекватности ИТ-решения Оценивается соответствие внедряемого ИТ-решения критериям выбора, учитывающим характеристики ИТ-продукта, его производителя и процесса внедрения 6 Повысить эффективность отношений с поставщиками ИТ-услуг Коэффициент эффективности взаимодействия с поставщиками Коэффициент эффективности взаимодействия с поставщиками складывается из следующих компонентов: • времени оплаты счетов поставщиков; • количества поставщиков; • рейтинга поставщиков в таблице 7.3 приведены некоторые хорошо известные показатели, ис- пользуемые для оценки непроектной деятельности ИТ-службы по со- провождению, поддержке и мониторингу ИТ.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 233 Таблица 7.3. Ключевые показатели непроектной деятельности ИТ-службы № Функциональные цели Показатели Комментарии 1 Повысить эффективность ИТ- и нфрастру ктуры Доступность ИТ-сервисов Оценивается период времени, в течение которого ИТ-сервис доступен пользователям 2 Снизить время реагирования на запросы в ИТ-службу Время ответа на инцидент Оценивается время, требуемое ИТ-специалистам на распознавание и подтверждение инцидента Время разрешения инцидентов Оценивается время, требуемое ИТ-специалистам на выявление причины инцидента и устранение его последствий 3 Поддерживать партнерские отношения с клиентами Своевременность пересмотра Соглашения об уровне обслуживания Оценивается степень готовности ИТ-службы идти навстречу пожеланиям клиентов в части изменения сервисов и уровня их предоставления 4 Обеспечить непрерывный контроль качества ИТ-услуг Качество отчетности об анализе причин инцидентов Оценивается удовлетворенность клиентов представляемыми им отчетами по причинам инцидентов 5 Обеспечить эффективное консультирование пользователей Качество отчетности об уровне обслуживания Оценивается удовлетворенность клиентов представляемыми им отчетами об уровне обслуживания А кому сейчас легко? При организации управления ИТ одним из важнейших вопросов се- годня является так называемый риск аутсорсинга в ИТ-проектах [7]. Проблема заключается в том, чтобы определиться, что же все-таки должна делать ИТ-служба и сколько она должна стоить своей компа- нии. Этот вопрос носит достаточно острый характер не только для руководства компании, но и для сотрудников ИТ-службы. Для них, собственно, это вопрос «жизни и смерти». К сожалению, золотое время нашего брата информационщика без- возвратно ушло. Пока от нас ждали чуда в виде небывалых прибылей (или хотя бы перевода бизнеса на более высокий уровень конкурентных преимуществ), денег не жалели. Чудеса закончились, и нам задали ба- нальный вопрос: «А где же прибыль от всех ваших нововведений?» Но мы (информационщики), развращенные собственными бесконечными обещаниями, подогретые собственным интересом к процессу ради про- цесса, сами поверившие в собственное волшебство, не смогли вовремя дать на этот вопрос адекватный или хотя бы просто внятный ответ.
234 Глава 7 Можно, конечно, ссылаться на стагнацию мировой экономики, на падение всяческих индексов, на некомпетентность заказчика или ру- ководства предприятия, но, если честно, у нас тоже рыльце в пушку: как говорится, что посеешь... На наш взгляд, процессы сокращения штата собственных програм- мистов и привлечения внешних разработчиков совершенно естествен- ны как с точки зрения текущей ситуации в экономике, приведшей к сокращению средств на создание информационных систем предприя- тий, так и с точки зрения тенденций развития отрасли ИТ. Попыта- емся прояснить последний тезис. 1. Один из главных аргументов разработчиков на предприятии: «Мы лучше знаем наше предприятие, поэтому быстрее и каче- ственнее решим задачу. Все сделаем сами». Да, но почему вас так много? И зачем программисту детально знать бизнес пред- приятия? На рынке достаточно консалтинговых компаний, специализи- рующихся в конкретных отраслях бизнеса. Они являются носи- телями передового опыта и в сочетании с ИТ-специалистами заказчика (действительно знающими процессы своего предприя- тия лучше, чем кто-либо посторонний) создают решения быст- рее и качественнее. 2. Но ИТ-службы с неизбежностью воспроизводят внутри своей организации поведение монополиста на рынке: начинают дик- товать правила игры на всех уровнях и не допускают конкурен- ции с внешними разработчиками. Мы наблюдали ситуацию, когда все громадье планов ИТ-службы на одном из крупнейших рос- сийских предприятий сводилось к бесконечному улучшению интерфейсов пользователей и совершенствованию функцио- нальных характеристик эксплуатируемых задач. Даже при жест- ком контроле со стороны руководства предприятия грамотный ИТ-директор докажет свою правоту и необходимость финанси- рования подобных задач. Поставьте ИТ-службу в конкурентную позицию по отношению к внешним разработчикам — и вы получите объективную кар- тину состояния и перспектив развития информационной систе- мы предприятия, а также узнаете... 3. ...сколько на самом деле стоит информационная система ваше- го предприятия. Если система создается собственными силами, то стоимость ее определяется (не считая стоимости приобретае- мого софта и оборудования) количеством штата разработчиков. А какой штат нужен? Побольше, конечно...
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 235 Если же обратиться к рынку, привлечь внешних разработчиков, то стоимость информационной системы приобретет более объек- тивные очертания. Современный взгляд на управление информационной системой пред- приятия предполагает наличие небольшой ИТ-службы, главной функ- цией которой является вовсе не решение сервисных задач, хотя ответ- ственность за разработку решений и эксплуатацию информационных систем по-прежнему лежит на ней. Основной ответственностью ИТ-под- разделения должны быть обеспечение организационно-структурного и информационно-технологического развития в соответствии с бизнес-це - лями и задачами предприятия, формирование планов этого развития и координация ИТ-нроектов. Мы понимаем, что в наших объяснениях мало утешения для тех, кто лишился работы. Но той ИТ-службы, к которой эти люди привык- ли, уже не вернуть, и хочешь не хочешь, а придется приспосабливаться к новой службе, более ответственной, более интересной, но, безуслов- но, и намного более сложной. Но кому сейчас легко?.. 7.2. Политика в проектах внедрения корпоративных информационных систем Политические риски проектов внедрения корпоративных информационных систем В подавляющем большинстве случаев внедрение корпоративной ин- формационной системы (КИС) приводит к значительному изменению политического ландшафта компании, нарушает сложившийся баланс интересов различных функциональных подразделений. Как мы уже отмечали выше, попытка изменения этого баланса в ту или иную сто- рону в приказном порядке, как правило, к успеху не приводит. Роль и место ИТ-службы в этом процессе можно охарактеризовать очень крат- ко: максимум ответственности за результат при минимуме рычагов влияния. Даже имея в своем активе утвержденную и принятую к исполне- нию ИТ-стратегию, директор информационной службы (СЮ) не мо- жет быть уверенным в том, что она будет реализована в полном объеме или хотя бы частично. Тот факт, что в какой-то момент СЮ удалось доказать необходимость преобразований в ИТ-сфере и «протолкнуть» ИТ-стратегию, вовсе не означает, что дальше все пойдет как по маслу. На самом деле, скорее всего, все будет наоборот, и ИТ-службе при- дется преодолевать несколько рубежей активного и пассивного сопро- тивления.
236 Глава 7 «Мы не можем сделать это, потому что... это слишком дорого, это не понравится начальству, юристы не разрешат, это не запланировано в бюджете, сомневаемся, что это будет работать, поставщик запросит слишком много за изменение кода, отдел маркетинга заберет это у нас в случае успеха, женщина, защищающая эту идею, просто пожиратель- ница кредитов, ИТ не должны проявлять такую инициативу, это от- влекает нас от основной миссии и т. д.». Список возражений легко продолжит каждый ИТ-директор [10]. Можно выделить четыре основных очага сопротивления внедре- нию ИТ, отличающихся как мотивами, так и формами противодей- ствия (см. рис. 7.3): • операционный персонал; • менеджеры среднего звена; • высшие менеджеры; • генеральный директор. Чтобы повысить свои шансы на успех в этой борьбе и вместе с тем избежать открытой конфронтации с недоброжелателями, СЮ должен заранее позаботиться о том, чтобы во всех случаях неопределенности и несогласованности выбора возможных вариантов развития событий действовали механизмы сглаживания возникающих возмущений. А это означает, что СЮ должен хорошо представлять себе, какие политиче- ские риски возникают при внедрении КИС, каковы их мотивы и источ- ники, в чем состоят стратегии по устранению этих рисков и, наконец, каковы механизмы реализации таких стратегий. Вовлечение, убеждение, принуждение... Методы преодоления сопротивления персонала и мотивирования ме- неджмента к активному участию в процессе изменений достаточно хорошо известны. Можно выделить три основные политические стра- тегии, которые СЮ может использовать при внедрении КИС: • Вовлечение — создание условий, при которых противники изме- нений становятся лично заинтересованными в их успехе. • Убеждение — создание условий, при которых противникам из- менений становится очевидна их необходимость. • Принуждение — создание условий, при которых противники изменений вынуждены проводить их в жизнь, в том числе под угрозой административных санкций.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 237 Рисунок 7.3. Барьеры на пути внедрения КИС
238 Глава 7 Наверное, СЮ, который должен быть опытным политиком уже по сути своей должности, может справиться с этими задачами. Но вопрос состоит в том, как ему избежать ненужной траты сил и нервов, не создавая многоходовых интриг для достижения своих профессиональ- ных целей. Решение мы видим в том, что вовлекать, убеждать и при- нуждать будут не СЮ и не какие-либо другие влиятельные фигуры компании, а формальные показатели, включенные в общую систему целеполагания компании. Задача СЮ в этом случае сведется к тому, чтобы определить основные риски «человеческого фактора» и предло- жить правильные показатели, оперирование которыми позволит демп- фировать эти риски. Пример 1. Успех внедрения модуля «Главная книга» на одном из газпромовских предприя- тий обусловлен автоматизацией операций в том виде, как их привыкли осуществ- лять сотрудники бухгалтерии. Каждый бухгалтер отвечал за свой счет (группу счетов): получал первичный документ (накладную, счет), делал проводку по своему счету и передавал этот документ следующему бухгалтеру. Понятно, что современные ERP-системы поз- воляют поручить все эти операции одному бухгалтеру. После введения документа все проводки делаются автоматически. Но фирма, занимавшаяся внедрением информационной системы в бухгалтерии, специально предложила руководству оставить всех бухгалтеров на своих местах и ничего не менять в их привычной деятельности. Все стали работать с энтузиазмом: повысился социальный статус сотрудников (они теперь не просто бухгалтеры, а пользователи системы управле- ния ресурсами предприятия). Пример 2. В то же самое время на том же газпромовском предприятии попытались автома- тизировать расчеты с кредиторами. До этого дня бухгалтер брал полученную за месяц пачку счетов-фактур, сор- тировал их по поставщикам и, посчитав для каждого общую сумму, проводил пла- теж одной общей проводкой. В итоге терялась всякая связь с первичными до- кументами и никакой анализ был невозможен. ERP-системы требуют введения в базу данных каждого первичного документа. Но бухгалтер резонно ответил: «Дай- те мне еще 10 человек, и они будут делать эту работу». Естественно, команда внедренцев не могла пойти на это. Не могли они и автоматизировать процесс «как есть», так как вводимая информация не позволяла осуществлять корректный учет и анализ, т. е. не решала задач, которые ставили перед КИС спонсоры ее внедрения на предприятии. Мудрые консультанты порекомендовали: «В запад- ных компаниях ввод первичных документов в информационную систему осущест- вляется на „месте возникновения" — если сотрудник отдела снабжения заказы- вает какую-либо продукцию у поставщиков, именно он должен ввести в систему Договор, затем проследить, чтобы приходная накладная, выписанная на складе, шла под тем же номером, что и Договор, и т. д.» Консультанты предложили, чтобы счета-фактуры вводили в систему сотрудники отдела снабжения. Но там им ответили: «Этим всю жизнь занималась бухгалте- рия, пусть и продолжает это делать. Мы этого делать не будем». Тогда консуль- танты предприняли отчаянную попытку все же заставить «правильно» работать с информацией о поставщиках и порекомендовали создать отдельное подразделе-
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 239 ние по работе со всеми поставщиками, собрав в нем всех людей, которые так или иначе связаны с внешними поставщиками товаров и услуг для предприятия. Эта акция окончилась полным провалом, так как столь серьезная реструктуризация вела к нарушению сложившегося баланса сил и интересов на предприятии. Рядовые исполнители не захотели перестраиваться. Начальники отделов, почувствовав угрозу лично для себя, не стали заставлять своих сотрудников ра- ботать по-новому, хотя и имели для этого достаточно власти. А у высшего руко- водства предприятия не хватило «политической воли» для преодоления сопро- тивления «среднего звена управления». Пример 3. В ходе консультирования СЮ одного крупного холдинга, управлявшего несколькими алюминиевыми заводами, мы столкнулись с весьма любопытным феноменом. Порядок финансирования инвестиционных проектов в холдинге предполагал обоснование таких проектов с точки зрения как выгод, которые ожидаются в ре- зультате их реализации, так и необходимых затрат. Эти стандартные, в общем, требования были детально прописаны в Положении об Инвестиционном комитете холдинга. СЮ рассказывал: «Для одного из наших заводов мы утвердили проект по реализации системы информационной безопасности, обосновав его выгодами снижения рисков разрушения информационной системы предприятия и утечки коммерческой информации. Однако в приоритеты Генерального директора заво- да выполнение этого проекта не входило: хотя деньги были выделены и реализа- ция системы безопасности стояла в плане работ завода, проект не был запущен. К чему это привело? Руководство предприятия получило премию за экономию средств». Анализ этой курьезной ситуации показал, что, несмотря на тщательно пропи- санные инвестиционные процедуры, в Положении об Инвестиционном комитете забыли определить ответственность за неисполнение инвестиционного плана. Это и определило соответствующее отношение руководства завода к исполнению запланированных работ по реализации системы информационной безопасности. Рубежи сопротивления Уровень операционного персонала То, что происходит с операционным персоналом при попытке внедре- ния КИС, можно обозначить как риск сопротивления изменениям. Это сопротивление порождается естественным стремлением сохранить привычную среду и инструменты. Причинами этого могут быть как опасения потерять работу из-за сокращения количества рабочих мест и недостаточной собственной квалификации, так и искреннее непони- мание целесообразности предлагаемых изменений. Влиять на эту ситу- ацию можно, используя самые разные рычаги — и убеждение, и вовле- чение, и принуждение. В части убеждения основным рычагом, на наш взгляд, является переобучение персонала. Коэффициент переобучения может рассчи- тываться как индивидуально для каждого сотрудника, так и для под- разделения в целом (подробнее об этом показателе см. [11]).
240 Глава 7 [Коэффициент массового переобучения] = 100% х [Время, затраченное на переобучение] / [Время, необходимое для переобучения в запланированном объеме] Одним из традиционных показателей степени вовлеченности операцион- ного персонала в проект внедрения КИС является количество выдвину- тых (принятых) предложений по совершенствованию различных аспектов внедряемой КИС. Чтобы такие предложения могли появиться, ИТ-служба должна организовать активную работу с будущими пользователями на различ- ных прототипах и макетах системы. И наконец, необходимо сформировать такую атмосферу, которая создает у сотрудников ощущение того, что «отсидеться» не удастся. Для этого должен быть придуман показатель, улучшение которого воз- можно только при использовании внедряемых ИТ, например сокра- щение времени выполнения некоторых технологических операций (см. пример ниже). Пример. Ежеквартальное сокращение в два раза количества заказов, время оформления которых по показателям системы качества является неудовлетвори- тельным, т. е. ниже 4 баллов. Оценки времени оформления заказа должны быть приведены в документа- ции системы качества компании, фрагмент которой приведен на рисунке. Если системы качества не существует, то таблица должна быть разработана специаль- но для этого показателя. Важно выстроить систему оценок таким образом, чтобы максимально возможная оценка для текущего состояния (без ИТ) была на уровне 2-3 баллов. Оценка времени оформления заказа 5 Интернет, e-mail 4 До 1 часа 3 1 -2 часа 2 2-4 часа 1 Более 4 часов Уровень руководителей среднего звена На этом уровне основной причиной сопротивления является стремле- ние избежать прозрачности бизнес-процессов и обобществления ин- формации, поскольку руководители среднего звена опасаются потерять собственную значимость в компании в результате внедрения ИТ. Важным фактором отечественной управленческой культуры явля- ется то, что руководитель среднего звена, как правило, выстраивает свой бизнес внутри организации, тщательно оберегает его, не допуская
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 241 постороннего вмешательства. Основным его клиентом выступает выс- ший менеджер, курирующий этот бизнес. Соответственно, важным показателем, определяющим значимость менеджера среднего звена, можно считать количество хождений к начальству с «интересной» ин- формацией. Этот показатель резко упадет, если вышестоящий началь- ник будет получать информацию «естественным путем» — через инфор- мационную систему. Основным средством давления на руководителей среднего звена являются показатели в области себестоимости, производительности труда, эффективности сотрудников. [Доход на сотрудника] — доход компании, обеспеченный бизнес-единицей, отнесенный к штатной численности этой бизнес-единицы. [Использование рабочего времени операционного персонала] — доля затраченного сотрудниками рабочего времени в общем фонде рабочего времени. Покажем, как эти показатели могут ограничить возможности мене- джеров среднего звена по противодействию внедрению ИТ. Основное возражение на этом уровне против внедрения ИТ — «мы и так справ- ляемся». На самом деле за этим «справляемся» часто стоят манипуля- ции с численностью персонала подразделения. Два основных приема — набрать больше людей или увеличить нагрузку на сотрудников. В первом случае падает рентабельность подразделения, поскольку дополнительные сотрудники не приносят дополнительного дохода. Регулирование этой ситуации осуществляется показателем Доход на со- трудника, который ограничивает возможности руководителя «сверху», — нельзя бесконтрольно набирать людей в штат. Во втором случае падает качество обслуживания клиентов (напри- мер, возрастает количество ошибок в периоды пиковых нагрузок). Ре- гулирование этой ситуации осуществляется показателем Использование рабочего времени операционного персонала, который ограничивает возмож- ности руководителя «снизу», — нельзя чрезмерно перегружать персо- нал. Отметим, что использование этого показателя может быть гораздо более разнообразным [12]. Таким образом, вместе целевые значения этих показателей опреде- ляют диапазон обоснованной численности подразделений (см. рис. 7.4). Важная область контроля деятельности руководителей среднего зве- на — доступность общекорпоративного знания и информации, необ- ходимой высшим менеджерам для оперативного принятия решений и смежным подразделениям для выполнения собственной работы. Здесь
242 Глава 7 Штатная численность персонала [Доход на сотрудника] — ограничивает возможности руководителя «сверху» — нельзя бесконтрольно набирать людей в штат [Использование рабочего времени персонала]— ограничивает возможности руководителя «снизу» — нельзя чрезмерно перегружать персонал о 5 Рисунок 7.4. Использование показателей для определения диапазона обоснованной численности персонала целевое значение показателя доступности информации может вы- ставляться с применением «принципа половины» — значение показа- теля должно уменьшаться в два раза по отношению к предыдущему периоду. [Индекс доступности информации] = [Количество часов рабочего времени, необходимое для получения требуемой информации] Уровень высших менеджеров Сопротивление на этом уровне возникает как следствие того, что вне- дрение ИТ оказывает влияние на бизнес компании и может привести к нарушению сложившегося баланса интересов и влияний высших ме- неджеров. Возможности воздействия на этих людей крайне ограничен- ны, но их можно попробовать убедить в том, что, сохраняя за собой контроль над процессом, не автоматизируя его, они теряют больше, чем отдавая его «на автоматизацию» и теряя контроль над ним. Для убеждения топ-менеджеров должны использоваться показатели, характеризующие качество исполнения бизнес-процессов, — время, стоимость, количество сбоев и т. д. При этом необходимо апеллировать к наиболее критичным процессам, подлежащим автоматизации, с по- казателями, например, Время оформления договораили Количество кли- ентов, потерянных из-за несогласованных действий подразделений.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 243 Уровень генерального директора На этом уровне основным риском является отсутствие политической воли. Характерный пример: решение принято, но под воздействием обстоятельств (давление «снизу») первое лицо компании перестает на- стаивать на неукоснительном следовании принятой стратегии. Компенсировать это давление «снизу» можно только адекватным давлением «сверху», т. е. требованиями владельцев выполнять план по инвестициям и использованием соответствующего показателя — Вы- полнение плана по инвестициям в развитие ИТ. Как это будет работать Необходимым условием того, чтобы показатели начали работать, яв- ляется использование их в качестве принципиальной основы для при- нятия управленческих решений в компании. Проиллюстрируем, как это происходит на примере применения методологии BSC. В табли- це 7.4 приведен фрагмент стратегической карты, построенный с ис- пользованием некоторых из упомянутых выше показателей. В таблице определены пять функциональных целей, относящихся к различным категориям, — финансы, клиенты, бизнес-процессы, обуче- ние и развитие. Формулировки этих целей вполне традиционны. Важ- Таблица 7.4. ИТ в стратегической карте компании Категория цели Цель Показатель Финансовая цель Повысить производительность труда 0 Доход на сотрудника Клиентская цель LJ Улучшить качество обслуживания клиентов Время оформления заказов Внутренние производственные цели Повысить согласованность работы подразделений *1 с Количество клиентов, потерянных из-за несогласованных действий персонала Цели обучения и развития U Повысить компьютерную грамотность персонала Коэффициент массового переобучения Автоматизировать наиболе критичные бизнес-процесс е ы Выполнение плана по инвестициям в ИТ
244 Глава 7 но то, что их достижение невозможно без осуществления целей ниж- него уровня, которые являются единственными напрямую связанны- ми с ИТ. Если соответствующие этим целям показатели регулярно появляются на столе у топ-менеджеров, если система мотивации всех сотрудников компании сверху донизу завязана на них, то шансы про- екта внедрения КИС на успех существенно повышаются. Программа действий для СЮ В качестве резюме раздела сформулируем краткую программу действий для СЮ. Шаг 1. Сформулировать и утвердить ИТ-стратегию как часть биз- нес-стратегии компании. Шаг 2. Определить конкретные бизнес-цели, достижение которых воз- можно только с использованием ИТ. Шаг 3. Определить реальные центры сопротивления внедрению КИС и вскрыть их мотивацию. Шаг 4. Построить систему показателей, мотивирующих центры сопро- тивления к достижению целей.. Шаг 5. Включить отчетность по этим показателям в общую обязатель- ную отчетность компании. 7.3. ИТ-проекты и персонал компании Человек или ресурс? При обсуждении вопроса об участии и роли конкретного человека в проекте очень часто приходится слышать словосочетание «человече- ский ресурс» (Human Resource, HR), употребляемое обычно в одном ряду с понятиями «финансовый ресурс», «материальный ресурс» и т. п. В этих случаях под «человеческим ресурсом» понимается то, что выра- жается в часах и стоимости. Такой ресурс складывается и вычитается, привлекается или освобождается. И все, казалось бы, просто: умножай трудозатраты на стоимость человеко-часа и смотри, чтобы не выйти за рамки бюджета. Но именно такой подход нередко оказывается при- чиной тех самых политических проблем, которые были рассмотрены в предыдущем разделе. Действительно, очень соблазнительно видеть в исполнителе только ресурс — и для руководителя, и часто для самого исполнителя. Каждая сторона может облегчить себе жизнь, не вникая в проблемы стороны
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 245 противоположной. Однако в проектах, в которых человеческий фактор имеет решающее значение, ориентация только на управление «трудо- выми ресурсами» и «штатом» без учета организационной и профессио- нальной культур, индивидуальных особенностей членов команд и дру- гих, плохо идентифицируемых и измеряемых характеристик команд часто приводит к конфликтам, трудностям на «ровном месте» и про- валу всего проекта. В работе [13] мы отмечали, что гармоничное соединение «ресурс- ной» составляющей человека с его личными интересами и мотива- цией, интересами команды и других участников проекта, организация совместной работы на основе командной управленческой культуры являются основой эффективной работы и одним из основных факто- ров успеха. Указывали мы также и на то, что при всем многообразии подходов к управлению людьми в проектах и на предприятии суще- ствует критически важный аспект «человеческого фактора». Речь идет о мотивации и системе мотивации, основой которых являются учет ресурсов проекта, а целью — создание стимулов к эффективной работе не только персонала, но и других участников проекта. Для проектов внедрения информационных систем все сказанное выше можно отнести не только к исполнителям, но, может быть, даже в большей степени и к функциональным заказчикам, т. е. к будущим пользователям системы. Поэтому и успех подобных проектов в значи- тельной степени определяется тем, насколько успешно решены в ком- пании кадровые вопросы. И здесь правильнее говорить уже не только об управлении персоналом в проекте, но и об управлении персоналом на предприятии. Кадровые вопросы в стратегии компании Стратегия компании должна давать ответы на три основных вопроса, связанных с управлением персоналом: • Чего компания ждет от своих сотрудников? • По каким критериям руководство будет оценивать работу со- трудников? • Что компания должна сделать, чтобы помочь сотрудникам вы- полнять возложенные на них задачи? Чего мы ждем от своих сотрудников На рисунке 7.5 представлены основные уровни стратегического управ- ления компанией. Стратегическая карта на каждом из этих уровней содержит цели, которые ориентированы на развитие бизнеса компа- нии и адресованы конкретным сотрудникам. В карте корпоративного
246 Глава 7 Корпоративная стратегия — подходы и направления, разрабатываемые руководством компании с целью достижения наилучших результатов в бизнесе Функциональные стратегии — управленческие планы действий по отдельным ключевым направлениям Операционные стратегии — инициативы и подходы в руководстве подразделениями при решении оперативных задач, имеющих стратегическое значение Рисунок 7.5. Уровни стратегического управления компанией уровня — это топ-менеджеры компании, в функциональных страте- гиях — это менеджеры среднего звена, в операционных стратегиях — это могут быть рядовые сотрудники. Собственно, именно эта система целей и дает ответ на первый из поставленных выше вопросов (при- меры целей ИТ-службы были приведены в таблице 7.1). Как оценивать работу сотрудников Наличие правильной стратегии и правильной системы целей является необходимым, но не единственным инструментом эффективной рабо- ты компании. Второй важнейший инструмент стратегического управ- ления — система критериев, позволяющих вовремя и правильно оце- нивать различные стороны работы компании, ее подразделений и со- трудников и на основании этих оценок принимать и своевременно реализовывать правильные управленческие решения. В качестве таких критериев рассматриваются ключевые показатели деятельности (КПД) — количественные индикаторы, позволяющие измерять степень дости- жения успеха в конкретных областях деятельности компании (см. раз- дел 2.1). Примеры показателей работы ИТ-службы приведены в табли- цах 7.2 и 7.3. КПД могут использоваться и в качестве критериев оценки работы сотрудников, хотя на самом деле задача эта не столь простая, посколь- ку кроме объективных финансовых и производственных показателей
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 247 есть еще множество субъективных факторов, таких как отношение к работе, удовлетворенность руководства или клиента и т.д. Они также должны учитываться при оценке работы сотрудника. Как помочь сотрудникам выполнять возложенные на них задачи На различных уровнях стратегии должны быть представлены цели в области собственно управления персоналом, поскольку, как мы уже отмечали ранее, эта область является ключевой с точки зрения дости- жения бизнес-целей компании. В стратегической карте корпоративно- го уровня цели в области персонала формулируются обычно в весьма общем виде и относятся к компетентности персонала, корпоративной культуре, лояльности персонала и т. д. Как и производственные цели, они могут быть детализированы на уровне отдельных направлений дея- тельности (производство, финансы, строительство ит. д.) и даже на уровне отдельных подразделений. Главная роль в реализации стратегии компании в области персона- ла принадлежит службе управления персоналом. Стратегическая карта этого подразделения, как правило, включает специфические цели раз- вития HR-технологий, но основным ее содержанием являются цели, ориентированные на развитие бизнеса компании в целом, в частности на поддержку реализации ИТ-проектов. Рассмотрим задачи управле- ния персоналом в процессе внедрения новых информационных систем подробнее. Управление персоналом в переходный период, связанный с внедрением информационных технологий Оценка персонала Перед началом проекта должны быть сформулированы ключевые тре- бования к сотрудникам с точки зрения использования новых техноло- гий и, возможно, работы в новой организационной структуре. Далее необходимо определить степень готовности персонала компании к ра- боте в новых условиях, зоны и методы развития необходимых ком- петенций. Важнейший элемент оценки персонала — это выявление по- тенциальных лидеров/агентов изменений и кандидатов в состав проект- ной группы. Компенсация и мотивация Важной особенностью переходного периода является необходимость работы большой группы сотрудников в условиях изменившихся, но еще не устоявшихся правил и требований. Это неизбежно ведет к фи-
248 Глава 7 зическим и психологическим перегрузкам у этих сотрудников, особен- но при возникновении сложных и тем более форс-мажорных обстоя- тельств при исполнении бизнес-процессов с использованием новых средств ИТ. Необходимо учитывать также, что наряду с новыми обязанностя- ми, связанными с реализацией принятых изменений, эти сотрудники, как правило, продолжают исполнять и свои обычные функциональные обязанности. Чтобы обеспечить успешность переходных процессов, необходимо предусмотреть меры, повышающие заинтересованность сотрудников как в участии в ИТ-проектах, так и в их успешном завершении. Заинтересованность сотрудников в участии в проектах можно по- высить, предусмотрев целевой премиальный фонд, выплаты из кото- рого осуществляются только непосредственным участникам проектов пропорционально их вкладу и независимо от их текущей производ- ственной деятельности. Заинтересованность сотрудников в успешном завершении проек- тов можно повысить, кроме того, связав напрямую успех проекта с их карьерным ростом. Иными словами, ключевые роли в этих проектах должны отдаваться сотрудникам, которых руководство компании счи- тает кадровым резервом. Психологическое сопровождение проектов В рамках этого направления осуществляется мониторинг обществен- ного мнения в компании относительно возможных результатов проек- тов, выявляется готовность сотрудников к изменениям и формируется конструктивное отношение сотрудников к изменениям. И все-таки какой бы существенной ни была роль HR-технологий, решающее значение при реализации ИТ-проектов имеют компетент- ность и профессионализм ИТ-специалистов компании, эффективность используемых ими инструментов управления проектами. Некоторые из этих инструментов будут рассмотрены далее в данной главе. 7.4. ИТ-проекты в портфелях и программах Много раз в самых различных компаниях (но чаще всего — в государ- ственном секторе) нам приходилось сталкиваться с ситуацией, когда все проекты развития рассматриваются исключительно в качестве цент- ров затрат, относимых на бюджет подразделения, которое реализует этот проект. При этом расходы на проекты, выполняемые в интересах одного функционального заказчика, оказываются разнесенными по бюджетам различных подразделений. Это означает, что все ИТ-проек- ты ложатся на бюджет расходов ИТ-службы, все расходы на строитель- ство — на бюджет расходов строительного управления и т. д.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 249 Вследствие этого возникают проблемы с финансовой прозрачностью предприятия, с определением того, сколько «стоит» ему каждое от- дельно взятое подразделение. А это, в свою очередь, не позволяет оце- нить эффективность работы подразделений, сравнивать их работу с лучшими отраслевыми практиками. Принципиальное решение указанных проблем возможно на основе следующей модели: • Каждое подразделение имеет бюджет расходов и бюджет до- ходов. • Бюджет расходов — это консолидированный бюджет проектов, в которых подразделение выступает как Функциональный за- казчик 1 проектов. • Бюджет доходов — это консолидированный бюджет проектов, в которых подразделение выступает как представитель Генераль- ного заказчика или внутренний Исполнитель проектов плюс операционный бюджет подразделения (на непроектную деятель- ность). В этом случае появляется возможность учитывать не только средства, затрачиваемые на оборудование, материалы и оплату работы сторон- них организаций, привлекаемых в качестве подрядчиков, но и факти- ческие затраты собственных специалистов, участвующих в проекте и со стороны Функционального заказчика, и со стороны представителя Генерального заказчика. Такой подход приводит нас к модели разделения проектов на про- граммы и портфели, которая уже обсуждалась в разделе 2.4 примени- тельно к портфелям проектов газотранспортного предприятия. Про- иллюстрируем теперь эту модель на примере ИТ-проектов. Начнем с цитаты: «Опыт показывает, что приоритетные задачи ИТ-отдела (напри- мер, модернизация оборудования, обновление программного обеспече- ния и т. д.) часто никак не связаны со стратегией развития бизнеса компании. Сотрудники ИТ-отдела не имеют представления о том, каким образом их работа может послужить интересам компании, а сотрудники других подразделений недоумевают, почему ресурсы, вы- деляемые на ИТ, нельзя перебросить на более важные задачи» /15, с. 26]. 1 Напомним, что термины «Функциональный заказчик», «Генеральный заказчик», «Исполнитель» были введены в разделе 2.5.
250 Глава 7 Отсюда следует, что кроме традиционного объединения ИТ-проектов по формальному принципу в портфели приложений необходимо вы- страивать еще и содержательные взаимосвязи. Рассмотрим в качестве примера следующую ситуацию. В компании реализуются две программы развития — в сфере финансов и в сфере отношений с клиентами. В рамках первой программы осуществляется внедрение автоматизированной системы бухгалтерского учета, в рам- ках второй — CRM-системы. Вместе эти системы составляют порт- фель приложений. При этом они входят в состав разных программ. Пересечение портфелей проектов и программ и порождает те взаи- мосвязи, которыми необходимо управлять в процессе реализации ИТ-проектов. Взаимосвязи в рамках портфелей проектов носят часто сугубо ма- териальный характер и касаются ресурсных ограничений компании. Отличительной же особенностью программ является то, что в ходе их реализации затрагиваются жизненно важные интересы различных под- разделений компании и ее отдельных сотрудников. Поэтому и взаи- мосвязи здесь совсем иные: управление программами в значительной степени направлено на достижение баланса интересов различных участ- ников. Данная ситуация самым непосредственным образом влияет на спо- собы координации различных работ. Прежде всего работы координи- руются «по вертикали» — в рамках различных программ. Для этого обычно выстраивается вертикаль управления, главенствующее поло- жение в которой занимают бизнес-заказчики программы, например финансовый директор компании, а специалистам ИТ-службы отво- дится подчиненная роль руководителя ИТ-проекта. Именно в рамках этих структур и достигается взаимодействие на регулярной основе пред- ставителей различных бизнес-групп и исполнителей. Координация работ «по горизонтали» — в рамках портфеля прило- жений — это прямая служебная обязанность СЮ. В этом смысле он является полновластным хозяином портфеля ИТ-проектов (или цент- ром ответственности), разумеется, в рамках своих полномочий в части распоряжения ресурсами. В заключение раздела отметим, что для определенной категории ИТ-проектов ИТ-служба вообще не должна играть никакой руководя- щей роли. Речь идет о проектах внедрения отраслевых и корпоратив- ных информационных систем (КИС), уже обсуждавшихся в этой гла- ве. Внедрение таких систем неизбежно нарушает сложившийся баланс интересов различных сторон в компании, внедряющей систему, и в силу этого требует применения специальных методов управления. Функция руководства созданием (внедрением) КИС не может быть делегирована какому-либо одному подразделению, в том числе и
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 251 ИТ-службе. Ее роль должна состоять, прежде всего, в обшей организа- ции и координации процесса, согласовании интересов различных функ- циональных заказчиков, экспертизе технических решений и приемке результатов, но не в руководстве проектом (см. рис. 7.6) (13, 17]. А для управления проектом должны создаваться временные (как правило, многоуровневые) организационные структуры, в состав которых вклю- чаются представители всех заинтересованных сторон. И совершенно особые обстоятельства возникают при внедрении ИТ в холдинговых структурах. Они очень точно описаны М. Аишиной: «Представьте, что вы дирижер и вам надо управлять оркестром. Вы входите в оркестровую яму, встаете за пульт и видите, что вокруг вас не музыканты, а дирижеры и у каждого из них — свой оркестр. Кто-то смотрит на вас вопросительно, кто-то — иронически, а кто-то уже вовсю дирижирует, не обращая на вас никакого внима- ния. Ужасно, не правда ли ? Примерно в таких удручающих условиях вынуждены „играть му- зыку информационных технологий “ ИТ-сотрудники компаний со слож- ной структурой. Холдингов в России становится все больше, а дела у их ИТ-подразделений идут по-разному — и далеко не всегда столь бодро, как хотелось бы. На это накладывается бурное развитие самих технологий. Как обращаться с подобным ИТ-хозяйством ? Обычно холдинг представляет собой объединение различных направ- лений деятельности компаний, относящихся к одной или нескольким областям бизнеса. Компании, как сиамские близнецы, могут срастаться разными „частями тел“: • финансовым управлением; • работой с клиентами; • внешним представлением — имиджем; • ИТ и т. д. Управление ИТ в подобной структуре — как и управление вообще — представляет собой скорее искусство, чем науку. И это искусство осложнено не только тем, что люди, которыми управляют, сами управ- ляют другими людьми (иерархическая структура — вещь уже привыч- ная). Проблема состоит в том, что для лучшей управляемости надо быть ближе к инфраструктуре, к пользователям. Ситуацию ослож- няет и руководство компаний холдинга, которое, в свою очередь, хо- чет руководить ИТ-подразделениями. И это вовсе не местничество и не самодурство, а реальная необходимость сделать ИТ гибкими, за- ставить их поворачиваться вслед за бизнесом. Если управлять ИТ
252 Глава 7 Рисунок 7.6. Организационная схема проекта внедрения КИС
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 253 будут „где-то там“, то они определенно станут неповоротливыми, начнут препятствовать развитию компании» ]18, с. 88]. Рассмотрим некоторые рекомендации по организации в холдинге струк- туры, управляющей внедрением ИТ (назовем ее Департаментом ИТ). 7.5. Управление ИТ-проектами в холдинге: подходы и рекомендации Типы управления ИТ в холдинге Возможные типы структур управления ИТ в холдинге можно предста- вить следующим образом: жесткая централизация, децентрализован- ная структура и мягкая централизация. Их применение в значительной мере зависит от методов управления холдингом в целом. Если руководство холдинга последовательно придерживается поли- тики создания самостоятельных бизнес-единиц из своих дочерних пред- приятий, то, очевидно, говорить о жестко централизованной структуре управления как холдингом, так и ИТ-услугами в нем не имеет смысла. Принципы управления в таком холдинге едины для всех сегментов управления. На их основе строится политика корпорации в этой об- ласти. Подобный подход можно наблюдать во многих мировых хол- дингах — Boeing, Microsoft, Volkswagen и других участниках рейтинга «Тор 500» журнала «Forbes». Если же говорить о нашем, российском опыте, то здесь можно на- блюдать все возможные и невозможные сочетания типов управления. Например, одна из крупнейших российских нефтяных компаний, по- строенная как децентрализованная структура, имеет жестко централи- зованный Департамент ИТ. Почему? Так видит правильное функцио- нирование ИТ-службы ее директор информационной службы. Нельзя определенно сказать, что это плохо. Возможно, такой вариант управ- ления в данном конкретном случае оптимален. Но рекомендовать его для всеобщего употребления нельзя. Жесткая централизация Построение управления по принципу жесткой централизации означа- ет создание единого ИТ-подразделения в холдинге. Весь ИТ-персонал дочерних структур переводится в штат вновь созданного подразделе- ния, и вся ответственность ложится на руководителя единого ИТ-под- разделения. Такой подход к построению управления ИТ сегодня явля- ется экзотикой для западных компаний, практикующих управление по центрам затрат. Однако в России он достаточно распространен. К сильным сторонам жесткой централизации следует отнести нали- чие единого ИТ-бюджета, который формируется для холдинга в целом.
254 Глава 7 Это позволяет избежать излишнего распыления средств, сконцентри- ровать их на «направлении главного удара». Распорядителем ИТ-бюд- жета становится руководитель Департамента ИТ. Централизованная кадровая политика обеспечивает управляемость организации, выработку единой корпоративной культуры. Однако в на- ших условиях, когда основной персонал необходимо искать на местах, осуществление этой работы из центра становится проблематичным. Выработка единой стратегии и методологии обеспечивает прозрач- ность и, как следствие, согласованность решений: в централизованной структуре добиться этого легче. В силу удаленности дочерних предпри- ятий и персонифицированной ответственности руководителя единого подразделения подобная организация управления ведет к низкой ско- рости принятия оперативных решений, ошибкам в них или пробук- совыванию проектов. В этих условиях в организации складывается негативный психологический климат. «Передовой» опыт состоит в том, как лучше исполнять распоряже- ния руководителя Департамента ИТ. Неизбежная диктовка из центра «как жить» ограничивает инициативу и вызывает раздражение персо- нала ИТ-служб. Децентрализованная структура В противовес системе жесткой централизации децентрализованная сис- тема управления встречается достаточно часто и соответствует холдинго- вым структурам, объединяющим различные слабо связанные между со- бой бизнесы. Как правило, Департамент ИТ в такой структуре не имеет права вмешиваться в деятельность ИТ-служб дочерних предприятий. К основным функциям Департамента ИТ относятся: • представление интересов ИТ-служб перед акционерами; • оценка и аудит их деятельности; • обеспечение консолидации разнородной отчетности дочерних предприятий. Децентрализованная структура управления ИТ-услугами в холдинге, объединяющем предприятия по отраслевому принципу, имеет ряд пре- имуществ. Это в первую очередь оперативность принятия решений в связи с отсутствием координирующего центра. Кроме того, всесторон- ний учет ситуации на местах позволяет повысить качество решений. Инициатива с мест порождает широкий спектр различных типов сис- темы управления, способствующих выработке и распространению пе- редового опыта. Наконец, отсутствие вертикальных административных связей ИТ-служб с центром обеспечивает независимость и объектив- ность аудита деятельности этих служб.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 255 Вместе с тем децентрализованная структура не позволяет разрабо- тать единую стратегию и методологию для холдинга. Соответственно, это приводит к большим затратам при интеграции решений дочерних предприятий. Разнобой в подходах и квалификации персонала делает трудноразрешимой задачу формирования корпоративной культуры ИТ-служб, что увеличивает риски провала проектов. Мягкая централизация При этом варианте построения управления ИТ в холдинговой структу- ре за центром остаются законодательные, контрольные и представи- тельские функции. Основная часть бюджета, а также ответственность за реализацию планов развития ИТ лежат на дочерних предприятиях. При таком построении управления реализуются основные преимуще- ства вариантов жесткой централизации и децентрализации. Данный вариант управления предполагает наличие консолидиро- ванных планов и бюджета, формируемых Департаментом ИТ на осно- ве планов дочерних структур. Однако управление основной частью бюджета сохраняется за дочерними предприятиями. Централизован- ная кадровая политика реализуется не непосредственным подбором и назначением персонала, а выработкой требований, оценкой и согласо- ванием предлагаемых на руководство ИТ-службами кандидатур. В случае мягкой централизации управления также возможна выра- ботка эффективной единой стратегии и методологии. Координирующий центр делегирует основные исполнительские функции в дочерние струк- туры, что определяет оперативность в принятии решений. Мягкая цен- трализация не подавляет инициативу с мест, но делает ее управляемой, направляет на реализацию согласованных, интегрируемых решений. Наконец, отсутствие жестких административных связей ИТ-служб с центром обеспечивает независимость и объективность аудита деятель- ности таких служб. В варианте мягкой централизации дочерние предприятия имеют достаточную самостоятельность в осуществлении своей производствен- ной деятельности, свой бюджет и распоряжаются им, но при этом Де- партамент ИТ определяет цели и задачи дочерних предприятий и конт- ролирует их деятельность. При мягкой централизации Департамент ИТ, не имея прямых ры- чагов воздействия на принятие решений на уровне дочерних предприя- тий, должен: • разрабатывать стандарты предприятия, рекомендации и требо- вания; • организовывать обучение управленческого персонала дочерних предприятий;
256 Глава 7 • осуществлять постоянный контроль и аудит деятельности пред- приятий в области эксплуатации средств ИТ и реализации про- ектов; • представлять интересы ИТ-служб предприятий перед высшим руководством холдинга; • представлять интересы ИТ-служб предприятий перед корпо- ративными поставщиками, обеспечивать консолидированную лицензионную политику. Практика показывает, что принцип мягкой централизации является наиболее перспективным для развивающихся сегодня в России холдин- гов. Поэтому необходимо остановиться подробнее на таких вопросах, как распределение основных функций по управлению ИТ для этого варианта между Департаментом ИТ холдинга, ИТ-службами дочерних предприятий и руководством холдинга, первоочередные стандарты пред- приятия, руководство и требования к деятельности по управлению ИТ. Для этого воспользуемся рекомендациями международного стандарта ISO/IEC 15288 [2], определяющего процессы управления жизненным циклом системы. Политика информатизации Основным документом, на базе которого строится деятельность всего организационного комплекса по управлению ИТ-услугами в холдинге? должна стать «Политика информатизации», которая утверждается выс- шим руководством холдинга. В ней определяются ключевые принци- пы построения процессов управления ИТ. Наиболее существенными, с нашей точки зрения, принципами, которые должны быть продекларированы в этом документе, являются: * Планирование от нужд бизнеса. Все проекты должны быть обо- снованы с точки зрения их необходимости для улучшения биз- неса предприятия. • Инвестиционное обоснование. Любой проект должен г.роити эко- номическую оценку'' с точки зрения его затрат и результатов. Вы- деление средств на проект должно быть утверждено руководством. • Прозрачность решений для руководства. Ключевые проектные решения должны быть представлены, объяснены и согласованы с руководством холдинга и соответствующих дочерних предприя- тий. Должна быть налажена система отчетности о состоянии ключевых проектов, доступная на всех уровнях управления хол- дингом и дочерними предприятиями.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 257 • Ответственность за результаты. Для руководителей должна быть разработана ясная и эффективная система мотивации как к вы- полнению поставленных задач по управлению ИТ, так и к их невыполнению. • Контроль качества. На уровне Департамента ИТ должна быть выстроена система контроля качества выполнения проектов и сопровождения информационных систем. Система контроля качества должна включать в себя как формальный контроль соответствия стандартам и требованиям, так и контроль коррект- ности проектных решений, их соответствия интеграционным требованиям и методическим рекомендациям. • Работа с лицензированным программным обеспечением. Для снижения рисков использования некачественного и зараженно- го вирусами программного обеспечения, а также рисков финан- совых потерь по искам авторов должна быть разработана ли- цензионная политика, предполагающая использование только легально приобретенных программных продуктов. Общие процессы управления Управление инвестициями Процесс управления инвестициями охватывает следующие области (см. рис. 7.7): • определение и инициация — они необходимы для развития про- ектов в области ИТ; • обеспечение их адекватного финансирования; • контроль их результатов; • определение возможности их продолжения и развития. Процесс управления инвестициями включает следующие этапы. Шаг 1. Разработка стратегии информатизации предприятия (ИТ-стра- тегии), определяющей состояние информационной системы в отда- ленной перспективе и планы реализации в горизонте годового плани- рования. ИТ-стратегия закрепляется в соответствующем согласован- ном с дочерними предприятиями документе, в создании которого они принимают непосредственное участие. Шаг 2. ИТ-стратегия утверждается советом директоров холдинга. В цик- ле развития информационной системы ИТ-стратегия должна периоди- чески подвергаться пересмотру и корректироваться. Этот процесс осу-
258 Глава 7 Руководство холдинга Департамент ИТ ИТ-служба дочерней компании 2. Утверждение ИТ-стратегии 1. Разрлб<>!ка р-псгии I Ро.'.раб'.икн г:р<!Д/Ч>Ж1.’-ИИ II!- ИТ 1 • >. Кон1 ллилацин предложении ги: ИТ-нрси?К1 <1<1 7 7. Утверждение консолидированного -бюджета ИТ Рисунок 7.7. Процесс управления инвестициями ществляется на основе мониторинга и анализа проблем использования информационной системы холдинга. Шаг 3. На основе утвержденной ИТ-стратегии ИТ-службы дочерних предприятий разрабатывают предложения на год по реализации ИТ-про- ектов. При разработке предложений ИТ-службы должны руководство- ваться общекорпоративными «Требованиями к обоснованию проек- тов» и «Положением об инвестиционном процессе». Важно отследить, а при необходимости доработать эти документы так, чтобы они адек- ватно отражали специфику ИТ-проектов. Шаг 4. Департамент ИТ консолидирует планы дочерних предприятий и выносит итоговый документ на Комитет по инвестициям для вклю- чения проектов в инвестиционный портфель. Шаг 5. Комитет по инвестициям утверждает инвестиционный порт- фель ИТ-проектов.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 259 Шаг 6. По проектам, включенным в инвестиционный портфель, про- изводится формирование бюджета ИТ-службы дочерних предприятий и Департамента ИТ. Кроме этого, в бюджет включаются все необходи- мые затраты на поддержание деятельности ИТ-служб, согласно разра- ботанной и утвержденной Департаментом ИТ-структуре. Шаг 7. Консолидированный бюджет ИТ утверждается советом дирек- торов холдинга. Управление ИТ-проектами Управление ИТ-проектами базируется на процессах жизненного цик- ла системы, включающего следующие стадии. • Запуск проекта ИТ-служба осуществляет выбор подрядчика, создает органы управ- ления проектом, формирует календарный план и бюджет проек- та. Все решения должны основываться на корпоративном стан- дарте управления проектами и рекомендациях по выбору постав- щиков и подрядчиков. Основные положения проекта (Устав проекта) согласуются и утверждаются в Департаменте ИТ. • Проектирование и разработка системы ИТ-служба выполняет функции Генерального заказчика — конт- ролирует ход работ и осуществляет приемку и согласование раз- работанной документации. Департамент ИТ согласовывает про- ектные решения с учетом их соответствия требованиям по ин- формационной, функциональной, документарной и инфраструк- турной совместимости с общекорпоративными решениями. Де- партамент ИТ проводит мониторинг и периодический аудит проекта. При вводе системы в действие ИТ-служба организует испыта- ния, в которых обязательно присутствие представителей Депар- тамента ИТ. После передачи системы в эксплуатацию ИТ-служ- ба готовит специальный отчет, на основании которого Департа- мент ИТ готовит оценку результатов проекта и представляет ее в Комитет по инвестициям для защиты. • Эксплуатация и сопровождение системы Основное содержание этой стадии с точки зрения проектного цикла — выявление необходимости развития системы и инициа- ция соответствующих ИТ-проектов. Задача ИТ-службы здесь со- стоит в мониторинге процесса эксплуатации и возникающих проб- лем. Процессы эксплуатации и сопровождения системы подвер- гаются периодическому аудиту со стороны Департамента ИТ.
260 Глава 7 Обобщение и анализ результатов мониторинга и аудита слу- жат основой для регулярного пересмотра стратегии развития информационной системы холдинга и внесения изменений в стандарты и другие руководящие документы. • Совершенствование/«списание» системы Работы по замене системы или выводу ее из эксплуатации, пере- профилирование связанных с этой системой служб эксплуатации и сопровождения должны рассматриваться как самостоятельные ИТ-проекты, в отношении которых реализуется полный цикл управления. Управление ресурсами Этот процесс обеспечивает процессы и проекты необходимым персо- налом. Основные функции Департамента ИТ при работе с персоналом та- ковы: • изучение разработанных стандартов и других руководящих до- кументов; • обучение современным ИТ (самостоятельно или с привлечением специализированных организаций); • проведение периодических совещаний с руководством ИТ-служб для обмена опытом и формирования корпоративного духа; • разработка типовой структуры ИТ-службы и требований к пер- соналу; • проведение аттестации руководителей ИТ-служб. В процессе назначения руководства ИТ-служб дочерних предприятий Департамент ИТ должен играть согласующую роль. Подбор персонала и принятие решений о назначении остаются за руководством дочерних предприятий. Управление закупками В процессе закупки определяются соглашения по приобретению про- дуктов и услуг, а также отношения с поставщиками в процессе приоб- ретения и получения товаров и услуг. Процесс закупки начинается с разработки ИТ-службами спецификации на основании лицензионной политики и стандарта предприятия по инфраструктуре, разработанных Департаментом ИТ. При выборе поставщика основным руководящим документом для ИТ-службы являются рекомендации по выбору подрядчиков и постав-
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 261 щиков. Роль Департамента ИТ в процессе закупки — согласующая. Осуществляет закупку ИТ-служба дочернего предприятия. Резюмируя анализ организации управления ИТ-услугами в холдин- гах, приведем две таблицы. Первая (см. табл. 7.5) фиксирует распреде- ление функций управления ИТ в холдинге между аппаратом управле- ния, Департаментом ИТ и ИТ-службами дочерних предприятий, а во второй (см. табл. 7.6) представлен список первоочередных руководя- щих документов по управлению ИТ в холдинге. Все эти результаты получены на основе моделей процессов управления ИТ, определенных в стандарте ISO/IEC 15288. Вместе с тем мы отдаем себе отчет (и это подтверждает практика), что в каждом конкретном случае модели могут быть построены в зависимо- сти от сложившейся практики управления и распределения функций. Таблица 7.5. Распределение функций управления ИТ Функция Департамент ИТ ИТ-служба Руководство холдинга Планирование/бюджетирование Разработка и корректировка стратегии Утверждение стратегии Планирование проектов Согласование плана проектов Формирование инвестиционного портфеля Разработка бюджета Согласование и консолидация бюджетов Утверждение бюджета Проектный цикл Запуск проекта у/ Утверждение Устава проекта Выполнение проекта Согласование проектных решений и аудит хода проекта Ввод системы в действие Участие в испытаниях Завершение проекта Оценка результатов проекта Защита проекта в Комитете по инвестициям
262 Глава 7 Таблица 7.5. (окончание) Функция Департамент ИТ ИТ-служба Руководство холдинга Работа с персоналом Обучение СТП Обучение современным ИТ Проведение совещаний с руководством ИТ-служб Подбор руководящего персонала Согласование кандидатур Проведение аттестации руководителей ИТ-служб Эксплуатация и сопровождение Организация эксплуатации и сопровождения Обучение пользователей Мониторинг проблем Формирование отчетности по проблемам Закупка Формирование спецификации Выбор поставщика Согласование закупки Осуществление закупки Таблица 7.6. Руководящие документы по управлению ИТ в холдинге № Документ 1 Дополнения к Положению об инвестиционном процессе холдинга, учитывающие специфику ИТ 2 Требования к обоснованию проектов в области ИТ 3 Структура и форма бюджета развития ИТ 4 Стандарт управления проектами в области ИТ 5 Рекомендации по выбору подрядчиков и поставщиков 6 Стандарт по инфраструктуре ИТ 7 Лицензионная политика 8 Требования по интеграции информационной системы предприятия 9 Методики и регламенты сопровождения и эксплуатации информационной системы 10 Типовая структура ИТ-службы и требования к персоналу 11 Методика проведения аудита информационных систем предприятий
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 263 7.6. Повесть о настоящем проекте В данном разделе приведен материал, посвященный опыту реализации крупного ИТ-проекта. Его уроки, на наш взгляд, позволят читателям более четко представить себе те подводные камни, с которыми сталки- ваются компании при внедрении сложных информационных систем, оценить уровень профессионализма, необходимый для решения воз- никающих проблем и, может быть, пересмотреть свои подходы к рис- кам аутсорсинга, обсуждавшимся выше в этой главе. Предпосылки проекта К 1993 г. в региональных управлениях Центрального банка (ЦБ) Рос- сии сложилась напряженная ситуация с обеспечением оперативной, достоверной и безопасной работы информационных систем (ИС). В это время многие региональные управления ЦБ РФ были осна- щены устаревшими техническими и программными средствами. Для осуществления платежей клиенты оформляли необходимые докумен- ты и в бумажном виде доставляли их в расчетно-кассовые центры (РКЦ). После обработки в РКЦ эти документы направлялись в региональные центры информатизации (РЦИ), где производились их обработка, ввод данных в вычислительную систему, автоматическая обработка данных (клиринг платежей и соответствующие бухгалтерские проводки) и пе- редача данных в платежные системы других регионов. Можно было также осуществлять передачу информации о платежах из удаленных местностей по телетайпу. Такая ситуация приводила к задержкам платежей, создавала воз- можность крупных денежных хищений (яркий пример — «чеченские» авизо) и усложняла работу при росте инфляции (из-за обработки сумм платежей с большим количеством знаков). Еще одна серьезная пробле- ма: отечественная банковская система не соответствовала современным международным стандартам, касающимся защищенности, прозрачно- сти, адаптивности и т. п. Между тем приближение к таким стандартам было одним из условий получения Россией западных кредитов. ЦБ РФ принял и начал осуществлять широкую программу информа- тизации, в рамках которой ведущие зарубежные фирмы подготовили соответствующие предложения. Предложение корпорации IBM, имеющей большой опыт по созда- нию ИС для центральных и коммерческих банков во всем мире, было принято к реализации в Иркутске. Для выполнения проекта корпора- ция IBM привлекла ряд субподрядчиков из США и Западной Европы. В соответствии с обоюдным желанием сторон был заключен контракт на полную системную интеграцию — создание системы «под ключ»
264 Глава 7 при твердой фиксированной цене. Соответствующие контракты были заключены и с субподрядчиками. Для IBM это был первый контракт такого рода в России. Участники проекта и их цели В роли организации-заказчика выступило ГУ ЦБ РФ по Иркутской области — структура по своей сути сугубо операционная и строго иерар- хическая. В рамках проекта заказчику предстояло выполнить очень важную часть работ по созданию современной телекоммуникационной и фи- зической инфраструктуры системы, а также по кардинальным измене- ниям технологии работы конечных пользователей. Команда управле- ния проектом IBM должна была сначала объяснить и доказать заказ- чику необходимость новых для него проектных подходов, а потом и помочь в их осуществлении. Следует отметить, что в данном случае заказчик оказался весьма восприимчив (чем немало удивил западных коллег) и с помощью IBM смог реализовать временную матричную структуру организации, необ- ходимую для выполнения своей части работ по проекту. Главной целью проекта для всех его участников стало создание со- временной, эффективной, надежной, защищенной, развивающейся автоматизированной банковской системы для ГУ ЦБ РФ по Иркут- ской области. Для ЦБ РФ были также важны опыт реализации подоб- ных проектов, выход на современные высокие информационные тех- нологии, повышение квалификации и деловой культуры персонала. IBM, кроме всего прочего, стремилась подтвердить свою способ- ность осуществлять сложные проекты в России и получить возмож- ность тиражирования решения в других регионах. Аналогичные цели ставили перед собой и субподрядчики корпорации. Роли и распределение ответственности В самом начале работ по определению проекта и подготовке контракта директором проекта с постоянным местом работы в Москве был назна- чен Д. Армстронг, прежде работавший в IBM UK, поэтому все члены команды управления проектом первоначально были из этой компании. Руководителем (менеджером) проекта с основным местом работы в Иркутске также стал представитель IBM UK Б. Торнтон. Основными задачами руководителя проекта были определены: • создание, реализация и использование системы управления про- ектом для управления проблемами, изменениями и рисками на всех фазах жизненного цикла проекта;
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 265 • управление субподрядчиками, представители которых являлись менеджерами соответствующих подпроектов; • взаимодействие с заказчиком вплоть до уровня высшего руко- водства; • подготовка и проведение совещаний по управлению проектом; • самостоятельное решение текущих вопросов, касающихся управ- ления проектом как в IBM, так и у субподрядчиков и заказ- чиков, поставок оборудования и программного обеспечения, выполнения монтажных и пусконаладочных работ, обучения об- служивающего персонала и конечных пользователей; • общее руководство подготовкой и согласованием проектной до- кументации, приемочными испытаниями системы и ее частей, развертыванием и внедрением системы по Иркутскому региону (22 РКЦ, в том числе в таких отдаленных точках, как Мама и Бодайбо), запуском в эксплуатацию, поддержкой и развитием; • обеспечение безопасности членов команды проекта (в первую очередь граждан других стран) в Иркутске; • согласование возникающих вопросов с представителями мест- ных и центральных властей, например в соответствии с дей- ствовавшим законодательством вопросы по защите информа- ции согласовывались с ФАПСИ и т. п.; • управление персоналом команды (численный состав команды проекта доходил до 30 человек); • управление коммуникациями и конфликтами как в команде проекта, так и в проекте в целом. Вскоре стало ясно, что успешно выполнить проект в совершенно неиз- вестном специалистам IBM деловом и культурном окружении невоз- можно без участия достаточно опытных и профессиональных местных, т. е. российских, специалистов. В московском офисе IBM в то время таких профессионалов не было. Руководители проекта, занимавшиеся подбором кандидатов, при- гласили одного из авторов этой книги (А. Товба) в команду управле- ния проектом сначала в качестве стажера, а впоследствии — замести- теля руководителя проекта («соруководителя» — project manager coun- terpart) [20]. Со временем в IBM сочли возможным и целесообразным, чтобы А. Товб сменил на позиции руководителя проекта своего настав- ника Дж. Кларка, который к тому времени стал одним из опытнейших профессионалов IBM UK.
266 Глава 7 Команда проекта Команда проекта состояла из временно привлеченных специалистов и «костяка» (команды управления проектом), куда вошли: • директор проекта; • руководители проекта от IBM и заказчика; • системный архитектор (главный конструктор) от IBM; • ведущие технические эксперты от IBM (по направлениям); * руководители подпроектов от IBM, субподрядчиков и заказчика; • администраторы проекта; • переводчики. Руководство коллективом осуществлялось путем организационного планирования, подбора кадров, поощрения и стимулирования при чет- ком распределении ролей и персональной ответственности. Метод руководства был выбран демократичный, что впоследствии стало одним из главных факторов успешности проекта. Показателем формирования успешной команды может служить тот факт, что и по прошествии десяти лет многие участники проекта из разных стран поддерживают теплые, дружеские отношения и обмени- ваются визитами. Предметная область Автоматизированная информационная банковская система ГУ ЦБ РФ по Иркутской области включала в себя следующие основные функ- циональные подсистемы: * подсистему ввода и учета данных о платежах в РКЦ на базе специально разработанного программного обеспечения компа- нии Arkansas Systems; • подсистему передачи данных о платежах по коммутируемым и выделенным телефонным и спутниковым каналам связи; • подсистему пакетного клиринга платежей в РЦИ также на базе программного обеспечения Arkansas Systems, специально дора- ботанного для соответствия требованиям ЦБ РФ; * подсистему бухгалтерского учета платежей в РЦИ на основе пакета Equation 3 компании Kapiti, доработанного (были осу- ществлены его адаптация, кастомизация и настройка) с целью полного соответствия требованиям ЦБ РФ;
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 267 • подсистему защиты информации во всей системе на базе специ- ально разработанного программного обеспечения Falcon корпо- рации IBM, обеспечивающего полную защиту информации за счет реализации стандарта DES. Управление проектом В проекте использовались в необходимом объеме принятые в IBM тех- нологии управления проектами, предусмотренные методологией MITP 1 фирмы IBM. Применялись планирование по вехам (контрольным точкам) и ка- лендарно-сетевое планирование с использованием MS Project. Все про- ектные планы сохранялись в центральном проектном архиве как в виде твердых копий, так и в виде машинных файлов. Для обеспечения детального планирования была проведена полная декомпозиция работ по подпроектам, пакетам работ и работам отдель- ных исполнителей. Координация работ участников осуществлялась посредством об- суждения первоначальных планов с последующими их изменениями и согласованием вопросов взаимосвязей и взаимозависимостей работ участников. Проводилась оперативная корректировка планов в соответствии с принятой процедурой принятия изменений. Вопросам отслеживания (мониторинга) и контроля за выполнением работ были посвящены регулярные совещания руководителей проекта и подпроектов, на которые при необходимости приглашались исполни- тели. По каждому совещанию составлялся протокол по утвержденной форме, рассылавшийся всем участникам и заинтересованным лицам. Все протоколы сохранялись в архиве твердых копий и в виде машин- ных файлов. Была принята жесткая система управления изменениями. Все из- менения производились только в соответствии с определенной проце- дурой: ограниченный круг лиц имел право инициировать процесс рас- смотрения изменения, заполнив специальный документ — запрос на изменение. В этом документе отражались: содержание предлагаемого изменения, обоснование его необходимости, возможные последствия реализации, влияние проводимых изменений на другие элементы сис- темы и другие моменты. Через руководителей подпроектов подготов- ленные запросы поступали к руководству проекта. Затем они рассмат- ривались в установленном порядке и получали определенный статус (принять, отклонить, отложить, доложить на очередном заседании Комитета по управлению проектом и т. п.). 1 MITP — Management Implementation of the Total Project.
268 Глава 7 Очень важную роль в успешной реализации столь масштабного международного проекта (в нем участвовали специалисты из Литл-Ро- ка, Лондона, Вены, Москвы, Иркутска) сыграло развертывание новей- шей по тем временам системы коммуникаций всех участников, кото- рая предусматривала обеспечение прямой международной телефонной связи, подключение заказчика к глобальной корпоративной сети связи IBM и Интернету. Надо сказать, что существовала серьезная языковая проблема, для решения которой специально была создана служба переводчиков и проводилось обучение участников проекта иностранным языкам. Основные проблемы и факторы успеха проекта При реализации проекта его участники столкнулись со следующими основными проблемами: 1. Для всех участников это был первый опыт подобного рода. 2. Помимо «обычных» разногласий, касающихся непосредственно бизнеса, приходилось преодолевать множество других проблем «гуманитарного» характера, как то: ♦ языковой барьер (в IBM не предполагали, что знание анг- лийского языка у наших соотечественников так сильно от- стает от общеевропейского уровня); ♦ культурные различия, например, один из участников проек- та, утром вылетев из солнечной Лозанны, а на рассвете при- летев в Иркутск и впервые в жизни увидев в центре города на фоне белого снега темные сибирские избы, серьезно и изумленно спросил: «Is it the same planet?» («Это все та же планета?»); ♦ разница в деловой культуре (например, принципиально разное отношение к взятым обязательствам, к данному слову и т. д.); ♦ социальные различия (уровень доходов и стиль жизни специа- листов заказчика и исполнителя порой были просто несо- поставимыми); ♦ психологические проблемы (например, россияне иногда де- монстрировали неожиданные «выпады», которые можно объяснить латентными пережитками шовинизма, ксенофо- бии и даже расизма, вперемешку с тем, что когда-то называ- ли «низкопоклонство»); ♦ различия образовательные, технические и т. д.
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 269 3. Территориальная отдаленность от основного места жительства (как правило, участники проекта три недели проводили в Ир- кутске, одну неделю — дома). Вместе с тем следует отметить и факторы, способствовавшие успешно- му завершению проекта: 1. Творческое и последовательное внедрение отработанной IBM методологии управления проектами MITP. 2. Активная позиция заказчика, действительно заинтересованного в результатах, который хотел и сумел сыграть определяющую роль в успехе проекта. Особенно велика в этом отношении роль высшего руководства. 3. Высокий профессионализм участвовавших в проекте специали- стов ЦБ РФ. 4. Продуманная и правильно выстроенная IBM система ролевых функций и ответственности руководителей, делегирования пол- номочий и соответствующая схема поощрений руководителей по результатам выполнения ключевых работ. 5. Атмосфера равноправного и конструктивного партнерства, ко- торая способствовала взаимопониманию и успешной реализа- ции проекта. 6. Максимальная сосредоточенность персонала на выполняемой работе (люди трудились по 12—14 ч в сутки без выходных), чему в немалой степени способствовало их вынужденное пребывание вне дома. И последнее, что необходимо подчеркнуть, — это демократичный стиль руководства, который давал каждому члену команды полную уверен- ность в том, что: • его мнение будет внимательно выслушано и по возможности учтено; • руководство всегда пойдет навстречу при решении его личных проб- лем (это особенно важно при географической удаленности «рабо- чей площадки» от постоянного места жительства сотрудника); • руководство не забудет отметить — если не материально, так морально — заслуги и достижения каждого члена команды; • у любого человека есть право на ошибку; за действия, которые не привели к нужному результату, наказание не последует, а за бездействие могут при необходимости и наказать;
270 Глава 7 • все члены команды делают одно большое дело, от их работы зависит успех всего проекта (для этого руководство проводило регулярные формальные и неформальные совещания, «пятими- нутки», на которых обсуждались последние новости, состояние и перспективы развития проекта); • руководство проекта постоянно следит за состоянием психоло- гического климата в команде и принимает все необходимые меры (в нашем случае был даже запланирован специальный бюджет) для поддержания рабочей атмосферы; • руководство всегда само будет отвечать за свои ошибки, не пы- таясь свалить их на исполнителей; • руководство проекта всегда защитит своих подчиненных от необос- нованных претензий. Проект был завершен успешно. Все поставленные цели были достигну- ты в рамках бюджета. Автоматизированная банковская система ГУ ЦБ РФ по Иркутской области была сдана в эксплуатацию в 1995 г. и успешно работала в течение нескольких лет. Однако сроки проекта не были выдержаны: система была принята с задержкой на полгода по сравнению с первоначальным планом. Главной причиной задержки стали дополнительные требования заказчика, кото- рые после соответствующих согласований были приняты к исполнению. Дополнительные работы были полностью выполнены и оплачены. Уроки управления сложным комплексным ИТ-проектом 1. Методология управления проектами должна всегда применяться творчески; особенно важен выбор оптимального уровня проект- ной «бюрократии» — это залог успеха. Неоптимальный уровень проектной «бюрократии» — всегда источник проблем. Умение определить оптимальный уровень зависит от опыта и интуиции руководителя проекта и свидетельствует о его мастерстве, пере- ходящем в искусство. 2. Основополагающее значение для успеха проекта имеет его свое- временное, достаточно четкое и глубокое определение. Послед- нее должно быть документально оформлено и согласовано с за- казчиком и может корректироваться по согласованию сторон. На основе этих изменений исполнитель порой получает допол- нительный объем работ за дополнительную оплату. 3. Важнейший фактор успеха — взаимоотношения сторон и отно- шения внутри проектной команды. Синергия позволяет преодо-
Проекты и политика. Роль и место ИТ-службы в реализации ИТ-проектов 271 леть трудности, а конфликты могут обесценить полученные ре- зультаты. 4. Особенно важны конструктивный подход заказчика к проекту (его реальная заинтересованность в результатах) и, как следствие, установление равноправного конструктивного партнерства с ним на базе постоянного и всестороннего взаимного учета интересов сторон. 5. Реализация проектного подхода в организации исполнителей проекта. Построение системы ролевых функций в соответствии с зонами ответственности, делегирование полномочий ответ- ственным руководителям проекта, забота о его участниках и соответствующая система поощрений руководителей и испол- нителей по результатам выполнения ключевых работ проекта. Участие в проекте, который и через много лет после его завершения 1 не утратил для его участников свою значимость, стало для автора важ- ной ступенькой в профессиональной карьере. У скептического читателя могло создаться впечатление некоторой благостной идеализации тех событий. Тем не менее все это правда. Проект остался в памяти как «настоящий», давший уникальный профес- сиональный опыт в силу сложившихся конкретных обстоятельств. Ко- нечно, не вся правда вошла в эту «повесть» (были и частные проблемы, ошибки участников и т. д.). Одна очевидная причина этого — в естест- венной аберрации памяти автора («и трава тогда была зеленее»), дру- гая — в том, что по прошествии стольких лет, за которые участников проекта раскидало по разным местам, публичный «разбор полетов» представляется неуместным с этической точки зрения, поскольку кри- тика может быть и неверно воспринята. Литература 1. ГОСТ 34.201-89. Комплекс стандартов и руководящих материалов на ав- томатизированные системы. УДК 65.015.13.011.56:006.354 2. ISO/IEC 15288 Life Cycle Management — System Life Cycle Processes. 3. CobIT: Executive Summary / ISACA, 3d ed. 2000 (неофициальный перевод на русский язык, выполненный Рабочей группой ISACA.ru, доступен на сайте www.isaca.ru). 4. Ципес Г., Терентьев Е., Циперман Г. Проекты и процессы в деятельности ИТ-службы // Директор информ, службы. 2006. № 6. 1 Участники проекта отметили его десятилетие встречей на праздничном обеде в одном известном лондонском ресторане русской кухни.
272 Глава 7 5. Циперман Г. Кризис информационных технологий // iBUSINESS. 2001. № 4. 6. Циперман Г., Ципес Г. К кому сейчас легко? // Директор информ, службы. 2003. № 6. 7. Овербай С. Сотрудники во власти стресса // Директор информ, службы. 2003. № 6. 8. Циперман Г., Ципес Г. Политические аспекты внедрения корпоративных информационных систем // Сб. трудов IV Всерос. практ. конф. «Стандар- ты в проектах современных информационных систем», Москва, 21—22 ап- реля 2004 г. М.: ФОСТАС, 2004. 9. Циперман Г., Ципес Г. BSC для СЮ // Директор информ, службы. 2004. № 6. 10. Шраге М. Ключ к инновациям: преодоление сопротивления // Директор информ, службы. 2006. № 2. 11. Каплан Р., Нортон Д. Сбалансированная система показателей. От страте- гии — к действию / Пер. с англ. М.: ЗАО «Олимп—Бизнес», 2003. 12. Ципес Г. Ключевые показатели деятельности в проектно-ориентированной компании // Директор информ, службы. 2003. № 5. 13. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003. 14. Болдырева Ю., Ципес Г. Управление персоналом: взгляд сквозь призму стра- тегии // Управление человеческим потенциалом. 2005. № 4. 15. Мензано Р. Управление портфелем приложений предприятия // Директор информ, службы. 2003. № 4. 16. Ципес Г. ИТ-проекты в портфелях и программах //Директор информ, служ- бы. 2003. № 4. 17. Циперман Г. Н., Ципес Г. Л. Проектное управление для СЕО. Практические рекомендации // iBUSINESS. 2001. № 1-2. 18. Аншина М. У страха глаза велики // Директор информ, службы. 2003. №11. 19. Циперман Г. О пользе разумной централизации // Директор информ, службы. 2003. № 11. 20. Товб А. Повесть о настоящем проекте // Директор информ, службы. 2001. №4.
Заключение

В этой книге мы остановились всего лишь на нескольких примерах использования методов проектного управления в различных областях современного бизнеса. Это те области, в которых у нас есть собствен- ный опыт внедрения методов проектного управления. Однако практи- ка внедрения этого подхода гораздо шире. И мы считаем необходимым в этой связи отметить некоторые интересные отраслевые решения, описанные в различных публикациях последних лет. Проектное управление в проектных институтах 1. Ананьин В. Модели управления проектной организации // Междунар. сим- позиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17 18 мая 2005 г. 2. Малыха Г., Перевалова Ю., Тащилин Е. Создание интегрированной инфор- мационной технологии автоматизации и управления процессами строи- тельного проектирования //17-й Всемир. конгресс по управлению проек- тами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 3. Юхов А., Волкова Е. Опыт применения СУП PRIMAVERA в проектном институте // 17-й Всемир. конгресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 4. Чернаков В., Сенько А., Фунтов В. Реализация стратегии проектного инсти- тута через проекты развития // Управление проектами и программами. 2006. № 4(8). Проекты в атомной и электроэнергетике 5. Giri J.P.N. Threshold dimension on vertical integration for energy business in India // 19th IPMA World Congress, New Delhi, 13—16 November 2005. Обсуждаются риски, с которыми сталкиваются участники энерге- тических проектов: политическая ответственность, опасности для окружающей среды, обеспокоенность общества, влияние организо- ванной преступности, физические риски для персонала и т. д. 6. Bogdanovic N. «Titanic syndrome» — is it possible to save the ship // Между- нар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Пе- тербург, 17-18 мая 2005 г. 275
276 Заключение Анализируются различные аспекты проекта восстановления систе- мы энергоснабжения, разрушенной во время войн на территории бывшей Югославии. 7. Полушкин А., Мезенин И., Цветков А., Колосова Е. Опыт внедрения сис- темы управления проектами в атомной энергетике // 17-й Всемир. конг- ресс по управлению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 8. Катышев С. Проект модернизации национальной электрической сети Ка- захстана и управление им // 17-й Всемир. конгресс по управлению проек- тами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. 9. Савельев Г., Резник М. Система управления проектами ремонтов оборудо- вания электростанций ОАО «Ленэнерго» // 17-й Всемир. конгресс по управ- лению проектами, Москва, 4-6 июня 2003 г. М.: СОВНЕТ, 2003. Проекты в банковской сфере 10. Богачева Ю. Внедрение проектного управления в банке «ИНГ Банк (ЕВ- РАЗИЯ) ЗАО» на примере департамента ИТ // 17-й Всемир. конгресс по управлению проектами, Москва, 4—6 июня 2003 г. М.: СОВНЕТ, 2003. Проекты в медиабизнесе и творчестве 11. Дубовик М. Система управления проектами многопрофильного медиахол- динга // Управление проектами. 2005. № 3(3). В статье рассматриваются подходы к классификации проектов в компании, уровни «схемы» управления, а также особенности роле- вой структуры управления проектами. Предлагается сбалансирован- ный подход к построению корпоративной системы управления в многопрофильном медиахолдинге, где реализуемые проекты отли- чаются друг от друга. 12. Коган Ю. Универсальность методологии управления проектами: об одном неочевидном применении // Междунар. симпозиум «Управление проек- тами: Бизнес. Идеи. Практика», С.-Петербург, 17-18 мая 2005 г. В качестве объекта применения проектного подхода рассматрива- ется творческая деятельность коллектива театра в совокупности с материальным производством художественного оформления спек- таклей, маркетинговой, издательской и административной деятель- ностью в процессе выпуска новых постановок и эксплуатации те- кущего репертуара. В статье приводятся аналогии творческо-про- изводственного процесса в театре с процессами проектно-конст- рукторских и научно-исследовательских разработок. 13. Виговская Л., Зенин С., Мкртумян А., Соловей И. Проектный подход при организации «творческого» бизнеса // Междунар. симпозиум «Управление проектами: Бизнес. Идеи. Практика», С.-Петербург, 17—18 мая 2005 г.
Заключение 277 Рассматривается опыт создания и внедрения методологии проект- ного управления в компаниях, основой деятельности которых явля- ются разработка архитектурных решений, дизайн и декорирование интерьеров жилой среды (дома, квартиры), проектирование ланд- шафтной среды, 14. Брук Дж. Как выжить на американских горках. Негативный опыт приме- нения управления проектами в телеиндустрии /,/ Управление проектами и программами. 2006. № 3(7), № 4(8). В работе предпринята попытка выявить общие закономерности в том, что касается опыта применения управления проектами в теле- визионной производственной индустрии, и на этой основе создать перечень универсальных «наихудших случаев» применения УП, ко- торый станет полезным пособием, отвечающим на вопрос, как не надо делать.
Списоктаблиц Табл. 2.1. Структура портфелей и программ................41 Табл. 2.2. Описание критериев оценки проектов............62 Табл. 2.3. Регламент управления целевой программой.......70 Табл. 2.4. Принципы формирования органов управления программами..................75 Табл. 2.5. Статус должностных лиц, входящих в органы управления программой.........76 Табл. 3.1. Структура стандарта управления проектами.... 107 Табл. 3.2. Дополнительные разделы стандарта управления проектами.......................... 109 Табл. 3.3. План управления проектом цифрового подключения клиента телекоммуникационной компании................. 116 Табл. 3.4. Отчет об использовании ресурсов............. 118 Табл. 3.5. Формирование измерителей и показателей в проектах подключения................................. 122 Табл. 4.1. Структура основных процессов авиаперевозчика.. 140 Табл. 4.2. Сбалансированная система показателей для продуктового подхода............................... 144 Табл. 4.3. Этапы работ в области создания института продуктовых групп...................................... 148 Табл. 5.1. Классификация проектов по масштабности....... 166 Табл. 5.2. Классификация проектов по сложности........ 166 Табл. 5.3. Фрагмент структуры операционного стандарта управления строительными проектами............ 172 Табл. 5.4. Состав микрошаблонов раздела «Организационная структура проекта».................... 174 278
Список таблиц 279 Табл. 5.5. Микрошаблоны подраздела «Состав рабочих групп». 175 Табл. 5.6. Смета затрат проекта по внедрению системы управления проектами (первый этап)...... 189 Табл. 5.7. Смета затрат проекта по внедрению системы управления проектами (второй этап) .............. 194 Табл. 6.1. Иерархия целей и результатов в программах и проектах.......................................204 Табл. 6.2. Конечные результаты программы поддержки малого предпринимательства..................... 208 Табл. 6.3. Прямые результаты программы поддержки малого предпринимательства.......................208 Табл. 6.4. Структура целевой программы....................210 Табл. 6.5. Показатели БОР и BSC...........................213 Табл. 6.6. Структура бюджета проекта......................217 Табл. 6.7. Смета расходов.................................218 Табл. 6.8. Форма финансового отчета проекта...............220 Табл. 7.1. Стратегическая карта ИТ-службы.................230 Табл. 7.2. Ключевые показатели проектной деятельности ИТ-службы........................................232 Табл. 7.3. Ключевые показатели непроектной деятельности ИТ-службы........................................233 Табл. 7.4. ИТ в стратегической карте компании ............243 Табл. 7.5. Распределение функций управления ИТ............261 Табл. 7.6. Руководящие документы по управлению ИТ в холдинге.......................................262
Список иллюстраций Рис. 1.1. «Пирамида успеха» — методология управления проектом.............................10 Рис. 1.2. Процессы управления проектом...................11 Рис. 1.3. Ключевые факторы успешного применения управления проектами............................30 Рис. 2.1. Проектные офисы в организационной структуре компании........................................42 Рис. 2.2. Взаимосвязь КПД с различными уровнями управления.............................45 Рис. 2.3. Жизненный цикл месторождения................. 48 Рис. 2.4. Состав работ комплексного проекта «Поиск месторождения»......................... 50 Рис. 2.5. Органы управления комплексного проекта «Поиск месторождения» ..........................52 Рис. 2.6. Процессы управления портфелем проектов.........54 Рис. 2.7. Структурированное представление проектов предприятия.....................................57 Рис. 2.8. Процедура формирования портфеля проектов.......58 Рис. 2.9. Процедура мониторинга и анализа проектов..... 59 Рис. 2.10. Структура организационных планов............ 68 Рис. 2.11. Структура целевой программы...................71 Рис. 2.12. Принципиальная схема синхронизации функциональных и интеграционных проектов........73 Рис. 2.13. Организационная структура управления целевой программой...................77 Рис. 3.1. Классификация бизнес-процессов.................85 Рис. 3.2. Бизнес-процессы таксопарка.....................85 280
Список иллюстраций 281 Рис. 3.3. Бизнес-процессы оператора связи............... 86 Рис. 3.4. Бизнес-процессы авиаперевозчика............... 88 Рис. 3.5. Бизнес-процессы строительной компании...........88 Рис. 3.6. «Пространство» процессов управления проектом ...90 Рис. 3.7. Модель бизнес-процесса «Продажа услуги»....... 97 Рис. 3.8. Формирование проектных структур............... 97 Рис. 3.9. Распределение ролей в проектно-ориентированной компании ......................99 Рис. 3.10. Схема организации команд проектов подключения.. 101 Рис. 3.11. Привлечение сотрудников компании на различных этапах проекта........................... 103 Рис. 3.12. Схема премирования в проектно-ориентированной компании.......................................... 104 Рис. 3.13. Структура корпоративного стандарта управления проектами............................................... 105 Рис. 3.14. Система ключевых показателей для процессов подключения........................................... 120 Рис. 3.15. Проекты обслуживания запросов................ 127 Рис. 4.1. Эволюция приоритетов бизнеса............... 132 Рис. 4.2. Варианты формирования продуктов авиаперевозчика ... 135 Рис. 4.3. Продуктовая структура транспортной компании.... 136 Рис. 4.4. Типовая структура жизненного цикла продукта .. 137 Рис. 4.5. Образование продуктовых групп............... 145 Рис. 4.6. Эволюция продуктовых групп.................. 145 Рис. 5.1. Структура бизнеса управления проектами ....... 154 Рис. 5.2. Основные составляющие СУП .................... 157 Рис. 5.3. Технология создания СУП....................... 160 Рис. 5.4. Стадии жизненного цикла строительного проекта.. 167 Рис. 5.5. Схема процедуры управления инжиниринговым проектом............................................ 176 Рис. 5.6. Зоны ответственности в строительном проекте .. 179 Рис. 5.7. Шаблон календарного плана стадии проектирования строительного проекта ............................ 180 Рис. 5.8. Обеспечение охраны труда и промышленной безопасности......................... 182 Рис. 5.9. Обеспечение охраны окружающей среды.......... 183 Рис. 5.10. Обеспечение финансирования проекта .......... 184 Рис. 5.11. Обеспечение работы по претензиям.......... 185 Рис. 6.1. Ограничения проекта.......................... 201 Рис. 6.2. Матричная структура целевой программы..........207 Рис. 6.3. «Дорожная карта» системы показателей целевой программы.............................................. 212
282 Список иллюстраций Рис. 7.1. Уровни функционирования ИТ-службы.............226 Рис. 7.2. Цели верхнего уровня функциональной стратегии ИТ-службы...............................................227 Рис. 7.3. Барьеры на пути внедрения КИС.................237 Рис. 7.4. Использование показателей для определения диапазона обоснованной численности персонала............242 Рис. 7.5. Уровни стратегического управления компанией...246 Рис. 7.6. Организационная схема проекта внедрения КИС...252 Рис. 7.7. Процесс управления инвестициями...............258
Послесловие Лет 10—15 назад достать книгу по управлению проектами в России было практически невозможно. Западная литература не переводилась, российские авторы писали мало, а то, что было написано, выходило мизерными тиражами и не переиздавалось. Сегодня ситуация измени- лась в лучшую сторону. Появилось много книг, в которых широко представлены теория, методология и инструментарий проектного управ- ления. Но даже на этом фоне книга, которую вы держите в руках, является особенной. В ней впервые широко показана практика применения управления проектами в России. С представлением реального опыта управления проектами проблемы возникали всегда. В прежние вре- мена это было связано с закрытостью советского общества, сегодня — с коммерческой тайной и корпоративными интересами. Поэтому зна- чение книги, в которой собран, систематизирован и обобщен практи- ческий опыт применения методов проектного управления в различных областях экономики, в государственном секторе, трудно переоценить. Хочу отметить еще одно принципиальное достоинство этой книги. Конкретный опыт собственных проектов авторы, с одной стороны, погружают в широкий контекст современных достижений в области методологии управления проектами и, с другой стороны, соотносят с опытом практического использования методов управления проектами, описанным в различных источниках. Это дает возможность читателям узнать и получить представление о десятках интересных работ, разбро- санных по различным журналам, сборникам конференций, симпозиу- мов и конгрессов. Эта книга является логичным и достойным продолжением и разви- тием первой книги авторов «Управление проектами: стандарты, мето- ды, опыт», в которой внимание было главным образом сконцентриро- 283
284 Послесловие вано на практических вопросах переложения традиционных методов управления проектами на язык корпоративных стандартов. Вместе эти две книги представляют собой значительный вклад в то, что я назвал бы «энциклопедией практического менеджмента проектов», энцикло- педией, в которой пока не хватает третьей части — описания лучших практик применения управления проектами и подробных case study. Я очень надеюсь, что авторы продолжат работу в этом направлении, хотя, конечно, создание подобной энциклопедии — это задача, кото- рую должно сообща решать все наше профессиональное сообщество. Авторы этой книги очень много выступают, пишут, и все, что они делают, пользуется неизменным интересом и признанием в среде про- фессионалов и специалистов. Это действительно уникальный автор- ский коллектив, в котором органично сочетаются глубокое понимание методологии управления проектами и владение широким контекстом управленческого консалтинга, практический опыт управления и яркие творческие способности. Именно благодаря этим качествам Александру Товбу и Григорию Ципесу и удается вносить весомый вклад в обога- щение и развитие нашей профессии. А выход на новые горизонты профессионализма в управлении про- ектно-ориентированной деятельностью особенно важен именно сегод- ня и именно в России. Мы все рассчитываем на то, что управление проектами как новая управленческая культура и технология позволит форсированно перейти от спонтанного развития в «точках роста» к целенаправленному планомерному развитию, от отдельных проектов и программ через проектно-ориентированные организации и компа- нии к проектно-ориентированному бизнесу и обществу в целом. В. И. Воропаев, Президент СОВНЕТ, академик РАЕН и МАИЭС, профессор, д.т.н.
А.С. Товб, ГЛ. Ципес А. С. Товб, Г.Л. Ципес Управление проектами. Стандарты, методы,опыт М., 2005, 240 с.: ил. 70x100 V16. Переплет ISBN 5-9693-0038-1 История бизнеса — это исто- рия успешных проектов. А конкуренция в современ- ном бизнесе ведется не на уровне компаний, а на уров- не проектов. Успешность ком- пании определяется качест- вом и прибыльностью ее проектов. Книга задумана как практическое пособие по созданию интегрированной системы управления проектами, реализуемой в виде стандарта предприятия. Предлагаемые в ней подходы и решения базируются на следовании основным положе- ниям общепризнанных методологий управления проектами и на практическом опыте работ, выполненных при участии авторов.
Российская национальная ассоциация управления проектами «СОВНЕТ» предлагает оптимальный путь продвижения вперед к новым знаниям в об- ласти управления проектами (УП). Повысив уровень профессйонального мастерства и став сертифицированным специалистом по УП, вы не только получите импульс для собственного карьерного роста, но и обеспечите кон- курентные преимущества и выгоды для своей компании. ОБУЧЕНИЕ И ПОВЫШЕНИЕ КВАЛИФИКАЦИИ Учебно-консультационный центр СОВНЕТ на базе кафедры «Управление проектами и программами» Государственной академии профессиональной переподготовки и повыше- ния квалификации руководящих работников и специалистов инвестиционной сферы (ТА- СИС) предлагает учебный курс подготовки специалистов по управлению проектами. Пос- ле окончания курса слушателям выдается удостоверение государственного образца МИН- ВУЗа РФ (лицензия Федеральной службы по надзору в сфере образования и науки, серия А №161695, регистрационный №3597 от 09.11.2004 г.). Занятия проводятся в дневное и вечернее время по программам базового курса (40 часов) и углубленного курса (80 часов). Организациям предлагается корпоративное обу- чение по программам, адаптированным к условиям заказчика, и на его территории. Обу- чение проводит высококвалифицированный профессорско-преподавательский состав из работников кафедры и членов СОВНЕТ. Все преподаватели обладают богатым педагоги- ческим и практическим опытом работы в области управления проектами и имеют между- народные сертификаты по управлению проектами. Занятия проводятся по адресу: Москва, ул. Кибальчича, д. 7 (5-10 минут пешком от метро ВДНХ). Приезжие обеспечиваются гостиницей, расположенной в том же здании. МЕЖДУНАРОДНАЯ ПРОГРАММА СЕРТИФИКАЦИИ СПЕЦИАЛИСТОВ Управление проектами и программами во всем мире осуществляется профессиональ- но подготовленными и сертифицированными специалистами в этой области. В России международную сертификацию специалистов осуществляет СОВНЕТ-СЕРТ в соответствии с требованиями, установленными международной ассоциацией управления проектами (IPMA) и Российской ассоциацией управления проектами (СОВНЕТ). Правовые основы для международной сертификации являются соглашение между СОВНЕТ и IPMA и регистрация в Государственном реестре Госстандарта России. Сертификации специалистов предусматривает четыре уровня: ’ уровень А — сертифицированный директор проектов; ' уровень В — сертифицированный управляющий проектом; уровень С — сертифицированный профессионал по управлению проектами; уровень D — сертифицированный специалист по управлению проектами. Сертификаты специалистов (на русском и английском языках) признаются признают- ся де-факто во всём мире и де-юре во всех странах-членах IPMA (более 40 стран Европы, Азии, Америки и Африки). Все данные о сертифицированных специалистах заносятся в международный реестр IPMA, опубликованный на сайтах СОВНЕТ www.sovnet.ru и IPMA www.ipma.ch.
ПРЕИМУЩЕСТВА, КОТОРЫЕ ДАЕТ СЕРТИФИКАЦИЯ Для Специалистов: • международное признание квалификации и компетентности; • персональные преимущества для карьерного роста; • повышение профессионального рейтинга и цены предоставляемых услуг. Для компаний и организаций: • высокая эффективность реализации проектов; • повышение рейтинга и конкурентоспособности на российском и международном рынках. Ассоциация Управления Проектами СОВНЕТ 129366, Москва, ул. Кибальчича, д. 7, 504 Тел./факс: (495) 682-62 -73, (495) 683-78-80 E-mail: sovnet@sovnet.ru Web: www.sovnet.ru
Роберт Б. Такер Инновации как формула роста. Новое будущее ведущих компаний М., 2006, 240 с.: ил. 70x100 Vie. Переплет ISBN 5-9693-0055-1 Перевод с английского: Robert В. Tucker. Driving Growth Through Innovation. How leading Firms Are Transforming Their Futures. Berrett-Koehler Publishers, Inc., 2002 Прочитав книгу, вы узнаете, как разработать и реализо- вать инновационную стра- тегию для вашей компании; обеспечить конкурентное преимущество, определяя и удовлетво- ряя нереализованные потребности клиентов; создать систему, ко- торая не позволит хорошим идеям затеряться или оказаться в ру- ках у конкурентов; определить продукты, процессы и стратегиче- ские идеи, которые потенциально могут стать достижениями. Книга является результатом многолетних исследований одного из ведущих экспертов в области инновационной деятельности. Анализируя реальные примеры из истории известных компаний, автор обобщает опыт лучших инновационных методов XX столетия и предлагает подходы к достижению роста в XXI веке.
Издательство «Олимп—Бизнес» 119071, Москва, ул. Орджоникидзе, д. 13/2, 15-й этаж Тел./факс: (495) 411-90-14 (многоканальный), 795-39-95, 795-39-96 Интернет-магазин: http://www.olbuss.ru e-mail: sales@olbuss.ru Как купить наши книги: • В интернет-магазине издательства • Сделать заказ по телефону 411-90-14 • Приехать в офис издательства «Олимп—Бизнес» Спрашивайте книги нашего издательства в магазинах вашего города Издательство «Олимп—Бизнес» приглашает к сотрудничеству оптовиков, книготорговые организации и магазины. Информацию об условиях работы можно получить в отделе продаж издательства
Г. Л. Ципес, А. С. Товб Менеджмент проектов в практике современной компании Редактор Г. Семеко Корректоры С. Малина, Н. Шерстенникова Компьютерная верстка С. Родионова Художник В. Каменева Сдано в набор 21.07.2006. Подписано в печать 13.10.2006. Формат 70x100 }/1Ь. Бумага офсетная № 1. Гарнитура «Times». Печать офсетная. Печ. л. 19,0. Уч.-изд. л. 11,5. Заказ № 2774 Издательство «Олимп—Бизнес». 119071, Москва, ул. Орджоникидзе, д. 13/2, 15-й этаж. ОАО «Типография „Новости"». 105005, Москва, ул. Ф. Энгельса, 46.

сГГ МЕНЕДЖМЕНТ ПРОЕКТОВ в практике современной компании Ципес Григорий Львович Главный консультант Департамента управленческого консалтинга IBS Член правления Российской ассоциации управления проектами СОВНЕТ Сертифицированный специалист по управлению проектами Участник и руководитель более 30 крупных консалтинговых проектов Автор и соавтор более 50 публикаций и докладов в области управления проектами, оптимизации бизнес-процессов и других областях управленческого консалтинга Председатель Программных комитетов международных симпозиумов по управлению проектами (май 2005 г. и февраль 2007 г.) Товб Александр Самуилович Заместитель руководителя проекта TACIS Вице-президент Российской ассоциации управления проектами СОВНЕТ Национальный асессор IPMA по профессиональной сертификации Сертифицированный управляющий проектами CSPM IPMA Руководитель ряда крупных и успешных проектов Автор и соавтор многих публикаций и докладов в области управления проектами Председатель Организационных комитетов международных симпозиумов по управлению проектами (май 2005 г. и февраль 2007 г.) Заместитель главного редактора журнала СОВНЕТ и ИД Гребенникова «Управление проектами и программами» Эта книга — замечательный пример применения идеи «Project Thinking», предложенной мною в 1999 году, ко- гда проектное мышление, проектный подход не подме- няют и не подминают другие управленческие методы, а наоборот гармонично сочетаются с ними Я с интересом следил за работами Александра Товба и Григория Ципеса, представленными на всех всемирных конгрессах IPMA по управлению проектами последних лет от Берлина (2001) до Шанхая (2006) Искренне рад, что эти работы получили логичное продолжение в форме очень интересной и практически полезной для широких кругов специалистов и руководителей книги Без преувели- чения могу назвать эту книгу «обязательным чтением» для всех профессионалов управления проектами. Адеш Джейн (Индия), Президент Международной ассоциации управления чргекгами IPMA Пдезияент и основа л РМА Индия Управление проектами становится одним из самых востребованных инструментов менеджмента в государ- ственной сфере Внедряемые в государственных органах власти программно-целевые методы управления и пла- нирования деятельности нацеленные на результат, есть не что иное, как элементы управления проектами Поэтому знакомство с этой книгой для читателей работающих в государственных органах власти, будет крайне полезно как с точки зрения совершенствования своих профессио- нальных знаний, так и для расширения кругозора в вопросах перспективных технологий управления. М. В. Мишустин, Руководитель Федерального агентства кадастра объектов недвижимости ОЛИМП БИЗНЕС Посетите наш интернет-магазин www.olbuss.ru 9 785969 300545