Расчет на салфетке. Как продать ИТ-проект с помощью математики

ДМИТРИЙ БУТЯНОВ, консультант по решениям компании Microsoft в области портальных технологий и BI,
специализируется на консультациях ключевых заказчиков компании. Опыт работы в области ИТ более 10 лет

Расчет на салфетке
Как продать ИТ-проект с помощью математики

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

Как же много всего поменялось на ИТ-рынке в целом и ИТ-отделах в частности за последнее время! Как только разговор заходит о докризисных временах, на лицах ИТ‑специалистов появляются добрые и немного грустные улыбки. Ведь было же время! И бюджеты давали по первому требованию, и в работу никто особенно не лез – лишь бы все функционировало и можно было работать с новыми технологиями, сколько душа пожелает. А сейчас – лишь следы былой роскоши. Ни тебе бюджетов, ни роста… Конечно, сейчас жизнь не сахар, но давайте-ка вспомним, так ли всё было замечательно в докризисные времена?

Так ли хорошо было?

Ещё год назад большинство предприятий находилось на различных этапах экономического подъёма, а капиталы были доступны, например, в виде кредитов с небольшой процентной ставкой. Хорошо ли было при этом ИТ-отделу? Я бы сказал, что относительно. Обращается, скажем, ИТ-директор к генеральному с предложением внедрить… CRM‑систему. И говорит, что внедрение этой системы позволит уменьшить величину оттока клиентов на 2%. Какой могла быть реакция гендиректора, у которого база клиентов росла на 10-15% в месяц, а объемы продаж – на 20% и без всяких CRM?

Интересная картина получалась. Особое внимание бизнес-пользователи уделяли специфическим ИТ-проектам.

Во-первых, главной целью их реализации было повышение капитализации компании. Это замечательно увеличивало стоимость компании на рынке, например, перед её продажей или перед публичным размещением акций (IPO). И было абсолютно не важно, принесет ли прибыль такой проект, так как главным в нем оставалась сумма потраченных средств. При упоминании таких проектов ИТ-директор, как правило, теперь хватается за голову, так как висят они на нем мертвым или полумертвым грузом.

Во-вторых, «зеленый свет» получали ИТ-системы, которые были своеобразным дресс-кодом для компании. Под влиянием тусовки, семинаров и многочисленных рекламных акций, которые проводят производители программного обеспечения, рождался определенный набор стереотипов, которым бизнес часто следовал. Внедрение подобных систем происходило не потому, что они были действительно нужны, а потому что «у них есть, почему у нас нет?!» или «у всех уже есть, и нам тоже обязательно надо».

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

Заметили, что общего в этих проектах? Решение о начале проекта принималось на основе каких угодно соображений, только не его финансовых параметров (в первую очередь финансовой эффективности) или его полезности. В самом деле, когда с бизнесом всё хорошо, с рентабельностью всё в порядке, а прогнозы продаж устремлены ввысь, зачем возиться с ИТ? Хлопотно это и малоэффективно. Роль ИТ-отдела сводилась к роли обслуживающего подразделения. Эдакий чёрный ящик, с большим аппетитом потребляющий деньги. ИТ-директор ничего не решал, его даже редко звали на совет директоров.

Так ли плохо сейчас?

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

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

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

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

Что считать?

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

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

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

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

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

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

Во-вторых, это достаточно долго, так как требуется выполнить большой объём работ.

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

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

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

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

Чтобы решить эту задачу, существует расчет, который я называю «расчетом на салфетке». Основная идея – исключить из расчёта статьи расходов и доходов, не оказывающих большого воздействия на конечный результат. Наверное, кто-то удивлённо поднимет брови. Как это не рассматривать в расчетах стоимость аренды занимаемой сервером площади и изменение амортизации клавиатур?! Это ведь снизит точность расчёта на 0,01%!!!

Коллеги, мне понятны ваши чувства, но помните: наша задача – не точный расчёт ROI или TCO, а формирование основы для принятия решения о финансировании проекта. И если вы знаете, что в расходах на проект пять статей составляют 90% всех расходов, то остальное – отбрасывайте. Это мелочь, которая отнимет массу сил и времени и в принятии решения не играет никакой роли. Так что смело оставляйте только самое важное и делайте вид, что остального не существует.

Важна также проблема входных данных для расчётов. Приступать к определению экономических параметров внедрений можно в трех различных фазах: до начала проекта, во время его выполнения и после его завершения. Разумеется, идеальным вариантом является тот, при котором можно сделать «снимок» ситуации до внедрения решения и после, потом сравнить два снимка. На практике такой расчет очень редок, по причинам, сами понимаете каким. Так что если расчёты ведутся до начала проекта, то можно сделать снимок текущего состояния подразделения (предприятия), а состояние «после внедрения» придется прогнозировать. Аналогично – если внедрение закончено, то можно сделать снимок «после внедрения», а состояние «до внедрения» надо будет вспоминать. И так далее – суть в том, что одно из состояний будет формироваться не как результат наблюдений, а как результат анализа или прогнозирования. Данные для таких операций можно рассчитать самим или взять примеры реализаций аналогичных проектов, каких на сайтах производителей много. И посмотреть, какие параметры и насколько изменились, у каждой технологии они, скорее всего, свои.

