Prueba de concepto de software MDM con sus propios datos maestros

Una prueba de concepto (POC) de software MDM solo vale si se ejecuta con sus propios datos maestros, la opera su equipo y se mide contra escenarios que usted escribió antes de ver la herramienta. Elija una muestra con problemas reales, proteja los datos personales, defina el resultado esperado de cada escenario y puntúe con pesos y evidencia guardada. Lo que se apruebe en la POC se convierte en criterio de aceptación en el contrato.

He visto pruebas de concepto convertirse en demostraciones ensayadas. El proveedor llega con su propia base, cada material tiene una descripción impecable, cada proveedor registrado pasa todas las validaciones y el flujo de aprobación avanza solo en la pantalla. Todos salen de la sala satisfechos.

Luego empieza el proyecto. La primera carga con la base real se traba, la regla de descripción que parecía simple necesita horas de consultoría y la integración con el ERP queda para "la fase dos". La POC midió la habilidad de quien presentó, no el software frente a sus problemas.

¿Qué es MDM y qué es una POC?

SAP lo define así: "La gestión de datos maestros es la disciplina de crear y mantener una vista única y confiable de los datos de negocio más importantes de una organización en todos los sistemas" (SAP, ¿Qué es la gestión de datos maestros (MDM)?). Fíjese en la palabra disciplina. El software de MDM es la herramienta que sostiene esa disciplina en el día a día: registro, reglas, aprobaciones, calidad y distribución hacia los demás sistemas.

Una prueba de concepto es una evaluación corta y controlada en la que la empresa verifica si la herramienta resuelve sus problemas, con sus datos, antes de firmar. Responde a una pregunta simple: ¿esto funciona aquí? No es capacitación, no es implementación y no es una presentación comercial.

¿Cuándo tiene sentido hacer la POC?

Después de la RFP y de la lista corta. La POC exige esfuerzo de todos los lados, así que entra cuando ya tiene dos o tres proveedores que pasaron en el papel. Si todavía no llegó a esa etapa, empiece por cómo preparar una RFP para un software de MDM y use el checklist de lo que hay que evaluar en un software de MDM para definir los criterios.

La RFP dice lo que el proveedor afirma tener. La POC muestra lo que logra hacer con sus registros, delante de usted. Son etapas distintas y una no reemplaza a la otra.

¿Cómo elegir la muestra de datos para la POC?

La muestra decide el resultado. Si está demasiado limpia, cualquier herramienta aprueba.

Paso 1: mida la calidad antes de la prueba

Sin una línea de base no sabrá si la herramienta mejoró algo. Antes de enviar datos a nadie, mida completitud, estándar de descripción y duplicados del recorte elegido. El artículo sobre cómo medir la calidad de los datos maestros muestra por dónde empezar.

Paso 2: incluya los casos difíciles a propósito

• Materiales con duplicados que su equipo ya conoce (el mismo artículo con descripciones distintas). Ahí la deduplicación demuestra si funciona.
• Proveedores con documentos vencidos, homologación pendiente o situación registral que no coincide con los registros oficiales.
• Registros con campos obligatorios vacíos y descripciones fuera de estándar.
• Un volumen que haga trabajar de verdad la carga masiva, no media docena de filas.

Paso 3: entregue la misma muestra a todos los proveedores

Si cada uno prueba una base distinta, no compara nada. Misma muestra, mismos escenarios, mismo plazo.

¿Cómo proteger los datos personales de la muestra?

Los registros de clientes y proveedores que son personas físicas contienen datos personales: identificación fiscal, dirección, teléfono. En Brasil, la identificación fiscal de las personas físicas es el CPF (y la de las empresas, el CNPJ). La LGPD, la ley brasileña de protección de datos personales (Ley n.º 13.709/2018), se aplica al tratamiento de datos en Brasil. Si su operación está en otro país, revise la ley local. Dos conceptos de la LGPD ayudan a decidir qué enviar.

El principio de necesidad, en el artículo 6, inciso III, limita el tratamiento al mínimo necesario para cumplir sus finalidades, abarcando solo los datos pertinentes. El artículo 5, inciso III, define el dato anonimizado como el dato relativo a un titular que no puede ser identificado, considerando el uso de medios técnicos razonables y disponibles. El artículo 12 añade que el dato anonimizado, por regla general, no se considera dato personal para los fines de la ley, salvo cuando la anonimización pueda revertirse (Ley n.º 13.709/2018, texto oficial en portugués). Son traducciones libres del texto original.

Mi recomendación para la POC:

