ERP – системи як інструмент реінжинірингу підприємства

У розділі 2.1.4 минулого розглянуті економічні переваги моделі MRP II/ERP як бізнесів-моделі. Потік доходів від проекту впровадження ERP-системи оцінювався винятково з погляду розходжень між бізнесом-моделлю MRP II і традиційними підходами до планування і керування виробництвом. Подібний підхід представляється цілком справедливим для проекту впровадження ERP-системи. Однак реінжиніринг бізнесів-процесів дає можливість у деякому змісті «перевпровадити» ERP-систему, забезпечивши тим самим подальше збільшення ефективності основного бізнесу.

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

- об'єднання декількох робіт в одну;

- прийняття рішень самими працівниками;

- скорочення обсягу перевірок і контролю за рахунок сукупного або відстроченого контролю;

- скорочення необхідності погоджень;

- сполучення переваг децентралізованих і централізованих операцій.

Приведемо невеликий приклад, що пояснює, з області оптової торгівлі нафтопродуктами. Ця торгівля звичайно має на увазі складання наступних документів:

- рамкового договору між постачальником і покупцем, що визначає умови взаєморозрахунків;

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

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

Контроль виконання бізнесів-правил (у спрощеному представленні) містить у собі перевірки:

◊наявності договору і додатка зданим контрагентом;

◊ відповідності обсягу і номенклатури постачання за заявкою залишкові (залишкам) позицій по додатку на поточний період;

◊ відповідності заявки поточному лімітові відвантаження НПЗ¹ з обліком уже надійшли заявок і їхньої пріоритетності;

◊ не перевищення покупцем установленого йому ліміту кредитування;

◊включення ціни транспортування в ціну нафтопродуктів, що буде враховано при виставлянні рахунка покупцеві, і т.д.

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

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

◊ наявність довідника контрагентів і постійне його ведення, що виключає пропуск і дублювання даних контрагентів;

◊ наявність довідника реалізованих нафтопродуктів з аналогічними вимогами до його ведення;

◊ можливість розробки плану виробництва з відповідними вимогами до довідників і алгоритмів.

Перераховані вище можливості, необхідні для автоматизації контролю бізнесів-правил, цілком присутні в ERP-системі і складають приблизно 60—80% обсягу функціональних вимог до останнього. Таким чином, ERP-система - навряд чи не оптимальний інструмент для виконання подібних операцій. Разом з тим система повинна працювати в істотно іншому режимі:

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

◊ працездатність ERP-системи стає неодмінною умовою збутових операцій. У результаті вартість часу навіть невеликого простою і вимоги до служби супроводу багаторазово зростають;

◊ специфіка роботи менеджера вимагає доступу до системи не тільки зі стаціонарного офісу, але і з офісу клієнта, що припускає вилучений доступ у ERP-систему з мобільного комп'ютера;

◊ усі торговельні документи вводяться в систему безпосередньо менеджерами. Помилка при уведенні вихідних даних зажадає повторного підписання торговельного документа в контрагента;

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

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

Рішення по обох проектах приймаються в рамках загального бізнесу-проекту реінжинірингу; іншими словами, той і інший проект будуть реалізовані як зв'язані. Вибір ERP-системи в розглянутому нами випадку не потрібно, тобто витрати на проект залежать винятково від дотримання методики ведення проекту (докладно ці питання будуть розглянуті в главі 3). Навпроти, проект підтримки планується й оцінюється по стандартній для нього схемі (рис. 2.10). При цьому в прийнятті рішень по обох ІТ - проектам крім органів керування проектом бере участь Комітет зі змін.

В міру впровадження і тестування нових бізнесів-процесів для них розробляється ФСА/ФСУ - модель. Вона дозволяє оцінити прибутковість нового сервісу в термінах КПР і ФСА, а також вартість одиниці часу простою сервісу для різних категорій простоїв. Після передачі нових сервісів в експлуатацію на них з тимчасових об'єктів витрат списується вартість обох ІТ - проектів. На підставі цих даних виробляються оцінка результатів проекту реінжинірингу і перегляд СУС. Останній необхідний для обліку нових сервісів і ймовірної зміни параметрів існуючих сервісів. Описана послідовність дій приведена на рис. 2.14.

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

Рис. 2.14. Прийняття рішень по пов’язаних ІТ-проектах у складі проекту реінженерингу.

При цьому вибір рішень по інфраструктурному проекті виробляється формально, на підставірозширеної ФСА-моделі, описаної в розділі 2.2.1 Далі, у міру уточнення цільової моделі бізнес процесів у ході реалізації проекту оцінюються економічні параметри нових сервісів ІТ. Після уточнення нові сервіси затверджуються Комітетом зі змін, а потім нові і змінені сервіси включаються в СУС.

Резюме

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

Економічні параметри сервісів ІТ у новій моделі бізнесів-процесів визначаються на етапі тестування останньої До цього моменту також стають відомими точні дані по витратах на зв'язані проекти розвитку ІТ На підставі тих і інших даних виробляється економічна оцінка зв'язаних проектів ІТ. Вона дозволяє визначити параметри нових і змінених сервісів, необхідних для перегляду СУС, а також проконтролювати результати проекту реінжинірингу в цілому

2.3.4. Контрольні запитання

1 Розкрийте поняття реінжинірингу бізнес процесів Дайте визначення реінжинірингу.

2 Які проблеми оцінки економічних результатів проекту реінжинірингу до визначення цільової моделі бізнесів-процесів? Охарактеризуйте моделі КПР і ФСА/ФСУ

3 Як застосовується розширена ФСА-модель сервісу ІТ в оцінці проекту реінжинірингу? Яка динаміка ССВ у проекті реінжинірингу?

4 Розкрийте роль неформальних і формальних компонентів в оцінці проекту реінжинірингу і зв’язаних з ним ІТ-проектів?

5 Розповісти про виключення ручного контролю виконання бізнес-правив і опишіть його роль у проекті реінжинірингу. Яка роль сервісів ІТ у виключенні ручного контролю виконання бізнес правил?

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

7 Розповісти про зміну умов функціонування ERP-системи при використанні її як засобу контролю бізнесів-правил. Як забезпечується працездатність у нових умовах засобами інфраструктури ІТ?

8 Яка мета формальної економічної оцінки нових і змінених сервісів ІТ у проекті реінжинірингу бізнесів-процесів? Назвіть умови проведення такої оцінки