Arquitectura de negocio ejecutable, con conformidad verificable.
Dexon Architect convierte la arquitectura de la organización en un objeto operable: no un repositorio de diagramas que alguien consulta antes de un comité, sino el modelo contra el cual corre la operación real. Es lo que los analistas llaman un gemelo digital de la organización, sobre Dexon BPM: los procesos que el modelo declara son los que el motor ejecuta, así que el modelo no puede separarse de la operación.
Siete eslabones, siete editores, un solo repositorio.
La arquitectura de negocio ejecutable solo significa algo si los artefactos son los objetos que la plataforma ejecuta. En Dexon Architect el mapa estratégico, el mapa de capacidades, el catálogo de servicios con sus ofertas, la ficha del proceso con su BPMN, el modelo de datos y la ficha del indicador son cada uno un editor de primera clase — no siete herramientas que se pasan archivos, sino siete vistas de un mismo repositorio, gobernado por un metamodelo que declara qué puede relacionarse con qué.
Por eso un cambio en uno se ve en los demás, y por eso «¿a qué capacidad responde este proceso?» tiene respuesta por consulta y no por comité. Pregunte «¿qué servicios quedan expuestos si este componente falla?». En un repositorio documental, la respuesta depende de que alguien haya mantenido el diagrama al día. Aquí es una consulta, y refleja la configuración vigente, porque no hay una segunda copia.
La administración es predominantemente sin código. Existen expresiones de bajo código para campos calculados y reglas, donde una expresión es de verdad la forma más clara de decir algo — pero la configuración estándar de un cliente no requiere cambiar el código fuente, que es lo que la hace revisable, migrable y capaz de sobrevivir a una actualización.
Un solo modelo
Cuatro alturas sobre la misma organización
No cuatro herramientas con cuatro exportaciones. Un modelo al que se le hace zoom, donde cada nivel condiciona al siguiente y el editor impone las reglas que lo mantienen analizable.
Cadena de valor
El mapa de nivel uno, partiendo de una plantilla Porter o ITIL y renombrado al lenguaje del cliente. Declara a quién se entrega el valor y quién lo evalúa —sus grupos de valor y de interés— y sus enunciados de valor del servicio y de valor público. Es el marco del que cuelga todo lo demás.
Mapa de capacidades
Lo que la organización debe saber hacer. Los paquetes son sustantivos y las capacidades hoja son verbos de acción; el tipo y la criticidad viven solo en las hojas; las capacidades son disyuntas y de granularidad pareja. El editor lo impone, porque un mapa de capacidades con nombres de proceso y secuencias temporales adentro no se puede analizar — y así es como terminan casi todos.
Ficha del proceso
Se llena antes de dibujar nada: identidad y propósito, el objetivo formal, la clasificación, la unidad organizacional dueña y la fecha de aprobación, el servicio que materializa, las capacidades que orquesta y el SIPOC. Un proceso que no puede declarar su posición en la cadena no recibe diagrama.
BPMN
Las trayectorias. Cada fin es un resultado esperado o una excepción gobernada; cada elemento del diagrama justifica qué aporta al objetivo, a una restricción, a un dato, a una regla, a un riesgo o a un indicador. Una compuerta sin datos y regla declarados no es una decisión: es ambigüedad dibujada.
Lo que incluye el producto
Cada eslabón de la cadena, y el editor donde vive
Dexon Architect incluye Dexon BPM: lo que aquí se modela es lo que el motor ejecuta. Lo que sigue no es una lista de funcionalidades: es la secuencia de un despliegue.
Estrategia →
Una visión con su meta grande y ambiciosa y su descripción vívida; objetivos, metas e indicadores con sus dependencias en un grafo; cuadro de mando integral; iniciativas con fechas reales que alimentan un Gantt. Aquí es donde un objetivo estratégico deja de ser una lámina y pasa a ser algo a lo que un proceso se puede trazar.
Mapa de capacidades →
La abstracción estable de lo que la organización hace, independiente del organigrama y de los sistemas. Cada capacidad declara qué servicios la implementan, qué procesos la materializan y qué sistemas la soportan, y de ahí sale un mapa de calor: dónde se concentra la inversión tecnológica y qué capacidades críticas están sin soporte.
Catálogo de servicios y ofertas →
Un servicio lleva dueño, propuesta de valor, criticidad, costo, las capacidades que lo implementan y los elementos de configuración que lo soportan. La oferta es la forma concreta y solicitable: su proceso, su formulario, su acuerdo de nivel de servicio y su precio. Un mismo servicio se ofrece de varias maneras sin duplicar el proceso que lo ejecuta, y nada llega al portal hasta que la oferta está completa.
El objetivo formal →
Un objeto estructurado en la ficha del proceso, no un párrafo: los grupos de interés que reciben el valor; resultados esperados enunciados como estados de negocio; un criterio de satisfacción por resultado con meta, tolerancia, sentido y fuente declarada; restricciones tipificadas; y los riesgos que condicionan el diseño. Un proceso se aprueba solo cuando esa especificación se satisface de forma fuerte.
Modelador de procesos →
Cadena de valor, mapa de procesos por bandas y macroprocesos, ficha del proceso con su SIPOC, y un editor BPMN que importa y exporta BPMN 2.0 y otros formatos de intercambio. Lo publicado se ejecuta: enrutamiento por fórmula sobre los datos del caso, uniones que esperan a una o a todas sus predecesoras, y subprocesos lanzados uno por cada registro de una tabla.
Simulación, ejecución y costo →
Cada ficha de proceso compara lo ejecutado con lo diseñado: transiciones fuera del diseño, trayectorias diseñadas que nadie recorre, los caminos más frecuentes y la carga de cada uno, y la duración real contra la esperada por actividad. Simula escenarios Monte Carlo sobre las duraciones medidas y la frecuencia real de cada rama, y compara el escenario base con los alternativos por mediana y peor caso (p50, p90). Y calcula el costo del proceso por actividad y por técnico a partir del trabajo medido y de las tarifas de los recursos, con un mapa de calor de costo y valor sobre el mapa de capacidades.
Un tablero por proceso →
Cada proceso tiene su propio tablero ponderado con los indicadores que le aportan, subprocesos incluidos. El mapa de procesos muestra un semáforo en cada proceso y el puntaje agregado de cada macroproceso y banda, y el semáforo de un proceso abre su tablero.
Aceleradores de implementación →
La cadena de valor parte de una plantilla ITIL o Porter y el mapa de capacidades de un mapa de referencia; una arquitectura de procesos existente —bandas, macroprocesos, procesos y subprocesos— se importa desde una hoja de cálculo, que muestra qué se va a crear y qué ya existe. La implantación misma nace como un proyecto con una actividad por cada paso del método, y una etapa no cierra mientras el verificador de conformidad encuentre fallas en ella: Dexon se implanta con Dexon.
Organización, lugares y grupos de interés →
El organigrama con sus unidades y roles, las sedes con su calendario laboral y el registro de grupos de interés. La unidad es a lo que se alinean los indicadores; la sede fija el calendario y los festivos que descuenta el motor de niveles de servicio; los grupos de interés son a quienes los objetivos de proceso declaran servir, y el viaje de cada grupo se mapea, etapa por etapa, sobre los procesos que lo atienden.
Registro de riesgos →
Los riesgos se registran contra el objeto que amenazan —un proceso, un servicio, una capacidad— con su valoración y su tratamiento. El objetivo de cada proceso declara los riesgos que condicionan su diseño, así que el registro es parte del diseño y no un inventario que se revisa una vez al año.
Indicadores alineados →
Todo indicador declara su fórmula, fuente, meta, periodicidad, responsable, ancla de medición y su alineación con la unidad organizacional y con el objetivo estratégico al que contribuye. Esa alineación muestra qué parte de una meta institucional sostiene qué unidad con qué proceso — y la meta que nadie sostiene.
Modelo ontológico de datos →
Más de mil entidades documentadas antes de que usted agregue una, recorribles por dominio y con un grafo de vecindario. Describa lo que necesita en lenguaje de negocio y la búsqueda le muestra, con puntaje, las entidades que ya se le parecen: así un modelo de datos deja de acumular cuatro tablas para lo mismo. Cada entidad declara su dueño del dato y si es crítica, y el verificador de conformidad exige un dueño con nombre en toda entidad crítica.
Roles y perfiles →
Permisos por función, para que «quién puede cambiar el mapa de capacidades» tenga una respuesta gobernada y ningún perfil de cliente sea todopoderoso. Es la diferencia entre una arquitectura que se puede entregar y una que depende de quien la configuró.
El verificador de conformidad
La conformidad es una pantalla, no un comité
Quince reglas de integridad del metamodelo, evaluadas sobre todo el repositorio con su informe de hallazgos: trece por máquina, y la revisión de las decisiones de diseño y la reevaluación de impacto tras un cambio como comprobaciones manuales gobernadas en el mismo informe. Cada hallazgo abre el editor donde se corrige. Córralo al cerrar una etapa y es la lista de verificación de salida; córralo en un comité de gobierno y es la agenda. Pídalo en cualquier evaluación comparativa: separa un repositorio de modelos de una arquitectura que se gobierna.
| Qué revisa | Qué encuentra |
|---|---|
| Que el proceso responda a una capacidad y materialice un servicio | El proceso huérfano cuyo propósito nadie sabe enunciar — el hallazgo más común el primer día |
| Que el servicio declare las capacidades que lo implementan y los elementos de configuración que lo soportan | Una entrada del catálogo sin nada detrás, y una falla cuyo impacto nadie puede consultar |
| Que la oferta esté completa: visible, vigente y con proceso publicado | Una entrada del portal que nadie puede solicitar de verdad |
| Que el objetivo sea verificable | Un proceso aprobado sobre un objetivo sin criterios, sin umbral y sin fuente declarada |
| Que el mapa de capacidades esté bien formado | Nombres de proceso y secuencias temporales dentro de un mapa que debía ser estable |
| Que cada proceso tenga un dueño y una fecha de aprobación | Un proceso que todos usan y del que nadie responde |
| Que cada actividad declare un ejecutor tipificado | Trabajo que ocurre sin que nadie, ni nada, responda por él |
| Que toda trayectoria cierre en un resultado o una excepción gobernada | La rama que no termina en ninguna parte y se resuelve por correo |
| Que cada compuerta declare la pregunta que responde, sus datos y su regla | Una decisión que nadie puede reconstruir un año después |
| Que toda entidad capturada tenga propósito y descripción | Un modelo de datos que creció como campos de formulario |
| Que todo indicador esté anclado a un objeto y a un atributo declarado | La métrica flotante, que no mide nada en particular y no responde ninguna pregunta |
| Que todo cambio se haya evaluado por impacto antes de hacerse | La ruptura silenciosa aguas abajo |
Precisión
Las distinciones que este producto preserva
Palabras que en una conversación comercial se usan como sinónimos y que en una implementación significan cosas muy distintas.
En la hoja de ruta
Lo que llega, y cuándo
Cada capacidad está disponible para una demostración o una prueba de concepto desde el mes indicado.
Causa raíz y recomendación de acción
Explicar por qué se movió un indicador, qué casos lo explican y qué acción conviene tomar.
La prueba
El mismo repositorio ejecuta una mesa de servicio certificada
Dexon ServiceDesk está construido sobre Dexon BPM, sobre el mismo repositorio que modela Dexon Architect. El servicio que el usuario solicita en el portal de ServiceDesk es el servicio que aquí se modela, enlazado a la capacidad que sirve y al proceso que ejecuta el motor; el elemento de configuración de la CMDB es el objeto que la arquitectura relaciona con ese proceso. Pink Elephant certificó Dexon BPM en doce procesos ITSM que corren sobre ese repositorio: la evidencia más clara de que lo que aquí se modela se ejecuta.
Ver los doce procesos certificados →Las capacidades de Dexon BPM, incluidas
Workflow
Enrutamiento condicional, tareas en paralelo, aprobadores dinámicos, plazos sobre calendarios laborales e historia de solo anexado — el mismo motor para todos los tipos de registro.
ETL e integración
API REST, intercambio programado y por eventos con bases de datos, archivos y servicios web, más directorio, correo y descubrimiento — con el origen autoritativo de cada atributo registrado.
Documentos
Árboles de versiones, permisos, búsqueda por contenido, firma con sello de tiempo — con requisitos documentales exigidos como condiciones que el flujo no pasa sin cumplir.
BI e indicadores
Tableros bajo objetivos estratégicos, metas por período, descenso del agregado al registro fuente, y proyección que nunca sobrescribe una medición.
Gestión de activos de TI
Inventario con el Agente Dexon, una CMDB que se mantiene sola, descubrimiento de red por SNMP, licenciamiento sobre uso real y control remoto registrado en el caso.
Traiga un proceso y le dibujamos su cadena
Uno suyo, con sus excepciones incómodas. Llenamos la ficha, enunciamos el objetivo formal, modelamos las trayectorias — y después corremos el verificador delante de usted: un hallazgo, su corrección y el verificador otra vez. Es la demostración menos halagadora que podemos ofrecer, y por eso la ofrecemos.