Categoría: Consultoria TI

Consultoría en tecnología de la información

«Muchos jefes para tan pocos indios»

“Las empresas de servicios profesionales, con su insistencia en el desarrollo de carreras profesionales, llegan a curiosas situaciones de pirámide invertida: un becario, dos seniors, tres gerentes y cuatro socios. Así no es extraño que el becario vaya con la lengua fuera porque sus brazos son los únicos sobre los que recaen la infinidad de planes de tantas cabezas pensantes”


Esta entrada podríamos decir que nos ha ayudado Gabriel Ginebra, autor del recomendable libro “El japonés que estrelló el tren para ganar tiempo”, del que utilizamos algunos extractos de su obra:

“Las empresas de servicios profesionales, con su insistencia en el desarrollo de carreras profesionales, llegan a curiosas situaciones de pirámide invertida: un becario, dos seniors, tres gerentes y cuatro socios.  Así no es extraño que el becario vaya con la lengua fuera porque sus brazos son los únicos sobre los que recaen la infinidad de planes de tantas cabezas pensantes”

El párrafo anterior bien podría ser un ejemplo de expresiones tan populares como las siguientes:

  • Uno trabajando y nueve mirando
  • Sobran gestores, faltan hacedores
  • Muchos jefes para tan pocos indios

“… Hay empresas tan ricas que producen dos productos paralelos y sin ninguna relación: un producto que la gente compra y con el que ganan dinero, y otro producto (declaraciones, reuniones, programas de calidad) sin relación alguna con el anterior, que nadie compra…. Hemos descuidado el negocio y estamos centrados en actividades como medir, planificar o controlar. Todos queremos dirigir, porque trabajar es más cansando.”

La consultoría informática nos obliga a mantenernos al día de la innovación tecnológica y en profundizar en aquello que consideramos nuestra especialidad, para de este modo brindar el mejor servicio a nuestros clientes.  La gestión es importante, pero si a la consultoría informática nos dedicamos, quizás la proporción promedio para todos los niveles de un equipo debería ser 50% para cada una de estas habilidades (gestión y conocimiento tecnológico), sabiendo lo que se debe hacer y quizás haciéndolo, contribuiremos a la eficiencia, reduciendo las casi siempre improductivas reuniones y documentos de coordinación.

“Bien o bonito, lo hago otro día”… Cuando la calidad no es importante

Hace unos días culminé con unas sesiones de SAP Business Intelligence, y como es lógico, en la última sesión tocaba “examen”, eso sí, con todo el material a su disposición (como en la vida real), incluyendo Google. En los últimos minutos, revisando los trabajos, me percato de algunas soluciones “originales”, brindaban el resultado solicitado, pero de aquella forma que nunca quisiéramos encontrar si nos tocara modificarlo. Al exigir una explicación, se me indica que “hace lo que he pedido” y “que bien o bonito, ya lo haría otro día”… Plop!… Lo curioso de esta anécdota, es que respuestas similares ya la hemos escuchado en la “vida real”.


Hace unos días culminé unas sesiones de SAP Business Intelligence, y como es lógico, en la última sesión tocaba “examen”, eso sí, con todo el material a su disposición (como en la vida real), incluyendo Google.  En los últimos minutos, revisando los trabajos, me percato de algunas soluciones “originales”, brindaban el resultado solicitado, pero de aquella forma que nunca quisiéramos encontrar si nos tocara modificarla.  Al exigir una explicación, se me indicó “hace lo que he pedido” y “que bien o bonito, ya lo haría otro día”… Plop!…  Lo curioso de esta anécdota, es que respuestas similares ya la hemos escuchado en la “vida real”.

La culpa de esta situación, en parte fue mía, porque sólo me limité a indicar lo que quería (alcance) pero no detallé nada sobra la forma, especialmente lo relacionado a la calidad.  Algo similar sucede en los requerimientos de los proyectos informáticos, se señala lo que se desea pero no los criterios mínimos de calidad que debe tener la solución, para medianamente garantizar su mantenimiento y evolución.  Más “pecado” tiene cuando la calidad se olvida en la implementación de soluciones de Business Intelligence o Corporate Performance Management (CPM o EPM) las cuales van dirigidas a mejorar la eficiencia de los procesos de negocio.

Dar por su supuesto que la calidad será parte de la solución, sería un error.  Tal vez sea porque se reducen los costes y los plazos, pero parece que hacer las cosas bien se considera una pérdida de tiempo.  Para que esto no te suceda, te sugerimos que en el alcance de tu proyecto, especifiques lo siguiente:

  • Todos los entregables (documentos y solución en sí), deberían estar regidos por estándares de calidad oficiales o adaptaciones de las mismas.
  • Especificar los procedimientos para asegurar que la calidad de integra en la solución.  Por ejemplo, se podría definir una planificación de auditorías y como se actuará con el resultado de ellas.
  • Señale como se controlará la calidad, indicando las métricas, tolerancias y responsabilidades.

En una coyuntura tan dinámica o cambiante, de poco servirá una solución que nos brinde el alcance solicitado y que por problemas de calidad,  sea rígida o poco flexible a ser modificada o evolucionada.

Las funciones de un PMO

La “unidad de gestión de proyectos” (Project Management Office”, PMO) es la oficina responsable de centralizar y coordinar la gestión de proyectos dentro de una empresa. Constituida normalmente en forma de comisión o departamento, el objetivo principal de una PMO es mejorar la tasa éxito de los proyectos, estandarizando y apoyando las prácticas de gestión dentro de la organización, a través de la siguientes funciones:


