З історії автоматизації методологій управління підприємства

Зміст:

Вступ
Від MRP II до ERP
Тягни чи штовхай, або Куди не крути, а головне — хто буде відповідати
Баланс

Закордонні терміни MRP, ERP і Supply Chain звучать сьогодні або як солодка музика, або як імпортні лайки, і тільки іноді можна зустріти дійсне розуміння суті цих цілком природних і широко використовуваних методик. У даній статті зроблено спробу неформального опису історії виникнення класичних методик управління ресурсами підприємства і їх сучасних розширень, що виявляють новий ступінь розвитку методології управління бізнесом.

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

Для вирішення завдання управління було розроблено методологію планування матеріальних ресурсів підприємства — MRP (Material Requirements Planning), проте виявилося, що крім методичних проблем,тут є і математичні, що цілком були вирішені тільки з появою обчислювальної техніки.

Використання цієї методології передбачає, як правило, застосування MPS «Master planning shedule» — старої і добре відомої як «обсягово-календарне планування» методології, що є базовою практично для всіх планово-орієнтованих методологій. Після цього достатньо швидко був реалізований варіант планування виробничих ресурсів (потужностей) — CRP «Capacity Requirements Planning», методологія якого принципово була схожа на MRP, але йшлося про розрахунки необхідних виробничих потужностей, а не матеріалів і компонентів. Це завдання було значно складнішим, оскільки потребувало врахування великого числа параметрів, а остаточний розрахунок обов'язково мав містити не тільки параметр потужності, але і тимчасову послідовність.

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

Об'єднання названих методологій дало завдання MRP «другого рівня» MRP II «Manufacturing Resource Planning» — інтегровану методологію планування, що включає MRP\CRP. При використанні данної методології обов'язково передбачається аналіз фінансових результатів виробничого плану, а також застосування MPS і FRP «Finance resource/requirements Planning» — планування фінансових ресурсів, правда,без їх інтеграції в «динамічну систему». (Часто йдеться про MRP без додавання індексу II, тому в деяких публікаціях потрібно орієнтуватися за контекстом, яка саме з методологій мається на увазі.) З метою прискорення проведення розрахунків, особливо з урахуванням малої потужності комп'ютерів того часу, були розроблені методології чорнового планування виробничих ресурсів (або потужностей) — RCCP, що дозволили «улагоджувати» виробничий графік без проведення повної процедури розрахунку, а потім уже робити остаточний баланс ресурсів за обома «гілками» планування — як MRP, так і CRP. На цьому рівні дане завдання пропонується дотепер у вигляді рішень, що тиражуються — так названих «MRP II-систем». Проте в такому вигляді завдання планування ресурсів становить інтерес тільки для обмеженого числа «типових MRP(MRP II)-виробництв», серед яких машинобудування, приладобудування і деякі інші серійні складові виробництва, для яких завдання щодо розрахунку потрібних ресурсів є самоцінною з огляду на обчислювальну складність. Модель одна — реалізацій багато. Природно, що для більшості виробництв «розрахунок чистих потреб» виявився недостатнім, і почався подальший розвиток «постановок» завдань. Тому відразу було сформульовано декілька основних напрямків розвитку методології MRP, частина яких пізніше виділилася у самостійні методології управління:

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

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

Крім цього, сформувалися самостійні завдання (потенційно реалізовані у вигляді «слабоінтегрованої» або навіть автономної підсистеми, як, наприклад. управління складами):

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

Два останні напрямки лежать в основі методологій управління компаніями типу FMCG (fast moving consumer good — швидкорухливі споживчі товари (напої, сигарети, консерви) — це практично всі «товари повсякденного попиту», що не виготовляються в дрібному приватному секторі, як, наприклад, хліб). Як вже відзначалося, самостійність цих напрямків означає можливість їх початкової реалізації у рамках окремої системи і важливість такої реалізації для бізнесу компанії. Природно, на якомусь кроці стає очевидно, що неінтегроване завдання дає тільки часткові або тимчасові переваги і потрібно будувати інтегровану систему, але спочатку здається, що достатньо перекласти відвантаження на комп'ютери, і можна спати спокійно.

Мал. 1. Взаємозв'язок систем планування

Стисло оглянувши першоджерела постановки завдання корпоративного управління, зупинимося на методах його формалізації. Досвід постановки завдань для реальних систем і аналіз наявних у Росії реалізацій «великих систем» дозволили виділити три підходи до формальної постановки завдань: функціональний, фінансовий і документообіговий. Незважаючи на те, що «чистих» рішень, заснованих на одному із таких підходів, не існує, проте «початки» дуже сильно позначаються на можливостях і якісних характеристиках систем. Сьогодні очевидні переваги функціонального підходу в галузі управління виробництвом, типовими представниками якого є рішення від Baan і Symix. Фінансовий підхід, який пропонує компанія SAP у своєму продукті R/3, справді виявився дуже ефективним для управління бізнесом холдингового типу і суто фінансових інститутів.

Винятково популярний у Росії документообіговий варіант серед західних «великих систем» у чистому вигляді, очевидно, не зустрічається зовсім, хоча його вплив дуже відчувається, наприклад, у Oracle Application. Значною мірою він зустрічається тільки в «малих» системах і в непромисловій сфері, де питома вага «вмонтованих» обчислювальних завдань, або вони легко «відчужуються» у самостійні модулі. Важливо відзначити, що ті або інші реалізації документообігу усе більше включаються до складу багатьох систем автоматизованого управління, проте їхнє завдання достатньо чітко окреслено як «зовнішнє» стосовно «основної» функціональності системи. Також поширеним є варіант інтеграції систем фінансово-економічного управління і системи, що забезпечує реалізацію того або іншого варіанту документообігу (у тому числі таким, як Lotus Notes або Microsoft Outlook).

Отже, MRP -системи, що тиражуються, як правило, доповнені хоча б елементарними системами управління складами і фінансами, почали свій переможний хід десь на початку 80-х (замовлені й унікальні з'явилися значно раніше). Ринкова ніша для них сформувалася величезна, і це призвело до негативних наслідків — розроблювачі довго ігнорували побажання клієнтів. До речі, аналогічна ситуація має місце зараз на російському ринку автоматизованих систем - концептуально явно застарілі рішення пропонуються як «останній крик», а ринок — величезний, кваліфікація менеджерів, що приймають рішення,- низька.

Часто можна почути діалог замовника із постачальником приблизно такого змісту: «але ви не можете вирішити актуальні для мене завдання, а робити так, як ви пропонуєте — це всеодно,що користуватися кремнієвою сокирою. — мабуть так, але чохол сокири — від Oracle, Microsoft, Sybase!». Найразючіше, що вартість таких рішень, які включають запуск у промислову експлуатацію, іноді перевищує вартість впровадження SAP R/3 на порівняних конфігураціях, за значно нижчої функціональністі (даний розрахунок проводиться достатньо просто: загальна остаточна вартість проекту ділиться на кількість запущених, а не проданих робочих місць), до речі,і вартість підтримки часто пропонується в розмірі 25 % від вартості проекту замість типових 15-18% від вартості програмного забезпечення.

Також зіставні з параметрами R/3 такі показники, як «вартість впровадження/вартість ПО» (вартість впровадження перевищує вартість власне програмного забезпечення від 2 до 15 разів, за типового показника близько 3-5, при чому вартість ПО обраховується за кількістю робочих місць, що функціонують реально, і відсотком «впровадження» (відсоток впроваджених рішень від загальної кількості проданих, що становить цифру, іноді істотно нижчу 70%, типово — близько 60% для «успішних» систем).

Мал. 2. Система фінансового планування

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

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