Wbs cbs что это

Алгоритм описания структуры проекта в логической матрице

Структуризация проекта.

Управление проектомпредполагает построение структуры проекта, т.е. его разбивку на отдельные блоки, которые являются самостоятельными объектами планирования, учета, организации и координации.

Структура проекта – это совокупность взаимосвязанных элементов и процессов проекта с различной степенью детализации. В терминах управления проектами структура проекта представляет собой ″дерево″, ориентированных на продукт компонентов.

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

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

Для структуризации проекта применяется ряд специальных моделей:

3) структура работ (WBS),

4) организационная структура (OBS),

5) матрица ответственности,

7) структура ресурсов (RBS),

8) структура затрат (CBS).

1) «Дерево проблем» – схема, которая представляет основную проблему, на решение которой направлен проект, а также разбивает по уровням причины ее возникновения в нижней части и возможные последствия в верхней части, устанавливая для данной проблемы причинно-следственные взаимосвязи.

2) ″Дерево целей″ – схема, которая показывает, как генеральная цель проекта разбивается на подцели по уровням, при этом основным правилом разбиения является полнота их представления.

Цели (Scope) –совокупность продуктов и услуг, намеченных к производству в проекте.

Определение целей (Scope Definition) –декомпозиция основных результатов проекта на меньшие более управляемые компоненты.

Планирование целей (Scope Planning) –разработка документа, содержащего обоснование, основные результаты и цели проекта.

3) ″Дерево работ″, Структура разбиения работ (СРР), (WBS – Work Breakdown Structure) –иерархическая структура работ проекта, отражающая его основные результаты, количество уровней детализации в которой определяется достаточностью для планирования и мониторинга всех работ по проекту.

Результат (Deliverable)– любой измеримый продукт, который должен быть произведен для завершения проекта или его части.

Элементарный результат –самый нижний уровень ответственности менеджеров проекта.

Пакет работ (Work Package) –элемент нижнего уровня WBS, который подразделяется на операции. В WBS пакеты работ не связаны по времени.

Операция (Activity)или Задача (Task) –элемент проекта, на исполнение которого назначаются ресурсы.

4) Организационная структура исполнителей (OBS – Organizational Breakdown Structure) –иерархическая структура, которая определяет все уровни функционального управления работами проекта, начиная с руководителя и команды проекта на верхних уровнях и заканчивая организациями, их отделами и лицами, отвечающими за выполнение каждого пакета работ, на нижних уровнях. OBS определяется по перечню пакетов работ нижнего уровня каждой из ветвей WBS и представляется людьми, непосредственно организующими выполнение работ.

5) Матрица ответственности (RAM – Responsibility Assignment Matrix) – структура, ставящая в соответствие иерархическую структуру работ (WBS) и организационную структуру (OBS)для назначения ответственных на все пакеты работ проекта.

Матрица ответственности (Accountability Matrix)– матрица распределения ответственности за нижние элементы проекта.

6) Сетевая модель – сетевой график, который строится на основе дерева целей, WBS и OBS, и представляет собой множество объединенных между собой элементов для описания зависимости отдельных работ и этапов проекта.

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

8) Структура затрат (CBS – Cost Breakdown Structure)– иерархическая структура, которая фиксирует стоимость элементов проекта на каждом уровне.

Типичными статьями затрат для проекта являются:

1. Прямые затраты (затраты на пакеты работ):

2. Накладные расходы (консультанты, команда, обучение, командировки);

3. Общие и административные накладные расходы (50% от прямых затрат).

Существует два основных метода структуризации:

Искусство структуризации проекта состоит в умелом согласовании его основных структур, к которым относятся WBS, OBS, CBS, RBS и структура процесса, при этом WBS служит основой для данного согласования.

Различают двумерную и трехмерную структуры проекта:

· двумерная – объединение WBS и OBS;

· трехмерная – объединение WBS, OBS и CBS.

