5 minutos de lectura

Automatización de procesos empresariales con Camunda: implantación tolerante a fallos de esquemas BPM

BPMN

Negocio

Comunda

Spring Boot

En el mundo digital actual, mantener una ventaja competitiva requiere procesos empresariales ágiles y eficientes. La automatización destaca como solución clave para lograrlo. Según Statista, el mercado de la gestión de procesos empresariales (BPM) se espera alcanzar un tamaño de 14.400 millones de dólares estadounidenses en 2025. La creciente popularidad y demanda de herramientas BPM como Camunda, conocidas por su flexibilidad y escalabilidad, dan fe de esta tendencia. A medida que las empresas buscan herramientas fiables para optimizar sus operaciones, Camunda emerge como precursor, allanando el camino para soluciones de automatización innovadoras y tolerantes a fallos en la industria.

¿Qué es Camunda?

En términos sencillos, Camunda es una plataforma de código abierto para la automatización de flujos de trabajo y decisiones que reúne a usuarios empresariales y desarrolladores de software. A través de su sólido conjunto de herramientas y funciones, Camunda ofrece formas de diseñar, implementar y optimizar flujos de trabajo BPMN (Business Process Model and Notation), haciendo que las operaciones empresariales sean más fluidas y transparentes.

Camunda, Spring Boot y BPMN: comprender los conceptos

Tres actores clave han reconfigurado el panorama de la gestión de procesos empresariales: Camunda, Spring Boot y BPMN. Cada uno de ellos se ha hecho un hueco, ofreciendo funcionalidades únicas que abordan distintas facetas de la gestión de procesos. Sin embargo, cuando se combinan, se transforman en una potencia sin parangón, capaz de revolucionar las operaciones de las empresas digitales.

Camunda: No se trata de una herramienta más en la vasta caja de herramientas de BPM, sino de una sobresaliente. Camunda es una sólida plataforma de código abierto especializada en la automatización de flujos de trabajo y decisiones. ¿Su principal objetivo? Fusionar a la perfección los mundos de los estrategas empresariales y los desarrolladores de software. De este modo, garantiza que la conceptualización, el diseño y la implementación de los procesos empresariales sean eficaces, transparentes y coherentes.

Spring Boot: Spring Boot toma la fuerza del armazón de resorte y los eleva. Al ofrecer un método simplificado para crear aplicaciones Java independientes, se ha convertido en la opción preferida de los desarrolladores que desean minimizar el código repetitivo y sumergirse directamente en el corazón de las funcionalidades específicas del proyecto. Su poder radica en su flexibilidad y su enfoque de convención sobre configuración, que defiende la idea de valores predeterminados inteligentes. Este enfoque permite a los desarrolladores crear aplicaciones escalables más rápido, lo que garantiza una entrega oportuna y un rendimiento constante.

BPMN: Si tuviéramos que personificar BPMN, sería el elocuente lingüista del mundo empresarial. Como norma mundialmente reconocida, BPMN proporciona un vocabulario visual para la redacción de procesos empresariales, haciéndolos fácilmente comprensibles para un amplio abanico de partes interesadas. Este lenguaje universal garantiza que los matices técnicos de un proceso sean descifrables tanto para el programador experto en tecnología como para el estratega empresarial, fomentando diálogos de colaboración y una toma de decisiones más informada.

La sinergia de las capacidades de automatización de Camunda, la facilidad de desarrollo de Spring Boot y la notación estandarizada de BPMN ofrece a las empresas una trifecta dinámica. Juntos, garantizan que los esquemas BPM pasen de ser meras construcciones teóricas sobre el papel a implementaciones prácticas en el mundo real. ¿El objetivo final? Cultivar procesos empresariales ágiles, resistentes y perfectamente alineados con las demandas cambiantes del panorama empresarial digital contemporáneo.

Componentes básicos de BPMN