Как считать?

Давайте рассмотрим конкретный пример[1]. Предположим, что мы работаем в торговой компании, у которой есть бумажный документооборот, поддерживающий систему ведения договоров с партнёрами. Партнерская сеть росла, проблемы документооборота также множились и расширялись, но до кризиса на это закрывали глаза – на фоне высоких темпов роста буксующий документооборот поддерживали экстенсивно (наймом дополнительного персонала). Сейчас, в кризис, компания вплотную занялась решением задач снижения себестоимости бизнеса, удержания партнерской сети и так далее. Руководство с надеждой смотрит на нас, ожидая нашего вклада в общее дело. Поразмыслив на досуге, понимаем, что удержание объёмов продаж – наше всё. Проблема документооборота известна, вот тут-то мы можем попытаться что-то сделать, переведя его из бумажного в электронный вид и немного оптимизировав в процессе перевода.

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

• В среднем через систему сейчас проходит 100 договоров в месяц от 100 партнеров.
• Согласующих договор с нашей стороны – 25 человек (для каждого договора!).
• Средний срок согласования договора – 10 дней.

Эти цифры помогут посчитать экономические параметры.

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

Получаем следующий список, ранжированный по степени важности:

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

Слишком долгие сроки согласования документов. Руководству хотелось бы сократить это время примерно на 30%.

Мы сами не лыком шиты и кое-что про документооборот прочитали. И о типичных проблемах «бумажных» систем тоже. В разговорах с респондентами выясняем, что у них они, оказывается, тоже есть, причем довольно острые.

Поиск документов. Каждый договор с контрагентом сопровождает пачка других документов. При перезаключении договора они нужны, их поиск занимает немало времени.

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

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

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

Предполагаем, что:

• Утеря договоров прекратится, так как всё будет в электронном виде.
• Сроки согласования сократятся примерно на 30-40% (в среднем замена бумаги на электронку даст такой эффект).
• Поиск документов будет автоматизирован, и его время сократится в разы, так как на смену поиска по картотеке и ходьбе по помещениям со стеллажами придет простой запрос к электронному архиву.

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

Для расчёта прибыли по проекту пользуемся принципом «что сэкономили, то заработали». Непосредственно система документооборота денег не заработает, но позволит исключить убытки от утери договоров и сэкономить некоторое количество рабочего времени. Зная себестоимость сотрудника в месяц (зарплата + налоги), легко подсчитать себестоимость часа его работы. Зная, сколько часов сможет сэкономить система документооборота, легко превратить это в деньги.

И не надо заниматься вопросами типа «как будут использоваться сэкономленные часы» и так далее. Это не ваши вопросы. Вы даёте директору возможность сэкономить N часов рабочего времени, которое стоит M рублей. Пусть он решает, как этим распорядиться – а он решит, вы не переживайте.

Итак, исходные данные для расчёта прибыли у нас есть и сведены для наглядности в таблицу 1. Колонка «Сейчас» показывает текущее состояние процесса, колонка «После решения» показывает наш прогноз ситуации после реализации проекта.

Таблица 1. Временные затраты на согласования документов

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

Таблица 2. Денежные затраты

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

Список статей может быть очень обширным, но опять же выкидываем всё неважное и составляем краткий список (см. таблицу 3).

Таблица 3. Совокупная стоимость приобретения (ТСА)

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

Таблица 4. Совокупная стоимость владения (ТСО)

А теперь под звук труб и фанфар мы определяем общую прибыль от проекта за 12 месяцев – примерно 4 млн руб в первый год. При этом ROI проекта за первый год составляет 242%, а срок окупаемости 93 дня.

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

Аналогичные методики можно применять и для расчёта эффективности развёртывания других технологий. Помните о двух принципах: «отбрасывание всего лишнего» и «то, что сэкономили, то заработали». Например, технологии Unified Communications позволят сэкономить на стоимости использования фиксированной и мобильной связи (в меньшей степени) и на расходах на командировки сотрудников (в большей степени), а также на количестве и длительности совещаний.

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

Внедрение того же System Center позволит сэкономить рабочее время работников ИТ-отдела, рабочее время сотрудников компании (ускорение операций восстановления данных), а также уменьшит стоимость аппаратного обеспечения за счёт виртуализации.

И главное – попробуйте взглянуть на ИТ-проект глазами того, кто платит. У этого человека масса требующих решения проблем. Если вы станете для него человеком, способным разрешить хотя бы часть этих проблем, – у вас всё получится.

Удачи!