Внешняя стоимость ошибок

Подождите!

Ответ нейросети:

⚠️Зарепортить пост!

Цена ошибки: как экономия приводит к повышенным тратам

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

Экономия затрагивает самые разные сферы проекта и специалистов. В этой статье рассмотрим обеспечение качества (QA). Бизнес нередко считает, что тестирование – та часть проекта, на которой можно сэкономить, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать. Наш коллега Андрей на конкретных примерах покажет, к каким последствиям приводят наиболее популярные случаи экономии на QA.

Вариант 1. Отсутствие тестирования на ранних этапах

Начнем с классического случая экономии на проекте – отсутствия тестирования на ранних этапах жизненного цикла ПО.  

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

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

1. Идея

2. Написание технического задания (далее – ТЗ)

3. Реализация

4. Тестирование

5. Выход в релиз

Обратите внимание, что на этой схеме QA подключаются довольно поздно – на этапе тестирования. Используя этот алгоритм, легко вычислить, что: 

• Если в фиче нет дефектов, то каждый участник жизненного цикла затрачивает свое время 1 раз, таким образом разработка стоит 5 условных часов.

• Если баг допущен на этапе реализации и найден на этапе тестирования, то разработчик и QA затрачивают по одной дополнительной единице времени: на фикс бага и на повторное тестирование (ретест) исправленной фичи, соответственно. В итоге получается: 5+2=7 единиц времени. У вас может возникнуть вопрос, почему мы считаем 5 часов, а не 4, если после тестирования фича не пошла в релиз? Потому что после исправлений и повторного тестирования все равно наступает релиз.

• Если баг допущен на этапе написания ТЗ и найден на этапе тестирования, то единиц времени будет 8 (5+3 на: исправление ТЗ, фикс бага , ретест)

• Если баг допущен в самой идее фичи и выявлен на этапе тестирования, то будет затрачено 9 единиц времени (5+4 на: коррекцию идеи, исправление ТЗ, фикс бага, ретест исправлений)

 Теперь давайте представим, что QA подключается на более раннем этапе – между написанием ТЗ и разработкой – и тестирует требования. В этом случае баги можно будет выявить раньше и сэкономить время.

Тестирование постановок (ТЗ) – одно из популярных решений тренда на раннее тестирование или, как это называют некоторые компании,  «shift left».

В третьем и четвертом случаях это будет 1 и 2 единицы времени соответственно. Однако можно заметить, что в первом и втором случаях происходит увеличение затрачиваемого времени на 1 единицу. Где же выгода? Добавим в теоретическую модель данные о статистике возникновения дефектов и реально затрачиваемом времени на тестирование требований и исправления постановок и кода.

 Начнем с возникновения дефектов. Мы собрали статистику со 117 проектов в различных сферах и анализ показал, что 66 % багов возникают на этапе реализации (написания кода), 31% — на этапе постановки задачи и 3% дефектов содержатся в идеях фич.

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

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

Переходим ко времени, которое затрачивается на тестирование требований.

Практика показывает, что тестирование требований на одну фичу (именно требований, а не фич) в среднем занимает от 25 минут до 6 часов. Значения более 2,5 часов встречаются крайне редко, а 4 и более часа ревью свидетельствуют о том, что фича перегружена требованиями и ей требуется декомпозиция.

Теперь рассмотрим время, затрачиваемое на корректировку ТЗ.

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

И наконец, изучим распределение времени, которое тратится на исправление кода.

На фиксы дефектов в коде уходит от 20 минут до 8 часов, в зависимости от сложности багов и если при исправлении не возникает критических противоречий с существующим кодом, стенды работоспособны, а ТЗ достаточное для работы. 

Анализ диаграмм позволяет сделать несколько выводов:

• Весомая доля (около 31%) дефектов зарождается на этапе создания ТЗ

• Типичное время тестирования ТЗ меньше, чем типичное время исправления кода (багофикса)

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

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

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

Например, на тестирование требований не обязательно подключаться всем QA команды. Это могут делать отдельные сотрудники. Кроме того, в результате проверки требований часто происходят мелкие правки ТЗ, которые делают его более понятным и однозначным, что в итоге сокращает время, которое  уходит на вопросы и пояснения при разработке. 

Вариант 2. Тестирование силами разработчика

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

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

Наши QA-специалисты нередко подключаются на проекты, где не было тестирования как процесса,  выполняемого отдельными людьми. Приемочный аудит таких проектов показывает, что отношение количества багов критичности major и выше к общему количеству фичей составляет 26,4 % 

После подключения профессиональных QA этот процент сокращается до 1,3 %. Небольшой процент сохраняется, так как в выборке присутствуют проекты, где допустимо выкатывать релизы с определенным количеством major багов.

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

Вариант 3. Отказ от регресса

Регрессионное тестирование (далее – регресс) – проверка ранее протестированного ПО или его отдельных компонентов, которая позволяет удостовериться, что последние внесенные изменения не повлекли за собой появления дефектов в неизмененной части программы.

Важная особенность регресса – в его регулярности. При этом может возникнуть вопрос: зачем тестировать то, что уже протестировано? Это непонимание впоследствии перерождается в отказ от проведения регрессионного тестирования.

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

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

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

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

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

Для исследования мы выбрали 46 проектов, каждый из которых был выпущен в релиз и просуществовал не менее полугода.

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

Анализ частоты возникновения регрессионных дефектов позволяет выделить два факта:

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

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

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

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

– крупные, которые будут проводится после изменений в ключевых компонентах;

– средние – в зависимости от серьезности внесенных изменений;

– мелкие, прогоняемые после каждого изменения в ПО.

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

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

Вариант 4. Отказ от тестовой документации

Тестовая документация – совокупность документов, которые создаются перед началом тестирования, а в некоторых случаях и в процессе. Она описывает покрытие требований тестами, а также процесс выполнения проверки ПО. В документации указывается вся информация, необходимая для тестирования. С точки зрения процессов она используется для структурирования работы QA.

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

Разумеется, создание тестовой документации требует времени, на котором часто экономят. Бытует мнение, что тестовая документация – это неоправданная трата времени и можно тестировать ПО без нее. Такое суждение складывается из-за непонимания последствий её отсутствия и неумения применять оптимальные виды документации в зависимости от особенностей проекта.

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

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

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

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

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

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

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

Вместо вывода

1. Контроль реализации проекта

1
Старший преподаватель кафедры МЭП
К.э.н. Булатенко Мария Андреевна

2. Оценка стоимости проекта

2
Оценка стоимости
проекта
В ходе процесса «Оценка стоимости» определяются стоимостные
оценки
для
ресурсов
(человеческих
и
материальных),
необходимых для каждой операции.

3. Выбор альтернатив

производит
ь
покупать
покупать
арендовать
3

4. Производить или покупать?

Это решение экономической целесообразности покупки необходимых
для проекта продукта или услуги либо их создания внутри организации.
Стоимость должна включать как прямые затраты (фактические затраты
на покупку товаров и услуг), так и косвенные, например зарплату
менеджеру, ответственному за процессы поставки, или затраты на
текущее обслуживание.
Другие вопросы: производственные мощности, навыки, доступность и
коммерческая тайна. Для определенных процессов может потребоваться
строгий контроль, поэтому они не могут быть отданы на аутсорсинг.
Решение «производить или покупать» — это документ, отражающий:
какие товары и услуги будут производиться внутри организации, а какие
будут покупаться на стороне (услуги, продукцию, страховые полисы и
пр.)
4

5. Входы процесса «Оценка стоимости»

базовый план по содержанию;
расписание проекта;
план обеспечения проекта персоналом;
реестр рисков;
факторы внешней среды предприятия;
активы организационного процесса.
5

