Управление консорциумом

В кінці XIX - початку XX століття консорціуми в основному представляли собою угоди між банками для  здійснення фінансових операцій на національному  і світовому ринках. У середині XX століття консорціуми широко поширюються в промисловості і служать цілям реалізацій великих промислових, науково-технічних, будівельних та інших проектів. Так, консорціуми створювалися найбільшими об'єднаннями промисловців для будівництва атомних електростанцій. Учасниками консорціуму можуть бути приватні і державні структури. На сучасному етапі розвитку науково-технічного прогресу консорціуми практикуються в галузях, пов'язаних з новими технологіями, на стику різних сфер діяльності і галузей. Характерною особливістю сучасних консорціумів є спільне проведення науково-дослідних робіт.

Управління консорціумом організується таким чином, що з  числа його учасників вибирається  лідер, який координує їх спільну  діяльність. Лідер представляє інтереси консорціуму перед замовником і  третіми особами, але діє в межах повноважень, отриманих від інших членів консорціуму. Відповідальність же за договірними зобов'язаннями несуть учасники консорціуму в розмірі їх частки в загальному обсязі поставок і послуг. У рамках консорціуму можливі різні варіанти відповідальності, наприклад часткова, солідарна. Кожен член консорціуму забезпечує фінансування певної частини робіт і бере на себе комерційні і технічні ризики, пов'язані з виконанням своїх зобов'язань.

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

Для сучасних консорціумів характерно багатонаціональне представництво. З'явилися і консорціуми нового типу, в яких в якості учасників виступають окремі держави, наприклад ІНТЕЛСАТ - Міжнародний консорціум супутникового зв'язку. [3]

II Зарубіжний досвід

Одним із засобів виживання  бізнесу в сучасному світі  є створення консорціумів. Автоматизація  такого гіганта - справа неабияка, що вимагає серйозного і вдумливого підходу. Як досягти цієї мети і уникнути пасток, розповів генеральний директор компанії "ПрограмБанк".

Російська економіка  після десятиліття розпаду вже  на початку цього століття перейшла до фази інтеграції. Логіка її проста: щоб вижити в конкурентній боротьбі, потрібно бути сильніше конкурентів, у тому числі і у фінансовому сенсі. Фінансові можливості можна накопичувати, капіталізуємо прибуток, проте темп органічного зростання - досить обмежена величина навіть в найуспішніших справах. Але можна вчинити по-іншому: взяти і об'єднати сили декількох підприємств, отримавши одномоментне збільшення.

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

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

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

2.1 Автоматизація - шлях до порядку

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

Крім того, кожен з  локальних "порядків" вже підтриманий  якимись засобами автоматизації. Але в кожній організації - своїми, з індивідуальним розподілом функцій. Найчастіше ж багато виповнюється вручну з використанням лише підручних засобів, наприклад всезагальної виручалочки - безмовного MS Excel.

Зрозуміло, що найбільш простим шляхом побудови загальної системи автоматизації представляється об'єднання вже існуючих на підприємствах систем. Однак, в силу згаданої унікальності "локальних" порядків, при спробі їх механічного об'єднання практично всі інформаційно-управлінські функції виявляються "проблемними". У управлінця, звиклого до чіткого інформаційного забезпечення своєї роботи, це викликає відчуття "безмежного бардаку". 
Звичайно, люди виконують необхідні завдання, елементарна управлінська звітність починає збиратися, і процеси управління консорціумом йдуть своєю чергою. Але правилом є скоріше наявність проблем при збиранні та консолідації інформації (причому майже щоразу - все нових!), Ніж їх відсутність. І ці складності виглядають головною причиною виникаючих проблем бізнесу.

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

Як можна об'єднати системи автоматизації  обліку в таких різних за цілями, функціями і організаційним принципам  підрозділах?

2.2 Як навести порядок у консорціумі?

Тим не менш, перед менеджментом стоїть завдання наведення порядку  в консорціумі ІТ-засобами. Але  як це зробити? Дуже схоже на задачу обрубування хвоста кішці. Дійсно, кожен  окремий крок - впровадження нової  автоматизованої системи (локальної  або в обсязі всього консорціуму) супроводжується "болем": невдоволенням персоналу, тимчасовим розладом функцій, грошовими витратами і т.д.