Para quienes no estén familiarizados con BPMN, es crucial comprender sus componentes esenciales. Estos componentes forman la base de cualquier diagrama BPMN.

Eventos

Significan algo que ocurre durante un proceso. Los eventos pueden iniciar, interrumpir o finalizar un flujo, y suelen representarse como círculos.

Pasarelas

Las pasarelas se encargan de la toma de decisiones dentro del proceso. En función de las condiciones, controlan el flujo del proceso, normalmente representado como diamantes.

Actividades

Las actividades representan el trabajo que se está realizando. Pueden ser tareas o subprocesos y se muestran como rectángulos redondeados.

Conexión de objetos

Estos elementos, incluidos los flujos de secuencias, los flujos de mensajes y las asociaciones, ilustran la secuencia de procesos y el flujo de mensajes.

Swimlanes

Clasifican los elementos BPMN por función (por ejemplo, gestor, contable) o sistema (por ejemplo, un sistema ERP).

Artefactos

Ofrecen información adicional sobre el proceso. Los artefactos más comunes son los objetos de datos, los grupos y las anotaciones.

Pros y contras de Camunda

Como cualquier solución tecnológica, Camunda aporta una mezcla de ventajas y retos. He aquí un análisis exhaustivo de sus pros y sus contras.

Pros:

Integración flexible y sencilla con aplicaciones Java a través de Spring Boot.
Una interfaz de modelado intuitiva para BPMN 2.0.
Proporciona análisis detallados de las métricas de los procesos.

Contras:

Puede tener una curva de aprendizaje más pronunciada para los usuarios no técnicos.
Es un buen punto de partida, pero considérelo sólo la base: aunque Camunda es un potente motor de flujo de trabajo, necesitará más desarrollo de software.

Racionalización de diagramas BPMN sobrecargados

Dura realidad

Camunda está diseñada para que desarrolladores y analistas hablen el mismo idioma, pero a menudo, la realidad interviene.

Los microservicios fallan, los usuarios introducen datos incorrectos, cualquier cosa puede suceder. En este caso, el hermoso diagrama analítico comienza a embellecerse con varios gestores de errores, registradores y vías alternativas. El analista diseña un esquema bonito, sucinto y comprensible. Tiene unos pocos delegados y proporciona caminos lógicos para el flujo del proceso en diversas circunstancias. Este es el aspecto de un esquema provisional cuando llega a manos de un desarrollador:

Sin embargo, existen inconvenientes. Un esquema de este tipo puede contener una breve descripción de la tarea, como "comprobar el cliente", que implica varias etapas, la toma de decisiones en función de cada resultado y la compilación de las decisiones derivadas en un único resultado, posiblemente con la posterior transferencia de este resultado a sistemas externos.

Es evidente que en este punto aparecen en el esquema o en el código manejadores de errores, registradores y elementos de servicio técnico. De este modo, una tarea "analítica" en la implementación de Java se vuelve voluminosa y compleja, o aumenta el número de pasos en el esquema, cada uno de ellos acompañado de manejadores y vías alternativas. Como resultado, el esquema se vuelve rápidamente enrevesado, difícil de soportar y modificar, y añadir nuevas funcionalidades puede implicar reestructurar una vasta área tanto del esquema como del código delegado. En esencia, contiene un enorme número de elementos idénticos.

Así es como se vería el esquema anterior en un despliegue real:

Evidentemente, el esquema se ha ampliado y se ha vuelto más engorroso. Pero tiene sus ventajas: todas las tareas se han vuelto atómicas y han surgido ramas de comportamiento en caso de error.

Comprender el problema

Si intentamos separar y encapsular el esquema y la lógica de negocio del código Java, podemos hacer lo siguiente:

