SAP Activate: Третя фаза Дослідження (Explore)  Частина 1

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

Ключові заходи дослідження:

• Проведення семінарів по вивченню стандартних можливостей  системи
• Підтвердити бізнес-процеси «to be» за допомогою моделей процесів
• Визначити основні дані та організаційні вимоги
• Отримати бізнес-підтвердження дельта-вимог до стандартних процесів у системі і проектних документів
• Збір інформації про кінцевих користувачів, аналіз навчальних потреб та розробка стратегії розгортання навчання
• Управління проектом, відстеження ходу проекту та звітування
• Всі плани необхідно підписати та перевірити їх на відповідність золотим правилам впровадження системи

З огляду на систему (а ми ж саме її впроваджуємо), до цього етапу ми маємо розгорнуту систему, стандартні налаштування такої системи відповідно обсягу проекту, та основні бізнес процеси компанії. Також, проведено навчання на цій, стандартно налаштованій системі, ключових користувачів. Образно кажучи – підготовлений паперовий макет нашого костюма (викрійка) та виконана перша попередня примірка. Розуміємо чого не вистачає, з якої тканини будемо шити, що можна прибрати, бо на стадії «фантазій – яка це буде система» завжди є щось надлишкове.

Розглянемо кроки етапу:

Виконання/моніторинг проекту. Це діяльність Управління проектом – Project Management, яка є основна та безперервна. Ну тут зрозуміло: відстежувати виконання та якість проекту, контролювати зміни, оцінювати ризики та оновлювати статус проекту. Працюйте з SAP Cloud ALM.

Не забувайте про документацію – графік проекту, інформацію про бюджет/вартість, тощо, але не перестарайтесь))), бо всю документацію потрібно тримати в актуальному стані. Виберіть для себе найголовніше.

Керуйте проектними проблемами, ризиками та змінами. У хмарних проектах командам рекомендується використовувати спеціальний документ відстеження проблем на основі відкритого шаблону списку проблем у методології SAP Activate. У локальних проектах таким середовищем є SAP Solution Manager, і залежно від типу та статусу проблеми, її можна безпосередньо передати у компанію SAP для вирішення.

Примітка Alloy: Але обов’язково це має бути система спільного доступу. Це може бути і  MS Excel таблиці, які відкриті на на мережевому ресурсі, але з нашої практики при сумісному доступі до таких таблиць іноді виникали проблеми з затиранням внесених даних різних користувачів при одночасній роботі з такою таблицею. Доволі непогано себе поводять при сумісному доступі таблиці Google. Деякі проекти велись з використанням цього ресурсу.

Готуйте звіти про виконання проекту для різних цілей і аудиторій, чітко повідомляйте про хід виконання ключових заходів, їх завершення, результати та статус відповідно до графіків та бюджету. Щотижня створюйте оновлення статусу проекту. Рекомендується, щоб цей звіт був дуже легким.

Аналіз зацікавлених сторін. Метою аналізу зацікавлених сторін є визначення рівня прийняття або загального ставлення до проекту з боку всіх ключових зацікавлених сторін, а також способів, якими вони можуть вплинути на проект.

Моніторинг цінності. Встановлення стійких механізмів моніторингу та контролю попередньо визначених KPI (Key Performance Indicators) та PPI (Process Performance Indicator) майбутнього процесу та/або змін процесу. Група по прийняттю рішень – Solution Adoption розробляє інформаційну панель KPI та PPI, а також того, як ці показники відстежуються та контролюються під час виконання проекту та після запуску.

Команда впровадження – Application Design and Configuration продовжує майстер класи, навчання, обговорення прийнятих рішень, робочі сесії по бізнес процесам, реалізованим по стандарту, з безпосередньою участю користувачів. Для користувачів має бути представлений новий SAP Fiori UX. Додатки SAP Fiori потрібно оцінити під час відповідності стандартам та вивести на основі бажаних бізнес-результатів.

Семінари для однієї теми можуть проводитися кількома циклами (спринтами), щоб систематично деталізувати рішення. Основна увага приділяється тому, щоб спочатку прояснити ключові рішення (як-от організаційні підрозділи чи концепції основних даних) і стати більш деталізованими з кожним циклом (спринтом). Наприклад, перший семінар для наскрізного процесу може бути зосереджений на рішенні, процесі, організації та ролях. Другий семінар може підтвердити детальні етапи процесу та функціональні можливості та визначити дельта-вимоги. Результатом буде набір підтверджених процесів і початковий перелік дельта-вимог з орієнтовними потенційними рішеннями

Примітка Alloy: Наприклад при обговоренні процесу закупівлі, на першому спринті необхідно визначити які ланки є у процесі закупівлі, які користувачі їх виконують, та які стандартні типи документів системи будуть відповідати яким ланкам процесу. На другому спринті можна вже перейти до деталізації типів документів, які необхідно буде створити та налаштувати, в чому є відмінності таких документів та інші більш детальні кроки. На третьому або четвертому кроці можливо переходити до моделювання конкретних ситуацій з використанням реальних документів які є в компанії.

