2018.08

ВОПРОСЫ АВТОМАТИЗАЦИИ ПРОЦЕССОВ БЮДЖЕТИРОВАНИЯ В РАЗРЕЗЕ ПРОЕКТНОГО УПРАВЛЕНИЯ

Аннотация

В работе рассмотрены вопросы построения автоматизированной системы планирования и бюджетирования с учетом специфики управления проектами (проекты могут быть долгосрочными и длиться в течении нескольких лет, в проекте могут принимать участие на разных этапах разные контрагенты, которые в свою очередь привлекают к участию в проекте своих контрагентов). Отмечено, что современные системы управления эффективностью бизнеса (BPM/CPM/EPM системы) позволяют реализовать бюджетное управление в разрезе проектов, с учетом существующей специфики в рассматриваемой области. Сформулированы требования к решению на базе систем управления эффективностью, учитывающие эти аспекты. Отмечено, что использование в решении показателей освоенного объема позволяет на основе финансовых данных оценивать состояние и прогноз развития проекта.

Востребованность проектного управления

В настоящее время в своей деятельности многие компании используют технологии управления проектами. Например, этот подход применяют IT-компании при разработке, создании и внедрении информационных систем. Практика управления проектами используется в строительстве. Проведение научно-исследовательских и/или опытно-конструкторских работ также может быть организовано на принципах проектного управления. Более того, анализируя существующую практику, можно отметить, что технологию управления проектами для организации работ используют именно в условиях ограниченности ресурсов и “жестких” сроках выполнения работ,

Особенности проектного управления и бюджетирование

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

Если в проекте планируется задействовать ряд контрагентов, то в этом случае, с учетом обязательно существующей на проекте иерархии управления/подчиненности, возникает потребность для участников кооперации (вплоть до конкретного контрагента) решать в том числе вопросы:

- комплексного планирования финансирования (доходов) и расходов по проекту, а также вопросы контроля движения денежных средств;

- получения финансовой отчетности по плановым и фактическим данным в различных аналитических разрезах;

- мониторинга и аудита выполнения финансовых аспектов проекта.

При этом возникает необходимость консолидации финансовой (и нефинансовой) информации по всем организациям, принимающих участие в проекте. С другой стороны, для конкретной организации необходимо иметь полную картину по всем проектам, в которых она задействована.

Постановка задачи

Таким образом, приходим к необходимости решения задачи планирования и бюджетирования финансово-хозяйственной деятельности компании/компаний в разрезе проектов с учетом иерархической структуры подчиненности задействованных в проекте организаций. При этом необходимо предусмотреть, что на разных этапах проект могут быть задействованы разные организации, а горизонт планирования может быть несколько лет.

Инструменты

Безусловно, существуют специализированные программные комплексы:

- и для решения задач, связанных с управлением проектами (как зарубежные - начиная от MS Project и заканчивая Oracle Primavera, так российские -например, Spider Project),

- и для задач планирования и бюджетирования (например, OEPM system Oracle Hyperion Planning компании ORACLE или программный комплекс PlanDesigner от pоссийской компании SoftProm).

Существуют программные комплексы, в которых уже изначально были заложены и реализованы механизмы интеграции между системой “бюджетирования” и системой с возможностью “оперативного управления проектами” (например, программный комплекс PlanDesigner–UPI российской компании SoftProm).

В современных программных комплексах, например, в OEPM системе Oracle Hyperion Planning, уже присутствует инструментарий, необходимый   для реализации задачи планирования и бюджетирования с учетом проектного характера организации работ в компаниях. (В этом случае речь не идет об оперативном управлении проектами, а именно о вопросах бюджетирования).

Основные требования к решению

Рассмотрим основные требования, которым должно удовлетворять решение, создаваемое в рамках таких программных комплексов.

· Иерархическая структура подчиненности

Во-первых, в создаваемом решении необходимо реализовать иерархическую структуру подчиненности (основная/контрагенты) и, соответственно, финансирования в рамках проводимых работ (см. рисунок 1).

Например, “Организация_1” является инициатором проекта, ее контрагентами по этому проекту являются организации: “Организация_2”, “Организация_3” и “Организация_5”. В свою очередь “Организация_3” задействует на проекте “Организацию_4”, а “Организация_5” привлекает на проект “Организацию_6” и “Организацию_7”.