• Envíe solo los campos que cada escenario necesita probar.
• Enmascare o anonimice lo que no se está probando. Si el escenario es sobre descripción de materiales, el proveedor no necesita ver la identificación fiscal de nadie.
• Cuando un escenario exija datos personales reales (validación de documentos, por ejemplo), use el recorte más pequeño posible y acuerde por escrito con el proveedor cómo se tratarán y descartarán esos datos.
• Involucre al encargado de protección de datos de su empresa antes de enviar cualquier archivo.

¿Cómo escribir los escenarios de prueba?

Escriba los escenarios antes de ver la herramienta y deje por escrito el resultado esperado. Si define el éxito después de la demostración, quien lo define es el proveedor. De cinco a ocho escenarios bien escritos son suficientes.

Escenario	Qué preparar	Resultado esperado	Evidencia a guardar
Alta de material con flujo de aprobación	Flujo de aprobación actual dibujado, con etapas y responsables	La solicitud pasa por las etapas correctas y cada aprobador ve solo lo que necesita	Grabación de pantalla e historial del registro
Modificación de un registro existente	Registros de la muestra y la regla de quién puede cambiar qué	El cambio exige aprobación cuando la regla lo indica y queda registrado	Historial con quién cambió, cuándo y el valor anterior
Deduplicación de materiales	Lista de duplicados que su equipo ya conoce	La herramienta encuentra los duplicados conocidos y explica el criterio	Informe de duplicados comparado con su lista
Validación de proveedor en fuente oficial	Proveedores cuya situación registral no coincide	La inconsistencia se señala antes de la aprobación	Pantalla o informe con el resultado de la consulta
Carga masiva	Hoja de cálculo con volumen real y errores mezclados	Los registros válidos entran y los inválidos vuelven con el motivo	Informe de carga con aceptados y rechazados
Integración con el ERP y error de respuesta	Ambiente de prueba del ERP o respuesta simulada, incluido un envío que falla	El envío queda registrado con estado, intento y un mensaje de error legible	Log del envío con el identificador en el ERP
Regla configurada por su equipo	Una regla de negocio nueva, escrita por el key user	Su equipo configura la regla con orientación, sin código	Grabación de la configuración y de la prueba de la regla
Pista de auditoría	Un registro que pasó por los escenarios anteriores	Se puede reconstruir todo lo que le ocurrió	Exportación del historial

¿Quién participa y quién opera la herramienta?

El proveedor explica. Su equipo opera. Esta es la regla que más separa una POC de una demostración.

Quién debe estar en la sala

• Los key users de datos maestros, que usarán la herramienta todos los días. Su papel se detalla en lo que su key user necesita saber sobre el software de MDM.
• TI y arquitectura, para integración, seguridad y accesos.
• El dueño del dato de cada dominio evaluado (compras para proveedores, ingeniería o mantenimiento para materiales, por ejemplo).
• Compras de TI o la PMO, para cuidar el plazo y el registro de la puntuación.

Qué pedirle al proveedor

Pida acceso al ambiente para que su equipo ejecute los escenarios. Si hay que configurar algo, que sea delante de usted. Una configuración "que hicimos anoche" no demuestra que su equipo podrá mantenerla después.

¿Cómo puntuar a los proveedores en la POC?

Defina los pesos antes

Cada escenario recibe un peso según lo que importa para su negocio. El grupo define y firma los pesos antes de la primera sesión.

Ponga nota solo con evidencia

Use una escala simple, de 1 a 5. Una nota sin evidencia guardada no cuenta. "Funcionó en el momento" no alcanza. Guarde grabación, log o informe de cada escenario.

Ejemplo hipotético. Los números son ficticios, solo para mostrar el cálculo. Una empresa define estos pesos: integración con el ERP 25, alta con flujo de aprobación 25, deduplicación de materiales 20, regla configurada por su propio equipo 15 y pista de auditoría 15, sumando 100. El proveedor A obtiene 5 en flujo de aprobación y 2 en integración. El proveedor B obtiene 4 en ambos. En estos cinco escenarios ponderados, B ya saca 25 puntos de ventaja solo en flujo e integración y puede ganar aunque no tenga la pantalla más bonita, porque fue mejor en lo que más pesa para esa empresa. Para eso existen los pesos.

¿Qué señales de alerta aparecen durante la POC?

• El proveedor insiste en usar su propia base "porque es más rápido".
• La configuración se hace fuera de su vista y aparece lista.
• El escenario de integración "queda para el proyecto".
• El resultado aparece, pero no hay rastro de quién hizo qué.
• Cada regla nueva necesita un ticket al proveedor.
• La respuesta a un escenario que falló es una diapositiva.

Ninguna de estas señales descarta por sí sola a un proveedor. Pero anótelas, porque suelen volver durante el proyecto.

¿Qué llevar de la POC al contrato?