6. Базовый план по содержанию

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

7. План обеспечения проекта персоналом

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

8. Факторы внешней среды предприятия

Рыночные условия определяют доступность материалов, продукции
и услуг на рынке и условия поставки этих ресурсов.
Открытая
коммерческая информация может содержать расценки
ресурсов. Эту информацию можно получить из коммерческих баз
данных или прейскурантов цен продавцов.
Необходимо
рассмотреть имеющийся персонал и его доступность.
Рыночные условия определяют доступность ресурсов, которые
можно нанять вне организации, и их текущие ставки.
Активы организационного процесса
В определении оценок текущего проекта могут быть весьма
полезными усвоенные уроки и историческая информация из
предыдущих проектов.
8

9. Общая стоимость проекта

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

10. Инструменты и методы оценки стоимости проекта

экспертная оценка;
оценка по аналогам;
параметрическая оценка;
оценка «снизу вверх»;
оценка по трем точкам;
анализ резервов;
стоимость качества;
ПО для управления проектом, используемое для оценок;
анализ предложений поставщиков.
10

11. Инструменты и методы оценки стоимости проекта

экспертная оценка;
оценка по аналогам;
параметрическая оценка;
оценка «снизу вверх»;
оценка по трем точкам;
анализ резервов;
стоимость качества;
ПО для управления проектом, используемое для оценок;
анализ предложений поставщиков.
11

12. Экспертная оценка

Сотрудники, выполняющие операции, смогут провести их наиболее точную
оценку.
Используется экспертная оценка, основанная на предыдущем опыте.
Необходимо рассмотреть квалификацию ресурсов, их производительность,
риски и другие факторы, которые могут повлиять на оценки.
Сочетание экспертной оценки с исторической информацией и привлечение
максимально
практикой.
возможного
количества
экспертов
являются
хорошей
Оценка по аналогам
Оценка «сверху вниз» (форма экспертной оценки)
Метод
предполагает определение стоимости текущей операции на основе
длительности похожей операции, выполненной в предыдущем проекте.
Этот метод особенно полезен в случае отсутствия детальной информации о
проекте, например на ранних стадиях проекта или для определения общей
стоимости проекта без детализации на работы проекты.
12

13. Инструменты и методы оценки стоимости проекта

экспертная оценка;
оценка по аналогам;
параметрическая оценка;
оценка «снизу вверх»;
оценка по трем точкам;
анализ резервов;
стоимость качества;
ПО для управления проектом, используемое для оценок;
анализ предложений поставщиков.
13

14. Параметрическая оценка

Параметрическая оценка — это количественный метод, при котором количественная
характеристика работы умножается на единичный параметр.
Стандартными путями выделения элементов являются:
переменные расходы — стоимость материалов, задействованных в выполнении
операции; стоимость трудовых ресурсов (стоимость единицы времени работы),
задействованных в каждой операции. Следует учитывать, что стоимость ресурсов на
разных стадиях выполнения операций может меняться;
постоянные расходы — стоимость самой операции и управленческих воздействий по
назначению на нее ресурсов.
Оценка «снизу вверх»
Оценка ≪снизу вверх≫ предполагает суммирование отдельных операций или пакетов работ
снизу вверх по уровням WBS проекта и агрегирование, таким образом, стоимости всего
проекта.
Оценки выражаются количественно — обычно в денежных единицах, отражающих стоимость
ресурсов (человеческие ресурсы, материал, оборудование, ИТ-решения и т. д., включая
резервы на непредвиденные обстоятельств), необходимых для выполнения операций проекта.
14

15. Инструменты и методы оценки стоимости проекта

экспертная оценка;
оценка по аналогам;
параметрическая оценка;
оценка «снизу вверх»;
оценка по трем точкам;
анализ резервов;
стоимость качества;
ПО для управления проектом, используемое для оценок;
анализ предложений поставщиков.
15

16. Стоимость качества

Стоимость качества — это суммарные расходы на производство продукта или
услуги проекта в соответствии со стандартами качества. Эти расходы включают
в себя стоимость всех работ (плановых и внеплановых), направленных на
соблюдение требований к продукту.
Они также включают в себя стоимость работ, выполненных из-за несоответствия
требованиям качества, стоимость оценки степени соответствия продукта или
услуги требованиям и стоимость переделок.
Существуют две категории стоимости качества: стоимость соответствия и
стоимость несоответствия. Стоимость соответствия связана с действиями,
направленными на избежание ошибок, в то время как стоимость несоответствия
связана с действиями по устранению сделанных ошибок.
Стоимость соответствия
Стоимость несоответствия
Стоимость предотвращения
Внутренняя стоимость ошибок
Стоимость оценки
Внешняя стоимость ошибок
16

17. Стоимость качества

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

18. Инструменты и методы оценки стоимости проекта

экспертная оценка;
оценка по аналогам;
параметрическая оценка;
оценка «снизу вверх»;
оценка по трем точкам;
анализ резервов;
стоимость качества;
ПО для управления проектом, используемое для оценок;
анализ предложений поставщиков.
18

19. Бюджетирование и базовый план по стоимости

19
Бюджетирование
и базовый план
по стоимости

20. Планирование затрат по проекту (бюджетирование)

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

21. Базовый план по стоимости

Распределенный во времени бюджет, называемый также базовым планом по
стоимости, служит для измерения, мониторинга и контроля исполнения
проекта по стоимости. Он разрабатывается суммированием оценок стоимостей
по этапам проекта. Обычно базовый план напоминает по форме латинскую
букву S и часто называется S-кривой.
Базовый план по стоимости
служит основой для разработки
требований к финансированию
проекта.
Финансирование
проекта
осуществляется
поэтапно.
Требования к финансированию
на отдельных этапах могут
превышать базовый план на
величину резерва управления.
21

22. Сбор требований к финансированию проекта

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

23. Задачи финансирования проекта

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

24. Этапы финансирования проекта

24

25. 1. Анализ жизнеспособности проекта

Позволяет определить, стоит ли проект дальнейших затрат времени и
средств, и будет ли потока наличности достаточно для покрытия всех
издержек и получения средней прибыли.
Жизнеспособность проекта характеризуется:
возможностью обеспечить требуемую динамику инвестиций;
способностью проекта генерировать потоки доходов, достаточные для
компенсации его инвесторам вложенных ими ресурсов и взятого на себя
риска.
Анализ жизнеспособности проекта состоит из двух подэтапов:
1)
из альтернативных
жизнеспособный;
вариантов
проекта
выбирается
наиболее
2)
для
выбранного
варианта
проекта
подбираются
методы
финансирования и структура инвестиций, обеспечивающие максимальную
25

26. 2. Этап планирования реализации проекта

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

27. 3. Этап организации финансирования

Выбор источников финансирования проекта зависит от таких факторов, как
масштаб проекта, финансовое состояние предприятия, уровень развития
финансовых рынков, макроэкономические показатели, уровень риска
проекта и др.
Небольшие проекты финансируются, как правило, за счет внутренних
источников (нераспределенная прибыль предприятия), крупные же
проекты требуют привлечения внешних источников:
— финансирование за счет выпуска акций;
— долгосрочное долговое финансирование;
— правительственная помощь;
— проектное финансирование;
— лизинговое финансирование и др.
27

28. Прочие финансовые вопросы

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

29. Ревизия

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

30. Первый этап ревизии

На первом этапе ревизии проверяется, были ли разработаны соответствующие
подходы, системы и процедуры для поддержания приемлемых уровней
управления финансовой деятельностью. При этом оценивается:
— сметная стоимость проекта;
— перспективная оценка потока денежной наличности;
— финансовые рычаги управления;
— требования к решению об осуществлении затрат;
— система учета;
— методология оценки;
—
уровень детализации календарного графика и методика надбавок к
стоимости;
— контроль за внесением изменений;
30