Рисунок 1. Взаимоотношение участников проекта по иерархии подчиненности и финансирования

Во-вторых, потребуется указать какие контрагенты в какие периоды и на каких этапах принимают участие в проекте.  Соответственно, в решении должна быть возможность:

- задать временные характеристики этапов проекта (см. рисунок 2);

- указать какие организации принимают участие в каких этапах проекта (см. рисунок 3);

- и сформировать матрицу, связывающие временные параметры проекта с участниками проекта и их иерархической структурой подчиненности/финансирования (см. рисунок 4).

· Поддерживаемые бизнес-процессы

В решении должны быть реализованы бизнес-процессы:

- планирования, согласования и утверждения стоимости работ и расхо­дов (бюджет доходов и расходов) как в самой компании, так и в организациях-контрагентах по проекту;

- получение данных о фактическом исполнении бюджетов;

- план-факт анализ исполнения бюджетов.

Рисунок 2. Этапы проекта по периодам и годам

Рисунок 3. Матрица участия организаций в проекте в разрезе этапов проекта

Рисунок 4. Матрица участия организаций в проекте по годам, периодам и этапам проекта в разрезе уровней детализации и иерархии подчиненности

В решении должны быть созданы возможности для планирования и бюджетирования в части:

- стоимости работ и затрат по этим работам (бюджет доходов и расхо­дов);

- движения (поступление и выбытие) денежных средств

в требуемых аналитических разрезах, позволяющих ответить на “простые” вопросы:

- кому, сколько, по какому проекту (теме)/этапу/подэтапу и когда мы должны заплатить;

- кто, сколько, по какому проекту (теме)/этапу/подэтапу и когда нам должен заплатить.

· Аналитические разрезы

Поэтому, по крайней мере, должны присутствовать следующие  аналитики:

- организации;

- проекты;

- этапы/подэтапы/подподэтапы проекта;

- годы;

- периоды (внутри года);

- направления финансирования (стоимость своих работ, стоимость ра­бот контрагентов);

- показатели (финансовые и натуральные).

В решении, также, должны поддерживаться различные сценарии планирова­ния, а также разные версии планов.

Рисунок 5. Пример аналитических измерений, в разрезе которых рассматриваются и анализируются данные.

· Технологии планирования

Представляется, что в решении следует реализовать возможности следующих технологий планирования:

- «сверху-вниз» (от общего к частному), в этом случае делается оценка в объемах финансирования участников проекта, исходя из общей суммы проекта;

- «снизу-вверх» (от частного к общему), когда делается оценка объема финансирования всего проекта, исходя из обоснованных потребно­стей в финансировании участников проекта.

Рисунок 6. Технология планирования «сверху вниз».  Распределение общего объе­ма финансирования по этапам (в соответствии с заданным процентом)


Рисунок 7. Технология планирования «сверху вниз». Распределение общего объе­ма финансирования по годам


Рисунок 8. Технология планирования «сверху вниз». Пример распределения общего объе­ма финансирования по контрагентам

Рисунок 9. Технология планирования «снизу вверх». Формирование бюджета проекта «от расходов»

Поскольку горизонт планирования может достигать несколько лет, то в решении, безусловно, должен быть реализован механизм переплани­рования – когда, исходя из фактических данных по исполнению работ, возникает необходимость проводить корректировку плановых данных в пределах оставшегося периода работ.

Соответственно, в системе должны храниться и плановые, и фактические данные за рассматриваемые периоды. Причем должен быть реализован механизм автоматического импорта фактических данных из используемых учетных систем контрагентов.

· Анализ и прогноз

В системе должны быть реализованы механизм проведения план-фактного анализа в рассматриваемых разрезах аналитических измерений. Должны быть реализованы механизмы расчета отклонения фактических значений от плановых (План-Факт) как в абсолютном выражении, так и в относительном ((План-Факт)/План).

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

Рисунок 10. План-фактный анализ финансирования и затрат «по своей ком­пании». Красным цветом выделено «недофинасирование» (плановое значе­ние больше фактического). Желтым цветом выделены ячейки таб­лицы, в случае превышения фактических затрат над плановыми.

· Оценка состояния проекта