Двумерная структура проекта позволяет интегрировать, планировать, контролировать работу и сравнивать ее выполнение по подразделениям и в целом по организации. Если изобразить рабочую структуру по вертикали, а организационную – по горизонтали, то на пересечении получим элементы двумерной структуры, каждый из которых имеет свои ресурсы, свой бюджет, что создает систему учета затрат.

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

При расчете пакетов работ, оценивая затраты, время и ресурсы, менеджер должен следовать 6-ти правилам:

1. Ответственность.На уровне пакета работ расчетами должен заниматься тот, кто лучше всего знаком с заданием.

2. Нормальные условия.Расчеты должны основываться на нормальных условиях, эффективных методах и нормальном уровне ресурсов.

3. Единицы времени.Все расчеты времени работ должны иметь неизменные единицы времени.

4. Независимость.Расчет времени выполнения каждого задания должен производиться независимо от других заданий.

5. Непредвиденные обстоятельства.При расчетах пакетов работ не должны учитываться непредвиденные обстоятельства.

6. Ошибки в расчетах. Культура управления проектом должна давать право на ошибку в расчетах.

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

1. Определение целей проекта. Необходимо четко определить характер, цели и содержание проекта, его конечные продукты и их характеристики. При этом следует использовать иерархию целей – полную цепь результатов проекта и способов их достижения.

2. Анализ проекта.Необходимо продумать различные уровни детализации планов и определить количество уровней элементов в структуре проекта.

3. Структуризация проекта.Подготовка схемы жизненного цикла проекта.

4. Разработка структуры продукта проекта.Подготовка иерархической схемы работ.

5. Разработка организационной структуры проекта.Подготовка организационной схемы, охватывающей все группы и отдельных лиц, которые будут работать на проект, включая заинтересованных лиц из его внешнего окружения.

6. Анализ плана бухгалтерских счетов организации.Система кодов, используемых при структуризации, должна базироваться на существующем в организации плане бухгалтерских счетов.

7. Синтез проекта.Объединение пунктов 3-6 в единую структуру проекта.

8. Составление генерального сводного плана проекта.Утверждение укрупненного плана, который в дальнейшем может детализироваться в процессе поиска критического пути. В ходе реализации проекта сводный план может использоваться для докладов высшему руководству.

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

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

11. Разработка рабочего сетевого графика.Реализация предыдущих 10 шагов позволяет разработать детализированный график, который включает по каждой работе временные и ресурсные оценки.

12. Создание системы наряд-заданий.На данном этапе задания должны быть абсолютно конкретны по времени и ресурсам.

13. Организация системы контроля и отчетности.

Основные результаты структуризации проекта представляются в виде логической матрицы проекта, которая дает представление о взамосвязи результата и цели проекта, продукта проекта и деятельности по выполнению проекта.

Логическая матрица проекта – это инструмент, который позволяет системно представить проект на стадии разработки и использовать его для мониторинга на стадии выполнения и закрытия проекта.

Содержание логической матрицы проекта

Алгоритм описания структуры проекта в логической матрице

Источник

Что такое WBS проекта, и зачем она нужна

Хорошо, что лето в разгаре, заказчики по отпускам, и можно потеоретизировать. Сегодня у нас на очереди статья о том, что такое WBS проекта и зачем она нужна. Опытные РМы – пропускают, ничего нового там не будет. Новички – читают в обязательном порядке.

Что такое WBS проекта

WBS проекта (она же Work Breakdown Structure или ИСР, Иерархическая Структура Работ) – это разбиение проекта на конкретные результаты, которые должны быть достигнуты для достижения целей проекта.

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

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

В конце поста будут ссылки на скачивание этого и других примеров WBS!

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

В классическом подходе все блоки WBS (так называемые Work Packages) нумеруются, но в жизни я таких ответственных РМов видела буквально несколько раз. Сама я, как правило, нумеровать не то что бы ленюсь – просто не вижу смысла, так как после завершения планирования WBS использую как инструмент оперативного управления, и при нумерации становится сложнее поддерживать корректную интеграцию в проекте.