31. Второй этап ревизии

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

32. Третий этап ревизии

Основная цель третьего этапа ревизии — обеспечение независимой оценки
выполнения законченного проекта.
В системе финансирования проекта важнейшую роль играет деятельность,
обеспечивающая рациональное расходование выделенных на его реализацию
средств.
Понимание того факта, что к расходам на проект следует относиться осознанно
и ответственно как с самого начала работы над проектом, так и в ходе
последующей его реализации является одним из главных условий
эффективного управления.
Эффективность деятельности менеджера проекта в значительной степени
зависит от того, насколько грамотно и ответственно решается им проблема
регулирования расходов по проекту. Инструментом, способствующим решению
указанной проблемы, является специальный план, известный в зарубежной
литературе по управлению проектами как cost management plan (CMP), что
можно перевести как план управления расходами или план регулирования
расходов.
32

33. Задачи бюджетного контроля

— получение точных оценок затрат;
— распределение расходов во времени;
— подтверждение затрат;
— своевременная отчетность по затратам;
— выявление ошибочных затрат;
— подготовка отчета о финансовом состоянии проекта;
— прогноз затрат.
33

34. Система бюджетного контроля

34

35. Контроль реализации проекта

35
Контроль
реализации проекта

36. Контроль при реализации проекта

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

37. Информация

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

38. Инструменты и методы процесса отчетности об исполнении

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

39. Методы прогнозирования

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

40. Методы прогнозирования

Методы временных рядов. Эти методы используют исторические данные в
качестве основы для оценки будущих результатов. Примерами методов из
данной категории могут быть: освоенный объем, экстраполяция и оценка
тренда и др.
Причинно-следственные / эконометрические методы. Данные методы
основаны на возможности определения факторов, которые могут повлиять
на прогнозы. Например, падение процентной ставки по кредитам может
спровоцировать рост продаж домов.
Субъективные
методы. Эти методы включают в себя интуитивные
суждения, мнения и вероятностные оценки для определения будущих
результатов. Примерами таких методов являются составные прогнозы,
опросы, метод Дельфи, разработка сценариев, прогнозирование
технологий и прогнозирование по аналогиям.
Другие методы. Другие методы могут включать в себя моделирование,
вероятностное прогнозирование и др.
40

41. Методы коммуникаций

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

42. Системы отчетности

Системы
отчетности используются для записи, хранения и
распространения информации о проекте (включая информацию об
исполнении работ, стоимости и расписании).
Информация может распространяться в виде презентаций, таблиц,
графиков в различных видах, включая S-кривую, гистограммы и др.
Выходами процесса являются: отчеты об исполнении и запросы на
изменения.
Панель инструментов — это пример простого отчета, использующего
цветные индикаторы «красный — желтый — зеленый» для отражения
статуса проекта. Красный цвет означает, что у данного элемента
есть проблемы или отставание от расписания, желтый цвет означа
ет, что существует потенциальная опасность для этого элемента и
необходимы корректирующие действия, зеленый цвет означает, что
все хорошо.
42

43. Контроль осуществляется на основании отчетности об исполнении проекта

• — характеризуют его состояние
(расходование ресурсов, исполнение
расписания и бюджета) на отчетную дату;
• отчеты о
состоянии
проекта • позволяют судить о динамике проекта
(какие результаты достигнуты, какие
операции завершены, а какие находятся в
стадии выполнения);
• отчеты о
прогрессе
проекта
• — суждения о будущем состоянии и
прогрессе проекта.
• прогнозы
43

44. Контроль

Эта
информация требует соответствующих управленческих
воздействий, внесения изменений. Получить же информацию
возможно в процессе контроля.
Контроль
— систематически протекающий процесс обработки
информации, предназначенный для выявления различий между
плановыми величинами и величинами, взятыми для сравнения, а
также анализа выявленных отклонений.
Контроль охватывает весь период планирования и реализации
проекта. Для успеха проекта его контрольная система должна
отвечать требованиям гибкости, экономичности, полезности для
проекта, этической приемлемости для исполнителей и команды
проекта, быстроты реагирования, удобства в документировании,
способности к расширению.
44

45. Контроль должен обеспечить

мониторинг (систематическое и
планомерное наблюдение за всеми
процессами реализации проекта)
выявление отклонений от целей
реализации проекта
прогнозирование последствий
сложившейся ситуации
обоснование
необходимости принятия
корректирующего
воздействия
45

46. Виды контроля

Предварительный
Текущий
Заключительный
46

47. Предварительный контроль

Предварительный
контроль осуществляется до фактического
начала работ по реализации проекта и направлен на соблюдение
определенных правил и процедур.
Он
включает в себя контроль трудовых, материальных и
финансовых ресурсов с точки зрения установления требований к
ним и предельных величин
Предварительный
Текущий
Заключительный
47

48. Текущий контроль

Текущий контроль осуществляется непосредственно при реализации проекта.
Он основан на сравнении достигнутых результатов с установленными в
проекте стоимостными, временными и ресурсными характеристиками.
контроль времени
• (достижение промежуточных целей и объемов
работ);
бюджета
• (уровень расходования финансовых средств);
ресурсов
• (фактические затраты материально-технических
ресурсов);
качества
• (уровень качества работ).
Предварительный
Текущий
Заключительный
48

49. Заключительный контроль

Заключительный
контроль проводится на стадии завершения
проекта для интегральной оценки реализации проекта в целом.
Предварительный
Текущий
Заключительный
49

50. Система контроля

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

51. Система авторизации работ

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

52. В зависимости от требуемой точности различают следующие технологии контроля:

— контроль в моменты окончания работ
(метод ≪0—100≫);
— контроль в моменты 50%-ой готовности работ
(метод ≪50—50≫);
— контроль в заранее определенных точках
проекта (метод контроля по вехам);
— регулярный оперативный контроль (через
равные промежутки времени);
— экспертная оценка степени выполнения работ
и готовности проекта.
52

53. Контроль исполнения календарных планов и расходования ресурсов

Для контроля исполнения календарных планов и расходования ресурсов
используют те же методы, что и при их составлении.
Это сетевые графики,
расписания и т.д.
S-кривые
(кривые
хода
работ),
матричные
53

54. Инструменты и методы процесса контроля стоимости

управление освоенным объемом (EVM)
прогнозирование
индекс производительности до завершения (TCPI)
анализ исполнения
анализ отклонений
ПО для управления проектом
54

55. Метод освоенного объема

Earned Value Analysis — EVA или Earned Value
Management – EVM.
Используя
метод освоенного объема, можно
проанализировать эффективность исполнения
проекта. Проще говоря, EVM позволяет сравнить
то, что получено или произведено, с тем, что
потрачено.
Здесь
оценивают объем ресурсов, который
осталось потратить — бюджет по завершению
проекта.
Суть EVM состоит в том, что мы берем измерения
сроков, стоимости и содержания проекта в
совокупности и сравниваем их с фактическими
55

56. Метод освоенного объема: показатели

плановый
объем (Planned Value — PV) —
плановая
(сметная)
стоимость
запланированных работ на определенный
момент времени (дату составления отчета);
освоенный
объем — (Earned Value — EV) —
плановая стоимость выполненных работ на
тот же момент времени;
фактическая стоимость (Actual Cost — AC) —
фактическая стоимость выполненных работ;
бюджет
по завершению проекта (Вudget at
Completion — BAC).
56

57. Компоненты стоимости

