Для начала нужно оговориться – инвестициями в сферу информационных технологий обычно считаются и смешиваются между собою четыре основных варианта:
- инвестиции производственной/торговой компании в автоматизацию и/или оптимизацию своей деятельности
- инвестиции 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
Кирилл, глянул Вашу презентацию.
А на какое время был рассчитан Ваш питч к ней?
Хочется пожелать автору поглубже ознакомиться со спецификой, современными сводами знаний и опытом ведения ИТ - проектов. Материал публикации настолько устарел и настолько ''заужен'' в тематике, что даже комментривать не хочется. Одно TCO чего стоит: от этого показателя отказались лет 8 назад, а если и используют, то только для конкретной среды и вместе с другими показателями... И задача ИТ - не снизить затраты, от этого отказались еще в 90-е. Одно и радует и печалит - качество материала отражает степеь грамотности большинства руководителей и, как выяснилось, консультантов. Какая уж тут модернизация, оптимизация и инновация... Вот и работа профильного министерства вызывает подобные эмоции и чувство глубокой грусти.
Прочитала статью. И комментарии к ней).
Хорошая статья!)
Для работы с компаниями, у которых деньги есть, необходимость развития есть, а штатной службы IT нет - вполне хороший пример того, что нужно учитывать при общении с Заказчиком. Не считать его идиотом, не сыпать ''научными'' терминами, а уметь понятно объяснить. Особенно полезна в этом плане первая часть статьи - про ''первый уровень''. Вторая часть не так интересна).
Не обязаны ни директор компании, ни остальные сотрудники разбираться в новинках IT технологий, если у них другая специализация). Сама в таких компаниях работала и, как самая коммуникативная и терпеливая, с IT-шниками общалась). Хотя, надо признать, учатся все-таки объяснять понятно))). А так - да, сначала объясняли мне, а потом я руководству))). При этом хорошо бы сначала хоть немного изучить специфику бизнеса, а то были случаи, когда предлагали совершенно ненужное и удивлялись: ''Как не подходит, у вас же тоже продажи?!'')))
В компаниях, где есть IT-департамент/отдел и т.д. - только для объяснения владельцам/руководителям, которые от этого далеки). Но в таких компаниях, скорее всего, уже есть свои методы). Для общения с IT директором и ''продажи'' ему - пожалуй, лучше говорить языком цифр и проф. терминов). Но ''в руках не держала'', а фантазировать не буду).
Что касается критики, мол старо, узко и т.д. - по-моему это те, кто или работает в компаниях в IT-подразделении и не знает, что бывает иначе)), либо предоставляющих IT-услуги, но не непосредственно с компаниями без штатного IT-специалиста, либо просто умничают))).
PS: прочитала Ваши комментарии и решила перечитать статью еще раз, видно во второй части что-то сразу не уловила).
Наталья, спасибо за поддержку. С одним ''но'' - статья базируется именно на опыте крупной компании с большим собственным штатом ИТшников. Но извечная проблема именно в том, что они, как и производственники, ''варятся в собственном соку'' и искренне не понимают, почему им отказывают в финансировании, когда ''очевидно же'', что (на примере моей отрасли) бурить надо!