Зачем нужна WBS

WBS – крайне полезная вещь в планировании проекта и вот почему:

Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во вторых – у вас появится хороший рычаг влияния на будущее.

Группировка и декомпозиция WBS

Первый вопрос, который возникает в начале создания WBS – как группировать элементы WBS, по какому принципу?

Способ группировки, как правило, выбирается в зависимости от проекта, основной критерий тут – чтобы было понятно вам и команде.

Классические варианты группировки WBS:

Одним словом – можно любой свой вариант придумать, лишь бы было удобно.

Второй любимый вопрос начинающего PMа – до какой степени нужно детализировать WBS? Забавно, но правильного ответа на этот вопрос не существует. Степень декомпозиции зависит как от размера, так и от типа проекта, а также от количества времени, которое вы можете потратить на проработку.

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

При подготовке к сдаче PMP в книжке Риты Малкахи приводятся такие усредненные рекомендации:

В жизни такой идеальный баланс найти не всегда удается, поэтому в WBS попадают как небольшие задачи, результат которых критически важен для проекта, так и крупные. Так, например, в примере с ремонтом есть как «закрытие договора с текущим ЖЭКом» длительностью максимум 30 минут (ЖЭК у меня на 1м этаже сидит в соседнем подъезде), так и штукатурка по маякам, которая несколько дней займет (но мне с этим комфортно, так как проконтролировать промежуточный результат или как-то всерьез повлиять на скорость высыхания штукатурки я все равно не смогу).

В работе лично я стараюсь ориентироваться на планку «8 часов на нижнем уровне WBS».

Самый простой критерий, по которому можно проверить, что вы достигли «дна» WBS – это возможность поставить конкретную задачу одному исполнителю для выполнения указанного пакета работ. Если исполнителей несколько и выделить среди них единого ответственного нельзя – значит, нужно декомпозировать дальше.

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

Третий вопрос, отражающий веяния времени – что делать, если проект выполняется по гибкой методологии и результаты вы получаете итерационно?

Правильного ответа тоже нет, но есть варианты:

Инструменты для разработки WBS

Единственное правило тут – разрабатывать в том, в чем удобно. Если у вас есть какой-то инструмент для построения диаграмм – отлично, если нет – подойдет любой другой, например, Mind Manager, Excel, MS Project, Visio или любой онлайн-аналог.

Я последние пару лет перешла от диаграмм к майнд-мепам (ментальным картам), на мой взгляд, формировать структуру работ там очень удобно из-за гибкости инструмента. Самый неудачный выбор, на мой взгляд – это Excel или MS Project, так как они сводят создание WBS к работе со списками и не дают нужной наглядности.

Типовая ошибка тех, кто делает WBS в MS Project – одновременно пытаться описать результаты и указать зависимости (в самых тяжелых случаях – еще и трудоемкость и ресурсы). Цель WBS – получить именно полное содержание проекта, а не закрыть задачу планирования одним махом. А еще так легко что-то упустить, так как представление в MS Project не наглядное.

WBS Dictionary или Словарь ИБС

WBS Dictionary (он же Словарь ИБС) – это описание на страничку А4 (или подробнее) для каждого пакета работ, включающее код пакета работ, его наименование, детальное описание результата, критерии приемки, ответственного (это, наверное, самое ценное в словаре), ограничения и допущения и вообще все, что кажется вам полезным.

Я сама в жизни это использовала буквально 2 или 3 раза, слишком уж трудозатратная вещь, тем более в очень динамичных проектах разработки ПО. В какой-нибудь стройке или энергетике, наверное, без этого никуда.

Это, наверное, все, что нужно знать о создании и использовании WBS для старта. Удачи!

P.S. И да, неполная, недостаточная и не совсем правильная WBS все равно гораздо лучше, чем ее отсутствие

Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога 🙂

Источник

Оценка целесообразности инвестиций через функциональную структуру стоимости.

