Практически в любой современной организации мы можем наблюдать тесное переплетение информационных технологий и бизнес-процессов основной деятельности. Поэтому внедрение (замена) информационной системы оказывается серьезным преобразованием, зачастую затрагивающим разнообразные сферы деятельности предприятия. Как следствие, во многих случаях оно становится сложным и болезненным процессом. Тем не менее проблемы, возникающие при внедрении системы, уже достаточно хорошо изучены, и в настоящее время созданы эффективные методики их решения, объединенные в соответствующих стандартах (методологиях).
Начиная рассматривать вопросы, связанные с организацией внедрения информационных систем, следует прежде всего уточнить значение термина "информационная система". К сожалению, до сих пор под информационной системой зачастую подразумевают программный пакет, что совершенно не соответствует истине и не позволяет сформировать правильное представление о задачах проекта внедрения.
Информационная система представляет собой сложный комплекс разнородных составляющих, которые взаимодействуют между собой и создают необходимые потребителю свойства системы. Для целей настоящей книги информационную систему следует рассматривать как всю инфраструктуру предприятия, задействованную в процессе управления информационно-документальными потоками и включающую в себя:
технологические элементы, обеспечивающие функционирование системы:информационную модель предметной области;
кадровые ресурсы, отвечающие за формирование и развитие информационной модели;
программный комплекс;
кадровые ресурсы, отвечающие за конфигурирование программного комплекса;
аппаратно-техническую базу;
эксплуатационно-технические кадровые ресурсы;
управленческие элементы, обеспечивающие организацию эксплуатации системы:регламент развития информационной модели и правила внесения в нее изменений;
регламент технической и пользовательской поддержки программного комплекса;
регламент внесения изменений в конфигурацию программного комплекса и состав его функциональных модулей;
регламент использования программного комплекса и пользовательские инструкции;
регламент обучения и сертификации пользователей.
Общая характеристика проектов внедрения информационных систем
Задача проекта внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию всех перечисленных выше элементов. О сложности этой задачи свидетельствует известная из результатов исследований Standish Group неутешительная статистика по успешности ИТ-проектов: в 1998 году только 26% проектов завершились в срок, не превысили бюджет и обеспечили реализацию предусмотренных функций.
Источники проблем при внедрении информационной системы охватывают различные аспекты частного проекта и деятельности компании в целом. К ним можно отнести:
отсутствие постановки менеджмента на предприятии;
необходимость в частичной или полной реорганизации структуры предприятия;
необходимость изменения технологии бизнеса в различных аспектах;
сопротивление сотрудников предприятия;
временное увеличение нагрузки на сотрудников во время внедрения системы;
необходимость в формировании квалифицированной группы внедрения и сопровождения системы, выбор сильного руководителя группы.
Кроме того, в процессе внедрения существует необходимость в реализации единой ИТ-стратегии предприятия, которая позволит адекватно сочетать развитие (создание) программной и аппаратной частей системы параллельно с комплексом работ по развитию существующей ИТ-инфраструктуры компании.
Значительная часть проблем проектов внедрения обусловлена довольно типичными ошибками, которые известны, но тем не менее часто повторяются:
проектирование систем без учета стратегии развития бизнеса — необходимо представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года , ;
нарушение принципа построения системы "сверху-вниз" и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления;
чрезмерное увлечение реинжинирингом бизнес-процессов и порой неоправданное их подчинение требованиям стандартной функциональности базовой ERP-системы;
кардинальная переработка базовой функциональности ERP-системы;
нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.
В то же время накопленный опыт внедрения информационных систем свидетельствует о наличии устойчивой группы факторов успеха таких проектов , и, как следствие, о возможности формирования технологии успешного управления проектом внедрения с учетом этих факторов (рис 1.1). Рациональная организация проектов внедрения информационных систем описывается в стандартах (международных, государственных, корпоративных), которые часто называют методологиями внедрения.
(рис 1.1) Факторы успеха проекта внедренияНазначение и состав методологий внедрения
Методологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками;
а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший
опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:
разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";
разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";
разработки компании Oracle - комплекс методологий "Oracle Method".
Такое разнообразие стандартов позволяет организациям выбрать на их основе рациональную стратегию и сформировать собственные процедуры внедрения, т. е. не "изобретать велосипед" и в то же время обеспечить конкурентные преимущества. Адаптация методологий к нуждам конкретного предприятия заключается не столько в переводе текстов и шаблонов документов на русский язык, сколько в корректировке подходов с учетом российских условий. При этом обычно пересматриваются рекомендуемые стандартами сроки и последовательность задач, создаются методики сбора, верификации и преобразования исходных данных, разрабатываются решения по интеграции с унаследованными системами.
Для Заказчика информационной системы основными результатами использования методологии являются:
создание решения, оптимально соответствующего требованиям клиента;
максимально эффективное использование ресурсов проекта;
минимизация сроков и затрат на внедрение;
уменьшение рисков проекта.
В то же время организация работы в соответствии с документально зафиксированной методологией оказывается полезной и для разработчика системы:
появляется методическая база для обучения новых сотрудников стандартным методам внедрения;
сокращаются внутренние расходы на организацию и реализацию проектов;
улучшается взаимодействие и взаимопонимание между членами проектной группы;
повышается эффективность совместного использования ресурсов между проектами, командами.
Несмотря на разнообразие существующих методологий, их содержание включает в себя следующие компоненты: описание состава и структуры комплекса работ проекта внедрения, правила управления таким проектом, организационную структуру команды внедрения.
Структурирование комплекса работ заключается прежде всего в выделении фаз (этапов) проекта. Разбиение проекта на фазы (длительностью 3-4 месяца) обусловлено высокой сложностью проектов и значительными затратами времени на внедрение информационных систем, позволяет получить значимые результаты в более сжатые сроки и реализовать следующие преимущества в организации проекта:
данные проектной документации не устаревают;
после выполнения каждой фазы проекта появляется возможность уточнить или скорректировать задачи к решению на последующих фазах;
снижаются проектные риски, обусловленные организационными изменениями на предприятии Заказчика в ходе проекта;
оптимизируются бюджет проекта и график платежей.
Состав этапов проекта и распределение работ по этапам зависит от конкретной методологии, однако можно выделить типовой состав этапов, которые в той или иной степени присутствуют во всех методологиях и определяются самой логикой внедрения. Это этапы определения проекта, обследования объекта автоматизации, анализа результатов обследования и разработки дизайна системы, создания (настройки) системы, запуска системы в эксплуатацию, сопровождения системы.
Следующим шагом является выделение процессов (комплексов работ), выполняемых на различных этапах проектов. Состав и последовательность исполнения процессов определяются конкретной методологией и служат основой для планирования проекта - для построения иерархической структуры работ (см. лекцию 4 "Управление интеграцией и содержанием проекта внедрения").
Таким образом, методология внедрения строится как пересечение двух различных областей знаний: специфической технологии создания продукта - информационной системы - и достаточно универсальной технологии управления проектной деятельностью (рис 1.2).
(рис 1.2) Составляющие методологии внедренияСтандарты управления проектами
Организация проектной деятельности осуществляется на основе стандартов управления проектами. Эти стандарты обеспечивают концентрацию лучшей практики в области управления проектами, создают основу взаимодействия между командами проекта, формируют базу для сертификации специалистов в области проектного менеджмента, дают возможность систематизировать знания в этой специфической области. В то же время, стандарты управления проектами обычно не содержат четких определений, как необходимо выполнять те или иные действия. Стандарты определяют, ЧТО должно быть сделано для эффективного управления проектом, а КАК это должно быть сделано, определяется в корпоративных документах, разработанных на основе этих стандартов.
Обычно стандарт фиксирует определения основных понятий предметной области, определяет действующих лиц управления проектами, необходимые области знаний и исполняемые процессы.
Основными действующими лицами проекта являются:
менеджер (руководитель) проекта (Project Manager) - лицо, отвечающее за управление проектом ;
спонсор (куратор) проекта (Project Sponsor) - лицо, обеспечивающее ресурсы проекта и любую административную поддержку ; определяет приоритеты, обеспечивает взаимодействие с функциональными подразделениями, утверждает изменения; во внутренних проектах обычно несет ответственность за результаты проекта;
Заказчик (потребитель) проекта (Project Customer) - лицо внутри или вне организации, которое будет использовать результаты проекта ;
Руководитель функционального подразделения - направляет ресурсы в утвержденные проекты;
Функциональный лидер проекта - объединяет усилия участников проекта в рамках функции или подразделения (именно с ним взаимодействует менеджер проекта);
Лидер пакета работ - объединяет усилия отдельных лиц в рамках пакета работ.
Содержание областей знаний является достаточно сходным в различных стандартах. В настоящей книге мы будем ориентироваться в основном на рекомендации стандарта PMBOK (Project Managment Body Of Knowledge - свод знаний по управлению проектами) американского института ANSI (American Standards Institute), дополняя их, при необходимости, сведениями из других стандартов и методик. В соответствии с этим стандартом управление проектами базируется на следующих областях знаний: Управление интеграцией (Project Integration Management), Управление содержанием (Project Scope Management), Управление временем (Project Time Management), Управление стоимостью (Project Cost Management), Управление персоналом (Project HR Management), Управление коммуникациями (Project Communication Management), Управление качеством (Project Quality Management), Управление рисками (Project Risk Management), Управление снабжением (Project Procurement Management).
В последующих разделах книги будет детально рассматриваться деятельность
по управлению проектами внедрения в рамках указанных областей знаний.
С точки зрения управления, проекты внедрения информационных систем никаких принципиальных особенностей не имеют. Как правило, под термином "проект" подразумевается ограниченный по времени и доступным ресурсам организационный стратегический план для создания уникального продукта или услуги (см. таблицу 1.1). Это определение полностью соответствует представлению о задачах и организации внедрения информационной системы.
Во-первых, процесс внедрения информационной системы носит временный характер, т. е. он всегда имеет определенное начало и окончание. При этом длительность внедрения информационной системы может быть разной, но наступает момент, когда исчезает необходимость в проекте.
Во-вторых, при внедрении информационной системы всегда учитываются особенности бизнес-процессов конкретного предприятия. Это означает, что результат внедрения - информационная система предприятия, - всегда будет отличаться от информационных систем других предприятий, т. е. будет уникальной. Наличие повторяющихся элементов информационной системы не нарушает принципиальной уникальности каждого проекта по внедрению ИС.
В-третьих, для внедрения информационной системы выделяются ресурсы - конкретные специалисты. В реальной жизни количество специалистов требуемой квалификации и компетентности всегда ограничено.
Поэтому имеет смысл рассмотреть общие характеристики проектной организации работ, которые окажутся полезными и при решении задач внедрения информационных систем.
Альтернативные определения проекта
| Определение |
Источник |
|---|
| Временное предприятие (усилие), предназначенное для создания уникальных продуктов, услуг или результатов |
Руководство к своду знаний по управлению проектами (PMBOK Guide 2000) |
Предприятие, которое характеризуется принципиальной уникальностью условий его деятельности (таких как цели (задачи), время, затраты и качественные показатели) и отличается от других подобных предприятий специфической проектной организацией
Предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач
Уникальный набор скоординированных действий с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами исполнения
|
ICB - IPMA (International Competence Baseline - International Project Management Association) |
| Уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый для соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам |
ISO/TR 10006 Guidelines to quality in Project Management |
| Уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели |
AIPM - Australian Institute for PM |
| Уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения |
British standard 6079-1:2000 PM |
Прежде всего, как и для любых проектов, для проекта внедрения принципиально важным является его соответствие целям стратегического развития организации . При создании информационной системы необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить ее потребитель. Если проект ориентирован на нужды Заказчика, то точкой концентрации усилий и оценкой успешности будет бизнес-отдача (business-value).
В качестве примеров конкретных задач внедрения информационных систем управления можно привести следующие:
Предоставление руководству информации для анализа текущего состояния организации и принятия обоснованных управленческих решений.
Обеспечение прозрачности и контроля деятельности предприятия на всех уровнях.
Организация эффективного взаимодействия с контрагентами и клиентами.
Снижение трудоемкости процесса бюджетирования и организация бюджетного контроля расходов.
Сокращение объема ручной и рутинной работы сотрудников, снижение административных издержек.
Снижение вложений в активы, снижение затрат на перемещение материалов, сокращение сроков производства, снижение запасов полуфабрикатов собственного производства.
Снижение потерь рабочего времени, минимизация переналадок, повышение коэффициента готовности оборудования.
Оперативность и точность расчета себестоимости, возможность оперативного анализа затрат, возможность анализа причин отклонений от плана, определение наиболее рентабельных видов продукции.
Второй аспект управления проектами связан с достижением поставленных в проекте целей в рамках выделенного времени и утвержденного бюджета.
Эти задачи решаются за счет организации управления проектом на всех этапах его жизненного цикла. Пример модели жизненного цикла проекта, приведенный на рис 1.3, показывает типичный состав фаз проекта и его связь с процессами проектирования информационной системы. Таким образом, можно сказать, что жизненный цикл разработки нового продукта отражает, что нужно сделать для его создания, а жизненный цикл проекта - как нужно управлять работой.
(рис 1.3) Ступенчато-шлюзовая модель жизненного цикла проекта
Управление проектами базируется на общепринятой :
формирование центров ответственности за исполнение проекта в целом (центров интегративной ответственности);
интегральное и прогнозирующее планирование (и контроль);
формирование и управление командой проекта.
Первая из указанных концепций предусматривает наличие в организации определенных должностей, предполагающих ответственность за выполнение проектов. Наиболее важные роли и сферы их ответственности представлены на рис 1.4.
Каждой из указанных ролей вменяются определенные обязанности по управлению проектами.
На генерального менеджера возлагается:
обеспечение соответствия проектов стратегиям роста организации;
предоставление ресурсов для выполнения утвержденных проектов;
обеспечение применения соответствующих методик управления проектами в компании;
мониторинг общего хода работ по проекту и координация с другими видами деятельности компании;
разрешение конфликтов, для которых не найдены решения на более низком уровне;
оценка качества работы непосредственно подчиненных менеджеров.
(рис 1.4) Участники проекта и их задачиСпонсор проекта:
отвечает за расходование средств, инвестируемых в проект;
определяет бизнес-план проекта;
утверждает цели, содержание, расписание, бюджет проекта и вносимые в них изменения;
издает распоряжения и приказы по проекту, назначает менеджера проекта;
осуществляет мониторинг окружения проекта и информирует МП об изменениях, способных повлиять на выполнение работ;
отслеживает ход выполнения проекта и формирует стратегические указания;
разрешает переадресованные ему конфликты;
обеспечивает соответствие требованиям конечного результата проекта.
Менеджер проекта:
отвечает за получение желаемых результатов в рамках утвержденного бюджета и расписания проекта;
обеспечивает общее планирование и контроль проекта в течение всех фаз жизненного цикла;
взаимодействует с функциональными руководителями для определения объемов, сроков и стоимости (трудозатрат) работ.
Функциональный руководитель подразделения, участвующего в проекте:
отвечает за своевременное обеспечение всех проектов необходимыми ресурсами;
объединяет требования (часто конфликтующие) всех активных проектов в подразделении;
осуществляет детальное планирование работ подчиненного персонала.
В большинстве случаев центральной фигурой в управлении проектом является менеджер проекта. Организация его управленческой деятельности в корне отличается от управления регулярно выполняемыми работами (см. таблицу 1.2) и это учитывается в содержании стандартов управления проектами.
Различия между проектными и функциональными менеджерами
| Менеджер проекта |
Функциональный менеджер |
|---|
| Имеет уникальную цель в каждом проекте, определенную в техническом задании |
Организует регулярное исполнение ряда стабильных функций |
| Руководит проектом, существование которого ограничено во времени |
Руководит постоянно действующим подразделением |
| Управляет временной командой, возможно, изменяющегося состава и двойного подчинения: менеджеру проекта и своему функциональному руководителю |
Управляет относительно стабильным коллективом сотрудников |
| Обычно в подчинении - команда разнопрофильных специалистов |
Как правило, имеет в подчинении группу специалистов одной или смежных специальностей |
| Может не быть специалистом в предметной области проекта |
Обычно разбирается в предметной области лучше всех своих подчиненных |
| По окончании каждого проекта может оказаться "временно безработным" |
Стабильно занимает свою должность |
| Карьера в основном "горизонтальная", рост состоит в управлении все более сложными, масштабными проектами |
Стремится сделать "вертикальную" карьеру, занимая все более высокие посты в своей функциональной сфере |
| Главная мотивация - бонус, зависящий от результатов проекта |
Основная часть мотивации - стабильный, фиксированный оклад |
Концепция интегрального и прогнозирующего планирования означает, что планирование и контроль должны охватывать все участвующие в проекте подразделения в течение всего жизненного цикла проекта и учитывать: расписание проекта, стоимость, риски, технические аспекты создаваемого продукта. Проектная документация должна содержать комплекс взаимоувязанных планов, а процедуры контроля - их регулярную проверку. В качестве примера можно привести комплекс планов проекта, рекомендуемый для использования управления проектом внедрения в методологии MSF:
коммуникационный план;
план разработки;
план обучения;
план мер безопасности;
план тестирования;
план финансирования;
план развертывания;
план закупок и материального обеспечения;
план пилотного внедрения.
И последней составляющей триады концепций является организация работоспособной команды и управление этой командой. Для решения этих задач в каждом проекте предусматривается следующий комплекс работ по управлению человеческими ресурсами: планирование и подбор персонала, формирование команды, развитие команды проекта, управление командой проекта.
Характерные особенности проектных работ
Проекты, независимо от сферы деятельности, обладают целым рядом одинаковых особенностей. ), причем до 90% затрат приходится на этапы разработки-реализации.
(рис 1.5) Типовое распределение затрат времени и ресурсов при выполнении проектаСтепень неопределенности оценок затрат на выполнение проекта изменяется в зависимости от этапа проекта, на котором такая оценка производится, и возможная величина погрешности сильно варьируется в зависимости от предметной области. Для проектов внедрения информационных систем можно воспользоваться "конусом неопределенности", рекомендованным для ИТ-проектов в методологии MSF (см. рис 1.6).
(рис 1.6) Относительные значения погрешности в оценке параметров проектаСтоимость внесения изменений в проект экспоненциально нарастает к концу проекта (см. рис 1.7), а значит, выполнение всех рискованных работ необходимо планировать на ранние стадии проекта.
(рис 1.7) Типовой график нарастания стоимости внесения изменений в проектСледующей общей для всех проектов характеристикой является их зависимость от . Зачастую снижение эффективности проектов, появление трудностей в их реализации связано с тем, что их цели, организация и методы управления несовместимы или конфликтуют с ключевыми элементами окружения. Относительно ИТ-проектов можно выделить следующие элементы окружения, оказывающие на них наиболее существенное влияние: структура организации, степень ее знакомства с используемыми технологиями, конкуренция с другими проектами, местные, региональные и национальные организации, поставщики продуктов и услуг, пользователи результатов проекта.
Менеджеру необходимо перед началом проекта сформировать представление об окружении, организовать взаимодействие с его элементами и отслеживать изменения окружения, происходящие в процессе исполнения проекта.
Обзор окружения может осуществляться в разных формах, от случайного наблюдения до запланированного систематического обследования. Для структурированного представления информации может быть использован шаблон [рис 1.4], показанный на рис 1.8.
(рис 1.8) Шаблон документирования обзора окруженияНа шаблоне вся область окружения делится на секторы - сферы, влияющие на проект. Концентрическими окружностями разделяются группы элементов окружения в зависимости от возможности влияния на эти элементы со стороны проекта.
В соответствующих областях шаблона размещаются обозначения субъектов и факторов, важных с точки зрения проекта.
Под :
руководство - лица, отвечающие либо за выделение бюджета разработки, либо за бюджет организации, где система будет использоваться; ответственные за стратегию развития компании;
инвесторы - лица, которые вкладывают средства в организацию, разрабатывающую или использующую систему;
пользователи - лица, которые непосредственно заинтересованы в возможностях или сервисах, предоставляемых системой; возможно существование таких пользователей, которые не взаимодействуют с системой напрямую, но используют результаты ее работы;
обслуживающий персонал - обеспечивает эксплуатацию системы после запуска;
утилизаторы - обеспечивают соблюдение требований законодательства по защите окружающей среды;
обучающий персонал - организует подготовку специалистов для эксплуатации системы;
покупатели - лица, которые платят за систему, но не участвуют в ее разработке и последующей эксплуатации;
продавцы (маркетологи) - лица, во многом определяющие требования к системам массового спроса;
эксперты по эргономике и эффективности - лица, заинтересованные в удобном и эффективном использовании системы;
правительство - принимает официальные документы органов власти, регулирующие возможности использования системы;
органы стандартизации - принимают стандарты (международные, национальные, корпоративные), влияющие на систему;
общественное мнение - отражает географические и национальные особенности среды создания или применения системы;
регулирующие органы - сертифицируют и разрешают эксплуатацию систем.
Факторы - это элементы окружения, которые не могут совершать действия, но влияют на проект самим фактом своего существования. Примерами факторов являются законы, постановления, традиции, тенденции, экономические, физические или какие-то другие условия и пр.
Для успешности проекта необходимо обеспечить его связи с окружением посредством организационных мероприятий и процедур управления.
К организационным мероприятиям относятся: создание формальных комитетов для координации, планирования и управления проектами; включение основных участников проекта в совет директоров, в группу советников или комитеты заинтересованных организаций; введение в проекте должности менеджера по взаимодействию с ключевыми фигурами окружения.
В процедурах управления целесообразно предусмотреть: приглашение ключевых действующих лиц для участия в совещаниях по проекту; рассылку им копий отчетов по проекту.
Работа менеджера проекта с выявленными факторами окружения предусматривает: учет влияния факторов при планировании и обосновании проекта; мониторинг изменения ключевых факторов и отражение изменений в планах проекта.
Пример специальных мероприятий, направленных на обеспечение взаимосвязи проекта с его окружением, приведен в таблице 1.3.
Взаимодействие проекта с окружением
| Задачи управления проектами |
Мероприятия, направленные на действующих лиц |
Мероприятия, направленные на ключевые факторы |
|---|
| 1. Определение проекта |
Вовлечь действующих лиц в процесс определения; если можно, использовать их идеи; объяснить им суть проекта; определить проблемы и негативные реакции |
Включить первостепенные факторы в допущения планирования, идентифицировать налагаемые ими ограничения, которые влияют на определение проекта |
| 2. Организация и формирование команды |
Установить формальные, рабочие и неформальные отношения с действующими лицами; рассматривать их как членов команды проекта, при необходимости приглашать на совещания по проекту |
Включить влияние факторов в организационную структуру; сообщить членам команды все ключевые факторы и прояснить их влияние на успех проекта |
| 3. Создание плана, расписания и бюджета |
По возможности привлечь действующих лиц к подготовке планов, расписаний и бюджетов; удостовериться, что планы отражают реальность, определяемую ключевыми действующими лицами |
Внести информацию, имеющую отношение к ключевым факторам, в планы, бюджеты и расписания |
| 4. Авторизация работ и начало исполнения |
Постоянно информировать действующих лиц о ходе выполнения проекта, особенно когда операции напрямую влияют на них |
По возможности вести мониторинг факторов во избежание возникновения прямых конфликтов и проблем |
| 5. Контроль исполнения работ, расписания и бюджета |
Постоянно информировать действующих лиц о ходе выполнения проекта, особенно когда операции напрямую влияют на них |
По возможности вести мониторинг факторов во избежание возникновения прямых конфликтов и проблем |
| 6. Оценка хода работ и руководство проектом |
По возможности включить действующих лиц в процесс оценки; заранее предоставлять им информацию об основных изменениях |
Периодически обновлять данные по каждому ключевому фактору и включать их в процесс оценки хода работ |
| 7. Закрытие проекта |
Привлечь действующих лиц к планированию и операциям закрытия; продолжать информирование |
Продолжать следить за факторами и вносить изменения в планы закрытия |
Организационная структура проекта
В управлении проектами важная роль отводится разработке организационной структуры проекта.
Организационная структура проекта - соответствующая проекту временная организационная структура, включающая всех его участников и создаваемая для успешного управления и достижения целей проекта.
Необходимость разработки организационной структуры объясняется тем, что для выполнения проекта создается команда проекта - новый временный рабочий коллектив, состоящий из специалистов различных структурных подразделений компаний со стороны Исполнителя и со стороны Заказчика. Как и для любого нового коллектива, для членов команды проекта необходимо определить проектные роли (временные должности), функции, обязанности, ответственность, полномочия и правила взаимодействия, а также организационную схему, отражающую отношения подчиненности. При этом несущественно, на какой период времени будет создаваться команда проекта - на несколько месяцев или на несколько лет. Структура проекта определяется сложностью, масштабностью разработки и внедрения ИС, количеством и специализацией членов команды проекта. В команду проекта могут включаться специалисты, как на полную, так и на частичную занятость.
Если внедрение информационной системы осуществляется с привлечением сторонней организации - Исполнителя, то для успешного внедрения необходимо сформировать команду проекта не только от Исполнителя, но и от Заказчика, после чего определить допустимые взаимодействия между членами команд Исполнителя и Заказчика (кто, с кем, по каким вопросам взаимодействует), т. е. установить правила взаимодействия.
При формировании организационной структуры проекта и принятии решения о подчиненности следует помнить, что управлять непосредственно более чем десятью членами команды проекта становится затруднительно. Идеальный вариант: пять-семь человек.
Особо отметим, что при создании организационной структуры проекта штатное расписание компании не должно изменяться. Не следует забывать, что проект - временное мероприятие, по окончании которого команда проекта распускается и специалисты приступают к своим функциональным обязанностям в соответствии со штатной организационной структурой компании или переходят на следующий проект, где их функции и полномочия могут быть другими.
Правильно сформированная организационная структура проекта обеспечит его эффективное управление, планирование, исполнение в запланированные сроки, на определенном качественном уровне.
Первая задача в формировании организационной структуры проекта - решить, какой тип структуры наилучшим образом подходит для данного проекта. Различные типы структур имеют определенные преимущества.
Основные типы организационных структур
Функциональная организация (Functional Organization) (рис 1.9). Иерархически выстроенная организация, в которой у каждого сотрудника есть один прямой начальник, сотрудники разделены на группы (отделы) по областям специализации. Каждая группа (отдел) управляется одним человеком, имеющим компетенцию в данной области - функциональным руководителем (руководителем отдела).
(рис 1.9) Линейно-функциональная структура организацииМатричная организация (Matrix Organization) (рис 1.10) - любая организационная структура, в которой Руководитель проекта разделяет с функциональными руководителями (руководителями отделов) ответственность по заданию приоритетов и управлению работой лиц, назначенных на исполнение проекта.
(рис 1.10) Матричная структура организацииПроектная организация (Projectized Organization) - любая организационная структура, в которой Руководитель проекта обладает достаточными полномочиями по установлению приоритетов, использованию ресурсов и руководству работой лиц, назначенных на исполнение проекта, а также финансовыми полномочиями в рамках бюджета проекта.
Для того чтобы понять сущность различных типов организаций, рассмотрим на условном примере, как может быть построена работа по разработке и внедрению ИС при структуре организации, представленной на рис 1.11.
Основные функции отдела Программирования: программирование алгоритмов расчета, анализа данных, интеграционных решений; разработка форм отчетов, разработка экранных форм, работа с базами данных ИС.
Основные функции отдела Бизнес-аналитики: разработка алгоритмов расчета, анализа данных, интеграционных решений, соответствующих бизнес-правилам, требованиям финансового учета и законодательства.
Основные функции отдела Консультаций и настроек ИС: настройка модулей ИС с использованием готовых алгоритмов, экранных форм и отчетов, оказание консультаций пользователям ИС.
Основные функции отдела Маркетинга и продаж: продажи ИС и услуг по ее внедрению.
Организация работ при функциональной структуре компании
При организации внедрения ИС в соответствии с функциональной структурой (рис 1.9), работа, как правило, происходит следующим образом:
После продажи отделом маркетинга и продаж услуг на внедрение информационной системы Руководитель компании проводит совещание с участием руководителей отделов Программирования, Бизнес-аналитики, Консультаций и настроек ИС. Руководитель компании доводит до участников совещания содержание и сроки работ по внедрению, в соответствии с условиями договора. Руководители отделов получают задание организовать работу по выполнению условий договора в рамках компетенций отдела.
Руководители отделов распределяют работу между сотрудниками отделов, контролируют качество и сроки ее выполнения, взаимодействуют с руководителями других отделов по смежным работам и по приему/передаче результатов работ из одного отдела другому. Например, отделом бизнес-аналитики был разработан в соответствии с Трудовым Кодексом РФ алгоритм расчета оплаты труда за ночные часы и праздничные дни. Разработанные алгоритмы передаются в отдел Программирования, где осуществляется программирование алгоритмов расчета. После завершения работ по программированию консультанты отдела Консультаций и настроек ИС проводят общую настройку системы с использованием разработанных алгоритмов расчета.
(рис 1.11) Пример организационной структуры консалтинговой компанииКаждый отдел одновременно может работать по нескольким договорам в рамках своих компетенций. При организации работ проекта по функциональной структуре каждый руководитель отдела отвечает за работы своего отдела и не отвечает за выполнение результатов по проекту-договору в целом. Отсутствие выделенного специалиста, ответственного за итоговый результат, является главным недостатком функциональной структуры. Этот недостаток проявляется тем сильнее, чем большее количество проектов-договоров одновременно выполняются функциональным подразделением и чем больше функциональных подразделений участвует в выполнении проектных работ. Внедрение ИС при таком подходе может происходить как в известной миниатюре артиста А. Райкина - "за рукава костюма отвечает один, за пуговицы - другой, за воротник - третий и т. д., а за костюм никто не отвечает и виновного за брак не найти…".
При построении системы управления проектной деятельностью функциональную структуру целесообразно использовать, если работы по проекту могут быть выполнены одним функциональным подразделением (отделом).
Рассмотрим на том же условном примере организацию работ проекта, но уже не по функциональной, а по матричной структуре (рис 1.10).
Руководитель компании при матричной организации проектных работ назначает ответственного за достижение конечных целей договора и выполнение условий договора - Руководителя проекта (менеджера проекта). Руководителем проекта при матричной структуре может быть назначен один из руководителей отделов. Если нет особых требований и условий, то Руководителем проекта назначается Руководитель того отдела, который выполняет в данном проекте больший объем работ. При этом с Руководителя отдела, назначенного Руководителем проекта, не снимаются функции по управлению отделом. Другими словами, Руководитель проекта при матричной организации может быть частично задействован на проекте (не на 100%), и продолжать выполнять свои функциональные обязанности.
Руководитель проекта анализирует содержание, объем и сроки работ, на основании чего определяет, сколько и каких специалистов нужно для выполнения проекта. Руководитель проекта делает запрос Руководителям отделов на выделение специалистов с указанием их квалификации и процента занятости. В зависимости от объема той или иной работы по проекту, специалисты могут быть выделены как на полную, так и на частичную занятость. После того как специалисты выделены, Руководитель проекта формирует для них задания и координирует работы. Задания Руководитель проекта согласовывает с Руководителем отдела (функциональным руководителем). У выделенного на проектные работы специалиста при матричной организации работ два руководителя - Руководитель отдела и Руководитель проекта. Руководитель проекта, как было сказано выше, отвечает за конечные цели и результат, а Руководитель отдела (функциональный руководитель) несет ответственность только за промежуточный результат в рамках компетенций подразделения (отдела).
Руководители проектов могут принимать решения только по организационным вопросам, функциональные руководители - по техническим (предметным) вопросам.
Достоинство матричной структуры - наличие ответственного за достижение целей проекта, недостаток - два руководителя у одного специалиста (консультанта), что часто приводит к межличностным конфликтам. При возникновении конфликта ресурсов проблема эскалируется вверх по иерархической структуре.
При матричной структуре организации проектных работ Руководитель проекта может быть наделен различной степенью полномочий. В зависимости от степени полномочий Руководителя проекта выделяют слабую, сбалансированную и сильную матричную структуру (таблица 1.4).
Организация работ при проектной структуре компании
При проектной организации работ, так же как и при матричной, для управления работами назначается Руководитель проекта, но занятость его на проекте не частичная, а полная. Специалисты, выделенные для выполнения проектных работ, подчиняются только Руководителю проекта до завершения проектных работ. Руководители отделов (функциональных подразделений), выделивших специалистов на проектные работы, не несут ответственность за качество их работы, в отличие от матричной структуры организации. Исходя из того, что при проектной структуре Руководитель проекта на 100% занят управлением проектом, напрашивается вопрос: а найдется ли такой Руководитель отдела или другой специалист с навыками управления, который бы на время проекта согласился отказаться от своей должности? Ведь для него возникает риск по окончанию проекта оказаться "не у дел". Решение подобной проблемы найдено в том, что в проектных структурах введена специальная должность - Руководитель проекта. В ряде организаций созданы
отделы/департаменты Руководителей проектов, и только из их числа назначаются Руководители проектов. Таким образом, основное отличие проектной структуры компании от матричной - в наличии специально выделенной группы специалистов для управления проектами. Руководитель проекта назначается только из этой группы (отдела, департамента), в проекте он занят на 100% и наделен всеми полномочиями по привлечению и управлению ресурсами, принятию управленческих решений, в том числе и по финансовым вопросам в рамках установленного бюджета.
Управление проектами в различных структурах
| Характеристика проекта |
Структура организации |
|---|
| Функциональная |
Матричная |
Проектная |
|---|
| Слабая |
Сбалансированная |
Сильная |
|---|
| Полномочия руководителя проекта |
Нет |
Ограниченные |
умеренные |
От умеренных до высоких |
От высоких до абсолютных |
| Занятость руководителя проекта |
Нет |
частичная |
полная |
полная |
полная |
Критерии выбора организационной структуры проекта, отвечающей целям и условиям осуществления проектов в конкретной компании, представлены в таблице 1.5.
Критерии выбора организационной структуры проекта
| Критерий выбора |
Функциональная |
Матричная |
Проектная |
|---|
| Решение проекта |
стандартное |
сложное |
новое |
| Сложность |
низкая |
средняя |
высокая |
| Продолжительность |
короткая |
средняя |
большая |
| Масштаб |
малый |
средний |
крупный |
| Важность |
не очень важный |
средней важности |
важный |
Рекомендации по выбору организационной структуры:
Масштабные, долгосрочные и дорогостоящие проекты обычно требуют проектной структуры либо сбалансированной и сильной матричной структуры.
Мелкими, краткосрочными и малозатратными проектами можно управлять с помощью функциональной или слабой матричной структуры.
Матричная структура является оптимальной для большинства проектов, а также хорошим компромиссом между функциональной и проектной структурами.
Организационная схема проекта
После выбора организационной структуры проекта Руководитель проекта должен определить организационную схему, в которой будут отражены взаимосвязи команды проекта, отношения подчиненности.
Пример организационной схемы проекта, состоящей из команды Исполнителя и Заказчика, приведен на рис 1.12.
(рис 1.12) Пример организационной схемы проектаВ организационной схеме проекта с участием двух команд - команды Исполнителя и команды Заказчика - должны быть предусмотрены как формальные, так и неформальные организационные взаимодействия. Формальные взаимодействия всегда обеспечиваются официальными документами, такими как протоколы совещаний, служебные записки, приказы, распоряжения и т. д. Неформальные взаимодействия не должны обеспечиваться документально. Взаимодействия по вертикали управления внутри одной команды: Куратор (Спонсор) проекта - Руководитель проекта - Команда проекта - должны быть формальными и поддерживаться официальными документами. Взаимодействия Руководителей проекта со стороны Заказчика и Исполнителя также должны оформляться официальными документами. Допускаются неформальные взаимодействия между Кураторами проекта и членами команд проекта от Заказчика и Исполнителя (рис 1.13).
(рис 1.13) Пример организации формальных и неформальных взаимодействий
Практически в любой современной организации мы можем наблюдать тесное переплетение информационных технологий и бизнес-процессов основной деятельности. Поэтому внедрение (замена) информационной системы оказывается серьезным преобразованием, зачастую затрагивающим разнообразные сферы деятельности предприятия. Как следствие, во многих случаях оно становится сложным и болезненным процессом. Тем не менее проблемы, возникающие при внедрении системы, уже достаточно хорошо изучены, и в настоящее время созданы эффективные методики их решения, объединенные в соответствующих стандартах (методологиях).
Начиная рассматривать вопросы, связанные с организацией внедрения информационных систем, следует прежде всего уточнить значение термина "информационная система". К сожалению, до сих пор под информационной системой зачастую подразумевают программный пакет, что совершенно не соответствует истине и не позволяет сформировать правильное представление о задачах проекта внедрения.
Информационная система представляет собой сложный комплекс разнородных составляющих, которые взаимодействуют между собой и создают необходимые потребителю свойства системы. Для целей настоящей книги информационную систему следует рассматривать как всю инфраструктуру предприятия, задействованную в процессе управления информационно-документальными потоками и включающую в себя:
технологические элементы, обеспечивающие функционирование системы:информационную модель предметной области;
кадровые ресурсы, отвечающие за формирование и развитие информационной модели;
программный комплекс;
кадровые ресурсы, отвечающие за конфигурирование программного комплекса;
аппаратно-техническую базу;
эксплуатационно-технические кадровые ресурсы;
управленческие элементы, обеспечивающие организацию эксплуатации системы:регламент развития информационной модели и правила внесения в нее изменений;
регламент технической и пользовательской поддержки программного комплекса;
регламент внесения изменений в конфигурацию программного комплекса и состав его функциональных модулей;
регламент использования программного комплекса и пользовательские инструкции;
регламент обучения и сертификации пользователей.
Общая характеристика проектов внедрения информационных систем
Задача проекта внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию всех перечисленных выше элементов. О сложности этой задачи свидетельствует известная из результатов исследований Standish Group неутешительная статистика по успешности ИТ-проектов: в 1998 году только 26% проектов завершились в срок, не превысили бюджет и обеспечили реализацию предусмотренных функций.
Источники проблем при внедрении информационной системы охватывают различные аспекты частного проекта и деятельности компании в целом. К ним можно отнести:
отсутствие постановки менеджмента на предприятии;
необходимость в частичной или полной реорганизации структуры предприятия;
необходимость изменения технологии бизнеса в различных аспектах;
сопротивление сотрудников предприятия;
временное увеличение нагрузки на сотрудников во время внедрения системы;
необходимость в формировании квалифицированной группы внедрения и сопровождения системы, выбор сильного руководителя группы.
Кроме того, в процессе внедрения существует необходимость в реализации единой ИТ-стратегии предприятия, которая позволит адекватно сочетать развитие (создание) программной и аппаратной частей системы параллельно с комплексом работ по развитию существующей ИТ-инфраструктуры компании.
Значительная часть проблем проектов внедрения обусловлена довольно типичными ошибками, которые известны, но тем не менее часто повторяются:
проектирование систем без учета стратегии развития бизнеса — необходимо представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года , ;
нарушение принципа построения системы "сверху-вниз" и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления;
чрезмерное увлечение реинжинирингом бизнес-процессов и порой неоправданное их подчинение требованиям стандартной функциональности базовой ERP-системы;
кардинальная переработка базовой функциональности ERP-системы;
нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.
В то же время накопленный опыт внедрения информационных систем свидетельствует о наличии устойчивой группы факторов успеха таких проектов , и, как следствие, о возможности формирования технологии успешного управления проектом внедрения с учетом этих факторов (рис 1.1). Рациональная организация проектов внедрения информационных систем описывается в стандартах (международных, государственных, корпоративных), которые часто называют методологиями внедрения.
(рис 1.1) Факторы успеха проекта внедренияНазначение и состав методологий внедрения
Методологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками;
а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший
опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:
разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";
разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";
разработки компании Oracle - комплекс методологий "Oracle Method".
Такое разнообразие стандартов позволяет организациям выбрать на их основе рациональную стратегию и сформировать собственные процедуры внедрения, т. е. не "изобретать велосипед" и в то же время обеспечить конкурентные преимущества. Адаптация методологий к нуждам конкретного предприятия заключается не столько в переводе текстов и шаблонов документов на русский язык, сколько в корректировке подходов с учетом российских условий. При этом обычно пересматриваются рекомендуемые стандартами сроки и последовательность задач, создаются методики сбора, верификации и преобразования исходных данных, разрабатываются решения по интеграции с унаследованными системами.
Для Заказчика информационной системы основными результатами использования методологии являются:
создание решения, оптимально соответствующего требованиям клиента;
максимально эффективное использование ресурсов проекта;
минимизация сроков и затрат на внедрение;
уменьшение рисков проекта.
В то же время организация работы в соответствии с документально зафиксированной методологией оказывается полезной и для разработчика системы:
появляется методическая база для обучения новых сотрудников стандартным методам внедрения;
сокращаются внутренние расходы на организацию и реализацию проектов;
улучшается взаимодействие и взаимопонимание между членами проектной группы;
повышается эффективность совместного использования ресурсов между проектами, командами.
Несмотря на разнообразие существующих методологий, их содержание включает в себя следующие компоненты: описание состава и структуры комплекса работ проекта внедрения, правила управления таким проектом, организационную структуру команды внедрения.
Структурирование комплекса работ заключается прежде всего в выделении фаз (этапов) проекта. Разбиение проекта на фазы (длительностью 3-4 месяца) обусловлено высокой сложностью проектов и значительными затратами времени на внедрение информационных систем, позволяет получить значимые результаты в более сжатые сроки и реализовать следующие преимущества в организации проекта:
данные проектной документации не устаревают;
после выполнения каждой фазы проекта появляется возможность уточнить или скорректировать задачи к решению на последующих фазах;
снижаются проектные риски, обусловленные организационными изменениями на предприятии Заказчика в ходе проекта;
оптимизируются бюджет проекта и график платежей.
Состав этапов проекта и распределение работ по этапам зависит от конкретной методологии, однако можно выделить типовой состав этапов, которые в той или иной степени присутствуют во всех методологиях и определяются самой логикой внедрения. Это этапы определения проекта, обследования объекта автоматизации, анализа результатов обследования и разработки дизайна системы, создания (настройки) системы, запуска системы в эксплуатацию, сопровождения системы.
Следующим шагом является выделение процессов (комплексов работ), выполняемых на различных этапах проектов. Состав и последовательность исполнения процессов определяются конкретной методологией и служат основой для планирования проекта - для построения иерархической структуры работ (см. лекцию 4 "Управление интеграцией и содержанием проекта внедрения").
Таким образом, методология внедрения строится как пересечение двух различных областей знаний: специфической технологии создания продукта - информационной системы - и достаточно универсальной технологии управления проектной деятельностью (рис 1.2).
(рис 1.2) Составляющие методологии внедренияСтандарты управления проектами
Организация проектной деятельности осуществляется на основе стандартов управления проектами. Эти стандарты обеспечивают концентрацию лучшей практики в области управления проектами, создают основу взаимодействия между командами проекта, формируют базу для сертификации специалистов в области проектного менеджмента, дают возможность систематизировать знания в этой специфической области. В то же время, стандарты управления проектами обычно не содержат четких определений, как необходимо выполнять те или иные действия. Стандарты определяют, ЧТО должно быть сделано для эффективного управления проектом, а КАК это должно быть сделано, определяется в корпоративных документах, разработанных на основе этих стандартов.
Обычно стандарт фиксирует определения основных понятий предметной области, определяет действующих лиц управления проектами, необходимые области знаний и исполняемые процессы.
Основными действующими лицами проекта являются:
менеджер (руководитель) проекта (Project Manager) - лицо, отвечающее за управление проектом ;
спонсор (куратор) проекта (Project Sponsor) - лицо, обеспечивающее ресурсы проекта и любую административную поддержку ; определяет приоритеты, обеспечивает взаимодействие с функциональными подразделениями, утверждает изменения; во внутренних проектах обычно несет ответственность за результаты проекта;
Заказчик (потребитель) проекта (Project Customer) - лицо внутри или вне организации, которое будет использовать результаты проекта ;
Руководитель функционального подразделения - направляет ресурсы в утвержденные проекты;
Функциональный лидер проекта - объединяет усилия участников проекта в рамках функции или подразделения (именно с ним взаимодействует менеджер проекта);
Лидер пакета работ - объединяет усилия отдельных лиц в рамках пакета работ.
Содержание областей знаний является достаточно сходным в различных стандартах. В настоящей книге мы будем ориентироваться в основном на рекомендации стандарта PMBOK (Project Managment Body Of Knowledge - свод знаний по управлению проектами) американского института ANSI (American Standards Institute), дополняя их, при необходимости, сведениями из других стандартов и методик. В соответствии с этим стандартом управление проектами базируется на следующих областях знаний: Управление интеграцией (Project Integration Management), Управление содержанием (Project Scope Management), Управление временем (Project Time Management), Управление стоимостью (Project Cost Management), Управление персоналом (Project HR Management), Управление коммуникациями (Project Communication Management), Управление качеством (Project Quality Management), Управление рисками (Project Risk Management), Управление снабжением (Project Procurement Management).
В последующих разделах книги будет детально рассматриваться деятельность
по управлению проектами внедрения в рамках указанных областей знаний.
С точки зрения управления, проекты внедрения информационных систем никаких принципиальных особенностей не имеют. Как правило, под термином "проект" подразумевается ограниченный по времени и доступным ресурсам организационный стратегический план для создания уникального продукта или услуги (см. таблицу 1.1). Это определение полностью соответствует представлению о задачах и организации внедрения информационной системы.
Во-первых, процесс внедрения информационной системы носит временный характер, т. е. он всегда имеет определенное начало и окончание. При этом длительность внедрения информационной системы может быть разной, но наступает момент, когда исчезает необходимость в проекте.
Во-вторых, при внедрении информационной системы всегда учитываются особенности бизнес-процессов конкретного предприятия. Это означает, что результат внедрения - информационная система предприятия, - всегда будет отличаться от информационных систем других предприятий, т. е. будет уникальной. Наличие повторяющихся элементов информационной системы не нарушает принципиальной уникальности каждого проекта по внедрению ИС.
В-третьих, для внедрения информационной системы выделяются ресурсы - конкретные специалисты. В реальной жизни количество специалистов требуемой квалификации и компетентности всегда ограничено.
Поэтому имеет смысл рассмотреть общие характеристики проектной организации работ, которые окажутся полезными и при решении задач внедрения информационных систем.
Альтернативные определения проекта
| Определение |
Источник |
|---|
| Временное предприятие (усилие), предназначенное для создания уникальных продуктов, услуг или результатов |
Руководство к своду знаний по управлению проектами (PMBOK Guide 2000) |
Предприятие, которое характеризуется принципиальной уникальностью условий его деятельности (таких как цели (задачи), время, затраты и качественные показатели) и отличается от других подобных предприятий специфической проектной организацией
Предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач
Уникальный набор скоординированных действий с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами исполнения
|
ICB - IPMA (International Competence Baseline - International Project Management Association) |
| Уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый для соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам |
ISO/TR 10006 Guidelines to quality in Project Management |
| Уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели |
AIPM - Australian Institute for PM |
| Уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения |
British standard 6079-1:2000 PM |
Прежде всего, как и для любых проектов, для проекта внедрения принципиально важным является его соответствие целям стратегического развития организации . При создании информационной системы необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить ее потребитель. Если проект ориентирован на нужды Заказчика, то точкой концентрации усилий и оценкой успешности будет бизнес-отдача (business-value).
В качестве примеров конкретных задач внедрения информационных систем управления можно привести следующие:
Предоставление руководству информации для анализа текущего состояния организации и принятия обоснованных управленческих решений.
Обеспечение прозрачности и контроля деятельности предприятия на всех уровнях.
Организация эффективного взаимодействия с контрагентами и клиентами.
Снижение трудоемкости процесса бюджетирования и организация бюджетного контроля расходов.
Сокращение объема ручной и рутинной работы сотрудников, снижение административных издержек.
Снижение вложений в активы, снижение затрат на перемещение материалов, сокращение сроков производства, снижение запасов полуфабрикатов собственного производства.
Снижение потерь рабочего времени, минимизация переналадок, повышение коэффициента готовности оборудования.
Оперативность и точность расчета себестоимости, возможность оперативного анализа затрат, возможность анализа причин отклонений от плана, определение наиболее рентабельных видов продукции.
Второй аспект управления проектами связан с достижением поставленных в проекте целей в рамках выделенного времени и утвержденного бюджета.
Эти задачи решаются за счет организации управления проектом на всех этапах его жизненного цикла. Пример модели жизненного цикла проекта, приведенный на рис 1.3, показывает типичный состав фаз проекта и его связь с процессами проектирования информационной системы. Таким образом, можно сказать, что жизненный цикл разработки нового продукта отражает, что нужно сделать для его создания, а жизненный цикл проекта - как нужно управлять работой.
(рис 1.3) Ступенчато-шлюзовая модель жизненного цикла проектаУправление проектами базируется на общепринятой :
формирование центров ответственности за исполнение проекта в целом (центров интегративной ответственности);
интегральное и прогнозирующее планирование (и контроль);
формирование и управление командой проекта.
Первая из указанных концепций предусматривает наличие в организации определенных должностей, предполагающих ответственность за выполнение проектов. Наиболее важные роли и сферы их ответственности представлены на рис 1.4.
Каждой из указанных ролей вменяются определенные обязанности по управлению проектами.
На генерального менеджера возлагается:
обеспечение соответствия проектов стратегиям роста организации;
предоставление ресурсов для выполнения утвержденных проектов;
обеспечение применения соответствующих методик управления проектами в компании;
мониторинг общего хода работ по проекту и координация с другими видами деятельности компании;
разрешение конфликтов, для которых не найдены решения на более низком уровне;
оценка качества работы непосредственно подчиненных менеджеров.
(рис 1.4) Участники проекта и их задачиСпонсор проекта:
отвечает за расходование средств, инвестируемых в проект;
определяет бизнес-план проекта;
утверждает цели, содержание, расписание, бюджет проекта и вносимые в них изменения;
издает распоряжения и приказы по проекту, назначает менеджера проекта;
осуществляет мониторинг окружения проекта и информирует МП об изменениях, способных повлиять на выполнение работ;
отслеживает ход выполнения проекта и формирует стратегические указания;
разрешает переадресованные ему конфликты;
обеспечивает соответствие требованиям конечного результата проекта.
Менеджер проекта:
отвечает за получение желаемых результатов в рамках утвержденного бюджета и расписания проекта;
обеспечивает общее планирование и контроль проекта в течение всех фаз жизненного цикла;
взаимодействует с функциональными руководителями для определения объемов, сроков и стоимости (трудозатрат) работ.
Функциональный руководитель подразделения, участвующего в проекте:
отвечает за своевременное обеспечение всех проектов необходимыми ресурсами;
объединяет требования (часто конфликтующие) всех активных проектов в подразделении;
осуществляет детальное планирование работ подчиненного персонала.
В большинстве случаев центральной фигурой в управлении проектом является менеджер проекта. Организация его управленческой деятельности в корне отличается от управления регулярно выполняемыми работами (см. таблицу 1.2) и это учитывается в содержании стандартов управления проектами.
Различия между проектными и функциональными менеджерами
| Менеджер проекта |
Функциональный менеджер |
|---|
| Имеет уникальную цель в каждом проекте, определенную в техническом задании |
Организует регулярное исполнение ряда стабильных функций |
| Руководит проектом, существование которого ограничено во времени |
Руководит постоянно действующим подразделением |
| Управляет временной командой, возможно, изменяющегося состава и двойного подчинения: менеджеру проекта и своему функциональному руководителю |
Управляет относительно стабильным коллективом сотрудников |
| Обычно в подчинении - команда разнопрофильных специалистов |
Как правило, имеет в подчинении группу специалистов одной или смежных специальностей |
| Может не быть специалистом в предметной области проекта |
Обычно разбирается в предметной области лучше всех своих подчиненных |
| По окончании каждого проекта может оказаться "временно безработным" |
Стабильно занимает свою должность |
| Карьера в основном "горизонтальная", рост состоит в управлении все более сложными, масштабными проектами |
Стремится сделать "вертикальную" карьеру, занимая все более высокие посты в своей функциональной сфере |
| Главная мотивация - бонус, зависящий от результатов проекта |
Основная часть мотивации - стабильный, фиксированный оклад |
Концепция интегрального и прогнозирующего планирования означает, что планирование и контроль должны охватывать все участвующие в проекте подразделения в течение всего жизненного цикла проекта и учитывать: расписание проекта, стоимость, риски, технические аспекты создаваемого продукта. Проектная документация должна содержать комплекс взаимоувязанных планов, а процедуры контроля - их регулярную проверку. В качестве примера можно привести комплекс планов проекта, рекомендуемый для использования управления проектом внедрения в методологии MSF:
коммуникационный план;
план разработки;
план обучения;
план мер безопасности;
план тестирования;
план финансирования;
план развертывания;
план закупок и материального обеспечения;
план пилотного внедрения.
И последней составляющей триады концепций является организация работоспособной команды и управление этой командой. Для решения этих задач в каждом проекте предусматривается следующий комплекс работ по управлению человеческими ресурсами: планирование и подбор персонала, формирование команды, развитие команды проекта, управление командой проекта.
Характерные особенности проектных работ
Проекты, независимо от сферы деятельности, обладают целым рядом одинаковых особенностей. ), причем до 90% затрат приходится на этапы разработки-реализации.
(рис 1.5) Типовое распределение затрат времени и ресурсов при выполнении проектаСтепень неопределенности оценок затрат на выполнение проекта изменяется в зависимости от этапа проекта, на котором такая оценка производится, и возможная величина погрешности сильно варьируется в зависимости от предметной области. Для проектов внедрения информационных систем можно воспользоваться "конусом неопределенности", рекомендованным для ИТ-проектов в методологии MSF (см. рис 1.6).
(рис 1.6) Относительные значения погрешности в оценке параметров проектаСтоимость внесения изменений в проект экспоненциально нарастает к концу проекта (см. рис 1.7), а значит, выполнение всех рискованных работ необходимо планировать на ранние стадии проекта.
(рис 1.7) Типовой график нарастания стоимости внесения изменений в проектСледующей общей для всех проектов характеристикой является их зависимость от . Зачастую снижение эффективности проектов, появление трудностей в их реализации связано с тем, что их цели, организация и методы управления несовместимы или конфликтуют с ключевыми элементами окружения. Относительно ИТ-проектов можно выделить следующие элементы окружения, оказывающие на них наиболее существенное влияние: структура организации, степень ее знакомства с используемыми технологиями, конкуренция с другими проектами, местные, региональные и национальные организации, поставщики продуктов и услуг, пользователи результатов проекта.
Менеджеру необходимо перед началом проекта сформировать представление об окружении, организовать взаимодействие с его элементами и отслеживать изменения окружения, происходящие в процессе исполнения проекта.
Обзор окружения может осуществляться в разных формах, от случайного наблюдения до запланированного систематического обследования. Для структурированного представления информации может быть использован шаблон [рис 1.4], показанный на рис 1.8.
(рис 1.8) Шаблон документирования обзора окруженияНа шаблоне вся область окружения делится на секторы - сферы, влияющие на проект. Концентрическими окружностями разделяются группы элементов окружения в зависимости от возможности влияния на эти элементы со стороны проекта.
В соответствующих областях шаблона размещаются обозначения субъектов и факторов, важных с точки зрения проекта.
Под :
руководство - лица, отвечающие либо за выделение бюджета разработки, либо за бюджет организации, где система будет использоваться; ответственные за стратегию развития компании;
инвесторы - лица, которые вкладывают средства в организацию, разрабатывающую или использующую систему;
пользователи - лица, которые непосредственно заинтересованы в возможностях или сервисах, предоставляемых системой; возможно существование таких пользователей, которые не взаимодействуют с системой напрямую, но используют результаты ее работы;
обслуживающий персонал - обеспечивает эксплуатацию системы после запуска;
утилизаторы - обеспечивают соблюдение требований законодательства по защите окружающей среды;
обучающий персонал - организует подготовку специалистов для эксплуатации системы;
покупатели - лица, которые платят за систему, но не участвуют в ее разработке и последующей эксплуатации;
продавцы (маркетологи) - лица, во многом определяющие требования к системам массового спроса;
эксперты по эргономике и эффективности - лица, заинтересованные в удобном и эффективном использовании системы;
правительство - принимает официальные документы органов власти, регулирующие возможности использования системы;
органы стандартизации - принимают стандарты (международные, национальные, корпоративные), влияющие на систему;
общественное мнение - отражает географические и национальные особенности среды создания или применения системы;
регулирующие органы - сертифицируют и разрешают эксплуатацию систем.
Факторы - это элементы окружения, которые не могут совершать действия, но влияют на проект самим фактом своего существования. Примерами факторов являются законы, постановления, традиции, тенденции, экономические, физические или какие-то другие условия и пр.
Для успешности проекта необходимо обеспечить его связи с окружением посредством организационных мероприятий и процедур управления.
К организационным мероприятиям относятся: создание формальных комитетов для координации, планирования и управления проектами; включение основных участников проекта в совет директоров, в группу советников или комитеты заинтересованных организаций; введение в проекте должности менеджера по взаимодействию с ключевыми фигурами окружения.
В процедурах управления целесообразно предусмотреть: приглашение ключевых действующих лиц для участия в совещаниях по проекту; рассылку им копий отчетов по проекту.
Работа менеджера проекта с выявленными факторами окружения предусматривает: учет влияния факторов при планировании и обосновании проекта; мониторинг изменения ключевых факторов и отражение изменений в планах проекта.
Пример специальных мероприятий, направленных на обеспечение взаимосвязи проекта с его окружением, приведен в таблице 1.3.
Взаимодействие проекта с окружением
| Задачи управления проектами |
Мероприятия, направленные на действующих лиц |
Мероприятия, направленные на ключевые факторы |
|---|
| 1. Определение проекта |
Вовлечь действующих лиц в процесс определения; если можно, использовать их идеи; объяснить им суть проекта; определить проблемы и негативные реакции |
Включить первостепенные факторы в допущения планирования, идентифицировать налагаемые ими ограничения, которые влияют на определение проекта |
| 2. Организация и формирование команды |
Установить формальные, рабочие и неформальные отношения с действующими лицами; рассматривать их как членов команды проекта, при необходимости приглашать на совещания по проекту |
Включить влияние факторов в организационную структуру; сообщить членам команды все ключевые факторы и прояснить их влияние на успех проекта |
| 3. Создание плана, расписания и бюджета |
По возможности привлечь действующих лиц к подготовке планов, расписаний и бюджетов; удостовериться, что планы отражают реальность, определяемую ключевыми действующими лицами |
Внести информацию, имеющую отношение к ключевым факторам, в планы, бюджеты и расписания |
| 4. Авторизация работ и начало исполнения |
Постоянно информировать действующих лиц о ходе выполнения проекта, особенно когда операции напрямую влияют на них |
По возможности вести мониторинг факторов во избежание возникновения прямых конфликтов и проблем |
| 5. Контроль исполнения работ, расписания и бюджета |
Постоянно информировать действующих лиц о ходе выполнения проекта, особенно когда операции напрямую влияют на них |
По возможности вести мониторинг факторов во избежание возникновения прямых конфликтов и проблем |
| 6. Оценка хода работ и руководство проектом |
По возможности включить действующих лиц в процесс оценки; заранее предоставлять им информацию об основных изменениях |
Периодически обновлять данные по каждому ключевому фактору и включать их в процесс оценки хода работ |
| 7. Закрытие проекта |
Привлечь действующих лиц к планированию и операциям закрытия; продолжать информирование |
Продолжать следить за факторами и вносить изменения в планы закрытия |
Организационная структура проекта
В управлении проектами важная роль отводится разработке организационной структуры проекта.
Организационная структура проекта - соответствующая проекту временная организационная структура, включающая всех его участников и создаваемая для успешного управления и достижения целей проекта.
Необходимость разработки организационной структуры объясняется тем, что для выполнения проекта создается команда проекта - новый временный рабочий коллектив, состоящий из специалистов различных структурных подразделений компаний со стороны Исполнителя и со стороны Заказчика. Как и для любого нового коллектива, для членов команды проекта необходимо определить проектные роли (временные должности), функции, обязанности, ответственность, полномочия и правила взаимодействия, а также организационную схему, отражающую отношения подчиненности. При этом несущественно, на какой период времени будет создаваться команда проекта - на несколько месяцев или на несколько лет. Структура проекта определяется сложностью, масштабностью разработки и внедрения ИС, количеством и специализацией членов команды проекта. В команду проекта могут включаться специалисты, как на полную, так и на частичную занятость.
Если внедрение информационной системы осуществляется с привлечением сторонней организации - Исполнителя, то для успешного внедрения необходимо сформировать команду проекта не только от Исполнителя, но и от Заказчика, после чего определить допустимые взаимодействия между членами команд Исполнителя и Заказчика (кто, с кем, по каким вопросам взаимодействует), т. е. установить правила взаимодействия.
При формировании организационной структуры проекта и принятии решения о подчиненности следует помнить, что управлять непосредственно более чем десятью членами команды проекта становится затруднительно. Идеальный вариант: пять-семь человек.
Особо отметим, что при создании организационной структуры проекта штатное расписание компании не должно изменяться. Не следует забывать, что проект - временное мероприятие, по окончании которого команда проекта распускается и специалисты приступают к своим функциональным обязанностям в соответствии со штатной организационной структурой компании или переходят на следующий проект, где их функции и полномочия могут быть другими.
Правильно сформированная организационная структура проекта обеспечит его эффективное управление, планирование, исполнение в запланированные сроки, на определенном качественном уровне.
Первая задача в формировании организационной структуры проекта - решить, какой тип структуры наилучшим образом подходит для данного проекта. Различные типы структур имеют определенные преимущества.
Основные типы организационных структур
Функциональная организация (Functional Organization) (рис 1.9). Иерархически выстроенная организация, в которой у каждого сотрудника есть один прямой начальник, сотрудники разделены на группы (отделы) по областям специализации. Каждая группа (отдел) управляется одним человеком, имеющим компетенцию в данной области - функциональным руководителем (руководителем отдела).
(рис 1.9) Линейно-функциональная структура организацииМатричная организация (Matrix Organization) (рис 1.10) - любая организационная структура, в которой Руководитель проекта разделяет с функциональными руководителями (руководителями отделов) ответственность по заданию приоритетов и управлению работой лиц, назначенных на исполнение проекта.
(рис 1.10) Матричная структура организацииПроектная организация (Projectized Organization) - любая организационная структура, в которой Руководитель проекта обладает достаточными полномочиями по установлению приоритетов, использованию ресурсов и руководству работой лиц, назначенных на исполнение проекта, а также финансовыми полномочиями в рамках бюджета проекта.
Для того чтобы понять сущность различных типов организаций, рассмотрим на условном примере, как может быть построена работа по разработке и внедрению ИС при структуре организации, представленной на рис 1.11.
Основные функции отдела Программирования: программирование алгоритмов расчета, анализа данных, интеграционных решений; разработка форм отчетов, разработка экранных форм, работа с базами данных ИС.
Основные функции отдела Бизнес-аналитики: разработка алгоритмов расчета, анализа данных, интеграционных решений, соответствующих бизнес-правилам, требованиям финансового учета и законодательства.
Основные функции отдела Консультаций и настроек ИС: настройка модулей ИС с использованием готовых алгоритмов, экранных форм и отчетов, оказание консультаций пользователям ИС.
Основные функции отдела Маркетинга и продаж: продажи ИС и услуг по ее внедрению.
Организация работ при функциональной структуре компании
При организации внедрения ИС в соответствии с функциональной структурой (рис 1.9), работа, как правило, происходит следующим образом:
После продажи отделом маркетинга и продаж услуг на внедрение информационной системы Руководитель компании проводит совещание с участием руководителей отделов Программирования, Бизнес-аналитики, Консультаций и настроек ИС. Руководитель компании доводит до участников совещания содержание и сроки работ по внедрению, в соответствии с условиями договора. Руководители отделов получают задание организовать работу по выполнению условий договора в рамках компетенций отдела.
Руководители отделов распределяют работу между сотрудниками отделов, контролируют качество и сроки ее выполнения, взаимодействуют с руководителями других отделов по смежным работам и по приему/передаче результатов работ из одного отдела другому. Например, отделом бизнес-аналитики был разработан в соответствии с Трудовым Кодексом РФ алгоритм расчета оплаты труда за ночные часы и праздничные дни. Разработанные алгоритмы передаются в отдел Программирования, где осуществляется программирование алгоритмов расчета. После завершения работ по программированию консультанты отдела Консультаций и настроек ИС проводят общую настройку системы с использованием разработанных алгоритмов расчета.
(рис 1.11) Пример организационной структуры консалтинговой компанииКаждый отдел одновременно может работать по нескольким договорам в рамках своих компетенций. При организации работ проекта по функциональной структуре каждый руководитель отдела отвечает за работы своего отдела и не отвечает за выполнение результатов по проекту-договору в целом. Отсутствие выделенного специалиста, ответственного за итоговый результат, является главным недостатком функциональной структуры. Этот недостаток проявляется тем сильнее, чем большее количество проектов-договоров одновременно выполняются функциональным подразделением и чем больше функциональных подразделений участвует в выполнении проектных работ. Внедрение ИС при таком подходе может происходить как в известной миниатюре артиста А. Райкина - "за рукава костюма отвечает один, за пуговицы - другой, за воротник - третий и т. д., а за костюм никто не отвечает и виновного за брак не найти…".
При построении системы управления проектной деятельностью функциональную структуру целесообразно использовать, если работы по проекту могут быть выполнены одним функциональным подразделением (отделом).
Рассмотрим на том же условном примере организацию работ проекта, но уже не по функциональной, а по матричной структуре (рис 1.10).
Руководитель компании при матричной организации проектных работ назначает ответственного за достижение конечных целей договора и выполнение условий договора - Руководителя проекта (менеджера проекта). Руководителем проекта при матричной структуре может быть назначен один из руководителей отделов. Если нет особых требований и условий, то Руководителем проекта назначается Руководитель того отдела, который выполняет в данном проекте больший объем работ. При этом с Руководителя отдела, назначенного Руководителем проекта, не снимаются функции по управлению отделом. Другими словами, Руководитель проекта при матричной организации может быть частично задействован на проекте (не на 100%), и продолжать выполнять свои функциональные обязанности.
Руководитель проекта анализирует содержание, объем и сроки работ, на основании чего определяет, сколько и каких специалистов нужно для выполнения проекта. Руководитель проекта делает запрос Руководителям отделов на выделение специалистов с указанием их квалификации и процента занятости. В зависимости от объема той или иной работы по проекту, специалисты могут быть выделены как на полную, так и на частичную занятость. После того как специалисты выделены, Руководитель проекта формирует для них задания и координирует работы. Задания Руководитель проекта согласовывает с Руководителем отдела (функциональным руководителем). У выделенного на проектные работы специалиста при матричной организации работ два руководителя - Руководитель отдела и Руководитель проекта. Руководитель проекта, как было сказано выше, отвечает за конечные цели и результат, а Руководитель отдела (функциональный руководитель) несет ответственность только за промежуточный результат в рамках компетенций подразделения (отдела).
Руководители проектов могут принимать решения только по организационным вопросам, функциональные руководители - по техническим (предметным) вопросам.
Достоинство матричной структуры - наличие ответственного за достижение целей проекта, недостаток - два руководителя у одного специалиста (консультанта), что часто приводит к межличностным конфликтам. При возникновении конфликта ресурсов проблема эскалируется вверх по иерархической структуре.
При матричной структуре организации проектных работ Руководитель проекта может быть наделен различной степенью полномочий. В зависимости от степени полномочий Руководителя проекта выделяют слабую, сбалансированную и сильную матричную структуру (таблица 1.4).
Организация работ при проектной структуре компании
При проектной организации работ, так же как и при матричной, для управления работами назначается Руководитель проекта, но занятость его на проекте не частичная, а полная. Специалисты, выделенные для выполнения проектных работ, подчиняются только Руководителю проекта до завершения проектных работ. Руководители отделов (функциональных подразделений), выделивших специалистов на проектные работы, не несут ответственность за качество их работы, в отличие от матричной структуры организации. Исходя из того, что при проектной структуре Руководитель проекта на 100% занят управлением проектом, напрашивается вопрос: а найдется ли такой Руководитель отдела или другой специалист с навыками управления, который бы на время проекта согласился отказаться от своей должности? Ведь для него возникает риск по окончанию проекта оказаться "не у дел". Решение подобной проблемы найдено в том, что в проектных структурах введена специальная должность - Руководитель проекта. В ряде организаций созданы
отделы/департаменты Руководителей проектов, и только из их числа назначаются Руководители проектов. Таким образом, основное отличие проектной структуры компании от матричной - в наличии специально выделенной группы специалистов для управления проектами. Руководитель проекта назначается только из этой группы (отдела, департамента), в проекте он занят на 100% и наделен всеми полномочиями по привлечению и управлению ресурсами, принятию управленческих решений, в том числе и по финансовым вопросам в рамках установленного бюджета.
Управление проектами в различных структурах
| Характеристика проекта |
Структура организации |
|---|
| Функциональная |
Матричная |
Проектная |
|---|
| Слабая |
Сбалансированная |
Сильная |
|---|
| Полномочия руководителя проекта |
Нет |
Ограниченные |
умеренные |
От умеренных до высоких |
От высоких до абсолютных |
| Занятость руководителя проекта |
Нет |
частичная |
полная |
полная |
полная |
Критерии выбора организационной структуры проекта, отвечающей целям и условиям осуществления проектов в конкретной компании, представлены в таблице 1.5.
Критерии выбора организационной структуры проекта
| Критерий выбора |
Функциональная |
Матричная |
Проектная |
|---|
| Решение проекта |
стандартное |
сложное |
новое |
| Сложность |
низкая |
средняя |
высокая |
| Продолжительность |
короткая |
средняя |
большая |
| Масштаб |
малый |
средний |
крупный |
| Важность |
не очень важный |
средней важности |
важный |
Рекомендации по выбору организационной структуры:
Масштабные, долгосрочные и дорогостоящие проекты обычно требуют проектной структуры либо сбалансированной и сильной матричной структуры.
Мелкими, краткосрочными и малозатратными проектами можно управлять с помощью функциональной или слабой матричной структуры.
Матричная структура является оптимальной для большинства проектов, а также хорошим компромиссом между функциональной и проектной структурами.
Организационная схема проекта
После выбора организационной структуры проекта Руководитель проекта должен определить организационную схему, в которой будут отражены взаимосвязи команды проекта, отношения подчиненности.
Пример организационной схемы проекта, состоящей из команды Исполнителя и Заказчика, приведен на рис 1.12.
(рис 1.12) Пример организационной схемы проектаВ организационной схеме проекта с участием двух команд - команды Исполнителя и команды Заказчика - должны быть предусмотрены как формальные, так и неформальные организационные взаимодействия. Формальные взаимодействия всегда обеспечиваются официальными документами, такими как протоколы совещаний, служебные записки, приказы, распоряжения и т. д. Неформальные взаимодействия не должны обеспечиваться документально. Взаимодействия по вертикали управления внутри одной команды: Куратор (Спонсор) проекта - Руководитель проекта - Команда проекта - должны быть формальными и поддерживаться официальными документами. Взаимодействия Руководителей проекта со стороны Заказчика и Исполнителя также должны оформляться официальными документами. Допускаются неформальные взаимодействия между Кураторами проекта и членами команд проекта от Заказчика и Исполнителя (рис 1.13).
(рис 1.13) Пример организации формальных и неформальных взаимодействий
