Стратегії автоматизації бізнесу

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

Тобто у компанії, що зважилася на автоматизацію процесів або систем управління, є всього3 стратегії автоматизації :

  • Автоматизація з урахуванням коробкового програмного продукту;
  • Доробка коробкового продукту під вимоги підприємства та його використання;
  • Розробка програмного продукту під свої вимоги «з нуля» та подальше використання.

Для того щоб вибрати стратегію автоматизації, потрібно виконати ряд дій:

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

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

У такому разі алгоритм вибору стратегії автоматизації може бути наступним:

рішення

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

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

Третій варіант - розробка на замовлення - у наш час виглядає практично фантастикою. Кілька разів про такі проекти я чув такі висловлювання: «Навіщо винаходити велосипед? Невже під ваш вид діяльності ще не написано коробкове рішення? Як я нещодавно дізнався, у деяких видах діяльності в Білорусі (наприклад, у наданні страхових послуг) існує один-єдиний коробковий продукт і одна компанія, яка його розвиває. Ризики під час впровадженнятакого коробкового рішення великі – якщо компанія-розробник закриє свій бізнес, підтримувати та розвивати програмний продукт у разі відсутності опису його архітектури буде вкрай складно. Ось і замислюються у такій ситуації про розробку на замовлення. Про цю стратегію також розмірковують у разі, коли існуючий коробковий продукт не закриває і 50-80% вимог до нього (на діаграмі написано 80%, але ця цифра умовна і виведена не на підставі якихось експериментів чи статистики). При виборі цього варіанта стратегії автоматизації відразу необхідно вирішувати питання підтримки користувачів та розвитку продукту. Хто це робитиме і на яких умовах? Часто при виборі цієї стратегії компанія створює власний підрозділ автоматизації бізнесу, який займається підтримкою та розвитком продукту.

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

Але якщо ви хочете вибрати стратегію автоматизації на підставі точніших розрахунків, то після аналізу ризиків потрібно зробити прогноз TCO (англ. Total Cost of Ownership) для всіх трьох варіантів стратегії, і після цього вибрати варіант знайменшим значенням TCO. Я розумію, що такий аналіз займе багато часу і коштуватиме дорого, тому в більшості випадків рішення про вибір стратегії прийматиметься одразу після опрацювання списку ризиків щодо кожної стратегії. Але краще так, ніж просто на підставі інтуїції.

У наступній статті я планую докладніше описати перебіг підготовки бізнес-процесів до автоматизації.