Un cliente preguntó recientemente: “¿Cuándo y por qué Decisions es una mejor opción que el desarrollo personalizado?”. Esta no es una pregunta poco común y un punto importante de mejores prácticas cuando considera las Decisiones como parte de su pila empresarial.
¿Por qué tomar decisiones sobre el desarrollo personalizado?
En realidad no se trata de una comparación directa, pero la pregunta de la dirección es lógica. ¿Cuáles son los beneficios potenciales en dólares, tiempo o algo de valor tangible que las Decisiones aportarán en relación con el desarrollo personalizado?
Entendemos que actualmente sigues la tradición.Ciclos de desarrollo NET para cada nueva aplicación y cada cambio en las aplicaciones existentes. Especialmente en un segmento de servicios financieros que está sujeto a regulaciones que cambian continuamente y al potencial de cambios rápidos por parte del negocio, la TI puede empantanarse con actualizaciones de lógica empresarial que toman tiempo para codificar, revisar, probar y traducir con el negocio.
La misión de Decisions es involucrar a una nueva clase de usuario, que no necesita saber codificar, para que participe en el proceso de diseño de software para la rápida evolución e implementación de una nueva lógica empresarial. Es posible que esta clase de usuario no diseñe ni implemente una aplicación completa, pero esta clase de usuario podrá crear una lógica comercial nueva y cambiar la existente en forma de reglas comerciales, procesos y políticas comerciales y formularios.
Cuando el proyecto se centra en la lógica empresarial: enrutamiento de datos, recopilación de datos, evaluación de datos, podría suponer un ahorro de tiempo de hasta un 50-75%. Cuando el proyecto es más complejo y requiere una arquitectura de base de datos personalizada, un diseño front-end extenso y otras necesidades de programación sofisticadas, podría suponer un ahorro de tiempo del 0 %, pero sería más fácil cambiarlo en el futuro.
Este ahorro de tiempo y potencial para realizar cambios y actualizaciones más fáciles en la lógica empresarial proviene del uso de entornos de desarrollo visual de Decisiones. Un diseñador de flujo de trabajo donde el usuario arrastra, suelta y configura nuevos procesos comerciales sin escribir código. Un motor de reglas en el que un usuario construye visualmente declaraciones de lógica empresarial tal como las escribiría en un documento de requisitos o las dibujaría en una pizarra. Un diseñador de formularios donde arrastran y sueltan componentes del formulario como botones, listas desplegables, etiquetas y otros elementos para crear puntos de interacción del usuario para recopilar datos. Todas estas actividades suponen un ahorro de tiempo en forma de menos requisitos de traducción de tiempo y menos habilidades a nivel de código necesarias para realizar las tareas de desarrollo.
Para ayudar con esta comprensión, aquí hay algunas historias de clientes:
Cliente de servicios financieros F500 - Utiliza Decisiones para monitorear y hacer cumplir los SLA con sus bancos afiliados. Cuando se emplearon recursos de desarrollo personalizados limitados, ya que estaban disponibles para crear nuevas incorporaciones a otros sistemas, este cliente reemplazó la recopilación, validación, puntuación y seguimiento de los informes de sus bancos afiliados con una solución automatizada que permite a los analistas de negocios editar las reglas y los mecanismos de puntuación a lo largo del tiempo sin involucrar a los desarrolladores.
Cliente minorista líder en suministros de oficina - Utiliza Decisiones como capa lógica para automatizar tareas relacionadas con el aprovisionamiento de nuevos sistemas PoS para sus establecimientos minoristas. Mientras que antes era un administrador altamente calificado y certificado el que tenía que iniciar sesión en una consola de Microsoft System Center para realizar todo el trabajo, hoy los miembros del equipo junior pueden iniciar el trabajo y, según las reglas (y cuando sea necesario, la aprobación del administrador), el trabajo puede completarse por sí solo, lo que resulta en importantes ahorros de tiempo. Este proyecto comenzó en Staples y, tras su éxito, Staples Canadá contrató a Decisions para los mismos servicios.
Otros clientes tienen historias similares de automatización de lo que solía ser trabajo manual o de liberación de recursos de desarrolladores capacitados para centrarse en resolver problemas complejos e interesantes en lugar de esforzarse por realizar simples cambios en los requisitos comerciales.
La respuesta honesta a "cuánto tiempo o dinero me ahorrará esto" es que depende. Esperemos que esta explicación pueda informar el potencial de su negocio.
¿Cuándo es Decisions una mejor opción que el desarrollo personalizado?
La mayoría de las cosas para las que no agregamos valor son cosas para las que tendemos a NO usar nuestra tecnología.
1. Aplicaciones web orientadas al cliente e impulsadas por el marketing. 2. Proyecto con una interfaz de usuario muy intensa y dinámica (piense en los sitios web de Facebook o Ebay). 3. Desarrollo hardcore (programación de sockets de red).
Hay algunas cosas en las que estamos en la burbuja. En estos casos tendemos a dividir la programación en partes que puedan reutilizarse dentro de nuestros entornos de desarrollo visual.
Ejemplo: Creación de un controlador para una aplicación de raspado de pantalla de mainframe. Podrías obtener los datos, analizar los campos, etc.; pero el modelo gráfico para esto realmente no agrega mucho valor y es más fácil de hacer en un lenguaje real. Hay pasos para analizar el texto, extraer valores, etc. Si el código está construido de manera que pueda consumirse en un paso de un flujo, obtienes lo mejor de ambos mundos.
Decisions fue diseñado como un entorno para coordinar pequeñas piezas de código reutilizables. Por esta razón, encontrar elementos que sea mejor hacer en el código no invalida la relevancia comercial y la eficiencia del entorno gráfico. A continuación se presentan algunas reglas generales que utilizamos para determinar cuándo se puede utilizar un nuevo paso.
Se necesitarían muchos pasos existentes para realizar la tarea
El camino para ensamblar estos pasos no es obvio
El mantenimiento de la lógica resultante es más fácil en un entorno de desarrollo visual que en código
Este concepto es reutilizable en otros flujos y aplicaciones
Los conceptos representados por la composición de muchos pasos no son algo que a un analista de negocios le interesaría, conocería o comprendería
El uso de pasos requeriría rutas de ejecución que no son ideales para el rendimiento (por ejemplo: recorrer 1 millón de filas en lugar de tener pasos para llamar a una consulta SQL)
Más ejemplos
A continuación se muestran algunos ejemplos básicos de para qué planea utilizar este cliente el producto: · API Scripting a la fuente de datos principal (aplicación web)
· Escribir datos en la fuente de datos principal (aplicación web)
· Tomar decisiones a partir de datos recopilados y cálculos
· Conexión a tablas SQL
· Creación de formularios dinámicos para el usuario final
· Iniciar flujo de trabajo basado en entradas de formulario
· Enrutamiento de formularios
Para cada uno de estos elementos es mejor desarrollar decisiones personalizadas o de uso, ¿dónde se obtienen las mayores ventajas y por qué?
API Scripting a la fuente de datos principal (aplicación web)
Todos los flujos y reglas son automáticamente API de servicios web cuando se crean en Decisions. Dado que para usar el editor ya tienes el servidor de aplicaciones en ejecución, no hay ninguna consideración de implementación, por lo que pasar del momento de comenzar a implementar la regla a ponerla a disposición como una API es solo la cantidad de tiempo que te lleva escribir la regla del flujo. No se dedica ningún esfuerzo a las vinculaciones de API ni a la plomería. Aunque ese realmente no es el punto. Si su equipo está formado exclusivamente por desarrolladores y los desarrolladores mantendrán los scripts de API, entonces el código es un lenguaje de diseño más natural para que lo utilicen. Si desea que las personas que no escriben código mantengan los scripts de API, el flujo de trabajo, las reglas, entonces Decisions ofrece una enorme ventaja.
Escribir datos en la fuente de datos principal (aplicación web)
La pregunta fundamental aquí, similar a la anterior, es: ¿quieres que las personas con mentalidad empresarial evolucionen y cambien este mecanismo o quieres que lo mantengan exclusivamente los desarrolladores? Lo que importa es responder al mundo empresarial, las regulaciones y las iniciativas estratégicas en constante cambio, por lo que asegurarse de utilizar herramientas que empoderen a los miembros del equipo que tiene disponibles para realizar estos cambios es más importante que elegir una herramienta que le permita algunos atajos en la implementación.
Decisions ha incorporado integraciones a bases de datos, servicios y otros sistemas externos que hacen que las interacciones con una fuente de datos principal sean algo que generalmente funciona en Decisions desde el primer momento. Esto significa que las Decisiones pueden producir muy rápidamente flujos que pueden recibir datos y escribirlos en una fuente principal. Por lo general, esto se puede hacer más rápidamente, o igualmente rápidamente para codificar directamente y, lo que es más importante, a medida que evoluciona esto para incluir reglas comerciales, límites, tareas, etc. La capacidad de tomar decisiones para evolucionar lo distingue.
Tomar decisiones a partir de datos recopilados y cálculos
Al utilizar Decisions Rule Engine y Workflows, puede evaluar, ramificar, secuenciar y orquestar la lógica que conduce a diferentes resultados en su proceso comercial.
Conexión a tablas SQL
Lo mismo que una respuesta anterior: Decisions ha incorporado integraciones a bases de datos, servicios y otros sistemas externos que hacen que las interacciones con una fuente de datos principal sean algo que generalmente funciona en Decisions desde el primer momento. Esto significa que las Decisiones pueden producir muy rápidamente flujos que pueden recibir datos y escribirlos en una fuente principal. Por lo general, esto se puede hacer más rápidamente, o igualmente rápidamente para codificar directamente y, lo que es más importante, a medida que evoluciona esto para incluir reglas comerciales, límites, tareas, etc. La capacidad de tomar decisiones para evolucionar lo distingue.
Creación de formularios dinámicos para el usuario final
Honestamente, esta es un área en la que podemos ser débiles dependiendo de su caso de uso. Si desea un formulario específico, eficiente y orientado a la acción, somos EXCELENTES. Si desea un formulario realmente dinámico con un diseño perfecto en píxeles según los estándares actuales, probablemente querrá desarrollar sus propios formularios y utilizar nuestros pasos de flujo de trabajo “formulario externo”.
Iniciar un flujo de trabajo basado en entradas de formulario
La interacción del usuario es un método principal para iniciar un flujo de trabajo. Junto con llamadas API o trabajos programados.
Enrutamiento de formularios
Puede utilizar reglas de decisión y flujos para enrutar formularios dinámicamente según una lógica condicional desarrollada y comprendida visualmente. Su documentación es lo que realmente se está ejecutando.
15 de octubre de 2026
Herramientas puntuales versus plataforma: qué sucede cuando la orquestación no es nativa