Evite duplicar elementos similares en el esquema.
Utilizar una implementación universal y reutilizable de delegados en el código Java.
Optimizar y acelerar el flujo del proceso.
Simplifique la gestión de errores técnicos y establezca una lógica de comportamiento de los procesos cuando surjan, casi sin intervención del código Java. Esto simplificará significativamente la depuración y el análisis manual de los procesos fallidos que se encuentren en un incidente.
Reducir drásticamente el número de procesos que "caen" en incidencias cuando surgen excepciones técnicas.
Sentar unas bases sólidas para el desarrollo posterior.

Para facilitar el trabajo con el producto es mejor descomponer el esquema en tareas atómicas, reducir el volumen total de elementos del esquema, disminuir el número de manejadores de servicio, reducir el volumen de código Java de cada delegado, y reutilizar los delegados universales, realizando refactorizaciones instantáneas cuando sea necesario. Todo ello implicaba automáticamente escribir pruebas unitarias para todos los delegados y las rutas principales del proceso.

Descomposición y atomización

Si se observa detenidamente la aplicación de proceso y se analizan sus nodos, se pueden ver muchas funciones repetitivas: consultas a sistemas externos, registro, gestión de errores, envío de callbacks, etc. En otras palabras, hay que evaluar críticamente la aplicación de proceso, identificar objetos de la misma que puedan encapsularse fácilmente... ¿Pero en qué? ¿En código Java? No, eso sería ilógico, porque en este caso, el esquema estaría estrechamente ligado a su implementación Java. En esta situación, tiene sentido considerar las agrupaciones de procesos.

Un pool de procesos es un esquema de un proceso separado que tendrá su propio contexto. Cabe destacar que es conveniente extraer piezas atómicas de funcionalidad del proceso principal en dichos pools, así como todos los momentos repetitivos: envío de notificaciones, peticiones a sistemas externos, etc.

Puede haber muchos grupos de procesos, y sería lógico agruparlos temáticamente. Por ejemplo, consultas a un microservicio concreto, alertas, envío de notificaciones diversas. La interacción entre estos grupos puede establecerse fácilmente utilizando la mensajería de Camunda. Cada vez que se llama a un pool de este tipo en el motor Camunda, se pasa un determinado mensaje que contiene una cabecera condicional y el número de proceso padre para devolver una respuesta, así como un conjunto de datos necesarios para el funcionamiento de este pequeño pool específico.

Aquí vemos cómo el proceso principal (abajo) envía un mensaje al que está suscrito el iniciador de otro pool. Cuando se produce el evento, el segundo pool inicia una nueva instancia del proceso, realiza una petición y envía una respuesta al proceso principal, tras lo cual se completa con éxito. Durante este tiempo, el proceso principal espera el evento de respuesta del pool externo al que envió una petición. Cuando llega el mensaje, el proceso continúa. Si no hay respuesta en el intervalo de tiempo especificado, el proceso entiende que el cálculo externo no está disponible o ha fallado, y termina.

Lo que esto ofrece:

Posibilidad de reutilizar el código. Si necesita llamar al mismo código varias veces bajo diferentes condiciones a lo largo del proceso, puede simplemente crear mensajes específicos y llamar a los pools de procesos atómicos correspondientes;
Encapsulación del esquema de implementación del software a partir de su representación empresarial. No importa cómo se rediseñará el esquema principal, ni qué caminos tomará el proceso. Todas las interacciones ya se han trasladado a procesos menores independientes, lo que proporciona una flexibilidad total: basta con formar una solicitud y esperar una respuesta.
El número y la probabilidad de que se produzcan las principales caídas del proceso se reducen considerablemente. Antes de tal división, el proceso se encontraba en una incertidumbre de 4 estados:
La respuesta ha llegado.
La respuesta no llegó porque el microservicio externo se bloqueó.
La respuesta no llegó porque el proceso principal se bloqueó al enviar la solicitud.
La respuesta no ha llegado porque se ha superado el tiempo de espera.

