La trampa del % de dedicación

Creado el 22 marzo 2013 por luis

Una práctica habitual para cuantificar el esfuerzo de las personas que forman el equipo de un proyecto es utilizar porcentajes de dedicación temporal, es decir del tiempo laboral disponible, cuánto, en porcentaje, se dedica la persona en cuestión al proyecto. Particularmente se utiliza bastante en las propuestas para vender servicios de consultoría.

El uso de esta práctica es muy cómodo para apreciar la magnitud de ese esfuerzo pero tiene varios riesgos, por llamarlos de forma suave, que hay que conocer:

Utilizar medias de punto gordo: Los proyectos tienen fases donde la dedicación requerida puede variar mucho de una fase a otra. Un 40% de dedicación media en un proyecto puede ser el 100% en una parte determinada del proyecto y del 20% en otra. Conviene siempre romper la dedicación porcentual en tramos/fases donde haya una mínima variación. No hacerlo te puede llevar, siguiendo el ejemplo anterior, a que reserves el 40% de tu tiempo para un proyecto y luego te encuentres que requiere que te dediques el 100% en un momento dado. Vaya desastre, ¿no?

Utilizar medias de punto fino: ¿Qué sentido tiene estar al 5% en un proyecto? Aunque tu participación en el proyecto se limitara a asistir a una reunión de 1 hora a la semana, el tiempo de preparación de antes y de acciones de después ya te hace superar ese 5%… ¡ah! ¿que no te preparas las reuniones y luego no haces nada? Pues entonces puede ser. En mi opinión no se debería utilizar nunca una dedicación menor del 10% (medio día por semana). No es realista y lleva a aberraciones.

Superar el 100%: Esta es la bestia negra del consultor que está en más de un proyecto. En un proyecto está al 60% y en otro al 50%. A veces no es un error de planificación (por medias de punto gordo por ejemplo) ni de voluntarismo, sino de que un proyecto se retrasa y donde antes un valle compensaba a un pico, ahora te encuentras dos picos. Despeñamiento fijo.

No especificar cuándo es la dedicación: Si dividimos la semana en trocitos de 10% de dedicación (una mañana o una tarde), es evidente que no es lo mismo el viernes por la tarde que el martes por la mañana, o incluso una mañana (donde estarás más fresco) o una tarde (menos fresco pero que puedes alargar en caso de necesidad). Es un detalle pero puede ser importante en algún caso.

¿Qué otros riesgos creéis que hay que evitar?

* * *

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.

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

Sobredimensionamiento

Creado el 11 marzo 2013 por luis

Me encuentro a menudo en mis proyectos de selección de aplicaciones de gestión que el cliente pide «más de lo que necesita»: Por si acaso lo uso algún día, por si acaso alguien me lo pide, mejor tenerlo no vaya a ser que me haga falta, porque lo tiene mi competencia, porque lo he leído en un artículo de no sé qué revista de management, en el Master lo mencionaron, … es igual, el caso es que aunque no les haga falta realmente, lo quieren.

Y claro, eso no es gratis:

Obviamente se traduce en mayor esfuerzo y coste del proyecto de implantación (horas de servicios y licencias).
Posiblemente lleve a mayores requerimientos de infraestructura.
Complicará el uso de la aplicación previsiblemente: más puntos de menú, requerimientos de datos que luego no se usan, etc.
En algún caso lleva a ese monumento a la estupidez humana que es el Shelfware, ese software que no se usa, puesto en una estantería y metido en una caja acumulando polvo, y lo que es peor, por el que se pagó licencias y se paga mantenimiento.
Complica el mantenimiento de la aplicación.

Es por eso que últimamente intento que mis clientes adopten una visión Lean de sus requerimientos y que huyamos del Waste-Muda que supone implementar algo que no necesitas. No creáis que es fácil.

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

Integración entre plataformas SaaS

Creado el 15 febrero 2013 por luis

Es un escenario futuro previsible que a medio plazo sólo subsistan media docena de fabricantes SaaS de software empresarial (ERP,CRM, …).

Esta concentración de soluciones, aparte de convulsionar y redefinir de manera radical todo el ecosistema y el negocio de servicios de implantación de estas aplicaciones, abre nuevas oportunidades, algunas de las cuales ya las hemos comentado (aquí y aquí). Entre estas oportunidades está la de los servicios de integración entre las diversas plataformas que subsistan.

Sin embargo, actualmente, ya existen multitud de plataformas de integración verticales (Rosettanet, moda-ml, OTA, … ) y protocolos de intercambio de mensajes (el más conocido de los cuales es el EDI) para integración de procesos entre empresas.

