Задачка для банкира

Если бы банки применили свои методы управления деньгами для управления собственной IT-инфраструктурой, они могли бы неплохо сэкономить.

Наверное, любой IT-директор, если спросить его об отношении бизнес-подразделений компании к IT-департаменту, сможет описать его коротко: "Давай-давай!" Что, в общем-то, логично: IT - сервисное подразделение, основная цель которого - обеспечивать бесперебойное решение бизнес-задач.

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

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

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

С точки зрения IT-активов, такая логика работает далеко не всегда. Вот две недавние истории из практики крупных банков.

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

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

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

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

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

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