Инвестиции: оценка привлекательности внедрения IT-проектов

Для начала нужно оговориться – инвестициями в сферу информационных технологий обычно считаются и смешиваются между собою четыре основных варианта:

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

В данной статье речь идет только о первом варианте.

Целью статьи не является рассказ о традиционных способах оценки инвестиционных проектов с помощью общеизвестных инструментов. По двум основным причинам:

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

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

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

Первый уровень:

Сколько?
На что?
Что я с этого буду иметь?

В зависимости от степени доверия этого человека к вам, этого уровня может быть достаточно для принятия решения. Но это доверие еще нужно заслужить…

Сколько?

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

На что?

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

Нижеприведенный текст скопирован с сайта Microsoft. Очень часто сотрудники IТ для поддержания обоснованности своей аргументации используют два вида действий под названиями «Copy» и «Paste»… Основных источников тоже два: техническая документация программного обеспечения и предыдущий запрос, который окончился положительным решением.

Итак, обоснование IТ-проекта по большей части начинается со слов типа:

«Начиная с версии SQL Server 2005, SQL Server обеспечивает интеграцию с компонентами CLR платформы .NET Framework для Microsoft Windows. Это означает, что хранимые процедуры, триггеры, определяемые пользователем типы, определяемые пользователем функции, определяемые пользователем статистические функции и возвращающие табличные значение потоковые функции теперь могут разрабатываться с использованием любого языка .NET Framework, включая Microsoft Visual Basic .NET и Microsoft Visual C#».

Классическая первая реакция в таком случае: «Что?! Ты с кем сейчас разговаривал?».

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

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

Что я с этого буду иметь?

Пробившись через первые два вопроса, именно здесь очень часто застревают руководители проектов:

Во-первых, им кажется, что ответ на этот вопрос уже дан при обсуждении предыдущего «На что?» (Ответ был: «Мы будем иметь возможность использовать еще несколько языков», неужели не понятно?).

Во-вторых, в силу описанных вначале стереотипов говорить о какой-то финансовой выгоде как-то даже неудобно – все равно никто не поверит.

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

Следующие уровни

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

Почему мне нужно тратить на это деньги?
Почему именно на этот продукт?
Почему именно столько?
Почему именно сейчас?
Qui prodest (кому выгодно)?

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

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

Появление идеи

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

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

Наброски

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

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

Эскизы

Это попытка нахождения первых работоспособных вариантов перехода из точки «как есть» или «as is» в точку «как должно быть» или «to be».

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

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

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

Все это включено в понятие TCO – Total Cost of Ownership или Совокупная стоимость владения.

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

Прототипы

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

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

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

К чему эта аллегория? В процессе управления проектом, а изначально в запросе средств на его реализацию, важно понимать местонахождение «key milestones» или основных критических точек его выполнения. В зависимости от размера проекта и грамотности людей, принимающих решение, средства должны выделяться именно для достижения этих критических точек, а не на все сразу. Перед выделением очередного транша оценивается качество планирования и исполнения предыдущих шагов, а не просто «освоение» средств, как это принято в отечественной практике.

Картина маслом

И вот все оценили, прикинули, набросали. Результатом должен являться относительно окончательный вариант реализации проекта. Почему «относительно»? Возвращаемся к теме эстафеты. Результат предстоящего этапа в текущих погодных условиях и, исходя из своего физического состояния, спортсмен может оценить с погрешностью +/- 10%. Если говорить о соревновании, которое будет проходить через месяц, погрешность увеличится процентов до 25, через год – до 50%. Та же история и здесь – чем ближе к реализации конкретный этап или фаза проекта, тем лучше понимание руководителя о том, какие ресурсы понадобятся для успешного завершения этого этапа в текущей среде. А значит, тем больше доверия к его запросу на ресурсы у того, кто эти ресурсы выделяет.

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

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

Совершенно по-разному звучат заявления: «Мне нужно 400 тысяч рублей на автоматизацию системы документооборота в течении года» и «Мне нужно 50 тысяч рублей на оценку возможности автоматизации системы документооборота, которая займет около двух месяцев, после чего я представлю оптимальный вариант решения, на сегодняшний день оцениваемый в пределах от 300 до 500 тысяч рублей и который может занять от 8 до 14 месяцев. Данные цифры взяты из статистики вероятных поставщиков и подтверждены их прежними клиентами».

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

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

И все же об эффективности…

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

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

Вы: Повысится эффективность использования персонала.

Финансист: Когда, сколько и кого можно будет уволить?

Вы: Неизвестно, но по статистике подрядчика, основанной на мировой практике, сокращение затрат за первый год после внедрения составляет 10%.

Это хорошая фраза, которую стоит сразу включить в обоснование, но после все равно нее последует вопрос: «За счет чего?». Как правило, после этого вопроса наступает конец первого разговора...

Назрело уточнение. Повышение эффективности чего-либо возможно лишь двумя способами: рост отдачи и/или сокращение потребления ресурсов. Простейший принцип КПД. Рост в данном случае возможен, но маловероятен... Значит, концентрируемся на ресурсах, то есть затратах.

Сокращение затрат от внедрения IТ-проектов возможно в трех основных областях:

1) Высвобождение рабочего времени:

рост производительности рабочего места;
снижение объемов документооборота;

2) Избежание потенциальных рисков:

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

3) Стандартизация:

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

Собственно, возвращаясь к самому началу, искать обоснование стоит именно здесь. Грамотное начало запроса на финансирование IТ-проекта должно содержать три заявления:

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

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

Презентация (документ в PowerPoint).

Источник изображения: pixabay.com

Олег Зайковский Директор по развитию, Москва 22 августа 2013, 15:15

