Внедрение Oracle E-Business Suite. Проблемы, риски, результаты - Пушников Андрей
←
→
Транскрипция содержимого страницы
Если ваш браузер не отображает страницу правильно, пожалуйста, читайте содержимое страницы ниже
Внедрение Oracle E-Business Suite.
Проблемы, риски, результаты
Пушников Андрей,
к.ф.-м.н, PMPПлан презентации
Предпосылки проекта
Начало (организация работ)
Ход проекта
Анализ
Приятно рассказывать о проекте, выполненном в рамках
бюджета, в оговоренные сроки и к полному удовлетворению
Заказчика.
Но полезнее поделиться с друзьями граблями.
Итак, грабли и засады…
2 Предпосылки проекта
Начало (организация работ)
Ход проекта
Анализ
3Предпосылки и окружение проекта
Одно из крупнейших внедрений OEBS в России
2002 2003 2004 2005 2006
май июнь сент фев окт дек
Внедрение OEBS (18
модулей) – Большой взрыв
Кадры
Зарплата
Ремонты
BIS
Другие проекты…
4 Предпосылки проекта
Начало (организация работ)
Ход проекта
Анализ
5Восстановление управления проектом
Цели проекта
1. Доработка системы по результатам анализа
2. Тщательное тестирование системы в режиме параллельной
эксплуатации
3. Внедрение системы в промышленную эксплуатацию
Процедуры управления
1. Новый Устав проекта
2. Периодическая отчетность по проекту
3. Регулярные встречи Управляющего Комитета
4. Регламент утверждения документов проекта
5. Подготовка плана и сценариев тестирования
6. Разработка процедуры регистрации и устранения замечаний
Стратегия перехода
Разработка критериев готовности к переходу в
- опытную эксплуатацию
- опытно - промышленную эксплуатацию
- промышленную эксплуатацию
Основа стратегии перехода – достижение
критериев готовности 6Приоритеты проекта
(триединое ограничение)
1. Качество (ключевой приоритет)
- Обеспечение качества является основным ограничением данного
Проекта
2. Сроки (желательный приоритет)
- Обеспечение плановых сроков является ограничением, не менее
важным, чем соблюдение качества
3. Ресурсы/Стоимость (по возможности)
- Для соблюдения первых двух ограничений должно быть выделено
необходимое количество ресурсов (квалифицированные сотрудники,
оборудование, внешние консультанты)
Срок полезного использования результата – какой?
[ ] Одноразовое применение, временный вариант: Вся система будет
аннулирована или заменена
[ ] Поставка и отладка: Поставка, затем отладка недостатков, модернизация
[ ] Долгосрочное использование: Необходимо идеальное состояние в момент
выпуска
А вообще-то ERP внедряют по 2-му варианту.
Но для зарплаты это не проходит…
7План нового проекта
Сентябрь 05
Февраль 05
Декабрь 04
Апрель 05
Январь 05
Август 05
Июнь 05
Июль 05
Март 05
Май 05
Этап 1 Тестирование и доработка (2 мес)
Опытная эксплуатация на
Этап 2 - ОЭ одном подразделении (2 мес)
Опытно-промышленная
Этап 3 - ОПЭ эксплуатация на всем
предприятии (3 мес)
Промышленная эксплуатация
Этап 4 - ПЭ на всем предприятии (1.5 мес)
- Контрольная точка
8Структура проектной команды
Председатель Управляющий комитет
Фин.Дир CIO Президент Дир.деп-та Менеджер
Менед.по
PM PM
качеству
Зам.по Зам.по
функц.диз техн.диза Админист Служба поддержки
Oracle
айну йну ратор
Функц.спец-ты Консультанты Инженер
Инженер
Специалист
Специалист
Специалист
Специалист Консультант
Специалис
Специалист
Специалист
Консульта
т нт Разработчики
Исполнителя
Техн.спец-ты Разработчик
Разработчик
Разработч
Специалист
Специалист
ик
Специалист
Специалист
Специалис
Специалист
Специалист
т
Рабочая группа
Исполни
Заказчик Oracle
тель
9Первоначальная оценка рисков
1. Большой объем тестирования – превысим срок
2. Полнота тестирования (непредсказуемые ситуации
при опытной эксплуатации) – недостаточное
качество
3. Недостаточная производительность системы
4. Неготовность конечных пользователей
5. Нехватка ресурсов специалистов, выполняющих
задачи по проекту
6. Плановые работы по изменению конфигурации и
техническому обслуживанию системы –
дополнительные задержки
Объем тестирования и доработок
1. 90 бизнес-процессов (Кадры, Табель, Зарплата)
2. 620 сценариев тестирования расчета зарплаты
3. 170 отчетов
Поехали…
10 Предпосылки проекта
Начало (организация работ)
Ход проекта
Анализ
11Декабрь
Январь
Февраль Состояние на март 2005
Март Статус проекта и изменения
Увеличение объема тестирования:
- В начале января Заказчик перешел на новую версию Oracle (c 8
на 9) – требует тестирования
- Принято решение изменить несколько важных архитектурных
решений
В результате:
- Конец января – готовность по критериям перехода к опытной
эксплуатации 30%
- Конец марта – готовность к опытной эксплуатации 90%,
- Протестированы бизнес-процессы, сценарии расчета, отчеты с
приоритетами 1, 2
- Реализованы новые архитектурные решения
12Декабрь
Январь
Состояние на март 2005
Февраль Анализ рисков
Март
1. Неутвержденный алгоритм расчета среднего заработка в
части индексации
2. Недостаточная производительность системы
3. Высокая вероятность появления проблем, не
обнаруженных при тестировании на ограниченном
объеме данных
4. Недостаток ключевых ресурсов в рабочей группе
5. Высокая вероятность появления новых технических
проблем
6. Высокая вероятность большого количества ошибок
пользователей, нарушение регламента расчета
13Декабрь
Январь Состояние на март 2005
Февраль Перепланирование
Март
1. Первоначальный план проекта –
сверхоптимистичный, нереализуемый.
- Первоначальный план проекта переоценивал степень
готовности системы
- В первоначальном плане проекта отсутствовали резервы
2. По текущему плану ведения проекта в план-график
заложен резерв
- Имеется резерв в 1 месяц на непредвиденные ситуации
- Возможное использование резерва – увеличение срока
опытной эксплуатации с 2-х до 3-х месяцев – решение должно
быть принято по итогам 2-х месяцев ОЭ (конец мая)
Обоснование:
- Недостаточное время для отработки регламента запуска
процессов:
- При опытной эксплуатации в течении 2-х месяцев второй расчет
зарплаты произойдет уже в ходе следующего этапа (опытно-
промышленной эксплуатации по всему предприятию)
- Вероятность выявления проблем, не обнаруженных в ходе
тестирования на ограниченном объеме данных
- Высокая вероятность появления новых технических проблем
- Повышенная загрузка членов рабочей группы – поддержка
пользователей и продолжение тестирования
14Декабрь Состояние на март 2005
Январь
Февраль Перепланирование
Сентябрь 05
Февраль 05
Октябрь 05
Декабрь 04
Январь 05
Апрель 05
Март
Август 05
Июнь 05
Июль 05
Март 05
Май 05
Тестирование и доработка
Этап 1
Опытная эксплуатация на
Этап 2 - ОЭ одном подразделении (2 мес)
Этап 3 - ОПЭ Опытно-промышленная
эксплуатация на всем предприятии
(Уменьшили до 2 мес)
Этап 4 - ПЭ Промышленная эксплуатация
на всем предприятии (1.5 мес)
- Текущий план
- Резерв - Контрольная точка 15Декабрь Состояние на июнь 2005
Январь Статус проекта и изменения
Февраль
Март С апреля – началась опытная эксплуатации на одном
Апрель крупном подразделении
Май Проведен полный расчет в соответствии с регламентом за апрель.
Июнь Результаты расчета:
- Длительность выполнения операций соответствует регламенту
- Зафиксировано большое количество замечаний, не выявленных в
ходе тестирования
- Запаздывание по регламенту – 1 месяц (за счет затрат времени на
устранения замечаний)
Критические факторы:
- На предприятии проводится плановое повышение зарплаты
- Получены разъяснения по алгоритмам расчета зарплаты от
Минздравсоцразвития РФ, Гос.инспекции по труду (17.05.2005)
- Согласованы алгоритмы расчета средней заработной платы
В результате:
- Полностью переработан алгоритм расчета средней заработной
платы (в течении 20.05 – 19.06)
Основная метрика проекта в настоящий момент –
журнал замечаний
16Декабрь Состояние на август 2005
Январь
Февраль
Перепланирование
Сентябрь 05
Октябрь 05
Декабрь 05
Апрель 05
Январь 06
Ноябрь 05
Март
Август 05
Июнь 05
Июль 05
Май 05
Апрель
Май
Июнь
Июль
Август Этап 2 ОЭ
Расчет по
одному
подразделению
Этап 3 ОПЭ Расчет по всему
предприятию с выплатой из старой
системы
Этап 4 Продуктивная эксплуатация с
выплатой из ORACLE E-BUSINESS
SUITE
17Декабрь
Январь
Состояние на август 2005
Февраль Анализ рисков
Март
Апрель 1. ОСНОВНОЙ РИСК. Ошибки при сдаче годовой
Май налоговой отчетности
Июнь - Отчетность поквартальная с нарастающим итогом из 2-х
Июль различных систем
Август
2. Появление новых запросов на уточнение/изменение
алгоритмов расчета – неконтролируемое увеличение
сроков разработки
3. Риск не уложиться в регламент в ходе ОПЭ (ошибки
пользователей и нехватка времени на выполнение
операций)
4. Возникновение непредусмотренных критических проблем
после перехода в продуктивную эксплуатацию
- Вторичные риски:
- 1) Работа пользователей в 2-х системах приводит к
большему количеству ошибок пользователей
- 2) Уменьшение влияния – дополнительный контроль
работы пользователей с использованием отчетов для
сравнения и аудита
18Декабрь
Январь
Состояние на август 2005
Февраль
Март
Апрель
Май Планируем:
Июнь - Уже понятно, что наиболее правильный вариант –
Июль
запуск в промышленную эксплуатацию с начала года
Август - Налоговая отчетность должна сдаваться из одной
системы
- Предложение для Управляющего комитета –
стартовать не раньше ноября
После дополнительного анализа рисков
принято решение о начале промышленной
эксплуатации с начала года
19Декабрь Состояние на декабрь 2005
Январь
Февраль
План проекта
Сентябрь 05
Февраль 06
Октябрь 05
Декабрь 05
Апрель 05
Январь 06
Ноябрь 05
Март
Август 05
Июнь 05
Июль 05
Май 05
Апрель
Май
Июнь
Июль
Август
Сент-рь
Октябрь
Ноябрь
Декабрь Этап 3 ОПЭ Расчет по
всему предприятию с
выплатой из старой
системы
Продуктивный старт с
выплатой из ORACLE
E-BUSINESS SUITE
20Декабрь
Январь
Состояние на декабрь 2006
Февраль Статус проекта и изменения
Март
Апрель
Завершен этап опытно-промышленной
Май
эксплуатации
Июнь - Проведено 3 полных расчета по всему предприятию в
соответствии с регламентом
Июль
Август
- Отклонение от регламента – 3 дня
- Все возникшие замечания по расчетам устранены
Сент-рь
Октябрь - Пользователи обучены
Ноябрь - Система реализована в соответствии с последними
Декабрь требованиями налоговых органов
- Отчеты проверены бухгалтерией предприятия
Изменения в последний момент
- На предприятии проводится плановая реорганизация
- На предприятии проводится плановое повышение заработной
платы
- В декабре приняты новые формы налоговой отчетности
Новогодние подарки для
рабочей группы…
21Декабрь
Январь
Состояние на январь 2006
Февраль Текущий статус проекта
Март
Апрель Система введена в промышленную
Май
Июнь
эксплуатацию с 01.01.06
Июль
Август Подготовлен детальный план (по дням) ввода в
Сент-рь промышленную эксплуатацию системы
Октябрь расчета заработной платы с 01.01.2006
Ноябрь
Декабрь
Январь - План выполняется с опережением графика
Февраль
22 Предпосылки проекта
Начало (организация работ)
Ход проекта
Анализ
23Анализ (что работало, а что – нет)
НЕ РАБОТАЛО
- Классическое детальное планирование проекта
с использованием диаграмм Ганта
- Метод набегающей волны
РАБОТАЛО
- Элементы экстремального управления
проектом
- Условно проект можно разбить на 3 фазы:
- Классическая фаза
- Экстремальная фаза
- Фаза перехода к поддержке
PMBOK: «Проект – это временное предприятие,
предназначенное для создания уникальных продуктов,
услуг или результатов»
Классика…
Дуг ДеКарло: «Экстремальный проект – это комплексное, высокоскоростное,
самокорректирующееся предприятие, во время работы над которым люди
взаимодействуют в поисках желаемого результата в условиях крайней
неопределенности, постоянных изменений и сильного стресса
24Элементы экстремального управления в
РАБОТАЛО проекте
Определение, Опытная и опытно- Переход к
построение промышленная продуктивной
эксплуатация эксплуатации
Классическая фаза
Инструменты: Экстремальная фаза
• Диаграммы Ганта Инструменты:
• Метод «набегающей волны» • Укрупненный план-график
• Еженедельное • Журнал замечаний
перепланирование • Релизы и быстрое
• Жесткое отслеживание тестирование (каждый Фаза перехода к
сроков задач расчет зарплаты – это
поддержке
тестирование релиза)
Инструменты:
• Участие
• Регламент
макс.кол.пользователей
работы
• Диаграммы Ганта – эскизы
пользователей
для отдельных задач
25Элементы экстремального управления в
РАБОТАЛО проекте
Условия возникновения элементов экстремального
проекта
- Невозможность предусмотреть, какие проблемы
появятся (много элементов разработки)
- Невозможность детального классического
планирования
- Затраты очень велики
- Все очень быстро меняется
- Управление по целям и критериям
- Наличие «самокорректирующейся» рабочей группы
- Сотрудники привержены целям проекта (Обеспечение
качества – основное ограничение)
- Сотрудники активны, сами ставят задачи
- Приверженность рабочей группы процессу
«Регистрация замечаний»
- Поверили, что это работает
Аналог в квантовой механике (мир Ньютона и квантовый мир)
На верхнем уровне – диаграмма Ганта
На нижнем уровне – управляемый «хаос»
26Анализ (что работало, а что – нет)
РАБОТАЛО
Измерение всего, что можно измерить
- Журнал замечаний – замечательный инструмент
измерения
- Динамика роста замечаний
- Выявление проблем
- Анализ трендов, прогнозы устранения замечаний
- Сравнение результатов расчета в двух системах
- По группам видов оплат
- По причинам расхождений
27Процедура регистрации и устранения замечаний
Заполнить
Заполнить бланк.
бланк. Приоритет
Описать суть
Описать суть замечания,
Расследовать
Расследовать Зарегистрировать
Зарегистрировать
проблемы,
проблемы, собрать
собрать кто устраняет
дополнительные
дополнительные вв журнале
журнале Журнал
Заполненный
материалы
материалы бланк,
замечаний
замечаний
доп.материалы
Протестировать Провести
Провести работу
работу по
по
Протестировать
результат устранению
устранению проблемы
проблемы
результат
Приоритеты замечаний:
1 – система работать не
может
Журнал
2 – работает в
ограниченном объеме
3, 4 – удобство, Нет
Проблема
интерфейс, пожелания решена?
Роли/Должности
Да Закрыть
Закрыть
замечание Кто обнаружил,
замечание вв
расследовал
журнале
журнале
Администратор
Закрыть замечание может ТОЛЬКО тот, кто
его открыл или расследовал. Кто устранял
Исполнитель замечание закрыть НЕ МОЖЕТ – Журнал
от должен убедить Заказчика
28Анализ (что работало, а что – нет)
Методология внедрения Oracle
РАБОТАЛО Applications (AIM)
Application Implementation Method
Определение Анализ Разработка Построение Переход к Эксплуатация
стратегии операций решения решения новой системе
Определение бизнес-требований
Отображение требований
Разработка архитектуры системы
Разработка и построение модулей
Перевод данных
Разработка документации
Испытания на соответствие бизнес-требованиям
Испытания производительности системы
Подготовка персонала
Перевод предприятия на новую систему
29Заключение
С чем повезло в проекте
Как бы дано свыше в виде подарка…
- Психологическая совместимость руководителей
проекта
- Замечательный Спонсор
- Исполнял роль «защитника» проекта с риском для своей
карьеры
- Закаленная проектная группа
- Спорщики
- Ничему не верят, все проверяют
Опираться можно только на то, что
оказывает сопротивление.
Господи, но как с ними трудно!...
- Защита проекта со стороны Oracle
- Поддержка
- Консультации
Добрый совет старшего друга...
30Заключение
С чем не повезло в проекте А это как бы в нагрузку к подаркам…
- Жизнь не ждет окончания проекта
- Реорганизации на предприятии
- Проведение индексации заработной платы
- Изменения законодательства
Все это дополнительные риски…
31ПРОЕКТ – ЭТО, ДЕЙСТВИТЕЛЬНО, ДЖАЗ…
А может, экстремальный спорт…
Вопросы и ответы
32Вы также можете почитать