Более того, представляется, что в решении должны быть задействованы и механизмы, которые на основе финансовой информации позволяют получить оценку состояния проекта (с точностью до шага планирования) как по этапам проекта, так и для проекта в целом. А также выявить «слабые звенья» (например, контрагентов, допускающих отставание от плана и т.д.). Для этого целесообразно использовать показатели «освоенного объема» (см. [1] .. [3]), которые включают:

- Базовые показатели, например,:

­ PV - плановый объем из бюджета проекта, разбитый на периоды и формируемый кумулятивно (сумма планируемых расходов по проекту);

­ EV - реально выполненный объем работ, указанных в бюджете по плановой стоимости (сумма тех фактических расходов по проекту, которые были изначально заложены в плане EV PV);

­ AC - фактически понесенные затраты на реализацию проекта на конкретный момент времени (сумма всех расходов по проекту, включая и незапланированные);

- Отклонения, например,:

­ SV - показатель отклонения от графика, показывающий отстает проект ли от графика или опережает его (SV=EV-PV, разница между тем, сколько было потрачено из того что планировалось, и изначально запланированной суммой расход);

­ CV - показатель отклонение no стоимости, показывающий находится проект в рамках или за рамками бюджета                       (СV=EV-АС - разница между тем, какие суммы были потрачены из запланированных сумм расходов и суммой понесенных расходов, включая незапланированные);

- Индексы, например,:

­ SPI  - индекс выполнения расписания, показывающий насколько в проекте опережаются сроки или же от них есть отставание        (SPI = EV / PV);

­ CPI  - индекс выполнения стоимости, показывающий сколько тратится денег на один запланированный рубль, насколько сильно недорасходуется или перерасходуется бюджет                 (CPI = EV / AC);

- Прогнозы, например,:

­ EAC - прогнозная стоимость проекта, позволяющий оценить какова ожидаемая стоимость (затраты) этапа проекта/проекта на конкретно взятый момент времени.

В качестве величины значений для показателей PV, EV, AC используется исходящее сальдо (конкретного показателя) на момент окончания рассматриваемого периода.

Представляется важным, еще раз подчеркнуть, что в решении должны быть реализованы сервисные возможности по формированию и передачи фактических данных из учетных систем для расходов освоенного объема и полных расходов (для рассматриваемых моментов времени).

На рисунке 11 представлена таблица с некоторыми из рассмотренных выше показателей «освоенного объема».

Рисунок 11. Показатели освоенного объема по этапу проекта в разрезе «по своей компании».

Ожидаемые результаты

Представляется, что решение, в котором реализованы рассмотренные выше требования, позволит:

- уменьшить трудозатраты на планирование (за счет сокращения сроков планирования, повышения точности планирования объема финансирования проектов, сокращения сроков согласования и т.д.),

- повысить контроль (фактическое состояние исполнения бюджета по проекту)

- повысить точность анализа (выявление отклонений от плана) проведения работ по проекту;

- обеспечить «прозрачность» исполнения финансирования проекта по всей цепочке кооперации (вся информация по всем контрагентам хранится в одном месте);

- обеспечить «мгновенный» доступ к информации и формирование отчетности по проекту/проектам, в том числе консолидированной, в требуемых для принятия решений аналитических разрезах (вся информация изначально “раскладывается” и храниться в этих разрезах);

- топ-менеджерам получить оценку состояния и прогноз развития проекта исходя из имеющихся финансовых данных.

Заключение

Таким образом, в работе рассмотрены особенности планирования и бюджетирования в разрезе учета специфики управления проектами. Отмечено, что современные BPM/CPM/EPM системы позволяют реализовать бюджетное управление в разрезе проектов. Сформулированы требования к решению, реализующие эти задачи. Сформулированы преимущества для пользователей, которые они получат после внедрения такого типа решения.

М.Ковалев

2017-2018 г.

Ссылки

1) Метод управления освоенным объемом

http://forpm.ru/метод-управления-освоенным-объемом/

2) Ильюшенко Н. Метод освоенного объема в управлении проектами.

http://fb.ru/article/286671/metod-osvoennogo-obyema-v-upravlenii-proektami

3) Султанов И. А. Управление освоенным объемом и своевременные решения

http://projectimo.ru/realizaciya-proekta/metod-osvoennogo-obema.html