Через терни до зірок або як правильно приготувати SAP

Як правильно впроваджувати систему? Чи існує єдиний правильний шлях? Чи є місце для творчого підходу або лише діяти за інструкцією?

Правильно говорять – критерій правильності впровадження один – або систему впроваджено і вона працює, або ні, все інше – нікому не цікаві подробиці.

Всім відомі два основні підходи – waterfall або agile. Вони описані, детально пропрацьовані та дуже наполегливо рекомендовані.

Waterfall – послідовні етапи робіт, які виконуються одна за другою, чітко та планомірно. Загальновідомі етапи цієї методології впровадження – обстеження, моделювання, проектування, розробка, реалізація, дослідна та промислова експлуатація. Детальна документація, яка погоджується на кожному, що найменшому кроці, протоколи, плани, концептуальні проекти, функціональні та інтеграційні тестування, специфікації на розробки. І це все, в кращому разі, за рік, відбувається на папері. Відбуваються «битви титанів» – як краще буде виглядати наша система, як потрібно її переробити, як вона повинна працювати, і знову ж таки, все це «теоретично». Клієнт не бачить системи, клієнт та компанія, що впроваджує систему, розмовляють різними мовами. Клієнт заспокоюється, коли бачить, що в проектних рішеннях написано саме так як він хоче, а консалтингова компанія готова саме це писати, щоб отримувати гроші. І от – все підписано, все гарно, але чому ж ця яхта починає дивно виглядати на етапі розробки, та починає тонути вже при першому спуску на воду? І в одну мить, все написане, весь рік роботи та гарячі дискусії, все можна сміливо викинути. Як казав мій колега – «то що, візьмемо ці тисячі листків списаного паперу та покладемо в систему?». Ця методика частіше використовується в компаніях, де основними критеріями прийомки системи будуть паперові документи, які підтверджують виконання кожного з етапів.

Agile – впровадження короткими циклами, ітераціями. Ця методика більш динамічна, тримає всю проектну команду в напруженні та все розглядається та приймається в поняттях системи. Кожний цикл наближає систему до бажаного вигляду та наповнення, з кожним циклом виконується уточнення вимог та реалізація їх. Так, документація також ведеться, але лише необхідна. Головне тут – отримати продукт, який задовольнить замовника. На словах все нібито зрозуміло, але як конкретно це зробити? Такий підхідне дуже подобається консалтингу – потрібно мати в команді спеціалістів, які знають систему досконало, які можуть швидко реагувати на уточнення або навіть на зміну вимог від замовника. Крім того, напруження дуже велике, а отже люди мають бути гарно вмотивовані. Це не класичний підхід, він зараз широко почав використовуватись, але для нього немає рецепту. Є підходи, створені з урахуванням принципів Agile, наприклад,  SAP Activate, але  це, на жаль, не послідовний опис кроків, а скоріше дорожня карта,  рекомендації, але послідовність кроків та об’єм не завжди можливо використати дослівно. Тому, рецепт  потрібно створювати самим. Agile методика використовується компаніями, які на перше місце ставлять працездатність системи в короткі строки.

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

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

• Проект має бути в пріоритеті та на контролі у людини №1 в компанії. Зазвичай, це керівник компанії, з максимумом повноважень. І інформація про пріоритетність проекту має бути донесена до кожного співробітника компанії.

• Проект має бути впровадженим досвідченими спеціалістами. І це не має бути дуже велика команда. Зараз дуже модно створювати команди по кожній функціональності у складі керівника за функціональністю, провідного консультанта, та ще 2-3 консультантів у підпорядкуванні, а ще й полюбляють додавати по кожній функціональності позицію архітектора. Але будемо відвертими – що таке архітектор фінансів? Або архітектор розробки? Архітектор може бути один – людина, яка тримає в голові всю конструкцію системи, людина з авторитетним досвідом та глибокими технічними знаннями. По кожному функціоналу достатньо від 1 до 3 консультантів, в залежності від складності модуля та функціональності.
• В проектну команду необхідно обов’язково включати не лише ключових користувачів від бізнесу, а й ІТ спеціалістів, які підтримують ІТ системи, що будуть замінені новою системою. Таким чином зразу отримуємо дві вигоди – з’являються нові спільники, «агенти впливу», яким вже довіряють користувачі та набагато спрощується процес вивантаження даних з існуючих систем для завантаження в SAP первісних залишків.
• Має бути роз’яснено та офіційно прийнято головний принцип – використання стандарту системи. Не для того купується дорога система, щоб її переписати та потім самотужки продовжувати переписувати весь час її функціонування.  Але і тут бувають непорозуміння, коли переписаний функціонал системи користувачі вважають стандартом тому що  працюють у стандартному інтерфейсі (SAP GUI-клієнт),  Використання стандарту системи це в першу чергу максимальне використання функціоналу, який закладений в саму систему, вивчення та прийняття ідеології системи.

