Etiqueta: Consultoría

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.

Ser 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.

SAP Build

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.

Fases de un proyecto (Waterfall)

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.

Éxito

He fracasado, intenté realizar un cambio, emprender un nuevo camino, alcanzar nuevas metas, llegar al éxito, pero aquello no funcionó. Pero he llegado al éxito después del fracaso.

¿Qué es el éxito?

Pues cada uno tendrá su definición de éxito, pero hay que tener mucho cuidado con algunas consideraciones de éxito.

  • ¿Es éxito ganar mucho dinero? Depende del pago que debes realizar para conseguirlo.
  • ¿El éxito es ir ascendiendo en puestos en la empresa? El principio de Peter golpea duro.
  • ¿El éxito es tener un  BMW, Mercedes, Lamborghini? Cuidado con la Jaula de Oro.
Si estás pensando que es mejor llorar en un Lamborghini, ánimo

Más no es mejor. Mejor es mejor

En el mundo en el que vivimos del ya, del ahora, de los perfiles de Instagram, LinkedIn, TikTok, Redes Sociales, de los Likes, etc. Parece que el éxito solo existe cuando se puede medir. Lo marcará el número de Likes, contactos, salario, estatus, nombre anglosajón  de tu puesto de trabajo (¿Vice President? ¿En serio?), fotos de viajes, número de países visitados o fotos de comidas en restaurantes en Instagram.

Sin embargo, hay otros criterios no medibles que, en una primera instancia, por el simple hecho de no poder ser medidos y poder «demostrar» cuanto de eso tienes, son menospreciados. Y, sin ningún lugar a dudas, son los más importantes. Criterios como:

  • Sentirte realizado y valorado en el trabajo
  • Tener una red de amigos en el mundo laboral
  • Ocio
  • Tiempo libre
  • Tiempo de calidad con tu familia
  • Tiempo para hacer ejercicio o deporte

Es decir, tiempo para ser tú mismo, para desarrollarte como persona, para estar con los tuyos, para mejorar tu cuerpo, mente y energía, para ser feliz. El problema es que el dinero no puede comprar el tiempo, suele ser al revés, cuanto más dinero quieres ganar, menos tiempo te deja ese puesto de responsabilidad. ¿De verdad compensaba ese ascenso?.

Tu vida solo pasa una vez en tu vida

Y es que hay cosas que no tienen una segunda oportunidad.

Tus hijos sólo nacerán una vez en la vida, sólo tendrán edad para que les cuentes un cuento por la noche durante un periodo corto del tiempo.

Tu cuerpo, cuando quizás ya sea tarde, explotará diciéndote que no te has levantado de la silla durante años, que has dormido mal, que has tomado demasiado café o cervezas y que no has movido el culo.

Tu pareja estará contigo por costumbre, por inercia, por conveniencia, pero no compartiréis el camino común.

Y finalmente tú, te darás cuenta cuando tengas 50, 60 o 70 años que lo has dado todo por un proyecto que no es el tuyo, por una empresa que no es la tuya y que no has construido tu identidad aparte de ese trabajo. Que no eres nadie, y estás vacío, y cuando te jubiles, no sabrás qué hacer esas 10-12 horas al día que antes gastabas en el trabajo.

Ser, Estar, Parecer

De pequeño me enseñaron que los verbos copulativos son Ser, Estar y Parecer. Y hay gente que parece ser que se queda con el «Parecer» y se olvidan del «Ser» y del «Estar».  Cierto es que ‘Ser’ y ‘Estar’ es mucho más complicado que ‘Parecer’, porque no tienen fin, no hay un momento en el que llega alguien que te pone la medalla del ‘Ser’ algo concreto y que para ‘Estar’ es necesario estar y gastar tu tiempo en ese ‘Estar’. Y es mucho más fácil «Parecer» porque no cuesta, no duele y no tienes que renunciar a nada.

Pirámide de Maslow

La pirámide de Maslow, también conocida como la jerarquía de las necesidades de Maslow, es una teoría psicológica propuesta por Abraham Maslow en su trabajo de 1943 «Una teoría sobre la motivación humana». Esta teoría sugiere que las necesidades humanas se encuentran organizadas en una jerarquía de cinco niveles, y que las necesidades más básicas deben ser satisfechas antes que los individuos puedan atender a necesidades más elevadas. La pirámide se divide en cinco niveles, que van desde las necesidades más básicas hasta las más complejas.

Si os dais cuenta, en una persona ‘sana’ (bueno eso es otro debate) primero hay que satisfacer ciertas necesidades básicas hasta llegar a la autorrealización. Nos podemos enrollar con esto de la pirámide de Maslow, pero si te interesa hay mucha información en Internet.

Conclusión

Cada uno tendrá su definición de éxito, y su forma de ver la vida. La mía, después de transitar sobre varios terrenos y después de muchos errores, es esta. Intento ser y estar en aquello que es importante, incluido el trabajo por supuesto. Y agradezco tener mucha gente en mi profesión que me quiere y me valora, y no sólo por mi valía profesional.

El éxito no es la clave de la felicidad. La felicidad es la clave del éxito. Si amas lo que haces, tendrás éxito.

Albert Schweitzer

Fdo: Jorge Ocampos

Padre, Compañero y Consultor

De Ícaro a Fénix

Hoy traigo Mitología Griega que me encanta, todo muy coherente con el sentido del blog (no). Bueno, veréis como sí tiene que ver con nuestra profesión (o cualquiera) y las motivaciones, debilidades y fortalezas humanas.

