🤶🏾 🙋 🎳 Del monolito al sistema distribuido 🤟🏼 🕷️ 🤝

El constante crecimiento de la competencia entre los bancos hace que sea necesario adaptarse a diferentes categorías de clientes. Entonces, es más fácil ir al sitio y solicitar un producto bancario en línea, mientras que otros están acostumbrados a elegir nuevos productos y servicios directamente durante la comunicación en vivo con un representante del banco. En septiembre de 2019 Home Credit Bank decidió lanzar un nuevo proceso para el Cliente, cuyo objetivo principal era mantener el contacto "Cliente - Operador del Banco" y rechazar la conexión física del operador a la oficina o mostrador del Banco en el centro comercial.

La fecha de lanzamiento del proyecto piloto se fijó para principios de diciembre de 2019. Para su implementación, lo antes posible, fue necesario desarrollar un sistema con funcionalidad para registrar una tarjeta de débito personal y no personal para clientes nuevos y existentes del Banco.

En camino a una nueva plataforma

Comenzaron a mirar hacia la solución de tableta. La implementación de un nuevo proceso en una tableta basada en la arquitectura del sistema de front-office actual del Banco para que los Operadores trabajen con el Cliente parecía irracional debido a una pila tecnológica obsoleta, ya que El front office actual es una aplicación web monolítica escrita hace 8 años en Silverlight. Los intentos de trabajar con el frente actual en la tableta no tuvieron éxito debido a la parte ui sobrecargada de la aplicación y la falta de diseño adaptativo. Además, la falta de soporte de Silverlight de Microsoft insinuó sutilmente que el ciclo de vida de nuestra aplicación actual estaba llegando a su fin y que había un momento de rediseño radical y la transición a nuevas tecnologías. Tomamos la decisión de implementar la arquitectura de microservicios. ¿Por qué era necesario abandonar el monolito? Primeramente,Debido a la escalabilidad de la solución, mejor tolerancia a fallas en general y actualizaciones de componentes independientes. En segundo lugar, en el Banco, la tendencia de la distribución de la funcionalidad entre los equipos de productos y el enfoque de microservicio en este caso brinda una mayor flexibilidad e independencia de los equipos.En las primeras etapas, se asignaron los siguientes dominios (microservicios) para el proyecto piloto: usuario, cliente, tarjeta de débito e incidente. Para crear la parte posterior de la aplicación, utilizaron la plataforma .Net Core 2.2 (recientemente cambiada a 3.0), tomando prestados elementos de la lógica empresarial del legado del sistema. Se decidió construir la parte delantera usando react.

UI / UX

Paralelamente a la definición de arquitectura, se discutió la interfaz de la aplicación y la lógica empresarial del proceso. Se requirió determinar cómo el Operador interactuará con el Cliente, qué paquete de documentos se necesita, qué información necesita el Operador en cada paso de venta específico. El objetivo era simplificar el proceso comercial actual, en lugar de simplemente copiar la funcionalidad a una nueva plataforma. Entonces, en la nueva decisión, el número de campos se redujo cuando se abrió una solicitud de tarjeta de débito y se excluyó el cuestionario para el Cliente (que recopila información sobre cómo el Cliente se enteró sobre Home Credit Bank). Se ha agregado una función para el acceso rápido al registro de productos de débito prioritarios en la página principal con datos del cliente. Y en la etapa de aprobación, las aplicaciones mostraron información detallada sobre las tarifas y condiciones del producto, lo que también ayudó al Operador.

Durante 8 años en un entorno productivo, la página de inicio de la página principal con los datos del Cliente y la funcionalidad para conectar productos y servicios se ha sobrecargado debido a los interminables íconos y campos.

Quería agregar "aire" a la interfaz. Aquí, tuve que priorizar, determinando qué funcionalidad necesitaban los Operadores en primer lugar para acceder a la página principal, que se puede mostrar en el panel lateral y que se puede abandonar debido a la inutilidad (¡sí, sí! Se encontraron estos campos). Como resultado del fructífero trabajo del equipo con el diseñador, se diseñaron las primeras miniaturas de la página con los datos del cliente y la página con las etapas de creación de una aplicación para una tarjeta de débito.

Documentación

