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

Вступ
Від 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, частина яких пізніше виділилася у самостійні методології управління:

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

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

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

Стисло оглянувши першоджерела постановки завдання корпоративного управління, зупинимося на методах його формалізації. Досвід постановки завдань для реальних систем і аналіз наявних у Росії реалізацій «великих систем» дозволили виділити три підходи до формальної постановки завдань: функціональний, фінансовий і документообіговий. Незважаючи на те, що «чистих» рішень, заснованих на одному із таких підходів, не існує, проте «початки» дуже сильно позначаються на можливостях і якісних характеристиках систем. Сьогодні очевидні переваги функціонального підходу в галузі управління виробництвом, типовими представниками якого є рішення від 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% для «успішних» систем).

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

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

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

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

Крім того, у 80-х роках сформувалися нові характеристики ринку, що істотно змінили вимоги до програмного забезпечення менеджменту:

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

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

Оскільки в бізнес-системах велике значення має схема фінансового управління, то зобразимо на такому малюнку систему фінансового планування (FRP) у рамках ERP (мал.2.)

Фокус — на споживача, або як одержати переваги на ринку за допомогою комп'ютера. Концепція управління виробничими ресурсами — CSRP (customer synchronized resource planning) — «планування ресурсів, синхронізоване зі споживачем»- була запропонована компанією Symix. Сутність даної концепції полягає в тому, що при плануванні і управлінні компанією можна і потрібно враховувати не тільки основні виробничі і матеріальні ресурси підприємства, але і всі ті ресурси, що звичайно розглядаються як «допоміжні» або «накладні». Це всі ресурси, споживані під час маркетингової і «поточної» роботи з клієнтом, обслуговування після продажу проданих товарів, перевалочних і обслуговуючих операцій, а також внутрішньоцехові ресурси. У такий спосіб враховуються всі етапи «життєвого циклу» товару. На мал. 3 показано співвідношення між поняттями CSRP, ERP і різноманітними стадіями життєвого циклу товару.

Непрямим, але винятково важливим наслідком даної концепції виявилося реалізація, вперше у виробничих системах класу ERP, завдання "тонкого" управління виробничими графіками в умовах обмежених потужностей (так званого APS- завдання — розширеного управління виробничими графіками). Автономні рішення такого класу були відомі і раніше, але вперше було досягнуто інтегрованості із повноцінним ERP-пакетом. Системи типу APS дозволяють вирішувати такі завдання як «просування» термінового замовлення у виробничі графіки, розподіл завдань з урахуванням пріоритетів і обмежень, перепланування з використанням повноцінного графічного інтерфейсу. Завдяки принципово новій «математиці» розрахунок типових MRP-завдань відбувається на декілька порядків швидше, ніж раніше. Реалізація концепції CSRP дозволяє управляти замовленнями клієнтів і загалом усією роботою з ними на порядок «тонше», ніж це було можливо раніше. Дійсно, стала реальністю щогодинна зміна виробничого графіка, тоді як в умовах «класичної» ERP це завдання належало до категорії «кошмарних снів», що на конкретних виробництвах середнього і малого розміру зустрічається всюди (у Росії — практично, скрізь).

Детальний аналіз вартості замовлення і навіть конкретних товарів у його складі став можливим вже на етапі його оформлення, причому не в «необгрунтованих» цифрах, а з урахуванням конкретних технологічних рішень.

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

Логістичні ланцюжки як дзеркало світового розвитку. Проте найважливішою «глобальною» новинкою в галузі управління бізнесом, на мій погляд, сьогодні стала концепція «логістичних ланцюжків» (supply chain).

Інформаційна підтримка даної методології — обов'язкова вимога для значних компаній. Характерно, що ще торік R/3, яка позиціонується як система управління насамперед для великого бізнесу, активно критикувалася саме за недостатній рівень підтримки даної концепції. Перехід у практику і теорію управління від маніпулювання постачаннями (supply management) до управління ланцюжками постачань (supply chain management) або, точніше, до управління логістичними ланцюжками (мал. 4), відбувся зовсім нещодавно — протягом останніх двох-трьох років.

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

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

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

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

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

