Облік затрат і бюджетний контроль в проекті впровадження інформаційної системи. Розподіл затрат по сервісах до закінчення проекту

У великому проекті особливо серйозні проблеми представляють облік витрат і контроль їх відповідності бюджету. При веденні на підприємстві обліку по моделі ФВА необхідно також робити розподіл понесених витрат по сервісах ІТ. У цьому розділі ми розглянемо методи такого контролю.

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

Система обліку витрат розробляється і вводиться в дію на етапі підготовки проекту. Витрати розподіляються по наступних групах:

- апаратне забезпечення - усі витрати на придбання і модернізацію устаткування, включаючи кабельну мережу і канали зв'язку;

- програмне забезпечення - усі витрати, зв'язані з придбанням ліцензій на ПЗ;

- зовнішні підрядники по проектних роботах - усі витрати, пов'язані з роботами по проекту зовнішніх консультантів;

- інші зовнішні роботи і послуги, наприклад послуги технічної підтримки, зв'язку і т.д.;

- роботи співробітників підприємства.

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

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

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

Цим забезпечується не тільки контроль відповідності фактичних витрат бюджету проекту, але і збирається інформація, необхідна для контролю й аналізу відхилень. Як буде показано нижче, вона використовується і при розподілі витрат на проект по знову створених ресурсах і сервісах ІТ. Важливо фіксувати витрати по методу нарахувань у момент виконання відповідних робіт, безвідносно моменту виплати, — це дозволяє однозначно пов'язати зроблені витрати з планом проекту і маршрутною картою.

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

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

Резюме

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

Витрати в ІТ-проекті розподіляються на дві категорії з різними принципами обліку. До першої категорії відносяться витрати, безпосередньо пов’язані з роботами по проекту. Ці витрати прив'язуються до відповідних їм позицій маршрутної карти; інші з маршрутною картою не співвідносяться. При порівнянні фактичних і планових витрат ті, які відносяться до робіт, підсумовують за період по статтях бюджету і позиціях маршрутної карти; інші підсумовують за період. Отримані суми порівнюються з бюджетом, виявлені відхилення аналізуються — при необхідності аж до окремих робіт.

3.3.2. контрольні запитання

1. Назвіть основні групи витрат у ІТ-проекті. Як співвідносяться витрати по проекту з позиціями плану проекту? Вкажіть призначення, розглядувані позиції витрат.

2. Як здійснюється контроль відповідності планових і фактичних витрат у ІТ-проекті? Розкажіть про використання маршрутної карти в аналізі відхилень.

3. Як розподіляються витрати на ІТ-проект по зданих в експлуатацію сервісах ІТ? Розкажіть про віднесення робіт в проекті до ресурсів і сервісів ІТ..

3.4. Інші проекти розвитку інформаційних систем:

загальні принципи ведення

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

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

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

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

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

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

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

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

Таким чином, вищевикладені принципи ведення проектів впровадження ЕRР-систем можна застосовувати і до проектів меншого масштабу. Для визначеності приведемо зміст етапів проектів для різних груп інформаційних систем (табл. 3.1).

Таблиця 3.1. Зміст етапів проектів по видах ІТ-проектів

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

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

Резюме

Методики ведення великих ІТ-проектів, такі як АSАР, можна застосовувати і для проектів меншого масштабу. Насамперед, заслуговує уваги прийнятий в цих методиках розподіл проекту на етапи і роботи, виконувані в рамках даного проекту. Далі, для будь-якого проекту важливі принципи документування результатів робіт і затвердження документів кінцевим користувачем. Нарешті, корисний принцип обліку витрат по моделі ФВА й обліку ризиків по методу дерева сценаріїв.

3.4.2.Контрольні запитання

1. Перелічіть і поясніть узагальнені етапи ведення ІТ-проекту. Які роботи виконуються на етапах підготовки, технічного проекту, реалізації, заключної підготовки для різних видів ІТ-проектів?

2. Які загальні вимоги до проектної документації? Розкажіть про типовий регламент ведення проектів і вимоги до нього.

3. Які загальні вимоги до обліку витрат і ризиків? Розкажіть про дерево сценаріїв і ФВА-моделі в узагальненому ІТ-проекті.

* * *