Нам пощастило працювати на проектах, де нам була надана свобода дій. На основі цього досвіду ми створили власний підхід реалізований по методиці Agile, який  допомагає успішно впроваджувати системи SAP, яка багато років буде безперебійно функціонувати. Звичайно, ця методика не є застиглою, бо кожний проект унікальний і потребує суб’єктивного підходу, але основні принципи залишаються незмінними.

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

Другий важливий момент – створення проектної команди. У проектах, де ми працювали зі сторони зовнішнього консалту, ми разом з бізнесом вирішували, який склад проектної групи має бути. ІТ спеціалісти зі сторони компанії-замовника, отримували роль внутрішніх консультантів. Ми проводили технічне навчання для них та саме вони технічно виконували налаштування системи, під нашим наглядом та з нашими поясненнями. У проектах, де ми працювали як внутрішні консультанти, ми проводили таку ж політику – залучали до налаштування системи ІТ спеціалістів, які підтримували поточну облікову систему. Це дає неймовірний результат – знімає напругу як зі сторони ІТ спеціалістів, так і створює довіру зі сторони бізнес-користувачів. Компанія отримує чіткий сигнал – систему буде кому підтримувати та розвивати, навіть якщо ми підемо на інші проекти.

Третій момент – планування. Так, звичайно, для проекту необхідний менеджер проекту,  потрібен план та оцінка бюджету. Чи потрібні детальні, щоденні звіти по виконанню детальних планів? Чи потрібні взагалі детальні плани? Скільки дорогого часу консультантів вони відбирають? І чи є вони запобіжниками від провалу проекту? Наш досвід говорить, що до цього питання треба підходити з позиції доречності. Так, ключовими етапами зі строками проект має бути описаним. І саме це цікавить керівництво компанії – на якому етапі процес? Чи в цілому витримуються строки? А якщо ні – то в чому причина? Проджект-менеджер – це людина, яка тримає руку на пульсі проекту та виступає в ролі зв’язкового проектної команди з топ-менеджментом компанії.

В-четверте, документування. Перші документи, що створюються на проекті, це схеми: 

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

Ці схеми проходять детальне обговорення з проектною командою та керівниками проекту та затверджуються. Вони становлять фундамент майбутньої системи. На одному з проектів, ці схеми були роздруковані та вивішені в офісі. Офіс був по типу open-space, а отже кожного ранку кожного співробітника зустрічала картина їх майбутнього. Одним з перших також створюється документ по нумерації та кодуванню об’єктів системи. Цей документ створюється архітектором проекту. Проектні рішення, або ще їх називають концептуальним проектом, на всіх проектах довели свою безцільність. Для фіксування концепту системи доречно створення документу, який описує як і для чого це зроблено, на етапі старту промислової експлуатації. Але створення цього документу дуже складна справа, ми це робили на одному лише проекті. На інших проектах цю роль більшою чи меншою мірою відіграють детальні та якісні інструкції користувачів. Також дуже корисним виявилось створення схем бізнес-процесів з прив’язкою до кроків процесів інструкцій користувачів. Обов’язковим є створення документу про виконані налаштування в системі.

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

Завдяки цій методиці ми отримали такі результати:

• Можливість поетапного впровадження. Оскільки фундамент системи обговорений та затверджений з самого початку проекту, то можна було виділити деякі, практично ізольовані, процеси та запустити їх в роботу вже через 3 місяці після початку впровадження.
• Скорочення часу на впровадження – рекордний строк запуску системи в дослідну експлуатацію на підприємстві з 1000 – 1200 користувачами за 6 місяців.

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

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