Con esta división, el proceso siempre se encuentra en un estado estrictamente único: la respuesta llegó o el proceso esperó y terminó. Para las empresas, importa cómo terminó exactamente el proceso: si fue un error o no. Pero esto será una conclusión adecuada, no un incidente. Esto es importante porque un proceso no atascado en un incidente no "consume" recursos, y los errores se pueden registrar fácilmente, recopilar estadísticas, configurar alertas y analizar.

Ya no importa lo que ocurra con los procesos menores. Pueden hacer lo que quieran: bloquearse, ejecutarse... Sólo importa el resultado: la respuesta del recurso externo. E incluso así, no siempre, porque el proceso principal no debe garantizar la funcionalidad de los sistemas externos. Por ejemplo, puede que no tenga sentido que el proceso espere una respuesta del microservicio de notificación, ya que podría no haber respuesta alguna.
La complejidad del proceso principal se reduce considerablemente. La lógica compleja puede distribuirse entre pequeños grupos separados, que son más fáciles de depurar. Por ejemplo, la verificación del cliente podría ser algo parecido a esto:

Aquí, podemos ver que en el pool externo, múltiples tareas son llamadas simultáneamente. Profundicemos en este punto.

Paralelización de los cálculos de procesos

Camunda permite la ejecución concurrente de ramas de cálculos de procesos. Para ello, existe una pasarela especial denominada pasarela paralela, mediante la cual se puede dividir el flujo en paralelos o fusionar varios cálculos paralelos en un flujo. Está claro que para acelerar el flujo de un proceso, sería ventajoso delegar ciertas tareas a hilos paralelos. Si la lógica es independiente, puede ejecutarse en paralelo, por ejemplo, realizando peticiones simultáneas a sistemas externos y esperando las respuestas de todos ellos a la vez:

Cada vez en una pasarela de este tipo, habrá gastos generales asociados con la creación de nuevos hilos para la división de tareas y la fusión de los resultados. Uno puede encontrarse con varias excepciones de bloqueo y, por supuesto, no siempre es necesario o está justificado actuar siempre de esta manera, especialmente sin realizar pruebas, pero los beneficios son evidentes.

Con la ejecución secuencial, el tiempo de ejecución total es igual a la suma de los tiempos de ejecución de cada operación. En cambio, con la ejecución paralela, equivale al tiempo de ejecución de la operación más larga. Dadas las condiciones de respuestas no instantáneas de fuentes externas, reintentos y fallos, esta diferencia dista mucho de ser insignificante. Otra ventaja innegable es la forma de "reintentos libres", es decir, mientras se ejecuta la petición más larga, las demás tareas tienen hipotéticamente la oportunidad de fallar varias veces e intentar rehacer sus acciones sin que ello repercuta en el tiempo total de ejecución de la tarea.

Excepciones e intentos de repetición

¿En quiebra? Ocurre. La versión "out-of-the-box" de Camunda tiene la capacidad de reintentar una transacción fallida. Por "transacción", nos referimos al mecanismo interno de Camunda para ejecutar código delegado. El inicio de una transacción puede ser, por ejemplo, el marcador "async before" o "async after" de una tarea en el modelador. Cuando el motor encuentra este marcador, consigna su información en la base de datos e inicia un nuevo hilo asíncrono. Esto es importante. Para profundizar, por "transacción" entendemos la sección de ejecución entre las llamadas al método .complete() en TaskService, seguida del registro de la información en la base de datos. Estas transacciones, al igual que otras, son atómicas.

Cuando se produce una excepción técnica, es decir, cualquier error no comercial, por ejemplo, dividir por cero y olvidar una comprobación nula, la transacción hace un rollback e intenta empezar de nuevo. Por defecto, lo hace tres veces consecutivas sin pausas. Un intento de reintento comienza cuando surge una excepción regular, que en el mundo BPMN se llama una excepción técnica, no un BpmnError. Un BpmnError que surja detiene el proceso sin ningún intento de reintento. Imagínese cómo esto mejora la resistencia del proceso.

