Archivo de la categoría: Consultoría de negocios

Consultoría de negocios

Quién es Quién 2014, (Consultoría e Informática) – 2da. edición


En mayo compartíamos el extracto sobre los rubros Informática y Consultoría del directorio de empresas “Quién es Quién” del Diario Expansión y la revista Actualidad Económica, hoy compartimos una segunda edición de este informe.

Destacamos de esta edición el reclamo de la Asociación Española de Consultoría (AEC) que señala que para que la consultoría se siga potenciando y continúe contribuyendo al desarrollo de las organizaciones, es necesaria una normativa adecuada que propicie la calidad de los servicios y la consolidación del empleo en las empresas de consultoría tecnológica.

Referencia: (aquí)

Los “5 por qué” para minimizar los “fallos técnicos”


En el mundo informático nos podemos encontrar con incidencias de todo tipo, pero las que mayor frustración pueden causar son las que se catalogan como “fallo técnico”.  Si al solicitar una explicación de la causa de un incidente recibimos como respuesta que se trata de un “problema técnico” o similar, pareciera que nos enfrentásemos a un “expediente X”, porque no hay explicación razonable, ninguna certeza que se solucionará y por consiguiente, no habrá garantías de que no volverá a ocurrir.

Inspirado en el sistema de producción Toyota, el autor de referencia, sugiere el uso de la técnica de los 5 por qué, para buscar la verdadera causa de los problemas que se originan en las organizaciones.  Se trata de indagar de manera consecutiva, al menos cinco veces, la ocurrencia de la causa de un problema, para llegar a la causa u origen real del mismo, el cual casi siempre deriva en una carencia en la gestión de los procesos de negocio. Por ejemplo:

Problema técnico inicial: En el nuevo producto hay una característica que no funciona

  1. ¿Por qué? Porque ha fallado un servidor
  2. ¿Por qué ha fallado el servidor? Porque un subsistema se utilizó de forma inadecuada.
  3. ¿Por qué se utilizó de forma inadecuada? Porque el ingeniero responsable no sabía utilizarlo.
  4. ¿Por qué no sabía utilizarlo? Porque nunca lo formaron
  5. ¿Por qué nunca lo formaron? Porque su director no consideraba necesario enseñar a los nuevos ingenieros y porque él y todo el equipo estaban “demasiado ocupados”.

Referencia: El Método Lean Startup (Eric Ries)

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:

  • 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


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

¿Tanto comprobar importes para que luego todo se “cocine”?


Este es la pregunta que nos formulamos después de saber que más del 60% de directivos cree que las empresas ajustan los números de sus cuentas según su conveniencia, lo que vulgarmente conocemos como “cocinar”.  Esta conclusión se basa en una encuesta realizada por Ernst & Young a directivos de 100 compañías de Europa, Oriente Medio, India y África.

Mapa del fraude en los negocios (Fuente, Diario el Economista del 7 de mayo 2013)

¿Dónde quedan las discusiones por los descuadres por diferencias de algunos céntimos o unidades monetarias que nunca falta cuando se comparan informes?, ¿Dónde queda la transparencia y responsabilidad social?… Bueno, siempre podremos decir que estamos dentro del 40% restante.

Fraude en los negocios (Fuente, Diario Expansión del 7 de mayo 2013)

Referencia: Diario Expansión y elEconomista

Preguntas para evaluar la “agilidad” de una empresa


Complementado la entrada anterior, las siguientes preguntas podrían ser útiles para identificar la situación actual de la capacidad de agilidad de reacción de una empresa, a partir de las respuestas que se obtengan, se podría elaborar un plan de acción para mejorar:

  • ¿Se ha planteado, al menos, tres escenarios posibles en cuanto al modo en que evolucionará el sector al que pertenece durante los próximos tres años? ¿Las opciones encontradas son buenas?
  • ¿Cómo podrían los competidores de la empresa alterar el mercado durante el próximo año? ¿Qué respuestas ha previsto para responder a estos eventuales cambios?
  • ¿Se cuenta con herramientas de análisis de información?  ¿Aprovechan al máximo estas herramientas? ¿La organización ha mejorado su capacidad de percibir los cambios que se producen? ¿La información necesaria es totalmente accesible?
  • ¿Qué está impidiendo que la organización sea más ágil? ¿Es posible superarlos? ¿De qué modo?
  • ¿Es posible trabajar de manera conjunta con competidores para impulsar cambios en el sector? ¿En qué áreas?
  • En los últimos años, ¿se ha recortado los costes fijos de la organización con el fin de mejorar la agilidad?
  • ¿Los recortes efectuados ha mermado la capacidad de agilidad de la organización? ¿De qué modo se está remediando esta situación?

Referencia: Revista Harvard Deusto (número 219)

El Triángulo de un Proyecto


Con la figura de triangulo se quiere hacer referencia al mensaje de equilibrio y armonía que debería existir en todo proyecto entre sus siguientes elementos clave: Alcance, coste, tiempo y calidad.  Donde el “Alcance” actúa como eje central, porque ante un mayor o menor alcance repercutirá en la misma dirección en los demás factores.

Controlar el Alcance y sus posibilidades de consecución pasan por hacer una adecuada planificación del tiempo, coste, calidad y de los recursos disponibles

