Перевод "How to lie with cost models" by Brian Madden.
Статья была написана в 2009 году, когда зарождался хайп VDI, поэтому примеры приводятся именно из этой сферы. Но все без исключения техники применимы в любой другой сфере.

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

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

Краткое содержание (хотя и пугающее): когда ты создаешь модель затрат для обоснования проекта виртуализации десктопов, то есть 100% гарантия, что ты сможешь подкрутить эту модель для обоснования любого выбранного тобой решения. Любого.
Можешь взять одну и ту же компанию, одни и те же входные параметры и создать две модели: "VDI - идеальный проект", и "Нет проекта хуже, чем VDI".

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

Техника 1. Упакуй «мягкие» затраты

• прим. это верный перевод, именно мягкие затраты, а не затраты на ПО

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

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

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

• если у нас 3000 обращений в техподдержку в год

• 15% техподдержка десктопов

• каждое обращение стоит 5000 руб (цифра с потолка, которую тоже можно обосновать 30ю разными способами и качать в любую сторону)

• общая стоимость 3000 * 15% * 5000 = 2 250к руб

А значит если мы сведем обращения к нулю, то экономия 2 млн 250 тыс руб в год! И вот это как раз базовый пример манипуляции "мягкими затратами".
Можно поднять уровень манипуляции, докинув "потерянную продуктивность".

Пусть:

• средняя стоимость сотрудника 1000 руб/час

• виртуализация десктопов даст среднюю экономию 2 часа в год

• 1000 сотрудников

Вуаля, и еще 2 млн руб в год! Разумеется, в реальном мире совершенно не факт, что сотрудники будут работать в эти два сэкономленных часа или будут работать на 2 часа больше, чем обычно. В реальном мире может быть что угодно, например задержаться на 2 неоплаченных часа вечером, чтобы отработать свой отчет (который не мог быть закончен из-за поломанного десктопа).

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

Техника 2. Перемести отслеживаемые затраты в неотслеживаемые

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

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

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

Техника 3. Придумай цифры, если нельзя доказать

Какое-то время назад была у меня встреча, на которой обсуждался вопрос "зелености" VDI, экологичнее ли VDI, чем обычные десктопы. Один из ключевых пунктов в обсуждении был тот, что устройство не всегда работает так, как на нем написано. Иными словами, если в сервере стоит два блока питания по 800 Вт, то это не значит, что сервер потребляет 1600 Вт от момента влючения, это всего лишь значит, что максимально возможное потребление может составить ДО 1600 Вт, а реальное зависит от конфигурации сервера (насколько мощные процессоры, сколько памяти, сколько дисков).

А как же ты можешь узнать сколько на самом деле потребляет каждый сервер? Разумеется, есть серверы, которые умеют измерять свое потребление, ИБП и тд. Но в большинстве случаев они не умеют, и большинство людей вообще не задумывается об электрической мощности. Так что если ты хочешь убить проект с новыми серверами на основании "они слишком много потребляют" - попросту придумай цифры для расчета ежемесячных затрат. Даже если ты неправв, то кто об этом узнает? Вряд ли представитель инженерной службы будет за тобой гоняться с правильным отчетом об энергопотреблении.

Этим Техника 3 отличается от высосанных из пальца цифр из Техники 1 или заметенных под ковер цифр из техники 2. Здесь мы знаем, что стоимость есть и она реальна, но не можем (не хотим) ее измерять. Поэтому попросту ее выкинем / придумаем удобную нам.

Техника 4. Обоснуй экономию фишками, которые заведомо никогда не будешь использовать

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

Так что же делать, если есть «реальные» данные, которые мешают? Вообще не проблема заставить их работать на себя! Если у тебя есть данные, помогающие обоснованию - добавляй в модель затрат, даже если точно знаешь, что они никогда не будут применимы в твоем проекте. Чем больше "самоочевидных" и "всеобще принятых" пунктов - тем лучше!

Умеет ли твой гипервизор в переподписку памяти, чтобы можно было побольше виртуальных машин на сервер? Отлично, добавляй в модель затрат! Даже если в продуктиве ты никогда это не будешь использовать и оторвешь руки тому, кто попробует!

Есть ли у тебя протокол, который потребляет половину полосы от протокола конкурента, которого ты не хочешь использовать в проекте? Прекрасно, добавляй в модель затрат! И плевать, что у тебя гигабит локальной сети до рабочего места, что по сути "неограниченная полоса" в рамках проекта.

Техника 5. Игнорируй неудобные цифры

Если и есть важная мысль в этой технике лжи: если данные / цифры не подтверждают твою точку зрения, просто игнорируй их!

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

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

P.S. знаешь еще техники - смело добавляй в комментариях.