Estas aplicaciones y tecnologías no son fáciles de implantar y muchas de las dificultades provienen de la heterogeneidad de sistemas a integrar (por la gran disparidad de procesos y formatos de información) y complicaciones técnicas asociadas a la conectividad y la seguridad.

En ese escenario de concentración de fabricantes descrito anteriormente, esas dificultades se reducen sensiblemente por dos razones, al menos:

Hay menos sistemas y por tanto formatos/procesos estándares a integrar.
Son sistemas más homogéneos cada uno de ellos, ya que el modo SaaS forzará a la estandarización de procesos y formatos de la información entre las empresas de cada producto.

Es de esperar pues que a medida que el modelo SaaS vaya consolidándose aparezcan nuevas oportunidades de negocio alrededor de los servicios de integración entre plataformas y que se pueda mitigar, en una parte al menos, la caída de actividad alrededor de los servicios tradicionales de implantación. ¿Opináis lo mismo?

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

Fricciones y proyectos

Creado el 8 febrero 2013 por luis

Project Manager en acción :)

Recuerdo de mis tiempos de estudiante en la Escuela de Ingeniería un problema de física donde se debía determinar la velocidad máxima que podía alcanzar un cuerpo en caida libre en la atmósfera terrestre. La gracia del planteamiento del problema era entender como la fuerza de rozamiento podía llegar a compensar a la fuerza de la gravedad y el concepto de coeficiente de rozamiento. Y lo que me llamó la atención era el hecho de que se alcanzaba una velocidad máxima.

En los proyectos que he conocido creo que pasa algo parecido con el avance. Llega un momento en el que la velocidad de avance del proyecto (se mida como se mida) llega a un máximo y por muchas acciones, técnicas o metodologías que como Project Manager apliques, hay un entorno que frena y que te hace llegar inexorablemente a esa velocidad de avance máxima.

¿Cómo romper, superar o desbloquear ese límite?

Lo primero es identificar el punto de saturación, porque es el momento en el que debes dejar de aplicar tus metodologías (sean las que sean) para incrementar la velocidad de avance del proyecto (no significa que las abandones, pues serán necesarias para que la velocidad se mantenga). Cualquier esfuerzo en ese sentido, traspasado ese punto de saturación o velocidad de avance máxima, será inútil o poco favorable en términos de coste/beneficio.

Nos queda después, identificar y actuar sobre otros elementos del entorno del proyecto, concretamente sobre lo equivalente al coeficiente de rozamiento – factores que frenan o friccionan. Y esto ya es más un arte que una ciencia pues nos metemos en terrenos de las organizaciones y relaciones humanas dentro de las empresas. Aquí cada cual tendrá sus habilidades.

¿Te atreves a poner ejemplos?

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

Visitas comerciales

Creado el 5 febrero 2013 por luis

¡Bien!, después de incontables e-mails, llamadas, whatsapps, linkedines, … consigues cerrar una visita con un posible cliente para presentarle tus servicios.

Llegas a sus oficinas, comienzas con el ritual de tarjetas, broma sobre el tiempo, fútbol, política mejor que no, tus especulaciones sobre quien acompaña a la reunión a la persona con quien has quedado, … le presentas tu ppt, le cuentas las excelencias de tus servicios, tu compromiso, tu experiencia, tu equipo, puede que hasta alguna batallita de algún proyecto, … todo lo que sea necesario para captar su atención y encenderle la lucecita que le haga pensar que le puedes ayudar de manera solvente.

La otra parte, el potencial cliente, te escucha, nunca sabes si por educación, por su compromiso con un conocido común (o ¡eureka!, porque le interesa lo que dices), asiente, cruza los brazos, los descruza (tú siempre atento al lenguaje no verbal), te explica (o no) iniciativas que tiene en marcha o en perspectiva y a las que, en tiempo real, tienes que encontrar la manera de poder aportar algo (lo imaginativo o voluntarioso que es cada uno ya depende de tu ansiedad por vender y ética profesional).

Acabas la reunión con la despedida formal y promesas vagas de que pensarán en ti cuando «surja una oportunidad» (odio esta frase), de darle una vuelta a alguna idea que hayas podido improvisar, y sólo en algunos casos, con el acuerdo de enviarle un documento con una propuesta preliminar de colaboración en algún tema concreto – el principal objetivo en ese momento.

Te vas pensando en que los próximos días tendrás que hacer el seguimiento, más llamadas, e-mails, documentos arriba y abajo, tocando a conocidos comunes…

De verdad, ¿no hay una mejor manera de vender en consultoría?

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

SaaS como plataforma de datos compartidos

Creado el 30 enero 2013 por luis

El mercado de las aplicaciones de gestión empresarial es un mercado dinámico pero también bastante maduro, lo que implica que está relativamente saturado, al menos si te limitas a hacer lo que hace todo el mundo (si funciona para otros, también funcionará para mi, es la lógica).

