Мал. 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% для «успішних» систем).
