El Síndrome de Procusto: cómo recortar el talento para hacerlo encajar

En los caminos que llevaban a Atenas vivía Procusto. No era un ladrón vulgar ni un asesino impulsivo. Se presentaba como un anfitrión correcto, casi amable. Invitaba a los viajeros cansados a pasar la noche en su casa, les ofrecía descanso y un lecho donde recuperar fuerzas. Su casa tenía una sola regla.

Una cama de hierro ocupaba el centro de la estancia. No era especialmente bella, pero sí sólida, recta, perfecta. Procusto la miraba con orgullo. Para él, aquella cama representaba el orden.

Cuando el viajero se tumbaba, Procusto medía. Si el cuerpo sobresalía, cortaba lo que sobraba. Si el cuerpo no alcanzaba, estiraba hasta que encajara. La cama nunca se ajustaba al hombre, era el hombre quien debía ajustarse a la cama.

Muchos viajeros murieron allí sin entender qué habían hecho mal, no eran culpables de nada, no habían fallado, simplemente no encajaban.

El mito termina cuando Teseo llega a su casa. Fingiendo aceptar la hospitalidad, espera el momento adecuado. Cuando Procusto intenta someterlo al ritual de la cama, Teseo se libera, invierte la situación y obliga a Procusto a tumbarse en su propia cama de hierro. Por primera vez, Procusto es quien no encaja. La medida que había impuesto a todos se vuelve contra él. Y la cama, fiel a su naturaleza, no se adapta. Procusto muere víctima de la misma norma rígida que había defendido, descubriendo demasiado tarde la violencia de un sistema que no admite excepciones.

El síndrome de Procusto

El mito de Procusto no habla de monstruos ni de épocas lejanas, habla de sistemas, de poder y de miedo a la diferencia, habla de la obsesión por imponer una medida única a realidades diversas.

Hoy llamamos síndrome de Procusto a la tendencia a:

  • rechazar lo que sobresale,
  • castigar lo que no encaja,
  • forzar la realidad para que se adapte a un modelo previo.

No es un trastorno clínico, es una actitud, y es más común de lo que parece.

Procusto en la empresa moderna

Muchas organizaciones siguen teniendo una cama de hierro en el centro de la habitación.

  • Procesos inamovibles.
  • Metodologías convertidas en dogma.
  • Roles definidos hace años que ya no reflejan la realidad.

Cuando alguien aporta algo distinto, no se revisa la cama. Se revisa a la persona.

“Aquí siempre se ha hecho así.”
“No compliques las cosas.”
“Eso no entra en el modelo.”

El talento que sobresale se recorta, el que no llega se estira hasta romperse. No por maldad, sino por miedo, no por eficiencia, sino por control.

Estandarizar no es uniformar

La estandarización bien entendida ordena, la uniformidad impuesta empobrece.

Procusto no buscaba justicia ni equilibrio. Buscaba que nada desbordara su medida. Y muchas veces, detrás de estructuras rígidas, no hay excelencia ni rigor: hay inseguridad.

Un sistema sano se adapta a las personas.
Un sistema enfermo obliga a las personas a adaptarse a él.

Liderazgos procústicos

El liderazgo procústico no grita, no siempre amenaza, a menudo se disfraza de sentido común. Es el líder que:

  • se rodea de perfiles que no le hagan sombra,
  • desconfía de quien piensa distinto,
  • confunde obediencia con alineación.

No destruye el talento de golpe, lo va recortando poco a poco, hasta que todos encajan, y ya nadie destaca.

Procusto, Sísifo e Ícaro

Si Sísifo representa el trabajo sin sentido y Ícaro la ambición sin límite, Procusto encarna algo aún más inquietante:
la mediocridad impuesta desde el poder.

  • Sísifo empuja.
  • Ícaro vuela demasiado alto.
  • Procusto impide que nadie vuele ni avance.

Tres formas distintas de destruir valor.

En Conclusión

El mito de Procusto deja una advertencia incómoda:

No todo lo que se presenta como orden es justo.
No toda igualdad es equitativa.
Y no toda norma merece ser defendida.