Многообразие видов декомпозиции проекта (продукта проекта) известно давно и в рамках проектной деятельности заключается, в основном, в умелом использовании основных структур, определяющих поток ключевых управленческих решений. Структура проекта – это совокупность взаимосвязанных элементов и процессов проекта, представленных с различной степенью детализации. В терминах управления проектами структура проекта представляет собой «дерево» ориентированных на продукт компонентов, представленных оборудованием, работами, услугами и информацией, полученными в результате реализации проекта. К ним чаще всего относятся именно структуры разбиения объектов и процессов (Объектно-ориентированные и процессно-ориентированные структуры), которые чаще известны как WBS, OBS, CBS, RBS и им подобные аббревиатуры. При этом WBS, чаще всего, служит основой для первичного разбиения задач и работ проекта, а потому наиболее популярна и исследована. Вместе с тем, имеет смысл вспомнить основной набор альтернативных структур разбиения процессов и объектов, так или иначе упоминаемых в проектной деятельности:

1. WBS (Work Breakdown Structure) или Структура разбиения работ (СРР) – наиболее часто используемая структура для анализа проекта, представляет собой иерархическую взаимосвязь работ проекта, отражающую его основные результаты, количество уровней детализации в которой определяется достаточностью для планирования и мониторинга всех работ по проекту.

2. CWBS (ContractWorkBreakdownStructure) или Иерархическая структура контрактов. В определенном смысле, такая структура является аналогом OBS если его отнести к строительным проектам. Правильнее такую структуру стоило бы называть – Контрактная модель проекта, поскольку в строительных проектах объем контрактации может достигать сотен контрагентов, а сами контракты, чаще всего, сложные или комплексные, то есть включают такой набор работ, который может не охватываться отдельным лицом или подразделением в OBS. Именно поэтому, OBS для строительных проектов менее предпочтительна по сравнению с CWBS, но и здесь надо учитывать стоимостной параметр контракта как ключевой фактор учета и контроля эффективности проекта.

3. PBS (Product Breakdown Structure) или Иерархическая структура продукта – это тоже общепринятая форма представления результатов проекта, которая описывает состав и иерархию компонентов продукта проекта. Если мы говорим о строительном проекте, например, здании, то как продукт оно состоит из строительных элементов – фундамента, каркаса, ограждения, крыши и т.д. Отчасти это похоже на WBS, но в иерархии компонентов продукта присутствует именно законченный элемент, описываемый как существительное. В отношении движимых продуктов это представить легче, поскольку такие элементы просто воспринимаются как детали и комплектующие. В WBSиерархия работ предполагает именно разбиение работ по созданию того же фундамента, каркаса или крыши, а эти работы могут быть идентичны и работам в других элементах продукта проекта. В определенном смысле, если речь идет о комплексном промышленном или инфраструктурном проекте с большим количеством самостоятельных зданий и сооружений, то состав проекта по титулам тоже можно считать PBS, поскольку каждое здание является компонентом общего продукта проекта – запущенного в эксплуатацию завода или предприятия.

4. OBS-1 (Organization Breakdown Structure) или Организационная структура исполнителей – это тоже иерархическая структура, которая определяет все уровни функционального управления работами проекта, начиная с руководителя и команды проекта на верхних уровнях и заканчивая организациями, их отделами и лицами, отвечающими за выполнение каждого пакета работ, на нижних уровнях. OBS определяется по перечню пакетов работ нижнего уровня каждой из ветвей WBS и представляется людьми, непосредственно организующими выполнение работ.

5. RBS-1 (Resource Breakdown Structure) или Структура потребления ресурсов – это тоже иерархическая структура, которая фиксирует ресурсы, необходимые на каждом уровне для достижения целей и подцелей проекта. Обычно сюда входят как материальные (то есть строительные материалы, конструкции и оборудование), так и человеческие ресурсы, а также необходимые расходные энергоресурсы, включая технику, машины, механизмы, временные здания и сооружения и иные сервисные издержки. Структура потребления ресурсов представляет собой иерархически построенный график, который фиксирует необходимые на каждом уровне ресурсы. Используется для анализа средств, необходимых для достижения целей и подцелей проекта и отчасти подобная структуре разбиения продукта (см. далее).