La base de conocimiento para el front-office actual "vive" en Word con coedición en SharePoint. El nuevo proyecto decidió poner a prueba un nuevo proceso de documentación en Confluence junto con Swagger para la autodocumentación. Nuestro camino de transición, los pros y los contras de la solución seleccionada se describirán en un artículo separado. Solo puedo decir que el tema de elegir una herramienta de gestión de requisitos aún está abierto, estamos en la etapa de búsqueda de la solución óptima para mantener actualizada la documentación con una inversión mínima de recursos.

¡Vamos a la carretera!

Como resultado, nuestra hoja de ruta para lanzar el codiciado piloto se veía así.

El sistema de interacción del equipo incorporado pudo cumplir con la fecha límite del piloto. Al comienzo del proyecto, el equipo tuvo que abandonar la cascada y poner un pie en el sendero Ágil. Fue un ágil adaptado por nuestro equipo. Paralelamente: los desarrolladores comenzaron en la etapa de acuerdo con el equipo sobre la implementación, que generalmente se refleja en los requisitos antes del inicio del desarrollo y se pusieron de acuerdo con todos los participantes en el proceso. Las preguntas abiertas se discutieron en las reuniones. Las decisiones fueron tomadas por un equipo juntos. En cualquier momento, cada miembro del equipo podía hablar sobre el estado del proyecto, todos se sentían involucrados en el proceso y esperaban con ansias el piloto de acuerdo con los resultados de nuestro trabajo.

Piloto

El piloto tuvo lugar en uno de los centros comerciales más grandes de Moscú en la víspera del Año Nuevo. Para el proyecto piloto, se contrataron nuevos especialistas en ventas que no conocían los productos bancarios y que no habían trabajado previamente con nuestro sistema actual de recepción. Los resultados del piloto mostraron que los nuevos usuarios descubrieron fácilmente la secuencia necesaria de acciones en nuestra nueva aplicación, lo que significaba que tal esquema podría lanzarse en otros sitios, reclutando nuevos especialistas con requisitos mínimos.

En la nueva aplicación, buscamos la actualización constante de la funcionalidad del producto, en función de las necesidades de los operadores y clientes. Entonces, en la primera semana de lanzamiento, se lanzaron 25 pequeñas mejoras basadas en los resultados del piloto. Por ejemplo, en el paquete de documentos al concluir el contrato, se agregó un formulario impreso con las tarifas del producto, porque La mayoría de los Clientes, después de ver las tarifas en la tableta del Operador, expresaron su deseo de recibir las tarifas impresas "a mano".

La actividad de ventas a través de la nueva plataforma se monitoreó en línea a través de un informe sobre Graphana y se regocijó con cada nueva firma del contrato.

Errores

Existe un problema en la oficina actual cuando se analizan los errores del producto: no siempre es posible restaurar la secuencia de acciones del Operador, especialmente en los casos en que hay transiciones impredecibles entre pantallas de aplicaciones (identificadas ex post) que no están integradas en la lógica empresarial del proceso. La apelación al usuario generalmente no es concluyente, porque Debido al gran flujo de clientes, es imposible restaurar la secuencia de acciones realizadas en la aplicación con un Cliente específico en un momento determinado. El nuevo sistema también quería resolver estos problemas. Registro de extremo a extremo para todos los microservicios en el marco de la sesión del cliente y el operador, grabación adicional en el registro de mensajes de texto para cada acción del operador (creó un nuevo cliente, firmó un acuerdo,conectado sms-information) y una captura de pantalla completa ayudaron a restaurar rápidamente la imagen del proceso de negocios, acelerando el análisis de los errores del producto al ver los registros en GrayLog.

El objetivo del piloto no era solo implementar una solución de tableta, sino también sentar las bases para nuestra futura plataforma del sistema de front office de Home Credit Bank. Ahora seguimos mejorando. Estamos trabajando en la adición de un nuevo módulo "Créditos" para trabajar con los productos de préstamos del Banco. Y también en el proceso de investigar el uso de nuevas tecnologías (graphql, cuyo propósito no es conducir datos adicionales de atrás hacia adelante; camunda para una configuración flexible del proceso de negocios; Prometheus para recopilar métricas de negocios para crear informes).

En el futuro, vemos el avance de la solución de tableta al agregar la funcionalidad de ventas de varios tipos de productos bancarios. Ahora la prioridad es crear el proceso de emisión de una tarjeta de crédito del Banco. Además, expandir el área de aplicación de la tableta a tiendas de electrónica y oficinas de representación de fondos de pensiones.