плановая
стоимость
(PV)
—
это
утвержденный бюджет на плановые
работы;
освоенный объем (EV) — фактически
выполненные работы и утвержденный
бюджет на эти работы.
фактическая
стоимость
(АС)
—
фактические затраты на выполнение
работ за определенный период
Продвигается ли проект согласно плану или все-таки существуют
отклонения от утвержденного базового плана?
Пример: PV = 400, EV = 375, АС = 325.
57

58. Отклонение по стоимости

Отклонение по стоимости (cost variance, CV) — отражает соотношение
утвержденной и фактической стоимости выполненных работ и затрат за
определенный период или на текущий день: CV = EV – АС
Если CV < 0, то фактические затраты превышают запланированный
бюджет.
Если CV > 0, то фактические затраты ниже запланированных в бюджете.
Давайте вычислим CV на 1 июля:
375 — 325 = 50
58

59. Отклонение по срокам

Отклонение по срокам (schedule variance, SV) указывает, есть ли
опережение или отставание по срокам, установленным в базовом
плане. Рассчитывается следующим образом:
SV = EV — PV
SV < 0 означает отставание от установленного срока.
SV > 0 означает опережение запланированного графика реализации
Для примера: 375 — 400 = -25.
59

60. Анализ состояний проекта по абсолютным отклонения

60

61. Индекс выполнения стоимости

 Индекс
выполнения стоимости (cost performance index, CPI) —
отношение освоенного объема к фактической стоимости выполненных
работ:
CPI
определяет эффективность затрат на текущую дату или по
завершении проекта. Если CPI больше единицы, то затраты ниже, чем
ожидалось, а если меньше единицы, то выше.
Для примера: CPI = 375 / 325 = 1,15. Исполнение проекта по стоимости
лучше, чем предполагалось.
Совокупный CPI часто используется с целью составления прогнозов
затрат по завершении.
Совокупный CPI = Совокупный EV / Совокупный АС
61

62. Индекс выполнения сроков

 Индекс
выполнения сроков (schedule performance index, SPI) —
отношение плановой стоимости выполненных работ к затратам, за
планированным к рассматриваемому периоду:
Эта
формула должна использоваться в совокупности с анализом
критического пути для того, чтобы определить, завершится проект до
или после запланированного срока. Если SPI больше единицы, то
налицо опережение сроков, если же меньше единицы, то выполнение
проекта отстает по срокам.
Для примера: SPI = 375/400 = 0,94. Выполнение сроков осуществляется
не так, как ожидалось.
Также можно рассчитать совокупный SPI по завершении проекта:
Совокупный SPI = Совокупный EV / Совокупный PV.
62

63. Прогноз стоимости по завершению проекта

При
прогнозировании
используется
собранная
информация
к
определенной дате и оцениваются будущие условия или исполнение
проекта.
Прогнозирующим показателем является оценка по завершении (estimate
at completion, EAC). EAC прогнозирует ожидаемую общую стоимость
компонента работ, операции или проекта по его завершении.
Это вероятная итоговая стоимость компонента или проекта. Существует
несколько формул определения ЕАС:
Прогноз по завершении «снизу вверх» ЕАС = АС + ЕТС
Прогноз по завершении для работ ЕТС, выполненных по
забюджетированным ставкам: ЕАС = АС + ВАС — EV
Прогноз по завершении для работ ЕТС, выполненных с эффективностью
текущего CPI: ЕАС = ВАС / Совокупный CPI
Прогноз по завершении для работ ЕТС с учетом обоих факторов SPI и
63

64. Оценка по завершении (EAC)

64

65. 1. Прогноз до завершения ETC

1. в случае некорректности предыдущих оценок составляется новый
прогноз:
ЕАС рассчитывается как фактические затраты на момент расчета
плюс величина ЕТС:
ЕАС = АС + ЕТС
Прогноз до завершения на основе метода «снизу вверх» (estimate to
complete, ETC) — это оценка, сделанная членами команды проекта,
реально участвующими в выполнении операций проекта. Они со
общают менеджеру проекта сведения о том, какие работы осталось
выполнить (следовательно, и их стоимость), основываясь на инфор
мации об уже выполненных работах. Эти оценки суммируются для
получения итогового значения ЕТС.
65

66. 2. Бюджет по завершении

2. в случае, когда возникли непредвиденные отклонения, которые в
дальнейшем, скорее всего, не возникнут вновь.
Бюджет по завершении (budget at completion, ВАС). ВАС — это сумма
всех расходов для всех оставшихся работ (это общий плановый объем
для оставшихся компонент работ или проекта).
EAC = AC + (BAC — EV)
По этой формуле ЕАС определяется на основе фактической стоимости
на конкретную дату и предположения, что все будущие работы ЕТС
будут выполнены по забюджетированным ставкам.
Предположим, что АС = 800 долл., ВАС = 1200 долл., EV = 600 долл.
Тогда ЕАС = 800 + 1200 — 600 = 1400 долл.
Это значит, что вы потратите 1400 долл, на выполнение этого
компонента работ (проекта), предполагая, что оставшаяся работа
66

67. 3. с эффективнос­тью текущего CPI

3. с эффективностью текущего CPI
3. в случае типичных и ожидаемых далее отклонений:
«ЕАС для работ ЕТС, выполненных с эффективностью текущего СРI».
Этот прогноз предполагает, что будущее исполнение проекта будет
таким же, как и предыдущее:
ЕАС = ВАС / Совокупный CPI.
Предположим, что ВАС = 2200 долл., совокупный CPI = 1,2.
Следовательно,
ЕАС = 2200 / 1,2 = 1833,33 долл.
Формула показывает, что вы ожидаете экономию расходов по
сравнению с запланированным уровнем.
67

68. 4. с учетом обоих факторов

Последняя формула звучит так: «ЕАС для работ ЕТС с учетом обоих
факторов SPI и СРI». Эта формула предполагает следующее:
текущий перерасход бюджета и жесткую необходимость уложиться
в срок. Формула имеет следующий вид:
ЕАС = АС + ((ВАС — EV) / (Совокупный CPI х Совокупный SPI)).
Предположим,
что АС = 1000 долл., ВАС = 1500 долл.,
EV = 900 долл., совокупный CPI = 0,97, совокупный SPI = 1,05.
Получаем:
ЕАС = 1000 + ((1500 — 900) / (0,97 х 1,05)) = 1598,1 долл.
68

69. Методы определения ЕТС

Вдобавок к определению ЕТС методом «снизу вверх», существуют еще
две формулы для его вычисления.
Если вы уверены, что будущие отклонения в стоимости будут похожи на
текущие, то ЕТС вычисляется так:
ЕТС = (ВАС — Совокупный EV) / Совокупный CPI
Предположив,
что совокупный EV =725, совокупный CPI = 1,12,
ВАС = 1000, получаем: ЕТС = (1000 — 725) / 1,12 = 245,5.
Таким образом, на момент расчета вам необходимы 245,5 долл, для завершения
оставшихся работ или проекта.
Если вы уверены, что будущие отклонения в стоимости не будут похожи
на предыдущие, то ЕТС вычисляется так:
ЕТС = ВАС — Совокупный EV
Подставим значения: ЕТС = 1000 — 725 = 275.
69

70. Индекс производительности до завершения

Индекс производительности до завершения (to-complete performance
index, TCPI) представляет собой прогноз эффективности выполнения
стоимости, которая должна быть достигнута на оставшихся работах для
достижения ЕАС или ЕТС. Этот показатель вычисляется путем деления
стоимости оставшихся работ на оставшиеся денежные фонды:
TCPI = (ВАС — EV) / (ВАС — АС).
Предположим, что ВАС = 1000 долл., EV = 700 долл., АС = 800 долл.
Тогда: TCPI = (1000 — 700) / (1000 — 800) = 1,5.
Полученный результат означает, что вам необходимо увеличить CPI в 1,5
раза по сравнению с текущим значением, чтобы выйти на планируемое
значение ВАС. Если TCPI меньше единицы, то можно снизить
эффективность выполнения будущих работ.
70

