Управление проектами по внедрению корпоративной информационной систем - Казаков И.В

Управление проектами по внедрению КИС

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

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

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

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

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

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

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

В проекте подлежит планированию все, что подлежит учет, контролю и анализу

ирегулированию. Это в первую очередь планирование функций управления:

•предметной областью

•стоимостью

•временем

•качеством

•человеческими ресурсами

•коммуникациями

•рисками

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

•Что необходимо делать?

•Кто и что должен делать

•Кто с кем взаимодействует

21

Управление проектами по внедрению КИС

•Когда и что должно быть сделано?

•Как должны распределятся ресурсы?

•Какое требуется качество?

•Каковы риски проекта?

Таким образам к общим принципам планирования проектов отнести следующее:

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

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

•Сбалансированность по ресурсам. Планы не должны содержать элементов, не обеспеченных ресурсами

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

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

•Многофункциональность – означает планирование по всем функциям управления проектом.

•Оптимальность планирования – формирование не просто приемлемые планы, а планы наиболее выгодные по выбранным критериям

•Адаптивность – способность отвечать на изменения внешней и внутренней среды проекта

•Непротиворечивость плана – то есть обеспечение полной взаимосвязанности и преемственности принимаемых решений

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

Тейхман и Уайлмон [9] в своем исследовании, где принимали участие 304 менеджера проектов и их руководство из различных компаний США определили ряд проблем, отрицательно сказывающихся на использовании исполнении проекта, а так же предложили некоторые рекомендации по реализации эффективного планирования и исполнения проекта:

•Убедиться, что каждый член команды лично отвечает за часть проекта

•Совместно с участниками проекта разработать подробный план проекта

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

•Добиться принятия обязательств по проекту от членов команды

•Добиться принятия по проекту от руководства

•Определить измеряемые контрольные события

•Привлекать и удерживать в проекте компетентных сотрудников

22

Управление проектами по внедрению КИС

•Назначить ответственного за контроль и выполнения каждого пакета работ

•Своевременно выявлять проблемы

Предварительный план проекта по внедрению КИС

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

1.Содержание проекта,

2.Цели проекта

3.Подход к проекту

4.Контрактные требования

5.технические требования внедренной КИС

6.Календарные планы общей детализации

7.Приблизительную оценку требуемых ресурсов

8.Финансовые ограничения

9.Области рисков

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

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

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

Планирование предметной области проекта

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

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

23

Управление проектами по внедрению КИС

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

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

•определение предметной области проекта — составление документа, утверждающего конфигурацию предметной области проекта как основу для принятия последующих решений

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

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

•обоснование проекта

•основные цели и задачи проекта;

•критерии и оценки успеха проекта или его частей.

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

В случае с КИС планом предметной областью проекта будет Дизайн-решение проекта, содержащего следующую информацию

Анализ требований.

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

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

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

ирезультатами внедрения:

•Технический

•Финансовый

•Коммерческий

•Организационный

•Социальный

•Экономический

Взвесив все «за» и «против» проекта, необходимо приступать к формулировке требований. На этом этапе необходимо определиться с вопросом «Что должна делать будущая система?».

Список требований к КИС должен включать:

•Совокупность условий, при которых предлагается эксплуатировать будущую систему

•Описания выполнения системой функций

24

Управление проектами по внедрению КИС

•Ограничения в процессе разработки (по времени, по бюджету, по

ключевым характеристикам).

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

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

Описание требований.

первоначально необходимо формализовать требования, предъявляемые на первом этапе внедрения. То есть необходимо подготовить документ, в котором будет строго и четко сформулированы требования к системе, а также, что немаловажно, форма их выполнения в конкретной системе. Степень детализации такого документа очень высока. В реальной проектной документации зачастую можно увидеть требования/описания к конкретному окну или строке. То есть, если заказчик желает, чтобы «новые, необслуженные заказы были на виду», то в описаниях требования необходимо указать, что «в модуле ЗАКАЗЫ, в таблице ЗАКАЗАНО сортировка должна быть по выполнению, а невыполненные заказы должны выделяться красным цветом» (пример из проектной документации Columbus IT partners)

Анализ процессов, документирование решения.

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

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

2 Схема составлена на основании личного опыта анализа бизнес процессов управления заказами.

25

Управление проектами по внедрению КИС

Техническая инфраструктура

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

•требование к базе данных

•системные требования

•требования к данным

•описание процесса конвертации исторических данных

•описание новых полей в интерфейсе

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

Дизайн проекта

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

Детализация проекта и конкретных задач.

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

Наиболее эффективным методом такого деления проекта является создание иерархической структуры проекта (ИСП), также часто называемой иерархической структурой работ (ИСР) [PMI: Work Breakdown Structure] или структурной декомпозицией работ (СДР) [1].

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

Иерархическая структура проекта разрабатывается путем разумного комбинирования структуры продукта с процессом его разработки. Термин

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

27

Управление проектами по внедрению КИС

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

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

Использование ИСП.

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

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

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

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

•для каждого элемента структуры проекта ("сверху вниз" - на всех уровнях до каждой задачи) указываются:

o ответственная и исполняющая организации и функциональные лидеры проекта;

o спецификации продукта

o основной контракт, контракты с субподрядчиками и основные заказы

o оценки и бюджеты ресурсов (сотрудники, фонды, программное и аппаратное обеспечение) и бюджеты;

o номера рабочих заданий/нарядов на работы;

o номера счетов издержек (только на уровне задач);

o контрольные события и относящиеся к ним операции в сетевых планах: методика анализа и оценки проекта или программы (PERT)/метод критического пути (СРМ)/управление данными о продукте (PDM) с запланированными датами;

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

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

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

28

Управление проектами по внедрению КИС

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

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

При разработке ИСП необходимо принимать во внимание следующие основные правила:

•Каждый элемент ИСП должен обеспечивать достижение ощутимого результата.

•Каждый элемент ИСП должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

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

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

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

•Все результаты в явном виде должны быть включены в ИСП.

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

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

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

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

Традиционные декомпозиции работ обычно имеют три фундаментальных порока.

29

Управление проектами по внедрению КИС

1.Они создаются преждевременно при разработке продукта.

2.Они преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно.

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

Поэтому в связи со спецификой работ по внедрению КИС применяются эволюционные модели ИСП Эволюционирующие ИСП организуют элементы планирования вокруг схемы

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

•Элементами ИСП первого уровня являются рабочие процессы (управление проектом, создание рабочей среды, управление требованиями, проектирование, реализация, оценка и внедрение). Эти элементы обычно закрепляются за одной командой и формируют «анатомию» проекта, которая используется в целях планирования и сравнения с другими проектами.

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

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

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

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

A.a. Управление начальной стадией A.a.a. Разработка бизнес-плана

A.a.b. Спецификации версии стадии уточнения A.a.c. Определение основ ИСП стадии уточнения A.a.d. План разработки ПО

A.a.e. Контроль и оценка состояния проекта на начальной стадии A.b. Управление стадией уточнения

A.b.a. Спецификации версии стадии конструирования , A.b.b. Определение основ ИСП стадии конструирования

A.b.c. Контроль и оценка состояния проекта на стадии уточнения

3 Адаптация ИСП из [14]

30