A veces, el problema no es que las personas no encajen, el problema es que la cama nunca se movió. Y cuando una organización prefiere conservar la cama antes que cuestionar su medida, el final del mito suele repetirse.

Si…

Si puedes mantener la calma
cuando el entorno entra en pánico
y aun así te señalan a ti como causa del problema.

Si confías en tu criterio
cuando todos dudan,
pero escuchas cuando alguien con experiencia te cuestiona.

Si sabes estimar un proyecto
sin prometer lo que no controlas,
y no respondes con humo
cuando te venden humo.

Si puedes convivir en entorno cambiante
sin perder la visión,
y tratar igual al usuario perdido
que al decisor impaciente.

Si soportas reuniones eternas
y aun así sales con una decisión clara.
Si explicas lo complejo sin parecer arrogante
y lo simple sin parecer ingenuo.

Si no te crees imprescindible
cuando el proyecto va bien,
ni te hundes cuando todo falla
y el sistema antiguo sigue funcionando.

Si puedes convertir incidencias en aprendizaje,
UATs en conversación,
y errores en diseño mejorado.

Si sabes decir «no» cuando toca,
«todavía no» cuando es honesto,
«no lo sé» cuando es verdad,
y «lo siento» cuando te has equivocado.

Si entiendes que la tecnología es el medio
y el valor el objetivo,
que SAP no es el fin
y el negocio no es el enemigo.

Si tras el cierre del proyecto
sigues teniendo curiosidad,
ganas de aprender
y respeto por quien lo mantiene.

Entonces, solo entonces,
no serás solo alguien que implementa SAP

Serás consultor

Basado libremente en el poema “Si…” de Rudyard Kipling.
Adaptado a lo que, con los años, he aprendido sobre la consultoría SAP.

Proof of Concept (PoC)

Hoy en, anglicismos para parecer más cool (otro), vamos a explicar qué es eso de Proof of Concept. En castellano «Prueba de Concepto» o, más comúnmente llamado, «piloto».

Ya no hay pilotos como antes
(si reconoces esta imagen estás en mi equipo)

¿Qué es Proof of Concept?

Hay veces que, ante una necesidad de un cliente, para satisfacerla a nivel tecnológico, sucede alguna de estas situaciones:

  • Incertidumbre tecnológica: No está clara la tecnología a aplicar
  • Evaluación de soluciones: No está clara la mejor de las soluciones de entre las propuestas
  • Costes elevados: El coste de implementar la solución es muy elevado
  • Resistencias internas: Hay resistencias por parte de los key users, dirección u otras áreas.

Si sucede alguna de estas situaciones una solución habitual es hacer una prueba de concepto (Proof of Concept) o piloto.

Un Proof of Concept o Prueba de Concepto es el implementar una solución acotada de la solución final. La forma de acotar puede variar dependiendo del contexto y los objetivos, pero generalmente implica reducir la escala del proyecto, simplificar funcionalidades y/o limitar el tiempo y recursos asignados. Y, en el caso de herramientas estándar, como SAP, minimizar al máximo, o incluso evitar cualquier desarrollo o ampliación, intentando enseñar como la herramienta estándar se adapta a las necesidades del negocio.

Resumiendo, lo más normal en una PoC es tomar un escenario aislado, dentro de todas las necesidades del cliente, y montarlo en la tecnología seleccionada como prueba del potencial a obtener si se implementa la solución completa para toda la necesidad.


Objetivos de un Proof of Concept

Una vez sabemos el qué es y el porqué, vamos a ahondar en cuales son los objetivos de realizar una PoC.

  • Validar la viabilidad técnica: Verificar si la tecnología propuesta es capaz de cumplir con los requisitos y expectativas del proyecto.
  • Identificar problemas y riesgos: Detectar posibles inconvenientes técnicos, organizativos o de otro tipo que puedan surgir durante la implementación.
  • Demostrar el valor de la solución: Proporcionar evidencia tangible de que la solución propuesta puede resolver el problema del cliente y ofrecer beneficios concretos.
  • Obtener retroalimentación: Recoger opiniones y comentarios de los usuarios clave y otras partes interesadas para ajustar y mejorar la solución antes de su implementación completa.

