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

Intelligent Enterprise: Как вы считаете, переход на SOA — задача сугубо техническая, или же здесь необходимо задействовать бизнес? Кому это больше нужно, ИТ-отделу или бизнес-подразделению?

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

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

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

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

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

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

SOA — довольно размытое понятие, не имеющее даже общепринятого определения. Что в него вкладываете вы?

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

Можете ли вы привести какие-то примеры из своей практики взаимодействия с бизнесом в качестве ИТ-директора, когда использование SOA помогало разрешить возникающие вопросы?

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

ИТ-отдел: «Мы хотим предложить вам гораздо более подходящее решение, чем есть сейчас». Бизнес: «Нам хотят предложить очень “продвинутую” технологию, которая поможет им решать их проблемы. А отвечать-то нам».

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

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

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

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

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

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

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

Прикладная архитектура SOA — это не система и даже не технологическая архитектура, это прежде всего бизнес-архитектура. Если ИТ-отдел и бизнес это сознают, то проблем во взаимопонимании гораздо меньше.

ИТ-отдел: «Нам необходимо протестировать прототип новой ИС».

Бизнес: «Они нам сейчас что-то там сделают на скорую руку, а нам потом мучиться».

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

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

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

Бизнес: «Компания N ознакомилась с нашими бизнес-процессами и бизнес-приложениями, они рекомендуют комплексное решение».

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

Бизнес: «Мы не успели выполнить некоторые операции, потому что ИТ-подразделение работает не так, как надо». ИТ-отдел: «Непонятно почему, но они не смогли закончить операцию. Им проще всего переложить проблемы на ИТ-подразделение. Все равно — проблема сложная, и никто не разберется, кто прав, кто виноват».

Пути решения этой проблемы — визуализация и объективизация ситуации. В девяти случаях из десяти внедрение SOA и эффективных показателей бизнес-процессов успешно её решают. При этом ситуация становится наглядной как для ИТ-отдела (в том числе с точки зрения управления ресурсами), так и для бизнеса (что обеспечивает средство мониторинга показателей и в конечном счете управления бизнес-процессами).

Как вы считаете, с чего нужно начинать процесс внедрения SOA?

Прежде всего нужно ответить для себя на несколько вопросов.

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

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

Какие информационно-технологические активы мы можем при этом использовать? Какие новые компоненты нам понадобятся? Может оказаться, что они и вовсе будут не нужны.

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

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