6. RBS-2 (Risk Breakdown Structure) или структура распределения рисков – это такой же важный и универсальный инструмент повышения эффективности проекта, который помогает руководителю визуализировать все риски проекта. Без RBS простой перечень рисков не будет иметь такого понятного иерархического представления. В иерархической структуре рисков должны быть представлены категории и подкатегории рисков, которые могут появиться на проекте, т.е. выполняется максимальная декомпозиция рисков. Для разных проектов и разных компаний применяется своя иерархическая структура рисков, но главным преимуществом данного подхода является то, что участники процесса идентификации детально анализируют все возможные риски из многочисленных источниках и в конце формируют общую картину рисков, которые присущи рассматриваемому проекту.

7. CBS (Cost Breakdown Structure) или Структура расходов или затрат – это важнейшая иерархическая структура, которая фиксирует стоимость элементов проекта на каждом уровне. Структура расходов фиксирует стоимость элементов проекта на каждом уровне. Именно CBS является наиболее спорным видом структуризации, поскольку, по аналогии с рисками, иногда подразумевают структурное содержание затрат: постоянные или переменные издержки, косвенные или прямые расходы. Вместе с тем, это одна из важнейших видом структуризации, поскольку связывает в своем содержании и риски проекта и контрактные комбинации CWBS, о котором мы говорили выше.

Для принятия эффективных управленческих решений иерархические структуры обычно рассматривают совместно, в форме различных матриц и кубов. Чаще всего, различают двумерную и трехмерную структуры проекта, например, наиболее типичная двумерная матрица – объединение WBS и OBS-1 в Матрицу ответственности (RAM – Responsibility Assignment Matrix) – структура, ставящая в соответствие иерархическую структуру работ (WBS) и организационную структуру (OBS-1) для назначения ответственных на все пакеты работ проекта. Такая двунаправленная структуризация проекта заключается в объединении рабочей и организационной структуры проекта и предусматривает поэлементный или попакетный учет расходов (RBS, CBS) и систему кодирования работ и узлов сетевого графика (CTR/CPP). Целесообразно составлять, кроме полного графика работ, сетевые графики отдельных пакетов работ, которые называются сетевыми блоками или подсетями. Это обеспечивает возможность проведения эффективного контроля, разрешает больше внимания уделять управлению наиболее важными (критическими) подсетями, заменив процедуру постоянного контроля всего сетевого графика и значительно экономя время. Двумерная структура проекта позволяет интегрировать, планировать, контролировать работу и сравнивать ее выполнение по подразделениям и в целом по организации. Если изобразить рабочую структуру по вертикали, а организационную – по горизонтали, то на пересечении получим элементы двумерной структуры, каждый из которых имеет свои ресурсы, свой бюджет, что создает систему учета затрат.

Классическая методология предполагает, что трёхмерная (кубическая) структура проекта создается добавлением к двумерной матрице третьей оси, позволяющей увидеть взаимную увязку элементов проекта в разных срезах. Трёхмерная матрица уже предусматривает и учет затрат по видам работ и контрактным группировкам, и описание пакетов работ, и их кодировку, необходимые инструменты и словари. Трехмерная структура проекта позволяет собирать и анализировать информацию о затратах, а также готовить отчеты о затратах для любого подразделения или элемента работ. Неудивительно, что часто третью ось такой кубической матрицы и представляют в формате структуры затрат – CBS. И тут как раз начинается основной когнитивный дисбаланс в теории и полезности такой структуры.

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

