In English

В зеркале ИТ-проекта

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

ИТ-ПРОЕКТ

Реализация ИТ-проектов вряд ли возможна без согласованной работы сотрудников компании, заказчиков, инвесторов, субподрядчиков и непо­средственных исполните­лей. Такие непохожие виды деятельности, как открытие филиала магазина, создание или внедрение информаци­онной системы, роднит то, что все эти мероприятия, как правило, проводятся при ограниченных времен­ных и финансовых ресурсах, а также при жестком кон­троле рисков и качества. Данные аспекты обязатель­но учитываются в рамках проектного управления. На сегодняшний день существу­ет два подхода к управле­нию: PMI (Project Management Institute - институт проектного менеджмента) и IPMA (Internet Public Management Association - меж­дународная ассоциация уп­равления проектами). Одна­ко из-за избыточности их требований все правила и рекомендации обычно не соблюдаются, а их согласо­вание по разным причинам не проводится. Одна из этих причин - техническая: от­сутствие оговоренных и ут­вержденных способов ин­формационного взаимодей­ствия и появляющиеся вследствие этого недоверие и проблемы, связанные с выполнением тех или иных стадий проекта. Другая со­стоит в сильной дифферен­циации подходов, знания и опыта заказчиков из госу­дарственного и коммерчес­кого секторов. Однако даже если проектное управление выстроено по всем канонам, проект не всегда оказывает­ся успешным.

НЕ КАЖДЫЙ ПРОЕКТ УСПЕШЕН

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

В немалой степени эти ус­пехи зависят и от инвестиро­вания средств в ИТ. Если в постперестроечные времена (когда, собственно, и начался компьютерный бум) реализа­ция проектов, не говоря уже об управлении, осуществля­лась методами "качественно­го убеждения"; при этом по­являлось огромное количест­во разработчиков ПО (созда­вались бухгалтерские, финансовые, офисные, share­ware-, игровые программы), продавцов ПО (некоторые из них позднее легализова­лись), интернет-провайдеров и т.д. К сегодняшнему дню появились иные методы оценки затрат на ИТ-проекты. Например, на качествен­ном уровне оценивается "интеллектуальность" бизнеса, растущая при увеличении объемов информации в сфе­ре управления, простота до­ступа к информации, зависи­мость управленческих реше­ний от оперативных данных и т.д. Учитывая все эти пара­метры вкупе с традиционны­ми показателями ROI, IRR, мы можем говорить о том, что проекты в ИТ-сфере стано­вятся вровень с другими биз­нес-проектами. Говоря об ин­вестициях в ИТ, надо напом­нить и о приоритетах: если в прошлые годы (1999-2001) компании вкладывались в развитие корпоративных ин­формационных систем, ин­тернет-технологии и Web-сервисы, решали "Проблему 2000", параллельно создавая необходимую технологичес­кую базу, то сегодня приори­теты несколько иные - по свидетельству агентства InformationWeek, проводяще­го опросы ИТ-директоров, среди наиболее приоритет­ных для компании задач на­зываются информационная безопасность и хранилища данных.

ДОЛГАЯ ЖИЗНЬ ПРОЕКТА

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

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

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

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

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

К ВОПРОСУ О МЕТОДАХ УПРАВЛЕНИЯ

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

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

Стратегический и деталь­ный планы служат для выра­ботки цели и разработки процессов управления проектом, которые тоже можно ранжировать по определен­ным признакам: одна группа связана со сроками, вторая с качеством, третья - с испол­нителями, четвертая - с ин­формационными потоками и т.д. На каждом таком этапе из-за ошибок в выборе стра­тегии, нечетких целей или низкой квалификации персо­нала возможны проблемы. Решить их можно с помощью методологии управления ри­сками в соответствии со стандартом ISO 10006:1996, включающей в себя выявле­ние, оценку, разработку пла­нов реагирования на риски, а также реализацию и обнов­ление планов. Мало оцени­вать риски, надо еще прово­дить анализ причин их воз­никновения, для чего лучше всего применить метод FMEA (Failure Mode, Effects and Analysis), в котором (как пра­вило, на основе данных пре­дыдущих проектов) подбира­ется стратегия внесения из­менений в проект.

В августе 2003 года орга­низация PMSI (Project Management Solution Inc.) опубликовала данные по эф­фективности внедрения ме­тодов управления, которые были получены в результате анализа работы 43 компаний, занимающихся созданием ин­формационных систем. Были отобраны специфические для проектного управления двад­цать метрик, в том числе ус­пешность завершения по вре­мени, по бюджету, по реали­зации ожиданий заказчика и др. По временной метрике эффективность достигала 38%, по минимизации затрат - 27%, по реализации ожида­ний заказчика - 38%. Подбор правильных методов управ­ления дает рост эффективно­сти выполнения проектов средней сложности до 35%. Для более сложных проектов эффективность выше, хотя и незначительно, всего на не­сколько процентов.

ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ: РОССИЯ И ЗАПАД

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

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

По мнению многих сис­темных интеграторов, диалог с новым заказчиком (прежде всего из госсектора) следует начинать не с демонстрации диаграммы Ганта, а с состав­ления списка конкретных ра­бот. На очередном совеща­нии - присовокупить к нему графики выполнения работ. А уже позднее пригодятся схемы с логическими связя­ми, указанием конкретных сроков выполнения работ и ответственными исполните­лями, и, наконец, заказчику объясняется, что такое диа­грамма Ганта. В следующем ИТ-проекте работа с этим за­казчиком пройдет значитель­но проще.

Различие школ проявляет­ся в понимании целей и на­значения задач проектного управления заказчиком, а также в самой возможности перераспределения полно­мочий участников проекта: они легко меняются в ком­мерческих компаниях и очень тяжело - в государст­венных. Сравнивать запад­ную и российскую школы проектного управления мож­но даже по такому парамет­ру, как объем проектного до­кумента. В США все положе­ния проекта согласуются с действующим законодатель­ством и жестко регламенти­руются - проектный доку­мент может занимать сотни страниц, а менеджер проекта тратит четверть своего вре­мени на согласование взаи­моотношений участников. В России, как правило, все в точности до наоборот: про­ектный документ порой уме­щается всего на нескольких десятках страниц, и последу­ющая переписка, телефонные переговоры между руководи­телем проекта и исполните­лями занимают до 75% вре­мени. Если западные отноше­ния строятся на юридической регламентации, то в России часто возникают конфликты сторон.

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

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

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

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

Стали расти и объемы фи­нансирования, расходуемые на управление проектами.

Несмотря на успехи в облас­ти проектного управления, объемы роста еще значитель­ны - по данным Междуна­родной ассоциации управле­ния проектами и Венского университета экономики и бизнес-администрирования за 2002-2003 годы, в России методы управления применя­лись не более чем в 5% про­ектов. В то же время, соглас­но исследованиям компании Interthink, в США и Канаде этот показатель порой дости­гает 98%, а в Западной Евро­пе - 50%. Единственное, что, пожалуй, объединяет россий­ские и западные методы и подходы к управлению про­ектами, это выбор инстру­ментария для обслуживания, планирования и исполнения проектов. Информационных систем для решения всех этих задач существует много, они довольно функциональ­ны и в каждой есть какая-то своя изюминка.

ИНСТРУМЕНТАРИЙ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

Вендоры (SAP, Oracle, BAAN, Microsoft и др.) вклю­чают в свои продукты собст­венные технологии управле­ния проектами, чтобы захва­тить дополнительные ры­ночные ниши. А также пото­му, что это модно... С точки зрения официального уп­равления проектами эти компоненты почти всегда неполноценны, упрощены. Они ориентированы на ин­терфейсное взаимодействие с другими модулями, в пер­вую очередь системой фи­нансов. По этому принципу организованы решения SAP; аналогичные модули есть и в некоторых других подоб­ных ERP-системах. Методика Oracle PJM, являющаяся со­ставной частью методологии разработки информацион­ных систем Oracle Method, напротив, представляет со­бой вполне проработанную систему, основанную на стандарте PMI; она доста­точно полно учитывает осо­бенности проектных подхо­дов к разработке программ­ного обеспечения. В резуль­тате Oracle PJM предлагает идти от ресурсов - количе­ства людей в команде ис­полнителя.

Что касается Microsoft Project, применяемого ныне многими российскими ком­паниями, то до версии 2002 года этот пакет мало опирал­ся на современную методо­логию управления проектами и существенно проигрывал многим конкурентам на рын­ке. В версии Microsoft Pro­ject 2002 (и выше) появи­лись функции, реализующие системный подход к управ­лению проектами: компания Microsoft предложила свою собственную концепцию уп­равления проектами Enter­prise Project Management (ЕРМ), в которой предусмот­рено многоуровневое управ­ление отдельными задачами, проектами, портфелями про­ектов и общей стратегией предприятия.

Впрочем, если вниматель­но изучить эти методики, то обнаружится, что все они со­гласуются со сводом знаний по управлению проектами Project management body of knowledge, основным инфор­мационным ресурсом PMI, -в них применены одинако­вые жизненные циклы про­ектов, функции и процессы управления проектами; а различия лишь терминологи­ческие.

УСПЕХ БУДЕТ ПРЕДСКАЗУЕМ
Независимо от того, какие подходы применяются при исполнении проекта, успех состоит не только из количе­ственных, но и из качествен­ных факторов. Если управле­ние портфелем проектов вписывается в стратегию роста компании, процесс уп­равления проектами после­дователен, детализирован и понятен всем участникам, применяемые для контроля и учета инструментальные средства основаны на уста­новленных в компании пра­вилах, процедурах и систе­мах, а интернет-технологии задействованы в повседнев­ных операциях по управле­нию и контролю, то с боль­шой вероятностью проект не только будет завершен, но и станет успешным.

МЕЖДУ PMI И IPMA

Сформировавшийся в 70-х годах прошлого века PMI -это системный или "процессорный" подход к управлению проектами, наибольшую популярность получивший в Аме­рике. Благодаря ему, собственно, и появился такой вид дея­тельности, как управление объектами. Позднее, уже в 1980-е годы, PMI дополнялся и совершенствовался, хотя суть мето­да - представить человеческую деятельность в виде техниче­ской модели - не менялась. Недостатком метода является его ограниченность: механистическое представление проекта и проектной деятельности в целом затрудняло реализацию многих бизнес-процессов, в которых главную роль играл че­ловеческий фактор. В 1990-х годах многие компании пере­шли на другую модель управления - IPMA.

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

В рамках PMI и IPMA различаются и уровни подготовки специалистов. Если для PMI предусмотрена одноуровневая сертификация (в последнее годы для руководителей и мене­джеров проектов появился и второй уровень сертифика­ции), то в IPMA используется четырехуровневая система сер­тификации (на уровне специалиста - D и С, и на уровне ме­неджера проекта - В и С).

БИЗНЕС-РИСКИ ОБЩЕМИРОВОГО МАСШТАБА

При планировании очередного бизнес-проекта составля­ется перечень специфических рисков и ищутся способы, как их избежать; в большинстве случаев можно прогнозировать риски, которые возникают при взаимодействии заказчика и исполнителя. Однако существует ряд глобальных угроз для мирового бизнеса. Они были названы компанией PwC на Всемирном экономическом форуме, проходившем в январе 2004 года в Давосе. Терроризм всего за два с небольшим го­да, прошедших после 11 сентября 2001-го, перестал быть главной угрозой бизнесу. По прошлогодним исследованиям, на первые места вышли государственное регулирование, рост конкуренции и неустойчивость валют (впрочем, недав­ние события - теракты в Америке, Европе и России - снова сделали проблему терроризма актуальной).

В России к этому списку добавились еще низкий уровень корпоративного управления и непрозрачность компаний, а также возникшие в 2003 году (из-за событий с "ЮКОСом") политический риск и риск деприватизации.

ПРОЕКТНОЕ УПРАВЛЕНИЕ

Компаний-внедренцев сегодня довольно много, но все их можно разделить на две категории. Первую группу составят фирмы, которые занимаются непосредственно внедрением управления проектами у клиента, - как правило, это неболь­шие предприятия, ориентированные именно на данный вид деятельности. Ко второй категории относятся компании, применяющие управление проектами в своем бизнесе. В процессе выполнения долгосрочных и крупных проектов они неизбежно внедряют проектный подход и у клиента. Та­ковы, например, "Микротест", "АйТи" и TopS Business Integration.

ОПЫТ "МИКРОТЕСТА"

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

Система управления проектами в "Микротесте" построе­на на базе Microsoft Project Server - этот продукт выбран ис­ходя из сложности исполняемых проектов, их бюджетов, объемов, а также возможностей современных серверных платформ. Кроме того, данная проектная система легко ин­тегрируется с офисными и финансовыми приложениями.

При исполнении проекта затраты на управление рассчи­тываются по принятым в Европе принципам: расходы со­ставляют 5-10% от стоимости контракта. Опыт "Микротеста" в управлении проектами был весьма успешен за последние 5 лет. Дифференцированные подходы позволяли укладываться в треугольник "требования - цена - время", однако бывали случаи, когда компания "Микротест" бралась за проекты, ко­торые с точки зрения управления проектами были неиспол­нимы в заданное время, но в процессе исполнения сдвига­лись сроки реализации по согласованию с заказчиком.

ОПЫТ "АйТи"

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

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

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

Что касается выбора информационных систем, то в "АйТи" отдано предпочтение продуктам IBM и Microsoft. Для докумен­тооборота применяется Lotus Notes, а для непосредственного управления проектами - Microsoft Project 2002. Эти системы хорошо интегрированы между собой и позволяют согласо­ванно управлять разными процессами.

Одним из основных индикаторов эффективности данного направления служит разработанная и внедренная система уп­равления качеством компании "АйТи", сертифицированная на соответствие международному стандарту ISO 9001 в области проектирования, построения и сопровождения интегриро­ванных информационно-вычислительных комплексов. Чет­кая организация проектных работ, построенная в соответст­вии с мировыми стандартами, и использование промышлен­ных средств управления проектами, управления требования­ми, автоматизированного тестирования и т.д. обеспечивают:
  • полный контроль за ходом исполнения проекта и пред­сказуемость его результатов;
  • возможность оперативного внесения изменений во вне­дряемое решение в соответствии с бизнес-задачами;
  • повышение управляемости простых, комплексных и тер­риториально распределенных проектов;
  • повышение скорости принятия и исполнения решений в ходе проекта;
  • улучшение основных метрик процессов управления про­ектами и, как итог, повышение базового показателя ROI.

ОПЫТ TOPS BUSINESS INTEGRATION

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

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

По словам Бориса Коновалова, вице-президента компа­нии TopS BI, до недавней поры каждый ИТ-проект, внедряе­мый TopS, выполнялся, как правило, в рамках отдельного подразделения, состоявшего из нескольких экспертов-"предметников". Но когда у крупных компаний, с которыми рабо­тает TopS, появилась потребность в интеграционных проек­тах, объединяющих внедрение ERP-систем и одновремен­ную разработку дополнительных модулей ИТ-системы, руко­водить ими было поручено вновь созданному центру управ­ления проектами, которому подчинялись различные подраз­деления.

Изменился и подход к построению информационных си­стем для управления проектами. Чтобы можно было разгова­ривать с заказчиком "на одном языке", проводится предпроектное обследование (анализируется архитектура ИТ-системы заказчика, включая ЛВС, серверы, телекоммуникацион­ное оборудование, приложения, способы передачи данных и т.д.), после чего проектные документы адаптируются.

Из набора предлагаемых вендором методик управления в TopS выбираются и адаптируются процедуры, необходимые для выполнения текущего проекта. Как правило, все много­образие документов и отчетных форм, которые доступны в Oracle PJM, на практике не используется, а их подготовка в полном объеме отнимает слишком много драгоценного проектного времени.

Центральный федеральный округ