Опыт внедрения SAP BW

Первый шаг при построении системы стратегического управления компанией — внедрение информационного хранилища. Поэтому рассмотрим опыт внедрения пакета SAP BW, накопленный в компании SAP на больших проектах.

Этапы внедрения

В типичном проекте внедрения BW можно выделить шесть этапов. Первый — это старт BW-проекта. Затем следуют: сбор сведений о потребностях, настройка системы, подготовка к продуктивному старту и дальнейшие доработки; на последнем этапе происходит проверка эффективности функционирования BW. Такая схема соответствует методологии и особенностям инструментария внедрения ASAP.

Перед началом BW-проекта необходимо четко сформулировать цели и предпосылки — как правило, речь здесь идет о потребностях бизнеса (бизнес-драйверы) или технических факторах. В ряде случаев отделу ИТ нужно заменить старую систему отчетности; иногда в компаниях используется сразу множество (скажем, более десятка) таких систем. Эти системы требуется заменить одной системой поддержки принятия решений. В качестве такой новой системы может выступать SAP BW, особенно если компания уже использует систему SAP R/3. Однако наличие "родной" системной платформы вовсе не есть необходимое условие выбора SAP BW.

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

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

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

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

1. Мыслите по-крупному, но начинайте с малого.
2. Расширение содержания планируйте на будущее.

Вот пример неверной предпосылки: «Мы хотим внедрить SAP BW для финансов, поскольку соответствующие данные у нас уже имеются в системе R/3». При такой позиции использование BW вряд ли принесет реальную пользу. Действительно получить выгоду от внедрения можно только в том случае, если BW применяется в качестве общего хранилища данных для всей компании.

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

Распределение ролей

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

Внутри коллектива внедренцев необходимо разделить обязанности таким образом, чтобы одни люди занимались разработкой клиентской части, а другие — выгрузкой, преобразованием и хранением данных. Внутри технической группы также должны быть лица, ответственные за техническую поддержку инструментов SAP и DBA (поддержка для администратора базы данных).

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

Итак, руководитель проекта по внедрению SAP BW должен иметь лишь общее представление о BW и системах OLTP. От специалистов группы технической поддержки требуются знания в области базиса системы, общие представления о механизме ALE и авторизации. Члены группы по выборке данных должны разбираться в интеграции с OLTP (приложения, бизнес-процессы), знать рабочее место администратора (BW Admin Workbench). Группа администрирования данных включает специалистов, знакомых с инструментами BW Admin Workbench, ABAP и Data modeling, а от участников группы по пользовательским интерфейсам требуется знание средств Business Analyzer, Front-end и Web-программирования. Необходимо, чтобы проектная команда прошла обучение до начала проекта. Очень важно, чтобы все участники посетили начальные курсы по BW и получили представление о возможностях этого инструмента.

План и его реализация

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

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

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

Другие процедуры, которые зачастую приходится выполнять в подобных проектах, связаны с работой онлайновой сервисной системы (Online Service System, OSS) и SAP-поддержкой. Необходимо также определить, кто отвечает за осуществление SAP-поддержки на проекте, за ввод запросов в систему OSS и за доведение до конца обработки запроса через систему OSS.

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

Вообще говоря, для управления проектом в ходе его выполнения руководителю следует регулярно проводить совещания, посвященные текущему состоянию проекта. Оптимально проводить их один раз в неделю в течение 30 мин. Многочасовые совещания очень дорого обходятся и непродуктивны. Отчетность по состоянию проекта должна составляться в разрезе работ в плане проекта. Это основная предпосылка для корректировки плана.

Потребности бизнеса и модели данных

Теперь мы подходим к стадии сбора сведений о бизнес-потребностях. Если что-то упустить на этой стадии, то проект стартует в уменьшенном объеме и с урезанной моделью данных.

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

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

При построении модели данных необходимо обеспечить ее гибкость, опираясь опять-таки на бизнес-потребности. Обратите внимание на строгое определение информационных объектов, а в дальнейшем постарайтесь получить подтверждение правильности выбранной модели. Обсуждая с сотрудниками аспекты реализации модели, не следует употреблять термин модель данных: пользователи этого не понимают. Предпочтительно говорить в терминах бизнеса. Например, если речь идет об анализе клиентов, можно сказать: “Сейчас мы сделаем анализ по группам потребителей, различным классам пользователей. Это то, что вам необходимо?”

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

На этом этапе также очень важно уделить внимание обучению пользователей. Обычно сотрудники в организации очень заняты, и нужно заранее зарезервировать время в их календарях. Определите также, какая документация необходима пользователям. В начале 2001 года компания SAP выпустила новое, облегченное средство подготовки отчетов (SAP BW Reporting made Easy) для BW-документов. Его можно взять за основу — это очень хорошее средство для пользователей, так как многие из них хотят иметь возможность самостоятельно готовить отчетность.

Итак, перечислим принципы и соображения, которые желательно учитывать при определении бизнес-потребностей:

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

Объем проекта

Определив бизнес-потребности, следует сформировать документ, регламентирующий объем проекта. Каждый подписанный документ дает повод констатировать завершение определенной фазы проекта и в то же время позволяет ограничить объем проекта, заявив: “Это то, о чем мы договорились. Это то, что мы хотим реализовать в ходе проекта”.

Оценка объема данных необходима именно на этой стадии, так как далее начинается определение технических потребностей в оборудовании. В документе, описывающем бизнес-потребности, должна содержаться оценка требуемой и проектируемой производительности (считают ли пользователи приемлемым время ответа на запрос на уровне одной минуты или же отклик требуется через 5—10 секунд и т. п.).