Владимир Зонзов пишет: Написал и подумал: в жизни-то - наоборот. Исполнитель делает как попало ...

То-то и оно. Доверия – никакого никому. Владимир Иванович, давайте поддержим эту «ветку» и далее: Вы, конечно, правы: «по идее», «в идеале» (А не как «просто НОРМА»!) Исполнитель в сфере IT вроде бы уж точно обязан знать потребности, нужды, ''бизнес-процессы предметной области'' Заказчика, но это да-ааа-алеко не факт в сфере IT. Кодеры-программеры ''бизнес-логику'' в грош не ставят. Им красота своего кода и собственная незаменимая и непризнанная гениальность - превыше всего, а что там на выходе у Заказчика - дело десятое, (раз плюнуть – «интерфейс» юзеру поправить). И в B2B сейчас тренд – если гора не идёт к Магомету, то Магомет сам идёт к… морю. Если Исполнители не будут досконально и дотошно разбираться во всех тонкостях бизнес-процессов и предметных областях Заказчиков, те самостоятельно – без особого труда, поверьте – сами разберутся во всех IT-прибамбасах и заморочках. Уже сейчас Майкрософт выпускает версию Visual Studio “Lightswitch” 2011, которая претендует на функции модульно-блочного конструктора Lego для бизнес-пользователей без знаний программирования, или 1С-Битрикс на Корпоративном портале: Пользователи сами могут менять бизнес-процессы простым «перетаскиванием», которые автоматом фиксируются в программном коде системы. «И все же об эффективности…» :)) Например, в такой «информационно-технологичной» сфере как туризм, и в малом бизнесе (а туризм на 80 и более процентов – «мал»), я, как Заказчик, просто обязан разбираться во всех новинках рынка и систем онлайн-бронирования, и «объединённых коммуникациях», и «корпоративных ERP-CRM», на уровне чёткого знания/понимания их программных платформ, архитектуры, функционала и возможностей настройки/кастомизации. Как и Исполнитель, имхо, должен также петрить в моих бизнес-процессах и предметной области (Волга впадает в Каспийское море и глобуса Украины НЕТ! а кнопка «забронировать» в онлайн-форме не равна по своим финансовым и бизнес-последствиям кнопке «ответить'' (как здесь на форуме) - просто спросить или ''по-бла-бла'' . Но они (Исполнители), вдруг!, начинают заново открывать для себя (и нас!) Америки и изобретать глобус Украины! (и не только в туризме), сами «от своей балды» мастеря наши бизнес-процессы! И многие рядовые сотрудники из обычных «турменеджеров» вполне сами в состоянии доучиться недоделанному - и контент на сайте поменять, и в базе данных формулы расчёта поправить для прайс-листов, и рекламные макеты подготовить, и даже самостоятельно прилепить к CRM возможности онлайн-звонков и видеоконференцсвязи. И никто от них не требует знания программирования на PHP, языка запросов SQL или прохождения авторизованных сертификационных курсов Adobe. А директор/владелец турфирмы вполне чётко себе представляет, как у него вся эта IT-байда работает: что фото отелей и курортов с описаниями у него на таком-то облачном хранилище, договора – там-то (в другом месте), что можно виртуализировать и загнать все офисные программные приложения на пару-тройку обычных «рабочих станций»-компов и превратить их в нормальные сервера – один «боевой», один «резервно-пожарный» и т.п. «Даже» GOOGLE, например, не покупает у IBM, Oracle, Cisco и т.п. готовых настроенных интегрированных решений с серверами приложений, системами хранения данных и ПО для управления сетевой инфраструктурой, (хотя бывают и очень неплохие наборы «всё в одном»). А покупает отдельно жёсткие диски и прочие комплектующее оборудование (и буквально! читал недавно, удивился, но понял смысл самостоятельности, независимости и стоимости!) сам «ручками, на коленке» лепит свои центры обработки данных. А что многим «наукоёмким» отраслям с «квалифицированными ПК-пользователями» мешает делать то же самое? Ни-че-го и никто. Поскольку «IT» - это уже неотъемлемая часть «бизнес-быта» и времена, когда приличные «сисадмины» были на вес золота и их дёргали через каждые пять минут «мышке коврик под хвостиком поправить» улетучиваются со свистом. Конечно, Заказчик не обязан сам «собирать шкаф» (хотя нередко и это он в состоянии), но знать – из каких частей и полочек он состоит и как можно лучше эти полочки использовать – для этого не надо заканчивать Ин-т радиоэлектроники и автоматики, и этим его знания и представления об «архитектуре ERP” или всей собственной IT-инфраструктуре могут ограничиваться. А позиции Исполнителей похожи на высказывание жены одного известного писателя на вопрос, читала ли она книги своего мужа: ''А зачем? А если бы он у меня был физик-теоретик?... Мне для того, чтобы с ним спать и обед готовить его китайская грамота совсем необязательна.'' Но если я, например, «переводчик с английского», то прежде чем давать мне текст на перевод, хорошо бы поинтересоваться, а в какой области я – «переводчик». И окажется, что я – переводчик поэзии, а не технической документации на МИГ-29. И если я даже переводчик медицинских рецептов, то к техдокументации на МИГ меня тоже нельзя и близко подпускать. Но если и у Заказчика такая же позиция, как и у Исполнителя, то мы в итоге и имеем, что таким «заказчикам», как чукчам, впаривают трубы от патефона (см. выше пример с типовым порталом для «муниципального образования» за 2 млн. при его реальной стоимости – порядка 20-50 тыс.-максимум, левой ногой небрежно, поскольку проверенных достойных готовых шаблонов и практик их массового внедрения – вагон).