Менеджер проекта. Непосредственный руководитель проектных работ. В случае привлечения к работам специалистов Заказчика, назначается два менеджера проекта – один со стороны Заказчика, другой – со стороны Исполнителя. Их функции во многом сходны, однако, менеджер проекта со стороны Исполнителя ( в отличии от менеджера проекта со стороны Заказчика) отвечает не только за работы, выполняемые его непосредственными подчиненными, но и за успех всего проекта в целом. В первую очередь отвечает за организационную сторону дела: соблюдение графика работ, обеспечение необходимыми ресурсами, разработку и согласование проектных документов, управление рисками, итд. Должен достаточно хорошо понимать суть выполняемых работ, однако, не обязан непосредственно активно участвовать в работах. Обязан выступать арбитром и разрешать все спорные и конфликтные ситуации внутри группы и при взаимодействии с Заказчиком.

Ведущий консультант. «Предметный лидер» проекта. Как правило, эксперт в одной или нескольких областях. Он отвечает за непосредственное выполнение работ и, как правило, несет персональную ответственность за выполнение наиболее сложных участков работ. Вместе с менеджером проекта представляет «ударную силу» проектной группы.

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

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

Технический эксперт. Технический эксперт отвечает за обследование IT инфраструктуры Заказчика, планирование размещения системы на серверах и рабочих станциях сети, решает технические вопросы интеграции информационных систем и оказывает технические консультации остальным членам проектной группы.

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

Следует обратить внимание на тот факт, что одни и те же роли могут исполняться как специалистами со стороны Заказчика, так и со стороны исполнителя. Так, например, у проекта может быть два менеджера проекта, а часть консультантов может быть сотрудниками Исполнителя.

1.6. Этапы проекта

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

Данная методология подразумевает наличие четырех этапов проекта внедрения автоматизированной системы бюджетирования. Каждый последующий этап строится на результатах предыдущего; таким образом, исключительно важно в каждом проекте последовательно пройти все его этапы. При этом следует иметь в виду, что в зависимости от величины и сложности проекта, та или иная фаза может длиться от одного дня до нескольких недель. В данном разделе приводится только общее описание всех этапов. Более детальная характеристика каждого из этапов проекта будет приведена в последующих разделах.

1.6.1. Предпроектный анализ

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

1.6.2. Обследование и проектирование

Данный этап представляет собой детальное обследование существующей методологии и практики бюджетного процесса на предприятии Заказчика и разработку эскизного проекта системы, который фиксируется в документе «Рабочее задание». По результатам детального обследования должно быть достигнуто однозначное понимание всех аспектов бюджетного процесса Заказчика и требований к его автоматизации. По результатам подэтапа проектирования должно быть достигнуто однозначно понимание принципов построения и архитектуры автоматизированной системы, а также функциональный состав информационной системы в разбивке по АРМам и рабочим местам пользователей.

1.6.3. Разработка и внедрение

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

1.6.4. Опытная эксплуатация

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

1.6.5. Анализ результатов

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

1.7. Статус проектной документации

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