¿Estandarizar o personalizar un proceso SAP? Cómo decidir antes de modificar el sistema

“Necesitamos que SAP funcione de otra manera.”

Esa solicitud puede terminar en una configuración, una adaptación o un nuevo desarrollo. Pero antes existe una pregunta mucho más importante:

¿por qué necesitamos que el proceso sea diferente?

No todas las particularidades de una empresa justifican una personalización del sistema. Algunas representan procesos esenciales para el negocio. Otras existen simplemente porque “siempre se ha trabajado así”. Distinguir ambas situaciones antes de modificar SAP puede evitar agregar complejidad innecesaria.

Estandarizar y personalizar no son decisiones opuestas

La decisión no siempre es elegir entre mantener el estándar SAP exactamente como viene o construir una solución completamente personalizada. Puede existir un punto intermedio. Fleig, Augenstein y Maedche (2018), en un caso sobre transformación hacia SAP S/4HANA, plantean tres posibilidades para los procesos:

estandarización → armonización → individualización.

La lógica es sencilla. Hay procesos donde mantener un estándar común puede aportar eficiencia. Hay otros donde algunas diferencias pueden conservarse. Y existen procesos cuya particularidad resulta suficientemente importante para el negocio como para justificar un diseño distinto.

Por eso la pregunta no debería ser:

¿estándar o personalizado?

Sino:

¿qué nivel de diferenciación necesita realmente este proceso?

1. Primero entiende por qué existe la diferencia

Una excepción puede tener muchas causas. Puede existir por una regulación. Por una particularidad comercial. Por un tipo de producto. Por una condición operativa. Por un cliente. Por una integración. Pero también puede existir porque durante años se construyeron pasos alrededor de limitaciones que ya no existen.

Antes de modificar SAP conviene identificar:

• cuándo ocurre la variante;
• quién la utiliza;
• cuántos casos representa;
• qué problema resuelve;
• qué ocurriría si desapareciera;
• qué impacto tendría adoptar el estándar.

El objetivo es distinguir una necesidad crítica de una costumbre histórica.

2. No todas las variantes tienen el mismo valor

Un proceso puede ejecutarse de decenas de maneras. Pero eso no significa que las diez, veinte o cien variantes tengan el mismo peso.

Fleig et al. (2018) utilizaron process mining precisamente para analizar variantes de procesos y determinar cuáles debían considerarse al diseñar procesos futuros. El análisis permitió observar los recorridos ejecutados realmente y posteriormente combinar esa evidencia con conocimiento de los responsables del proceso.

Este enfoque permite pasar de:

“este flujo es importante porque lo hacemos así”

a preguntas más concretas:

• ¿con qué frecuencia ocurre?
• ¿qué casos dependen de él?
• ¿qué impacto tendría eliminarlo?

3. Estandarizar puede reducir complejidad

Cuando distintas áreas resuelven la misma necesidad mediante procesos diferentes, mantener todas las variantes puede aumentar la complejidad.

Cada diferencia puede afectar:

• capacitación;
• soporte;
• documentación;
• integraciones;
• pruebas;
• desarrollos;
• mantenimiento futuro;
• cambios posteriores.

Por eso la estandarización puede aportar valor cuando varias variantes realizan esencialmente la misma función sin una razón de negocio suficientemente fuerte para mantenerse separadas. Pero esto no significa que estandarizar siempre sea correcto.

4. Hay procesos donde la particularidad sí importa

Fleig et al. (2018) también advierten sobre el riesgo de eliminar variantes necesarias para procesos esenciales del negocio. Una diferencia puede representar una capacidad que permite atender un mercado, un cliente o una característica particular de la operación.

En esos casos, forzar un estándar podría afectar el desempeño del proceso. Por eso, la personalización debería responder a una necesidad demostrable, no únicamente a una preferencia.

5. Antes de desarrollar, revisa el AS-IS

Una decisión sólida necesita entender cómo funciona hoy el proceso. No únicamente cómo aparece documentado. Los registros de un ERP pueden ayudar a reconstruir el AS-IS y revelar diferencias entre la definición formal y la ejecución diaria.

Ingvaldsen y Gulla (2008) explican que los datos transaccionales de SAP permiten estudiar cómo se ejecutan los procesos, aunque requieren preparación para poder reconstruir correctamente las relaciones entre actividades y documentos.

Esta información puede ayudar a responder:

• ¿el proceso actual sigue realmente el flujo diseñado?;
• ¿dónde aparecen variantes?;
• ¿qué actividades generan modificaciones?;
• ¿qué pasos se ejecutan con mayor frecuencia?;
• ¿dónde existen excepciones?

Esto reduce el riesgo de diseñar el futuro sobre una percepción incompleta del presente.

6. Pregunta si el problema está realmente en SAP

Un usuario puede pedir una personalización porque el proceso resulta incómodo. Pero la causa puede estar en otro lugar.

Por ejemplo:

Problema: una aprobación tarda demasiado.

La reacción podría ser modificar SAP. Pero el análisis podría mostrar que el retraso ocurre porque la aprobación depende de una persona que recibe la información incompleta.