Pasos para desarrollar un Proof of Concept

Ya sabemos el qué, el porqué y el para qué, ahora vamos a ver el cómo. Para ello, como ejemplo, podemos proponer los siguientes pasos:

  1. Definir los objetivos y el alcance: Establecer claramente qué se pretende lograr con la prueba y cuáles son los límites del proyecto piloto.
  2. Seleccionar las herramientas y tecnologías: Elegir las tecnologías y herramientas que se utilizarán en la prueba de concepto.
  3. Desarrollar un prototipo: Crear una versión simplificada de la solución final que permita realizar las pruebas necesarias.
  4. Realizar pruebas y recopilar datos: Ejecutar la prueba de concepto y recopilar información relevante sobre su desempeño.
  5. Analizar los resultados: Evaluar los datos recopilados para determinar si la prueba de concepto ha cumplido con los objetivos planteados.
  6. Tomar decisiones informadas: Basándose en los resultados, decidir si se procede con la implementación completa, si se requieren ajustes, o si se debe reconsiderar la solución propuesta.

Riesgos de hacer una Prueba de Concepto (PoC)

Al hacer una PoC todas las partes implicadas tienen que estar alineadas con los requisitos, el alcance, la funcionalidad a implementar y las espectativas del resultado.

Entre los riesgos que hay que controlar cuando queremos hacer una PoC están:

  • Alcance mal definido: Como he comentado anteriormente, es crucial acordar. entre todas las partes, un alcance claro de cara, no solo a su implementación, sino también de las expectativas y demostración de funcionalidad potencial.
    • Alcance no relevante para el negocio: Una PoC sin sustancia suficiente no vale para que el negocio vea el potencial de la solución final
    • Alcance no claro: Habrá problemas con las expectativas de las partes. Desde el famoso «yo tenía un excel que hacía más cosas» hasta el «¿y esto no lanza la nómina de este mes?»
    • Alcance justo: No un alcance sin sustancia ni un alcance que sea ya la solución definitiva. Se trata de hacer un piloto, muchas cosas no funcionarán, porque no tendrán que funcionar.
  • Recursos insuficientes: Vamos, que te dejan a ti solo a hacer una PoC de un alcance que supone mucho trabajo. Tampoco está bien poner un equipo de 20 personas.
  • Dependencia de prototipos: Cuidado con ir montando la solución en base a prototipos o PoCs. La prueba de concepto ha de ser la llave de entrada al análisis, diseño e implementación de una solución final, robusta y funcional.
  • Falta de aceptación del usuario: Puedes ponerlo de colores, con música o con Gifs animados de gatitos. Puedes hacer una PoC perfecta, que satisfaga ese área del negocio acotado. Pero si no tienes a los usuarios/negocio apostando por ello, le buscarán los problemas. Ahora bien, mejor identificar estos problemas en una PoC que en un arranque a producción.
  • Problemas de integración: El eterno problema, es una PoC, hay que minimizar al máximo cualquier desarrollo. ¿Nos integramos con otros sistemas? Pues hay ocasiones en las que no hay más remedio si quieres que el negocio se sienta identificado. Hay que definir muy bien qué integraciones son necesarias e incluso posibles, puesto que en ocasiones las PoC se desarrollan fuera del ámbito tecnológico del cliente.

Conclusión

Las Proof of Concept, PoC o Prueba de Concepto son nuestros aliados, y cuando digo nuestros hablo de todos, Consultores, TI del cliente y negocio. Debe ser una palanca de cambio que nos ayude a ponernos en situación y poder evolucionar el negocio a nuevas metas tecnológicas.

Desde el punto de vista de la consultoría nos sirve como palanca para abrir negocio, poder mostrar nuestras capacidades y las de la solución, y la posibilidad de adaptación que tanto la solución como nosotros podemos aportar para conseguir satisfacer las necesidades del negocio.

SAP Mazinger Z

El título de este artículo sólo lo entenderán los Boomers y los Milenials como yo. Mazinger Z eran unos dibujos animados japoneses sobre un niño y un súper robot acojonante que luchaba con otros robots acojonantes u otros bichejos. Tampoco lo recuerdo mucho.

