Швей В.И. Управление проектами информационных систем

Подождите немного. Документ загружается.

стадии), (“Моделирование 3”).

Проекты фаз консолидации протекают так же, как и проекты внедрения, но

завершаются после стадии реализации (корпоративное проектное решение не

предназначено для внедрения, миграция отсутствует).

Разбиение проектов фазы оптимизации на стадии осуществить довольно сложно

ввиду разногласий по вопросам природы подобных проектов. Однако условно можно

выделить стадии оценки (текущего состояния) и определения (необходимых мероприятий

по изменению/оптимизации).

Следующим уровнем WBS рассматриваемой методики являются события. Без

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

событие представляет собой недвусмысленно сформулированный промежуточный

результат проекта. Событие, подобно целям проекта, обладает SMART характеристиками

и является:

 Специфичной (Specific) – формулировка отражает достижение конкретного

результата;

 Измеримой (Measurable) – наличие явных критериев достижения вехи и

контроля достижения;

 Приемлемой (Acceptable) – необходимость достижения вехи разделяется

всеми вовлечёнными лицами;

 Реалистичной (Realistic) – по отношению к поставленной цели;

 Увязанной по времени (Time-Related) – наличие временного показателя

достижения.

События кодируются определённым образом, расшифровка кодов представлена в

таблице 2.1. События хранятся в репозитарии событий и могут группироваться средствами

Target Enterprise в Концептуальные планы. Один план – один сценарий управления

проектом. Target Enterprise предлагает несколько сценариев по выбору, консолидации,

внедрению, оптимизации, управлению проектами, управлению программами, организации

Центра компетенции Baan.

Таблица 2.1

Расшифровка кодов событий

Элемент кода Пример Расшифровка

Фаза I выбор (selection), консолидация (visioning), внедрение (implementation),

оптимизация (optimization). X используется для вех, которые могут быть

отнесены к нескольким фазам

Результирую

щий путь

O Персонал (Personnel), Техническое обеспечение (Technical Infrastructure),

Кастомизация (Customizations), Интерфейсы (Interfaces), Данные (Data),

Построение бизнес модели (Business Model Architecture), Организационные

улучшения (Organizational Alignment), Управление проектом (Project

Management), Управление программой (ProGram Management)

Номер п/п 1 Номер п/п, использующийся в соответствующих проектных сценариях

Вариант b Разновидность исходной вехи (без буквы в конце кода)

На самом низшем уровне WBS расположены работы. Декомпозиция работ

осуществляется по-разному в зависимости от типа и специфики конкретных проектов

Target Enterprise.

Это все основные элементы методологии, предлагаемой в качестве стандарта

управления проектами внедрения программного обеспечения Baan. В таблице 2.2

представлены результирующие пути Target Enterprise и соответствующие им

результирующие пути метода GDPM. Понимание концепции результирующих путей

необходимо для анализа структуры (WBS) проектного решения, предлагаемого в методике

Target Enterprise.

Важно ещё раз отметить, что Target Enterprise – это не только методика, но и

инструментарий внедрения. TE включает в себя Конфигуратор Проекта (программа,

позволяющая генерировать Концептуальные планы и диаграммы ответственности на

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

графики работ в MS Project); Риск Менеджер (программа, позволяющая производить

оценку рисков проекта внедрения и осуществлять элементы управления рисками);

Генератор бюджетов (программа, позволяющая проводить оценку затрат по проекту и

осуществлять управление затратами); Моделировщик предприятия DEM, позволяющий

создавать прототипы информационной системы предприятия (нулевой, первичный,

стандартный и т.д.);

Таблица 2.2

Соответствие результирующих путей GDPM и TE

Результирующие

пути в GDPM

Результирующие

пути в TE

Цели

Персонал (P) Тренинг и

коммуникации (P)

Понимание и навыки работы с корпоративным проектным

решением, заинтересованные пользователи, решённые кадровые

вопросы

Информационные

технологии (S)

Техническое

обеспечение (T)

Исправно работающая техническая инфраструктура

Разработка:

кастомизация,

интерфейсы,

программы

переноса данных

(C, I, D)

Дополненные стандартные приложения Baan, реализованные

интерфейсы с предшествующими информационными системами

и/или другими компаниями, корректные данные в базах данных

Построение

бизнес модели (M)

Бизнес модель, отражающая работу организации заказчика (как

есть и как будет), спроецированная на конкретные программные

приложения

Система

управления (O)

Организационные

улучшения (O)

Проведённые организационные изменения для обеспечения

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

приложений Baan

Нет в GDPM Управление

проектом (PM)

Достигнутые цели проекта посредством методов управления

проектами

Нет в GDPM Управление

программой (PG)

Достигнутые цели программы посредством запуска,

координации и обеспечения реализации проектов

Структуру продукта Target Enterprise можно представить в виде четырёх уровней:

 Концепции (Управления проектами, Моделирования предприятия),

 Методы (метод GDPM, методы моделирования, управления рисками),

 Инструменты (перечислены выше)

 Шаблоны (репозиторий событий, сценарии проектов, форматы документов).

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

Практика показывает, что сокращение продолжительности и увеличение качества

проектов внедрения в последнее время требует всё более сложных решений и

комплексного подхода. Это обусловлено вовлечением большего числа ключевых и

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

территориальной удаленностью звеньев, разнонаправленностью внутренних интересов и

т.д.

Усложнение проектов внедрения возможно лишь до некоторого уровня, в случае

комплексного внедрения Target Enterprise предлагает инициировать программы внедрения,

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

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

приближенно и уточняются по мере реализации (уточняется количество и

последовательность запуска отдельных проектов, сроки, затраты и т.д.). Планирование

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

