Для управления большим числом независимых разработчиков (40 человек) была разработана и применена многоступенчатая система управления и контроля за разработками.

На начальном этапе каждый выходящий на проект специалист BW/BI получал на входе для изучения пакет проектной документации регламентирующей правила и принципы работы:

• Реестр признаков и показателей проекта;
• Требования к разработке BW/BI;
• Регламент разработки ABAP;
• Порядок разработки отчетных форм;
• Общие требования к оформлению отчетов;
• Правила загрузки из плоских файлов;
• Реестр разработанных Bex переменных;
• Реестр источников данных;
• Спецификации на разработку.

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

Реестр признаков и показателей.

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

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

• Ведение перечня всех аналитик и показателей проекта с их наполнением;
• Ведение матрицы использования аналитик в бюджетных формах и отчетах;
• Ведение перечня потоков данных системы;
• Ведение всех мепингов для трансформации данных.

Загрузки всех статических справочников с ручным ведением значений было организовано через реестр.

Требования к разработке BW/BI и ABAP.

Эти документы определяли принципы, подходы и правила по которым разработчикам необходимо было выполнять разработку. Если документ «Регламент разработки ABAP» по большей части был статическим документом с редкими изменениями, то документ «Требования к разработке BW/BI» дорабатывался на всем протяжении проекта, по мере появления наиболее оптимальных решений тех или иных типовых задач.

Только использование единого подхода к реализации позволило после запуска системы в продуктивную эксплуатацию полностью переложить сопровождение системы на штатных сотрудников отказавшись от дорогостоящего фриланса.

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

Управление экстракцией

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

№ п.п.	Вид изменения	Дата	ФИО	Версия	Описание изменения
1	Создание экстрактора	24.04.201...	…	1	Создание экстрактора из таблицы корреспонденций с доп.полями из основных FI-таблиц
2	Расширение экстрактора	02.07.201...	…	2	Расширение