Характеристики устойчивой архитектуры для выполнения законодательных требований и повышения эффективности бизнеса

В материале речь идет о том, как создать архитектуру управленческой системы,
которую можно одинаково успешно использовать как для выполнения различных
нормативных актов (Базельские соглашения, МСФО и т.д.), так и для повышения
эффективности бизнеса.

С точки зрения IT управление эффективностью бизнеса (ВРМ) и управление выполнением нормативных требований ведут различную, но нераздельную жизнь. То, что их соединяет - это различные риски и данные.

Традиционные показатели эффективности, такие как ценность клиентов, непогашенные остатки, безнадежный долг, оценка собственности и фондовых опционов, представляют интерес как для менеджеров, так и для инвесторов, а, следовательно, и для законодателей. Во многих случаях ключевые показатели эффективности (KPI), используемые в ВРМ, и ключевые показатели рисков (key risk indicators, сокр. KRI), используемые в системе индикаторов Базельских соглашений, фактически являются синонимами. Кроме того, любой тип этих показателей может напрямую отражать общий контроль финансовой отчетности - непосредственный признак требований закона Сарбаниса-Оксли (Sarbanes-Oxley Act).

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

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

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

Согласование этих потребностей в гибкости в рамках отчетливой интегрированной архитектуры, которая может поддерживать как выполнение корпорацией нормативных требований, так и ВРМ, является непростой задачей. Стандартные проекты интеграции корпоративных приложений (EAI) обычно оказываются слишком медленными, дорогими и негибкими для поддержки нормативной отчетности на протяжении продолжительного периода времени. Нормативные акты меняются быстрее, чем можно написать новый код, поэтому следование постоянно обновляющимся требованиям таких актов, как закон Сарбаниса-Оксли, быстро становится слишком дорогим и сложным процессом. Кроме того, до настоящего времени в большинство усилий по выполнению нормативных требований вообще не включали косвенные KPI - например, KPI, связанные с системами управления отношениями с клиентами (CRM) или цепями поставок (SCM), которые являются центральными для ВРМ. Любая общая архитектурная структура должна как минимум выполнять следующие задачи:

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

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

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

В целом все эти показатели могут быть обобщены в форме пяти основных характеристик:

1. функциональная совместимость, основанная на стандартах разработок (например, XML, XBRL¹, FpML², MDDL³ и т.д.), а также сервисов и систем сообщений, не зависящих от типа архитектуры;
2. быстрая разработка на базе упрощенных проектов, основанных на бизнес-целях, на уровне отдельных подразделений;
3. модульный дизайн: простые повторяемые процессы, к которым можно обращаться, комбинировать их и повторять по мере необходимости (принцип игры Лего);
4. контроль на уровне интерфейсов: ключевые системы остаются в безопасности;
5. стандартизованные очищенные данные без повторов, лежащие в основе.

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

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

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

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

[1]Расширяемый язык бизнес-отчетности. (прим. переводчика).

[2]Язык разметки финансовых продуктов. (прим. переводчика).

[3]Язык определения данных о рынках. (прим. переводчика).

Автор: По материалам зарубежных сайтов