CAPATAZ BPM es el nuevo lanzamiento de nuestra marca. Muchos de ustedes se preguntarán en qué se diferencia o cómo amplía las potencialidades del resto de nuestros productos. En definitiva, ¿qué es CAPATAZ BPM?
Primero vamos con BPM, para los que no están familiarizados con la sigla, BPM es un acrónimo de Business Process Management, en español algo así como Administración o Gestión de Procesos de Negocio.
CAPATAZ BPM entonces es un nuevo producto de CAPATAZ Software capaz de hacer precisamente eso: Administrar Procesos de Negocio en su Organización.
¿Cómo se implementa CAPATAZ BPM?
El software permite modelizar o crear un WorkFlow o flujo de trabajo consistente en una secuencia interconectada de Estados y Eventos que aplicados a determinados Estados pueden generar un cambio de Estado. Esto puede resultar un trabalenguas, así que veamos un ejemplo simple y concreto de modelado en CAPATAZ BPM:
En el ejemplo expuesto, hemos modelado un circuido o WorkFlow extremadamente simplificado para el seguimiento de Reclamos de Clientes. En dicho WorkFlow hemos identificado 3 estados y 2 eventos, los cuales hemos simplemente habilitado o inhabilitado (sencillamente modificando la propiedad Activo) a partir de un conjunto de Estado y Eventos ya pre-cargados y listos para usar en la Configuración de WorkFlows que CAPATAZ BPM provee.
Allí también definimos relaciones de los eventos que serán posibles dado cada estado del reclamo: por ejemplo, que sólo se pueda Cerrar un Reclamo cuando esté en estado Iniciado, esto implica en la práctica de este ejemplo que sólo podremos Cerrar un Reclamo cuando al menos ya haya recibido una novedad, puesto que el evento Registrar Novedad cambia el estado del Reclamo a Iniciado. En detalle así son los Estados y Eventos activados para nuestro ejemplo:
ESTADOS
• Generado: cuando damos de alta un reclamo con un título o resumen, más opcionalmente una amplia descripción del mismo.
• Iniciado: para indicar que el reclamo ya recibió una o varias novedades, es decir que el reclamo está en curso o está siendo atendido.
• Cerrado: para indicar la finalización del reclamo.
EVENTOS
• Registrar Novedad: para poder ingresar una nota con cualquier contenido referido al incidente, por ejemplo, comunicaciones con el cliente, sus manifestaciones, nuestras acciones o respuestas, etc. Como se desprende del gráfico este evento sólo podemos ejecutarlo sobre reclamos en estado Generado o Iniciado.
• Cerrar: para poder dar por finalizado un reclamo, sólo podremos ejecutar este evento cuando un reclamo está en estado Iniciado.
¿Podemos expandir o mejorar este circuito, luego de que lo hemos comenzado a usar?
La respuesta corta es: Sí. La respuesta larga es: Síííííííííííííííííííííííííííí.
Dejando de lado la broma, sí que podemos, por ejemplo podríamos activar más eventos y estados propuestos por CAPATAZ BPM al circuito para reflejar con más detalle lo que va ocurriendo paso a paso con cada reclamo. En nuestro ejemplo activemos ahora 3 nuevos eventos y definamos sus relaciones de modo tal que:
• Modificar: evento aplicable sólo al estado Generado para poder modificar el contenido del reclamo, podríamos también habilitarlo para el estado Iniciado pero no lo haremos para mantener la simplicidad del ejemplo.
• Reabrir: un nuevo evento para poder volver atrás un cierre de Reclamo puesto que el cliente por ejemplo aún no quedó conforme con nuestra respuesta o acción o simplemente porque lo hemos cerrado por error.
• Asignar: es un evento Especial en CAPATAZ BPM que al ejecutarlo solicita indicar a quién o quienes estamos asignado el elemento del WorkFlow (en nuestro caso un Reclamo de Cliente) de modo tal que el o los involucrados en dicha asignación reciban una notificación vía CAPATAZ Mobile y/o vía e-mail.
Ahora el gráfico que nos mostrará CAPATAZ BPM, luego de introducir estos cambios es:
Vemos aquí el nuevo circuito posible y que el evento Asignar está diferenciado con el color azul. Esta diferenciación está planteada por la naturaleza especial de dicho evento ya incorporado en CAPATAZ BPM que podemos utilizar, como ya dijimos, para hacer responsable a alguien del seguimiento y/o atención del reclamo al tiempo que este es notificado electrónicamente vía CAPATAZ Mobile (Android App) y/o vía e-mail.
Hasta aquí, todo lo hemos hecho utilizando, habilitando o inhabilitando Estados y Eventos estándares ya provistos por CAPATAZ BPM y listos para usar, ¿pero aquí terminan nuestras posibilidades? No.
¿Podemos crear nuestros propios Estados y Eventos?
Otra vez la respuesta es afirmativa. Supongamos que ahora queremos incorporar más detalle y conocer cuando un reclamo ya ha recibido una acción de nuestra parte, definiendo de este modo que dicho reclamo está atendido.
Agregaremos entonces un Estado y un Evento para tal fin, ambos serán identificados por CAPATAZ BPM como Personalizados, es decir, creado por usted mismo, quedando:
• Estado personalizado Atendido: para indicar que el reclamo ya ha recibido una acción de atención de nuestra parte.
• Evento personalizado Acción: para registrar el contenido de la acción realizada tendiente a solucionar el reclamo.
Hecho esto, volvemos a solicitar a CAPATAZ BPM que grafique nuestro WorkFlow, y esto es lo que obtendremos ahora en colores de tonalidad anaranjado nuestro Estado y Evento personalizado:
Resumen de Características de CAPATAZ BPM
Utilizadas en el ejemplo de esta nota:
• Conjunto de Estados y Eventos pre-cargados listos para usar.
• Posibilidad de cargar nuevos Estados y Eventos, es decir Personalizados.
• Definir fácilmente la secuencia necesaria, dada por la relación Eventos Aplicables a Estados.
• Generación del Gráfico del WorkFlow:
– Imprimible
– Exportable en formatos de imagen: BMP, PNG, JPG, etc.
Otras potencialidades con las que cuenta CAPATAZ BPM:
• Posibilidad de Relacionar de manera obligatoria o no, otras Entidades de CAPATAZ o TANGO Gestión, por ejemplo:
– Clientes
– Proveedores
– Artículos
– Partidas
– Series
– Máquinas
– Operarios
– Sectores
– Depósitos
– Ubicaciones de Depósitos
• Posibilidad de definir una lista personalizada de “Tipos” para clasificar cada elemento gestionado por el WF (en nuestro ejemplo cada Reclamo).
• Posibilidad de definir una lista personalizada de “Prioridades” para luego marcar cada elemento gestionado por el WF (en nuestro ejemplo cada Reclamo).
• Posibilidad de definir una lista personalizada de “Textos” frecuentes o típicos, para luego poder agregarlos fácilmente a cada elemento sin tener que reescribirlos cada vez.
• Posibilidad de Definir Comportamientos de Eventos, tales como:
– Solicitar Confirmación o no.
– Editar, Mostrar u Ocultar Usuario
– Editar, Mostrar u Ocultar Fecha
– Editar, Mostrar u Ocultar Nota
– Limpiar una asignación previa
• Asignar Íconos Personalizados a cualquier evento.
Por último, saludos y agradecimiento a todos los que siguen nuestro blog, hasta la próxima nota.
Latest posts by Mauricio Ulla (see all)
- API de CAPATAZ Software (II) - 22 mayo, 2017
- ¿Qué es CAPATAZ BPM? - 10 mayo, 2017
- API de CAPATAZ Software (I) - 29 noviembre, 2016
Se puede restringir a ciertos usuarios la posibilidad de realizar un evento en cierto estado? Por ejemplo: que un evento «Autorizar» que cambie el estado de «Iniciado» a «Autorizado» pueda ser realizarlo un usuario solo.
Esa posibilidad está ya diseñada pero aún no implementada, en las próximas versiones, más tardar la de Jun o Jul, estará!!!
Mientras tanto podrías solucionarlo con Personalización en el Botón del Evento (Tratamiento_ANT) colocando un código como el siguiente:
*** INI - Código de Ejemplom.vf = INLIST(UPPER(m.fo.usuario),"FULANO","MENGANO","SULTANO")
IF NOT m.vf
m.cb.xmb_informar(15, "Usuario no autorizado para "+m.cb.ToolTipText+CHR(13)+"Usuario: "+UPPER(m.fo.usuario), "EX")
ENDIF
*** FIN - Código de Ejemplo
Para más información de como introducir este código de Apertura o Personalización en un botón de ToolBar de CAPATAZ, consultarlo con nuestra Mesa de Ayuda mesadeayuda@ulasoft.com.ar
Algunas herramientas que he utilizado en otros BPMs y que he explotado bastante.
1. Poder disparar un «Ticket» de un WF desde algún origen externo, por ejemplo:
– Resultado de una query (como vimos con las alarmas)
– Chequeo de una casilla de Mail
– WebServices
2. Poder interactuar con un Ticket de un WF, por ejemplo, pasar de un estado a otro a través de un Mail. Por ejemplo, se envía un aviso de aprobación de un Pedido por mail al gerente y si hace click en un link del mail se lo redirecciona a una web donde ingresa sus credenciales o se da el mail como «de confianza» y se aprueba el Pedido, pasando al siguiente Estado.
3. Cuando se trabaje con las condiciones de un ticket dentro de un WF, que se puedan utilizar los datos del Ticket, incluyendo los campos adicionales dentro de la condición.
4. Disparar un reporte ante un cambio de estado de un Ticket de un WF. Ejemplo: Cuando se aprueba la OT, que se emita por impresora.
Gracias Sergio! Excelente tu aporte.
Te cuento como están estas cosas en nuestros planes y otras cosas también… 🙂
Básicamente, lo que nos comentás en Diseño los vemos como dos funcionalidades o aspectos:
A) puntos 1 y 2: entendemos que tienen que ver con que el WorkFlow responda ante eventos externos
B) puntos 3 y 4: tienen que ver con acciones en el WorkFlow que provoquen eventos o información hacia el exterior.
Honestamente lo primero, si bien lo conocemos como una posibilidad, no se ha tenido en cuenta en nuestros análisis, ni siquiera en una prefactibilidad, en cambio lo segundo, sí.
Respecto a emitir información hacia el Exterior, algo ya está disponible CAPATAZ BPM de forma natural, esto es: las Notificaciones de Eventos de CAPATAZ. Sin embargo, nuestra pretensión de funciones que impacten externamente del WorkFlow no terminan allí, nuestra idea es poder desencadenar eventos de CAPATAZ a partir de la ocurrencia de determinado estado del BPM, ejemplo: Ante tal o cual evento, que se genere una OT, Orden de Compra, Pedido, Libere una Partida, Ajuste in inventario, etc. Es un desafío grande pero es a lo que finalmente deseamos llegar.
Venimos trabajando hace tiempo en CAPATAZ BPM para poder lanzarlo al Mercado y que sea útil/usable, pero eso no significa que nuestro trabajo ha terminado ahí.
Lo que si fue prioritario en nuestro Diseño, y es la principal ventaja frente a cualquier otro BMP del Mercado, es la Integración Nativa a las Entidades del CAPATAZ y TANGO Gestión, y esto ya es possible desde la version de Abril de este año.
Te contamos además que hay muchas otras funcionalidades que estamos mes a mes incorporando en este 2017, y éste es nuestro cronograma propuesto de mejoras o nuevas funcionalidades:
- Documentos Adjuntos: funcionalidad extendida en todo CAPATAZ que aún no tenemos en BPM, y que nobleza obliga integrarla tanto al Elemento Ticket como a cada uno de los eventos posibles.
- Pre-Condiciones de Eventos: posibilidad de condicionar la ocurrencia de un evento, según el resultado de un Query. Relacionado a tu comentario del punto 3, como lo tenemos pensado, sí podras utilizar esos campos personalizados para inclurilos en el query de la condición.
- Post-Condiciones de Eventos: posibilitad de condicionar el estado resultante.
- Permisos de Eventos por Usuario.
- Campos Personalizados:
a) a nivel Cabecera del Elemento Ticket
b) a nivel del Detalle del Elemento Ticket
c) en cada Evento
- Desencadenar Eventos/Información desde el WorkFlow (símil lo comentado en tu punto 4).
Comparto contigo además, que con apenas 4 releases en la calle, y debido a la política comercial para todo 2017 que consiste en que todo cliente que Actualice su CAPATAZ o Extienda su Actualización está recibiendo Gratis CAPATAZ BMP, ya hay muchos clientes que están aportando muchísimo y variado feedback. Los comentarios y sugerencias de esos usuarios es «oro en polvo» y por ende nuestra prioridad, por eso que la lista planeada de cambios y mejoras puede verse alterada en su contenido y orden según lo que estos usuarios actuales y futuros de CAPATAZ BPM comenten.
Esperamos también introducir el próximo año funcionalidades más sofisticadas y extensas, quizás como las que expusiste en tus puntos 1 y 2!!!
[…] Gestionar BPM (Tickets) y armar tu propio flujo de […]