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.

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.

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.

Ojo a esta sentencia sobre quién debe pagar licencias de SAP

Según ha establecido un juez en UK en una sentencia citada por PCWorld, el coloso de la industria de bebidas Diageo deberá pagar licencias a SAP por cualquier usuario o aplicación que acceda a los datos que residen en la base de datos del ERP, independientemente de cómo acceda. Es decir que todas aquellas empresas que han desarrollado aplicaciones que se integran con SAP tendrían que pagar a SAP.

El conflicto viene de que Diageo había desarrollado sobre su plataforma de Salesforce.com una conexión a SAP para que sus clientes puedan hacer pedidos y su fuerza de ventas pueda seguir esos pedidos. Esta conexión entre salesforce.com y SAP la ha hecho Diageo con SAP Exchange Infrastructure (SAP PI), la plataforma de integración de SAP, y lo que se discute es si la licencia genérica de uso de SAP PI cubre ese uso. SAP cree que no y que los clientes de Diageo deberían pagar como usuarios nominales por lo que reclama 67.8 millones de dólares, nada menos.

En The Register también se hacen eco de la sentencia y analizan los argumentos del juez.

Habrá que estar atento a como evoluciona el tema.

Estudio de SoftDoit sobre el estado del software en España

Según  la 5ª Edición del Estudio: Estado actual y futuro del software en España 2017 realizado por SoftDoIT en colaboración con la Asociación de Técnicos de Informática, más del 30 % de las empresas encuestadas en dicho estudio planea hacer un cambio en su sistema ERP. Un 19,2% cambiará para pasarse a la nube, un 4,8% para implantar una solución más económica, y un 17,8% se muestra dispuesto a contratar una solución que no tiene.

Otro dato interesante de ese estudio es que algo más del 70% de las empresas encuestadas creen que van a crecer en 2017.

Por el perfil de las empresas encuestadas que se ve en la infografía resumen [PDF] se puede deducir que la mayoría son PyMES.

¿Qué os parece? ¿Coincide con vuestra percepción del mercado?

De medir proyectos (I)

Principio de Indeterminación de HeisenbergEs la ecuación que enuncia matemáticamente y de forma elegantísima por sencilla (al menos para mí) el Principio de Incertidumbre de Heisenberg.

En lenguaje llano viene a decir que no es posible medir de forma exacta y a la vez la velocidad (1) a la que se mueve un objeto y su posición – que siempre hay un margen de imprecisión en la medida de alguna o ambas de las magnitudes, y que el producto de esas imprecisiones es una constante, concretamente la de Planck dividida por dos.

Este principio básico de la física cuántica es frecuentemente interpretado en el sentido de que cualquier cualquier acción de medir altera de alguna forma al objeto medido y falsea, por tanto y aquí está el quid de la cuestión, el resultado de la propia medida. Es curioso porque a una conclusión similar se llega en otros ámbitos tan distintos (o no) de la física cuántica como la psicología del trabajo o sociología donde se habla del Efecto Hawthorne (los sujetos que saben que siendo sometidos a un experimento modifican los comportamientos que están siendo experimentalmente medidos)

Aterrizando dentro del ámbito de la temática de este blog, ¡cuántas veces nos empeñamos en medir proyectos y equipos… y sólo por este hecho de medir, aparentemente inocuo, estamos condicionando el desarrollo de lo que estamos midiendo!

No creo que nadie discuta la necesidad de medir de alguna forma cómo van los proyectos. La cuestión está en hacerlo de forma que no haga entrar en dinámicas dañinas a las personas protagonistas del proyecto ni a distorsionarlo. Y esta es una de las reflexiones recurrentes y retos con las que me tengo que enfrentar proyecto a proyecto.

Es muy conocido y cuestionado, por ejemplo, el modo de medir el avance de un proyecto por el tiempo que se invierte (o gasta, no sé qué término es mejor) en él. Este método de medir el avance por horas invertidas/gastadas provoca que las personas de los equipos no se vean motivadas por la calidad o eficiencia de lo que hacen – no son factores que se midan al fin y al cabo – y que los proyectos se alarguen y alarguen para alborozo de la consultora cárnico-industrial de turno y desesperación del pagano cliente.

Otra situación perniciosa tiene que ver con las reuniones de seguimiento e informes de progreso, donde a veces (me resisto a decir frecuentemente) se pierde de vista el objetivo del proyecto y el informe de marras se convierte en un objeto en sí mismo… el esfuerzo del equipo, el tempo y las tareas del proyecto se centran en la redacción del consabido informe – que para acabar de arreglarlo se plasma en uno de esos powerpoints infumables con fuentes a tamaño 10.

¿Cabe algo más perverso que el que el objeto de un proyecto sea la propia medición del mismo?

¿Y qué decir cuando el coste de medir es desproporcionado, del mismo orden de magnitud y comparable al coste del objeto medido, verbigracia el proyecto?.

Cuando analizo para mis clientes el coste de sus proyectos a donde primero apunto es a lo que se denomina eufemísticamente, la capa de gestión o de calidad que suele poner el proveedor. No digo que no haga falta pero hay que escrutar con detenimiento y siempre cuantas de las funciones de esas capas son sólo meramente administrativas, es decir para contar horas en un excel y dibujar bonitos (?) diagramas de Gantt.

En alguno de mis proyectos de selección de aplicaciones de gestión, medio en broma, le he llegado a proponer a mi cliente que dominar el Microsoft Project sea directamente un criterio de exclusión/veto (o al menos penalizador) de la persona propuesta como jefe de proyecto por los proveedores ofertantes (hay que aclarar que en las ofertas siempre exigimos que adjunten los CVs del equipo que proponen para hacer el proyecto).