В диалоге с пользователями необходимо сделать выбор, какой интерфейс пользователя будет применен в системе. Если все пользователи хотят работать через Web, надлежит применить инструментарий Web. Это может быть средство SAP BW Web Reporting или Web-инструментарий независимого поставщика. Не используйте сразу несколько инструментов. Есть примеры проектов, в которых наряду с Web Reporting использовали другие средства подготовки отчетов на первом внедрении BW, что привело ко многим стрессовым ситуациям в рабочей группе по созданию клиентских рабочих мест. Поэтому на первом этапе лучше использовать один инструментарий, а другие инструменты, если это необходимо, внедрить позже.

Настройка и обкатка системы

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

Осуществив быстрое внедрение в определенной функциональной сфере (например, охватив сбыт и распределение или управление персоналом), необходимо на какое-то время остановиться на этом объеме. Если вы завершили BW-проект в области управления персоналом, не принимайтесь сразу за другую сферу. В будущем вы, безусловно, сможете расширить проект — фактически это бесконечный процесс. Сейчас же очень важно иметь определенную область, полностью готовую к работе на новой основе, — тогда можно переходить к продуктивной эксплуатации. Важно, чтобы клиентские места, система выборки данных и модели данных развивались одновременно, параллельно.

Итак, в фазе реализации следует:

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

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

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

Безусловно, вам следует протоколировать все действия и получаемые результаты. Некоторые ошибки всегда неизбежны, и их полезно протоколировать, документировать — хотя бы делая "снимки" экрана. Если вы сможете воспроизвести ситуацию, вызвавшую ошибку, это поможет SAP решить проблему.

Вот перечень важных задач на этапе конфигурирования:

• начинайте оптимизировать систему и документируйте этот процесс;
• активируйте сбор статистики;
• начинайте работы по транспорту данных в BW;
• готовьте проектную документацию и материалы для обучения пользователей, сделайте создание документации стандартной частью проекта;
• создавайте учебные материалы и готовьте преподавателей в бизнес-подразделениях;
• протоколируйте все результаты,, чтобы накапливать опыт внедрения.

Начало эксплуатации

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

Бывали случаи, когда проекты приходилось закрывать, поскольку не было вовремя проведено обучение пользователей, что сделало невозможным расширение объема данных. Необходимо запланировать проверку готовности к запуску в промышленную эксплуатацию, которая проводится консультантами SAP. Это очень хорошая возможность оптимизации работы системы. Две проверки выполняются до пуска системы в эксплуатацию и одна -- после.

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

Проверка работающей системы должна проводиться через 1—1,5 месяца после пуска в эксплуатацию, когда все пользователи регулярно работают в системе и уже используют инструмент BW в своей деятельности. Теперь уже нет пути назад, но не следует этого пугаться. Обычно пользователи не начинают работать с системой с первого дня. Вы скорее всего будете наблюдать неуклонный рост числа пользователей.

Вот вопросы, которым нужно уделить внимание при подготовке системы к пуску в эксплуатацию:

• организация поддержки и процедуры поддержки;
• тестирование (с реальными данными и в достаточном объеме). Используйте среду продуктивной системы для тестирования с точки зрения производительности и режима стресса. Результаты тестирования должны быть одобрены пользователями;
• обучение пользователей. Сделайте их энтузиастами нового инструмента;
• управление объемом проекта и оценка риска. Не начинайте расширение проекта, пока не запустите систему в промышленную эксплуатацию.
• проверка SAP BW Go live check (осуществляется службой поддержки TCC).

Рабочий режим

Затем вы входите в нормальный режим работы. Кто будет поддерживать работу системы? Многие проекты основываются на консалтинговой поддержке. В этом случае вам необходимо заранее иметь под рукой соответствующую команду поддержки — обычно это люди, которые участвуют в проекте с первых дней. Необходимо исключить попытки привлечения для этого людей из "базиса" — администраторов базы данных, а также пользователей.

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

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

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

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

Оценка проекта

Хороший инструмент для получения независимой, объективной оценки проекта — пакет BW Review. Его целесообразно применять, когда опытные консультанты по SAP BW заканчивают свою работу на проекте. Экспертиза проекта должна проводиться по определенному расписанию — она занимает обычно до двух дней (для некоторых проектов до пяти дней). Результатом могут стать усовершенствования в некоторых областях проекта и некоторые полезные идеи по завершению проекта. В конце проведения экспертизы руководству передаются результаты, содержащие выводы и рекомендации. Программа проведения экспертизы предусматривает совещание по запуску новых проектов, необходимых для удовлетворения всех бизнес-потребностей.

Кроме того, может проводиться экспертиза готовности проектной команды, проектного плана и проектной документации для старта проекта. Несколько экспертиз проводятся и в ходе внедрения. Они связаны с анализом модели данных, проектных решений, потребностей и проектной группы — круг вопросов может быть как сужен, так и расширен. Фактически экспертизы проводятся на разных стадиях внедрения, в том числе совместно с центрами технической компетенции (TCC) SAP.

В отличие от других систем решение SAP BW предлагает готовое бизнес-содержание (BW Business Content). Это позволяет в короткий срок ввести компонент BW в эксплуатацию. Если система SAP BW связана с системой R/3 (OLTP), то можно использовать включенные в BW Content настроенную выборку данных, сценарии и отчетность.

На первой стадии реализации проекта по созданию информационного хранилища вы будете осуществлять выборку в рамках ограниченных предметных областей и использовать исключительно бизнес-содержание, имеющееся в BW (выборки, инфообъекты, источники и кубы), которое поставляется со стандартной системой BW. В этом объеме систему SAP BW можно ввести в действие за 4—8 недель. В результате вы очень быстро получаете результаты для лиц, ответственных за отчетность, а также накапливаете опыт реализации.

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