Нині є популярною ідеологія CFM (Customer Focused Manufacturing) — виробництво «орієнтоване на покупця». Власне, наведений приклад також може бути віднесений до даної категорії, проте в загальному випадку «фокус» CFM полягає не просто в адаптації товару до потреб конкретного покупця, а в постійній підтримці «зворотного зв'язку» із покупцем і відповідної адаптації ланцюжка . Це може відображатись, наприклад, у тому, що в одному магазині купують комп'ютери з великими дисками, а в іншому — із найсучаснішими відеоплатами і великою пам'яттю, отже й асортимент програмного забезпечення для цих магазинів, найімовірніше повинен бути розрізнений. Корпуси також вимагаються різні, те ж можна сказати і про монітори,тощо, якщо компанія орієнтується не на «колінне» збирання, а на «типові рішення», ті, які легко зрозуміти (розходження істотні), причому важливо, що подібні «пріоритети» можуть істотно змінюватися, іноді протягом одного-двох місяців. Найзагальніший випадок «глобальної» мультинаціональної компанії. «Фокус» — не задоволення специфічних потреб споживачів конкретної країни (праска, вона, як кажуть, і в Африці праска), а в проблемі управління глобальною дистрибуцією і зниження загальних операційних витрат.

В останньому випадку цікаво розглянути розбіжності концепцій Supply Chain і Distribution Requirements Planning (планування розподілених ресурсів), що фокусується на проблемі планування «поповнення» розподіленої складської системи, причому не тільки з «центрального» складу, але і за рахунок переміщення товару між складами одного рівня, у тому числі і шляхом переміщення з магазину в магазин, не зосереджуючись на проблемах зниження операційної вартості і зворотного зв'язку. Даний підхід оптимальний для поповнення, скажімо, системи складів сервісних центрів, обмінних фондів або, наприклад, системи оптових складів продовольчої продукції масового попиту, як наприклад, цукор, сіль, крупа і подібні товари, що незначною мірою підлягають примхам покупців щодо упакування і неістотно диференціюються за якістю. Концепція DRP реалізована достатньо давно, наприклад, у таких продуктах як CA-PRMS, а також у замовлених системах. Особливість системи полягає в тому, що вона цілком якісно працює і з off-line інформацією. У принципі її можна успішно реалізувати і на Excel. Сутність аналізу логістичних ланцюжків є дуже простою і зводиться до ряду очевидних, але не тривіальних фактів: вартість товару формується протягом усього логістичного ланцюжка і визначається найкритичнішим чином тільки на останній стадії — при продажу кінцевому споживачу; на вартості товару критичним чином позначається «загальна ефективність операцій», у тому числі транспортних і маркетингових, по всьому логістичному ланцюжку, а не тільки на шляху конкретного продажу; найбільш керованими, із погляду вартості, є саме початкові стадії — стадії виробництва товару, а найбільш вразливими — останні — продажні.

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

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

Не претендуючи на абсолютну точність можу припустити, що ідея управління логістичними ланцюжками зародилася в надрах методів виробничого управління відомих, як JIT (Just in Time — «точно вчасно» замовити і встановити ) і Kanban (точно вчасно доставити). По суті, це модифікації того самого методу, перша орієнтована на push, друга — на pull -технологію. У якийсь момент ці технології здавалися «панацеєю» від усіх виробничих хвороб, але їх недоліки не дозволили їм стати «універсальними». Можливо, що на шляху їх поширення стала саме істотна трудомісткість реалізації. Ідея даних методологій полягає в тому, що витрати на виробництво можна істотно скоротити, якщо кардинально зменшити складські запаси, а отже і витрати на них. Комплектуючі при цьому йдуть «у роботу» «з коліс», не накопичуючись на складах тимчасового збереження, де вони мають тенденцію псуватися і губитися (типовий приклад подібної ситуації — майданчики навколо мурованих будинків, забиті «про запас» привезеними блоками, а після закінчення будівництва — їх уламками). Природно, подібний стиль роботи потребує підвищеної відповідальності всіх працівників і дуже якісної системи управління постачаннями в цілому. Очевидно, це і призвело до аналізу всієї системи постачань і, згодом, до створення концепції управління логістичними ланцюжками. Цікаво, що поширення JIT і Kanban виявилося значно меншим, ніж початковий інтерес до них, що зумовлено кількома дуже важливими причинами. Уникнути помилок в асортименті і зривів термінів постачань дуже важко навіть в умовах Японії і США, а кожний такий «збій» призводить в умовах «точних» технологій до припинення виробництва. Тому доводиться тримати «гарячий запас» у розмірі щонайменше разового завантаження устаткування, що в умовах великих виробництв може виявитися досить накладним. Тому не вдасться уникнути кардинальної статті витрат — капітальних вкладень у складські приміщення й устаткування, а її більше всього і хотілося «редукувати». Проте в деяких секторах виробництва, наприклад, малосерійне складання, будівництво дана технологія дуже поширена, зокрема, у більшості високотехнологічних компаній: Nortel, Xerox, HP, Honda, Toyota, Sony. Для тих галузей, де вона застосовується, характерна мала потужність обробних центрів, (як правило, багатоцільових), стабільні складальні специфікації і технологічні карти.

