технологическая зрелость и ит-проекты

1. 1
Модель технологической зрелости
применительно к участникам и
продукту проекта как средство
анализа и определения вероятности
успеха проекта внедрения ИСУП.
ДмитрийДмитрий ЛукьяновЛукьянов,,
ДиректорДиректор отделенияотделения информационныхинформационных технологийтехнологий
МеждународногоМеждународного автомобильногоавтомобильного холдингахолдинга ««АтлантАтлант--ММ»»,,
ЧленЧлен СообществаСообщества ИТИТ--директоровдиректоров УкраиныУкраины,,
СертифицированныйСертифицированный ПроектныйПроектный МенеджерМенеджер ((IPMA, level B)IPMA, level B),,
ЧленЧлен IPMA, UPMA, SOVNETIPMA, UPMA, SOVNET
Осенний съезд ИТ-директоров Украины. Киев, 29 сентября – 1 октября 2004

2. 2
История вопроса
Информационная Система Холдинга «Атлант-М» -
источник информации для анализа:
К 2004 году:
Основной бизнес – дистрибьюция новых автомобилей как
импортных, так и отечественных марок на территории трех
стран – Белоруссии, России и Украины.
Около 30 предприятий объединены в единое
информационное пространство
Более 1000 пользователей
Служба доставки сообщений на базе Lotus Notes,
ERP система SAP R/3
Другие специализированные приложения (автобизнес).

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

4. 4
Наши задачи.
«Цепочка ценности» предоставляемой услуги в области внедрения
программного решения для Заказчика
Задача: качественно обеспечить внедрение решения и запуск его в
продуктивную эксплуатацию
П1.1 П1.2 П1.3 П1.4 П1... П1.N
Пользователь/
Заказчик
Поставщик
решения
Процессы, полностью контролируемые «внедренцами»
Процессы, на которые влияют внутренние факторы Заказчика

5. 5
Эволюция подхода
«внедренцев»
2001
«Коробочные»
легкие продукты,
Минимум
аналитики,
Решения
максимум
уровня MRP-
продуктов,
Невысокий проф.
уровень
2002
Доработка
стандартных
решений,
Появление
специалистов
бизнес-анализа,
Предложение
систем уровня
ERP,
Проф.
уровень растет
2003
Полноценный
Бизнес-анализ
Внедрение
методологии и
инструментария
Проекта внедрения,
Обучение
сотрудников,
высокий уровень
профессионализма
2004
Реальный
реинжениринг
с предложением
Конкретного
Решения для
Конкретного
Заказчика

6. 6
Эволюция подхода
Заказчика
2001
Типовые
процедуры для
проведения
тендерной оценки
предложений
«внедренцев».
Вера в «чудо»,
Надежда сделать
все сразу и
дешево,
Неготовность
платить
аналитикам
2002
Шок,
Откат назад,
Появление
внутренних
экспертов-
аналитиков
2003
Обучение
сотрудников,
Бизнес-анализ
собственных
бизнес-процессов,
Сотрудничество с
консультантами
2004
Поиск реальных
решений для
своих задач,
Готовность
привлекать
консультантов

7. 7
Но немного статистики…
Оказывается, не все так
хорошо…
Успешный проект: сроки,
бюджет и качество
соответствуют
запланированным
либо изменения
согласованы
и выполнены в соответствии
с измененными критериями
успешно ОИТ успешно проч.
2004 год
2000 год
2004 год
2000 год
Налицо отрицательная динамика! Необходимо выработать критерии оценки
для решения Go or Not to Go для каждого конкретного проекта с учетом
особенностей предприятия-Заказчика, компании-интегратора и продукта!
Необходимы согласованные действия в рамках одной методологии!

8. 8
Возможная модель.
Как возможную метрику для оценки ситуации на
проекте внедрения предлагается использовать
Модель Технологической Зрелости…
Но не только применительно к Предприятию-
Заказчику и к Предприятию-«Бизнес-интегратору»
(консалтинговой компании), но и к
Внедряемому Продукту!
И только на основании такого комплексного анализа
планировать проект внедрения!

9. 9
Уровни модели зрелости.
Справочная информация.
Уровень 4. Развитие через жизненные циклы,
постоянные улучшения, бенчмаркинг, реинжениринг.
(устойчивое развитие бизнеса)
Уровень 3. Единая методология управления проектами
(формирование самодостаточной системы)
Уровень 2. Общие процессы управления проектами
(формирование базовой системы)
Уровень 1. Общий профессиональный язык управления
проектами (начальное формирование)
Обратная связь по развитию
инфрастуктуры
Источник: www.upma.kiev.ua