Tiene sentido maximizar esta característica. Por lo tanto, en cada delegado que solicita un sistema externo, se establecen estos marcadores, especificando el número de reintentos y la pausa entre ellos, y en el código del delegado se separa la lógica para cuando el proceso debe terminar y cuando no. Esto da un control total sobre el manejo de excepciones y los mecanismos de reintento. Como resultado, el proceso intenta rehacer la tarea fallida varias veces, y sólo después de una serie de fallos produce un error.

Quizás, el mayor reto sea el manejo de excepciones técnicas y errores relacionados con BPMN, así como el diseño de la lógica de su manejo para un flujo continuo del proceso. Ya hemos hablado de algunos errores relacionados con el manejo de respuestas de fuentes externas al hablar de la división en grupos de procesos. Nos gustaría recordarte que la misma llamada se encapsuló en un mini-proceso separado, y el principal o bien recibió una respuesta y siguió adelante o, debido a un tiempo de espera, siguió la ruta "No recibí respuesta".

Ahora, veamos ese pequeño proceso:

¿Ves el marco? Es un subproceso. Contiene tareas específicas y captura los errores lanzados por las tareas internas. Además, en tales marcos, el ejecutor de tareas es capaz de crear un trabajo para el temporizador, que establece el tiempo de ejecución para todo dentro del subproceso.

¿Cómo funciona? El flujo de ejecución llega al subproceso, crea un procesamiento de temporizador paralelo y espera a que se complete lo que hay dentro o, si el temporizador se agota antes, seguirá la ruta del temporizador. Si se lanza una excepción durante el proceso, que el marco del subproceso captura, el proceso detendrá su ejecución en la rama actual y seguirá la rama de error.

También es evidente que hay una opción para crear despachos de respuesta para peticiones críticas. Tenga en cuenta que la captura de errores sólo funciona para BpmnError con un código específico. Por lo tanto, técnicamente, es esencial capturar cualquier excepción y lanzar un BpmnError con el código requerido, que funciona para el ErrorBoundaryEvent.

El tratamiento de errores en el proceso principal funciona de forma similar. A partir de varias tareas, se seleccionan unidades lógicas que pueden colocarse en un marco de subproceso, con un oyente configurado para un código de error específico. Pero aquí hay dos matices. El primero es que la creación de múltiples ramas idénticas con tratamiento de errores, que sólo difieren en el código, es inconveniente. Si la estrategia de manejo de errores cambia o, por ejemplo, el registro, entonces muchos delegados en el esquema tendría que ser rediseñado, que no es deseable. Por lo tanto, uno podría considerar buscar subprocesos basados en eventos.

En esencia, se trata de un subproceso independiente del conjunto de procesos, que se inicia sólo cuando se produce un determinado evento al que está suscrito. Por ejemplo, si se suscribe un subproceso de este tipo al evento BpmnError con un código, digamos, MyCustomBusinessError, entonces cuando se produce este evento, el controlador se activará, y tras su finalización, el proceso terminará correctamente. Sí, no terminará con éxito, pero terminará correctamente. En estos subprocesos, usted también puede implementar diferentes lógicas de manejo para el mismo evento dependiendo de condiciones externas, por ejemplo, opcionalmente notificar sobre un error de aplicación cuando el proceso pasa un punto condicional.

El segundo matiz es mucho más complicado. En la vida real, el ciclo de vida de cada proceso se divide probablemente en dos etapas comerciales: antes de la generación de leads y después de ella. Si se produjera un error antes de formatear los datos para convertirlos en un lead, probablemente bastaría con finalizar el proceso, notificando las dificultades encontradas. Una vez generado el lead, esto ya no es posible.