Ще один із найважливіших моментів у понятті «логістичний ланцюжок» — уже згадане і мало поки звичне поняття push/pull-технології. Сутність даного поняття — різноманітні точки ініціювання операцій по всьому «ланцюжку». Наприклад, варіант «виштовхування» продукції. Підприємство виготовило продукт, далі продає — «з очей геть, із серця геть». Або технологія «висмикування»: «треба — от візьмете». Природно це спрощений підхід. До того ж концепція push/pull не цілком очевидна — вона показує досить тонке розходження між методологіями управління системою закупівель або продажів, до того ж практично застосовувані системи продажів часто є певним поєднанням двох базових технік. Знову ж дуже спрощено можна сказати, що система продажів за замовленнями — це технологія висмикування, а виробництво на склад — технологія виштовхування.

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

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

Проте повернемося до логістичних ланцюжків. Вже сам по собі логістичний ланцюжок є дуже цікавим інструментом управління бізнесом. Але крім того, із використанням відповідних фінансових інструментів можливо створення «віртуального бізнесу» (мал.5) із розподілом системи декількох компаній, що охоплює повний «життєвий цикл» товару, або, навпаки, поділ однієї компанії на декілька «віртуальных бізнесів». При цьому для кожного «віртуального бізнесу» можлива підтримка повного спектру «віртуальних систем управління», характерних для єдиної компанії. Проте така система працює коректно тільки у випадку «прозорості» усієї «віртуальної» мережі, що входить у компанію. При наявності «чорного розмитнення », що характерно для наших умов, та й «сірки», застосовуваної повсюдно, коректність визначення повної вартості товару й операційних витрат дуже умовна, що зводить нанівець усі зусилля з фінансового управління віртуальним підприємством за допомогою «простих рецептів» логістичних ланцюжків. Для цих випадків застосовуються методи управління фінансовими холдингами, про які варто говорити окремо. На закінчення хотілося б звернути увагу на один аспект, якому аналітики ще не приділяли достатньої уваги. Методології Supply Chain і CSRP взаємно доповнюють одна одну. Перша фокусується на «глобальній» логістиці і пов'язаних із нею, «зовнішніх» стосовно виробництва процесах, друга – на «внутрішніх», зокрема, на "тонкому" управлінні замовленнями і розширенному управлінні витратами завдяки трактуванню бізнес-циклу товару як «розширеного» виробничого циклу і, що важливо, не «товару взагалі», як MRP, а «товару в конкретному замовленні», що точно відповідає ідеології Supply Chain.

З огляду на те, що «ядром» логістичних ланцюжків є виробник (у глобальному розумінні — виробник додаткової вартості), можна сказати, що методологія CSRP — це методологія виробничого ядра Supply Chain. Об'єднання цих двох методологій у єдиній системі дозволило б вийти на новий якісний рівень систем і методологій управління ресурсами бізнесу. Автоматизовані системи, що підтримують «тонке» управління замовленнями і логістичними ланцюжками, можуть надати дуже значні конкурентні переваги [2,3]. На основі загальних тенденцій розвитку ділового програмного забезпечення можна припустити, що такого роду пропозиції повинні з'явитися вже до кінця поточного року.