<<
>>

Управление ИТ-проектами в холдинге: подходы и рекомендации

Типы управления ИТ в холдинге

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

Их применение в значительной мере зависит от методов управления холдингом в целом.

Если руководство холдинга последовательно придерживается политики создания самостоятельных бизнес-единиц из своих дочерних предприятий, то, очевидно, говорить о жестко централизованной структуре управления как холдингом, так и ИТ-услугами в нем не имеет смысла. Принципы управления в таком холдинге едины для всех сегментов управления. На их основе строится политика корпорации в этой области. Подобный подход можно наблюдать во многих мировых холдингах — Boeing, Microsoft, Volkswagen и других участниках рейтинга «Тор 500» журнала «Forbes».

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

Жесткая централизация

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

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

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

Распорядителем ИТ-бюд- жета становится руководитель Департамента ИТ.

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

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

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

Децентрализованная структура

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

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

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

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

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

Мягкая централизация

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

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

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

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

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

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

Практика показывает, что принцип мягкой централизации является наиболее перспективным для развивающихся сегодня в России холдингов. Поэтому необходимо остановиться подробнее на таких вопросах, как распределение основных функций по управлению ИТ для этого варианта между Департаментом ИТ холдинга, ИТ-службами дочерних предприятий и руководством холдинга, первоочередные стандарты предприятия, руководство и требования к деятельности по управлению ИТ. Для этого воспользуемся рекомендациями международного стандарта ISO/IEC 15288 [2], определяющего процессы управления жизненным циклом системы.

Политика информатизации

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

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

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

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

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

Общие процессы управления Управление инвестициями

Процесс управления инвестициями охватывает следующие области (см. рис. 7.7): определение и инициация — они необходимы для развития проектов в области ИТ; обеспечение их адекватного финансирования; контроль их результатов; определение возможности их продолжения и развития.

Процесс управления инвестициями включает следующие этапы.

Шаг 1. Разработка стратегии информатизации предприятия (ИТ-стра- тегии), определяющей состояние информационной системы в отдаленной перспективе и планы реализации в горизонте годового планирования. ИТ-стратегия закрепляется в соответствующем согласованном с дочерними предприятиями документе, в создании которого они принимают непосредственное участие.

Шаг 2.

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

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

Шаг 4. Департамент ИТ консолидирует планы дочерних предприятий и выносит итоговый документ на Комитет по инвестициям для включения проектов в инвестиционный портфель.

Шаг 5. Комитет по инвестициям утверждает инвестиционный портфель ИТ-проектов.

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

Шаг 7. Консолидированный бюджет ИТ утверждается советом директоров холдинга.

Управление ИТ-проектами

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

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

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

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

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

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

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

Управление ресурсами

Этот процесс обеспечивает процессы и проекты необходимым персоналом.

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

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

Управление закупками

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

При выборе поставщика основным руководящим документом для ИТ-службы являются рекомендации по выбору подрядчиков и постав

щиков. Роль Департамента ИТ в процессе закупки — согласующая. Осуществляет закупку7 ИТ-служба дочернего предприятия.

Резюмируя анализ организации управления ИТ-услугами в холдингах, приведем две таблицы. Первая (см. табл. 7.5) фиксирует распределение функций управления ИТ в холдинге между аппаратом управления, Департаментом ИТ и ИТ-службами дочерних предприятий, а во второй (см. табл. 7.6) представлен список первоочередных руководящих документов по управлению ИТ в холдинге. Все эти результаты получены на основе моделей процессов управления ИТ, определенных в стандарте ISO/IEC 15288.

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

Таблица 7.5. Распределение функций управления ИТ

Функция

Департамент

ИТ

ИТ-служба

Руководство

холдинга

Планирование/бюджетирование

Разработка и корректировка стратегии

¦gt;/

¦gt;/

Утверждение стратегии

¦gt;/

Планирование проектов

¦gt;/

Согласование плана проектов

¦gt;/

Формирование инвестиционного портфеля

¦gt;/

Разработка бюджета

¦gt;/

Согласование и консолидация

бюджетов

¦gt;/

Утверждение бюджета

¦gt;/

Проектный цикл

Запуск проекта

у

Утверждение Устава проекта

¦gt;/

Выполнение проекта

¦gt;/

Согласование проектных решений и аудит хода проекта

Ввод системы в действие

?

Участие в испытаниях

