BAS TREK: про технологію впровадження систем ERP на платформі BAS

Що таке «Впровадження» ? Нещодавно одна клієнтка задала мені таке питання, і я зрозумів, що, насправді, сам цей термін, який ми всі постійно використовуємо, не є повністю визначеним і зрозумілим за межами професійної спільноти

Що таке «Впровадження» ?

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

Отже «впровадження».

Є умовна «точка А» – це поточний стан підприємства, і є умовна точка «B» – це стан якого керівництво хоче досягти. Між ними є певна відстань. «Відстань» також умовна, тому, що мова не про пересування в просторі, а про масштаб змін. Подолання цієї «відстані» і є процес «впровадження».

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

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

• Технології – це сам програмний продукт або якась архітектура з декількох продуктів. Те, що можна купити. Тобто це кнопки, форми, алгоритми і все те, про що зазвичай пишуть в своїх презентаціях продавці програмних продуктів, а також те, про що вони ніколи не розповідають
• Дані – тобто процес реструктуризації, верифікації та доповнення даних. Нові технології створюють нові можливості, але, зазвичай, щоби цими можливостями скористатися наявних даних або недостатньо, або вони невідповідно структуровані, або просто не відповідають дійсності. Все це потрібно привести до ладу;
• Люди – набуття користувачами навичок використання нової технології. Модний колись термін «реінжиніринг бізнес-процесів» це також на цій смузі, тому що реальні процеси, хто б що не казав, протікають не де інде, а в головах у людей, відповідно до їх навичок і розуміння можливостей.

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

• 5% - технології;
• 15% - дані;
• 80% - люди.

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

Як ми це робимо? І чому ми робимо саме так

Якщо керівництво підприємства переконано, або хтось його переконує, що проект впровадження ERP має починатись з розробки «ТЕХНІЧНОГО ЗАВДАННЯ», то з огляду на написане вище, це значить, що в фокусі уваги знаходиться не більше 5% реальної складності задачі. Технічні аспекти важливі, але не з них треба починати.

Втім, слід зауважити, дискусії про те, як впроваджувати ERP, і чи є взагалі якийсь порядок дій, який веде до гарантованого успіху доводиться вести на початку майже кожного проекту. На наш погляд такий порядок дій є – це технологія BAS TREK, яка останнім часом набирає популярності серед клієнтів та консультантів, і про яку, власне, весь цей текст. Спрощено універсальний план проекту впровадження виглядає так:

Далі ми розглянемо кожний з цих етапів детально.

Навчання робочої групи

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

• продажі;
• виробництво та склад;
• закупівлі;
• фінанси, контролінг;
• кадри і заробітна плата;
• регламентний облік.

І, звісно, у робочої групи має бути керівник - особа, яка має повноваження ухвалювати рішення.

Всіх їх потрібно навчити. В цей момент (на початку проекту)  основні налаштування ще не зроблені, більше того саме члени робочої групи (на відміну від звичайних користувачів) мають знати, які ж взагалі є ці налаштування, тому навчання відбувається на демонстраційних інформаційних базах. Повний набір курсів  для цього етапу можна знайти на сайті Центру сертифікованого навчання «ПРОКОМ» за цим посиланням: https://csoprocom.com.ua/study/kursy-bas/, а вже конкретний перелік ми зазвичай рекомендуємо з огляду на реальну потребу Замовника.

Моделювання

Це один з найважливіших процесів технології BAS ТРЕК. В загальному вигляді моделювання складається з 4 етапів.

1. Збір первісної інформації.
2. Розробка та погодження Завдання на моделювання.
3. Створення та погодження моделі.
4. Опис моделі, розробка та погодження документу ТЕХНІКО-МЕТОДИЧНЕ РІШЕННЯ.

Великого відкриття тут немає. Це просто творчо перероблена фахівцями «ПРОКОМ» та адаптована під специфіку наших проектів (впровадження ERP систем) відома методологія Model-Based Systems Engineering, MBSE – Системна інженерія на основі моделей. Проте «диявол», як кажуть, «криється в деталях». Тому в пошуку та відпрацюванню цих «деталей» ми витратили не одну тисячу людино годин. Користуйтесь !