71. Индекс производительности до завершения

Если значение ВАС больше не актуально, то менеджер проекта должен
вычислить значение ЕАС, которое станет целевым для дальнейшего
сравнения. В этом случае формула для TCPI приобретает следующий вид:
TCPI = (ВАС — EV) / (ЕАС — АС)
Добавим
к предыдущим выкладкам значение ЕАС = 1200 долл.
Следовательно, TCPI = (1000 — 700) / (1200 — 800) = 0,75.
Если совокупный CPI становится меньше единицы, всю дальнейшую
работу по проекту вы должны выполнять в соответствии с TCPI.
71

72. Анализ отклонений

Анализ отклонений в процессе контроля стоимости проверяет раз
ницу между базовым планом исполнения стоимости и фактическим
исполнением.
Показателем, вычисляемым в ходе анализа, является отклонение
по завершении (variance at completion, VAC). Он вычисляет
разницу между бюджетом по завершении и прогнозом по завер
шении:
VAC = ВАС — ЕАС
Если VAC меньше нуля, то бюджет исполняется неэффективно.
72

73. Расчетные формулы

Промежуточные выводы
Мантра
любого заинтересованного лица: «в срок и в рамках
бюджета». Следовательно, контроль за бюджетом и расписание
проекта — это две наиболее важные задачи в управлении проектом.
Процесс контроля стоимости направлен на управление изменениями
стоимости проекта. В ходе процесса также отслеживаются бюджеты
проекта с целью предотвращения включения в базовый стоимостной
план несанкционированных или ошибочных расходов. Для
отслеживания расходов в процессе используются метод освоенного
объема (показатели CV, SV, CPI, SPI), прогнозирование (показатели
ЕТС, ЕАС) и анализ исполнения проекта (анализ отклонений, анализ
тенденций и метод освоенного объема).
Процесс контроля расписания направлен на определение текущего
статуса выполнения расписания проекта, на определение возникших
отклонений или необходимости их внесения и на управление
изменениями в расписании.
75

74. Расчетные формулы

76

75. Промежуточные выводы

Метод освоенного объема и вопросы
оперативного управления проектом
Отстает проект от графика или опережает его?
• Отклонение по расписанию (по срокам) (SV)
Насколько эффективно используется время?
• Индекс выполнения расписания (SPI)
Находится проект в рамках или за рамками бюджета?
• Отклонение по затратам (по стоимости) (CV)
Насколько эффективно используются ресурсы?
• Индекс выполнения бюджета (CPI)
Насколько эффективно должны использоваться ресурсы для успешного завершения проекта?
• Индекс необходимой эффективности (TCPI)
Какова ожидаемая стоимость проекта?
• Прогнозная стоимость проекта (ЕАС)
Будет проект завершен в рамках или за рамками бюджета?
• Отклонение при завершении (VAC)
77

76.

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

77. Метод освоенного объема и вопросы оперативного управления проектом

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

78. Задачи регулирования хода реализации проекта

Мониторинг проекта
Важным элементом системы контроля является мониторинг проекта. Это
механизм осуществления постоянного наблюдения за важнейшими текущими
результатами реализации проекта с целью своевременного обнаружения
отклонений от календарного плана и бюджета.
Мониторинг
позволяет
осуществить
сравнение заданных и фактических
данных,
касающихся
планирования
проекта и его реализации. Путем оценки
проводится сравнение между заданными
плановыми
показателями
и
фактическими показателями проекта.
Осуществлять мониторинг может как
команда проекта, так и организации,
работающие вне его рамок.
80

79. Процесс регулирования

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

80. Мониторинг проекта

Команда для мониторинга
1.
2.
3.
4.
• Это должна быть небольшая команда, состоящая из экспертов, имеющих
опыт осуществления проектов и знания особенностей данного проекта.
• Команда изучает проект на месте его проведения.
• Команда составляет краткие отчеты и передает их менеджменту
проекта.
• Предложения и рекомендации, сделанные командой, должны
учитываться, а их реализация — проверяться при осуществлении
дальнейших мониторингов.
82

81. Задачи мониторинга

Процедура мониторинга
83

82. Команда для мониторинга

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

83. Процедура мониторинга

Основные характеристики контекста
организационных изменений
Характеристика Основные аспекты
Власть и влияние Кому принадлежит власть в организации? Чьей
поддержкой внутри и вовне организации необходимо
заручиться? Какими возможностями по проведению
изменений
обладают
руководители
отдельных
подразделений?
Время
Сколько времени есть у организации, чтобы достичь
желаемого состояния? Она находится в кризисе и нужно
быстро принимать решения, или есть время для
спокойных
эволюционных
преобразований?
Каковы
ожидания ее владельцев? Они хотят получить быстрые
результаты
или
готовы
ждать
фундаментальных
преобразований?
85

84. Управление изменениями

Основные характеристики контекста
организационных изменений
Характеристика
Масштаб
изменений
Степень
сохранения
активов
Степень
разнообразия
персонала
Основные аспекты
Требуется слегка изменить систему выпуска продукции
или нужна полная трансформация? Изменения должны в
основном затронуть какое-то конкретное подразделение
или всю организацию в целом?
Идентификация осязаемых и неосязаемых активов. Что
целесообразно сохранить и что можно ликвидировать?
Насколько разнообразны работники по своим ценностям,
предпочтениям, нормам и правилам поведения? Много ли
субкультур и национальных культур существует в группах?
86

85. Основные характеристики контекста организационных изменений

Характеристика Основные аспекты
Способность
к Есть ли у организации способность, опыт и потенциал для
изменениям,
преобразований?
Как
широко
этот
потенциал
потенциал
распространен внутри организации? Насколько глубоко
организация и ее персонал изменялись в прошлом? Есть
ли в организации люди, которые представляют, что такое
изменения, и практикуют их в индивидуальном порядке?
Платежеспособ- Какие финансовые и кадровые ресурсы может выделить
ность
организация на проведение изменений?
Готовность
к Персонал сознательно идет на перемены или людей надо
изменениям
убеждать? Какова степень сопротивления изменениям?
Какова степень поддержки изменений?
87

86. Основные характеристики контекста организационных изменений

Характеристика Основные аспекты
Путь изменений Эволюция — природа изменений основана на постепенном,
приростном принципе, а в конечном результате они
направлены на полную трансформацию организации.
Адаптация — принцип остается тем же, но в результате
изменений должна быть преобразована только какая-то
часть
организации.
Реконструкция
—
быстрые
преобразования в части организации. Трансформация —
полное изменение организации быстро, в сжатые сроки
Стиль изменений Зависит от стиля управления, предпочитаемого или
выбираемого менеджером, отвечающим за изменения.
Существует множество подходов к классификации стилей
(директивный, основанный на участии, эксплуататорский,
стиль сотрудничества и т.д.)
88

87. Основные характеристики контекста организационных изменений

Характеристика Основные аспекты
Цель изменений На чем будут сосредоточены изменения главным образом?
Это могут быть изменения ценностей персонала,
поведенческие изменения, изменения качества продукции
и т.п.
Роли
в Изменения тогда будут происходить так, как мы хотим,
изменениях
когда есть, кому играть роль лидера. Тогда есть смысл
говорить об управлении стратегическими изменениями.
Агенту изменений необходима поддержка других людей.
Необходимо создавать социальную базу для изменений.
Можно
приглашать
внешних
фасилитаторов
для
продвижения в процессе изменений. Создание команды
единомышленников — весьма важный вопрос
89

88. Основные характеристики контекста организационных изменений

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