10. 10
Стандартный подход –
применительно только к
предприятию
• Анализ по данной модели возможен как для
сопоставления на тот или иной уровень
предприятия-заказчика так и предприятия-
интегратора.
• Для анализа же продукта необходимо внести
некоторые корректировки в модель – требуется
ввести некий «эталон предприятия-потребителя
продукта» для определения возможности успешного
внедрения.
Вариант анализа эталонного предприятия для
внедрения систем типа ERP, MRP, PRP – см.
следующий слайд:

11. 11
Уровни модели зрелости
применительно к продукту
Уровень 4. Развитие через жизненные
циклы, постоянные улучшения,
бенчмаркинг, реинжениринг.
(устойчивое развитие бизнеса)
Уровень 3. Единая методология
управления проектами (формирование
самодостаточной системы)
Уровень 2. Общие процессы
управления проектами
(формирование базовой системы)
Уровень 1. Общий профессиональный
язык управления проектами (начальное
формирование)
Успешное внедрение и
функционирование систем управления
предприятием (продукта внедрения) на
всех его уровнях
Успешное дальнейшее развитие
систем управления предприятием
(продукта внедрения) на всех его
уровнях
Возможно успешное внедрение и
функционирование систем управления
предприятием (продукта внедрения)
лишь на некоторых его уровнях
Возможен провал проекта внедрения.
Успех проекта невозможен на
«тяжелых» решениях без коррекции
уровня внедряемого продукта в
сторону уменьшения его сложности
Обратная связь
по развитию
инфрастуктуры

12. 12
Уровни модели зрелости.
Моделирование ситуации
Интегратор 2
Успех проекта внедрения
проблематичен –
результат проекта зависит
от уровня интегратора
(группы интеграторов)!
Продукт
Конфликтная
зона!
Интегратор N
Интегратор 1

13. 13
Уровни модели зрелости.
Возможные сценарии.
Зона успеха
1 Зона успеха
N
Интегратор 2
Продукт
Интегратор N
Интегратор 1

14. 14
???
Заказчик
???
«Темная
лошадка»
Уровни модели зрелости.
Заказчик.
Возможные сценарии.
Интегратор 2
Продукт
Интегратор N
Интегратор 1

15. 15
Уровни модели зрелости.
“Stairway To Heaven ?”
•Явно «вырисовывается» ситуация, когда возникает
необходимость учитывать, и, соответственно, управлять
риском, появляющимся в связи с участием в проекте
«темных лошадок» - которыми могут оказаться как
интеграторы, так и непосредственно само предприятие-
заказчик и, как это не парадоксально, даже продукт
проекта.
и этом видятся два способа минимизации такого
риска/рисков:

16. 16
Уровни модели зрелости.
“Stairway To Heaven ?”
•Второй способ скорее является расширением первого – здесь
необходимо еще «выбрать в пору костюм» - внедряемый продукт –
отклонения как в большую так и в меньшую стороны по возможному
функционалу так или иначе приведут к неудовлетворенности
Заказчика.
•Первый способ управления таким риском – проведение аудита
уровня технологической зрелости своей компании и привлечение
интегратора (консалтинговой компании), находящегося как
минимум на том же (а лучше выше) уровне (пример – наличие
«большой четверки» аудиторских фирм) – и принятия решения о
том, идти или не идти в проект и с кем на основании такого анализа.
Это более-менее стандартно для выбора интегратора, но, к
сожалению редко применяется к Заказчикам

17. 17
Уровни модели зрелости.
“Stairway To Heaven !”
Заказчик
Проекта – полноценный
член команды Проекта
«Мечта»
Менеджера
Проекта
Интегратор 2
Продукт
Интегратор N
Интегратор 1

18. 18
План действий.
• Всесторонний анализ – собственного предприятия Заказчика,
Предприятий-интеграторов (консультантов), Продукта внедрения.
• Внешний аудит технологической зрелости предприятия – как норма
• Взаимодействие с профессиональными организациями и ассоциациями
• Повышение уровня технологической зрелости предприятий
• Совершенствование процедур, инструментария УП и
навыков работы с ними
• Принятие решений о проектной активности на основе анализа
соотношения метрик для Продукта, Компании и Команды Проекта

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

20. 20
А почему бы и
нет?!
Когда, например, для ПО SAP AG –
появится такая запись -
прямо в лицензионном соглашении:
«Для предприятий уровня ниже 3 – не внедрять!»
(Как на триллере – «Детям до 16 – не смотреть!»),
Возможно, тогда
количество неуспешных проектов
в области внедрения ERP-систем и сократится?

21. 21
Спасибо за внимание!
• Дмитрий Лукьянов
Certificated Project
Manager
(IPMA level B)
Mail: dl@atlantm.com
Mobile: +375 29 6506305
Web: www.atlantm.com