Маховик для BW/BI проекта
Решения и услуги Новости компании
10 февраля 2014г. ОАО «БК Софт» (BC Soft) и ООО «ФИТКОН», входящие в Группу ITG Consulting, завершили настройку процессов обмена электронными счетами-фактурами в российском представитель стве концерна АББ.
Рады сообщить о старте системы ИУС П ГК и о начале проведения опытной эксплуатации.

Все новости...
Главная » Пресс-центр » Опубликованные статьи

Маховик для BW/BI проекта

Маховик (маховое колесо) — массивное вращающееся колесо, использующееся в качестве накопителя (инерционный аккумулятор) кинетической энергии.
Википедия.
Краткая справка по проекту.
Название проекта – шаблон информационной управляющей системы для генерирующих компаний (ИУС П ГК).
Цель проекта – комплексное повышение эффективности управления деятельностью по генерации электроэнергии, производству и сбыту тепловой энергии в компаниях с долевым участием ОАО «Газпром».
Задачи проекта:

  • Улучшение существующих бизнес-процессов путем их автоматизации;
  • Совершенствование и стандартизация методологической и нормативно-справочной базы;
  • Проектирование системы с учетом существующих горизонтальных и вертикальных связей, унификация процессов;
  • Развитие технической инфраструктуры;
  • Разработка единой технологии информационного взаимодействия между участниками процессов;
  • Внедрение информационно-управляющей системы на организационном объеме проекта.

Функциональный объем:

  • Ведение договоров;
  • Управление маркетингом и сбытом;
  • Управление финансами и управленческий учет;
  • Бюджетирование и бизнес-аналитика;
  • Бухгалтерский и налоговый учет;
  • Управление снабжением МТР, управление ТОиР, управление инвестициями;
  • Интеграция с локальными системами и системами ОАО «Газпром».

Особенности проекта:

  • Территориальная распределенность: 12 регионов РФ;
  • 6 тысяч пользователей системы.

Подсистема бюджетирования и аналитической отчетности

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

  • Годовое планирование, в т.ч. планирование по следующим направлениям:
    • Планирование выручки;
    • Планирование производственной программы;
    • Планирование затрат на топливо.
  • Планирование затрат на ремонты;
  • Планирование запасов и закупок;
  • Планирование затрат на персонал;
  • Планирование инвестиций;
  • Планирование прочих доходов и расходов;
  • Формирование Бюджета Доходов и Расходов;
  • Формирование Бюджета Движения Денежных Средств;
  • Формирование Прогнозного Баланса;
  • Формирование Бизнес плана Общества;
  • Квартальное планирование;

Количественные показатели объема проекте BW/BI:

  • Плановые и фактические бюджетные формы – 170 форм;
  • Общекорпоративная отчетность (ОКО) – 168 отчетных форм;
  • Унифицированная и фискальная отчетность – 197 отчетных форм.

Суммарное число форм BW/BI на момент передачи в промышленную эксплуатацию: 535.

Организация проекта BW/BI

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

  • Штатные сотрудники – 9 человек;
  • Фрилансеры – 41 человек.

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

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

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

Единый классификатор.

Использование и централизованное ведение файла «Единый классификатор» (ЕК) не позволило допустить размножение в системе одинаковых признаков и показателей с разными названиями.

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

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

Загрузки всех статических справочников с ручным ведением значений было организовано через Единый классификатор. В ЕК ответственный за наполнение вводил значения которые в последствие выгружались в файл для загрузки в систему.

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

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

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

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

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

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

Спецификация на разработку

Организация процесса реализации бюджетов и аналитических отчетных форм при условии линейного взаимодействия разработчика с Заказчиком в большинстве случаев бывает обусловлена отсутствием в компании методологов и редко когда приводят к положительному результату. На реализованном проекте ИУС П ГК группа методологов только по бюджетированию состояла из 14 человек. Для аналитической отчетности по бизнес-направлениям методологами выступали руководители ответственные за соответствующие SAP модули.

Подход, когда проработкой требований к аналитической отчетности занимается SAP консультант соответствующего направления, а проработкой постановки на реализацию  бюджета методолог по бюджетированию, полностью себя оправдал. Ответственность за написание спецификации на разработку и последующую сдачу отчета или бюджета лежали соответственно на консультанте SAP по направлению или методологе, разработчик при этом обеспечивал техническое сопровождение разработки. Такой подход позволил в сжатые сроки, при ограниченном объеме доступных ресурсов консультантов SAP BW/BI организовать и выполнить весь запланированный объем реализации.

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

LSA архитектура

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

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

Управление разработками

Управление разработками, разработчиками (40 из которых работали удаленно) и контроль за своевременным выполнением реализации осуществлялись посредством реестра разработок в котором для всех разрабатываемых отчетов/бюджетов отслеживались следующие параметры:

  • Статус и ФИО ответственного за разработку и реализацию спецификации;
  • Куратор разработчика и автора спецификации;
  • ФИО тестировщика;
  • Плановые и фактические даты:
    • Готовности спецификации;
    • Начала и готовности реализации;
    • Тестирования реализации.
  • Трудозатраты на:
    • Разработку спецификации;
    • Реализацию;
    • Тестирование.


На основании информации ведущейся в реестре разработки формировались предупреждения по отклонениям и рискам проекта:

  • Просроченная реализация;
  • Просроченное назначение даты теста;
  • Просроченное тестирование;
  • Просроченная сдача.

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

 

Все приведенные выше принципы и обеспечительные документы подкреплялись внутренними регламентами и правилами работы на проекте. В ситуации, когда объем привлекаемого внешнего консалтинга в пять раз превышает собственный ресурсы, только жесткая система ограничений, требований и правил позволили выстроить процесс таким образом, что 170 бюджетных форм и 265 аналитических отчетов были реализованы и запущены в промышленную эксплуатацию.
Все вместе: регламентирующие документы, правила, ограничения, принципы, методики контроля и отслеживания реализации – все вместе это являлось маховиком SAP BW/BI, который будучи запущен на старте проекта только набирал обороты, продолжал равноускоренное вращение и сохранил свою инерцию до этапа поддержки и развития проекта – реализации объема функционала второй очереди.

Результаты проекта

  • Разработано многоуровневое масштабируемое информационное хранилище данных, обеспечивающее ежедневное функционирование более пятисот бюджетных форм и аналитических отчетов;
  • Разработано и внедрено уникальное комплексное решение по автоматизации процессов бюджетного управления предприятиями электроэнергетического комплекса.
  • В рамках данной разработки была переработана нормативная база, приведены к единому стандарту аналитики планирования путем внедрения Единого Бюджетного Классификатора, они приведены в полную симметрию процессам и аналитикам фактического учета.
  • В процесс планирования вовлечены все подразделения компании Заказчика, что обеспечивает своевременное предоставление подразделениям требуемых ресурсов.
  • Разработана система согласования на базе SAP WorkFlow и RCM, предоставляющая комплекс инструментов для организации и управления процессом планирования: заместители, сроки, задачи в почте, мониторинг и т.д. Разработка позволяет соединить все процессы планирования и согласования бюджетов в единую прозрачную систему с учетом связей и зависимостей между бюджетами.
  • Для администратора бюджетных компаний разработан многофункциональный пульт управления позволяющий контролировать статус формирования и согласования бюджеов в рамках каждой отдельной бюджетной компании.