Андрей Трушкин – Архитектура цифровых платформ. От настоящего к будущему (страница 3)

• Учетная составляющая, в рамках которой предполагается ведение синтетического учета данных о продукте.

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

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

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

Что же происходит в организации, которая, приняв за руководство к действию следование платформенным подходам, попадает в ментальную ловушку «множества платформ» (как мы увидим ниже)?

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

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

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

Автоматизация бизнес-процессов предполагает возможность быстрого создания и изменения последних, а также обеспечение их мониторинга, расчета КПЭ и т. д. Продуктовые бизнес-процессы предполагают исключительно широкие возможности настройки, необходимость создания и исполнения кросс-продуктовых процессов (задействующих различные типы продуктов с генерацией совместной аналитической и синтетической учетной логики), потенциал создания большого количества точек интеграции, использование современных практик low-code и no-code для проектирования и исполнения процессов. Можно констатировать, что требования к удобству и гибкости настроек для данного слоя исключительно актуальны. Долгое время считалось, что вопросы производительности на уровне настройки и исполнения бизнес-процессов уходят на второй план по сравнению с гибкостью, но современный мир диктует необходимость изменения подобного подхода. В условиях повсеместного развития дистанционных каналов обслуживания невысокая производительность автоматизированных бизнес-процессов приведет к утрате конкурентоспособности организации, допустившей указанный недостаток. Например, низкая скорость обработки поступающих заявок на кредит исключает привлекательность для клиентов каналов, не требующих аутентификации (например, сайты компании или ее партнеров), обнуляя возможность лидогенерации, что недопустимо для организации, ставящей во главу угла интенсивное развитие. При этом вопросы выполнения групповых и пакетных операций (по аналогии с автоматизацией аналитического учета) практически неактуальны. Вопросы мониторинга исполняющихся процессов, напротив, крайне важны: специалисты, ответственные за развитие бизнес-процессов организации, должны иметь возможность моделирования и установки КПЭ процессов, клиенты и партнеры нуждаются в развитой статусной модели процессов, позволяющей получать информацию о состоянии интересующих их процессов и обрабатываемых в ходе их исполнения данных. При этом традиционной характеристикой автоматизации бизнес-процессов является высокое потребление вычислительных ресурсов при выполнении данной задачи. Соответственно, необходим мониторинг ресурсов, потребляемых теми или иными бизнес-процессами и их экземплярами, на основании данных которого оказывается возможным обеспечивать «здоровье» ИТ-ландшафта организации. В рассматриваемом случае речь идет о командах DevOps и/или сопровождения, являющихся пользователями мониторинга бизнес-процессов. То есть речь идет как о системном, так и о прикладном характере мониторинга. Пользователи же мониторинга являются как внутренними с точки зрения организации, так и внешними. Проанализировав все указанные аспекты, мы приходим к необходимости высоких требований к возможностям пользовательского интерфейса «платформы» автоматизации бизнес-процессов. При этом автоматизация бизнес-процессов в большинстве случаев не предполагает транзакционного характера исполняемых операций (в части того, что операции на уровне данной составляющей не являются типовыми и/или короткоживущими).

При автоматизации фронтальной составляющей продукта особое внимание уделяется упомянутым выше «клиентскому пути» и «дизайн-мышлению», а также аналогичным им аспектам. В противном случае конкурентоспособность продукта оказывается чрезвычайно низкой в современном цифровом мире, инвестирование средств в создание, развитие и продвижение такого продукта теряет всяческий смысл. При несомненной важности рассмотренных выше аспектов продуктовой автоматизации фронтальное представление является базовой составляющей формирования эффективного P&L (profit and loss analysis) продукта. Составляющей исключительной важности в случае фронтального представления является производительность этого самого автоматизируемого фронтального представления: в случае медленной отрисовки графики по продукту, длительного переключения экранов представления потенциальный (да и действующий) клиент потеряет интерес к продукту, обратит внимание на предложения конкурентов, и организация понесет убытки. Особенно актуален вопрос производительности в условиях дистанционных каналов, далеко не все из которых в процессе лидогенерации предъявляют требования к обязательности аутентификации или заполнению пространных анкет. В условиях резкого роста числа каналов продукты должны быть представлены если не в каждом из них, то в некоем значимом множестве. В противном случае можно неоправданно сократить воронку продаж. И организация приходит к необходимости поддержки концепции омниканальности, при которой все каналы коммуникации с пользователями (в их число могут входить не только клиенты организации, но и ее сотрудники и партнеры) объединяются в единую связанную экосистему, при этом коммуникация в рамках продуктового взаимодействия носит сквозной характер. Таким образом достигается целостное взаимодействие пользователей с автоматизируемым продуктом. Но как обеспечить рассматриваемую омниканальность? Зачастую организации добавляют в свой ландшафт очередную «платформу» – омниканальную, в задачи которой входит:

• Отделение логики представления от процессной.

• Предоставление развитых инструментов создания интерфейсов.

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

• Обеспечение непрерывности коммуникации с пользователями.

• И многие другие…

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