Разумным переходом от подобной смешанной трёхмерной структуры является переход к одноразмерным осям, где каждая ось измеряется только одним параметром – СТОИМОСТЬЮ. Стоимостное выравнивание осей позволяет не только адекватно воспринимать структурное разбиение, но и делать главную задачу лиц, принимающих решения – моделировать стоимость элементов с позиции полезности для реализации проекта в будущем. Для этого достаточно предположить, что любые структуры разбиваются иерархически не по физическим или иным основаниям, а именно – по основанию стоимости. Например, если мы представим ту же классическую матрицу RAM в виде соизмеримых структур, то она станет скорее матрицей WBS-OBS, но другого типа. Здесь OBS-2 – это вариант PBS, который формализован как OBS-2 – Object Breakdown Structure или структура разбиения комплексного проекта на титулы, на отдельные здания, сооружения, системы, комплексы, внешние инженерные сети и иные элементы генплана. Крестиками в квадратиках показаны элементы стоимости, которые или присутствую, или отсутствует в конкретном элементе структуры. Логично, что в таком разбиении суммарные итоговые значения стоимости ДОЛЖНЫ БЫТЬ РАВНЫ! Иными словами, если уж создавать 3D-матрицу, то все оси там будут стоимостные, а сама матрица будет называться: 3D—CBS.

Что дает такая матрица? Преимуществ здесь очевидно больше, чем в разномерных осях (например, работы и оргструктура), поскольку становится очевидно, что матрица позволяет более эффективно формировать контрактную модель, как с учетом сетевого графика по времени, так и с учетом загрузки конкретных исполнителей на площадке. И, соответственно, точнее видеть потребность в финансировании и закупках. Теперь, если применить подобный подход к другим видам структур, становится очевидным, что они становятся здесь не применимыми. Например, если вставить третьей осью риски, то данная матрица просто теряет смысл, даже если риски выражены в стоимостных показателях. И если уж мы решили найти сочетаемый аналитический срез проекта, то он может быть, например, ресурсный. Очевидно, что при выполнении задач стоимостного инжиниринга, особенно в части оценки новых проектов и целесообразности инвестиций, в BIM-данных будут полезны комплексные очищенные стоимости или зданий и сооружений, или сводных комплектов материалов. А если выбрать основные материалы-представители, несущие на себе 80-90% очищенного CAPEX, то прогнозные оценки будут максимально точными без лишних сборов данных. Здесь стоимостному инженеру предоставляется возможность выбора наилучшего метода оценки стоимости нового проекта: или аналоги выбрать по объемам материалов, или взять аналоги уже когда-то строившихся зданий и сооружений в рамках релевантного допущения условий строительства и эксплуатации. Или, что архиважно, одновременно использовать и ту и другую возможность по разным титулам. По полностью повторяемым титулам, например – полная стоимость аналога, по частично-применимым – стоимость материальных ресурсов и пакетов оборудования. Третий срез данного куба – это срез RBS-OBS – дает очевидную стоимостную раскладку ресурсов по титулам. В результате мы имеем возможность варьировать сценарии оценки просто по факту наличия или отсутствия информации как о полной стоимости объектов-аналогов, так и об их ресурсном наполнении в любом приемлемом наборе.

Но для эффективного стоимостного моделирования новых проектов этих данных явно недостаточно. Особенно это касается сложных промышленных предприятий с многофункциональными технологическими линиями с большим числом переделов и вспомогательных сервисов. Однозначно оценить такое предприятие по неким аналогам просто невозможно в силу банального их отсутствия или возрастного несоответствия. С другой стороны, и ресурсные оценки могут уже не отвечать требованиям, поскольку в ход идут новые технологии, новые материалы и оборудование, новы технологии организации строительном-монтажных работ и пуска. Это говорит о том, что стоимостная 3D-матрица WBS-OBS-RBS уже не дает ответа на вопрос о наиболее эффективных проектных решениях.