Es por esto por lo que llevo últimamente dándole vueltas a diversas ideas, u ocurrencias, intentando identificar oportunidades de mejora, y de negocio digámoslo todo, que permitan salir de ese océano rojo en el que se ha convertido este ecosistema tan peculiar constituido por las aplicaciones de gestión empresarial.

Una de las líneas de exploración que estoy siguiendo es la conducida por el paradigma SaaS/Cloud, (alguna idea ya se ha compartido por aquí) y he llegado a la siguiente reflexión que quería compartir y debatir con los hipotéticos lectores de este blog.

En una instalación de un vendor SaaS consolidado conviven, en una misma plataforma tecnológica, los datos y transacciones de multitud de empresas, información, que una vez agregada y estructurada, podría tener un valor extraordinario para mejorar la toma de decisiones y la gestión de los procesos de esas mismas empresas.

Ejemplos que se me ocurren a bote pronto:

En entornos de RRHH:

Salarios medios por sector y nivel
Ratios de rotación de personal
Ratios de movilidad interna/promoción
Ratios organizativos (p.e. nº empleados de IT / nº de empleados totales)
Datos demográficos (edades medias, % femenino, …)

Workday o NorthGate Arinso serían los vendors de referencia (por lo de consolidados) en este ámbito.

En entornos de Finanzas:

Plazos medios de pago/cobro
Ratios de impagos y registro compartido de hábitos de pago de terceros – protección frente a morosidad (!)
Indicadores de stock (ratios de rotación, de obsolescencias, costes medios, …)
Volúmenes de facturación, vencimientos medios,…

Los referentes en este ámbito serían SAP Business ByDesign, FinancialForce y Netsuite

En entornos de ventas y comercial:

Duraciones medias de pipelines por sector
Ratios de efectividad actividad comercial oferta/venta, acciones/respuesta, …
Valor medio de ofertas

Salesforce sería aquí el referente

Cruzados:

Ratios como facturación per capita
Plantilla total o por departamentos por facturación

Las empresas que comparten aplicación SaaS, podrían beneficiarse de esta información para mejorar sus procesos, dimensionarse adecuadamente, negociar mejor con terceros (bancos por ejemplo 🙂 ), prevenir riesgos (morosidad), identificar oportunidades en otros sectores, …

A cambio, es verdad, deberán ceder sus preciosos datos a un tercero (el vendor SaaS) para que este los consolide, procese, anonimice, … y no se me escapa que algunas empresas, celosas de sus presuntas excelencias, no quieran entrar pero creo que si el proveedor SaaS es solvente (y deberia serlo porque si no deberían ser su cliente) debería poder darles la confianza y garantías suficientes – no olvidemos que ya está gestionando sus datos .

¿Qué pensáis?, ¿utópico?, ¿inviable?, ¿fantástico?, ¿en línea con tendencias como la coopetición y colaboración proactiva entre empresas?, …

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

SaaS como habilitador de plataformas B2B

Creado el 22 enero 2013 por luis

A finales de los 90, en plena burbuja tecnológica, uno de los temas de moda eran los portales B2B, marketplaces sobre plataformas tecnológicas para canalizar los flujos de información de las transacciones entre empresas.

Recuerdo bien, por haber participado en su día en el lanzamiento de varios de ellos, los precios astronómicos que se pedían por las plataformas tecnológicas existentes por aquel entonces (Commerce One, Ariba, ATG, i2, …), la mayoría de las cuales sólo han sobrevivido porque fueron absorbidas por grandes del software empresarial, Ariba por SAP, ATG por Oracle, i2 por JDA.

Uno de los argumentos que esgrimían los proveedores para defender esos altos precios era la complejidad de integración de la información por la heterogeneidad de entornos tecnológicos y de procesos operativos de las diferentes empresas que transaccionaban en el portal B2B.

Aparte de efectos burbuja que inflaban los precios, era muy cierto, y lo veías en el momento de implantarlos, que esas razones basadas en la complejidad de integración eran reales, principalmente por las diferencias del formato de la información que usaba cada empresa , lo que obligaban a usar formatos intermedios como lingua franca y a utilizar sofisticados sistemas de sincronización y distribución de mensajería… ¿alguien se acuerda de las herramientas EAI?

La mayoría de iniciativas de esa época fracasaron, al menos en sus pretensiones iniciales sustentadas en Business Plans descabellados, arrastradas en su mayor parte por la explosión de la burbuja tecnológica del 2000 y en parte también porque no dio tiempo a que la tecnología (y disposición de las empresas en adoptar ese modelo nuevo) madurase lo suficiente.

