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

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

Кубики сервисов

Сегодня сложно сказать, откуда пришла идея сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) — из бизнеса или из ИТ. Например, сервис-ориентированная структуризация бизнеса пластиковых карт, возможность выделения услуг обслуживания пластиковых карт и продажа другим банкам услуг обслуживания появились далеко не благодаря, а скорее вопреки присутствию ИТ в этом сегменте. Другим ярким примером реструктуризации бизнес-процессов и выделения бизнес-сервисов являются не так давно появившиеся бюро кредитных историй, которые ведут кредитные истории заемщиков и по запросам предоставляют банкам соответствующую информацию. В процессе обработки кредитной заявки и принятия решения о выдаче кредита банк может направить запрос в одно или несколько бюро кредитных историй. Информация о заемщике, полученная из бюро, влияет на скоринговый балл, который формируется на основании множества параметров. Отметим, что такой сервис предоставляется банку внешней компанией и является платным. Этот факт должен учитываться при проектировании бизнес-процессов, связанных с обработкой кредитных заявок. Ряд функций очевиден. Например, до отправки запроса в бюро целесообразно проверить информацию, уже имеющуюся в банке. В том числе наличие кредитов у заемщика в банке, наличие у заемщика перед банком просроченной задолженности по текущим кредитам. Но гораздо больше здесь менее очевидных решений, связанных, например, с возможной частичной или полной потерей связи с бюро. Банк должен решить, готов ли он нести риски принятия решений из-за неполной информации, будет ли в этом случае процесс принятия решения и выдачи кредита по-прежнему сквозным и непрерывным. Если будет, то с какими ограничениями. Или, скажем, банк может приостановить процесс кредитования до возобновления связи с бюро. Это решение может распространяться на заявки, сумма кредита которых превышает определенную величину. Таким образом, проектирование бизнес-процесса подобно конструированию, то есть собирается из типовых блоков сервисов, «устоявшихся» в банке или предоставляемых внешними компаниями. После подобной «сборки» целесообразно выполнить имитационное моделирование для оценки сходимости, устойчивости и производительности процесса, оценки рисков, расчета себестоимости той или иной услуги — ведь только на основании точного расчета этой себестоимости банк может принять решение о величине тарифа на ту или иную услугу.

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

Аналогии проектирования

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

Безусловно, все эти виды работ при проектировании бизнес-процессов выполнялись и прежде. Неправильно утверждать, что раньше не было ни технологических карт, ни функционально-стоимостного анализа. Но чего не было точно — так это структуризации бизнеса, бизнес-сервисов как устоявшейся последовательности бизнес-операций, повторяющейся и используемой в различных бизнес-процессах. Посмотрим хотя бы на методологию IDEF или предшествующую ей методологию SADT, которая возникла в конце 60-х годов прошлого столетия в ходе революции, вызванной структурным программированием. Структурный анализ зародился на уровне бизнес-архитектуры и ставил задачи структурной декомпозиции функционала проектируемой системы; при этом зрелость программной индустрии все еще находилась на уровне структурного программирования. Однако в то время, в период становления структурного анализа, еще не шло никакой речи ни об объектном программировании, ни тем более о сервисах на уровне программирования. Даже спустя почти двадцать лет после появления методологии SADT в предисловии к известной книге «Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique)», написанном в 1986 году Дугласом Т. Россом, говорится о функциональном моделировании, но о сервисах речь не идет. Спустя еще десять лет, в 90-х годах, в методологии ARIS была сделана слабая и неуклюжая попытка ввести типизацию услуг и операций при реализации продукта, что находит отражение в матрице продуктов-сценариев. Однако эта попытка заканчивается на верхнем уровне — уровне матрицы. На нижнем уровне — уровне декомпозиции — все сценарии различаются, и каждый имеет свое описание и реализацию.

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

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

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

Проектирование XXI века

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

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

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

Виктор Галактионов — главный системный архитектор АКБ «РосЕвроБанк»; V.Galaktionov@roseurobank.ru