Полноценный анализ строящего объекта недвижимости, независимо от того, является он монопродуктовым (то есть одно здание) или имеет большое количество разнообразных зданий и сооружений, возможен при рассмотрении всех стоимостных аспектов при оценке целесообразности инвестиций. Крайне важным аспектом, в этом свете, является стоимостная оценка конкретных функциональных систем будущего объекта недвижимости. Такая оценка проводится по методологии Функционально-стоимостного анализа (ФСА или Activity Based Costing, АВС), который мы обычно ассоциируем с одним из методов определения себестоимости товарной продукции или услуги, но не объекта недвижимости. ФСА-анализ – это метод определения стоимости и других характеристик изделий, услуг и потребителей, в основе которого лежит использование функций и ресурсов, задействованных в производстве, маркетинге, продаже, доставке, технической поддержке, оказании услуг, обслуживании клиентов, а также в обеспечении качества. При этом мы часто забываем, что себестоимость продукции, в том числе посчитанной посредством АВС-костинга, должна включать и амортизационную долю тех активов, которые приняли участие в её создании. А соответственно стоимость такой продукции (например, электроэнергии) будет включать сумму (CAPEX+OPEX)на функциональную себестоимость конкретного продукта. Именно с этой позиции, функциональная структура проекта начинает играть важную роль в стоимостной оценке: мы должны точно понимать какой вклад в функциональную стоимость продукта вносит конкретный функциональный актив, т.е. совокупность ресурсов, потраченных на создание и эксплуатационную пригодность конкретного функционального блока. Именно поэтому ФСА-анализ часто называют методом системного исследования функций объекта с целью поиска баланса между себестоимостью и полезностью.

Пример здесь может самый простой. Если мы знаем, что нам необходим для производства продукции сжатый воздух, который требуется различных цехах, но не во всех зданиях, то нам надо принять решение или о его производстве в заводских условиях, либо о его закупки у поставщиков из внешних установок. Сравнить эти два сценария можно только если мы четко осознаем реальную себестоимость куба сжатого воздуха нужного качества при определенном ТУ давлении. Для этого мы анализируем все капитальные затраты на создание системы генерации, подачи и утилизации сжатого воздуха по всем потребителям (функциональный CAPEX), оцениваем операционные издержки на его производства (функциональный ОРЕХ) и, исходя из срока работы установки и системы в целом, её максимальной и минимальной производительности, оцениваем себестоимость куба сжатого воздуха собственного производства. Вероятно, это будет очень дорогой куб воздуха (не очень часто он нужен), по сравнению с закупкой такого воздуха у соседнего предприятия, где он требуется постоянно.

Функционально-стоимостной анализ – это больше чем просто метод оценки стоимости, это технология, позволяющая оценить реальную стоимость продукта или услуги безотносительно к организационной структуре компании. Как прямые, так и косвенные расходы распределяются по продуктам и услугам в зависимости от объема ресурсов, требуемых на каждом из этапов производства. Действия, производимые на этих этапах, в контексте метода ФСА и называются функциями (Activities), а конечная цель состоит в обеспечении правильного распределения средств, выделяемых на производство продукции или оказание услуг, по прямым и косвенным издержкам. Это позволяет наиболее реалистично оценивать расходы компании. Именно поэтому имеет смысл говорить о трансформации нашей стоимостной 3D-матрицы в функционально-стоимостную матрицу, имеющую ось с FBS-CAPEX (Functional Breakdown Structure).

Иными словами, мы создаем новую иерархическую структуру на основе функционально-стоимостного анализа будущего объекта недвижимости под аббревиатурой FBS (Functional Breakdown Structure)или Функциональная Структура затрат. Предполагая, что это еще одна важная иерархическая структура, которая фиксирует стоимость элементов проекта по каждой производственной функции, выделение которой имеет свою целесообразность и аналитическую обособленность. Примеры таких функций могут быть самые разнообразные и, в общем случае, они могут охватывать совершенно разный набор зданий и сооружений. Для проведения стоимостного выравнивания обычно формируется или реальная технологическая функция (технология основного производства), в которую входят все прочие элементы строительства и ресурсы, не вошедшие в конкретные функции. Или номинальная организационно-управленческая функция, например, для непромышленных проектов, которая объединяет в себе все прочие затраты. Для промышленных предприятий, управленческая функция в принципе может рассматриваться как самостоятельная, а может и как интегральная, в которую входя и транспортные задачи, и сети связи и иные управленческие функциональные ресурсы.

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

