Пролог

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

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

На певному етапі розвитку підприємства в його офісі з'являємось ми – фахівці з виконання проектів впровадження ERP систем. Дуже часто цьому передують інші драматичні події, такі як зміна власника, топ-менеджменту або терпець когось із топ-менеджерів розривається під час спроби відповісти на питання: "Чому наша собівартість 1 гривня, а китайці продають майже те саме за 80 копійок вже з доставкою в Одесу...". Можливо, все це відбувається одночасно – це не важливо. Важливо тільки те, що це сталося, бо саме з цього моменту починається наша "драма".

Декілька "велосипедистів" вирішили придбати "автомобіль"...

Частина 1. Вибір

З будь-якого детального опису конструкції автомобіля велосипедист, який ніколи його не бачив, зробить висновок: "Ну, все ясно, автомобіль - це те саме, що і велосипед: сидіння, педалі, кермо." І він буде правий. У тому сенсі, що будь-яка інформація, зазвичай, сприймається людиною в контексті вже наявних знань.

Під час вибору ERP системи відбувається те саме. Базова проблема, яку доводиться долати, - це стійке переконання фахівців Замовника, що якась куплена програма робить все, що їм потрібно саме так, як вони це уявляють. Реальність така, що в більшості випадків все інакше. Здається, що подолати цю проблему легко - потрібно просто детально показати, як працює програма, і Замовник все зрозуміє. Проте на практиці це неможливо, оскільки сучасна ERP система є досить складною інженерною інфраструктурою. Наприклад, повний набір курсів для користувачів BAS ERP у нашому Сертифікованому Навчальному Центрі «ПРОКОМ» має загальну тривалість близько 100 годин. І хоча ми пропонуємо всім клієнтам у стані вибору почати з простих оглядових курсів, очевидно, що у Замовника завжди буде бракувати і сил, і часу, щоб дослідити хоча б одну ERP систему перед тим, як почати в ній працювати. Я вже не говорючі про те, щоб досліджувати декілька систем, порівнювати їх між собою та робити обдуманий вибір.

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

В будь-якому разі, всі автомобілі якось їдуть, але якщо Ви не довіряєте авто-дилеру, то просто не будете мати з ним справи, і марка автомобіля тут ні до чого. Цей, на 100% суб’єктивний критерій, тим не менше, на мій погляд, є найбільш точним. Бо в своїй предметній області Замовник, зазвичай, сам добре розбирається і здатен оцінювати фах людей на відміну від якості екранних форм і кнопок невідомої програми. Досвідчені фахівці не пропонуватимуть аби що. Бо сама система є для фахівця інструментом вирішення задачі клієнта. Різні фахівці віддають перевагу різним інструментам, але це вже питання цін, термінів і так далі.

Частина 2. Консультанти

На початку епохи автоматизації виникла і була визнано професійною спільнотою аксіома одного з батьків кібернетики - академіка Глушкова: «неможливо автоматизувати хаос…». Сенс цієї аксіоми полягає в тому, що для того, щоб розпочати автоматизацію, потрібно детально описати та, ще краще, оптимізувати процеси, зменшуючи «хаос». Це призвело до розвитку консалтингових послуг, таких як оптимізація бізнес-процесів, які є популярними і досі. Однак, чи є така парадигма актуальною в епоху ERP?

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

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

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

Взагалі, якісне навчання персоналу на 80% становить основу успіху проекту, і це головне, з чого потрібно починати.

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

Частина 3. Демони, які ховаються в деталях

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

Давайте уявимо, що троє наших велосипедистів обмінюються один з одним пакетами. Цей обмін може протікати за одним із трьох сценаріїв: 1) вони зупиняються та виконують обмін; 2) вони синхронізують свій рух так, щоб їхати поруч на відстані руки; або, нарешті, 3) є дехто четвертий, хто не є жодним з велосипедистів, але літає між ними з цими пакетами - свого роду янгол чи демон, залежно від обставин. Очевидно, після того, як велосипедисти потрапляють в автомобіль, проблема обміну зникає. Та що станеться з "демоном"?

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

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

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

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

Частина 4. Фактор руху

Коли ми описуємо процес отримання велосипедистами навичок автомобілістів, здається, що це повинно відбуватися в відповідних умовах. Наприклад, велосипедисти зупиняються, припарковують свої велосипеди, пересідають в автомобіль, який також припаркований, і продовжують рух. У реальних проектах, однак, це завжди не так. Зупинити підприємство для впровадження нової системи - не практично. Все має відбуватися без зупинки. Тобто велосипедисти повинні по черзі пересідати в автомобіль, не зупиняючи його руху. І, звісно, хтось повинен керувати як велосипедами, так і процесом пересадки. Це ілюструє, на що проектна команда витрачає основні ресурси. Об'єктивно, без допомоги ззовні, виконати таку операцію дуже важко, хоча існують винятки. Важливо враховувати, що скорочення витрат на цю "допомогу ззовні" може збільшити ризики додаткових витрат часу та стресів для проектної команди. З іншого боку, досвідчена проектна команда завжди намагається передбачити рівень готовності організації реагувати на зміни. Якщо є група неорганізованих велосипедистів, яких доведеться "заставляти" пересісти в автомобіль, прогнозована вартість проекту зростає через додаткові витрати часу проектної команди на управління цими ризиками. Це не завжди зрозуміло клієнту, але саме так воно працює.