La “unidad de gestión de proyectos” (Project Management Office”, PMO) es la oficina responsable de centralizar y coordinar la gestión de proyectos dentro de una empresa.  Constituida normalmente en forma de comisión o departamento, el objetivo principal de una PMO es mejorar la tasa éxito de los proyectos, estandarizando y apoyando las prácticas de gestión dentro de la organización, a través de la siguientes funciones:

  • Estándares, procesos y mejores prácticas. Define y facilita los protocolos, procedimientos y plantillas de gestión con el fin de lograr coherencia entre los proyectos.
  • Requisitos de certificación y reglamentarios. Respalda y controla el cumplimiento de los requisitos que apoyan a los objetivos de la empresa.
  • Metodología. Brinda apoyo y asesoramiento sobre técnicas de gestión de proyectos.
  • Herramientas e infraestructuras. La PMO se responsabiliza del despliegue de aplicaciones informática, plantillas, formularos y de la disponibilidad de repositorios para la elaboración y almacenamiento de los documentos de los proyectos
  • Recursos compartidos y comunicaciones. Administra al grupo de gestores de proyectos. En ocasiones, es responsable de la asignación de recursos y de coordinar la comunicación entre ellos.
  • Asesoramiento y capacitación.  La PMO asesora, lidera y forma a los gestores de proyectos para que contribuyan a mejorar las tasas de éxito.

Referencia: ISBN 9788441532250

«Esto es» como «este otro»… o la comodidad de «encontrar» similitudes entre las cosas

Estas son algunas expresiones que hemos escuchado en el mundo de la consultoría informática. Nadie quiere complicarse, pero se «peca» en el afán de simplificar todo con el fin de convencer y no entrar en detalles que quizás por desconocimiento se trata de evitar. No pretendemos asustar a nadie, sino de afrontar cada reto tecnológico con todo el conocimiento necesario para identificar las verdaderas posibilidades y limitaciones, y de este modo, gestionar adecuadamente su implementación.


  • BPC es como Excel,
  • La 10 es como la 7.5,
  • BusinessObjects es como MicroStrategy,
  • Una migración a BW sobre HANA es como cualquier otra migración… Plop!!!

Estas son algunas expresiones que hemos escuchado en el mundo de la consultoría informática.  Nadie quiere complicarse, pero se «peca» en el afán de simplificar todo con el fin de convencer y no entrar en detalles que quizás por desconocimiento se trata de evitar.  No pretendemos asustar a nadie, sino de afrontar cada reto tecnológico con todo el conocimiento necesario para identificar las verdaderas posibilidades y limitaciones, y de este modo, gestionar adecuadamente su implementación.

La necesidad de simplificar, resumir, asociar, catalogar o clasificar es parte de la naturaleza humana, pero dependiendo en qué contexto se formule, su utilidad o inutilidad tendrá un impacto directo sobre las cosas que se hagan.  Si se trata de la implementación de un producto SAP podemos señalar las siguientes premisas:

  • Ningún producto es similar a otro producto SAP, al de otro fabricante e inclusive las diferencias pueden ser importantes entre las versiones del mismo producto.
  • Difícilmente un producto SAP podrá llevar la etiqueta de producto terminado. La innovación es constante y en muchas ocasiones la madurez o estabilización del producto se logra cuando el producto es liberado y lo comienzan a utilizar los usuarios.
  • Las fortaleza de un producto son conocidas desde un inicio, pero muchas de las debilidades o limitaciones se descubren durante los períodos de implementación.

Las similitud informática no existe y menos entre SAP HANA con relación a la tecnología del pasado, y más aún, si sabe que SAP HANA presenta novedades constantemente.

No cuentes lo que has hecho, sino lo que puedes hacer por el cliente

Las iniciativas comerciales y estilos de comunicación que crea SAP son imitados por casi la totalidad de sus partners o consultoras que ofrecen los servicios de implementación de productos SAP…


Las iniciativas comerciales y estilos de comunicación que crea SAP son imitados por casi la totalidad de sus partners o consultoras que ofrecen los servicios de implementación de productos SAP (nota: sabemos que es más habitual usar el término implantar, implantación y sus derivados, pero creemos que el término que más se ajusta al objetivo que se persigue al poner en funcionamiento una solución informática que mejore la eficiencia de los procesos es implementación).

Desde una apreciación personal, consideramos que “la técnica” de contar “casos de éxito” está agotada, muy válido para SAP que se comunica a un amplio público, mundial y heterogéneo; pero quizás poco efectivo para un partner que tiene la oportunidad de comunicarse a un público conocido y concreto.

La facilidad con la que se puede encontrar “casos de éxito” en Internet, muchas veces mejor explicados y más relevantes, hace que el efecto “sorpresa” o “interesante” no se produzca cuando se cuenta lo que se ha hecho en otros sitios.  Por otro lado, nos encontramos con usuarios con una mayor presión de encontrar soluciones que se pueden adaptar a sus negocios, al cual consideran único y diferente.

Nuestra sugerencia es buscar la diferenciación constantemente, contar la experiencia es importante, pero no debe convertirse en el único mensaje, porque quizás el cliente se quede con la sensación de haber asistido a una exhibición del ego y no a una reunión en dónde esperaba llevarse ideas claras de cómo mejorar la gestión de sus procesos de negocio.