Esta situación puede haber cambiado drásticamente y la idea de Marketplaces B2B tener una segunda oportunidad con la eclosión del modelo SaaS en las aplicaciones de gestión, porque en un ecosistema SaaS, más empresas comparten el mismo sistema, o mejor dicho, la misma base tecnológica. Lo que facilita evidentemente que se tenga el mismo formato de información y el intercambio intercompañía.

Adicionalmente, [1] el hecho de que además los datos de todos estén detrás del mismo firewall (gestionados por el mismo proveedor) facilita el intercambio de información desde un punto de vista de seguridad y sincronización, y [2] los procesos de las empresas que comparten el ecosistema SaaS tenderán a parecerse bastante (de manera forzada por usar todas la misma aplicación) lo que hará que la integración entre procesos intercompañía sea más natural.

Y, esto es lo que me interesa destacar, se abre una muy interesante oportunidad de negocio para proveedores de plataformas SaaS, que podrían ser, no sólo los proveedores del sistema de gestión, sino también plataformas de transacción entre sus clientes o puertas de integración con los clientes/proveedores de sus empresas cliente, aprovechando las avanzadas herramientas/capacidades de integración inherentes a su negocio y tecnologías.

Ejemplos que se me ocurren, así a bote pronto, para apreciar las enormes oportunidades de mejora global que se habilitarían:

al emitirse un pedido de compra en la empresa cliente se crea el pedido de venta en la empresa proveedora en la misma transacción.
una empresa pendiente de un pago podría tener visibilidad de las previsiones de pago de su cliente.
al crearse la orden de salida de un almacén en la empresa proveedora, se crea en el sistema de la empresa cliente la previsión de entrega, lo que le permitirá planificar mejor toda su gestión (ubicaciones, órdenes de fabricación ligadas, etc.)

No se me escapa que para que esta oportunidad de negocio se materialice hace falta alcanzar una masa crítica y concentración de empresas alrededor de la plataforma SaaS (o un número reducido de ellas pero interoperables entre sí), pero soy optimista viendo los progresos de empresas como SAP con su Business ByDesign, Workday, Netsuite, FinancialForce (joint venture de Unit4 con Salesforce) por citar las primeras que se me vienen a la memoria.

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

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.

Imagen de r.p.i

Multitenancy, ese difuso concepto

Creado el 20 diciembre 2012 por luis

Según la definición que más me gusta del concepto Multitenancy, una aplicación de gestión SaaS además es Multitenancy si cumple simultáneamente:

Puede ser compartida por diferentes clientes.
Es capaz de adaptarse y evolucionar con los diferentes requerimientos de cada cliente.
Y al mismo tiempo ser viable, técnica y económicamente, para el proveedor.

Multitenancy, al mismo tiempo que piedra angular que sostiene todo modelo viable de delivery SaaS de una aplicación de gestión, es un concepto que habitualmente se maneja con poco rigor y que puede ser confuso, porque, en mi opinión, no es un término absoluto sino relativo: una aplicación SaaS no es que, SI o NO, sea Multitenancy, sino que lo es más o menos en relación a otras con las que se compare.

Y ello es así por varias razones:

Adaptarse a diferentes requerimientos, manteniendo compatibilidades, tiene siempre un límite para una determinada aplicación. Entre dos aplicaciones SaaS, cuanto más lejos esté ese límite en una aplicación con respecto a otra, más Multitenancy es la primera. Soy consciente de que ese más lejos, en esta afirmación hay que definirlo bien en cada caso o comparación.

La viabilidad (capacidad de que sea rentable económicamente) para el proveedor vendrá dada, no sólo por la tecnología que use, sino también por lo buenos que sean sus procesos internos. Un proveedor SaaS podrá permitirse tener una tecnología menos preparada para el Multitenancy si es muy eficiente en sus metodologías y procesos de desarrollo, servicio al cliente, despliegue de versiones, etc.

Influye mucho las dispersión de funcionalidades requeridas por sus clientes. Cuanto más homogéneas y comunes, más fácil de compartir que será la aplicación. Es decir, en un entorno homogéneo las exigencias Multitenancy serán menores. Por eso las aplicaciones SaaS que quieran ser muy Multitenancy (siempre en términos relativos) deberán tender a verticalizarse, es decir a especializarse por funciones o sectores.

En conclusión, cuando evalúes una aplicación SaaS, la pregunta correcta no es si es o no Multitenancy, sino en qué grado lo es en relación al conjunto de aplicaciones evaluadas.

Archivos de: luis

La trampa del % de dedicación

Sobredimensionamiento

Fricciones y proyectos

Visitas comerciales

Multitenancy, ese difuso concepto

Uso de cookies