Организация управления проектом
ТКВ определяет, что в каждом проекте должны быть задействованы участники 19 ролей:
- спонсор проекта (владелец результатов проекта);
- куратор проекта (представляет интересы спонсора проекта);
- руководитель проекта1 (осуществляет управление проектом: планирует, контролирует, обеспечивает реализацию и отвечает за результаты проекта);
- руководитель исполнителя проекта (отвечает за ресурсы исполнителя на проекте);
- бизнес-аналитик2 (осуществляет бизнес-анализ работы предприятия);
- менеджер по качеству;3
- администратор проекта (выполняет техническую работу, связанную с управлением проектом);
- системный аналитик4 (разрабатывает спецификацию требований и архитектуру ИС);
- программисты5;
- тестировщики;
- внедренцы (проводят запуск системы в эксплуатацию);
- менеджер по конфигурационному управлению;
- менеджер по закупкам;
- менеджер по обучению (организует обучение команды проекта и пользователей);
- преподаватель (проводит обучение);
- аккаунт-менеджер (организует коммерческое взаимодействие между заказчиком и исполнителем);
- системный администратор (отвечает за работоспособность технической инфраструктуры, необходимой для ИС);
- специалисты службы поддержки;
- пользователи системы.
Схема, иллюстрирующая основные взаимоотношения этих ролей в проекте по ТКВ, приведена на рис. 1.
Рис. 1. Основные взаимоотношения ролей и некоторых продуктов в рамках проекта по ТКВ.
Типовые риски и их минимизация
Жизненный цикл проекта и периодические мероприятия позволяют минимизировать риски. Фазы жизненного цикла помогут свести к минимуму наиболее тяжелые последствия рисков на максимально ранних этапах проекта. Перечень некоторых типов рисков, привязанный к фазам жизненного цикла проекта, последствия и меры по их минимизации приведены в таблице. Для каждого конкретного проекта эти риски должны быть сформулированы в привязке к целям и среде выполнения конкретного проекта.
Таблица. Типы рисков проекта внедрения.
|
Фаза жизненного цикла |
Тип рисков |
Последствия реализации риска |
Меры по минимизации последствий в методологии ТКВ |
|
Фаза 0. Инициация проекта |
Границы и рамки проекта определены неверно |
ИС не будет соответствовать ожиданиям и потребностям заказчика. Проблемы и задачи компании, ради решения которых открывался проект, не будут решены. Для исправления ситуации, как правило, потребуется значительная переделка ИС. Сроки и бюджет проекта будут очень сильно превышены. Как правило, проект будет признан неуспешным и закрыт |
|
|
Фаза 1. Концептуальное проектирование |
Объем и цели проекта определены неверно |
ИС не будет соответствовать потребностям заказчика. Бизнес-цели, ради достижения которых открывался проект, не будут достигнуты. Для исправления ситуации может потребоваться значительная переделка ИС. Сроки и бюджет проекта будут значительно превышены. С высокой вероятностью проект будет признан неуспешным и закрыт до своего планового окончания |
Согласование и утверждение целей проекта, бизнес-требований к ИС и основных документов проекта (концепция ИС, план-график проекта, бюджет и т. д.)
|
|
Фаза 2. Архитектура системы |
Доступные технические средства и возможности типового решения не позволяют полностью реализовать все требования к ИС |
ИС не будет соответствовать потребностям заказчика в полной мере. Часть целей проекта не будет достигнута либо будет достигнута не так, как планировалось. Реализация этого риска на последующих фазах проекта приведет к существенным переделкам системы, существенному увеличению сроков проекта, а в некоторых случаях к его полному провалу по причине принципиальной невозможности реализации требований к ИС |
|
|
Фаза 3. Рабочий проект (разработка) |
Ошибки в программном обеспечении |
ИС не будет соответствовать требованиям заказчика в полной мере. Часть целей проекта не будет достигнута либо будет достигнута не так, как планировалось. Реализация этого риска на последующих фазах проекта приведет к увеличению сроков и бюджета проекта. В редких случаях может привести к досрочному неуспешному завершению проекта. |
|
|
Фазы 0–4 |
Недостаточный уровень коммуникаций между участниками проекта со стороны заказчика и исполнителя |
|
|
|
Фазы 0–4 |
Уровень квалификации участников команды проекта не соответствует поставленным задачам |
|
|
|
Фаза 5. Ввод в промышленную эксплуатацию |
Сопротивление со стороны персонала заказчика |
Задержка в сроках ввода ИС в эксплуатацию. В редких случаях может привести к досрочному неуспешному закрытию проекта |
|
|
Фазы 0–5 |
Несвоевременное финансирование проекта |
Срыв сроков выполнения работ по проекту. Штрафные санкции со стороны субподрядчиков и поставщиков за невыполнение финансовых обязательств |
|
Область эффективности технологии корпоративного внедрения
ТКВ представляет собой достаточно универсальную методологию. Ограничение её применения связано только с одним фактором — эффективностью. На небольших проектах с небольшими изменениями использовать ТКВ слишком дорого. Именно поэтому ТКВ — это не единственная методология управления проектами внедрения тиражных продуктов семейства «1С:Предприятие». Для относительно простых внедрений типовых продуктов без доработки фирма «1С» разработала методологию стандартного внедрения, а более сложные проекты, с определенными доработками и кастомизацией типового решения, ведутся по технологии быстрого результата. Выбор той или иной технологии внедрения продуктов семейства «1С:Предприятие» происходит на основе пяти характеристик проекта и среды выполнения:
- масштаб проекта;
- критичность технологических изменений (доработок тиражной системы);
- критичность организационных изменений в компании-заказчике (внедрение ИС неминуемо связано с организационными преобразованиями в компании6 );
- готовность методологий и политик учета, формализация бизнес-процессов и процедур;
- готовность компании-заказчика к быстрому принятию решений по проекту.
Алгоритм принятия решения об использовании ТКВ показан на рис. 2. 
Рис. 2. Алгоритм принятия решения об эффективности использования методологии ТКВ.
Отталкиваясь от этих критериев, можно сформулировать пять ключевых критериев, при выполнении которых эффективно использовать технологию корпоративного внедрения:
- масштаб: численность команды проекта — более 10 человек (общая: как сотрудников заказчика, так и подрядчика), объем — более 3 тыс. человеко-часов, срок — более 6 месяцев;
- критичность технологических изменений (доработок тиражной системы): требуются существенные изменения, затрагивающие архитектуру ИС;
- критичность организационных изменений: требуемые решаемой задачей изменения не локальны и затрагивают важные подходы к управлению компанией, а также существенно перераспределяют роли и ответственность руководителей;
- готовность методологий и политик учета, формализация бизнес-процессов и процедур: задача такова, что, кроме внедрения программного продукта, необходима разработка и утверждение методологий или изменение бизнес-процессов и процедур7;
- готовность компании к быстрому принятию решений: заказчик (или заказчики) ИТ-системы не готовы быстро принимать решения по проекту, либо этого требуют корпоративные процедуры и стандарты.
Чтобы оставить комментарий пожалуйста Авторизуйтесь