Управление изменениями как основа конкурентного преимущества

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

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

Баланс развития и функционирования

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

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

Если говорить об изменениях, источником которых выступает бизнес, то для любого банковского продукта или сервиса можно выделить (с определенной долей обобщения) четыре основные стадии жизненного цикла:

• формирование рыночного предложения: формулирование условий, расчет доходности, формирование портрета потенциального клиента и т. д.;

• подготовка к продаже: изменение (внедрение) процессов и инструментов для обеспечения продажи и обслуживания продукта;

• продажа: массовое заключение договоров с клиентами;

• обслуживание: операционная обработка сделок в соответствии с условиями договоров и требованиями регуляторов.

Очевидно, что основа конкурентного преимущества на динамичном рынке закладывается на фазах 1 и 2 (условно их можно назвать «зоной развития»), а на фазах 3 и 4 (которые составляют «зону эксплуатации») достаточно поддерживать заданные нормы эффективности.

Службы банка при этом испытывают на себе воздействие двух разнонаправленных, но равномощных установок:

• с одной стороны, необходимо обеспечивать требуемый темп и масштаб изменений (то есть давать возможности для развития);

• с другой — важно обеспечивать бесперебойное обслуживание ранее заключенных договоров (то есть поддерживать функционирование).

В разрезе ИТ деятельность по этим направлениям ведется одновременно на одном и том же «материале» (к которому относятся, в частности, ИТ-системы). То есть развитие и функционирование находятся в постоянном антагонизме, и данное противоречие невозможно разрешить. Но можно поставить под управление.

Таким образом, изменения становятся самостоятельным объектом управления, а одним из направлений деятельности банка в сегменте розничного бизнеса становится выстраивание «конвейера», обеспечивающего их проведение на всех стадиях жизненного цикла продукта (сервиса).

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

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

Взгляд сквозь призму архитектурных уровней

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

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

• Информационная архитектура (ИА) задает состав информации, способы ее представления и обработки, обеспечивающие выполнение бизнес-функций, формируя тем самым информационную модель предметной области, включающую в себя модели информационных объектов, их взаимного влияния и действий над ними.

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

• Технологическая архитектура (ТА) определяет, какие технологии в части аппаратного обеспечения, системного программного обеспечения, сетей и каналов связи необходимы для создания среды работы приложений уровня АП.

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

Это означает, что на уровне ИА каждый бизнес-замысел может быть оценен с точки зрения:

• оптимального способа реализации (с помощью ИТ, организационными мерами и т. д. — к примеру, нередко то, что безуспешно пытаются решить доработкой ИТ-систем, можно более эффективно реализовать перераспределением полномочий между подразделениями банка);

• масштаба изменений (и, если они связаны с IТ, — степенью влияния изменений на ИТ-ландшафт банка);

• корреляции с другими проектами (посредством изменения информационных моделей одних и тех же объектов или посредством их взаимных блокировок при реализации);

• выявления скрытых зависимостей в изменениях (когда, например, условия нового продукта влекут изменения за пределами подразделения, в котором он обслуживается);

• обнаружения потенциальных возможностей как синергии нескольких изменений.

Каким образом слой ИА реализуется на  практике? В подавляющем большинстве случаев структура финансовой организации проектируется исходя из текущих бизнес-целей и существующих шаблонов best practice. Ни один из известных способов организации не выделяет работу с ИА как самостоятельную деятельность, а, следовательно, соответствующие ИА функции выполняются фрагментарно в нескольких организационных единицах.

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

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

«Технологизация» развития: первые шаги

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

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

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

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

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

---

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