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

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

Тому ми вирішили дати декілька порад.

1. Не поспішайте одразу працювати в реальній базі в реальному часі. Спершу створіть робочу групу з 3-4 фахівців – керівників середньої ланки. Продажі, Виробництво (Склад), Закупівлі, Фінанси. В залежності від масштабу підприємства, та особливостей розподілу повноважень, в цю групу може входити ще, наприклад, бухгалтер, та HR. Хтось цю групу має очолити. Може директор, особисто, або той, кого він визначить.

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

3. Ця робоча група має визначитись в дрібних деталях по п’яти блокам питань:

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

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

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

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

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

3.3. Хто саме має натискати на ці кнопки. Це називається «Рольовою моделлю».

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

3.4. Які організаційні зміни потрібно буде здійснити, щоби все працювало як належне.

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

3.5. Які зміни в програмному продукті мають бути зроблені до початку експлуатації.

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

Підсумок

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

Після завершення моделювання, коли з’явилась певна ясність, ми дуже радимо приділити увагу навчанню користувачів по кожному напрямку. Звісно все залежить від масштабу підприємства, але з нашого досвіду 70% трудовитрат при впровадженні йде саме на аналіз помилок користувачів.

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

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

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

Сергій Бутенко, травень 2024 р.