Oracle EPM Cloud Planning · Agentes de IA
Soporte de Oracle EPM Planning, resuelto por agentes de IA.
Un agente especializado trabaja tu instancia real de Oracle EPM Cloud: la lee y, sólo con tu aprobación, la modifica. Jobs fallidos, reglas Groovy, dimensiones y forms, diagnosticados con evidencia y explicados en español o inglés.
Todo cambio en producción requiere la aprobación de una persona.
Un ticket, resolviéndose solo
La carga agregada semanal falló parcialmente tras el job nocturno
M. Duarte · FP&A
▸ classify TCK-4182
incident_diagnosis · es · 0.94
▸ ticket_history_search "Agg_Load_FY26"
2 tickets relacionados · última importación de metadatos hace 6 días
▸ epm_get_job_log Agg_Load_FY26 · paso 34 de 61
essbase 1203380 — miembro "FY26_Act" no encontrado en Planning_Actual
Causa raíz
La importación de metadatos del martes pasado renombró un miembro a FY26_Actual. Dos scripts de cálculo en Groovy y la regla del agregador todavía apuntan al alias anterior, y por eso la corrida falla en el paso 34.
Esperando tu aprobación
epm_run_business_rule · BR_Refresh_AliasRefs · prod
▸ epm_run_job Agg_Load_FY26
61 de 61 pasos completados
La carga nocturna volvió a estar en verde. La causa fue el renombrado de un miembro en la importación de metadatos del martes: tres referencias seguían usando el alias anterior. Las actualicé, volví a correr el job y los 61 pasos completaron. No se cambió nada en producción sin tu aprobación: la escritura fue BR_Refresh_AliasRefs y quedó en la bitácora de auditoría.
Respondido en español, el idioma en que llegó el ticket
Incidente ilustrativo, compuesto a partir de las fallas que el agente sabe atender.
Funciona donde ya están tus tickets
El agente lee de los sistemas que tu equipo ya usa y responde en el idioma en que tus solicitantes ya escriben.
Oracle EPM Cloud
Planning, vía la API REST v3
Jira Cloud
Lee y responde en tu cola
Tu propio portal
Captura sin migración
Documentación de Oracle
Lo único que puede consultar
El problema
El soporte de Oracle EPM es caro, lento y difícil de repetir.
El trabajo no es glamuroso, y esa es la gracia: es el mismo trabajo, una y otra vez, y aterriza en las pocas personas que conocen bien el sistema.
El conocimiento está en una sola persona
Una regla que se rompe al guardar un form la entiende quien la depuró la última vez. Cuando esa persona no está, el ticket espera.
Una carga de las 2am se descubre a las 9am
Nadie está mirando la consola de jobs de madrugada, y la primera persona en ver la falla suele ser la que tiene una entrega esa misma mañana.
Horas senior en el primer nivel
Buena parte del volumen son preguntas e incidentes repetibles. Eso llega siempre a la persona más cara disponible, todas las veces.
El conocimiento no viaja
Casi toda la documentación de Oracle EPM está en inglés. Buena parte de quien levanta los tickets no lo está. La traducción no está presupuestada, entonces no ocurre.
Cómo funciona
Cuatro pasos, y los que se niega a dar solo.
Llega el ticket
Desde Jira o desde tu propio portal, en el idioma en que lo escribió el solicitante. Sin plantillas, sin reestructurar formularios y sin migración.
Se clasifica
Un clasificador barato y sin herramientas ordena el ticket y detecta su idioma. Por debajo del umbral de confianza se enruta a una persona en lugar de adivinar.
El agente investiga
Herramientas tipadas leen tu instancia real: aplicaciones, dimensiones, miembros, jobs y logs, además de la base de conocimiento y el historial de tickets.
Responde o escala
Una respuesta en el idioma del solicitante, con la evidencia detrás. Lo que queda fuera de alcance es un reporte para una persona, nunca una improvisación.
Qué resuelve
El trabajo que llena una cola de soporte de EPM.
Cada grupo es una habilidad que el agente carga para el ticket que tiene delante, no una promesa genérica.
Jobs y logs
Jobs fallidos o parciales, datos faltantes, la consola de jobs y las cargas programadas.
- Estado del job y logs paso a paso
- Corridas de agregador e integración de datos
- Fallas recurrentes rastreadas hasta un cambio
Reglas de negocio
Groovy, rulesets, resultados de cálculo y los errores que arrojan.
- Scripts de cálculo en Groovy y prompts de runtime
- Códigos de error de Essbase y qué significan aquí
- Por qué una cifra no cuadra
Dimensiones y metadatos
Miembros, jerarquías, alias, atributos, importaciones y refrescos.
- Miembro no encontrado tras un refresco
- Importación de metadatos y Refresh Database
- Alias, atributos y UDAs
Forms
Los problemas que reportan los usuarios, con las palabras que usan los usuarios.
- “No data” y celdas que no aceptan captura
- Celdas read-only y por qué
- Forms lentos, Smart Push y Smart View
Dentro de tu instancia
El agente lee el sistema en vivo, no una copia de la documentación.
- Aplicaciones, dimensiones, miembros, jobs y logs
- Porciones de datos, exportadas y comparadas
- Cambios ejecutados sólo con aprobación
En tu idioma
Bilingüe por diseño, no traducido después.
- Respuestas en español e inglés
- Idioma detectado en cada ticket
- La misma evidencia, en el idioma de quien lee
Gobernanza
Tú conservas las llaves. El agente conserva el registro.
Un agente con permiso de escritura sobre un sistema financiero sólo sirve si puedes ver exactamente qué hizo y detenerlo antes de que importe. Las dos cosas están diseñadas desde el inicio, no agregadas después.
La escritura en producción pide a una persona
Cada ambiente trae su política de escritura: bloqueada, requiere aprobación o permitida. En producción un cambio se propone y espera. El agente no tiene forma de esquivarlo.
Tus credenciales nunca llegan al modelo
EPM sólo es alcanzable a través de una puerta de herramientas que corre fuera del ambiente del agente. El agente no tiene secretos de EPM, ni nombres de host de clientes, ni shell.
Cada acción queda registrada
Cada acción se escribe en una bitácora de auditoría encadenada por hash e inviolable, por tenant, para que la secuencia se pueda reconstruir y verificar después.
Tus tickets son datos, no instrucciones
El texto de los tickets, los comentarios, los logs y los adjuntos se tratan como entrada no confiable. El contenido de un ticket no puede hacer que el agente actúe.
Escala en lugar de adivinar
Accesos y permisos, service requests de Oracle, y temas comerciales o de licenciamiento: van a una persona, con la evidencia ya reunida para que nadie empiece de cero.
Para quién es
Dos formas de trabajar con nosotros.
El mismo agente, supervisado por quien esté en mejor posición para supervisarlo.
Para consultoras EPM
Tu marca, nuestro agente
Supervisa al agente en todos los ambientes de tus clientes, con tu nombre y tus colores, desde un solo lugar. Conserva la relación con tu cliente y deja de reenviar tickets.
- Una vista para todos los clientes que atiendes
- Tu nombre, tu logo y tu color de acento
- Aprobaciones y autonomía las defines tú, por cliente
- Una oferta de soporte que puedes cotizar tú mismo
Para equipos EPM internos
Nosotros supervisamos al agente
Un equipo supervisando al agente en tus ambientes de Planning, respondiendo a tus solicitantes en su propio idioma y escalando a tus expertos sólo lo que necesita una persona.
- Lee y, con aprobación, cambia, sobre tu instancia
- Responde en el idioma en que escriben tus solicitantes
- Tus expertos reciben escalaciones con la evidencia adjunta
- Empieza con un ambiente y ve ampliando
Límites
Lo que deliberadamente no hacemos.
Un agente que haría cualquier cosa es un agente que no puedes meter en un sistema financiero. Estas son las líneas que no puede cruzar.
- Usuarios, grupos, roles y permisos de acceso
- Abrir o gestionar service requests de Oracle
- Compromisos comerciales, de licenciamiento o de nivel de servicio
- Procesos de EPM ajenos a Planning sin una habilidad dedicada
- Nada fuera de sus herramientas tipadas: sin scripts improvisados ni llamadas a sistemas que no se le dieron
Preguntas
Lo que primero pregunta quien compra EPM.
¿El agente escribe en mi ambiente de producción?
Puede, y ese es el punto. Cada ambiente tiene una política de escritura — bloqueada, requiere aprobación o permitida — y en producción un cambio se propone y espera la aprobación de una persona para esa escritura en específico. El agente no tiene forma de hacer un cambio no aprobado en producción.
¿Qué pasa cuando no sabe?
Escala, con la evidencia que ya juntó. Un ticket clasificado por debajo del umbral de confianza se enruta a una persona en vez de responderse, y las preguntas de accesos, los service requests de Oracle y todo lo comercial siempre van a un humano.
¿Qué áreas de EPM cubre?
Planning, antes conocida como PBCS: Financials, Workforce, Capital, Projects y Strategic Modeling, que era Enterprise PBCS. Los demás procesos de EPM quedan fuera de alcance hasta que exista una habilidad dedicada para ellos, y el agente lo dice en vez de improvisar.
¿Mis solicitantes pueden escribir en español?
Sí. El idioma se detecta en cada ticket y la respuesta vuelve en ese idioma, con la evidencia en el mismo idioma. No hay una cola en español aparte ni un paso de traducción.
¿Otro cliente puede ver mis datos?
No. Cada cliente es un tenant separado, y el aislamiento se impone en la capa de base de datos y no en el código de aplicación, con una suite de pruebas que rompe el build si una consulta puede cruzar la frontera de un tenant.
¿Esto reemplaza a nuestras consultoras?
No. Lo que toma es el triaje repetitivo y las fallas conocidas. Las decisiones que requieren criterio, las discusiones de arquitectura y la relación se quedan con las personas.
¿Por dónde empezamos?
Un ambiente, en sólo lectura o con aprobación requerida, y una muestra pequeña de tus tickets reales. Ves qué hace con ellos antes de ampliar nada.
Agendar una demo
Trae un ticket que ya hayas resuelto una vez.
La demo más útil no es un recorrido. Es un incidente real tuyo, pasado por el agente de principio a fin, para que juzgues el diagnóstico y la evidencia por ti mismo.