Процедура адаптации модели ЖЦ ИС
При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия.
- Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают (но не ограничиваются) перечисленное ниже:
- стабильность и разнообразие среды функционирования;
- коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;
- новизну, размеры и сложность;
- дату начала и продолжительность применения;
- вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения,
- доступность;
- вновь возникающие технологические возможности;
- бюджетный профиль и доступные организационные ресурсы;
- готовность предоставления услуг обеспечивающими системами.
- При наличии свойств, критичных по отношению к системе, руководитель проекта должен учесть структуры ЖЦ, которые рекомендованы или установлены в качестве обязательных стандартами, соответствующими области критичности.
- Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта:
- правообладатели системы;
- заинтересованные стороны соглашения, заключенного организацией;
- стороны, вносящие вклад в организационные функции.
- Руководитель проекта определяет новую (модифицированную) модель жизненного цикла системы в терминах стадий, их назначения, целей и результатов, которые достигаются вследствие применения процессов жизненного цикла в пределах каждой стадии.
- Проектный офис принимает решение об адаптации базовой модели.
- Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной (под)системы) или общекорпоративный характер по решению проектного офиса, по результатам апробации предложенной РП модификации.
| Описание причины: | |||||||
|---|---|---|---|---|---|---|---|
| Действия | Базовый | Модифицированный | Характеристики модифицированного этапа/процесса | ||||
| Этап | Процесс | Этап | Процесс | Назначение | Цель | Результат | |
| _ | |||||||
| _ | |||||||
| Дата подачи заявки (руководитель проекта): | |||||||
| Дата принятия решения (проектный офис): | |||||||
| Дата начала применения: |
Разработка технико-экономического обоснования
Традиционно основной целью подготовки технико-экономического обоснования ( ТЭО ) ИТ-проекта является получение финансирования на реализацию соответствующей инициативы.
Кроме того, корректно составленное ТЭО может решать следующие задачи:
- приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;
- определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта;
- обеспечение заинтересованности руководителей бизнес-подразделений в проекте;
- формирование основы для оценки соответствия результатов проекта и первоначальных планов.
Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время всего лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].
Помимо обозначенных задач ТЭО может обеспечивать входную информацию для устава проекта, рассматриваемый в данной книге как ключевой документ интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную информацию, рекомендуется следующим образом структурировать идентифицированные бизнес-выгоды ИТ-проекта (см. табл. 1.4.).
В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается «на пересечении» соответствующих значений двух обозначенных факторов.
Использование матрицы структурирования выгод начинается с определения характера воздействия на бизнес каждой из них. Определены три типа воздействия.
- Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
- Повышение эффективности операций:функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
- Отказ от операций:информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
| ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС | ||||
|---|---|---|---|---|
| Создание новых возможностей | Повышение эффективности операций | Отказ от операций | ||
| СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ | Финансовые | |||
| Количественные | ||||
| Измеримые | ||||
| Качественные |
После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые (качественные), измеримые, количественные, финансовые.
- Качественные: выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для «переноса» качественных выгод в более объективные категории.
- Измеримые:выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
- Количественные:аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
- Финансовые:это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат «обогащения» количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.
Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории — наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы (TCO), рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта.
Формирование бизнес-цели проекта
Бизнес-цель — это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).
Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.
Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО, или бизнес-кейс, проекта.
Разработка устава проекта
Устав проекта — это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях, т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта, должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.
Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта. К информации, имеющей ключевое значение для составления устава, относятся:
- стратегические и тактические цели организации-заказчика;
- формулировка требований организации-заказчика;
- ТЭО ;
- контракт;
- внутрикорпоративная методология управления проектами и соответствующие политики.
Решение о выполнении проекта — итог процесса отбора проектов, основанного на информации, которая изложена в вышеуказанных документах. Таким образом, крайне важно давать прямую ссылку в соответствующих разделах устава на них с тем, чтобы придать уставу больший вес.
В табл. 1.5 приведены требования к уставу проекта — перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.
| № | Раздел | Пояснения |
|---|---|---|
| 1. | Название проекта | Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания |
| 2. | Бизнес-причина возникновения проекта | Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте |
| 3. | Бизнес-цель | Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел «Формирование бизнес-цели проекта « |
| 4. | Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта | Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта |
| 5. | Расписание основных контрольных событий | На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий — это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18] |
| 6. | Участники проекта | Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел «Идентификация участников проекта» |
| 7. | Окружение проекта | Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика — к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники — участники, овалы — факторы окружения) [20] |
| 8. | Допущения относительно организации и окружения, а также внешние допущения | Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе |
| 9. | Ограничения относительно организации и окружения, а также внешние ограничения | Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ [11]. Пример ограничений проекта:
Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом |
| 10. | Объем денежных средств, выделенных на достижение бизнес-цели | На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% [18] |
| 11. | Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор | Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта — объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [8,18]. Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект2Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта — по одному от заказчика и исполнителя. . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18]. Администратор (координатор) проекта — это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена |
-
Разработка технико-экономического обоснования
Традиционно
основной целью подготовки
технико-экономического обоснования
(ТЭО)
ИТ-проекта является получение
финансирования на реализацию
соответствующей инициативы. Кроме того,
корректно составленное ТЭО
может решать следующие задачи:
-
приоритизация
проектов в условиях ограниченных
финансовых, человеческих и прочих
ресурсов; -
определение
совокупности организационно-технологических
мероприятий по обеспечению заявленных
бизнес-выгод от реализации проекта; -
обеспечение
заинтересованности руководителей
бизнес-подразделений в проекте; -
формирование
основы для оценки соответствия
результатов проекта и первоначальных
планов.
Согласно
последним исследованиям 75% компаний
ставит именно такие цели при подготовке
ТЭО,
в то же время все лишь 40% из них считают,
что используемые ими методы позволяют
получить корректную оценку эффективности
внедряемого ИТ-решения.
Помимо
обозначенных задач ТЭО
может обеспечивать входную информацию
для устава проекта, рассматриваемый в
данной книге как ключевой документ
интегрированного управления проектом.
Для того чтобы ТЭО
обеспечивал качественную информацию,
рекомендуется следующим образом
структурировать идентифицированные
бизнес-выгоды ИТ-проекта (см. табл.
2.1.).
В
соответствии с предлагаемым подходом
бизнес-выгоды можно классифицировать
по двум факторам: (1) характеру воздействия
на бизнес и (2) степени определенности.
Таким образом, каждая выгода по проекту
размещается «на пересечении»
соответствующих значений двух обозначенных
факторов.
Использование
матрицы структурирования выгод начинается
с определения характера воздействия
на бизнес каждой из них. Определены три
типа воздействия.
-
Создание
новых возможностей:
функциональность информационной
системы, ранее не доступная компании,
ее контрагентам или иным заинтересованным
сторонам. -
Повышение
эффективности операций: функциональность
новой информационной системы позволяет
выполнять существовавшие до нее операции
гораздо более эффективно. -
Отказ
от операций: информационная
система позволяет отказаться от
выполнения операций, утративших свою
актуальность для бизнеса компании в
связи с изменением бизнес-процессов.
|
Таблица |
||||
|
ХАРАКТЕР |
||||
|
Создание |
Повышение |
Отказ |
||
|
СТЕПЕНЬ |
Финансовые |
|||
|
Количественные |
||||
|
Измеримые |
||||
|
Качественные |
После
определения характера воздействия
необходимо классифицировать каждую
бизнес-выгоду по степени определенности
(от менее определенных к более
определенным): наблюдаемые, измеримые,
количественные, финансовые.
-
Качественные:
выгоды, которые могут быть зафиксированы
на уровне экспертного мнения или
суждения. В то время как данный тип
выгод вполне допустим, необходимо
всегда предупреждать ситуацию, когда
без четкого значения выгоды на этапе
планирования очень сложно определить
степень ее реализации на момент принятия
результатов проекта. В связи с этим
рекомендуется разрабатывать четкие
критерии реализации качественных выгод
в самом начале проекта и, по возможности,
собирать дополнительную информацию
для «переноса» качественных выгод
в более объективные категории. -
Измеримые:
выгоды
данного типа поддаются измерению. В
расположении аналитика есть инструменты
и техники, например, ключевые показатели
эффективности, позволяющие измерить
их значение до внедрения. Для данного
типа бизнес-выгод характерна невозможность
оценить значение соответствующего
показателя после внедрения. -
Количественные:
аналогично
измеримым, количественные выгоды
характеризуются наличием показателей,
позволяющих измерить их значение до
выполнения проекта. Но, в отличие от
измеримых, значение показателей
количественных бизнес-выгод на момент
окончания проекта можно оценить с
высокой степенью точности. -
Финансовые:
это
тип бизнес-выгод, которые могут быть
выражены в терминах финансовых
показателей. Отнесение бизнес-выгоды
к данной категории должно производиться
только в том случае, если в распоряжении
аналитика имеется достаточно достоверная
информация о финансовой оценке
соответствующих показателей. Очевидно,
финансовые выгоды есть результат
«обогащения» количественных
бизнес-выгод финансовыми данными.
Агрегированные финансовые выгоды
проекта образуют базу для построения
финансовой модели проекта (ROI-модель)
и расчета инвестиционных показателей:
NPV, IRR, периода окупаемости.
Выбор
той или категории для конкретной
бизнес-выгоды производится на основе
доступной информации о ней до момента
реализации инвестиций. Каждая бизнес-выгода
на момент ее идентификации относится
к наименее определенной категории —
наблюдаемая. По ходу анализа необходимо
максимальное количество бизнес-выгод
перенести в финансовую категорию для
построения экономической модели
окупаемости проекта, кроме доходной
части, в которой должна быть отражена
и расходная. В качестве инструмента
оценки стоимости проекта и системы
авторы рекомендуют использовать модель
совокупной стоимости владения системы
(TCO), рассмотрение которой будет произведено
в разделе, посвященном управлению
стоимостью проекта.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Оценка помогает команде определить вектор развития проекта и вовремя его скорректировать. Однако для многих менеджеров оценка — сложный и пугающий процесс, из-за чего она часто упрощается или игнорируется вовсе.
Вместе с Андреем Кокшаровым, продюсером направления «Высшее образование» в Нетологии, разобрались, зачем проводить оценку проекта, из каких этапов она состоит и какие инструменты помогут в этом.
Статья будет полезна участникам проектных команд и начинающим предпринимателям.
Проект — это временное предприятие, которое направлено на создание уникального продукта или услуги. Проекты могут иметь различные формы и реализовываться в любой сфере и отрасли. Например, проектами можно считать:
- создание вакцины от коронавируса;
- разработку приложения по мониторингу за больными;
- проект слияния двух организаций;
- разработку нового технического устройства;
- строительство какого-либо объекта;
- разработку IT-продукта для удовлетворения неочевидной или новой для рынка потребности.
Также к проектам относят стартапы — молодые компании без опыта операционной или проектной деятельности, работающие над идеей с высокой долей риска и неопределённости.
Любой проект начинается с идеи, а заканчивается, когда:
- достигнуты цели проекта;
- становится понятно, что достичь поставленных целей невозможно;
- проект больше не актуален для заказчика или рынка.
Оценка проекта как раз помогает избежать рисков не уложиться в бюджет или сроки проекта, потерять в качестве продукта или разработать фичи, которые никому не нужны.
Расскажу, зачем командам проводить оценку проекта и какие методы при этом используют.
Оценка проекта — это способ выяснить, насколько вероятно выполнить задачу в нужные сроки, качественно и в пределах бюджета.
Оценка позволяет понять реальный статус проекта.
Она не призвана наказать отстающих, иначе участники будут приукрашать результаты или прятать неудобные данные и оценка станет необъективной и бесполезной.
Получить реальные данные для принятия решений возможно только, если оценка будет достоверной и актуальной. Чтобы в процессе оценки не возникало искажений, руководителю важно позволить участникам проектных команд высказывать опасения и предположения по ходу проекта.
Например, в некоторых компаниях используют анонимные ящики, которые устанавливают в общедоступных местах, чтобы любой участник команды мог положить туда записанные на листке бумаги сомнения и опасения. С определённой периодичностью менеджер проекта проверяет ящик и узнаёт о проблеме, о которой по какой-то причине подчинённые не говорят лично.
Оценку проекта можно разделить на оценку идеи проекта и оценку самого проекта. Данные блоки в свою очередь состоят из процессов, связанных с оценкой бюджета, сроков, качества и прочих компонентов в зависимости от уровня сложности проекта.
Оценка идеи проекта происходит на этапе, когда формируется бизнес-план и создаётся концепт продукта. Она позволяет руководителю обосновать решение о запуске проекта и его необходимости для бизнеса. В оценке идеи обычно участвуют аналитик, команда маркетинга, менеджер будущего проекта. По её результатам принимают решение об инициации проекта, подписывают устав проекта и набирают команду.
Оценка же самого проекта может происходить на всех этапах, начиная от планирования до этапа завершения. Её задача — скорректировать ход проекта. После проведения оценки проекта обычно вносят изменения в документацию, может измениться состав команды или перечень фичей продукта, либо вовсе решают закрыть проект. Если команда решила продолжать, то после этого оценивают потребности в дополнительных ресурсах.
Менеджер определяет, что важно рассмотреть в ходе оценки проекта. Он же решает, какие процессы нужно оценить и формирует список критериев для оценки каждого из них. В крупных компаниях — особенно тех, которые работают на зарубежном рынке, — инициирует оценку обычно отдельный специалист или команда специалистов отдела контроллинга, которые следят за ходом проекта. В перечень могут входить, например, такие процессы, как:
- бюджетирование — соответствует ли потенциальный доход от проекта затраченным ресурсам, нет ли несоответствий в запланированном бюджете и реальными запросами рынка;
- качество получаемого продукта — нет ли изменений в качестве продукта из-за изменений, произошедших в ходе проекта (например, не стало возможности закупить дорогие материалы), соответствует ли продукт требованиям отраслевых сертификатов (ГОСТ, ISO и тому подобные);
- потребность в материальных и нематериальных ресурсах — нет ли несоответствий с изначально запланированным качеством и количеством ресурсов с реальной ситуацией, нет ли необходимости перераспределить ресурсы или нужно поискать возможности для приобретения новых ресурсов;
- соответствие запланированным срокам — нет ли проблем с их соблюдением, не нужны ли дополнительные временные ресурсы;
- дополнительные процессы с учётом отраслевой специфики.
Состав оцениваемых процессов определяет менеджер на этапе инициации проекта. Чаще всего это называется процессом адаптации системы управления проектом к новому проекту — важно настроить его под среду и процессы внутри компании. Во время адаптации менеджер проекта тесно взаимодействует с командой проекта, с владельцем продукта и ключевыми стейкхолдерами. Адаптация помогает определить контролируемые точки в проекте, грамотно распределить ресурсы и разработать базовый план проекта.
Процесс адаптации — важный этап в работе над любым проектом, так как из-за уникальности разрабатываемого продукта каждый новый проект требует свой набор инструментов, компонентов и контрольных точек.
Менеджер проекта разрабатывает план управления выгодами проекта. И в процессе адаптации ему необходимо синхронизировать между собой основные бизнес-документы проекта — понять, нет ли расхождения между ними и бизнес-кейсом, который изначально представлялся руководству.
К основным бизнес-документам относят:
- Бизнес-кейс проекта — анализ целесообразности проекта, описания и оценки идеи, которые используются для определения и обоснования основных выгод проекта. За утверждение бизнес-кейса отвечает спонсор или руководитель продукта. Менеджер проекта выступает в роли администратора, который готовит документы и данные для бизнес-кейса.
- План управления выгодами проекта — план по определению результатов проекта, реализация которых позволяет получить запланированные выгоды. За него уже полностью отвечает менеджер проекта.
Прежде чем сформулировать бизнес-кейс, нужно провести оценку потребностей рынка. В неё будет входить первичная оценка бизнес-идеи, оценка бизнес-задач, потенциальных проблем и возможностей проекта.
Существует большое количество методов оценки проектов. Правительства разных стран используют различные методы оценки, а частные компании разрабатывают свои собственные подходы к оценке, опираясь на мировой и личный опыт.
Поэтому методы оценки проектов в равной степени подойдут как для проекта, так и для стартапа, так как по своей сути он является технологическим проектом.
Проектная работа должна основываться на запланированных сроках, придерживаться ТЗ и устава проекта, иметь системы оценки и переоценки ресурсов, сроков и прочих компонентов. Иначе такая работа превращается в неопределённый временной забег без чётких целей с почасовой оплатой.
В проекте заказчик платит за результат, а не за рабочие встречи, время технических специалистов и отговорки менеджера проекта. Заказчик не оценит 13 000 часов работы по разработке продукта, если продукт будет сырой и недееспособный. Заказчик оценит лишь качественный продукт.
Поэтому отсутствие системы оценки проекта наравне с отсутствием фиксации договорённостей по проекту и игнорированием расстановки приоритетов в задачах — одна из основных причин возникновения проблем при реализации проекта.
Система оценки проекта — совокупность процессов и инструментов, которые направлены на своевременную оценку, анализ и подготовку документации о продолжении работы над проектом или о внесении в него изменений.
По содержанию система оценки проекта относится к группе процессов мониторинга и контроля проекта и должна включать процессы, направленные на оценку важных этапов и элементов проекта.
В малых и средних проектах ответственный за систему оценки проекта — менеджер проекта, в крупных — отдел контроллинга или специалист проектного офиса и менеджер программы, в рамках которой реализуется проект.
Остановимся подробнее на методах, инструментах и содержании оценки проекта.
Наиболее распространённый инструмент оценки проекта — экспертная оценка, которую используют не только в проектном подходе.
Экспертные оценки могут быть индивидуальные и коллективные.
Индивидуальная оценка — процесс привлечения эксперта с опытом реализации аналогичных проектов. Эксперт анализирует основные точки, указывает для них допущения и риски, после чего высказывает предположение по оценке.
Коллективная оценка — собрание, симпозиум или совет, на который приглашаются участники проекта, отвечающие за разные области и процессы. Каждый участник описывает предположение по продолжительности, сложности работ по своему участку или другому оцениваемому параметру. Руководитель проекта систематизирует выводы и выстраивает общий график или систему действий по проекту.
Более точные и менее распространённые — количественные оценки, например, метод PERT.
Метод PERT (англ. Program Evaluation Review Technique) используют для оценки времени выполнения задачи по проекту. Идея оценки заключается в использовании для расчёта оптимистичного и пессимистичного сроков выполнения задачи. Наиболее точный результат можно получить, если в качестве примера взять реальные сроки по схожим задачам в предыдущих проектах. При этом даже без знания чётких сроков можно воспользоваться экспертной оценкой опытных менеджеров проектов для вычисления результата.
Формулы расчёта по методу PERT выглядят следующим образом:
О = оптимистичная оценка: минимально возможная длительность выполнения задачи, если всё идет по плану. Риски учтены и не должны возникнуть.
Р = реалистичная оценка: среднее значение для подобных задач, с учётом возникновения рисков, которые не оказывают значительного воздействия на продолжительность проекта.
П = пессимистическая оценка: закладываем вероятность возникновения средних и серьёзных рисков, при возникновении которых существует вероятность значительного переноса сроков.
Метод PERT хорошо подходит для высокоуровневой оценки проектов и оценки общих трудозатрат, но при более детальной декомпозиции работ процесс анализа может быть неоправданно трудоёмким или ошибочным. Поэтому не рекомендуется использовать данный метод при расчёте непродолжительных задач.
Для определения объёма непродолжительных задач наилучшим образом подходят методы и инструменты оценки работ, принятые в различных Agile-подходах.
- Освоите профессию проджект-менеджера в IT и digital
- Пройдёте стажировку у партнёров программы уже в первый год обучения
- Примете участие в нескольких реальных проектах, которые сможете добавить в портфолио
Существует большое количество инструментов, созданных для оценки продолжительности работ, качественных показателей и прочих важных компонентов проекта. Выделим наиболее универсальные из них, подходящие и часто используемые в описанном или модифицированном виде для оценки различных временных, качественных и прочих количественных показателей.
По опыту автора статьи, эффективную оценку проекта без серьёзных трудозатрат можно произвести при помощи последовательного использования двух инструментов, распространённых в гибких системах управления проектами. Это выстраивание порядка задач и покер планирования — рассмотрим их подробнее.
Выстраивание порядка задач (Ordering Rule)
Этот инструмент представляет собой пошаговый процесс, цель которого выстроить порядок из всех предстоящих задач.
Перед началом процесса ведущий утверждает соотношение цвета стикера с типом задачи. На стикеры выписывают все задачи и раскладывают случайным образом на столе.
Далее каждый участник процесса оценки совершает одно из двух действий: берёт карточку и размещает её на шкале или перемещает на соседнее поле уже прикреплённую карточку, комментируя и обсуждая с участниками своё решение. При необходимости на доску можно добавить отдельное окно, где будут размещены задачи, которые имеют неопределённый размер.
Данный процесс позволяет определить объём задач проекта.
Такой инструмент эффективен при работе с 10–20 задачами. Если требуется обсуждение большего количества задач, лучше разделить процесс на несколько сеансов или воспользоваться схожим инструментом.
Покер планирования (Planning Poker)
Покер планирования — одна из самых популярных техник оценки в проектном менеджменте. Для процесса используют специальную колоду карт, которая пронумерована в соответствии с последовательностью Фибоначчи, чтобы участник голосования с их помощью мог голосовать за задачу. Кроме карт с числами в колоде также присутствуют карта вопроса и карта с чашкой кофе.
Игрок использует карту вопроса, если считает, что задачу надо уточнить или обсудить, а чашку кофе — при необходимости сделать перерыв.
Каждый участник получает набор карт с числовыми значениями и с изображениями чашки и вопроса, а ведущий анонсирует задачу или пользовательскую историю и отвечает на вопросы.
Затем участники выбирают карту с подходящей, по его мнению, оценкой и кладёт карту рубашкой вверх. Это необходимо для того, чтобы выбор участников, которые проголосовали первыми, не повлиял на решение других.
После того как каждый член команды определился с выбором, карты одновременно переворачивают. Участники с самыми высокими и самыми низкими оценками дают краткие комментарии, объясняя свой выбор оценки.
В итоге обсуждения команда приходит к единому решению и переходит к следующей задаче.
Покер планирования — одна из наиболее точных техник оценки, но среди основных минусов выделяют продолжительность процесса оценки. В течение часовой сессии сложно произвести оценку более чем десяти задач.
Вдохновившись идеей или продуктом, мы погружаемся в информационный пузырь и можем не заметить очевидные для рынка и скрытые для нас недостатки разрабатываемого нами продукта или услуги. Поэтому объективная оценка на всех этапах проекта — важный процесс, направленный на достижение успеха проектной деятельности.
Рассмотрим основные шаги оценки проекта.
Оценку потребностей проводят перед описанием бизнес-идеи — она необходима для принятия решения о запуске проекта. Именно на оценке потребностей рынка и целевой аудитории, анализе ситуации должно основываться решение о старте проработки бизнес-идеи и подготовке устава проекта или подобного документа, подписание и утверждение которого служат формальным подтверждением начала проекта.
В результате оценки потребностей формируется понимание и видение бизнес-цели и бизнес-задач, а также возможных проблем, важных допущений и рисков. Также оценка потребностей помогает сформировать первичное понимание того, каких показателей и в течение какого срока должен добиться проект, с учётом возможных рисков и описанных в рамках оценки допущений.
Оценка бизнес-идеи — творческий процесс, который зависит от отрасли и специфики проекта. Для каждой отрасли процесс оценки бизнес-идеи будет отличаться, но есть универсальные рекомендации:
- описывайте идеи проекта в удобном формате — чтобы каждый участник проекта понял содержание проекта и мог интерпретировать данные;
- внедряйте проработку идей, их анализ и обсуждение в общий процесс работы отдела или организации — чтобы избежать однобокости и ограниченности информации;
- правильно презентуйте идею проекта — участники могут не понять идею, если она будет оформлена неправильно. К тому же, не нужно пренебрегать стилистикой компании.
План управления проектом — это живая сущность, требующая постоянного внимания. Практически невозможно распланировать проект на этапе инициации так, чтобы после старта не пришлось пересматривать сроки, стоимость, менять содержание или очерёдность задач. Поэтому оценка плана управления проектом, его актуализация и пересмотр — нормальная практика для любого проекта.
В случае реализации непродолжительного проекта (3–9 месяцев) рекомендуем производить оценку и обновление плана каждые 2–3 недели.
Если длительность проекта составляет от 9 месяцев до нескольких лет, лучше переоценивать план и актуализировать его не реже одного раза в месяц.
MVP — минимально жизнеспособный продукт. Это прототип продукта проекта, который можно представить инвестору или потенциальным пользователям в качестве демообразца для сбора обратной связи и последующей доработки продукта до полностью рабочего состояния.
Оценка MVP может строиться на следующих инструментах:
- опрос клиентов;
- запуск тестовых посадочных страниц;
- тестовые рекламные кампании и фандрайзинг;
- продажа MVP клиенту с условием сбора обратной связи и последующей заменой на полноценный продукт;
- оформление предзаказа.
После сбора информации об MVP с помощью предложенных или других инструментов команда проекта должна проанализировать полученные данные и доработать продукт до финального состояния.
Нельзя считать выпуск MVP и сбор предзаказов по продукту успехом и завершающим этапом проекта. После выпуска MVP его доработка обязательно должна продолжиться — одним из основных приоритетов любого проекта должна быть нацеленность на разработку качественного продукта для его пользователей.
Представляет собой глубокий анализ собранных данных и результата деятельности проекта в целом.
Для финальной оценки необходимо:
- проанализировать и соотнести запланированные и реальные показатели по проекту;
- выявить лучшие практики и оформить их в удобный для последующего использования вид;
- собрать обратную связь от участников проектных команд для улучшения рабочих процессов;
- проанализировать результат проекта для выявления возможностей его дальнейшего развития и поддержки;
- для крупных проектов, в рамках которых происходит выпуск сложной продукции, на данном этапе может быть инициирован проект по разработке способов утилизации выпущенной продукции.
Вне зависимости от сложности проекта, его продолжительности и предполагаемого результата проектной команде и менеджеру проекта важно придерживаться систем оценок проекта, работать над его развитием и прислушиваться ко мнению будущих пользователей результата проекта. Следование описанным в статье рекомендациям поможет снизить риски проекта и минимизировать ошибки в самом проекте, снизить количество ошибок и при его оценке.
Главная причина неудачи в оценке проекта — недосказанность или недопонимание между заказчиком и исполнителем. Необходимо вести прозрачный диалог с заказчиком, если в проекте появились изменения. В противном случае могут быть проблемы.
Избежать ошибок в проекте невозможно, но важно своевременно проводить оценку или переоценку проекта, чтобы обладать актуальной информацией для корректировки хода проекта и минимизации негативных рисков. Тем не менее ошибки в проекте не должны пугать или отталкивать от работы и процесса оценки.
Поэтому ответ на вопрос «как не ошибиться», будет звучать парадоксально: практикуйтесь! Оценивайте, ошибайтесь, нарабатывайте опыт и экспертность. Со временем вы будете сталкиваться со всё меньшим количеством ошибок в оценке проекта, а вызванные вашими ошибками риски будут выглядеть менее критично.
Удачи в проектах!
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
| Описание причины: | |||||||
| Действия | Базовый | Модифицированный | Характеристики модифицированного этапа/процесса | ||||
| Этап | Процесс | Этап | Процесс | Назначение | Цель | Результат | |
| Дата подачи заявки (руководитель проекта): | |||||||
| Дата принятия решения (проектный офис): | |||||||
| Дата начала применения: |
Разработка технико-экономического обоснования
Традиционно основной целью подготовки технико-экономического обоснования (ТЭО) ИТ-проекта является получение финансирования на реализацию соответствующей инициативы. Кроме того, корректно составленное ТЭО может решать следующие задачи:
- приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;
- определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта;
- обеспечение заинтересованности руководителей бизнес-подразделений в проекте;
- формирование основы для оценки соответствия результатов проекта и первоначальных планов.
Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время все лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности проекта [7].
Помимо обозначенных задач ТЭО может обеспечивать входную информацию в устав проекта, рассматриваемый нами как ключевой документ интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную входную информацию, рекомендуется следующим образом структурировать информацию о бизнес-выгодах ИТ-проекта (см. Таблица 4.).
В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности идентифицированных бизнес-выгод. Таким образом, каждая выгода по проекту размещается «на пересечении» соответствующих значений этих двух факторов.
Использование матрицы структурирования выгод начинается с определения характера воздействия на бизнес каждой бизнес-выгоды. Определены три типа воздействия.
- Создание новых возможностей: функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
- Повышение эффективности операций: функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
- Отказ от операций: информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
Таблица 4.
Матрица структурирования выгод ИТ-проекта
-
Характер воздействия на бизнес Создание новых возможностей Повышение эффективности операций Отказ от операций Степень определенности Финансовые Количественные Измеримые Качественные
После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые, измеримые, количественные, финансовые.
- Качественные: выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для «переноса» качественных выгод в более объективные категории.
- Измеримые: выгоды данного типа поддаются измерению. В расположении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
- Количественные: аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
- Финансовые: это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат «обогащения» количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.
Выбор той или категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории – наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы (TCO), рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта.
Дмитрий Рябых, генеральный директор компании «Альт-Инвест»
При проведении оценки инвестиционного проекта эксперту приходится решать ряд вопросов, которые могут быть сведены к следующему базовому перечню:
- Можем ли мы реализовать такой проект? Соответствуют ли правовые, организационные и технологические аспекты нашего проекта требованиям, которые вероятнее всего предъявит нам жизнь?
- Обеспечен ли проект финансированием в достаточном объеме и достаточно ли мы защищены от финансовых рисков?
- Является ли этот проект эффективным, достаточно ли привлекательна для нас прибыль от его реализации?
- Приемлемы ли риски?
Пропустив задачи других направлений анализа, рассмотрим подход, который применяется при анализе того, является ли инвестиционный проект достаточно прибыльным для инвестора. Традиционно, для такой оценки проекта применяется анализ дисконтированных денежных потоков проекта, на основе которых рассчитывается группа стандартных показателей. Как будет показано ниже, существует целый ряд случаев, охватывающих значительную долю проектов, когда применять эти показатели в чистом виде не удобно, зато на помощь приходят методики и подходы из другой сферы — оценки бизнеса.
Классический подход
Для оценки эффективности инвестиционных затрат проекта традиционно используют следующие показатели:
- дисконтированный срок окупаемости (Pay-Back Period, PBP);
- чистая текущая стоимость (Net Present Value, NPV);
- внутренняя норма рентабельности (Internal Rate of Return, IRR).
Именно этот набор показателей приводится в резюме бизнес-плана инвестиционного проекта и используется заинтересованными сторонами для оценки коммерческой привлекательности инвестиционной идеи. Базой для расчета показателей эффективности являются так называемые чистые денежные потоки (Net Cash-Flow, NCF), включающие в себя выручку от реализации, текущие и инвестиционные затраты, прирост потребности в оборотном капитале и налоговые платежи. Название «чистые потоки» говорит о том, что потоки не учитывают схему финансирования — вложение собственных средств и привлечение кредитных ресурсов. Без этого вложения денежный поток проекта будет, естественно получаться отрицательным на начальном этапе и накопленные денежные средства будут выглядеть так, как это показано на рисунке.
На этом графике инвестора интересует несколько значений. Во-первых, это срок окупаемости проекта. Такой срок определяется по времени, требующемуся для того, чтобы суммарные чистые доходы проекта сравнялись с его затратами. На графике это точка, в которой NCF нарастающим итогом выйдет на положительные значения. В нашем примере — в 2012 году. Но ни один инвестор не согласится расстаться с сегодняшними деньгами в пользу будущих, достаточно отдаленных доходов, если эти доходы будут лишь покрывать инвестиции. Поэтому в оценке эффективности проекта всегда используются дисконтированные денежные потоки, в которых NCF каждого года уменьшается на величину ставки дисконтирования по формуле
где i — номер года проекта, а d — ставка дисконтирования. То есть, будущие денежные потоки «обесцениваются» для инвестора с годовыми темпами, равными ставке дисконтирования.
В результате, для нашего случая окупаемость проекта смещается на 2014 год.
Принцип расчета PBP всегда сводится к построению графика и нахождении точки, в которой накопленный дисконтированный NCF выходит на положительные значения.
Другой важный показатель проекта, NPV, хотя и виден очень хорошо на графике денежных потоков, обычно рассчитывается по формуле. Суть NPV — чистый доход, который принесет проект с учетом дисконтирования. На графике это то значение, которой принимает накопленный дисконтированный NCF проекта к моменту окончания расчетов (в примере — около 500). Формула же NPV выглядит так:
где NCFi — чистый денежный поток i-го года, а N — общее число лет.
Если в отношении срока окупаемости единых критериев приемлемости не существует, то анализ проекта по уровню NPV выглядит существенно проще. Любое положительное значение NPV считается показателем хорошей эффективности проекта. При этом конкретная величина NPV указывает не на прибыль инвестора (хотя название показателя и переводят иногда как «чистый приведенный доход»), а на «сверхприбыль», т.е. на тот дополнительный доход, который будет получен инвестором сверх ожидаемого.
Расчета NPV, как правило, достаточно для принятия решений по проекту. Но его значение выглядит не очень показательным, из него может быть понятно, что проект выгоден и привлекателен, но трудно оценить — насколько привлекателен. Поэтому в помощь NPV применяют третий стандартный показатель — внутренняя норма рентабельности.
Внутренняя норма рентабельности проекта (IRR) — это такое значение ставки дисконтирования d, при котором NPV становится равным 0. То есть IRR показывает какое максимальное требование к годовому доходу на вложенные деньги инвестор может закладывать в свои расчеты так, чтобы проект еще выглядел привлекательным. Например, если для финансирования проекта используются деньги банка, то IRR продемонстрирует максимальную величину процентной ставки по кредиту, которую теоретически способен окупить проект.
Рассчитать значение IRR по формуле невозможно, этот показатель всегда находится подбором. Например, для отображенного выше денежного потока значение чистого дохода без учета дисконтирования составило 3300, а по мере увеличения ставки будущие доходы все меньше перекрывали начальные инвестиции и, как показано ниже, при ставке 20% величина NPV стала равна нулю. Это и есть значение IRR данного проекта.
Итак, с точки зрения классических представлений об оценке инвестиционных проектов, необходимо рассчитать три показателя: NPV, PBP и IRR. При этом инвестора должны устроить значения окупаемости проекта и IRR, а величина NPV должна быть больше нуля.
Ставка дисконтирования
В основе всех описанных расчетов лежало дисконтирование прогнозируемых денежных потоков. Для того, чтобы провести его, необходимо выбрать ставку дисконтирования. Смысл ставки дисконтирования — отражение в расчетах влияния стоимости денег. Иногда уже этого определения бывает достаточно для того, чтобы принять решение о ее величине. Например, если проект будет финансироваться полностью за счет средств банковского кредита, то ставка дисконтирования равна процентной ставке по кредиту.
В более сложном случае, когда инвестируемый капитал взят из разных источников, расчет ставки дисконтирования усложняется, но незначительно. Теперь, вместо процентов по кредитам, в расчете используется понятие средневзвешенной стоимости капитала (Weighted Average Cost of Capital, WACC). Этот показатель рассчитывается так:
где:
kкр — доля кредитных средств в источниках финансирования,
kск — доля собственных средств акционера,
rкр — ставка процентов по кредиту,
rкр — доход на собственный капитал, требуемый акционером.
Получается, что каждая компонента капитала закладывает в стоимость денег проекта долю, пропорциональную доле самого источника капитала.
Фактически, через этот механизм расчета ставки дисконтирования учитывается требование каждого из инвесторов проекта к своим доходам на вложенные средства. Любопытно, что понятие WACC пришло в оценку инвестиционных проектов с фондового рынка, где оно активно применяется при анализе стоимости акций компаний.
Здесь мы впервые встречаемся с применением элементов, которые чаще встречаются в оценке бизнеса, для расчета эффективности инвестиционных проектов. Дальше мы увидим насколько тесно переплетены эти темы.
Главное — NPV. Но этого недостаточно
Главным критерием эффективности инвестиционного проекта всегда считалась величина NPV. Это объясняется и тем, что его просто интерпретировать, и тем, что расчет NPV вызывает меньше всего сложностей по сравнению с другими традиционными показателями проекта. Но на практике часто оказывается, что рассчитать NPV не всегда будет легким делом, а правильно сделать выводы, получив его значение, еще сложней. Назовем основную причину затруднений. Для этого рассмотрим в качестве примера небольшой проект.
Небольшое предприятие планирует закупить оборудование для производства автомобильных деталей. В течение 6 месяцев длится инвестиционная фаза проекта, после чего за 1,5 года компания планирует выйти на плановые объемы производства и начать регулярную деятельность.
В ходе анализа проекта не только решается вопрос о его привлекательности, но и оцениваются перспективы с точки зрения потенциального партнера, готового профинансировать часть затрат в обмен на долю в бизнесе.
В этом проекте надо обратить внимание на две характерных детали. Во-первых, покупаемое оборудование может работать достаточно долго, 7-15 лет. Но всерьез строить прогнозы доходов и затрат небольшого предприятия до 2022 года очевидно нельзя. Значит взятые нами сроки для прогнозирования доходов окажутся меньше, чем реальный срок полезного использования результатов проекта. Во-вторых, среди инвесторов есть потенциальный новый акционер. Значит по результатам анализа будут приниматься решения о доле бизнеса и выгоде каждого участника. Было бы гораздо проще, если бы бизнес уже существовал и был оценен, тогда можно сопоставить сумму, выплачиваемую акционером и долю в компании с известной стоимостью, которую получает новый участник, т.е. рассматривать инвестиции как покупку «товара» с известной рыночной стоимостью. Если заплатить надо не больше реальной цены, то сделка выгодна, в противном случае от нее лучше отказаться. Но мы пока оперируем другими показателями.
Итак, практически в любом реальном проекте мы сталкиваемся с двумя недостатками NPV:
1. Строить детальные прогнозы на весь период, в течение которого работают сделанные инвестиции, не всегда оправдано. В результате, в каждом проекте остается значительный фрагмент неучтенных доходов. Особенно хорошо это видно в тех ситуациях, когда теоретически созданный бизнес или направление может работать бесконечно.
2. NPV не дает окончательного вывода о том, насколько выгодно акционерам участвовать в проекте и какие доли в бизнесе являются для них минимальными.
В большой степени эти проблемы решаются, если перейти от традиционных показателей эффективности к одному из методов, используемых при оценке стоимости компаний.
Модель Гордона
Как известно, стоимость компании можно определять либо изучая ее активы, либо сравнивая ее с другими похожими компаниями, либо прямо анализируя ее доходы. И последний подход будет интересен нам как альтернатива NPV проекта. Для того, чтобы понять механизмы оценки компании на основе доходов надо представить себе, что запущенный нами инвестиционный проект длится вечно, не имеет ограничений по срокам. Хотя и кажется, что ценность бесконечного дохода тоже может оказаться бесконечной, в действительности это не так. Формула NPV при бесконечном горизонте прогноза принимает следующий вид:
Расчет оказался не только возможен, но и значительно упростился! Однако мы здесь внесли одно упрощение, предположили, что NCF проекта будет неизменным год от года. Но в действительности он будет постоянно меняться, как минимум, за счет инфляции, а иногда и быстрее, за счет постепенного расширения масштабов деятельности. Поэтому такое упрощение будет чрезмерным и потребуется добавить учет ежегодного роста доходов. А наша формула примет вид:
где g — годовой темп роста доходов компании.
И, наконец, последняя поправка. Как можно легко убедиться, чистый денежный поток проекта NCF равен посленалоговой операционной прибыли плюс амортизация. Амортизация не считается затратами в инвестиционных проектах, так как она не связана напрямую с денежными затратами, а отражает начисление износа имущества. В коротких инвестиционных проектах это было верно, но если прогнозировать развитие деятельности компании на бесконечный срок, то было бы правильно, пусть и не с первого года, учитывать регулярные вложения денег в постепенную замену и поддержание оборудования. А это значит, что сумму, близкую к величине амортизации надо бы учесть как затраты проекта.
Если мы сделаем это, то интерпретация формулы изменится. Значение в числителе можно будет назвать другим термином — посленалоговая операционная прибыль, NOPLAT. А получившаяся формула,
станет ни чем иным, как формулой Гордона, одной из наиболее известных формул, по которым оценивается стоимость компаний и коммерческой недвижимости.
Итак, оказалось, что распространенные методики оценки бизнеса тесно связаны с понятием NPV.
Продленная стоимость
Теперь остается сделать последний шаг. NPV неудобен, потому что этот показатель требует полного прогноза денежных потоков, в том числе и там, где мы такого прогноза сделать не можем. Но и модель Гордона, хорошо отражающая стоимость будущих доходов, не идеальна. Она работает при одном важном условии — денежные потоки проекта стабильны или равномерно растут. Это верно для стадии зрелого развития но совершенно не соответствует тому, что происходит на начальной фазе.
Вернемся к упомянутому ранее примеру. Первые два года проект развивается очень динамично. Меняются обороты и чистые доходы. Но с третьего или четвертого года ситуация меняется. Денежные потоки стабилизируются, т.к. компания вышла на полную загрузку мощностей. Но прогнозировать их детали становится все сложнее и хотелось бы оперировать примерными оценками. И здесь нам на помощь приходит понятие продленной стоимости. Вот как оно будет использовано в нашем примере:
1. На первые 3 года проекта (инвестиционный период + выход на полную загрузку + 1 год стабильной деятельности) будет построен детальный прогноз денежных потоков проекта. На основании этого прогноза рассчитывается NPV.
2. По последнего году проекта определяется величина NOPLAT. Фактически, это его чистая прибыль без вычета процентов по кредиту (проценты по кредиту, как и другие затраты на оплату капитала, мы учли в ставке дисконтирования). На основе NOPLAT и стоимости капитала, определенной инвесторами, рассчитывается стоимость бизнеса по модели Гордона. В нашем случае она будет называться продленной стоимостью, т.е. стоимостью, создаваемой за пределами прогнозного периода.
3. Полная стоимость проекта рассчитывается по формуле:
то есть продленную стоимость проекта мы продисконтировали за три года прогнозного периода и прибавили к NPV. Тем самым, мы предположили, что на последний день расчетного периода мы продали созданный бизнес по рыночной цене, рассчитанной исходя из его способности приносить доходы владельцу и требования инвесторов к годовой доходности (она учтена у нас в ставке d)
Теперь наш анализ приобрел должный баланс между детальностью и способностью заглядывать в будущее, а вместо показателя NPV мы получили оценку каждого проекта как бизнеса с определенной рыночной стоимостью. Принимать решения о долях участников и максимальной сумме вложений стало проще, а в проекте не осталось таких выгод и доходов, которые остались бы за рамками оценки.
Оценка проекта — всегда оценка части бизнеса
Приведенный пример использования понятия продленной стоимости при оценке проектов — только частный случай оценки проекта как бизнеса. Вообще же, любой инвестиционный проект может рассматриваться как с позиций «внутреннего» анализа ожидаемых доходов, так и более обобщенно, на базе методологии оценки бизнеса. Более того, нормальный план оценки коммерческой эффективности проекта можно представить так:
При анализе любого инвестиционного проекта желательно использовать для проверки сделанных прогнозов информацию об аналогичных проектах и компаниях. Если цель анализа — привлечение банковского кредита, то на этом работа эксперта и заканчивается. Но если проект должен быть представлен потенциальным или текущим акционерам, то обязательное продолжение традиционных расчетов это оценка создаваемого бизнеса как с помощью спрогнозированных денежных потоков (на основе продленной стоимости), так и на основе рыночных аналогов. И чем ближе будут друг к другу перечни аналогов, применяемых на этапе прогнозирования доходов и на этапе оценки бизнеса, тем выше будет качестве расчетов.
* На сайте текст статьи дан в предпечатном варианте.
1 При практическом применении эта формула может усложняться, учитывая детали источников финансирования и налогообложения, но смысл остается неизменным
