Оглавление

Статья I. Необыкновенное чудо: BW on HANA

Раздел 1.01 О компании

Раздел 1.02 Введение

Два хранилища

Раздел 1.03

Раздел 1.04 SAP BW on HANA – наше всё

Раздел 1.05 Предпроектный этап. Построение объёма проекта

Раздел 1.06 Этапы и стадии жизни проекта

(a) Подготовительный этап

(b) Этап реализации

(c) Окончание проекта

Раздел 1.07 Итоги

(a) Основные достижения

(b) Проблемы перехода

Статья I. Необыкновенное чудо: BW on HANA

Раздел 1.01 О компании

«М.Видео» – лидер среди розничных сетей по продаже электроники и бытовой техники в России и одна из крупнейших европейских компаний в этом сегменте. Кроме того, «М.Видео» – единственная публичная российская непродуктовая сеть. С ноября 2007 года торговля акциями ПАО «М.Видео» идёт на ведущих российских биржевых площадках – РТС и ММВБ (тикер: MVID).

Сеть «М.Видео» основана в марте 1993 года. На весну 2017 года 399 магазинов сети работают в 165 городах России.

Товарный ассортимент магазинов «М.Видео» превышает 20 тысяч наименований техники: аудио/видео и цифрового направлений, мелкой и крупной бытовой электроники, товаров для развлечения и аксессуаров. Для магазинов «М.Видео» разработан специальный единый формат торгового зала площадью 1500–1 800м².

Раздел 1.02 Введение

В 2012 году, в компании «М.Видео», был дан старт проекту по переходу на новое хранилище SAP BW on HANA. Общую информацию по данному проекту можно почерпнуть в первой статье цикла, которая находится по адресу http://sapland.ru/file/neobiknovennoe-chudo-bw-on-hana-god-opita-v-riteile-2.html.

Процесс перехода состоял из двух этапов. Первый этап описан в указанной выше статье. Второй (заключительный этап) будет кратко изложен в данной статье.

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

Данная статья будет полезна участникам проектов перехода на SAP BW on HANA, так как я постарался в общем виде описать используемый нами подход и по возможности расписал основные подводные камни, с которыми мы столкнулись.

Раздел 1.03 Два хранилища

В 2014 года в компании М. Видео существовали:

1. SAP BW on HANA – новая инсталляция SAP BW которая была создана в 2012 году. Тогда же туда были перенесены основные отчёты компании и системы планирования;
2. SAP BW on Oracle - старая система отчётности, из которой переносилась функциональность на новую систему отчётности.

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

Такая ситуация сложилась в связи с принятой методологией перехода на SAP BW on HANA. Мы не производили миграцию текущей функциональности, мы поставили новую инсталляцию и заново делали там все разработки. При переносе разработок проводился их рефакторинг.

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

Раздел 1.04 SAP BW on HANA – наше всё

Так как к 2015 году, система SAP BW on HANA доказала свою жизнеспособность, было принято окончательно решение о переходе нашей компании полностью на SAP BW on HANA.

Основные цели, которые мы преследовали:

1. Все данные должны грузиться напрямую в SAP BW on HANA из исходных систем;
2. Все пользователи должны смотреть отчёты только в новой системе. Для отчётов мы одновременно переходили с SAP ANALYZER на SAP Analysis for Microsoft Excel.

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

1. Воссоздаем старые отчёты BeX один в один в новой системы;
2. Пересоздаём потоки данных в новой системе, используя по максимуму DSO и минимизируя количество промежуточных уровней хранения;
3. Проводим техническую сверку данных в отчётах, и если данные равны, то высылаем инструкцию пользователям. Теперь за своими отчётами они заходят в новый инструмент и используют новое соединение.

Раздел 1.05 Предпроектный этап. Построение объёма проекта

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

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

1. Если в новой системе есть аналогичный объект, то мы используем его, при необходимости расширяя;
2. Если аналогичного объекта в новой системе нет, то создаем новый.

Все