Підведемо підсумки. Проект впровадження інформаційної системи з економічної точки зору - цілком самостійна сутність. Це в однаковій мірі випливає як із змістовного аналізу проблем, так і з аналізу основного рівняння економічної оцінки ІТ-проекта (формула 1.1). Найвищий фінансовий результат досягається шляхом спільної максимізації грошового потоку доходів від експлуатації інформаційної системи і ймовірності успішного завершення проекту з врахуванням математичного очікування витрат у випадку зупинки (заморожування) проекту. З цієї причини максимізація фінансового результату здійснюється в два етапи. На першому серед можливих варіантів проекту вибирається варіант із найбільшим очікуваним грошовим потоком (тобто грошовим потоком, скоректованим на імовірність успішного завершення проекту). На другому організація проекту оптимізується з метою зниження імовірності відмови від проекту на пізніх стадіях розробки, коли значна чи навіть основна частина витрат на нього вже зроблена. Як показує проведений аналіз, стандартні методології впровадження систем, наприклад методологія ASAP для впровадження системи R/3, повністю підходять для цього. Поліпшення структури ймовірностей у проекті досягається такими методиками за рахунок:

- затвердження організаційної структури проекту з чітким розподілом ролей уже на першому етапі проекту,

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

- встановлення стандартів документації по проекту — опис біз­нес-процесів, налаштувань у промисловій системі, власних розробок і т.д.;

- фіксування вимог користувачів до системи в погодженому користувачами і розроблювачами концептуальному проекті: «вимоги користувача є те, що записано у концептуальному проекті»;

- зведення до розумного мінімуму власних розробок у проекті;

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

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

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

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

^[1] Явні витрати - витрати, що враховуються в прив'язці до певного об'єкту витрат (в даному випадку - до глобальної мережі), а не віднесені до загальних статей невигідних витрат. Детально будуть розглянуті в наступному розділі разом з прихованими витратами.

^[2] Даний перелік об'єктів витрат і управляючих параметрів не претендує на повноту і приводиться лише в ілюстративних цілях.

^[3] Галузь, розмір, географічне положення і т.д.

^[4] Детально проблеми цих методик будуть розглянуті в наступному розділі.

^[5] Далі буде показано, як на основі однієї і тієї ж прикладної системи - SAP R/3 – можуть бути побудовані сервіси абсолютно різного змісту.

1 Резервний сайт – приміщення, віддалене від основного офісу підприємства і забезпечене всією інфраструктурою електроживлення, зв’язку та ІТ, необхідного для продовження діяльності підприємства при виході із ладу головного офісу у випадку пожежі, стихійного лиха, терористичного акту 11 вересня 2001 р., безупинно продовжувати операції після руйнування їх офісів у Нью-Йорку.

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

1 Апарат ФВА буде розглянутий докладно у розділі 2.2.

1 Якщо критичний ресурс не може бути виділеним, процесорний час, оперативна пам’ять і дискова пам’ять розглядаються як окремі ресурси з окремими факторами витрат.

1 При аутсорсингу даного сервісу мова йде про персонал підприємства-аутсорсера.

[6] В методології ФСУ витрати розподіляються не просто на постійні і змінні, а на значно більше число категорій: пов’язані з одиницею продукту, з партією (серією), на підтримку виробничого процесу, ринку і т. д.

1 Під “неформальною моделлю бізнес-процесу” розуміється наявність в компанії співробітників – носіїв інформації про бізнес-процеси, які покривають всі суттєві процедури за умови включення таких людей в проектну групу

1 Відношення приросту вартості, доданої менеджером, до середньозваженої вартості капіталу

[7] Автоматизовані системи управління технологічними процесами

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

1 система “канбан” – система оперативного управління виробництвом на основі спеціальних карток замовлення, які супроводжують партії виробів у процесі їх обробки.

1 EDI – Electronic Documents Interchange, електронний обмін документами. Технологія передачі документів між підприємствами в електронному вигляді через стандартизовані форми.

1 Підсистеми електронного бізнесу, як правило, існують саме в ERP-системах і відсутні в більш ранніх стандартах.

1 1 Прогони MRP, CRP і інших алгоритмів також вимогливі до ресурсів системи, однак запускаються поодинці в спеціально відведений час, як правило вночі.

1 Як вже відмічалось, накладні витрати, які довільно розподіляються на об’єкти затрат, можливі і в моделі ФВА/ФВУ. Один із критеріїв віднесення затрат до накладних витрат як раз і зіставляє суми затрат на впровадження моделі ФВА/ФВУ і суми затрат, що описуються моделлю в даній групі бізнес-процесів.