(Todas las imágenes han sido generadas con ChatGPT y Dall-E 3)

El Mito de Ícaro

Cuenta la leyenda de la mitología griega que Ícaro era el hijo de Dédalo, un talentoso inventor y arquitecto ateniense. Dédalo era famoso por haber construido el Laberinto en Creta, donde el rey Minos encarceló al Minotauro (esa es otra historia), una criatura mitad hombre y mitad toro.

Sin embargo, tras ayudar a Teseo a matar al Minotauro y escapar del Laberinto, Dédalo cayó en desgracia con el rey Minos. Como castigo, el rey Minos encerró a Dédalo y a su hijo Ícaro en una torre alta en Creta para evitar que escaparan y difundieran los secretos del Laberinto. Sin embargo, Dédalo, con su ingenio, ideó un plan para huir: construir alas hechas de plumas de aves y cera para Ícaro para poder volar sobre el mar y escapar de la isla.

Antes de iniciar el vuelo, Dédalo advirtió a Ícaro que no volara demasiado alto ni demasiado bajo. Si volaba demasiado bajo, el agua del mar empaparía las alas y lo haría caer. Si volaba demasiado alto, el calor del sol derretiría la cera que mantenía las plumas unidas.

Lleno de emoción por la experiencia de volar, Ícaro olvidó las advertencias de su padre y, embriagado por la sensación de libertad, comenzó a ascender cada vez más alto en el cielo. Al acercarse demasiado al sol, la cera de sus alas comenzó a derretirse, haciendo que las plumas se desprendieran. Sin posibilidad de mantener el vuelo, Ícaro cayó desde el cielo y se hundió en el mar, donde se ahogó. El lugar donde Ícaro cayó fue nombrado en su honor: el Mar Icario.

Reflexión sobre el Mito de Ícaro

La leyenda de Ícaro se puede interpretar como una advertencia sobre los peligros de la desmesura, el exceso de confianza y la desobediencia. La ambición de Ícaro lo llevó a ignorar los límites y las precauciones, lo que resultó en su caída.

Para mi, o sobre lo que yo quiero reflexionar en este artículo, es que hay que tener cuidado con la ambición, saber medir los riesgos, controlarse y controlarlos. Nada es gratis y, si intentas volar muy cerca del sol, es muy posible que te quemes.

Así que la próxima vez que sientas el deseo de volar más alto que nunca, recuerda que incluso el cielo tiene sus límites. Pero, claro, eso no significa que no debamos intentar volar.

El Mito del Ave Fénix

En un rincón lejano del mundo, mucho antes de que la humanidad pudiera siquiera imaginar criaturas fantásticas, existía un ser único, majestuoso y envuelto en misterio: el Ave Fénix. Era un ave radiante como ninguna otra, con plumas doradas y rojas que parecían llamas vivientes. Pero lo que hacía especial al Fénix no era solo su belleza, sino su increíble capacidad para renacer de sus propias cenizas.

Cuenta la leyenda que el Fénix vivía en un paraíso escondido, donde el tiempo pasaba de manera diferente. Su vida no era corta como la de otras aves, sino que duraba siglos. Sin embargo, el Fénix sabía que, al igual que todo en el universo, su tiempo también llegaría a su fin. Cuando empezaba a sentir el peso de los años y la fatiga en sus alas, el Fénix se preparaba para el gran momento: su renacimiento.

Cuando el tiempo llegaba, volaba hasta lo más alto del cielo y, desde allí, descendía en un vuelo majestuoso hacia su nido hecho de ramas de especias y plantas aromáticas. Una vez en su nido, el Fénix dejaba que las llamas lo envolvieran, ardiendo con un fuego brillante y purificador. Todo su cuerpo se consumía en ese fuego, hasta que no quedaba más que un montón de cenizas.

Pero aquí es donde ocurría el milagro: de esas mismas cenizas, entre el humo y el calor residual, nacía un nuevo Fénix, joven y lleno de vida. Con un poderoso aleteo, este nuevo ser emergía, más hermoso, con más energía y más resplandeciente que antes. Y así, una y otra vez, el Fénix vivía y moría, solo para resurgir con más fuerza.

Reflexión sobre el Mito del Ave Fénix

Resumen rápido: Cuando te caes, te levantas, aprendes y mejoras.

El mito del Ave Fénix es un poderoso mensaje sobre resiliencia, renacimiento y esperanza. El Fénix simboliza la capacidad de resurgir de las cenizas, incluso después de haber pasado por momentos de destrucción o pérdida.

Este mito nos recuerda que, aunque atravesemos dificultades, fracasos o situaciones dolorosas, siempre existe la posibilidad de volver a levantarse y comenzar de nuevo, renovados y fortalecidos.

¿Por qué cuento esto? ¿Qué relación tiene?

Bueno, digamos que es una reflexión personal que estoy contando en público. Es muy fácil convertirse en Ícaro, querer volar demasiado cerca del sol pero que tus capacidades, tu entorno, las alas que tienes o el destino donde quieres volar te hagan caer, y la caída es dura.

Pero es más difícil, una vez habiéndote convertido en cenizas, como el Ave Fénix, al volar tan cerca del Sol, resurgir de tus cenizas, aprender de los errores y hacer que ese tropiezo sea una lección aprendida que te haga resurgir con más fuerza, siendo más consciente de lo bueno que tienes y queriendo mejorar.

Y en eso estamos:

De Ícaro a Fénix