89. Основные характеристики контекста организационных изменений

Процесс
управления
изменениями
91

90. Основные характеристики контекста организационных изменений

Логика внедрения изменений
92

91. Процесс управления изменениями

Подходы к внедрению изменений
В контексте главной стратегии первыми
угрожающие реализации проекта. Затем
востребованные персоналом.
решаются проблемы,
вводятся изменения,
Стратегия
принуждения, предусматривающая силовое решение
вопроса. Требует тщательного непрерывного контроля, приказ
выполняется по минимуму, но выполняется, если контроль надежен.
Стратегия
рационального
убеждения,
решение
реализуется
максимально, но одновременно проверяется на разумность — появление
у исполнителя сомнений немедленно тормозит процесс.
Стратегия формирования новых ценностей, требует больших затрат
времени, хотя теоретически результативно (практически, рынок
меняется слишком быстро, чтобы получить результат до устаревания
идей, кроме случаев ≪вечных≫ ценностей).
Стратегия
компромиссов. Бартер есть сочетание убеждения и
принуждения, усиливающее действенность обоих, но — за
93

92. Логика внедрения изменений

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

93. Подходы к внедрению изменений

Управление изменениями
95

94. Выбор стратегии

В ходе реализации проекта может
возникнуть необходимость осуществить
следующие изменения
1) изменения содержания продукта (состав и спецификация элементов
продукта);
2) содержания проекта (состав и содержание работ проекта) — например,
внесение незначительных, но, как правило, многочисленных и зачастую
неконтролируемых улучшений по просьбе заказчика. Последнее особенно
характерно для инновационных проектов, где заказчики занимают
активные позиции в ходе их реализации;
3) сроков и стоимости проекта;
4) процедур управления проектом;
5) вследствие реакции на наступление рисковых событий.
96

95. Управление изменениями

Источники изменений
Внешние источники
изменений
• относятся политические,
экономические социальные,
законодательные,
технологические,
экологические,
международные,
географические и др.
аспекты.
Внутренние источники
изменений
• формируются в процессе
отношений между
участниками проекта.
97

96. В ходе реализации проекта может возникнуть необходимость осуществить следующие изменения

Изменения оказывают
существенное влияние на:
ценность и
эффективность
проекта;
качество выполнения
работ и спецификации
требований к
результатам.
продолжительность
и сроки завершения
проекта;
стоимость и
бюджет
проекта;
98

97. Источники изменений

Документы, регламентирующие и
протоколирующие прохождение изменений
1. Отчет о проблеме (Problem report) — описание проблемы,
возникающей в ходе реализации проекта. Формируется на начальной
стадии.
2. Запрос на осуществление изменения (Change request) — формируется
на начальной стадии.
3. Описание предполагаемого изменения (Change proposal form) —
информация об изменении, его текущем статусе, инициаторах и
ответственных за выполнение и контроль.
Формируется на начальной и корректируется на последующих стадиях.
4. Заявка на изменение (Change order) — оформляется в виде
письменного приказа и подписывается должностным лицом подрядчика;
разрешает и указывает, какие производить изменения по проекту.
Формируется на стадии принятия решения.
99

98. Изменения оказывают существенное влияние на:

Управление конфигурацией
Управление конфигурацией представляет собой подмножество управления
изменениями, которое акцентирует внимание на том, как реализовать
утвержденные изменения.
Это
набор формализованных документированных процедур, которые
определяют, как результаты и документация проекта контролируются,
изменяются и утверждаются. Именно эта подсистема обеспечивает
единообразие документов, используемых всеми исполнителями в работе
над проектом.
Управление конфигурацией особенно важно в проектах, связанных с
созданием сложных инновационных продуктов.
Каждая очередная версия обновления компонента такого продукта требует
документирования и является объектом управления конфигурацией такого
продукта.
100

99. Документы, регламентирующие и протоколирующие прохождение изменений

Управление конфигурацией охватывает процессы
подачи предложенных изменений;
отслеживания системы рассмотрения и утверждения
предложенных изменений;
определения уровней утверждения для
авторизации изменений;
обеспечения методов реализации
одобренных изменений.
101

100. Управление конфигурацией

Этапы организации управления
конфигурацией проекта
102

Исследования группы
Стендиша (Standish Group) [1] свидетельствуют
о следующем. В США ежегодно тратится
более 250 миллиардов долларов на разработку
прило­жений информационных технологий
в рамках примерно 175 000 проектов. Средняя
стоимость проекта составляет:

• для крупной компании
  — $2 322 000;

• для средней компании
  — $1 331 000;

• для мелкой компании
  — $434 000.

При этом 31 % проектов
будет прекращен до за­вершения. Затраты
на 52,7% проектов составят 189% от первоначальной
оценки.

Исходя из этого, группа
Стендиша оценивает, что американские
компании и правительственные учреждения
потратят 81 миллиард долларов на
программные проекты, которые так и не
будут завершены. Эти же организации
заплатят допол­нительно 59 миллиардов
долларов за программные проекты, которые
хотя и завер­шатся, но значительно
превысят первоначально отведенное на
них время.

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

• успешные — завершенные
  срок и в рамках отведенного бюджета;

• проблемные –
  проекты, по которым возникла задержка
  или проекты, не оправдавшие ожи­даний;

• потерпевшие неудачу
  — прекращенные проекты.

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

• Недостаток исходной
  информации от клиента: 13% всех проектов.

• Неполные требования
  и спецификации: 12% проектов.

• Изменение требований
  и спецификаций: 12% всех проектов.

По остальным факторам
(рис. 3.1), влияющим на успех проекта,
данные сильно расходятся:

• проект потерпел
  неудачу из-за нереалистического подхода
  к составлению графика и выделению
  времени — 4% проектов,

• неправильный подбор
  персонала и выделения ре­сурсов — 6%,

• несоответствия
  технологических навыков (7%)

• по другим причинам.

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

Рисунок
3.1. Факторы, влияющие на провал проекта.

Хотя большинство
проектов действительно превышают
отведенное время и бюджет, если их вообще
удается закончить, группа Стендиша
обнаружила, что около 9% проектов крупных
компаний были завершены вовремя и в
пределах бюджета; аналогичного успеха
удалось достигнуть в 16% проектов мелких
компаний. Согласно проведенному
исследованию тремя наиболее важными
«факторами успеха» были названы
следующие.

• Подключение к
  разработке пользователя: 16% всех успешных
  проектов.

• Поддержка со стороны
  исполнительного руководства: 14% всех
  успешных проектов.

• Ясная постановка
  требований: 12% всех успешных проектов.

Другие источники
приводят даже более впечатляющие
результаты. Например, орга­низация
ESPITI (European Software Process Improvement Training Initiative —
Европей­ская инициатива по обучению
совершенствованию процесса программирования)
прове­ла опрос с целью определить
относительную важность различных типов
су­ществующих в отрасли проблем. Двумя
самыми главными проблемами, упоминавшимися
почти в половине ответов, оказались
следующие.

• Спецификации
  требований.

• Управление
  требованиями клиента.

Если бы ошибки требований
можно было быстро, просто и экономно
устранять, про­блема не была бы столь
серьезна. Алан Дэвис (Davis) в своей работе
[2] подвел итоги нескольких исследований
и показал, что при обнаружении ошибок
на стадии формирования требова­ний
компания получает экономию средств в
соотношении 200:1 по сравнению с их
обнаружением на стадии сопровождения
программы.