Buscar el equilibrio deseado y gestionarlo es clave para el éxito de un proyecto.  Por ejemplo:

  • Construir algo a mucha velocidad, con muy poco dinero, redundará negativamente en la calidad.
  • Construir algo con altísima calidad podría repercutir en el incremento del tiempo  y en el coste.
  • Construir algo con más funcionalidades de las inicialmente definidas (mayor alcance), incrementará los y el tiempo del proyecto.

Otro factor que también se debería tener presente es la disponibilidad de recursos el cual también puede ser gravitante en el éxito de un proyecto.

Referencia: ISBN 978-84-415-3225-0

Preguntas clave para iniciar la gestión de un proyecto


En un “mundo ideal” y mientras sea posible, en la gestión de un proyecto, preferentemente al comenzar, nos deberíamos plantearnos las siguientes preguntas:

  • Formulación del problema: ¿Cuál es el problema?, ¿Por qué es un problema?
  • Misión del proyecto: ¿cuál es el propósito de este proyecto?
  • Objetivos del proyecto: ¿Cómo podríamos descomponer los objetivos en elementos específicos, mensurables y justificables?
  • Estrategia del proyecto: ¿Cómo pensamos resolver el problema? o ¿cómo pensamos aprovechar la oportunidad?
  • Requisitos: ¿Cuáles son los resultados detallados que produce el proyecto?
  • Criterios de éxito: ¿Qué debe suceder para que el patrocinador, cliente y público interesado declaren que este proyecto ha sido un éxito? o ¿Qué valor de negocio estamos obteniendo de este proyecto?
  • Alcance del proyecto: ¿Qué conseguirá el proyecto? o ¿Qué no conseguirá el proyecto?
  • Resultados: ¿Qué resultados tangibles estamos produciendo y demuestran que se esán los criterios de alcance?
  • Riesgos: ¿Qué eventualidades podrían afectar al éxito del proyecto?, ¿Cuál es su probabilidad?, ¿cuál sería el impacto?, ¿Cómo podríamos responder?
  • Suposiciones: ¿Qué no sabemos todavía y qué suposiciones debemos hacer para decidir que la planificación siga adelante?
  • Limitaciones: ¿Qué limitaciones se oponen a la realización de este proyecto?

Tener claras las respuestas de estos temas, nos ayudará a realizar una mejor gestión

Referencia: ISBN 978-84-415-3225-0

Planificar respuestas a los riesgos negativos de un proyecto


En la gestión de un proyecto, una vez que se han identificado los riesgos, clasificado y analizado, el siguiente paso debería ser planificar la respuesta que daremos a los riesgos que se van a controlar y gestionar.

Como señalábamos en una entrada anterior, los riesgos de alta probabilidad y alto impacto, no deberían ser ignorados, en general, ningún riesgo debería ser rechazado, especialmente los que hubiesen obtenido, como resultado del uso de la matriz “Probabilidad vs. Impacto”, el resultado “Planificar Respuesta” requieren una atención especial para proponer un plan de acción si estos se produjesen.

El planteamiento de una respuesta debería seguir alguna de las siguientes estrategias:

  • Mitigar la probabilidad o impacto del riesgo. Reducir la probabilidad o el impacto, o ambos se justifican siempre cuando las acciones que se emprendan para este fin sean rentables con relación al impacto del riesgo.
  • Planificar una contingencia. La alta probabilidad de un riesgo justifica el planteamiento de un plan de contingencia, esto también incluye la identificación de condiciones de su activación (descripción del momento).
  • Transferir el riesgo a otra parte. Trasladar el riesgo no lo elimina, lo externaliza (por ejemplo la contratación de seguros o suscripción de garantías)
  • Evitar el riesgo. El beneficio de una tarea no justifica el costo que puede significar el impacto de un riesgo si este ocurriese, si fuese así se podría eliminar la actividad o sustituirla por otra.
  • Aceptar el riesgo.  El costo de cualquier respuesta es superior al coste del impacto del riesgo, la alternativa para este caso es aceptar que el riesgo puede ocurrir y gestionarlo de la mejor manera si este se concretara.

Referencia: ISBN 978-84-415-3225-0

La consultoría informática necesita su libro de historia


Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que  si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro.  Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:

  • Problemas o diferencias políticas.
  • Incremento desproporcionado de los costes de los proyectos.
  • No se logran cubrir los objetivos esperados, insatisfacción de los usuarios.
  • Considerable incumplimiento de los plazos de entrega (“dijeron que podían hacerlo en siete semanas. Les dimos siete meses, y tenemos cero…”).
  • Presentación de un “demo” amañado en la preventa
  • Asignar consultores sin experiencia al proyecto.
  • Errores informáticos que generan incorrectamente pagos millonarios (Diagnóstico de auditoría: “el sistema se puso en marcha antes de superar ciertos hitos de prueba”).

Conocer un poco más sobre estos casos serían verdaderas lecciones para clientes y consultores.  Por ejemplo, interesante resulta el argumento de defensa de Oracle ante una demanda: “… Cuando los problemas surgieron durante el transcurso del proyecto, se hizo evidente que el cliente no comprendió adecuadamente la tecnología, como tampoco sabía los pasos que debía seguir para completar el proyecto…”

Referencias: aquí y aquí