Roadmap по ключевым результатам (deliverables) проекта внедрения Oracle Hyperion Planning.

Roadmap по ключевым результатам (deliverables) проекта внедрения Oracle Hyperion Planning.

Две потенциально возможные методологии реализации:

  • Каскадный (Waterfall) метод
  • Итерационный (Agile) метод

Так как чаще всего применяется Каскадный метод (он же является основой методологи AIM), то рассмотрим его подробней. Схема описания метода приведенная в статье, рекомендуется для использования как Roadmap при общении с Заказчиком.

Buterin Sergey

https://www.linkedin.com/in/kayros

Russia: +7 968 617 8959, Ukraine: +38 063 1263710

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

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

Две потенциально возможные методологии реализации

Есть опыт применения двух основных различных метода:

  • Каскадный (Waterfall) метод на рисунке 1
  • Итерационный (Agile) метод на рисунке 2

Рис. 1

Рис.2

Эти методы, прежде всего, различаются акцентами:

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

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

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

В рамках методологии AIM существует два типа результата (Deliverables):

  • Формальный документ
  • Реализация функционала системы

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

На рисунке 3 приведена схема основных результатов проекта при использовании каскадного метода и взаимосвязь между ними.

Рис. 3

Краткое описание и значение каждого результата (deliverables):

  • Запрос на предложение (RFP) – от наличия данного документа выигрывает, прежде всего, Заказчик. От его полноты и корректности во многом зависит будущая стоимость и содержание продукта. Так же это может сохранить время и нервы Заказчику, так как в случае тендера не придется отвечать на одни и те же вопросы различным потенциальным Исполнителям. Так же стоить отметить, что любые неясности Исполнитель трактует как риск и закладывает дополнительную стоимость. Либо для формирования приемлемой цены исключает из коммерческого, чтобы в дальнейшем трактовать как дополнительные желания вне границ и будет настаивать на увеличении стоимости проекта в рамках изменения Границ проекта.

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

  • Требования верхнего уровня – это неформальный документ. Это результат собеседования, проведенного Исполнителем с целью выявления потребностей Заказчика, для формирования Коммерческого предложения и настройки демонстрационного примера для проведения презентации продукта в рамках CRP1. Чем менее детально прописан RFP, тем больше работы необходимо проделать в рамках этой задачи. Но так как этот документ не является формальным, Заказчику тяжело будет уже во время проекта апеллировать к нему. Совет – подписывать протоколы по результатам этих собеседований. Если это не противоречит политике компании – то в рамках этой задачи, Заказчику необходимо передать используемую модель Исполнителю.
  • ДЕМО1 (CRP1)– демонстрационная презентация возможностей системы с пред настроенным примером. Чаще всего это первое знакомство Заказчика с продуктом в «живую». Совет – делать акцент не на интерфейсе и технических возможностях, а на решаемых бизнес задачах с помощью продукта.
  • Технико-коммерческое предложение (ТКП) – данный документ должен достаточно детально описывать предложение по автоматизации и нередко вкладывается в Договор, как приложение к нему. Содержит явным образом описанные цели, задачи и рамки проекта. Описан подход к реализации (методология) и архитектура верхнего уровня. Указана команда Исполнителя и крайне важно до принятия решения провести собеседования со всеми ее участниками для подтверждения их квалификации. И основной пункт – это стоимость. Допускается указание «вилки» по цене, которая будет уточнена в течение проекта.
  • Договор – юридически оформленный документ на услуги между Заказчиком и Исполнителем, после подписания которого официально начинается проект.
  • Бюджетная модель Заказчика. Если это excel – это значительно облегчает задачу автоматизации. При добавлении к ней Регламента и политики безопасности, дает детальную картину требуемого решения. Если это 1C или другой программный продукт – то необходима документация и доступ к системе для анализа.
  • Устав и Границы проекта (PSU[1]). Это может быть как два документа, так и один Устав в котором есть отдельный раздел Границы. Данный документ во много по содержанию похож на ТКП, если оно написано качественно. Основные различия:
    • Детальное описание по работе с Рисками
    • Описание процедуры по работе с Запросами на изменения (CR)
    • Описание организационной структуры проекта и привязка конкретных людей к ролям
    • Организационные вопросы проектного офиса

