El extraño caso del PM por minutos

Gantt comprimido

El amigo de un amigo me ha explicado un divertido caso (o no, según se mire) y que comparto a continuación.

Resulta que un proyecto de implantación de un ERP que tiene que arrancar, sí o sí, a principios del año que viene, ve retrasado su inicio por causas diversas, por lo que una planificación que inicialmente eran unos razonables ocho meses se tiene que comprimir a menos de cinco.

Para ello se ha realizado ajustes: a la baja en el alcance (menos países, algún proceso se deja para más adelante, etc.) y al alza en la intensidad del proyecto (más dedicación del equipo en menos tiempo). Bueno, no de todo el equipo, porque resulta que el cliente quiere recortar proporcionalmente la dedicación del Project Manager, con lo que que ésta queda en un día por semana.

Y es un error, un grave error, por varios motivos:

  • Con una dedicación de menos de un día por semana, mientras llegas y te explican lo que ha pasado durante la semana, sólo te queda tiempo para despedirte hasta la semana que viene, por lo que al final el PM se convierte en un lastre. Pierde totalmente su sentido.
  • En un proyecto con tanta intensidad, la velocidad tan alta a la que pasan las cosas (y cosas en estos proyectos pasan, creedme) requiere respuestas muy rápidas, sin capas intermedias, entre lo que pasa y el PM.
  • El PM pasa gradualmente a intervenir reactivamente, más como apagafuegos, que gestionando el proyecto. El proyecto siempre irá por delante.
  • Desde el punto de vista del PM es también muy ineficiente porque acaba fragmentando su dedicación durante la semana – por goteo y si está en más proyectos acaba en una multitarea excesiva.

Por eso le he dicho a mi amigo que a su vez le transmita a su amigo de que debe convencer a su cliente de que, en realidad, cuando aumenta la intensidad de un proyecto, aunque se acorte su calendario, lo que se requiere es aún más dedicación del PM.

El Process Mining NO es utilizar BI para analizar procesos.

Process Mining NO es BI para procesos

Una pregunta recurrente cuando explicamos qué es Process Mining a nuestros clientes es: ¿Pero eso que me estás explicando no es un BI o un Data Mining para procesos?

Y hay que reconocer que, depende cómo lo expliques, se puede confundir. Pues para deshacer esa confusión vamos a intentar explicar algunas diferencias entre usar Process Mining y BI/Data Mining para analizar procesos:

  • El análisis de procesos con una herramienta BI parte de fotos estáticas, sin la historia del proceso. El análisis con Process Mining se realiza con la historia (traza) de cada instancia del proceso. Lo que hace más fácil determinar los casos problemáticos y el origen del problema (root analysis).
  • Data Mining busca y analiza patrones de datos, Process Mining patrones de procesos.
  • Process Mining es cómodo para analizar excepciones, Data Mining requiere identificar, y en su caso excluir, los outliers porque distorsionan su análisis.
  • Una herramienta BI requiere definir y preconfigurar un modelo de datos (dimensiones, ejes, segmentos, etc.). La herramienta de Process Mining trabaja con el log, con una estructura base mínima (id de instancia, id de evento y time stamp) sin prejuzgar el modelo de datos.
  • Y por último, una diferencia muy importante a la hora de decidirse a empezar un proyecto: el despliegue de una herramienta de Process Mining en general es más rápido porque requiere infraestructuras y capacidades técnicas más ligeras, además de un análisis preliminar de los datos menos exigente para empezar a obtener resultados.

¿Qué opináis? ¿Me dejo o estáis en desacuerdo con algo?

Si te interesa la práctica de Process Mining puedes encontrar más info en Process Mining Profesional.

Netsuite. Crónica desde el SuiteWorld 2017.

Ben Kepes, reconocido analista de tecnología, hace una excelente crónica de las novedades anunciadas por Netsuite en la SuiteWorld 2017, su reunión anual para usuarios.

Muy resumidamente:

  • La adquisición por Oracle ha proporcionado un gran impulso a la expansión de Netsuite: se doblan los data centers, se pasa de presencia con oficina en 10 países a 23 y se aprovechan de la red mundial de centros de desarrollo de Oracle.
  • Se anuncia SuiteSuccess, verticalizaciones del producto con las mejores prácticas sectoriales, por ahora para Advertising, media, publishing,  Financial technology, Manufacturing, Nonprofit, Retail, Service-based businesses, Software/internet y Wholesale distribution.
  • Se lanza SuitePeople, solución de gestión de RRHH (con nómina sólo para EEUU).
  • No se va a competir con las soluciones de Oracle. Tienen targets diferentes.