Завершение проекта

У

Оценка результатов проекта

¦gt;/

Защита проекта в Комитете по инвестициям

Таблица 7.5. (окончание)

Функция

Департамент

ИТ

ИТ-служба

Руководство

холдинга

Работа с персоналом

Обучение СТП

Обучение современным ИТ

Проведение совещаний с руководством ИТ-служб

/>

Подбор руководящего персонала

Согласование кандидатур

Проведение аттестации руководителей ИТ-служб

Эксплуатация и сопровождение

Организация эксплуатации и сопровождения

Обучение пользователей

Мониторинг проблем

Формирование отчетности по проблемам

7

Закупка

Формирование спецификации

Выбор поставщика

Согласование закупки

Осуществление закупки

Таблица 7.6. Руководящие документы по управлению ИТ в холдинге

Документ

1

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

2

Требования к обоснованию проектов в области ИТ

3

Структура и форма бюджета развития ИТ

4

Стандарт управления проектами в области ИТ

5

Рекомендации по выбору подрядчиков и поставщиков

6

Стандарт по инфраструктуре ИТ

7

Лицензионная политика

8

Требования по интеграции информационной системы предприятия

9

Методики и регламенты сопровождения и эксплуатации информационной системы

10

Типовая структура ИТ-службы и требования к персоналу

11

Методика проведения аудита информационных систем предприятий

7.6. Повесть о настоящем проекте

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

Предпосылки проекта

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

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

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

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

Предложение корпорации IBM, имеющей большой опыт по созданию ИС для центральных и коммерческих банков во всем мире, было принято к реализации в Иркутске. Для выполнения проекта корпорация IBM привлекла ряд субподрядчиков из США и Западной Европы. В соответствии с обоюдным желанием сторон был заключен контракт на полную системную интеграцию — создание системы «под ключ»

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

Участники проекта и их цели

В роли организации-заказчика выступило ГУ ЦБ РФ по Иркутской области — структура по своей сути сугубо операционная и строго иерархическая.

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

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

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

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

Роли и распределение ответственности

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

Руководителем (менеджером) проекта с основным местом работы в Иркутске также стал представитель IBM UK Б. Торнтон.

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

управление субподрядчиками, представители которых являлись менеджерами соответствующих подпроектов; взаимодействие с заказчиком вплоть до уровня высшего руководства; подготовка и проведение совещаний по управлению проектом; самостоятельное решение текущих вопросов, касающихся управления проектом как в IBM, так и у субподрядчиков и заказчиков, поставок оборудования и программного обеспечения, выполнения монтажных и пусконаладочных работ, обучения обслуживающего персонала и конечных пользователей; общее руководство подготовкой и согласованием проектной документации, приемочными испытаниями системы и ее частей, развертыванием и внедрением системы по Иркутскому региону (22 РКЦ, в том числе в таких отдаленных точках, как Мама и Бодайбо), запуском в эксплуатацию, поддержкой и развитием; обеспечение безопасности членов команды проекта (в первую очередь граждан других стран) в Иркутске; согласование возникающих вопросов с представителями местных и центральных властей, например в соответствии с действовавшим законодательством вопросы по защите информации согласовывались с ФАПСИ и т. п.; управление персоналом команды (численный состав команды проекта доходил до 30 человек); управление коммуникациями и конфликтами как в команде проекта, так и в проекте в целом.

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

Руководители проекта, занимавшиеся подбором кандидатов, пригласили одного из авторов этой книги (А. Товба) в команду управления проектом сначала в качестве стажера, а впоследствии — заместителя руководителя проекта («соруководителя» — project manager counterpart) [20]. Со временем в IBM сочли возможным и целесообразным, чтобы А. Товб сменил на позиции руководителя проекта своего наставника Дж. Кларка, который к тому времени стал одним из опытнейших профессионалов IBM UK.

Команда проекта

Команда проекта состояла из временно привлеченных специалистов и «костяка» (команды управления проектом), куда вошли: директор проекта; руководители проекта от IBM и заказчика; системный архитектор (главный конструктор) от IBM; ведущие технические эксперты от IBM (по направлениям); руководители подпроектов от IBM, субподрядчиков и заказчика; администраторы проекта; переводчики.

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

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

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

Предметная область

Автоматизированная информационная банковская система ГУ ЦБ РФ по Иркутской области включала в себя следующие основные функциональные подсистемы: подсистему ввода и учета данных о платежах в РКЦ на базе специально разработанного программного обеспечения компании Arkansas Systems; подсистему передачи данных о платежах по коммутируемым и выделенным телефонным и спутниковым каналам связи; подсистему пакетного клиринга платежей в РЦИ также на базе программного обеспечения Arkansas Systems, специально доработанного для соответствия требованиям ЦБ РФ; подсистему бухгалтерского учета платежей в РЦИ на основе пакета Equation 3 компании Kapiti, доработанного (были осуществлены его адаптация, кастомизация и настройка) с целью полного соответствия требованиям ЦБ РФ;

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

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

В проекте использовались в необходимом объеме принятые в IBM технологии управления проектами, предусмотренные методологией MITP [16] фирмы IBM.

Применялись планирование по вехам (контрольным точкам) и календарно-сетевое планирование с использованием MS Project. Все проектные планы сохранялись в центральном проектном архиве как в виде твердых копий, так и в виде машинных файлов.

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

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

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

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

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

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

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

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

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

бизнеса, приходилось преодолевать множество других проблем

«гуманитарного» характера, как то: языковой барьер (в IBM не предполагали, что знание английского языка у наших соотечественников так сильно отстает от общеевропейского уровня); культурные различия, например, один из участников проекта, утром вылетев из солнечной Лозанны, а на рассвете прилетев в Иркутск и впервые в жизни увидев в центре города на фоне белого снега темные сибирские избы, серьезно и изумленно спросил: «Is it the same planet?» («Это все та же планета?»); разница в деловой культуре (например, принципиально разное отношение к взятым обязательствам, к данному слову и т. д.); социальные различия (уровень доходов и стиль жизни специалистов заказчика и исполнителя порой были просто несопоставимыми); психологические проблемы (например, россияне иногда демонстрировали неожиданные «выпады», которые можно объяснить латентными пережитками шовинизма, ксенофобии и даже расизма, вперемешку с тем, что когда-то называли «низкопоклонство»); различия образовательные, технические и т. д.

3. Территориальная отдаленность от основного места жительства (как правило, участники проекта три недели проводили в Иркутске, одну неделю — дома).

Вместе с тем следует отметить и факторы, способствовавшие успешному завершению проекта: Творческое и последовательное внедрение отработанной IBM методологии управления проектами MITP. Активная позиция заказчика, действительно заинтересованного в результатах, который хотел и сумел сыграть определяющую роль в успехе проекта. Особенно велика в этом отношении роль высшего руководства. Высокий профессионализм участвовавших в проекте специалистов ЦБ РФ. Продуманная и правильно выстроенная IBM система ролевых функций и ответственности руководителей, делегирования полномочий и соответствующая схема поощрений руководителей по результатам выполнения ключевых работ. Атмосфера равноправного и конструктивного партнерства, которая способствовала взаимопониманию и успешной реализации проекта. Максимальная сосредоточенность персонала на выполняемой работе (люди трудились по 12—14 ч в сутки без выходных), чему в немалой степени способствовало их вынужденное пребывание вне дома.

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

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

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

Проект был завершен успешно. Все поставленные цели были достигнуты в рамках бюджета. Автоматизированная банковская система ГУ ЦБ РФ по Иркутской области была сдана в эксплуатацию в 1995 г. и успешно работала в течение нескольких лет.

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

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

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

Участие в проекте, который и через много лет после его завершения [17] не утратил для его участников свою значимость, стало для автора важной ступенькой в профессиональной карьере.

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

Литература ГОСТ 34.201-89. Комплекс стандартов и руководящих материалов на автоматизированные системы. УДК 65.015.13.011.56:006.354 ISO/IEC 15288 Life Cycle Management — System Life Cycle Processes. CobIT: Executive Summary / 1SACA, 3d ed. 2000 (неофициальный перевод на русский язык, выполненный Рабочей группой ISACA.ru, доступен на сайте www.isaca.ru). Ципес Г., Терентьев Е., Циперман Г. Проекты и процессы в деятельности ИТ-службы //Директор информ. службы. 2006. № 6.

Циперман Г. Кризис информационных технологий // iBUSINESS. 2001. № 4. Циперман Г., Ципес Г. А кому сейчас легко? // Директор информ. службы. 2003. № 6. Овербай С. Сотрудники во власти стресса //' Директор информ. службы. 2003. № 6. Циперман Г., Ципес Г. Политические аспекты внедрения корпоративных информационных систем // Сб. трудов IV Всерос. практ. конф. «Стандарты в проектах современных информационных систем», Москва, 21—22 апреля 2004 г. М.: ФОСТ АС, 2004. Циперман Г., Ципес Г. BSC для СЮ // Директор информ. службы. 2004. № 6. Шраге М. Ключ к инновациям: преодоление сопротивления // Директор информ. службы. 2006. № 2. Калган Р., Нортон Д. Сбалансированная система показателей. От стратегии — к действию / Пер. с англ. М.: ЗАО «Олимп—Бизнес», 2003. Ципес Г. Ключевые показатели деятельности в проектно-ориентированной компании // Директор информ. службы. 2003. № 5. Товб А., Ципес Г. Управление проектами: стандарты, методы, опыт. М.: ЗАО «Олимп—Бизнес», 2003. Болдырева Ю., Ципес Г. Управление персоналом: взгляд сквозь призму стратегии // Управление человеческим потенциалом. 2005. № 4. Мензано Р. Управление портфелем приложений предприятия // Директор информ. службы. 2003. № 4. Ципес Г. ИТ-проекты в портфелях и программах // Директор информ. службы. 2003. № 4. Циперман Г. Н., Ципес Г. Л. Проектное управление для CEO. Практические рекомендации // iBUSINESS. 2001. № 1-2. Аншина М. У страха глаза велики // Директор информ. службы. 2003. №11. Циперман Г. О пользе разумной централизации // Директор информ. службы. 2003. № 11. Товб А. Повесть о настоящем проекте // Директор информ. службы. 2001. №4.

<< | >>
Источник: Ципес Г. Л., Товб А. С.. Менеджмент проектов в практике современной компании. 2006

Еще по теме Управление ИТ-проектами в холдинге: подходы и рекомендации:

  1. Плюсы и минусы постановки маркетинга в холдинге Какими бывают холдинги
  2. Подход к управлению качеством проекта
  3. УПРАВЛЕНИЕ ПРОЕКТОМ СЕГОДНЯ - ИНТЕГРИРОВАННЫЙ ПОДХОД
  4. 12.4. Организационно-финансовый механизм управления холдингом
  5. Управление целевыми программами в управляющей компании холдинга ТЭК
  6. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОГО ПРОЕКТА
  7. Рекомендации по совершенствованию практики эмиссий: сегментированный подход
  8. Глава 6 Проекты и деньги. Бюджетирование и финансирование проектов в органах государственного управления
  9. 5.1 .Холдинги
  10. ОБЩИЕ РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ КОНФЛИКТАМИ
  11. Рекомендации по управлению конфликтом
  12. Методические рекомендации по обеспечению эффективного управления стоимостью компании
  13. 3.3. Современные подходы куправлению проектом
  14. 4.1. Жизненный цикл проекта и подходы к его структуризации
  15. Глава 5 Проекты и стандарты. Стандарт управления проектами строительной компании
  16. 4.5. Стратегии в антикризисном управлении предприятием малого бизнеса и рекомендации по повышению эффективности деятельности
  17. ГЛАВА 2. МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ ПРИ ОЦЕНКЕ ИННОВАЦИОННЫХ ПРОЕКТОВ КОММЕРЧЕСКИМ БАНКОМ
- Антикризисное управление - Деловая коммуникация - Документоведение и делопроизводство - Инвестиционный менеджмент - Инновационный менеджмент - Информационный менеджмент - Исследование систем управления - История менеджмента - Корпоративное управление - Лидерство - Маркетинг в отраслях - Маркетинг, реклама, PR - Маркетинговые исследования - Менеджмент организаций - Менеджмент персонала - Менеджмент-консалтинг - Моделирование бизнес-процессов - Моделирование бизнес-процессов - Организационное поведение - Основы менеджмента - Поведение потребителей - Производственный менеджмент - Риск-менеджмент - Самосовершенствование - Сбалансированная система показателей - Сравнительный менеджмент - Стратегический маркетинг - Стратегическое управление - Тайм-менеджмент - Теория организации - Теория управления - Управление качеством - Управление конкурентоспособностью - Управление продажами - Управление проектами - Управленческие решения - Финансовый менеджмент - ЭКОНОМИКА ДЛЯ МЕНЕДЖЕРОВ -