Описана вище часткова втрата керованості, гостро відчувається топ-менеджментом в початковий період формування консорціуму, неминуче викликає роздратування, оскільки прямо суперечить завданням прискореного розвитку.

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

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

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

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

2.3 Крок за кроком

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

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

Однак і тут є варіанти. Можна з самого початку поставити завдання впровадження "сильної" ERP-системи, але впроваджувати її саме поетапно, починаючи з модуля консолідації звітності. До слова сказати, це досить поширена схема. І продавці ERP-систем, бажаючи отримати належні при продажах бонуси, погоджуються на цей крок, не розуміючи, що це в корені суперечить початкової ідеї ERP-системи. Це все одно, що купувати автомобіль по частинах, починаючи з салону - адже в ньому так зручно сидіти! Але функція автомобіля - возити, тобто починати треба, як мінімум, з коліс і двигуна. Так і впровадження ERP-системи потрібно починати з перенесення в неї первинного обліку, але ніяк не з звітного модуля. 
Тому найбільш правильною видається ідея впровадження на першому етапі спеціалізованої системи для консолідації звітності. Використовуючи її (і тим самим відразу отримуючи від неї віддачу, тобто управлінську звітність), можна вибудувати саму звітність, починаючи з агрегованих форм, поступово їх деталізуючи під виникаючі управлінські потреби аж до первинних облікових документів. Це теж непросте завдання, оскільки готових загальновизнаних звітних форм для консорціумів ніхто не стверджував, та й годі придумати управлінську звітність, вирішальну будь постають в процесі формування довільного консорціуму проблеми. Так виглядає магістральний шлях. 
Однак можна з самого початку зафіксувати виключно звітний, тобто заздалегідь обмежений характер впроваджуваної системи. Що це дає?

2.4 "Накладене" управління

Має сенс почати з результату, тобто з формування системи управління консорціумом. Пропонована тактика автоматизації відповідає моделі "накладеного" управління, тобто такої організації управління підприємствами консорціуму, коли централізоване управління "накладається" поверх локального, не втручаючись або майже не втручаючись у нього. 
Плюси такого підходу очевидні: мінімум дезорганізації на початковому етапі скрізь, де можна (перебудова локального управління в окремих місцях не суперечить концепції, якщо формулюється не як локальна задача, а як глобальна, тобто як мета центру, а не змушувати центром "самодіяльність мас "); безупинне підтримку керованості консорціумом на прийнятному рівні; можливість витрачати на ІТ-мети стільки коштів, скільки визнається виправданим з точки зору бізнесу, а не стільки, скільки змушується прийнятими" принциповими "рішеннями; швидка, часто негайна віддача від вкладення коштів у ІТ-рішення, що робить процес побудови спільного ІТ-рішення консорціуму добре керованим навіть без обов'язкового залучення високооплачуваних ІТ-менеджерів і / або ІТ-консультантів.

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

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

2.5 Плюси і мінуси "накладеної автоматизації"

Враховуючи те, що консолідована  звітність буде формуватися не шляхом обробки повного масиву первинних  документів, а на основі спеціально вивантажуються з облікових систем аналітичних таблиць, при формуванні загального ІТ-рішення можна істотно розширити поле для маневру.

При цьому доступ до первинних  документів зовсім не виключається, по окремим напрямкам він цілком може використовуватися. Але все-таки основна робота по обробці документів віддається на відкуп низовим обліковими системам.

Це дозволяє досягти відразу  кількох результатів. По-перше, "накладена" автоматизація дозволяє мінімізувати витрати (і час!) До моменту отримання  стійкого процесу отримання консолідованої звітності. Істотно, що цей підсумок досягається не в результаті абстрактних зусиль з тестування, а в ході отримання самої звітності. Тобто найважливіша функція починає виконуватися відразу. Інша справа, що для цього впроваджувана система повинна володіти сильними засобами підвищення якості інформації, що збирається.

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

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