неоправданным ожиданиям, разочарованиям и демотивации. По ряду причин программы

необходимо отличать от проектов и соответствующим образом подходить к их

управлению.

Программы Baan предназначены для реализации на оперативном и тактическом

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

реинжениринга бизнес процессов, BPR-проекты) обеспечиваются, но не покрываются

информационной системой, последняя, как известно, может выступать в роли

эффективного инструмента, но не более того.

В рамках Target Enterprise разработаны варианты стратегий программного

управления для однозвенного и многозвенного внедрения. В последующих разделах будут

рассмотрены возможные стратегии, а также примеры организационных структур программ

и проектов.

2.2.4.1 Стратегии программ внедрения

Возможны два основных варианта внедрения системы:

 внедрение в простой организации или однозвенное внедрение

 внедрение в сложных корпоративных структурах или многозвенное

внедрение.

Примером многозвенной среды может быть наличие нескольких юридических лиц с

разной специализацией в рамках одной организации.

Программы инициируются и в первом и во втором случаях. Для однозвенного

внедрения выделяют три характерных стратегии (рис. 2.5).

1. Техническое внедрение, затем организационная оптимизация;

2. Полномасштабное внедрение;

3. Организационная оптимизация, затем внедрение.

В первом случае происходит простое замещение предшествующей информационной

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

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

информационной системы. Противоположность первому – последний случай.

Рис. 2.5. Типовые стратегии программ внедрения

Сначала инициируются проекты по организационным изменениям, лишь затем

начинается внедрение системы. Сбалансированным вариантом является вариант

полномасштабного внедрения. Во всех трёх случаях конечное состояние (to be) одно и то

же – новая система в новой среде с изменёнными бизнес процессами. Различия

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

продолжительности и уровне рисков.

Проекты внедрения в трёх случаях разнятся объёмами реализуемых

организационных изменений. В таблице 2.3 представлены преимущества и недостатки

типовых стратегий программ внедрения для одного звена.

В случае многозвенного внедрения в программе появляется фаза консолидации,

более сложной становится фаза внедрения. Большее число проектов ставит во главу угла

проблему их координации, соблюдения той или иной последовательности.

Таким образом, стратегия программного многозвенного внедрения, не исключая трёх

Настоящее

состояние

Желаемое

состояние

100%

Техническое

внедрение

Организационная

оптимизация

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

следующим направлениям:

 Сверху вниз;

 Снизу вверх;

 Децентрализовано.

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

проектного решения (на фазе консолидации) и последующее “серийное” внедрение этого

решения на выбранных звеньях организации.

Таблица 2.3

Преимущества и недостатки типовых стратегий программ внедрения

Преимущества Недостатки

Техническое внедрение, затем организационная оптимизация

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

Управляемый цикл обучения

Требуется дисциплина в проектах

оптимизации; Фальстарт программы ввиду

Равномерное использование

ресурсов

низкой популярности и слабой вовлечённости

менеджмента и простых работников; требуются

доработки в ходе оптимизации

Полномасштабное внедрение

Быстрота

Отсутствие необходимости

пересмотра конфигурации системы

Концентрация на достижение

желаемого, целевого состояния

Высокая потребность в ресурсах; Высокие

требования к качеству проектного управления;

Повышенная сложность и риски проекта;

Естественная тенденция к смене приоритетов

сразу после внедрения

Организационная оптимизация, затем внедрение системы

Потребности бизнеса

выдвигаются на первый план и

хорошо осознаются заказчиком

Риск выхода за временные рамки проекта

Риск существенных доработок системы

под выявленные требования, риск изменения

организационных решений

Пример программы, построенной сверху вниз, представлен на рисунке 2.6.

Рисунок 2.6. Пример программы многозвенного внедрения

Пилотное внедрение иногда необходимо для тестирования и уточнения

корпоративного проектного решения и протекает с сильной обратной связью. Штамповка

проектного решения может осуществляться последовательно или параллельно. Второй

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

получения корпоративного проектного решения, но с последующей разработкой этого

решения до начала “штампованного” внедрения. Последний случай предполагает

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

В практике стратегии программного управления – это смешанные стратегии.

Решение о следовании тем или иным сценариям, как правило, принимаются и уточняются

на фазе консолидации. Важными критериями здесь становятся уровень общности бизнес

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

уровень осознания руководством общей схемы функционирования элементов организации.

Высокая общность и низкая интеграция, к примеру, могут обеспечить разработку

исчерпывающего корпоративного проектного решения и параллельное “штампованное”

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

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

разработку корпоративного решения менее существенной задачей.

Отдельное

внедрение

Отдельное

внедрение

Консолидация

Управление программой

Звено 1

Зв. 2

Зв. 3

Зв. 4

Зв. 5

Штамповка

Пилотное внедрение

2.2.5 Структуры программ и проектов

Большое внимание в рассматриваемой методологии уделяется формированию и

развитию организационных структур проектов и программ с соответствующим

документооборотом, распределением ролей и ответственности. Наиболее чёткой

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

структура представлена на рис. 2.7.

Рис. 2.7. Организационная структура проекта внедрения

Структура проекта выстраивается в соответствии с результирующими путями. Если

не рассматривать Управление программой, то их шесть:

 Тренинг и коммуникации;

 Построение бизнес модели;

 Миграция данных и Разработка

 Техническое обеспечение;

 Организационные улучшения;

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

Все, кроме последнего, относятся к реализации проекта и составляют Проектное

решение, шестой путь – собственно управление реализацией проекта. Результирующие

пути, как уже было показано, – это основные направления деятельности и ключевые

О ф и с м е н е д ж е р

Р а б о ч а я г р у п п а 1

Р а б о ч а я г р у п п а I I

Р а б о ч а я г р у п п а I I I