En Nodotic llevamos siguiendo a Netsuite desde el 2009 y ahora que hemos empezando a participar en dos implantaciones  ya avanzo que tenemos buenas sensaciones.

Teoría de las restricciones. La manera de gestionar sistemas complejos.

Este video de Vector Consulting Group me ha parecido muy interesante por la manera tan didáctica de mostrar que un sistema con un mínimo de complejidad no puede gestionarse con el enfoque lineal y simplista de la cuenta de resultados.

Hay más videos, tan interesantes o más, en su página de YouTube.

Por cierto, la traducción de constraint por restricción no me acaba de gustar. ¿Conocéis alguna mejor?

¿Hemos de hacerle caso a Gartner y similares?

Gartner MQ for Dummies

Acabo de leer en LinkedIn este artículo de Kevin Hunt, Senior Account Executive de  MicroStrategy, sobre el último MQ de Gartner de plataformas BI y que ya comentamos en su día en este blog.

El señor Hunt es muy duro en su artículo y subraya, entre otras cosas, el conflicto de intereses que supone que el evaluador cobre de los evaluados. No se queda ahí, sino que se pregunta sobre el verdadero valor que aportan los informes de Gartner y otros (Forrester, BARC, …) y las consecuencias de no salir en el cuadrante.

También se pregunta el porqué se les hace caso y afirma que el verdadero poder de Gartner es lo que se llama el “social proof”, el mecanismo psicológico por el cual, subconscientemente, los individuos nos sentimos mejor opinando como los demás.

Lo llega a comparar, y esto me hace particularmente gracia, con las risas enlatadas que hay en algunos programas de televisión.

El artículo se puede leer directamente el LinkedIn o en una copia que podéis encontrar aquí.

 

Esta es una polémica recurrente. Cada vez que Gartner saca un MQ alguien se queja o le quita importancia. En nuestro caso siempre lo usamos con mucha precaución y normalmente porque el cliente lo menciona en algún momento.

Reconozco que puede ser útil para tener una primera impresión sobre who-is-who en un determinado mercado pero con muchas limitaciones, sobre todo si lo intentas utilizar en entornos de mediana empresa o locales – se puede dar el caso de que un producto que es líder indiscutible en su país no salga en el MQ, por eso, por local – ¿Lo vas a descartar entonces?.

Otra queja frecuente es su dificultad de interpretación directa. No se pueden sacar conclusiones automáticas por el cuadrante donte hayan metido a un producto y creo que es más útil y significativo ver cómo se ha evolucionado un producto, él mismo por los cuadrantes y en relacion a sus competidores. En nuestra entrada sobre el MQ de plataformas BI ya pusimos un gráfico que ilustra muy bien esto que digo:

 

Y para acabar, si os interesa seguir profundizando en el tema os recomiendo este artículo donde explican como leerlo y este, del propio Gartner, donde dan pistas para no equivocarse al interpretarlo.

***

Si este contenido te ha parecido interesante y no quieres perderte otros similares o mejores, te invito a suscribirte a nuestra lista de correos en el icono de la derecha o directamente desde aquí

Tecnología óptima

A veces utilizar la última tecnología no es una buena opción para conseguir el mejor resultado. Según este artículo en Wired, la mejor manera de transferir a la nube de Amazon los 100 petabytes de información que la empresa DigitalGlobe había recopilado en imágenes de satélite en sus servidores, era llevándola en un camión, no por fibra.

Y no debe ser un caso aislado porque Amazon lo ofrece como un servicio más. Aquí podéis ver un vídeo explicativo:

Me recuerda aquella vieja historia de la paloma mensajera que era más rápida que el ADSL en Sudáfrica o en el Reino Unido.

Curioso, ¿no?

 

SAP sigue apretando con el licenciamiento

Contábamos no hace mucho el caso del litigio que SAP le había ganado a Diageo en el Reino Unido. No es tema menor, de entrada por el coste que para Diageo le podría suponer (del orden de 70 millones de USD) pero sobre todo por el precedente (o jurisprudencia mejor dicho) que se podía establecer.

Pues efectivamente, según cio.com esta vez le ha tocado a la cervecera Anheuser-Busch Inbev (los que hacen la Budwiser), a la que SAP reclama…600 millones de USD. Y no está claro que sea únicamente por la misma razón que Diageo, que los usuarios que acceden a los datos en SAP utilizando aplicaciones construidas sobre Salesforce.com tienen que pasar por caja como si accedieran directamente desde SAP.

Es difícil valorar el impacto que puede tener en el negocio de SAP esta política de demandar a sus clientes dado el grado de cautividad de estos. Pero está claro que las decisiones de inversión en nuevos ERPs van a  tener más elementos a considerar a la hora de decantarse por SAP. Veremos.

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies