ИСКУССТВО БЫТЬ ПОНЯТЫМ

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

Инвестиционный подход к оценке проектов внедрения специализированного программного обеспечения

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

Мы говорим на разных языках

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

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

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

Обычно необходимые для обоснования параметры получаются в результате расчета по так называемой методике дисконтированных денежных потоков (Discounted Cash Flow, DCF). B ИТ-сфере наиболее востребованы следующие из них — совокупная стоимость владения (Total Cost of Ownership, TCO) и возврат на инвестиции (Return on Investments, ROI); также может рассматриваться и величина чистой приведенной стоимости (Net Present Value, NPV) проекта [1, 2].

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

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

Язык доходов и затрат

Инвестиционные характеристики проекта (ROI, TCO, NPV) легко рассчитываются, если определены его затратные и доходные статьи.

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

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

Затратная часть стоимости большинства банковских ИТ-проектов обычно имеет схожую структуру. Более того, с некоторым допущением можно считать, что ТСО большинства собственных разработок и систем отечественных разработчиков приблизительно равна (при сравнимом документообороте, количестве рабочих мест, платформе). Такое утверждение опровергает бытующее в банковской среде мнение, что собственные разработки могут обойтись кредитному учреждению дешевле. Ведь в этом случае расходы не ограничатся заработной платой всех ИТ-специалистов, занятых написанием программ и поддержкой АБС. Кроме оплаты значительного количества человеко-лет, требуемых для создания полноценной банковской системы, сюда следует добавить стоимость используемого программного и аппаратного обеспечения, плату за аренду и содержание помещений, всевозможные накладные расходы и т. д. В результате окажется, что реальные затраты намного превышают ожидаемую сумму. Напротив, при приобретении АБС у профессионального разработчика ее себестоимость, то есть средства, которые были потрачены компанией-разработчиком на создание и продвижение системы, распределяется между его пользователями. Поскольку себестоимость продукта учитывается в его ТСО, можно ожидать, что при прочих равных условиях совокупная стоимость такой системы будет меньше, чем в случае «самодельной» АБС.

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

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

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

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

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

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

Сколько стоит возможность маневра

Рассмотренный подход, несмотря на то что его история насчитывает всего несколько десятилетий, по праву можно назвать классическим. Действительно, он де-факто стал нормой при обосновании целесообразности выделения средств для реализации любых проектов. Однако, как это бывает и в других областях человеческого знания, существуют эффекты, недоступные для классического описания. Так, расчет NPV и других аналогичных параметров выполняется при наличии единственного сценария развития проекта. При этом совершенно не принимается во внимание вмешательство менеджеров проекта в ход его реализации. В итоге это приводит к существенной недооценке стоимости проекта. Именно руководство должно учесть различные появляющиеся в ходе развития проекта возможности и реализовать их, опираясь на гибкость проекта. Этот недостаток позволяет исправить методика анализа реальных опционов (Real Options Analysis, ROA).

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

Расширенная чистая приведенная стоимость вычисляется как сумма классической чистой приведенной стоимости и стоимости реального опциона (Real Option Value, ROV).

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

Такую же картину можно увидеть и в реальных проектах, куда понятие опциона мигрировало из финансовой сферы, доказав свою эффективность. Рассмотрим проект по внедрению в организации программной платформы (операционной системы, СУБД, системы документооборота, информационно-аналитической системы, ERP и т. п.), на которой могут функционировать различные специализированные приложения, в том числе и те, использование которых не предусмотрено «классическим» сценарием проекта. При открывающихся возможностях, в частности при улучшении рыночной конъюнктуры, такие приложения могут с успехом использоваться, принося прибыль компании. С другой стороны, в случае ухудшения рыночных условий потери проекта ограничиваются ранее сделанными инвестициями в программную платформу. Финансовые потоки, генерируемые таким проектом, напоминают структуру выплат по финансовым инструментам, которые хеджированы соответствующим опционом.

Но каким образом рассчитать стоимость подобного реального опциона? Для финансовых рынков, характеристики которых отвечают ряду условий, очень удобно применение формулы Блэка-Шоулса-Мертона [3-5], за вывод которой ее авторам была присуждена Нобелевская премия по экономике. При расчете стоимости опциона по этой формуле аналитику не нужно строить гипотезы относительно, например, поведения цены актива в будущем. Ему достаточно лишь подставить в нее значения тех параметров, которые вычисляются на основе имеющихся у него исторических данных.

Можно предположить, что эта формула применима и к реальному сектору (см. таблицу).

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

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

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

Актуальность взаимопонимания

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

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

Думаем, такая методика для расчета стоимости гибкости подобных проектов на данном этапе развития бизнеса в России мало приемлема — в первую очередь из-за трудоемкости процесса этой оценки. Столь тонкие аналитические методики должны применяться как дополнение к традиционному подходу. Необходимо полноценно освоить нюансы классического инвестиционного описания и закрепить их на практике. И только затем переходить к использованию более «продвинутых» методик.

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

Литература

1. Липсиц И.В., Косов В.В., Инвестиционный проект, М.: БЕК, 1996.
2. Кляшторная О. Оценка ИТ-проектов: что выбрать? // "Директор информационной службы". № 6, 2003.
3. Black F., Scholes M. The Pricing of Options and Corporate Liabilities. // Journal of Political Economy, 1973, vol. 81.
4. Merton R. C. Theory of Rational Option Pricing. // Bell Journal of Economics and Management Science, 1973, vol. 4.
5. Cochrane J. H., Asset Pricing. Princeton University Press, 2000.
6. Боди З., Мертон Р. К. Финансы. М.: Вильямс, 2000.

Владимир Кузовлев — коммерческий директор департамента банковского ПО RS-Bank V.6 компании R-Style Softlab,Kuzovlev@softlab.ru

Владимир Угрына — менеджер отдела маркетинга компании R-Style Softlab, Ugryna@softlab.ru

Сопоставимые понятия финансового и реального секторов