El tema del que vamos a hablar no son los dibujos, no os preocupéis, pero el nombre me venía perfecto para lo que quería explicar.

El caso es que SAP es una herramienta estándar, de caja, instalar, configurar y listo. Esa es su ventaja competitiva, y eso es por lo que los clientes pagan las licencias tan baratas que cobra SAP. Eso es lo que le ha traído aquí a estar donde está, y lo que ha hecho que sus competidores vayan saliendo con sus soluciones «Out of the box» al igual que SAP (Salesforce, Oracle, Microsoft, etc).

Out of the box

Pero en ocasiones, como los niños o los gatos.

A ciertos clientes y consultores lo que les gusta es jugar con la caja y no con el contenido.

Entienden que lo divertido es lo que ponga en la caja del software pero los procesos estándar, aplicaciones, integraciones no se adecúan a ellos.

Es aquí donde nace SAP Mazinger Z, poco a poco empresas, consultores y desarrolladores van construyendo una especie de sistema paralelo al sistema estándar.


Ampliaciones en SAP

Pero ¿por qué he traído el nombre de Mazinger Z? Porque en SAP, las ampliaciones de cliente se realizan, normalmente, con el prefijo Z. Hay locos que usan ‘Y’, pero esa gente quiere ver el mundo arder.

Yo entrando en un proyecto donde las ampliaciones comienzan por Y

Y claro, ceñirse al estándar es, en ocasiones, más difícil que hacerte un Mazinger Z monstruoso.

El primer nivel que debe controlar esto es el propio cliente, que es el dueño del negocio y es el que compra el producto (SAP) y debe ser consecuente con esa decisión.

Nadie compra un Ferrari para llevar una caravana

El segundo nivel es la consultoría. Como consultores tenemos la obligación de conocer la herramienta y saber adaptar el negocio del cliente manteniendo, en la medida de lo posible, el estándar. Ofrecerle al cliente las mejores prácticas tecnológicas de un software usado por miles de empresas. En definitiva, ser un buen consultor.

Presas del desarrollo

Y es que, en ocasiones, los sistemas se modifican tanto o se crean tantos procesos no estándar y tan complejos (y mal codificados/documentados) que el cliente y la consultora se hace presa del desarrollo realizado. En ocasiones me he encontrado con semidioses intocables, creadores del averno codificado, que están ahí porque son los padres de la fiera y los únicos que saben domarla. Se han convertido en los dueños del Mazinger Z.


Upgrades y actualizaciones estándar

Porque claro, cuando se compra una herramienta como SAP se paga una licencia anual que, entre otras cosas, te asegura el soporte y mantenimiento de la herramienta estándar, corrigiendo errores vía Support Packages o Notas. Además puedes querer o necesitar un upgrade a una nueva versión superior.

Cada vez que SAP lanza una actualización, los desarrollos Z pueden generar incompatibilidades que requieren tiempo y recursos adicionales para ser resueltos, afectando la agilidad del negocio.


Futuro y tendencia

Con el avance de las plataformas Low-code y No-code, el futuro del desarrollo en sistemas ERP podría orientarse hacia configuraciones cada vez más sofisticadas sin necesidad de recurrir a desarrollos complejos, facilitando el mantenimiento y las actualizaciones. Ejemplos de esto en SAP seria, SAP Build, SAP Build Code, Github Copilot, Microsoft Power Platform, etc.


En conclusión

El desarrollo dentro de suites como SAP es, sin duda, necesario, pero, como consultores, tenemos que conocer la herramienta y sus posibilidades, saber si de una manera u otra los requerimientos del negocio pueden ser satisfechos configurando la herramienta y, finalmente, si es necesario un desarrollo, acotar bien el alcance del mismo.

En un mundo donde la tecnología evoluciona rápidamente, saber cuándo y cómo construir tu propio ‘Mazinger Z’ dentro de SAP puede ser la diferencia entre un sistema que empodera a tu negocio y uno que lo atrapa en su propia complejidad.