Отже, щоб зменшити вартість проекту впровадження ERP для клієнта, необхідно не шукати більш дешевого підрядника, а демонструвати готовність розв'язувати організаційні питання. Оскільки проект впровадження ERP - це, перш за все, проект внутрішніх організаційних змін, а вже потім придбання програм або послуг.

Метафора з велосипедистами та автомобілем дозволяє проілюструвати кілька важливих тез, пов'язаних з рухом. Є дві досить поширені помилки, які роблять топ-менеджери підприємств, приймаючи рішення по ходу проектів впровадження ERP: 1) іноді це можливо і навіть необхідно, працювати паралельно в двох системах; 2) в разі невдачі легко повернутися до старої системи. Схоже, що будь-яке з цих рішень створює важку перешкоду для персоналу (їхати одночасно і на велосипеді, і на автомобілі - м'яко кажучи, не дуже зручно , що в свою чергу створює ризики не для проекту, а для загальної діяльності підприємства).

Частина 5. Зміни змін

Інформаційні системи, умовно, можна поділити на «відкриті» та «закриті». Відкриті системи дозволяють змінювати систему під потреби конкретного Замовника зусиллями сторонніх підрядників, тоді як закриті системи цього не дозволяють (тобто самі розробники можуть змінювати свою систему, але це вже інша історія). Уявна простота змін, які можна робити у відкритих системах (і BAS ERP саме така система), криє в собі приховану небезпеку. Цей процес матиме позитивні наслідки лише тоді, коли всі, хто відповідає за вироблення та прийняття технічних рішень, критично ставитимуться до причин, які викликали потребу в змінах. Загалом існують дві основні причини: зручність для користувачів і відповідність механізмів ERP завданням підприємства.

Перше, з чим доводиться мати справу, - це бажання «велосипедистів» мати по парі педалей та по керму. Зрозуміло, що це деструктивний підхід, який спільно з надмірною чутливістю постачальників відповідних послуг швидко призводить до того, що велосипедисти опиняються в кюветі. Причина проста: зручність користувачів - дуже суб'єктивна, важко вимірювана і, головне, нестабільна в часі. Хоча іноді можна зустріти цікаві творчі задачі, вони зазвичай не мають чітких меж, і в умовах конкретних обмежень по термінах і вартості вирішення цих задач не завжди є доречним.

Звісно, існують й інші аспекти. Ходові якості автомобіля визначають дорогу, по якій доцільно рухатися. На NISSAN PAJERO можна проїхати прямо через ліс, а на FERRARI краще проїхати 20 км по асфальтованій дорозі. Результат може бути однаковим з точки зору витрат часу та пального, але обрати дорогу не завжди можливо, і саме тут може знадобитися зміна автомобіля. Підлаштовувати систему ERP під певні специфічні процеси підприємства можливо і необхідно. Зазвичай такі задачі існують об'єктивно, їх границі можна легко виміряти, і самі рішення можна передбачити ще на початкових етапах проекту.

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

Епілог

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

Специфіка сучасних інформаційних систем рівня ERP в тому, що вони, з одного боку, дуже сильно налаштовуються та переналаштовуються (це є побічним ефектом намагань розробників охопити якнайбільше галузевих ніш), а з іншого боку, вплив різних налаштувань системи на життя підприємства має глобальний характер. Це вимагає адекватного мислення людини, яка приймає рішення про зміну таких налаштувань. Образно кажучи, «той, хто за кермом», керує за трьох, і на ньому трійна відповідальність. Підготувати такого фахівця не просто; ніхто не народжується адміністратором ERP, і цьому, поки що, не навчають у вишах. Зазвичай такі люди виявляються вже під час проекту серед членів проектної групи з боку Замовника, іноді це і є вже згаданий ІТ-Директор. Цей керівник повинен, з одного боку, мати системний погляд на нові можливості, що приносять користь підприємству, з іншого боку, розуміти наслідки власних рішень. Консалтингові послуги у вигляді рекомендацій, про які ми згадували в другій частині цього оповідання, потрібні саме йому. А після закінчення принаймні третього місяця (а то й цілого року) реальної експлуатації ERP настає час, коли такі рекомендації стають доречними.

Когось нудять різкі повороти, хтось намагається вистрибнути на ходу. «Той, хто за кермом», повинен думати про кожного. Це непересічний персонаж із складною подальшою долею. З ймовірністю 50% він невдовзі покине автомобіль, або тому, що йому самому стало вже не цікаво, або тому, що його викинули інші, бажаючи покрутити кермо. Але це вже зовсім інша історія...

Сергій Бутенко, ТОВ «ПРОКОМ»

Листопад 2023 р.