Специалисты Исполнителя отработали и успешно применяют технологию ведения проектов аналогичную методологии Oracle AIM for Business Flows - методику внедрения приложений, основанную на использовании стандартных библиотек процессов, адаптированную под архитектуру Adempiere и используемые в ней библиотеки процессов.
В ходе внедрения используются те же типы документов, поскольку они изначально вытекают из рекомендаций по ведению проектов PMBoK и SEBoK.
• Сознательный отказ от трудоёмкой фазы формализации бизнес-процессов и требований к информационной системе "на бумаге"
• Исключение фазы описания бизнеса "как есть" (as is) и акцент на интенсивное моделирование бизнес-процессов "как будет" (to be)
• Активное использование работающего прототипа будущей системы, претерпевающего развитие от некоторой типовой конфигурации до максимально соответствующей требованиям бизнеса системы
• Максимальное стремление к реализации нестандартных требований бизнеса имеющимися средствами настройки системы
Основным регламентирующим документом является Устав проекта, согласуемый сторонами на первом этапе. Он содержит общие требования заказчика, подробную спецификацию работ и план-график, правила взаимодействия команд проекта со стороны Заказчика и Исполнителя, порядок внесения изменений, общее понимание рисков проекта и способов их снижения и т. п.
Основной формой взаимодействия консультантов и ключевых пользователей системы (владельцев бизнес-процессов) является серия демонстрационных сессий. В ходе сессии консультант демонстрирует пользователю возможности системы и фиксирует отклонения от бизнес-процесса заказчика, согласует необходимые изменения. Изменения обобщаются, вносятся в конфигурацию системы, выполняется следующая итерация.
Внедрение проходит в несколько установленных этапов, на каждом из которых устанавливаются базовые настройки. Сразу после прохождения регламентированных процессом установки этапов можно начинать работу в системе и вводить первые хозяйственные операции.
Рассмотрим основные понятия методики.
Задача в терминах данной методики представляет собой элементарный (неделимый) объём работ, который обязательно заканчивается каким-либо результатом (в большинстве случаев - документом). Все задачи проекта разделены и сгруппированы по фазам и процессам проекта.
Фаза - это группа задач, выполнение которых приводит к достижению важного рубежа в ходе проекта. Фазы делят проект на "вертикальные" (временные) части и создают естественные вехи для контроля выполнения проекта.
Выделяют 5 фаз проекта:
- "Определение". Содержит задачи определения и анализа, а также планирования проекта.
- "Уточнение". Содержит задачи по проектированию будущей системы.
- "Построение". Объединяет задачи по настройке системы и разработке её расширений.
- "Переход". Состоит из задач по комплексному тестированию системы, импорту данных и обучению пользователей.
- "Поддержка". Начало промышленной эксплуатации, развитие системы.
Процесс - это группа задач, объединенная общей функцией и приводящая к разработке ключевых выходных документов, связанных единой темой. Задачи в рамках процесса тесно связаны между собой, задачи одного процесса могут занимать почти весь проект.
Выделяют следующие основные процессы проекта:
- Отображение бизнес-процессов. Целью процесса является анализ того, какая функциональность Adempiere и каким образом может использоваться для реализации функциональных возможностей, необходимых Заказчику. В этом процессе окончательно определяется будущая реализация бизнес-процессов Заказчика, определяется размещаемая в системе информация, перечень требуемых доработок, а также значения параметров настройки.
- Прикладная и техническая архитектура. Целью процесса является разработка дизайна архитектуры информационной системы, соответствующего видению бизнес-процессов Заказчика, определяются значения ключевых параметров (например, организационная структура, план счетов Заказчика).
- Проектирование. Процесс фокусируется на разработке расширений, ориентированных на специфические технические требования заказчика.
- Конвертация данных. Целью процесса является конвертация (перенос) всех необходимых данных из имеющихся информационных систем Заказчика, замещаемых в ходе внедрения системы, основная часть работы заключается в подготовке данных для конвертации, определении надежных источников, очистке данных.
- Документирование. Документирование начинается с самой ранней стадии проекта, включает в себя подготовку технических и пользовательских материалов с учетом специфики заказчика.
- Тестирование решений. Целью процесса является многократный "прогон" предлагаемого бизнес-решения с помощью проведения итеративных целевых сессий-совещаний и тестирования качества всех элементов решения.
- Освоение и тренинги. Процесс проведения тренингов конечных пользователей (завершение проекта внедрения). Главной целью процесса является способствование принятию новой системы всеми её будущими пользователями.
- Переход к промышленной эксплуатации. В ходе этого процесса рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением. В ходе этого процесса производится настройка параметров системы для промышленной эксплуатации.
В результате методикой внедрения предлагается следующий алгоритм внедрения:
Алгоритм внедрения Adempiere.
В тестовую среду системы вводятся данные, позволяющие демонстрировать все возможности приложения. Проектная группа начинает активно тестировать преднастроенный работающий прототип системы (сессия CRP1).
В ходе CRP1 возможности приложения консультанты-специалисты по приложению демонстрируются по заранее проработанным сценариям показа (что именно кому и с какими данными выполнять). Зрителями и активными участниками CRP1 являются участники проектной группы от предприятия: бизнес-эксперты. При этом достигаются следующие цели:
- Происходит ознакомление бизнес-экспертов предприятия с вариантами использования приложения.
- Выявляются особенности бизнес-процессов предприятия, и собирается орг-структурная информация о предприятии.
На втором этапе проекта прототип системы настраивается на все процессные и структурные особенности бизнеса, реализуемые путем настройки. Корректируются сценарии использования системы в привязке к особенностям бизнеса.
Система, максимально настроенная на особенности бизнеса повторно "прокручивается" по максимально приближенным к реалиям бизнеса сценариям (сессия CRP2). Главной целью CRP2 является разъяснить представителям бизнеса, что использование заложенных в приложение бизнес-процессов эффективно для практики предприятия.
В ходе CRP1 и CRP2 выявляются и документируются все особенности бизнеса, которые не могут быть удовлетворены настройкой приложения и требуют его доработки (если таковые существуют). Одновременно разрабатываются новые сценарии, позволяющие продемонстрировать / протестировать работу системы в "доработанном" варианте.
На второй и третьей фазе выполняются задачи по доработке приложения. На третьей фазе проекта прототип системы, настроенный и доработанный под все особенности бизнеса, опять "прогоняется" проектной группой уже на полностью реальных сценариях (сессия CRP3). Устраняются все замечания и недоработки системы. Цель CRP3 - убедиться в полной работоспособности бизнес-процессов, построенных на использовании системы.
На четвертой фазе проекта все настройки и доработки системы переносятся со среды тестового прототипа в среду промышленной эксплуатации системы. Происходит ввод начальных данных в систему, тренинги для всех пользователей.
На пятой фазе система запускается в эксплуатацию. Проводится интенсивная "работа над ошибками" в течение первого периода эксплуатации системы.
В целях приведения предлагаемого методикой алгоритма внедрения в соответствие со сложившейся практикой внедрения информационных систем в российских организациях весь Проект был разбит на четыре основных Этапа, критерием разбиения является основной значимый результат, достигаемый в ходе выполнения работ Этапа.
Главной задачей данного этапа является выполнение работ по общему планированию проекта, определению его рамок, организационной структуры, способов взаимодействия команды Проекта и т.д. Соответствие Этапа 1 работам алгоритма внедрения указано на нижеследующем рисунке
Соответствие Этапа 1 работам алгоритма внедрения
Главной задачей данного этапа является показ работы демонстрационного экземпляра Системы, и получение согласованных предложений по структуре ключевым настройкам Системы. Соответствие Этапа 2 работам алгоритма внедрения указано на нижеследующем рисунке.
Соответствие Этапа 2 работам алгоритма внедрения
Этап 3. Развёртывание опытного экземпляра Системы и проведение тренингов специалистов Заказчика.
Главной задачей данного этапа является развёртывание на программно-аппаратных средствах Заказчика опытного экземпляра Системы, сконфигурированного с учётом специфики деятельности Заказчика, а также проведение тренингов бизнес-экспертов Заказчика по базовой функциональности внедряемых модулей. Соответствие Этапа 3 работам алгоритма внедрения указано на нижеследующем рисунке.
Соответствие Этапа 3 работам алгоритма внедрения
Главной задачей данного этапа является тестирование процедур интеграции с существующими бухгалтерской и PDM-системами на опытном экземпляре Системы, сконфигурированного с учётом специфики деятельности Заказчика, проведение технических и организационных мероприятий по формированию среды промышленной эксплуатации Системы, создание промышленного экземпляра Системы и загрузка данных для начала промышленной эксплуатации и проведение тренингов для конечных пользователей. Соответствие Этапа 4 работам алгоритма внедрения указано на нижеследующем рисунке.
Соответствие Этапа 4 работам алгоритма внедрения
Этап 5. Начало промышленной эксплуатации Системы.
Главной задачей данного этапа является поддержка промышленной эксплуатации Системы, оказание консультаций и разрешение проблем, связанных с запуском Системы в промышленную эксплуатацию. Соответствие Этапа 5 работам алгоритма внедрения указано на нижеследующем рисунке.
Соответствие Этапа 5 работам алгоритма внедрения
Общая схема соответствия Этапов Проекта алгоритму внедрения представлена на нижеследующем рисунке.
Общее соответствие Этапов проекта алгоритму внедрения
В результате предложенное разбиение Проекта на Этапы является эффективным способом управления сложностью реализуемого Проекта, обеспечит нарастающее планомерное развитие и позволит эффективно проконтролировать ход выполнения Проекта и, как следствие, достигнуть основных целей и задач Проекта.
Организационная структура Проекта
Организационная структура Проекта
Проект, как временный институт, создаваемый для достижения поставленных целей, должен иметь четкую организационную структуру, обеспечивающую успешное функционирование, коммуникацию и учет интересов основных лиц, вовлеченных в осуществление и управление происходящими переменами.
Для ведения Проекта принята следующая его организационная структура.
Организационная структура Проекта
Для выполнения любой задачи Проекта назначается функциональная роль (одна или несколько), представляющая собой совокупность обязанностей и выполняемых в Проекте функций. Методика ведения Проекта предлагает набор стандартных ролей, например - Спонсор Проекта, Руководитель Проекта, Бизнес-эксперт и т.д. На основе распределения ролей на Проекте определяются тип и количество необходимых ресурсов.
Рассмотрим подробнее описание обязанностей, соответствующих указанным ролям.
Куратор Проекта (со стороны Исполнителя) - это руководитель высшего звена Исполнителя, обеспечивающий поддержку Проекта, определяющий стратегию ведения Проекта, обеспечивающий его ресурсами и участвующий в разрешении проблем проекта, вынесенных на уровень Управляющего совета Проекта.
Основные функции Куратора Проекта:
- Утверждать изменения рамок Проекта.
- Участвовать в управлении Проектом и своевременно принимать решения, обеспечивающие успешное завершение Проекта.
- Идентифицировать выгоды Проекта.
- Обеспечивать финансирование Проекта.
- Обеспечивать решение организационных проблем Проекта.
- Принимать окончательное решение при возникновении спорной ситуации.
- Содействовать в разработке Устава и Календарного плана Проекта.
- Участвовать в завершении работ по зарегистрированным проблемам.
Спонсор Проекта (со стороны Заказчика) - это руководитель высшего звена Заказчика, обеспечивающий поддержку Проекта со стороны руководства.
Роль Спонсора проекта особенно значительна, поскольку он несёт ответственность за то, чтобы средства, выделенные на проект, расходовались разумно, и выполняемые задачи действительно были направлены на создание полезных для Заказчика выходных результатов Проекта. Спонсор Проекта принимает окончательное решение в случае возникновения противоречий в подходах к работе и задачах проекта.
Основные функции Спонсора Проекта:
- Утверждать изменения рамок Проекта.
- Участвовать в управлении Проектом и своевременно принимать решения, обеспечивающие успешное завершение Проекта.
- Идентифицировать выгоды Проекта.
- Обеспечивать финансирование Проекта.
- Обеспечивать решение организационных проблем Проекта.
- Принимать окончательное решение при возникновении спорной ситуации.
- Содействовать в разработке Устава и Календарного плана Проекта.
- Участвовать в завершении работ по зарегистрированным проблемам.
Руководитель Проекта (со стороны Исполнителя) - ответственный за выполнение работ Проекта. Руководитель проекта на регулярной основе доводит до Управляющего совета информацию о состоянии Проекта, о наиболее значительных проблемах, возникших в ходе проекта, и ключевых документах, подготовленных проектной группой. Он информирует Спонсора проекта о мерах, необходимых для обеспечения своевременного и качественного выполнения задач проекта.
Обязанности Руководителя Проекта со стороны Исполнителя:
- Обеспечивать функциональное качество разрабатываемого решения.
- Утверждать подходы к работе и принимать результаты Проекта в соответствии с утвержденными подходами.
- Контролировать технические аспекты Проекта.
- Ежедневно контролировать работу Команды Проекта.
- Разработать и поддерживать в актуальном состоянии Устав проекта и План проекта
- Проводить формальные проверки.
- Участвовать в решении проблем.
- Контролировать процесс решения и закрытия проблем.
- Контролировать основные показатели Проекта (сроки, рамки, бюджет).
Координатор Проекта (со стороны Заказчика) - ответственный руководитель Заказчика, контролирующий и координирующий ход работ Проекта со стороны Заказчика.
Помимо обязанностей, указанных для Руководителя Проекта со стороны Исполнителя, Руководителя Проекта со стороны Заказчика:
- Отвечает за организацию проектных работ со стороны Заказчика.
- Обеспечивает поддержку проекта со стороны Заказчика по работам, производимым на предприятии.
- Обеспечивает доступность ресурсов и взаимодействие персонала со стороны Заказчика.
Консультант - специалист, ответственный за корректную постановку автоматизируемых бизнес-процессов Заказчика и их методическое обеспечение, непосредственно выполняющий работы по конфигурированию и настройке Системы.
Основные обязанности бизнес-аналитика:
- Формальное описание бизнес-процессов Заказчика.
- Анализ бизнес-процессов предприятия на предмет непротиворечивости;
- Согласование моделей бизнес-процессов со специалистами Заказчика для отражения данных моделей в документах по конфигурированию Системы.
- В пределах своей компетенции решение вопросов, связанных с проведением работ.
В Проекте представлены бизнес-аналитики со стороны Исполнителя.
В целях передачи знаний и более эффективных коммуникаций в Проект могут быть введены консультанты со стороны Заказчика.
Системный архитектор - специалист, непосредственно выполняющий работы по установке и администрированию Системы, а также отвечающий за техническую архитектуру Системы.
В Проекте представлен системный архитектор со стороны Исполнителя.
В целях передачи знаний и более эффективных коммуникаций в Проект может быть введен системный архитектор со стороны Заказчика.
Функциональный архитектор - специалист, отвечающий за:
- общесистемные настройки;
- регистрацию новых пользователей;
- правильность конфигурации и использования модулей системы;
- стыковку системы с внешними приложениями;
- импорт начальных данных в систему;
- обеспечение пользователей учебными материалами по работе с Системой;
- отслеживание развития функциональных возможностей Системы (Этап 5. Начало промышленной эксплуатации);
- отработку технических запросов и заявок пользователей, работающих в Системе в процессе технической поддержки (Этап 5. Начало промышленной эксплуатации).
Разработчик - специалист, непосредственно выполняющий работы по разработке дополнительной функциональности Системы.
Бизнес-эксперт - это ключевой предметный специалист Заказчика, обеспечивающий экспертизу в соответствующей предметной области бизнеса для создания выходных результатов Проекта. Как правило, бизнес-эксперт не выполняет самостоятельно работы на Проекте, а обеспечивают необходимой информацией бизнес-аналитиков, которые готовят выходные результаты Проекта. Исключение составляют целевые сессии-совещания по тестированию бизнес-процессов в Системе, на которых бизнес-эксперт выступает в качестве ключевого специалиста, ответственного за корректность отражения предметной области и автоматизируемых бизнес-процессов в Системе. Основные обязанности бизнес-эксперта:
- Обеспечивать экспертизу по текущему состоянию бизнес-процессов.
- Представлять область бизнеса при формировании видения будущей информационной Системы.
- Эффективно обеспечивать Команду Проекта информацией и участвовать в проектной работе. При необходимости для предоставления информации привлекать других сотрудников предприятия из соответствующих подразделений.
- Активно способствовать обмену знаниями в условиях работы проектной группы.
- Участвовать в целевых сессиях-совещаниях (CRP), представлять замечания и предложения по построению бизнес-процессов Заказчика с помощью Системы.
- Является ответственным за корректное отражение предметной области бизнеса в Системе.
Перечисленные выше функциональные роли объединены в управляющую (Управляющий совет) и исполнительную (Команда Проекта) структуры Проекта.
В соответствии с организационной структурой Проекта в состав Управляющего совета входят:
- Куратор Проекта со стороны Исполнителя.
- Спонсор Проекта со стороны Заказчика.
- Руководитель Проекта со стороны Исполнителя.
- Координатор Проекта со стороны Заказчика.
Управляющий совет выступает как коллективный эксперт Проекта. Управляющий совет обеспечивает движение Проекта в соответствующих областях бизнеса и способствует достижению целей Проекта, определённых в Уставе Проекта. В частности, Управляющий совет должен способствовать созданию благоприятного климата для реализации Проекта и проведению требуемых изменений.
Управляющий совет имеет полномочия поднимать вопросы, связанные с изменением рамок Проекта и выделением финансирования на Проект.
Работа управляющего совета происходит путем регулярных заседаний. На данном Проекте Управляющий совет должен собираться не реже 1 раза в 4 недели. Собрания Управляющего совета могут быть приурочены к знаковым событиям (вехам) Проекта.
Основные обязанности участников Управляющего совета:
- Увязка и согласование интересов различных областей бизнеса.
- Решение проблем, вынесенных на рассмотрение Управляющего совета.
- Содействие продвижению Проекта.
- Участие в регулярных заседаниях Управляющего совета.
Команда Проекта состоит из специалистов Исполнителя и выделенных сотрудников Заказчика. Каждый участник Команды Проекта должен выполнять конкретные задачи по подготовке рабочих продуктов Проекта и отчитываться за свою работу перед соответствующим Руководителем Проекта (со стороны Исполнителя, со стороны Заказчика). Все члены Команды Проекта, работая в тесном сотрудничестве и обмениваясь полученными знаниями при взаимодействии, обеспечивают достижение целей Проекта.
Работа проектной группы базируется на следующих принципах:
- Вся работа выполняется группой, каждый член которой несет персональную ответственность за выполнение порученного задания перед Руководителем проекта или Координатором проекта;
- Все члены группы тщательно документируют результаты своей работы в заранее установленном формате представления;
- Каждый член группы отвечает за результаты работы всей группы и при необходимости может быть привлечен к выполнению работ, не входящих в сферу его непосредственной ответственности.