Так же важным отличием данного документа от ТКП  является то, что он создается после заключения Договора и может               опираться на информацию, которую Заказчик не мог передать Исполнителю раньше. Например – бюджетная модель может не передавать до старта проекта.

  • Детальный план проекта (CPMP[2]). План верхнего уровня формируется еще на этапе ТКП, в котором указаны только фазы и сроки по этим фазам. Детальный план должен содержать конкретные задачи с привязанными к ним ресурсами. Крайне желательно, что бы задачи в плане были длительностью не более 1 недели.
  • Бизнес требования (RD). Данный документ описывает детальные бизнес требования, которые должны быть автоматизированы в рамках проекта. На базе этого документа строится архитектура решения (при этом стараясь не противоречить архитектуре описанной в ТКП). В данный документ должны быть включены все согласованные требования бизнеса Заказчика (не только ключевых пользователей).

Необходимые разделы документа:

  • Описание автоматизируемых функциональных процессов – текущее планирование, стратегическое планирование, прогнозирование, план-факт
  • Формируемые бюджеты – Операционные, Основные
  • Описание справочников системы
  • Альбом форм и отчетов. Если необходимы расчеты на уровне форм или отчета, их лучше зафиксировать в этом разделе.
  • Требования к ad-hoc возможностям
  • Политика безопасности
  • Требования к процессу утверждения
  • Фиксация алгоритмов расчета, в случае отсутствия их в ранее переданной Бюджетной модели (например – аллокации).
  • Требования к интеграции с внешними системами

Не редко, для подписания RD, Заказчик требует демонстрацию системы, что бы иметь представление о способе реализации требований.

  • ДЕМО2 (CRP2) – демонстрация системы с примерами реализации требований. Этот демо показ так же используется для обучения ключевых пользователей и от него во многом зависит желание ключевых пользователей работать с системой. Следует изначально ставить ударения на том, что решение не должно стать конечным продуктом, а лишь инструментом для реализации возникающих в рабочем процессе задач.
  • Архитектура системы (TA). По сути, данный документ должен описывать будущую систему, настроенную согласно Бизнес требований. Но в отличие от документа RD, который должен быть подписан бизнесом и поэтому пишется без применения терминологии целевой системы, TA пишется в терминологии будущей системы и подписывает его соответственно Архитектор Заказчика.

ТА должен содержать:

  • Функциональная архитектура
    • Приложения, кубы, справочники
    • Data Dictionary
    • Workflow
    • Task list
    • Матрица безопасности
    • Интеграция между приложениями
    • Техническая архитектура
      • Программное обеспечение
      • Аппаратное обеспечение
      • Параметры приложений
    • Интеграция с внешними системами
    • Расширения стандартного функционала (MD). Данный документ содержит спецификации для разработки функционала необходимого для реализации требований, но не покрываемого стандартным функционалом системы.
    • Разработка решения. Работы по разработке решения. Эта задача по объему занимает половину всего проекта и должна быть предметом не этого документа.
    • Тест-кейсы. Ключевым фактором успеха проекта является заложенные в начале проекта критерии приемки системы. Одним из этих критериев должны быть согласованные и сформированные Заказчиком Тест-кейсы. Они должны позволять в полном объеме протестировать математику решения и пройти бизнес процесс. Зачастую Тест-кейсы состоят из текстового файла со сценариями тестирования и excel файлы для тестирования математики. Идеальный вариант, когда для тестирования математики используется заполненная excel модель Заказчика.
    • Приемочное тестирование (TE). Это процедура тестирования решения ключевыми пользователями Заказчика по Тест-Кейсам. В начале этой задачи создается Журнал замечаний, в котором фиксируются как ошибки при тестировании, так и пожелания бизнеса по развитию решения, которые либо сразу, либо впоследствии будут служить ориентирами для развития решения.
    • Перенос решения на продуктивный сервер. После успешного завершения Приемочного тестирования, о чем должно свидетельствовать закрытие всех открытых вопросов в Журнале замечаний, решения переносится на продуктивный сервер.
    • Загрузка исторических данных (CV). Если есть такая необходимость, в систему загружаются исторические данные. Это может быть факт, плановые данные, нормативно-справочная информация. Загрузка может осуществляться как из заранее подготовленных текстовых файлов, так и из внешних систем.
    • Руководство пользователей (DO). Описательная документация пользователей по ролям. Зачастую формируются документы для следующих ролей:
      • Планировщик
      • Функциональный администратор
      • Системный администратор

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

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

[1] Project Start Up

[2] Complete Project Management Plan