2.3. Великомасштабні проекти розвитку підприємства: реінжиніринг бізнесів-процесів

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

2.3.1. Сутність проекту реінжинірингу підприємства і роль іт у проекті реінжинірингу.

Реінжиніринг бізнесів-процесів — один із самих дискусійних напрямків у теорії менеджменту. Роботи М. Хаммера і Д. Чампа оцінюють украй неоднозначно: у діапазоні від революції в менеджменті до чергового термінологічного трюку консультантів по керуванню. У дійсній роботі не ставиться задача загальної оцінки даного підходу або його результатів для підприємств. Замість цього проект реінжинірингу розглядається у світлі описуваної дійсним курсом системи моделей. Отже, чи можна за допомогою системи моделей ССВ — ФСА — КПР дати економічну оцінку проектові реінжинірингу підприємства?

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

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

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

• особисто відповідального за результат процесу (ситуаційного працівника);

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

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

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

• виконанням роботи там, де можна зробити її найбільше ефективно, незалежно від границь між окремими підрозділами підприємства і навіть від границь самого підприємства (мається на увазі аутсорсинг);

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

• скороченням необхідності погоджень за рахунок зменшення числа контактів із зовнішнім середовищем;

• використанням у якості «крапки контакту» із зовнішнім середовищем єдиної відповідальної особи — ситуаційного менеджера;

• сполученням переваг децентралізованих і централізованих операцій за рахунок децентралізованих звертань до централізованої бази даних і правил.

У ході успішного проекту реінжинірингу змінюються:

• характер роботи — від орієнтованої на прості задачі до багатомірного;

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

• критерії оцінки й оплати праці — від діяльності до результатів.

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

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

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

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

Модель ФВА/ФВУ споконвічно створювалася для оцінки вартісних і інших характеристик бізнесів-процесів. От чому дана модель добре оцінює результати проекту реінжинірингу апостеріорі. Однак апріорні (тобто проведені до початку проекту) економічні оцінки можуть бути заможні лише в припущенні, що набір ресурсів, об'єктів витрат і факторів витрат залишається незмінним. Таке твердження суперечить визначенню реінжинірингу: при фундаментальному переосмисленні бізнесу-процесу дивно очікувати збереження в цілості механізму його економічної оцінки. Більш того, спроба оцінки проекту по моделі ФСА може перешкодити його успіхові, упроваджуючи цей механізм (можливо, що застарів) у свідомість людей. Таким чином, модель ФСА не надає даних для апріорної оцінки проекту реінжинірингу.

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

Таким чином, розглянуту в даному курсі сукупність моделей не можна використовувати ні для оцінки проекту реінжинірингу в цілому, ні для оцінки його ІТ-складової. Чи є це недоліком даної системи моделей або ознакою повної неможливості економічної оцінки для даного випадку? На наш погляд, правильний другий висновок. Ризик великих змін у будь-якій області, включаючи й область бізнесів-процесів, складається саме у відсутності бази для припущень про фінансовий результат. На користь цього міркування ми приведемо два свідчення. Перше з них виходить від авторів концепції реінжинірингу: «реінжиніринг компанії — це подорож зі знайомого в незвідане». Численні свідчення іншого роду приводить Р. Фостер. У своїй книзі він описує безліч прикладів несподіваних для винахідників і в принципі непередбачених результатів упровадження нових технологій — від прального порошку «Тайд» до персонального комп'ютера. Таким чином, невизначеність фінансових результатів є неминучим атрибутом великих змін у бізнесі; можна припустити, що серед інших областей і в реінжиніринг бізнесів-процесів.

Нарешті, варто сказати кілька слів про прийняття рішень по проектах реінжинірингу. На наш погляд, реінжиніринг — це нова модель бізнесу, місце якої займала раніше модель загального контролю якості, а ще раніше — регулярне планування, бюджетування і фінансовий контроль на великих підприємствах. Для ухвалення рішення про перехід на нову модель бізнесу необхідні і достатні дві умови. Перше — необхідність радикального підвищення результативності підприємства. Друге — відповідність на якісному рівні проблем підприємства нової моделі бізнесу. Кількісні оцінки на даному етапі виключаються саме через їхню неспроможність. Вони мають сенс пізніше, вже в ході проекту, при порівнянні різних технологічних рішень або різних варіантів бізнесу-процесу. У цьому випадку при необхідності застосовуються моделі ССВ і ФВА/ ФВУ відповідно.

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

2.3.2. 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 Далі, у міру уточнення цільової моделі бізнес процесів у ході реалізації проекту оцінюються економічні параметри нових сервісів ІТ. Після уточнення нові сервіси затверджуються Комітетом зі змін, а потім нові і змінені сервіси включаються в СУС.