A nadie le despiden por contratar IBM

Eres el CIO de una empresa. En tu empresa habéis decidido hacer una transformación digital y dejar de una vez el ábaco y el Excel para llevar ventas, almacén, finanzas y costes y queréis implementar SAP como ERP de la empresa. Habéis lanzado la RFI (Request for Information) para pedir información, os han respondido tres consultoras medianas, tienen buena pinta, hacen hincapié en su experiencia, conocimiento y capital humano para afrontar un proyecto de implantación de SAP S4/HANA. Ninguna de las ¿grandes? ha contestado a la RFI.

Una de las consultoras (JOB Consulting), la que ha mostrado más interés y se ha preocupado por tus procesos, se presta a ayudarte a elaborar la RFP (Request for Proposal). Una vez consensuada con Negocio, TI y Dirección lanzas la RFP a las tres consultoras que te contestaron a la RFI y, aunque no se haya preocupado anteriormente, a una de las ¿grandes? (Deloitte, Accenture, NTT Data, IBM, Indra. Elige tu propia aventura).

The big 4

Las cuatro consultoras contestan a la RFP con su propuesta de solución, implementación y costes. La consultora que te ayudó a elaborar la RFP es la que mejor propuesta de valor ofrece. Hace referencia a procesos de tu negocio y da soluciones dentro de la herramienta elegida. Tiene casos de éxito, referencias, perfiles especializados, capital humano suficiente, solvencia en el mercado y un precio de implantación medio. Hay otras respuestas a la RFP más genéricas y más caras, más automáticas, sin tanto detalle por tu negocio. Tu invitado ¿grande? a la RFP mandó la respuesta fuera de plazo (bueeeno se lo admitimos), con carencias funcionales y bastante genérica, a nivel de músculo (financiero y capital humano) son, obviamente, el increíble Hulk. La oferta que ofrecen no cubre toda la funcionalidad de una vez, se presentan distintas fases de proyecto, solo dando precio a la primera, el producto mínimo viable (MVP). Obviamente el precio es muy bajo.

Producto Mínimo Viable (MVP) vs Producto Completo

No hay forma de comparar la respuesta de la consultora JOB Consulting y la ¿grande?. Tu yo interior, experto en tecnología y machacado en mil batallas lo tiene claro, la consultora JOB es la que más valor aporta y menos riesgo tiene a nivel tecnológico. Pero tú vas al consejo de administración, con el CEO y los distintos directores de área. Ellos expresan que no conocen a JOB, que sí conocen a la ¿grande?, pero que tu eres el CIO y delegan en ti la responsabilidad.

Pero esa reunión y ese dedo que te señala va calando en ti. ¿Y si sale mal? ¿Y si elijo a la consultora desconocida por el consejo y no va bien? Eres cobarde y te quieres aferrar al puesto porque vives en La Jaula de Oro. ¿A quien iban a despedir si va mal con la ¿grande?? ¿Quién se iba a imaginar que la ¿grande? pudiese fallar? El precio inicial es mucho más bajo pero, claro, solo incluye una parte, además no han participado muy activamente en la RFP.

Al final tu empresa decide (tú decides) contratar a la ¿grande? para hacer la implantación. El primer día aparece allí el socio, con el director y el manager, y te dejan una horda de 12 consultores de 25 años recien graduados, con uno que parece que más o menos sabe. Sabes que vas a sufrir, que los key uses del negocio van a sufrir, que tus usuarios van a sufrir, que el negocio va a sufrir, pero tu tomaste la decisión más coherente.

Tú observas la escena y te das cuenta de que has optado por lo que parecía la opción segura, la que el consejo reconocía, la que nadie cuestionaría en caso de fracaso. Sin embargo, una duda persiste en tu mente: ¿He elegido la mejor opción para el proyecto o solo la opción que me protege a mí?. Este es el dilema que enfrenta cualquier líder en tecnología cuando la reputación pesa más que el valor real.

Al final del proyecto, cuando todo esté en llamas, nadie te despedirá por contratar a la ¿grande?

… pero tampoco te felicitarían si hubieras tomado la decisión más valiente.