La eterna pregunta de si comprar o construir su software (James Monaghan)

Felicidades. Tienes un problema, un proyecto, un presupuesto y una fecha límite. En lugar de arrojarle cuerpos, el software es la solución, pero ahora hay que decidir si construir o comprar, esa es la cuestión. ¿O es eso? Ya no estoy tan seguro de que sea una decisión clara.
Construir uso para referirse a la contratación de programadores internos para codificar cualquier sistema que fuera necesario y comprar productos disponibles en el mercado que se pudieran comprar y ejecutar. Esto tenía sentido cuando hablábamos de sistemas de contabilidad, sistemas comerciales, CRM, informes,
Préstamos, cobros, CLM, etc. Ahora vivimos en un entorno de código bajo donde construir algo no requiere experiencia en codificación. Puede ser arrastrar y soltar. Combine eso con la compra de soluciones listas para usar que terminan siendo tan personalizadas que usted también podría
Bueno, lo hemos construido. Entonces, ¿dónde nos deja eso para tomar la decisión de construir o comprar? Veamos lo que realmente necesitamos.

Ningún sistema moderno puede depender ya de un único punto de entrada. Las expectativas del cliente dictan que son necesarios varios canales. En persona, por teléfono directo o centro de llamadas, correo electrónico, redes sociales, SMS, web, móvil, tableta (tanto móvil como nativa)
apps, todas con la necesidad de ser intercambiables sin perder contenido ni contexto. Un cliente que comienza en una sucursal/tienda o en persona pero tiene que salir para una cita quiere poder continuar donde lo dejó cuando inicie sesión en línea más tarde ese día. O
Si comienzan en línea pero se frustran y piden ayuda, no querrán tener que comenzar el proceso desde el principio. Esto también se aplica a las partes interesadas internas. La cadena de información dentro de una organización debe ser tan flexible como se enfrenta el cliente.
. 

Entonces, ¿qué sigue para comenzar con la entrada de datos en cualquier lugar? Bueno, hay una razón por la que necesitamos esos datos en primer lugar. Ya sea que un nuevo cliente quiera trabajar con la organización, un cliente existente quiera un nuevo producto o servicio, o incluso simplemente consultas o quejas cotidianas.
o solicitudes de información. Todos estos deben iniciar procesos definidos pero flexibles para completar la solicitud de la manera más eficiente y sencilla posible. El proceso generalmente está definido y normalmente el personal está capacitado para seguir una secuencia de tareas para completarlo con un tiempo predeterminado.
acciones basadas en determinadas entradas de datos. 

Ni los clientes finales ni los usuarios del sistema deberían tener que volver a introducir información en ningún lugar si ya se ha capturado en algún lugar. De hecho, si la información está disponible en cualquier lugar dentro de la organización o de fuentes de terceros como proveedores de datos, agencias de crédito,
proveedores de detección, etc. debe ser accesible durante todo el proceso para todos los usuarios que lo necesiten. El proceso está definido, pero los puntos de contacto deben ser intercambiables en todo momento y los datos recopilados deben integrarse cuando sea posible y estructurarse cuando sea posible.
Menús desplegables, valores de búsqueda, campos de fecha y valores de texto libre controlados para garantizar la captura de la mayor calidad de los datos por adelantado. Esto permite mucha más automatización durante todo el proceso y menos manejo de excepciones.

Ahora que los datos están en proceso de captura o actualización activa, se puede aplicar la inteligencia artificial. El personal no necesita conocer todos los detalles e incluso los miembros más nuevos pueden trabajar en casos más complejos porque el sistema utiliza reglas codificadas por políticas.
lógica para tomar automáticamente decisiones que antes el personal debía tener una amplia formación y experiencia para manejar. No más errores y al mismo tiempo permite la supervisión e incluso controles de calidad o colas de excepción para intervención manual si es necesario.

Todo esto requiere un enfoque sistemático. La vieja idea de una carpeta manilla que se guarda en el cajón de un miembro del personal para su cartera de clientes está obsoleta y crea un riesgo innecesario. Los clientes que se procesan de forma aislada pueden ser limitantes y redundantes
al mismo tiempo. Si un cliente corporativo tiene directores que trabajan junto a muchos otros clientes, ¿por qué cada revisión individual ignoraría el panorama general? ¿También revisarás al mismo director varias veces en cada relación o podrías
¿Hacerlo una vez y reutilizar esa información en toda la organización?

Ni siquiera es necesario que tengan partes relacionadas en común para que el beneficio sea evidente. Industrias similares, clientes similares, ¿qué pasa si los vendedores/proveedores de sus clientes también son clientes? Esto nos lleva a cómo necesita procesar la información.
y por qué las organizaciones necesitan mirar a toda la empresa al considerar el software en estos días. Si ve un problema de forma aislada y lo trata como tal, estableciendo presupuestos y emitiendo RFP para cada componente de CRM, Fincrime y Atención al Cliente, terminará
con gastar más recursos tratando de integrar todo que cualquier ahorro potencial que se esperaba inicialmente. Ahora aplique eso para cada región o línea de negocio que pueda tener presupuestos y supervisión separados y terminará con 8 versiones.
del mismo software que necesita integrarse consigo mismo debido a la gran personalización por área, eliminando cualquier economía de escala que pudieran lograr.