• Los escenarios aprobados, con su resultado esperado, como criterio de aceptación de la implementación.
• Lo que se mostró como configurable por su equipo, para que no se convierta después en un servicio cobrado aparte.
• El alcance de la integración con el ERP, incluido el tratamiento de los errores de respuesta.
• Cómo funcionan los ambientes de prueba y quién los mantiene.
• Lo acordado sobre el tratamiento y el descarte de los datos enviados en la POC.

Por dónde empezar

1. Cierre la lista corta a partir de la RFP.
2. Mida la calidad del recorte que será la muestra.
3. Arme la muestra con los casos difíciles y proteja los datos personales.
4. Escriba de cinco a ocho escenarios con resultado esperado y peso.
5. Defina quién participa y asegúrese de que su equipo operará la herramienta.
6. Ejecute la POC con la misma muestra para todos y guarde evidencia de todo.
7. Lleve los escenarios aprobados al contrato.

Para verificar si sus escenarios cubren lo que importa, vuelva a los criterios de evaluación de software de MDM.

Preguntas frecuentes

¿Cuánto debe durar una POC de MDM?

Depende de la cantidad de escenarios, de cuántos dominios entran en la prueba y del tiempo que su equipo pueda dedicar. La integración con el ERP suele ser lo que más preparación exige. Yo prefiero un plazo corto y cerrado, acordado antes e igual para todos los proveedores, porque una POC sin fecha de fin se convierte en un proyecto sin contrato.

¿La POC debe ser pagada?

Depende del alcance y del esfuerzo que le pida al proveedor. Una POC con integración real y varios dominios da trabajo a ambas partes. Mi opinión: conversarlo abiertamente en la RFP es mejor que descubrirlo después. Lo importante es que el modelo acordado no le quite el derecho a operar la herramienta y guardar evidencia. Para entender el costo de una solución completa, vea cuánto cuesta una solución de MDM.

¿Puedo enviar datos reales de clientes y proveedores a la POC?

Los datos reales son los que dan valor a la POC, pero los datos personales exigen cuidado. En Brasil, la recomendación es seguir el principio de necesidad de la LGPD (artículo 6, inciso III): enviar solo lo que cada escenario necesita probar y enmascarar o anonimizar el resto. Hable con el encargado de protección de datos de su empresa antes de enviar nada.

¿Cuántos proveedores llevar a la POC?

Depende del tiempo que tenga su equipo, porque cada proveedor adicional es otra ronda completa de escenarios. En mi opinión, dos o tres que ya pasaron la RFP son suficientes. Más que eso suele cansar al equipo antes de llegar a lo que importa.

¿Cuál es la diferencia entre demo, POC y piloto?

La demo es el proveedor mostrando la herramienta, con sus datos y su guion. La POC es su equipo probando escenarios definidos por usted, con sus datos, antes de firmar. El piloto ya es uso real en un alcance pequeño, normalmente después de la contratación, para ajustar el proceso antes de ampliarlo.

¿Qué hacer si ningún proveedor pasa los escenarios?

Primero, revise los escenarios: ¿el resultado esperado era realista y estaba claro para todos? Si lo era, acaba de evitar un mal proyecto. Vuelva a la RFP, vea si el problema está en los requisitos o en los proveedores consultados y ajuste la lista corta antes de una nueva ronda.

Cómo 4MDG puede ayudar

Los escenarios de este artículo se corresponden con lo que ofrece la plataforma de 4MDG: SaaS en la nube, flujo de aprobación configurable sin código, reglas de negocio declarativas probadas contra registros reales, alta masiva por hoja de cálculo, integración mediante API REST y conectores con ERP (cada envío registra estado, intentos, identificador en el ERP y mensaje de respuesta) e historial completo de cada registro. Los detalles están en cómo funciona y se integra la plataforma.

Si todavía está armando la muestra, puede solicitar el diagnóstico de 4MDG sobre una muestra real de su base. Usted envía una hoja de cálculo o una extracción, no se instala nada en su ambiente, el material queda bajo acuerdo de confidencialidad y se queda con su empresa, independientemente de la contratación. Si prefiere conversar antes, puede hablar con un arquitecto de 4MDG.

Aviso: la sección sobre la LGPD es una orientación general y no constituye asesoramiento jurídico. Para su caso concreto, consulte al encargado de protección de datos y al área jurídica de su empresa.

Fuentes

• SAP. ¿Qué es la gestión de datos maestros (MDM)? https://www.sap.com/latinamerica/resources/what-is-mdm. Consultado el 7 de octubre de 2026.
• Presidencia de la República de Brasil (Planalto). Ley n.º 13.709/2018, Ley General de Protección de Datos Personales de Brasil (LGPD), artículos 5 (III), 6 (III) y 12, texto oficial en portugués. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm. Consultado el 7 de octubre de 2026.