Как измерить все, что угодно

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

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

Применяя инвестиционные границы для оценки инвестиционных проектов, мы обнаруживаем, что требуемая скорректированная на риск ROI должна быть значительно выше типичных «пороговых ставок» (требуемой минимальной доходности), используемых иногда руководителями, санкционирующими вложение средств в информационные технологии (нередко эти пороговые ставки составляют 15–30 %). С ростом объемов предполагаемых инвестиций этот эффект быстро усиливается. Доходность самых крупных проектов разработки программного обеспечения должна намного превышать 100 %. Риск замораживания проекта, неопределенность в связи с выгодами и риск возникновения неожиданных препятствий — все это увеличивает рискованность таких проектов, а значит, и их требуемую доходность. Для руководителей, санкционирующих инвестиции в информационные технологии, этот вывод важен по целому ряду причин.

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

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

Количественное определение субъективных компромиссов: решение проблемы нескольких взаимоисключающих предпочтений

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

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

Когда клиенты просят меня помочь им оценить эффективность, я всегда спрашиваю их: «А что вы подразумеваете под эффективностью?» В ответ они, как правило, предоставляют мне перечень разрозненных наблюдений, которые ассоциируются у них с эффективностью, например: «Этот человек всегда все делает вовремя» или «О ней заказчики всегда отзываются положительно». Могут упоминаться и такие факторы, как небольшое число допускаемых ошибок или высокая производительность труда, например: «За три месяца этот сотрудник сумел собрать целых три модуля без брака». Иными словами, проблема в том, что никто не представляет, как наблюдать эффективность. Один мой клиент высказался: «Я знаю, что должен искать, но как мне суммировать все это? Могу ли я считать, что тот, кто делает всю работу вовремя и почти без ошибок, работает эффективнее того, кто постоянно получает больше положительных отзывов клиентов?»