Tampoco recomendamos terminar los procesos si surgen obligaciones legales durante el proceso, por ejemplo, si se firma un contrato. ¿Cómo gestionamos estos errores? Algunos errores técnicos, como los asociados a la indisponibilidad de servicios externos, se gestionan mediante reintentos automáticos dentro de un tiempo de espera acordado previamente. Pero, ¿qué ocurre si el proceso se ha bloqueado, han pasado los reintentos, pero el hipotético microservicio externo sigue sin funcionar?

Optimización manual

Llegamos al concepto de resolución manual o, también conocido como, compensaciones.

¿Cómo funciona? Se captura cualquier error, se da a los delegados la oportunidad de reintentarlo si es necesario, y si la suerte sigue sin favorecerles, el proceso pasa a un estado de error, pero con el código apropiado, por ejemplo, COMPENSATION_ERROR. Este código es capturado por otro subproceso basado en eventos, que procesa, registra, notifica y, lo que es importante, no puede fallar inesperadamente. Sólo donde está diseñado, lanza una excepción técnica incatchable y se estrella en un incidente.

¿Por qué hacerlo así? Para la supervisión, puede utilizar EXCAMAD, un panel de administración externo para Camunda, análogo a Cockpit, con potentes funciones. Destaca en rojo los procesos en incidencias. Estos procesos pueden modificarse o reiniciarse desde el punto deseado. Por ejemplo, puede colocar el valor variable necesario en el contexto y reiniciar el proceso desde el punto justo después del problemático. Esto es cómodo, sencillo y permite la resolución manual de problemas con el mínimo esfuerzo.

Automatización de procesos empresariales con Camunda: ejemplos reales

Conocida por su plataforma de código abierto y su interfaz fácil de usar, Camunda ha permitido a numerosas empresas optimizar sus flujos de trabajo. Veamos algunos ejemplos reales.

Banca y Finanzas

Münchener Hypothekenbank eG, Camunda un banco inmobiliario independiente, pasó a utilizar el motor de flujo de trabajo de Camunda para mejorar y automatizar los procesos internos, en concreto la gestión del correo y la coordinación interdepartamental de las solicitudes de préstamo. Anteriormente, su sistema era rígido, carecía de flexibilidad y generaba complejidades que aumentaban las tasas de error.

En su avance hacia una arquitectura de microservicios basada en Java, seleccionaron Camunda basándose en recomendaciones internas y colaboraron estrechamente con WDW Consulting Group. Algunas ventajas que obtuvieron inmediatamente de Camunda eran funciones listas para usar, mientras que otras necesitaron más desarrollo. Esta transición dio lugar a una lista de tareas centralizada utilizada por todo el personal y proporcionó flexibilidad para mantener procesos individuales sin afectar a otros.

El resultado más notable ha sido una mejora significativa de la velocidad de tramitación de las solicitudes de préstamo. Esto beneficia tanto al personal como a los clientes finales. Como prueba de su éxito, otros departamentos están considerando la posibilidad de adoptar Camunda, y el banco ha contratado incluso a más desarrolladores para seguir apoyando su implantación.

Seguro

SV Informática, SV SparkassenVersicherung, filial de SV SparkassenVersicherung, está especializada en soluciones informáticas a medida para empresas de seguros. Incorporaron Camunda para automatizar varios procesos en todos los departamentos, lo que permitió un notable ahorro de tiempo y mejoró los tiempos de respuesta al cliente. La compañía adoptó Camunda en 2018 como una solución a su búsqueda de una herramienta eficaz de modelado de procesos de negocio, con un enfoque en la mejora de los procesos y la mejora de la colaboración entre TI y otros departamentos.

Desde su implantación, Camunda ha automatizado tareas como la cancelación de pólizas de seguros de automóviles y la solicitud de documentos de pólizas. Un logro notable fue el procesamiento automatizado 80% de los informes en línea de daños causados por tormentas. Esto resultó especialmente valioso durante las inundaciones y tormentas de 2021 en Alemania. Herramientas como Camunda Optimize y Camunda Cockpit facilitan la supervisión y optimización de los procesos.