Y a todo esto, alguno de mis hipotéticos lectores se dirá: vale, cierto, es verdad… este tipo saca todo esto a relucir y no aporta nada para cambiarlo o mejorarlo. Pues sí, tendría toda la razón (al menos eso es lo que yo pensaría). El problema es que esta entrada ya me está saliendo demasiado larga. Mejor lo dejo para un post posterior.

Por supuesto tus comentarios son más que bienvenidos.

 
(1) En realidad no es la velocidad sino la cantidad de movimiento o lo que es lo mismo, el producto de la masa por la velocidad del objeto en cuestión. Para simplificar se suele obviar el concepto masa para no tener que meternos en berenjenales de definir masa y considerar equivalencias con energía, etc. A efectos de esta entrada esta simplificación no tiene relevancia.
 
 (2): Esta entrada es una actualización de una publicada anteriormente.

La plataforma Cloud de SAP

SAP no es una organización que se caracterice precisamente por la claridad de su portafolio de servicios. Tiene tantos productos, y les cambia tan frecuentemente el nombre, que realmente es complicado explicar qué productos vende SAP. Por eso es de agradecer artículos como este de Dion Hinchcliffe de los Enterprise Irregulars que ayuda a entender la galaxia SAP, en este caso de su portafolio cloud.

Hinchcliffe, además de escribir estupendos artículos sobre tecnología en el mundo empresarial, suele hacer unos gráficos muy ilustrativos. Os recomiendo que lo sigáis.

ERP Value Matrix 2016 from Nucleus Research

Interesante la matriz resultante del último benchmarking de Nucleus Research de ERPs.
He acabado recientemente un proyecto de selección de ERP para un cliente donde hemos evaluado, entre otros, a SAP ERP, MS Dynamics AX, JD Edwards entre otros, y coincido donde los coloca el gráfico.
Más info en: http://nucleusresearch.com/research/single/erp-technology-value-matrix-2016/

Nada automático

 

tiempos modernos

 

No quiero nada automático, que el sistema proporcione toda la información disponible. El usuario ya decidirá qué hace y que el sistema lo registre para su trazabilidad, en todo caso. No quiero otra cosa, ya somos todos mayorcitos

 

Esta afirmación de un cliente, enunciada en una reunión de toma de requerimientos para un nuevo sistema de información de gestión empresarial, me ha hecho despertar una reflexión que tenía larvada desde hace tiempo:

¿Qué es preferible, que el sistema de información guíe al usuario de forma automática o que el propio usuario decida que hace con toda la información?

¿Workflow automático que dirige al usuario por el proceso de negocio o un usuario que decide en todo momento por donde fluye el proceso?

 

Piénsatelo bien antes de responder porque la pregunta/respuesta tiene una profunda carga conceptual, por no decir ideológica:

  • Sistema vs Persona
  • Empoderamiento de los individuos
  • Confianza
  • Formación
  • Cortoplacismo
  • Visión de(l) equipo

Y con todas las matizaciones que se te ocurran:

  • Procesos con intervención humana
  • Habrá procesos donde sea más viable o tenga más sentido que en otros
  • Capacitación de la persona
  • Situación de la organización

***

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Y por supuesto que estaré encantado de conocer tu opinión (en los comentarios mejor, así lo compartimos entre todos).
Y si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

 

Ecosistema ERP

Ecosistema ERP

A los que estamos de alguna u otra manera envueltos en el mundo de los sistemas de información de gestión empresarial nos es conveniente conocer el ecosistema en el que hay que moverse.

En esta entrada empezaremos explorando el primer nivel de ese ecosistema, el que está formado por el Cliente, el Fabricante del Software y el Implantador. Y si el tema interesa podremos seguir en entradas posteriores por segundos niveles, por ejemplo los distintos agentes y/o elementos que están dentro de los clientes.

Es en esta primera capa o nivel donde se juega la partida principal, donde cada jugador,  según sus intereses particulares, va a mover sus fichas:

El cliente

  • Reducir inversión/gasto
  • Cubrir requerimientos ¡y no sólo funcionales!
  • Evitar impacto organizativo
  • ROI, ROI, ROI, … ∞

 El fabricante del software

  • Vender licencias y mantenimientos
  • Minimizar descuentos
  • Vender certificaciones y formación
  • Mejorar el producto
  • Licencias, licencias, … ∞

El implantador

  • Vender horas y … ¡no hacer más de las vendidas!
  • Recurrencias … quedarse en el cliente
  • Reaprovechar desarrollos
  • Margen, margen, margen, … ∞

 

Estos intereses son los que van a provocar que se desarrollen estas dinámicas:

 

El cliente

 El cliente

 

 

 El fabricante del software

 El fabricante

 

El implantador

El implantador

 

Conocer y entender estas dinámicas es el paso previo a ser capaz de gestionarlas, estés en rol que estés o en medio de todos como es mi caso. Conocer los objetivos que mueven a tus compañeros de partida te permitirá hacer mejores movimientos y en cualquier caso creo que siempre es bueno para todos conocer las reglas que rigen el juego.

Para acabar una observación. Este análisis tiene un enfoque racional y cartesiano, pero como en todo ecosistema donde participan personas, siempre hay que considerar los efectos de las relaciones humanas, las emociones y las dinámicas entre individuos, que al final pueden acabar siendo las más influyentes.

 

 

***

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Y por supuesto que estaré encantado de conocer tu opinión (en los comentarios mejor, así lo compartimos entre todos).
Y si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

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