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

— Начало года — время подвести итоги прошедшего периода. Каким стал для вашей компании 2011 г.? Всех ли поставленных целей удалось достичь?

Андрей Сыкулев: Прошедший год стал для нас вполне успешным с точки зрения достижения поставленных целей. Мы рассчитывали на рост бизнеса порядка 40%, и этих показателей нам удалось достичь. Количество клиентов также выросло. В 2011 г. нашими клиентами стали несколько крупных банков из числа лидеров российской банковской системы. Кроме того, нашими клиентами стали представители страхового бизнеса. Поставленные на год задачи выполнены.

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

— 40%-ный рост — неплохой показатель. Это больше, чем в среднем по рынку?

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

— С чем вы связываете свои успехи?

— Опять-таки за ответом лучше обратиться к заказчикам, которые пользуются нашими услугами. В целом, я думаю, наши результаты объясняются качеством предоставляемых услуг, общими впечатлениями заказчика от работы с нашей компанией, тем, что в международной практике называется better experience. Мы стремимся к тому, чтобы оставить наилучшие впечатления о работе с нами у наших партнеров.

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

— Изменились ли требования заказчиков к поставляемым решениям в последнее время? Наблюдаете ли вы новый подход к реализации IT-проектов в банках?

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

— Многие участники рынка автоматизации банковских процессов говорят о том, что компаниям-интеграторам, внедренцам IT-решений становится работать все труднее из-за изменившихся условий сотрудничества, как с поставщиками продуктов, так и потребителями конечных решений. С одной стороны, поставщики повышают цены на свои продукты, с другой — потребители стремятся максимально снизить свои расходы, опасаясь повторения кризисных явлений. Вы сталкиваетесь с такой проблемой?

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

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

Это объясняет наш интерес к стандартам, поскольку только таким образом можно обеспечить повторяемость решений.

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

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

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

— Кто в банке занимается разработкой соответствующих стандартов?

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

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

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

— Возможно ли решить этот вопрос за счет привлечения зарубежных специалистов, например, из США или Западной Европы?

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

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

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

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

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

— Некоторые из компаний-интеграторов в качестве одного из направлений своего развития рассматривают создание собственных программных решений. Компания «Синимекс Информатика» не планирует действовать в этом направлении?

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

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

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

— Вы упомянули о том, что современному банку нужно оперативно реагировать на изменения рыночной ситуации. Растут ли при этом требования к скорости реализации IT-проектов?

— Они растут по вполне объективным причинам. Эти требования всегда были достаточно высокими, и растут они вместе с развитием технологий. Если некоторое время назад приемлемым временем для реализации крупного IT-проекта был год, а то и два три года, то сейчас заказчики рассматривают в качестве приемлемого срока реализации 2—4 месяца.

Сроки более 9 месяцев практически не рассматриваются. Мир меняется гораздо быстрее, чем еще несколько лет назад, во всех сферах деятельности. Соответственно растут и требования к скорости реализации IT-проектов. Это естественный процесс.

— В свое время вы продвигали идею облачной интеграции в качестве подхода к внедрению IT-систем. Изменились ли ваши взгляды на перспективы таких решений?

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

Все правила обработки сообщений, включая пересылку сообщений в другие системы, ожидание и возврат ответных сообщений и т. п., настраиваются в «облаке». Такой механизм позволяет с максимальной степенью удобства и предсказуемости результата «интегрировать» любые системы, в том числе устаревшие (legacy), которые до сих пор широко используются во многих компаниях. Дополнительный «бонус» облачной интеграции — возможность настройки управления данными (data governance). Облачная интеграция — это централизация управления всеми связями, что особенно полезно, если банк планирует замену бэк-офисных систем.

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

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

— Кто в таком случае должен выступать идеологом IT-проекта: представители бизнес-подразделений, заинтересованные в извлечении максимальной прибыли, или IT-структуры, обладающие, возможно, более стратегическим взглядом на развитие IT-систем?

— Бизнесу и IT нужно работать вместе. Это жизненно необходимо для успеха компании. Нужно искать механизмы, которые позволят быстрее строить IT-решения и точнее их настраивать под потребности бизнеса. «Водопадная» технология, в которой до сих пор делается большое количество проектов, и в которой бизнес и IT работают последовательно (сначала бизнес формирует требования, затем IT «изготавливает» систему, а после этого бизнес ее получает на тестирование) — сегодня устарела.

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