С позиции оценки стоимостной 3D-модели будущего объекта недвижимости, функциональная структура декомпозиции может использоваться как взамен WBS и формировать кубический стоимостной блок типа FBS – OBS-2 – RBS-1. Или заменить иной аналитический срез, например, убрать анализ по зданиям и сооружения комплексного проекта, просто в силу того, что строится одиночное здание. Даже одиночное здание имеет работы по благоустройству, подводу внешних инженерных сетей, устройству дорог и внешней защиты и т.п., то есть набор отдельных объектов присутствует, но он привязан к одному зданию. Тогда стоимостная модель будет иметь формат FBS – WBS – RBS-1, которая дает возможность анализа и формирования контрактных группировок по видам работ и ресурсам в соответствие с функциональными задачами. Очевидно, что стоимостное моделирование функций становится важной часть планирования как промышленного производства, так и иных крупных инфраструктурных проектов, особенно таких, которые всегда имеют аутсорсинговую альтернативу. Более того, такие проекты должны и обязаны генерировать такую предпринимательскую альтернативу в местах локализации крупных проектов.

Каждый отдельный кубик в такой трехмерной конструкции представляет собой уникальную стоимостную единицу, которая одновременно содержит коды ресурса, объекта недвижимости, работы и функциональной группировки. Отнести такую единицу к контракту или иному организационному делению возможно, но только после наполнения этих цен индексными показателями, созданными в рамках конкретного проекта. В набор этих индексов входит, как и перераспределение прибыли проекта между всеми участниками, а также оценка и покрытие рисков в рамках плана управления рисками. Именно здесь появляется необходимость оценки рисков конкретных функций, например, остановка линии подачи воздуха или иной энергосреды. В любом случае, именно такие стоимостные блоки являются составляющими элементами того или иного контракта и формирования его предельной или целевой стоимости для проведения торгов. Разумеется, мы предполагаем, что каждый элемент стоимости представляет собой максимальную стоимость для Заказчика, потому поиск оптимального контракта может строиться не только на основе графика выполнения работ, проектирования и поставок, но и на основе компенсационных балансов цены контракта, когда затраты на мобилизацию в одном объеме работ могут быть компенсированы последующими дополнительными соглашениями и объемами, не включающими эти затраты. И таких примеров стоимостного моделирования можно привести много.

С другой стороны, функциональная структуризация влияет на организацию пуска и поочередного ввода в эксплуатацию тех или иных зданий и сооружений, необходимых для комплексного пуска. Очень часто бывает так, что некоторое строение будет сдаваться много позже, чем включенная в его функциональная система, охватывающая всё предприятие. А поскольку эта же система требуется для промежуточного пуска или испытаний, то и все это здание придется строить раньше обычного. Либо принимать решение о создании временных функциональных сооружений и сетей, которые позволят провести испытания без упомянутого здания. А это уже решение о стоимости и о рисках, а также и об объемах контракта, выносимого на конкурс.

Наконец, если вернуться к вопросу управления стоимостью на всех этапах жизненного цикла проекта, можно констатировать, что представленная модель FBS или Функциональной структуры стоимости нам кажется абсолютно работоспособной и применимой для автоматизации и оцифровки задач управления стоимостью, а не только стоимостного инжиниринга. Мы уже предложили методику экспресс-анализа текущей стоимости любого проекта исходя из фиксированной стоимости конкретного элемента на своем этапе. В случае существенных колебаний стоимости можно принимать корректирующие решения не только в отношении того или иного здания или сооружения, а в отношении функциональной системы, например, просто заменив её целиком на более дешевую альтернативу. Это может быть и просто отказ от целой системы и, соответственно, уменьшение объемов строительно-монтажных работ. Так или иначе, функциональная структура – существенный инструмент управления стоимостью будущего объекта недвижимости.

Источник