Hospitalidad

En 2020, el Grupo SV, que opera en Alemania, Suiza y Austria, lanzó una plataforma digital disruptiva llamada "likeMagic" con la ayuda de Camunda. Esta plataforma proporcionó una experiencia sin fisuras a los huéspedes, desde la reserva hasta la salida, con resultados como una tasa de autocheck-in/out del 95% y una puntuación de felicidad de los huéspedes de 9 sobre 10. La innovación redujo las necesidades de personal e integró a la perfección plataformas como Airbnb. Al reconocer su potencial, SV Group ofreció "likeMagic" a otros proveedores de servicios hoteleros. En 2023, pasaron de 2 a más de 30 clientes en la región DACH, con planes para ampliar su alcance en Europa y alcanzar las 15.000 habitaciones a finales de año.

Conclusión

El potencial transformador de Camunda no reside únicamente en sus funcionalidades básicas, sino en su capacidad para redefinir las operaciones empresariales a un nivel fundamental. Combinado con Spring Boot, abre una puerta a integraciones sin fisuras y a una escalabilidad mejorada. Comprender los entresijos de BPMN es fundamental para aprovechar todo el potencial de Camunda. A medida que las empresas evolucionan en esta era digital, herramientas como Camunda destacan, ofreciendo soluciones dinámicas que pueden pivotar y adaptarse a las necesidades siempre cambiantes. No se trata sólo de automatizar procesos, sino de innovar los flujos de trabajo, mejorar la eficiencia e impulsar resultados tangibles que marquen la diferencia. Adopte el poder de Camunda y deje que su empresa se eleve a nuevos horizontes.

Dmitry Nazarevich CTO

Date: 17 de enero de 2024

Índice

Valora este artículo:

★★★★★ 4/5

4,8/5 (45 opiniones)

Contenidos relacionados

Blog

Cómo elegir un sistema ERP: explorando los mejores sistemas ERP en 2024

Blog

Looker vs Power BI - Revolucionando la industria de cubiertas pequeñas

Comparación entre Looker y Power BI: presentación de la herramienta de BI

Blog

Por qué contratar desarrolladores de software junior para sus proyectos

Blog

Cómo elegir el socio adecuado de nearshoring de IT: consejos para consultores de IT en Europa

Blog

$Por qué es probable que su proyecto fracase sin BA$

Por qué es probable que su proyecto fracase sin un especialista en BA

Blog

$Por qué fracasan los proyectos IT$

Por qué fracasan los proyectos IT

Contáctenos

Nombre

Empresa

Correo electrónico

Teléfono

Mensaje Por favor, facilítenos detalles del proyecto, duración, tecnologías, especialistas informáticos necesarios y otra información relevante.

Grabe un mensaje de voz sobre su proyecto
para ayudarnos a comprenderlo mejor.

Adjunte los documentos adicionales si es necesario

Cargar archivo

Puede adjuntar hasta 1 archivo de 2 MB en total. Archivos válidos: pdf, jpg, jpeg, png

Le informamos de que cuando haga clic en el botón Enviar, Innowise procesará sus datos personales de acuerdo con nuestra Política de privacidad con el fin de proporcionarle la información adecuada.

¿Qué pasa después?

Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallar las necesidades de su proyecto y firmar un acuerdo de confidencialidad que garantice la confidencialidad de la información.

Después de examinar los requisitos, nuestros analistas y desarrolladores elaboran una propuesta de proyecto con el alcance de las obras, el tamaño del equipo, el tiempo y las estimaciones de costos.

Concertamos una reunión con usted para discutir la oferta y llegar a un acuerdo.

Firmamos un contrato y comenzamos a trabajar en su proyecto lo más rápido posible.

Automatización de procesos empresariales con Camunda: implantación tolerante a fallos de esquemas BPM

¿Qué es Camunda?

Camunda, Spring Boot y BPMN: comprender los conceptos