Leer esto primero
Hay aproximadamente una página de prosa narrativa genuina sobre Supplier Risk en el material disponible de SAP. Casi todo lo demás es un título de capítulo o el título de un artículo de soporte. Esta guía mantiene esos niveles de confianza separados en lugar de disimularlos como si fueran un procedimiento, porque en ICM una instrucción errónea con confianza sale más cara que un vacío reconocido honestamente.
De ahí se derivan dos consecuencias que estructuran todo lo que sigue. Primero, ningún parámetro de configuración del sitio de Supplier Risk está documentado en ningún lado — a pesar de que ICM tiene una categoría literalmente llamada Supplier Risk Parameters. Cualquier cadena Application.SupplierRisk.* que se vea en una guía pública está inventada. Segundo, cuando dos fuentes se contradicen, se presentan ambas y no se elige ninguna. Verificar contra el tenant.
Una guía que disimula los vacíos de Supplier Risk le va a generar un problema a alguien en ICM. Los vacíos son parte del insumo de diseño.
Qué es Supplier Risk, y dónde está su límite
Supplier Risk identifica, evalúa, monitorea y mitiga el riesgo de proveedores. Es la única solución de la familia Supplier Management que hace monitoreo de riesgo y evaluación de riesgo basada en controles, y la columna de arquitectura la califica como standalone — no como un módulo de SLP. Su propósito declarado tiene dos modos, que se corresponden con las dos mitades del producto.
| Propósito | Capacidad |
|---|---|
| Monitorear el riesgo potencial de los proveedores actuales | Risk exposure, puntajes, alertas, dashboards |
| Evaluar el riesgo de nuevos proveedores antes de comprometerse con ellos | Control-Based Engagement Risk Assessment |
Se le atribuyen a Supplier Risk cinco titulares de capacidad: due diligence de riesgo, monitoreo proactivo de riesgo, disposición colaborativa de riesgo, protección de reputación de marca, y control- based engagement risk assessment. Nótese que este último aparece nombrado en un solo archivo fuente — y es la capacidad sobre la que suele apoyarse todo un workstream. Definir su alcance teniendo esto en cuenta.
Cuatro superficies de administración, no una
La configuración está repartida entre SM Administration (BTP), Risk administration, donde viven las credenciales de proveedores, Enrichment Administration, que puede requerir habilitación propia, e ICM, que tiene una categoría Supplier Risk Parameters cuyo contenido no está documentado. “¿Dónde configuro esto?” es una pregunta real en este producto, y responderla mal cuesta un sprint.
Sumar dos más: la pregunta sobre el Unified Vendor Model — si agregar Supplier Risk a un sitio legacy dispara una migración a UVM — no tiene respuesta publicada, así que hay que preguntarle a SAP por escrito antes de planificar una migración de datos que tal vez no se necesite. Y el modelo de reversión de ICM solo revierte el despliegue más reciente, razón por la cual un paquete por cambio lógico es una disciplina, no una preferencia.
Prerrequisitos y decisiones previas a la configuración
El entitlement va primero — si Supplier Management o Supplier Risk no es visible en el sitio, hay que revisar el entitlement antes que la configuración (3290213). Luego, la activación es un proceso, no un interruptor: es un proceso con nombre propio y su propio artículo de fallas (3644870), registrado como Problem. Presupuestar tiempo de calendario y plantearlo temprano.
Todo proyecto proviene de una plantilla, y los datos maestros van antes que las plantillas: importar los datos requeridos → configurar plantillas → personalizar notificaciones → configurar dashboards por defecto. Los commodity codes, regiones y departamentos se comparten entre todas las soluciones de Strategic Sourcing, así que una plantilla que referencia datos maestros no cargados simplemente no funcionará bien.
Los tres pasos de configuración específicos de Risk —lo más parecido a un orden de construcción que ofrece la fuente— son: configurar Risk Exposure, configurar los proyectos de evaluación de riesgo basados en controles, e importar los datos de riesgo de proveedores. La sección 13 amplía esto con los prerrequisitos y modos de falla que la fuente menciona en otros lugares.
Puertas de un solo sentido: decidir esto antes de producción
Tres decisiones de habilitación cambian lo que puede hacer la UI, y ninguna está documentada como reversible. Una cuarta es un prerrequisito ineludible que detiene todo en seco. Estas decisiones pertenecen a un workshop de decisiones previo a producción, no a un ticket de cambio.
| Acción | Consecuencia documentada | KBA |
|---|---|---|
| Habilitar Engagement Requests basados en controles | No es un simple interruptor. Ejecuta una tarea programada, MigrateSRNewProjectsTemplatesTask, y esa tarea puede fallar. Nada documenta qué cambia esa tarea. | 3666311 |
| Feature ARI-4598 — envío avanzado de evaluaciones | Ya no se pueden enviar evaluaciones de riesgo de forma individual. | 3183689 |
| Finding and Event Collaboration (FEC) | La opción Create Issue desaparece de los Engagement Requests. Es por diseño, y no tiene vuelta atrás. | 3605362 |
| Prerrequisito: FEC requiere Sourcing SSO | “No SAP Ariba Sourcing systems with valid single sign-on setups available” es el error textual cuando falta. | 3580370 |
Tres más de menor gravedad
| Acción | Consecuencia |
|---|---|
| Template Upgrade en proyectos de Engagement Request | Puede terminar en estado Upgrade Failed (3303389). Practicarlo en un realm de prueba. |
| Despliegue de paquetes de ICM | Solo se puede revertir el despliegue más reciente. No existe una gestión de versiones completa: un paquete por cambio lógico. |
| Personalización de plantillas FEC | Registrada como Known Error (3748559) — el único Known Error en todo el conjunto de artículos de Supplier Risk. |
No existe un procedimiento de rollback para la configuración de Supplier Risk en ningún lugar, más allá de la reversión de un solo despliegue en ICM. Leer las notas 3183689, 3605362, 3666311 y 3580370 antes de habilitar nada, y dejar la decisión registrada con un responsable asignado.
Grupos, y la dimensión de costo que nadie menciona
Existen tres listas de grupos distintas en la fuente y se contradicen entre sí. Solo dos nombres sobreviven en las tres: Supplier Manager y Supplier Risk Manager. Tomar los nombres de grupo de la guía Strategic Sourcing and Supplier Management Group Descriptions, nunca de una tabla resumen — incluida cualquiera de esta guía.
El hallazgo verdaderamente poco obvio: en Supplier Risk, la membresía de grupo determina la facturabilidad. Dos grupos que las tablas resumen nunca mencionan —SM ERP Administrator y SM Ops Administrator— hacen que sus miembros sean usuarios facturables. Revisar el Group Licensing Reference antes de asignar cualquiera de los dos, y exportar las métricas de uso periódicamente.
Dos hechos de permisos específicos de Risk: el User Matrix llega hasta Supplier Risk y rige las aprobaciones e Issues de los Engagement Requests (3433355) — revisarlo primero cuando las aprobaciones no resuelvan. Y la resolución del aprobador puede mostrar un nombre de grupo en lugar de una persona (3675814); decidir en el UAT si auditoría acepta eso.
| Pregunta | KBA |
|---|---|
| ¿Qué usuarios de Supplier Risk cuentan como usuarios con licencia? | 3361571 |
| ¿Por qué los miembros de los grupos SM ERP Administrator y SM Ops Administrator son ahora usuarios facturables? | 3269932 |
| ¿Qué permiten hacer los roles de Supplier Risk a los usuarios? | 3186275 |
| El User Metrics Report no mostraba si un usuario estaba activo o inactivo | 3190403 |
| Roles y permisos requeridos para la navegación del perfil de proveedor en Joule | 3719864 |
Risk exposure: cuatro puntos, y lo que no son
La documentación narrativa completa de la configuración de risk exposure son cuatro puntos: definir las categorías de riesgo relevantes para la organización; configurar el peso de cada categoría; seleccionar las fuentes de datos de riesgo (content providers); establecer umbrales de alerta por nivel de riesgo. Sin nombres de parámetros, sin escala, sin fórmula, sin valores por defecto, sin ruta de UI.
Hay que leerlos por lo que son: una agenda de diseño, no un procedimiento. Se mapean limpiamente a cuatro workshops — conjunto de categorías, modelo de ponderación, selección de proveedores, y política de umbrales y notificaciones. Lo que no pueden hacer es indicar dónde hacer clic. Planificar un recorrido en el tenant junto con el administrador del cliente como una tarea explícita del proyecto, no como algo secundario.
Antes de diseñar una sola categoría, hay que establecer qué régimen de puntuación corre el tenant — Custom Risk Categories o Legacy Scoring (3721985). SAP publica un instructivo para verificarlo, lo que confirma que es algo por determinar y no por asumir. Sumado a un capítulo sobre Managing Legacy Risk Assessment Projects, son dos señales independientes de una división generacional dentro del producto. En un tenant brownfield, es una pregunta de descubrimiento de la primera semana.
El vocabulario de puntuación existe; nada de él está definido
| Término | Dónde aparece | KBA |
|---|---|---|
| Risk Exposure (como valor calculado) | ¿Cómo se calcula el Risk Exposure? | 3183969 |
| Puntaje general de riesgo inherente | Muestra N/A en Supplier 360 / no se actualiza o Not Applicable | 3495126, 3736860 |
| Puntaje de Inherent Risk en Engagement Requests | Sin puntaje de Inherent Risk / valores de Inherent Risk incorrectos | 3551434, 3244929 |
| Residual Risk Domain | Residual Risk Domain no se calcula | 3566091 |
| El risk domain como eje de puntuación | Calcular el riesgo inherente para ERs por risk domain | 3189134 |
| Custom Risk Categories vs. Legacy Scoring | Cómo verificar el tipo de puntuación en Supplier Risk | 3721985 |
Los content providers son, primero, una cuestión contractual
D&B, EcoVadis y Bureau van Dijk aparecen en el corpus como proveedores cuyos datos alimentan los puntajes de exposure. La falla que más tiempo consume no es de Ariba: el registro en D&B que falla con el código de error (00041) se resuelve contra la autorización de la propia cuenta de D&B del cliente (3684395). Confirmar que existan los contratos y las credenciales antes de agendar la prueba de integración.
Las credenciales se ingresan en un área de Risk administration (3360417), y Enrichment Administration es una superficie propia que puede requerir habilitación (3736855) — razón por la cual “no encuentro dónde poner las credenciales” es un síntoma real y documentado, y no un error de usuario. Cuando faltan puntajes de proveedores en el puntaje general, revisar la agregación por separado de la conectividad con el proveedor.
Qué proveedores se monitorean: tres poblaciones, no una
Todos empiezan asumiendo que “los proveedores en Risk” son un único conjunto. En realidad son al menos tres, se administran de forma distinta, y un proveedor puede estar en uno y no en otro. El mecanismo de selección en sí no está documentado en absoluto — pero el catálogo de fallas demuestra que el alcance se rompe de maneras independientes.
| Población | Síntoma cuando está mal | KBAs |
|---|---|---|
| Visible en Supplier Risk en absoluto | Proveedores no visibles en Supplier Risk; imposibilidad de buscar proveedores en Supplier Risk | 3182921, 3179441 |
| Seguido (followed) — lo que impulsa el Alert Feed | Alertas en el Alert Feed para proveedores que se dejaron de seguir; ¿existe un reporte para identificar proveedores seguidos? | 3440209, 3638969 |
| Seleccionable al crear un Engagement Request | Distintos proveedores devueltos en la búsqueda al crear un Engagement Request | 3734396 |
| Terceros — una cuarta clase de objeto | Campos estándar para terceros dentro de Supplier Risk; proveedores ausentes del Risk Map | 3420517, 3571310 |
Diseñar el plan de pruebas para verificar cada población por separado, y esperar que al menos una sorprenda en el UAT. Si el alcance de riesgo del cliente incluye terceros que no son proveedores — agentes, distribuidores, socios de joint venture—, third parties es una cuarta clase de objeto con sus propios campos estándar, y el corpus no dice nada más al respecto. No prometer nada ahí sin leer 3420517.
Evaluación de riesgo de engagement basada en controles
Esta es la mitad previa al compromiso del producto: una evaluación basada en controles predefinidos, que genera proyectos de evaluación con un flujo de aprobación. La habilitación no es un interruptor — ejecuta MigrateSRNewProjectsTemplatesTask, y esa tarea falla lo suficientemente seguido como para tener su propio artículo. Asignar a alguien para monitorearla.
El modelo de objetos hay que reconstruirlo a partir de artículos de fallas: los controles tienen un type y un status importable (3722166), los controles se evalúan al crear el ER y pueden fallar en dispararse (3528588), y los control assessments difieren de las assessment versions — ambos pueden mostrar respuestas distintas (3748213). Cómo se redacta un control, y qué campos tiene, nunca se especifica.
Las plantillas cargan con el resto del riesgo. El Template Upgrade puede terminar en Upgrade Failed (3303389) — ensayarlo en un realm de prueba. Se sabe que el orden de las tareas en la UI del ER se desvía de la plantilla (3605435), así que hay que verificarlo después de cada upgrade. Y la personalización de plantillas FEC está registrada como un Known Error (3748559), el único de todo el conjunto de Supplier Risk.
APIs e importaciones: dos bloqueos y una corrupción silenciosa
| Hecho de la API | KBA | Fecha |
|---|---|---|
| Existe la Risk Category Information API para Supplier Risk Exposure | 3184142 | abr 2022 |
| Comportamiento de los campos personalizados de proveedor al usar esa API | 3721402 | mar 2026 |
| ⚠ La Supplier Risk Engagement API no admite extracción masiva de todos los workspaces | 3705132 | mar 2026 |
| ⚠ smVendorId en GET /questionnaires devuelve un Workspace ID para evaluaciones de tipo control | 3757372 | may 2026 |
| 400 – Bad Request en la Supplier Risk Engagements API | 3341615 | jun 2023 |
| POST /vendordatarequests devuelve proveedores cuando solo cambia el estado del certificado; no hay filtrado de la respuesta | 3753022 | may 2026 |
Las dos filas marcadas son bloqueos de diseño, y ambas son recientes. La imposibilidad de extraer en bloque los workspaces de Engagement implica que “exportar todas nuestras evaluaciones de riesgo al data lake” necesita un diseño completamente distinto. Y que smVendorId devuelva un Workspace ID para evaluaciones de tipo control es exactamente el tipo de sorpresa de semántica de campo que corrompe silenciosamente un join aguas abajo — hay que verificar el tipo de valor antes de usarlo como clave.
Importaciones relevantes para Risk
| Importación | Qué puede fallar | KBA |
|---|---|---|
| Archivo de Risk External IDs | “Could not find smVendorId for erpVendorId=XXXXX” — primero hay que limpiar el mapeo de claves de proveedor | 3346928 |
| Importación de estado de controles | El estado del control de tipo engagement no cambia tras la importación | 3722166 |
| Supplier Risk Data Import | Trae los datos de riesgo y los datos maestros que necesitan los proyectos de evaluación. No se publica ningún layout de archivo | — |
| Supplier Data Import (SM Administration) | Falla con una Unique Constraint Violation | 3529477 |
| Cualquier importación CSV | Se eliminan los ceros a la izquierda: corrupción silenciosa justo de las claves de proveedor con las que hace join Risk | 3190123 |
| Verificación de la importación | Descargar el resumen de importación en SM Administration y conciliar los conteos | 3274930 |
Nunca tratar un mensaje de éxito de importación como una verificación. Descargar el resumen de importación y conciliar los conteos de registros. El comportamiento de los ceros a la izquierda merece una verificación previa dedicada, porque corrompe justo los campos con los que hace join la importación de Risk External IDs.
Síntoma → capa
Con un solo defecto confirmado en noventa y tres artículos, cuando Supplier Risk se comporta mal la respuesta casi nunca es un bug. Revisar la habilitación, el alcance, la plantilla y las credenciales de proveedor antes de decir “bug de SAP” — y enrutar el caso al componente correcto desde la primera vez.
| Síntoma | Revisar |
|---|---|
| Un proveedor no aparece en Supplier Risk en absoluto | Alcance de proveedores evaluados, luego la búsqueda (3182921, 3179441) |
| Aparecen proveedores distintos al crear un Engagement Request | Una población distinta a la de visibilidad en Risk (3734396) |
| Las alertas dejaron de dispararse, o se disparan para los proveedores equivocados | Configuración de alertas, luego el modelo de seguir/dejar de seguir (3184092, 3440209) |
| El puntaje de riesgo muestra N/A o “Not Applicable” | Primero el régimen de puntuación —Custom vs. Legacy—, luego los datos del proveedor (3721985, 3495126) |
| El riesgo residual no se calcula | Residual Risk Domain (3566091) |
| El Engagement Request no tiene puntaje de Inherent Risk | Puntuación a nivel de ER (3551434, 3244929) |
| Los puntajes de D&B o EcoVadis están ausentes del puntaje general | Integración de proveedores y agregación de puntajes (3386868, 3684395) |
| El registro en D&B falla con el código de error (00041) | La autorización de la cuenta de D&B del cliente — no es configuración de Ariba (3684395) |
| No se encuentra dónde ingresar las credenciales del proveedor | Habilitación de Risk administration / Enrichment Administration (3360417, 3736855) |
| El Engagement Request queda atascado en Edit, o no se puede cancelar | Estado del ciclo de vida del ER (3591797, 3309170, 3713722) |
| Los Risk Controls no se dispararon al crear el ER | Configuración de controles (3528588) |
| La tarea “Send Assessments” queda atascada | Primero la tarea, luego el comportamiento masivo, luego ARI-4598 (3455392, 3515411, 3183689) |
| La aprobación en un ER resuelve a nadie o al aprobador incorrecto | Primero el User Matrix, luego el flujo de aprobación (3433355, 3402199) |
| Desapareció la opción Create Issue | Se habilitó FEC — por diseño, y sin vuelta atrás (3605362) |
| Los correos de Risk llegan con la marca de notificaciones de Sourcing | Risk reutiliza el framework de notificaciones de Sourcing (3700262, 3318639) |
| El Template Upgrade termina en “Upgrade Failed” | Elegibilidad para el upgrade y ensayo previo (3303389, 3609058) |
| El risk exposure no es visible en Guided Buying o Guided Sourcing | Configuración por superficie (3379973, 3640466) |
Orden de construcción, y qué se ve al invertirlo
| # | Hacer esto | Qué se ve si se invierte |
|---|---|---|
| 1 | Confirmar el entitlement y ejecutar el proceso de activación | La activación es un proceso con nombre propio y su propio artículo de fallas, no un interruptor (3290213, 3644870) |
| 2 | Determinar el régimen de puntuación — Custom Risk Categories o Legacy Scoring | El diseño de exposure de cuatro puntos presupone categorías personalizadas; el régimen equivocado implica rediseñar (3721985) |
| 3 | Determinar qué generación de proyectos de evaluación de riesgo está activa | Existe todo un capítulo para proyectos de evaluación legacy, y ninguna de las dos generaciones está descrita |
| 4 | Tomar y registrar las decisiones sin vuelta atrás | ARI-4598, FEC y la habilitación de ER basados en controles no tienen un camino de regreso documentado |
| 5 | Establecer Sourcing SSO antes de habilitar FEC | “No SAP Ariba Sourcing systems with valid single sign-on setups available” (3580370) |
| 6 | Confirmar contratos y credenciales de proveedores antes de probar el enrichment | El registro en D&B falla en la cuenta de proveedor del cliente, no en la configuración propia (3684395) |
| 7 | Cargar los datos maestros compartidos, y los grupos antes que los usuarios | Una plantilla que referencia datos maestros no cargados no se comportará correctamente |
| 8 | Revisar el Group Licensing Reference antes de asignar grupos de administración | La membresía hace que los usuarios sean facturables — es una línea de presupuesto, no un detalle de permisos (3269932) |
| 9 | Limpiar el mapeo de claves de proveedor antes de importar los Risk External IDs | “Could not find smVendorId for erpVendorId” (3346928) |
| 10 | Configurar Risk Exposure — categorías, ponderaciones, proveedores, umbrales | De lo contrario los puntajes muestran N/A y los ER no llevan Inherent Risk (3495126, 3551434) |
| 11 | Definir el alcance de proveedores evaluados — las tres poblaciones | Invisible, no buscable, o un conjunto distinto dentro de la creación de ER (3182921, 3734396) |
| 12 | Importar las plantillas de proyecto de Supplier Risk | Todo proyecto proviene de una plantilla; leer primero el artículo de mejores prácticas de importación (3185077) |
| 13 | Importar Supplier Risk Data, incluyendo los datos maestros de evaluación | La dependencia está establecida; el layout del archivo no está documentado en ningún lado |
| 14 | Configurar las notificaciones de Risk por separado de las de SLP | Una mala configuración emite correos con marca de Sourcing desde Risk (3700262, 3318639) |
| 15 | Probar cada superficie de salida individualmente | Siete superficies, nueve artículos independientes de “por qué no se muestra” |
Checklist de configuración
Antes de configurar, y antes de salir a producción
- Confirmar el entitlement de Supplier Risk, y si el cliente está en Supplier Risk completo o en la edición base.
- Ejecutar el proceso de activación con anticipación y tratarlo como tiempo de espera (3644870).
- Confirmar el régimen de puntuación y la generación de proyectos de evaluación en el tenant.
- Decidir y registrar la habilitación de ARI-4598, FEC y ER basados en controles — leer las cuatro notas primero.
- Un paquete de ICM por cambio lógico; solo el último despliegue es reversible.
- Tomar los nombres de grupos de la guía Group Descriptions, no de tablas resumen.
- Revisar el Group Licensing Reference antes de asignar SM ERP Administrator o SM Ops Administrator.
- Validar que las asignaciones del User Matrix resuelvan correctamente en los Engagement Requests antes del UAT (3433355).
- Realizar un recorrido en el tenant sobre el risk exposure — sustituye a la documentación que no existe.
- Confirmar el conjunto real de categorías de riesgo en el tenant; no diseñar a partir de ninguna tabla resumen.
- Establecer la frecuencia de actualización de los datos de riesgo e informarle al negocio cuál es (3547822).
- Verificar los contratos y credenciales de D&B / EcoVadis / BvD antes de la prueba de integración.
- Definir explícitamente las tres poblaciones de proveedores — visible, seguida, seleccionable en ER — y probar cada una.
- Decidir si los terceros están dentro del alcance (3420517).
- Revisar cada CSV en busca de corrupción por ceros a la izquierda y conciliar el resumen de importación (3190123, 3274930).
- Ensayar el upgrade de plantillas de Engagement Request en un realm de prueba (3609058, 3303389).
- Recordar que los cuestionarios modulares y la gestión de certificados se habilitan juntos (3183117).
- No diseñar una exportación masiva de workspaces de Engagement — la API no lo admite (3705132).
- Verificar el tipo de valor de smVendorId antes de hacer join sobre él aguas abajo (3757372).
Glosario
| Término | Significado |
|---|---|
| Alert Feed | La superficie de alertas en Supplier Risk, impulsada por un modelo de seguir/dejar de seguir (3440209, 3638969). |
| ARI-4598 | ID de feature: habilitar el envío avanzado de evaluaciones. Al habilitarlo se elimina el envío individual de evaluaciones. |
| base edition | SAP Ariba Supplier Risk, edición base — nombrada dos veces en la fuente y nunca descrita. |
| BTP | SAP Business Technology Platform. Aloja SM Administration, Supplier Profile Summary y FEC. |
| BvD | Bureau van Dijk — un proveedor de contenido externo; las credenciales se ingresan en Risk administration (3360417). |
| Control / Risk Control | El objeto de debida diligencia predefinido detrás de la evaluación basada en controles. Se evalúa al crear el ER; tiene un tipo y un status importable. |
| Control-Based Engagement Risk Assessment | Una evaluación que se ejecuta antes de comprometerse con un proveedor, basada en controles predefinidos, que genera proyectos de evaluación con un flujo de aprobación. |
| Engagement Request (ER) | El objeto de proyecto que lleva un puntaje de riesgo inherente, controles, tareas, aprobaciones e issues. |
| FEC | Finding and Event Collaboration. Requiere Sourcing SSO; al habilitarlo se elimina Create Issue de los ER. |
| Finding vs. Issue | Dos nombres de objeto que SAP nunca ha reconciliado. Establecer en el tenant a cuál se refiere el proceso del cliente. |
| MigrateSRNewProjectsTemplatesTask | La tarea programada que ejecuta la habilitación de ER basados en controles — y puede fallar (3666311). |
| Risk Exposure | El valor calculado de monitoreo continuo: categorías, ponderaciones, datos de proveedores y umbrales de alerta. |
| smVendorId / erpVendorId | El par de claves de proveedor con el que hace join la importación de Risk External IDs. Limpiarlo antes de importar. |
Una ambigüedad que SAP nunca resolvió: Findings versus Issues. Ambos nombres de objeto están en uso, la nueva feature Findings tiene su propio feature ID, y habilitar FEC elimina Create Issue. Definir en el tenant a cuál se refiere realmente el proceso del cliente antes de redactar cualquier documento de proceso en torno a alguno de los dos.