Una carpeta en un cajón que debe revisarse anualmente o de otro modo, y que el personal debe recibir capacitación sobre qué hacer y cuándo hacerlo. La revisión completa (o la nueva incorporación/producto/servicio adicional/etc.) se puede dividir en partes compuestas que pueden o
no puede ser manejado por otras personas/equipos. Luego, el sistema puede determinar cuándo se completa una tarea o cuándo se capturan datos suficientes para enviarlos a la siguiente persona para que los ingrese. Todos estos están estructurados como casos y subcasos internos. De esta manera cada elemento de
el caso puede tener su propia fecha límite, ruta de escalamiento, cesionario y aprobadores. En lugar de una tarea grande que un miembro del personal necesita tener suficiente experiencia para saber cómo completarla y a quién acudir para varios elementos internos, el sistema ahora asigna el trabajo.
y garantiza su finalización oportuna en toda la empresa con tantas tareas automatizadas como sea posible para liberar a los tomadores de decisiones para que se concentren en lo importante.

Todo esto está muy bien desde el punto de vista empresarial. Se conoce el trabajo y lo que hay que hacer. Pero cuando intentamos decidir si debemos comprar o desarrollar el software nosotros mismos, ¿cómo influye eso en las cosas? Bueno, supongamos que hay múltiples fuentes.
de datos en múltiples sistemas. Se espera que cualquier sistema moderno esté impulsado por API y tenga capacidades de código bajo o sin código. Una suposición razonable para un software más rápido y flexible. Hoy en día, todo debe tratarse como una especie de microservicio para evitar
los monolitos de software de estilo antiguo. El software debe instalarse y utilizarse porque es el mejor disponible y está preparado para adaptarse a los cambios según sea necesario. Demasiadas ofertas están arraigadas y se mantienen solo porque son demasiado difíciles y consumen mucho tiempo.
para reemplazar. La mayor parte de esto se debe a que las reglas están codificadas, probablemente entrelazadas con los datos mismos, los datos no sólo se integran sino que se replican varias veces para cada pieza de software separada en la cadena de información y si se intenta reemplazar una pieza, la
todo el sistema podría romperse. Demasiado del viejo proceso de pensamiento, si no está roto entonces no lo arregles. Lo que realmente se necesita es que todos esos componentes sean microservicios, tomando los datos necesarios, aplicando reglas automatizadas o entradas/revisiones de los usuarios y
pasándolo al siguiente microservicio. Los datos no deben almacenarse en más de una ubicación. Puede estar federado pero no replicado fuera de las copias de seguridad. Sus sistemas CRM, Onboarding, KYC, Client Outreach, etc. solo deben acceder a los datos que necesitan y no
ser repositorios de datos a menos que haya elegido uno. Replicar los mismos datos en múltiples ubicaciones y las reglas que los gobiernan es un ejercicio inútil ya que cada sistema adicional agregado multiplicará las complejidades involucradas.

Esto nos lleva a la consideración final. Ya sea que tenga una única fuente de verdad/Copia Dorada o múltiples registros y sistemas redundantes y competitivos que puedan actualizarlos, aún se encontrará en otra capa de requisitos basados ​​en la línea de
negocio, jurisdicción, tipos de clientes y productos/servicios. Un individuo recibe un trato diferente a una empresa o fideicomiso y difiere según las líneas de negocio de consumo/minorista, comerciales o corporativas en cuanto a requisitos e idoneidad. En el más básico de los ejemplos si
Tenemos 10 tipos de clientes (individuos – solteros, casados, etc., empresa privada, empresa pública, fideicomiso, organización benéfica, etc.) y usted puede operar en 10 regiones, y puede ofrecer 10 tipos de productos/servicios, ya estamos en potencialmente más de 1000 reglas que podrían
se aplicado. ¿No sería mucho más fácil definir reglas para una región, para una línea de negocio, para un tipo de cliente y productos o servicios y dejar que el sistema resuelva los requisitos? Eliminar duplicados y reutilizar puntos de datos que estaban previamente
proporcionó. Este es el beneficio de abstraer su proceso y reglas de su capa de datos. 

Así que ahora, cuando consideramos la vieja cuestión de comprar o crear software, sabemos que necesitamos orquestación omnicanal, automatización de procesos cuando sea posible, lógica de reglas flexible, gestión de casos para supervisión y auditabilidad, código bajo y API impulsado, una solución abstracta.
capa de datos y un motor de reglas inteligente que puede heredar de diferentes capas lógicas. El mercado tecnológico está lleno de innovadores que satisfacen gustosamente cada problema de nicho que se pueda imaginar, pero ¿en qué momento deja de tener sentido tenerlo "listo para usar"?
productos que deben personalizarse e integrarse entre sí en lugar de crearlos usted mismo. Las plataformas de código bajo pueden permitirle tener disponible el 80% de sus requisitos y solo necesita configurar ese delta del 20%. Lo mejor de ambos mundos es un nivel bajo.
plataforma de código para la que otros también han creado componentes reutilizables para que pueda obtener los productos disponibles como aceleradores para su negocio y al mismo tiempo tener la capacidad para que su personal o terceros certificados creen el resto de los requisitos específicos.
a su organización. ¿Comprar o construir? Realmente deberían ser ambas cosas.