En ese escenario, el problema principal no necesariamente es tecnológico.

Por eso, antes de desarrollar conviene separar:

• problema de sistema
• problema de proceso
• problema de datos
• problema de integración
• problema de adopción.

Una personalización resuelve solamente algunos de esos escenarios.

7. Evalúa el impacto futuro de la personalización

Una modificación puede resolver una necesidad hoy y generar nuevas dependencias mañana.

Antes de aprobarla conviene preguntar:

• ¿quién mantendrá esta solución?;
• ¿requiere conocimientos específicos?;
• ¿afecta integraciones?;
• ¿genera nuevas pruebas ante cambios?;
• ¿aumenta la dependencia de desarrollos particulares?;
• ¿la necesidad podría resolverse de otra manera?;
• ¿seguirá teniendo sentido si cambia el proceso?

No se trata de evitar toda personalización.

Se trata de que cada personalización tenga una razón suficientemente clara.

Una matriz simple para decidir

Situación	Dirección que conviene evaluar
Variantes distintas sin diferencia de negocio clara	Estandarizar
Procesos similares con algunas diferencias justificadas	Armonizar
Variante necesaria para una capacidad crítica	Evaluar individualización
Excepción utilizada muy pocas veces	Revisar si realmente debe mantenerse
Proceso con alto retrabajo	Analizar causa antes de personalizar
Usuarios trabajan fuera de SAP	Revisar proceso, adopción y funcionalidad
Desarrollo pedido para conservar una práctica histórica	Validar primero si sigue aportando valor

Esta matriz no sustituye un análisis funcional. Sirve para evitar que la primera respuesta sea automáticamente “desarrollemos”.

¿Dónde puede ayudar el process mining?

El process mining puede aportar evidencia sobre cómo se comportan realmente las variantes.

Por ejemplo:

• cuántos casos siguen cada recorrido;
• qué actividades aparecen;
• dónde existen desviaciones;
• qué variantes son frecuentes;
• dónde se concentran determinados tiempos.

En el caso estudiado por Fleig et al. (2018), esta información se utilizó para comparar procesos AS-IS con posibles diseños TO-BE y apoyar decisiones sobre estandarización y conservación de variantes relevantes.

El valor no estuvo únicamente en visualizar el proceso.

Estuvo en utilizar los datos como insumo para decidir qué debía cambiar.

La frecuencia tampoco decide por sí sola

Que una variante ocurra muchas veces no significa automáticamente que sea correcta. Y que ocurra pocas veces no significa que sea irrelevante.

Puede existir un proceso poco frecuente que sea crítico para un cliente, una regulación o una situación excepcional. Por eso los datos necesitan interpretación.

El análisis debería combinar:

frecuencia + impacto + criticidad + conocimiento del negocio.

Antes de modificar SAP, responde estas preguntas

1. ¿Qué problema estamos intentando resolver?
2. ¿Cómo funciona realmente el proceso hoy?
3. ¿Por qué existe la variante?
4. ¿Qué porcentaje de casos la utiliza?
5. ¿Qué valor aporta al negocio?
6. ¿Podría el estándar cubrir la necesidad?
7. ¿Qué complejidad agregará mantenerla?
8. ¿Qué ocurriría si no hacemos la personalización?

Si estas respuestas todavía no están claras, probablemente aún no es momento de decidir el desarrollo.

Personalizar con criterio, no por inercia

Un ERP necesita adaptarse a la realidad del negocio. Pero adaptar no significa reproducir automáticamente dentro del sistema cada excepción existente.

En algunos procesos conviene estandarizar. En otros, armonizar. Y en aquellos donde la diferenciación realmente aporta valor, puede existir una razón válida para conservar una variante.

La decisión debería surgir de comprender primero:

cómo funciona hoy → por qué funciona así → qué valor aporta la diferencia → qué impacto tendrá mantenerla.

Solo después conviene decidir qué modificar.

¿Necesitas evaluar un proceso antes de modificar SAP?

En Altamira Technology realizamos Assessment TI para identificar brechas entre procesos, aplicaciones, datos e integraciones antes de definir cambios tecnológicos. El objetivo es entender primero la causa del problema y priorizar qué debe modificarse, qué puede optimizarse y qué quizá no necesita desarrollo.

Referencias

Fleig, C., Augenstein, D., & Maedche, A. (2018). Process mining for business process standardization in ERP implementation projects: An SAP S/4 HANA case study from manufacturing. Proceedings of the Dissertation Award, Demonstration, and Industrial Track at BPM 2018.

Ingvaldsen, J. E., & Gulla, J. A. (2008). Preprocessing support for large scale process mining of SAP transactions. En A. ter Hofstede, B. Benatallah, & H.-Y. Paik (Eds.), Business Process Management Workshops (Lecture Notes in Computer Science, Vol. 4928, pp. 30–41). Springer.

Roest, A. (2012). A practitioner’s guide for process mining on ERP systems: The case of SAP order to cash [Master’s thesis, Eindhoven University of Technology].