У нових впровадженнях докладні відомості про кращі практики можна знайти за допомогою прискорювача Enterprise Management Layer для SAP S/4HANA.

Щодо інтерфейсу взаємодії з користувачами та застосування нового UX скористайтесь прискорювачем Quick guide to evaluating SAP Fiori apps.

Ну а Робоча група клієнта – Customer Team Enablement виконує стандартні процеси, продемонстровані на семінарах із відповідності стандартам у початковій системі або призначеній DEMO-системі. Рекомендується користуватись прискорювачем SAP Best Practices Explorer for S/4HANA (Public).

Крок аналізу та доповнення документації. Команда впровадження – Application Design and Configuration має задокументувати та класифікувати за критеріями важливості всі дельта-вимоги. Документацію слід додати до перегляду вимог і приміток SAP Cloud ALM у Backlog (інструмент або шаблон). Існують такі типи дельта-вимог:

• Вимоги до конфігурації: їх можна реалізувати за допомогою стандартного налаштування SAP. Вони включають конфігурацію для бізнес-процесів, основних даних, інтерфейсів користувача та інтеграції SAP до SAP.
• Організаційна структура: надається через конфігурацію.
• Основні дані: наприклад, інформація, яку не можна зіставити зі стандартними полями SAP.
• Процес: новий процес, який не є частиною стандартного рішення SAP.
• Авторизація: зміни стандартних попередньо визначених повноважень і ролей.
• WRICEF (WRICEF=workflows, reports, interfaces, conversions, enhancements and forms): усі налаштування або розширення для робочих процесів, звітів, інтерфейсів, перетворень, удосконалень і форм. У деяких проектах для затвердження цих вимог потрібна спеціальна процедура керування/затвердження, оскільки вони впливають на початкові зусилля щодо впровадження та поточні зусилля з обслуговування.
• Розробка: значні нові розробки щодо функцій, які можуть бути недоступні в стандарті SAP.
• Взаємодія з користувачем (UX).

Деякі дельта-вимоги можна усунути шляхом адаптації бізнес-процесу до стандартного рішення.

Необхідно зафіксувати організаційну структуру та план рахунків, з урахуванням всіх вимог, зібраних на семінарах та обговореннях. Також, ведемо документ по конфігурації – опис налаштувань системи і забезпечуємо повноту документації основних даних, необхідних для створення та налаштування.

Аналітики – Analytics  перевіряють чи всі вимоги до звітності повністю задокументовані.

Команда впровадження – Application Design and Configuration разом з групою по Інтеграції – Integration створює документ щодо вимог до інтеграції, які обговорювалися під час семінарів з адаптації до стандарту. Вимоги необхідно задокументувати для подальшого технічного завершення.

Команда впровадження – Application Design and Configuration разом з групою по Розширенню – Extensibility веде документацію по керуванню виведенням документів та шаблонам форм.

Спеціальна перевірка якості. Архітектор рішення та команда управління проектом переглядають і визначають пріоритетність вимог, враховуючи цілі проекту та загальну архітектуру рішення SAP S/4HANA. Критерії визначення пріоритетів узгоджуються заздалегідь.

Кожна дельта-вимога, що веде до WRICEF, піддається сумніву: «Чи життєво важливо відповідати бізнес-вимогам, і якщо так, чи можна це виконати через стандартну конфігурацію?». Команда проекту також переглядає та критикує вимоги до дельти. Вони перевіряють повноту кожної вимоги. Параметри складності (дуже високий, високий, середній, низький) можуть бути призначені кожній визначеній вимозі, що дозволяє групі управління проектом скласти початкову оцінку зусиль на реалізацію проекту. У деяких випадках до прийняття рішень буде залучений керівний орган, наприклад керівний комітет.

Метою цієї перевірки є якнайточніше дотримання стандарту SAP. Зведіть до мінімуму кількість модифікацій і користувацького коду.

Примітка Alloy: Ми рекомендуємо дуже простий підхід: якщо у системі є реалізація вимоги тим чи іншим чином, то береться цей підхід до процесу і тільки в разі відсутності стандартної реалізації виконується оцінка об’єму необхідної розробки.

Деталізація та документування рішень для дельта-вимог, які були визначені як пріоритетні.

Наступні критерії мають бути задокументовані в проектному документі:

• Короткий опис процесу
• Бізнес-вимоги високого рівня
• Блок-схеми процесу: базовою лінією завжди є блок-схема процесу SAP Best Practices. Тільки коригування повинні бути задокументовані.
• Короткий опис конфігурації
• Ролі користувачів
• Вимоги до концепції авторизації
• Необхідні ІТ-системи, наприклад системи, підключені до SAP S/4HANA
• Delta вимоги та рішення
• Розробки
• Організаційні аспекти
• Кількісна оцінка процесу (обсяг даних)

Подальші кроки фази дослідження будуть описані у наступній статті. Далі буде…

Литвиненко Артем

Шевченко Тетяна