3.1. Економічний аналіз проекту впровадження великої фінансово-економічної інформаційної системи

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

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

Повернемося до рівняння (1.1). Грошовий потік витрат на проект характеризується двома векторами: сумами витрат С_t і імовірностями їхнього настання р_t. По даному грошовому потоці розраховується чиста приведена вартість з коефіцієнтом дисконтування d, що входить як один з доданків у рівняння фінансового результату проекту. Передбачається, що величини і моменти витрат на проект визначені і імовірнісним законам підкоряється тільки продовження проекту до моменту часу t. Під імовірністю p_t настання даної витрати С_t як елемента грошового потоку розуміється імовірність того, що проект продовжується від моменту часу t-1 до моменту часу t. У світлі сказаного розглянемо рівняння (1.1) виходячи з припущення про незалежність настання витрат C₁…С_n¹.

Рівняння (1.1) перетвориться до виду:

(3.1)

де t = l...n — періоди часу, у яківідбуваються інвестиційні витрати;

d — коефіцієнт дисконтирування.

З рівняння (2.1) випливає:

(3.2)

У випадку залежних C₁...С_n у рівняння (3.2) додаються члени, що описують імовірності (CJC), що ускладнюють формулу, але не змінюють її принципово. У графічному виді рівняння, що складаються, (3.2) приведені на рис. 3.1.

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

Рис.1.3. Грошовий потік за фазами проекту впровадження

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

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

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

• слабке організаційне забезпечення робіт з боку керівництва підприємства. Упровадження великої фінансово-економічної системи практично неминуче зв'язано зі зміною організаційної структури і регламентів бізнесів-процесів підприємства. З цієї причини лідером проекту повинний бути один з топ-менеджерів

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

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

• відсутність регламенту контролю якості робіт і внесення змін в обсяг проекту. Хоча ці моменти можна віднести до пп. 1,2, їхня важливість змушує обмовити них окремо. Економічне обґрунтування проекту, його план і бюджет будуються виходячи з припущень про обсяг проекту. Тому будь-яка істотна його зміна спричиняє перегляд усіх трьох документів, що означає не тільки відчутні витрати на проект і керування їм, але й анулювання раніше зроблених витрат. У свою чергу, зафіксований обсяг робіт повинний бути підкріплений процедурами контролю якості, що забезпечують відповідність обсягу і якості фактично виконаних робіт вимогам замовників проекту.

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

Подібним компромісом представляється допущення змін у проект лише при виконанні одного з трьох умов:

◊ зміна обумовлена уточненням границь бізнесів-процесів. Раніше було показано, що складні фінансово-економічні системи, насамперед системи класу MRP I1/ERP і родинні їм, засновані на визначених стандартах бізнесів-процесів і ефективні лише при скільки-небудь цілісній реалізації останніх. Тому в ході виконання проекту, наприклад на стадії концептуального проектування, можуть бути уточнені організаційні і функціональні границі бізнесів-процесів, що підлягають автоматизації. Приведемо приклад такої зміни в проекті оптимізації керування запасами (див. главу 2). Обсяг проекту був визначений виходячи з забезпечення сировиною і комплектуючим основним виробництвом. При виконанні робіт були виявлені допоміжні виробництва, що постачаються в рамках єдиного процесу закупівель і загальні склади, що мають, з основним виробництвом. Це може зробити доцільним розширення обсягу проекту за рахунок допоміжних виробництв;

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

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

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

Важливий механізм, що обмежує внесення в проект небажаних змін, — керування чеканнями. Воно спрямовано на створення сприятливого відношення до проекту при зведенні до мінімуму несправджених чекань користувачів. До основних принципів керування чеканнями відносяться:

• приоретизація вимог користувачів — проектна команда разом з бізнесами-користувачами привласнює вимогам пріоритети;

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

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

• явне формулювання ризиків, що випливають з перевищення ресурсних можливостей.

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

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

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