Збір первісної інформації

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

Завдання на моделювання

Це структурований текстовий опис того, що має бути відтворено в моделі. Він описує:

• вимоги до загальної архітектури моделі;
• об'єкти НДІ, приклади яких мають бути налаштовані та створені під час моделювання;
• процеси, які мають бути промодельовані;
• дані, що надані Замовником для моделювання.

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

Створення моделі

Модель – це інформаційна база обраного Замовником продукту (BAS УТ, BAS КУП, BAS ERP або BAS Малий бізнес), яка наповнюється даними відповідно до Завдання на моделювання. Створюються довідники (види номенклатури, номенклатура, ресурсні специфікації тощо), заповнюються регістри, вводяться первісні документи. З рештою на цій інформаційній базі відтворюються всі окреслені Завданням процеси так, як вони мають працювати в реальних умовах.

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

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

Опис моделі

Коли модель повністю готова, і всі процеси відпрацьовано, складається документ «ТЕХНІКО-МЕТОДИЧНЕ РІШЕННЯ». В якому є 5 головних розділів:

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

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

Як можна побачити на цьому етапі робота відбувається одночасно на всіх 3-х напрямках (технологія, дані, люди):

• Відпрацьовується технологія (підбираються налаштування, визначаються функціональні розриви).
• Визначаються структури даних (насамперед довідників, в тому числі з’ясовуються джерела інформації для їх завантаження або створення вручну).
• Готується підґрунтя для підготовки користувачів (визначається рольова матриця, та створюється контрольний приклад, на базі якого вже готуються спеціалізовані курси для користувачів або інструкції).

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

Створення НДІ

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

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

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

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

Навчання користувачів

Знову згадуємо розподіл зусиль по напрямкам – 80% проблем вирішується шляхом якісної підготовки людей. Тому ця хвиля навчання дуже важлива і потребує попередньої підготовки. Фахівці «ПРОКОМ» відповідно до рольової моделі і методичних рішень, які узгоджено під час моделювання, готують курси навчання, «методички» та інструкції для кожної групи користувачів.

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

5. Підтримка після запуску.

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

Дослідна експлуатація

Звісно, тільки реальна практика дасть відповідь на те, чи готовий весь колектив користувачів до роботи в новій системі. І чи готова сама система. Тобто всієї попередньої підготовчої роботи може виявитись недостатньо, щоби користувачі і керівництво почували себе цілком впевнено. В таких випадках (не завжди) проводиться дослідна експлуатація. Команда впровадження вирішує на цьому етапі декілька задач:

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

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

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

Звісно, на все це потрібен час. Неможливо обробити дані одного місяця за, наприклад, місяць. Бо всі користувачі зайняті поточною роботою. Тому кожен з них може приділяти цій додатковій роботі максимум 1-2 години на день. Саме тому дослідна експлуатація на даних одного місяця може зайняти 3-4 місяця (в залежності від складності об’єкта).

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

Що далі?

Існуюча система має бути зупинена. Це ключове. За 34 річну історію «ПРОКОМ» ми багато разів бачили спроби «паралельної роботи» в двох різних системах, але жодної успішної. Втім про те, що в якийсь заздалегідь визначений час існуюча система буде зупинена має бути відомо, як мінімум, за 3 місяці. Це створює здорову психологічну основу для керування такими змінами.

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

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

А де ж програмісти?

А їх тут і бути не повинно. Бо проекти впровадження ERP систем, це перш за все проекти організаційних змін. Хоча участь програмістів не виключена. Інтеграція з якимись сервісами, сайтами, технологічним обладнанням, наприклад, вагами, і таке інше, може потребувати програмування.

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

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

От і все! Задля того, щоби допомогти Вам виконати цю роботу, і існують такі підприємства, як «ПРОКОМ». Звертайтесь, допоможемо

Коротко про все викладене дивіться тут  https://www.youtube.com/watch?v=z2Xr4RNY17M

І вдалих Вам впроваджень!