Такая стоимость ошибок
обусловлена эффектом умножения. Многие
из ошибок в требованиях достаточно
долго остаются не обнаруженными, и
группа разработчиков тратит время и
усилия на создание проекта по этим
ошибочным требованиям. В результате
проект, вероятно, придется отбросить
или пересмотреть. Для уточнения, в чем
же состоит ошибка требований, необходимо
общение с клиен­том, который участвовал
в его разработке на самом первом этапе.
Однако на практике может оказаться, что
в данный момент связаться с этим человеком
невозможно, он забыл, в чем со­стояла
суть инструкции, которую он давал команде
разработчиков, не помнит, чем
руководствовался при этом, или же просто
изменил свою точку зрения. Может
оказаться, что принимавший участие на
этом этапе член команды разработчиков
(бизнес-аналитик или системный аналитик)
пе­решел в другое подразделение. В
результате определенная часть работы
проделывается вхолостую, что приводит
к потере времени. Проблемы, связанные
с «просачиванием» недостатков из
одного этапа в другой, явля­ются вполне
очевидными, однако подавляющее большинство
организаций ими всерьез не занималось.

Одной из организаций,
действительно работавшей над данным
вопросом, является компания “Hughes
Aircraft”. Исследование Снайдера (Snyder) [3]
обнаружило явление «просачивания»
дефектов во многих проектах, выполненных
компанией на протяжении 15 лет. В данном
исследовании говорится о том, что 74%
дефек­тов, связанных с формированием
требований, были обнаружены на этапе
анализа требова­ний, когда клиенты
совместно с системными аналитиками
обсуждают, подвергают мозго­вому
штурму, согласовывают и документируют
требования к проекту. Этот этап работы
над проектом является идеальным с точки
зрения обнаружения таких ошибок с
наименьшими затратами. Однако исследование
также свидетельствует, что 4% дефектов
«просачиваются» на этап предварительного
(высокоуровневого) проектирования, а
7% — еще дальше, на этап детализированного
проектирования. Невыявленные ошибочные
требования жизненному циклу системы,
и 4% ошибок требований оказываются не
найденными вплоть до этапа сопровождения,
когда система уже передана клиентам и
счи­тается полностью работоспособной.

Таким образом, в
зависимости от того, где и когда при
работе над проектом разработ­ки
программного приложения был обнаружен
дефект, стоимость его устранения может
разниться в 50-100 раз. Причина состоит в
том, что для его исправления придется
затратить средства на не­которые (или
все) ниже перечисленные действия.

• Повторная спецификация.

• Повторное
  проектирование.

• Повторное кодирование.

• Повторное тестирование.

• Создание документации.

• Замена де­фектной
  версии исправленной.

• Списание части
  работы, которая оказалась ненужной.

• Выплаты по гарантийным
  обязательствам

Из сказанного выше
можно сделать два вывода.

• Ошибки в определении
  требований являются наиболее
  распространенными.

• Стоимость устранения
  таких ошибок — одна из самых высоких.

Ошибки в определении
требований приводят к затратам,
составляю­щим 25-40% бюджета проекта
разработки в целом. Учитывая частоту
возникновения ошибок в определении
требований и эффект умно­жения
стоимости их устранения, легко предсказать,
что эти ошибки обусловят до 70% затрат
на повторную работу.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Цена ошибки

«Чтобы правильно и хорошо жить,
нужно уметь и хотеть жить правильно и хорошо».
Эпиктет (50 – 140 годы н. э.)

Традиционно менеджеры были уверены – производить высококачественные товары и услуги накладно. И в течение многих лет это было оправданием того, отчего компаниям так и не удавалось в полной мере реализовать свой потенциал. Но в 70-тые – 80-тые стало очевидно, что высококачественные продукты обеспечивают высокую прибыль на инвестированный капитал и дают возможность компаниям максимально увеличить свою долю рынка. Взгляды менеджеров на качество начали изменяться. Вот, к примеру, рассуждения Джеймса Олсона, бывшего президента AT&T: «Многие говорят, что качество обходится слишком дорого. Но это не так; высокое качество даст вам возможность сэкономить деньги».

Какие же новые истины открылись менеджерам компаний? Прежде всего, то, что производить продукты и услуги высокого качества выгодно. Если компания не жалеет средств для достижения качества продукции, соответствующего запросам потребителя, то в конечном итоге ее общие затраты будут ниже, чем в случае когда качество не удовлетворяет заказчика (расходы на выяснение причин отказа от продукции, ее переделку, ремонт, замену и т.п.). Профессор Джуран, ведущий специалист по качеству, сравнивает это с добычей «золота в шахте»: чтобы спуститься под землю, могут понадобиться значительные суммы инвестиций и большие усилия, но в дальнейшем «золото» (высокое качество продукции) даст компании возможность увеличить прибыль.

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

Система «затраты на качество» Арманда Фейгенбаума: язык понятный всем

В 1943 году Арманд В. Фейгенбаум, работавший в то время в General Electric Company’s Schenectady Works, разработал систему «затраты на качество», которая включала затраты на контроль качества, а также затраты, понесенные в случае когда продукт не соответствовал потребностям клиентов. Система была адаптирована к языку топ-менеджеров и акционеров: в ее основе лежал доллар. И поэтому, когда Фейгенбаум представил систему руководителям компании, она сразу же привлекла их внимание. Вскоре концепция «затраты на качество» была внедрена в GE Jet Engine Group в Массачусетсе; а к 1948 году – во всей компании GE в США. Система Фейгенбаума учитывала следующие категории затрат: на предотвращение дефектов, на оценку качества продукта, а также затраты, обусловленные внутренними и внешними дефектами продукта.

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

Арманд В. Фейгенбаум более 10 лет проработал в General Electric, затем основал собственную консалтинговую фирму General Systems Company, Ltd, которая ныне стала одним из мировых консультационных центров по менеджменту качества.

Различные модификации системы затрат на качество были внедрены в целом ряде компаний, в частности IBM, Bendix, Komatsu Ltd., Abbott Laboratories, Westinghouse, Honeywell, General Electric, International Telephone & Telegraph, Irving Trust, Eaton, Digital Equipment, Allis-Chalmers Canada, General Motors и многих других. Такие системы должны были помочь менеджерам найти ответы на вопросы: как реорганизовать деятельность компаний; как сделать концепцию качества основой деятельности всей организации; как оценить эффективность системы управления качеством.

Само понятие «затраты на качество» имеет некий негативный оттенок, в значительной мере отражая подходы, доминировавшие в 50-тые, когда бытовало мнение – чем выше качество продукции, тем выше и затраты на ее производство. Но по мере того как изменялось отношение менеджеров к концепции «затраты на качество», изменялось и само содержание этого понятия. Поскольку задача системы «стоимость качества» состоит в снижении затрат компании, обусловленных плохим качеством продукции или услуг, суть такой системы более точно отражает термин «затраты на неудовлетворительное качество» (poor-quality cost, PQC).

Концепция PQC и другие

Концепция PQC отличается от других некоторыми положениями.

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

Сколько стоит плохое качество?

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

И хотя руководители большинства компаний знают, что цена плохого качества очень высока, реальные суммы часто оказываются настоящим откровением. В большинстве случаев финансовые потери компании, обусловленные низким качеством продукции, составляют 20-40% от суммы продаж, но нередки случаи, когда они значительно превышают эту сумму. Бывший председатель IBM Джон Эйкерс признавался: «Когда мы проанализировали, сколько тратим на качество: а именно – на предотвращение сбоев и устранение дефектов, мы были удивлены и обеспокоены. Прежде всего, наши общие затраты на качество оказались выше, чем мы ожидали. И кроме того, если то, что мы определяем как стоимость профилактики дефектов и оценки качества составляла в общей сумме одну четвертую часть; то доля стоимости устранения последствий дефектов – около трех четвертых».

