В нашем банке вопросы подобных оценок не менее актуальны, чем в других. Почему? «Ренессанс Кредит» занимается розничным кредитованием, имеет точки продаж по всей стране. Все основные системы у нас централизованные, поддерживаются и управляются из Москвы, и от ИТ наш бизнес зависит самым непосредственным образом, поэтому вопросы оценки эффективности ИТ-проектов для нас крайне важны. Хотелось бы поделиться опытом такой оценки на примере проектов, проведенных в банке в последние год-два или же планируемых к внедрению.
Что нужно для оценки
В основе оценки эффективности лежит системный подход, без которого вряд ли может обойтись любая деятельность ИТ-менеджера. Поэтому для начала рассмотрим возможные цели внедрения. Они могут быть весьма разнообразны. Не претендуя на полноту, попробуем перечислить некоторые из них.
1. Снижение операционных издержек. В этом случае с помощью ИТ сдерживается рост расходов на персонал, повышаются скорость и точность исполнения операций. В качестве простейшего примера можно привести внедрение системы автоматизации бухучета с нуля. 2. Выпуск на рынок нового продукта. Например, если вы задумали эмитировать пластиковые карты, вам для учета карт и операций по ним понадобится соответствующая информационная система.
3. Создание условий для выпуска новых продуктов. Это нечто совершенно отличное от предыдущего. Для реализации такой цели недостаточно внедрить какие-то приложения. Для быстрого выпуска продуктов сама архитектура ИТ-систем должна быть гибкой, способной к адаптации. Решением может быть построение SOA.
4. Повышение качества и скорости обслуживания клиентов. Всем известно, что недовольный клиент о своём негативном опыте расскажет как минимум десятку других потенциальных клиентов. Достичь большей удовлетворенности можно, например, за счет повышения пропускной способности вашей информационной системы, что в свою очередь складывается из разных составляющих, начиная от каналов доступа в Интернет и заканчивая переделкой архитектуры прикладных систем.
5. Поддержка увеличивающейся доли рынка. Эта цель выглядит довольно просто, но нередко упускают из виду, насколько существенно ИТ-системы могут влиять на возможность расширения бизнеса. Например, если пропускная способность вашей ИТ-системы составляет пять тысяч операций в день, то сколько бы вы ни увеличивали число филиалов, сколько бы ни давали рекламы, больше операций вы сделать всё равно не сможете — только очереди недовольных клиентов вырастут, а репутации будет нанесен урон. Бизнес лишь понесет убытки, а ваша доля рынка не увеличится.
6. Улучшение качества управленческих решений. Это может касаться как стратегического управления, так и создания, например, моделей оценки кредитоспособности, используемых в ежедневных операциях.
7. Выполнение требований регулирующих органов. Одна из самых распространенных наших задач. Неисполнение этих требований может привести к отзыву лицензии на совершение банковских операций.
8. Уменьшение совокупной стоимости владения. Например, если оборудование в течение года загружено неравномерно и есть ярко выраженные немногочисленные пики, имеет смысл рассмотреть возможность его аренды на условиях выделения вычислительной мощности по требованию и таким образом снизить совокупные расходы на поддержку.
После того как цели будут определены, нужно сформулировать, по каким критериям можно оценивать их достижение. Несмотря на кажущуюся очевидность этого этапа, здесь зачастую возникают весьма суровые препятствия. Одно из них — явное или скрытое нежелание оценивать результат. В такой ситуации дальше просто не о чем говорить. Если же потребность в оценке все-таки есть, то для того чтобы она была адекватной, необходимо выполнить еще несколько условий.
Прежде всего нужна связанная с бизнес-стратегией ИТ-стратегия, иначе неясна будет общая ценность достигнутых результатов. Не менее важен формализованный проектный подход. Следование ему позволяет видеть проект целиком от бизнес-кейса до оценки результатов в отчете о завершении работ. Уверенный системный менеджмент в ИТ и вытекающая из него системность оценок позволят рассмотреть картину в целом. Ведь внедряя одно приложение, мы можем получить целый букет результатов, не всегда прямых. В ряде случаев можно посчитать эффект применения ИТ напрямую — например, внедряя систему скоринга при выдаче кредитов, вы снижаете риски их невозврата на вполне определенную величину. Но оценка прямого результата не всегда возможна или может быть недостаточно полной, и в таких случаях нужно рассматривать косвенные результаты. Например, увеличение пропускной способности информационной системы приведет не только к росту продаж, но и к большей удовлетворенности клиентов и партнеров за счет уменьшения времени ожидания.
Еще один способ оценки эффективности ИT-проектов — оценка рисков. Допустим, ваш банк выдает пять тысяч кредитов в день, сто долларов с каждого — ваш доход. (Все цифры совершенно условные.) При этом в силу разных обстоятельств в месяц набегает один день простоя, который обходится в 500 тысяч долларов. Но если внедрить внешний сервис поддержки приложений, то появляется возможность снижения времени простоев вдвое. Тогда за него можно заплатить 250 тысяч и даже не торговаться, так как будут еще и косвенные результаты в виде возросшей удовлетворенности партнеров в устойчивости работы. Но, конечно, это всего лишь подход к оценке, в реальности всегда нужно учитывать множество других факторов для определения истинной цены.
Оценить эффективность можно и через стоимость компании, хотя и это не очевидный путь. На мой взгляд то, что многие российские банки сейчас принялись внедрять западные системы, — не всегда оправданно. Ни одна западная система в наших условиях так, как было задумано ее разработчиками, работать не будет. Некоторые банки их уже используют, но это стоит огромной крови. Либо западная система должна работать в паре с российской. При оценке таких проектов, возможно, целесообразней смотреть на рост капитализации, а не на операционный эффект от внедрения. Такой же эффект может дать сертификация ISO 9001.
Примеры оценки эффективности
Предположим, ваш банк имеет какой-то уровень потерь от мошенничества при выдаче кредитов. Уменьшить эти потери на вполне прогнозируемую величину можно с помощью системы предотвращения мошеннических операций, задействованной при выдаче кредитов. Для оценки эффективности от её внедрения придётся учесть стоимость лицензий, оборудования, консалтинга, интеграции, всех видов поддержки и расходов на персонал. Соотнести все это нужно с сокращением потерь от невозврата кредитов за счет использования экспертной системы. В данном примере можно вполне точно просчитать бизнес-кейс и оценить фактические результаты, сравнив полученные бизнес-показатели с периодом до внедрения системы при условии, что параллельно не внедрялся другой функционал, приводящий к аналогичным эффектам.
Рассмотрим другой пример. Оценить комплексный проект, такой как внедрение интеграционной платформы или хотя бы её центрального компонента — шины данных (ESB), может быть особенно сложно. Первый шаг, как мы и договорились выше, — сформулировать бизнес-цели проекта.
В данном случае целей несколько. Во-первых, возможность постепенной замены отдельной бизнес-системы на новую без остановки бизнеса. Во-вторых, поддержка требуемых объемов бизнеса. В-третьих, возможность выпуска комбинированных продуктов. И это далеко не полный список.
От перечисленных бизнес-целей можно переходить непосредственно к целям ИТ, хотя это всего лишь взгляд на бизнес-цели через призму информационных технологий. Здесь на первом месте стоит построение надежной и управляемой среды взаимодействия приложений. На втором — сокращение расходов на последующую интеграцию. Затем появятся широкие возможности для мониторинга бизнес-процессов. И наконец гибкость архитектуры. Подключать новые приложения можно будет чуть ли не в режиме онлайн. При этом мы сможем для каждой задачи в рамках исполнения основного бизнес-процесса выбирать информационные источники из числа подключенных к шине и переключать их на ходу. И это еще не всё, что дает интеграционная платформа.
Выбрать критерии достижения целей для такого проекта — задача нетривиальная. Первое, что приходит в голову, — оценивать общую производительность информационных систем, рассматривая как непосредственные показатели, так и возможность ее увеличения. Очевидно, что нужно сравнивать положение до и после внедрения платформы. Зачастую, однако, такая прицельная оценка невозможна ввиду того, что в организации могут идти многие другие проекты, как внедренческие, так и организационные. В этом случае нужно попытаться определить, какую долю проект внедрения интеграционной платформы вносит в общий результат. Например, используя возможности шины данных, мы перешли от синхронного обмена сообщениями с автоматизированной банковской системой к асинхронному. В результате пропускная способность системы увеличилась на тысячу кредитов в сутки. Нетрудно посчитать, что расходы на проведение этой доработки в данном случае окупаются за один рабочий день.
Другой способ оценки заключается в аллокации части эффекта от внедрения прикладной системы на интеграционной платформе. В данном случае совсем не очевидно, по каким правилам определять эту долю, ведь интеграция приложений с использованием шины данных менее трудоемка, чем без нее. Следовательно, по трудозатратам долю определять нельзя и нужно принимать какие-то иные алгоритмы.
Самым очевидным и одновременно самым трудным для (высококачественного) расчета является сравнение вариантов интеграции point-to-point с вариантом использования ESB. По собственному опыту мы можем сказать, что больше пяти систем интегрировать без шины данных не имеет смысла.
Практика эксплуатации созданного нами интеграционного решения показала, что действительно применение ESB позволяет быстро подключать новые приложения. Каждый следующий «раунд» интеграции, подключение каждого нового приложения действительно обходится дешевле предыдущих. Что касается создания «надежной и управляемой среды взаимодействия», то это достигается широкими стандартными возможностями масштабирования, высокой отказоустойчивостью индустриальных решений, широкими возможностями мониторинга, применением стандартных технологий (например, Java).
Рассмотрим другой пример — внедрение процесса управления мощностями (capacity management). Оценить эффективность такого проекта можно только через риски. Бизнес-задачей в этом случае будет создание плана управления емкостью информационной системы. План должен соответствовать показателям бизнес-плана по количеству транзакций.
В качестве критериев оценки можно выбрать разнообразные риски — сбоев и замедления обслуживания клиентов, закупки ошибочного оборудования и лишних лицензий и т. д. и т. п, список здесь может быть весьма обширен. Например, не имеет смысла покупать тысячу лицензий на рабочие места бизнес-системы, если система не справится с таким количеством пользователей. Другими словами, имея оценку емкости информационной системы, можно сэкономить огромные деньги и направить их на поиск альтернативного решения для доступа к информации.
Ещё пример. Допустим, вы покупаете сервер за 500 тысяч долларов США. Однако через полгода понадобится его модернизация стоимостью 300 тысяч, которой хватит еще на полгода. В то же время можно было приобрести сервер достаточной мощности за 700 тысяч (сэкономив таким образом 100 тысяч), которого хватит на больший период времени. Или, скажем, в случае превышения допустимой нагрузки работа информационной системы может замедлиться, что приведет к очередям клиентов, неудовлетворенному спросу, недовольству клиентов и партнеров. И всё это можно оценить. Вот алгоритм решения подобных задач со стороны ИT и должен предложить процесс управления мощностями.
Оценить стоимость внедрения процесса можно с учётом прямых расходов на дополнительные компоненты (мониторинг, тестовые среды и т. д.) и их поддержку, стоимости контрактов. Потребуется также учет трудозатрат персонала на поддержку процесса. Для этого придется построить систему учета рабочего времени, которая позволит сделать ИТ-службу более управляемой в целом.
Заключение
Можно ли вообще так считать? Практика показывает, что можно, мы сами так делаем, когда есть необходимость. А часто ли так считают? Насколько мне известно, нет. Надо ли всегда считать? Думаю, тоже нет. Например, зачем считать каждый отдельный подпроект в рамках запуска стартапа, рассчитанного на год? Перейти к детальной оценке эффективности имеет смысл после того, как установится нормальная операционная деятельность. Другими словами, нет универсального рецепта, есть только подходы. В каждой конкретной организации будет своя специфика, равно как и в каждом конкретном проекте.
И последнее: данная статья не претендует на безусловную точность с финансовой точки зрения, это скорее дополнение, показывающее подходы к комплексной оценке проектов.
