Во взаимоотношениях ИТ и бизнеса, ИТ‑департамента с функциональными подразделениями нередко возникают барьеры. О том, как их преодолеть, о связи ИТ‑стратегии со стратегическими целями бизнеса рассказывает Алексей Телятников, директор департамента информационных технологий банка «Связной».

Intelligent Enterprise: Как изменения бизнес‑стратегии сказываются на стратегии ИТ?

Алексей Телятников: Давайте сначала разберемся в термине «изменения бизнес-стратегии». Чаще всего у компании есть общая стратегия, определяющая, куда идет компания, и со временем она лишь уточняется. Такие уточнения часто трактуются как изменения стратегии, но это всего лишь уточнения.

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

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

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

Когда мы строим или арендуем офис, мы знаем, что у нас будет работать 1000 человек, на каждого нужно 10 кв. м. Если решено занять офис категории В+, то аренда одного метра, условно говоря, будет стоить 400 долл. в год. Умножили цену на число метров — получили бюджет. Все просто и понятно.

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

Гартнер называет это «total cost of ownership», Каплан употребляет термин «activity based hosting». Но на самом деле это все тот же советский функционально‑стоимостной анализ 1948 г., или даже сметное дело, придуманное еще в середине XIX в. Именно тогда Александр II утвердил образцы метрик типа «сколько стоит пуд земли на одной подводе, перевезенный на одну версту». Это было необходимо при постройке крепостей по всей России для сравнения стоимости работ. Такого рода общепринятых метрик в ИТ до сих пор практически нет. И именно их отсутствие рождает непонимание при планировании бюджетов: вроде бы лишь немного поменялся только один показатель, а ИТ сразу требует сильно увеличивать бюджет.

Почему же нет стоимостных метрик? Когда они появятся и что для этого нужно сделать?

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

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

Над обычным ИТ-директором висит куча проблем, весьма конкретных и срочных, и до разработки метрик у него просто руки не доходят. Разложить ИТ-бюджет любого банка в такие метрики, если этим позаниматься прицельно, совсем не сложно. И поэтому сегодня в сообществе ИТ-директоров мы вместе решаем эту проблему. Я сам тоже занимаюсь этим в клубе 4CIO.

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

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

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

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

Вопрос использования ценовых моделей принципиально очень важен. Применяя их, мы начинаем говорить с бизнесом на одном языке. Я говорю им: «Ребята, если мы вложим деньги вот в это устройство, то снизим издержки на одного клиента на столько‑то». Я объясняю модель. И меня понимают. Это один из способов преодоления барьеров между бизнесом и ИТ.

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

Тем не менее хочу подчеркнуть, что это все равно процесс, а не единожды решенный вопрос. Мы пересматриваем эти стандарты регулярно. Мы понимаем, какие у нас есть перспективы роста с точки зрения технологических показателей, и по­следовательно вместе с бизнесом вырабатываем план, как именно эти показатели будут обеспечиваться, делаем все затраты прозрачными. Сколько тот или иной рубеж будет стоить банку? Это не одноразовая задача, и нельзя ее решить одним махом.

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

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

Помогают даже очень грубые оценки. Скажем, на работу шины нам требуется восемь процессоров. Один работает на передачу сообщений, а все остальные — на обслуживание базы данных. А что случится, если мы не будем вести журнал этих сообщений? Что мы потеряем, как будем восстанавливать работоспособность системы в случае сбоя? У нас есть копия базы, она работает, и вообще‑то этот лог нам не нужен. Если мы обрубаем лог-файл, то сколько мы сэкономим процессоров и места в системах хранения? Нам потребуется уже не терабайт, а всего лишь сотня гигабайт. И при построении ресурсной модели мы видим, где еще могут потребоваться высвобожденные таким образом ресурсы. Мы работаем по всей стране в режиме 24×7, у нас два дата-центра, мы постоянно анализируем их загрузку и следим за стоимостью всех используемых ресурсов, стараясь ее оптимизировать.

Собственно, в этом смысле ИТ не особенно отличаются от любой другой предметной области. Есть только два принципиальных отличия. В нашей работе много сложных для оценки стоимости объектов и быстрые изменения. Эти быстрые качественные изменения заставляют людей менять менталитет. Общепринятой ста­ла точка зрения, что для обеспечения надежности нет лучше средства, чем реляционная база данных. Их теперь используют для чего угодно, только вот стулья по коридору не возят на них. Но ведь на самом деле есть масса технологий, которые для определенных задач не хуже, а намного лучше этих баз. Скажем, ни одна телефонная станция реляционных баз не использует. Она построена по другим принципам. Банк же использует для обработки карточек только реляционную базу, считается, что работать можно так и только так. А можно ведь сравнить другие подходы с общепринятым, посчитать стоимость операций и задаться вопросом: а мы вообще‑то ту технологию применяем? Оптимальную ли?

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

На что можно опереться при построении стоимостных моделей? Есть ли на рынке услуги внешних аудиторов, способных в этом помочь?

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

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

Насколько формализованы ваши отношения с функциональными подразделениями? Как меняются SLA со временем?

У нас есть формальные SLA c бизнесом, где определены доступность систем, время выполнения определенных операций. В стратегии банка описано, как мы будем ужесточать SLA со временем, и это уже происходит. По ряду сервисов нужна надежность «две девятки», и идут работы над обеспечением уровня «99,9». Для некоторых сервисов потребуется и четвертая «девятка», а то и пятая. Но каждый переход базируется на оценках необходимости такого уровня надежности.

Есть и другая сторона стратегических требований. Вопрос может ведь стоять и иначе: при неизменном уровне SLA снизить стоимость его обеспечения. Мы идем и по этому пути. Это именно так и должно быть. Ведь ясно, что нельзя каждый год на 10% снижать стоимость рабочего места. Появляются новые потребности, новый функционал, новые объемы данных. При этом вы не снижаете стоимость, а при прочих равных увеличиваете объем функционала, предоставляемого сотруднику. Есть области, где снижение возможно: каналы связи, например, дешевеют на 10—15% в год. Эти параметры вы должны закладывать в ценовую модель, учитывая и взаимоотношения с поставщиками, и те сервисы, которые вы даете бизнесу. Возможно, то, что невыгодно сейчас, в результате таких прогнозируемых изменений цен станет выгодно через год-другой. Иначе можно разработать прекрасные решения, элегантные с точки зрения ИТ, но совершенно невыгодные экономически.

Наша компания в первую очередь ориентирована на сервис для клиентов. Поэтому ITIL, сервисы, обработка инцидентов — для нас основа работы, причем понятная для бизнеса. Есть ежедневные отчеты по инцидентам в критичных для бизнеса сервисах. Это очень детальный отчет, с указанием вовлеченных в инцидент других сервисов и исполнителей, времени, характера сбоя, принятых мер. Мы постоянно боремся за то, чтобы время простоев было как можно меньше, чтобы уже совершенные ошибки не повторялись, и все это позволяет выявлять системные проблемы и устранять их, а не следствия.

Каким образом вы координируете проектные и сервисные работы?

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

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

Таким был подход к ИТ в банке с самого начала. Есть приоритеты, связанные с разработкой новых продуктов и увеличением клиентской базы. Сейчас она растет более чем на 3 тыс. клиентов в сутки. Наш главный канал распространения — центры мобильной связи «Связной». Поэтому мы стараемся обеспечить максимальный уровень сервиса для клиента, опираясь на уровень сервиса наших партнеров. Мы быстро растем, предоставляем клиентам очень качественный сервис и при этом внимательно считаем, сколько он стоит с точки зрения технологических расходов.