Слова Эйкерса находят подтверждение и в высказываниях топ-менеджеров других корпораций. Так, согласно Джеймсу Э. Прэстону, экс-президенту компании Avon – крупного мирового производителя косметических средств: «Затраты на то, чтобы в продукт «встроить» качество, составляют 5%, а затраты, связанные с несоответствием продукта – 20% суммы продаж».

Неудовлетворительное качество: управление затратами

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

Какие же виды затрат включает PQC?

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

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

Анатомия прямых затрат

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

Прямые затраты включают:

• затраты, связанные с тем, что руководство опасается, что люди будут совершать ошибки;
• затраты, связанные с тем, что люди совершают ошибки;
• затраты, связанные с обучением сотрудников, с тем, чтобы они могли работать эффективно;

Далее, прямые затраты, связанные с неудовлетворительным качеством, делятся на следующие группы:

• управляемые PQC;
• PQC на устранение последствий совершенных ошибок;
• PQC, связанные с оборудованием.

Управляемые PQC – это затраты на осуществление прямого контроля за соответствием качества продукции и услуг потребностям клиентов. В эту категорию входят затраты на предотвращение ошибок; затраты на проведение оценки качества продукта или услуг и затраты, не связанные с созданием добавочной стоимости.

Затраты на предотвращение ошибок, включают все затраты, связанные с оказанием помощи работникам в постоянном выполнении их работы соответствующим правильным образом. С финансовой точки зрения – это не столько затраты, сколько инвестиция в будущее развитие (иногда специалисты используют термин «инвестиция в предотвращение ошибки»). Обычно затраты на предотвращение включают: тренинги, направленные на профессиональное развитие сотрудников; тренинги, связанные с вопросами менеджмента качества; исследования мнения потребителей; внедрение программ организационных изменений, направленных на усовершенствование бизнес-процессов; анализ и пересмотр процессов создания продукта или услуги; действия по предотвращению повторного проявления ошибок.

Инвестирование в предотвращение ошибки является наиболее эффективным способом сокращения затрат на неудовлетворительное качество. Но почему же такой ценный инструмент используется столь редко? Возможно, потому, что уровень PQC достаточно сложно соотнести с прибылью на инвестированный капитал.

Затраты на оценку качества связаны с определением соответствия качества произведенного продукта или оказанной услуги установленным критериям или процедурам. В частности, это затраты на аудит производственного процесса, на проведение различных испытаний и тестирований продуктов, на сертификацию.

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

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

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

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

Затраты на устранение последствий внешней ошибки компания несет в случае, если ее система не распознает ошибку до того, как продукт (услуга) неприемлемого качества попадает к конечному потребителю. Такие затраты, в частности, включают: затраты на рекламацию продукта (услуги), затраты на обработку жалоб, на гарантийное обслуживание, накладные расходы на содержание центров технического обслуживания.

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

Взаимодействие между управляемыми затратами и затратами на устранение последствий совершенных ошибок представлено на рис. 1.

Примечание: Best interim operating point – Оптимальная промежуточная операционная точка

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

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

При суммировании управляемых затрат и затрат на устранение последствий совершенных ошибок возникает еще одна кривая, которая представляет сумму затрат обоих видов.

На этом же рисунке на кривой обозначена точка, определенная как «оптимальная промежуточная операционная точка». Качество глубоко пронизывает все аспекты деятельности компании, вследствие чего сумма затрат обоих видов минимальна, и наряду с этим прибыль на инвестированный капитал становится максимально высокой. Любое изменение сложившихся условий влечет за собой смещение «точки». Так, положение «оптимальной промежуточной операционной точки» изменяется, если компания учитывает свои непрямые затраты на неудовлетворительное качество.

«Товары возвращаются, покупатели – нет»

Непрямые затраты, связанные c неудовлетворительным качеством – еще одна важнейшая составляющая системы PQC. Эти затраты не всегда очевидны для менеджеров компаний, но они составляют часть жизненного цикла продукции, будучи индикатором того, какую ценность представляет продукция для клиента. Непрямые PQC включают следующие виды затрат: затраты, понесенные клиентом из-за неудовлетворительного качества продукции; потери компании, обусловленные неудовлетворенностью клиента; стоимость утраченной репутации; стоимость утраченных возможностей.

Затраты, понесенные клиентом из-за неудовлетворительного качества продукции

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

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

Затраты, обусловленные неудовлетворенностью клиентов

Не существует частично неудовлетворенных клиентов – клиенты бывают либо удовлетворенные либо нет. На рис. 2 представлена взаимозависимость утраченных доходов компании и уровня удовлетворенности клиентов.

Рис. 2. Взаимозависимость утраченных доходов компании и уровня удовлетворенности клиентов

Как видно, небольшое улучшение качества приводит к существенному сокращению падения доходов компании (левая часть кривой); однако после того как продукция достигает приемлемого для клиентов уровня качества (правая часть кривой), кривая превращается в прямую: хотя качество и продолжает улучшаться, это практически не отражается на сумме утраченных доходов. Изгиб кривой имеет тенденцию к постоянному смещению вправо: то есть минимизация потерь доходов компании из-за неудовлетворенности клиентов требует постоянного улучшения качества. Следовательно, анализ требований и ожиданий клиентов должен приводиться компаниями постоянно.

Стоимость утраченной репутации

Этот вид затрат спрогнозировать и выразить в количественных показателях крайне сложно. Затраты компании в связи с утраченной репутацией отличаются от затрат, обусловленных неудовлетворенностью клиентов, тем, что они отражают отношение клиента к компании в целом, а не к отдельному виду ее продукции. Клиенты перестают покупать продукцию компании; сума недополученных в результате этого доходов и составляет затраты на утраченную репутацию.

Стоимость утраченных возможностей

Стоимость утраченных возможностей отражает финансовые потери, которые несет компания, когда из-за неадекватной оценки ситуации или неудовлетворительного качества продукции она упускает возможность получить определенный доход. Если клиент расторгает контракт стоимостью $1 млн., соответственно, цена утраченной возможности для компании составляет $1 млн. Еще один пример утраченной возможности – клиент меняет продукт компании на аналогичный продукт конкурента. Так, стоимость «переметнувшегося» клиента для американского супермаркета составляет утраченный годовой доход в сумме $12 тыс. Во многих организациях PQC, обусловленные утраченной возможностью, составляют более 100% от суммы совокупных доходов. А во что вылились доходы, недополученные IBM в период, когда компания отвергла предложение Билла Гейтса о продаже IBM патентов на продукты, которые сейчас производит Microsoft?

Как компании используют непрямые PQC?

Ряд организаций не учитывают эту категорию затрат; другие учитывают их только тогда, когда вносят изменения в систему оценки качества; третьи интегрируют эти затраты в свою систему PQC. Такие разные подходы к использованию непрямых PQC в значительной степени определяются тем, насколько велико внимание компании к клиентам. Так, если организация осознает, какие последствия та или иная ошибка может иметь для клиента, то в общую сумму затрат компании на неудовлетворительное качество должны быть включены как минимум затраты клиента из-за неудовлетворительного качества. Анализ непрямых затрат (попытка оценить их и найти ответ на вопрос, почему они возникли) может помочь менеджерам компании правильно оценить ожидания клиентов и сделать так, чтобы PQC, связанные с неудовлетворенностью клиентов, находились в правой части кривой (рис. 2).

В чем ценность системы PQC для компаний?

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

PQC дают возможность оценить в денежном выражении, насколько эффективны внедряемые изменения.

По словам Джеймса Р. Хоугтона, экс-председателя компании Corning Glass, «в Corning анализ затрат на качество дает возможность повысить эффективность работы компании в целом. Это чрезвычайно ценный инструмент, но обращаться с ним надо крайне осторожно, чтобы он не превратился в… обычный молоток».