La logística de último kilómetro de los proyectos digitales

Uno de los temas fundamentales en el comercio digital es la llamada logística de último kilómetro. Cuando una empresa ha dedicado miles (o millones) de euros en marketing, una web, un comercio electrónico y una estrategia logística de almacenes, son precisamente los últimos kilómetros que hay del punto de reparto al de entrega donde se negocia parte de la rentabilidad y de la experiencia del cliente. Yo he dejado de comprar en algunos comercios on-line por problemas de este tipo, o he cambiado de proveedor, o he evitado hacer compras en determinadas condiciones.

El caso es que este contexto no es especialmente diferente en otras muchas transacciones: un producto de serie puede fracasar por su última configuración o adaptación. Esto ocurre muchas veces con los proyectos de transformación digital: ideas, planes o herramientas de software pinchan en el hueco que hay entre la configuración o diseño y su adaptación a la administración receptora. Esto es lo que llamaremos errores de último kilómetro (y es que no en vano, la gestión de la implementación de proyectos digitales se denomina delivery). Aquí os cuento los más habituales siguiendo el símil del post.

Cuando lo pides por Ali express y cuando te llega: gestión de expectativas de un proyecto digital

Uno de los memes más usados en internet es el que muestra la diferencia entre una cosa estupenda y una chapuza bajo la leyenda: cuando lo pides por Alí express y cuando te llega. Esto indica un problema muy habitual del comercio electrónico: la diferencia entre las fotos de producto y el producto real. Esto no es en sí mismo un problema de logística: si la foto del producto no se corresponde a la realidad, no hay entrega que corrija eso.

Sin embargo, en los procesos de venta de proyectos y software digital hay una parte importante que es la gestión de expectativas del público. Más de una vez y más de dos he asistido a reuniones relacionadas con productos en las que el responsable comercial ha contestado de manera evasiva una pregunta sobre el producto. Luego cuando se pone a funcionar y lo que «se había entendido» no estaba genera no pocos problemas.

Hay una cuestión de gestión de expectativas que genera fricción enorme en un proyecto que acaba en muchas ocasiones en que una compra hecha bajo una premisa concreta queda anulada en el momento en el que su función básica no se cumple. Si hay ganas, dinero y apoyo institucional, se puede forzar la entrega de esa funcionalidad, pero esta no será fácil, ni rápida. También hay que decir que más de una vez he asistido a ventas en las que ha perdido quien honestamente ha dicho que una funcionalidad no se cubre o se hará de manera complicada. A veces a la administración le pasa como a Johnny Guitar y dice «miénteme y dime que me quieres«.

He pasado por aquí pero no había nadie: funcionalidades sin desarrollar

Otro meme clásico de Internet es cuando el repartidor deja una nota diciendo «pasé a X hora y no había nadie en casa«. En muchas ocasiones has estado toda la mañana, pero te encuentras la nota y un poco alucinas. En el caso de los proyectos digitales esto es similar a cuando se dejan funcionalidades sin cubrir porque no se implementan todas las medidas necesarias porque no se han pedido o no se han tratado.

Un proyecto digital requiere que el equipo del proyecto se plantee las preguntas que sabe que un cliente va a tener sí o sí pero que no se suelen manifestar hasta que hay cierto uso. Decir «es que eso no lo hemos hecho porque no se ha pedido» es prácticamente como dejar la nota de «no estabas en casa»

Cuando te retuercen el paquete para que entre en el buzón: hacer el proyecto inaplicable

El tercer meme de turno es cuando encuentras en el buzón el paquete que esperabas que puede ser un libro u otra cosa más delicada, retorcida en el buzón. Con suerte solo se te han doblado las páginas… si no, se te ha roto lo que sea que esperas. Este caso también lo he visto más de una vez: un paquete que está pensado para funcionar en determinado contexto y que tiene una implementación tan endemoniada que pierde todo el valor que puede aportar. Automatizaciones excesivas, controles paranoicos, o configuraciones manuales que rompen la lógica del producto son situaciones frecuentes.

En estos casos el problema está muy relacionado con la capacidad de una persona del equipo de cliente (de la administración) de retorcer el software hasta que sea como le parece mejor. Esto no es malo de por sí, pero si gastarte un dineral en un software y/o proyecto para que luego no se use como se debe entra en la línea de lo absurdo. Es cierto que el trabajo de un consultor es precisamente encontrar y proponer ese hueco de utilidad entre lo que necesita el cliente y el software y encontrar el punto no siempre es fácil o, directamente, posible.

Cuando el reparto está muy por detrás del horario previsto: demoras en la implementación

Otra cuestión muy habitual es que te llegue en el correo de confirmación: «reparto de 10 a 14 horas», te dejes la mañana libre y llegue, por ejemplo, a las 17 (nunca antes de las 13:55). Un tema frecuente en un proyecto de software, y más en las administraciones públicas, es la fecha de lanzamiento y sus posibles retrasos. Esto tiene implicaciones de imagen y utilidad (queda mal no sacar algo previsto y puede que no se pueda hacer algo necesario como matricular alumnos en un colegio), pero además económicas y jurídicas. Cuando se licita un proyecto por una cantidad de dinero para salir en un año, y tarda tres, o directamente, no acaba nunca, como pasó con Mastil en Madrid, es un problema en términos presupuestarios y de contratos.

Evidentemente, en un proyecto digital, como dicen los anglosajones, «sh*t happens» y puede haber imprevistos. El problema es cuando empezamos a asimilar que esos imprevistos son la norma (aunque no siempre sea así). Una correcta previsión de plazos en la implementación es fundamental para que esto no pase. Eso significa contar que terminar un proyecto no es solo acabar de construirlo, es testearlo (bien) formar al personal, documentarlo y ya, entonces, lanzarlo.

Cuando te lo dejan fuera de casa o sin poner: hágalo usted mismo

Un problema habitual es la cadena de bricolage en la que compras los electrodomésticos y, en ningún momento te dicen que te los instalan. Puedes volver a casa y encontrarte la nevera en mitad de la cocina, o la campana en el suelo. El problema no es que no lo hagan, que allá cada uno, es que no te lo dicen hasta que no preguntas «¿instaláis esto?». Si tienes suerte, o si haces la pregunta, te dicen que si, pero que tiene un gasto adicional.

Este es otro problema que se puede dar: la instalación está, pero está hasta cierto punto. Entonces el equipo de la administración tiene que documentarse, ocasionalmente formarse y ponerse a implementar un producto que requiere cierta especialización o, en su caso, pasar por caja. De nuevo, no es una práctica ilegítima, pero esa falta de claridad ha dado lugar a problemas importantes en productos digitales y, personalmente, dudo que en muchos casos adviertan de que la instalación cuesta cierta cantidad de dinero y que requiere algo de especialización. Ni todo el mundo sabe conectar extractores de humo, ni configurar gestores documentales de código abierto bien.

Cuando no te llegan las instrucciones: hágaselo usted mismo, y, además, a ciegas

Un corolario al punto anterior es el que se da cuando la implementación requiere un personal especializado. Sin querer faltar al respeto, el modelo de negocio de empresas como Red Hat o Alfresco se basa en gran medida en la necesidad de servicios de consultoría para gestionar la implementación del proyecto. Esto es legítimo y normal, más aún hablando de un software que es de calidad y que se distribuye con licencia gratuita. El problema está en cuando se hace mucho, mucho, mucho hincapié en que es gratis y poco, poco, poco hincapié en que hay que tener un conocimiento importante para implementarlo en cierto contexto de complejidad.

Igual que pasa si tienes un familiar manitas (que es una de mis maldiciones, o de mis familiares, según haya salido la ñapa en cuestión), tener un equipo de IT que conozca el mercado es importante. Ese equipo puede valorar si tiene competencias para ejecutar el proyecto o si hay que contar con consultoría externa. Si no se hace esta evaluación, el problema puede aparecer tarde y cuando ya se han dado varias ruedas de prensa diciendo «nos pasamos a software libre» dar otra diciendo «nos volvemos a privativo» no suele quedar bien (salvo para los del software privativo)

La maldición de lo gratis: cuando pierdes el derecho de gestión

Cuando amueblé mi primera casa me costó un tiempo desarrollar miedo a la palabra «reparto gratuito». No es que me guste pagar por el reparto, es que a la quinta vez que te dejaban las cosas mal, o fuera de horario, o temías por tu salud si decías al repartidor que ese mueble estaba mal puesto, sabes que el reparto gratis te hace perder los derechos como cliente. A fin de cuentas, cuando llamas a quejarte, te dicen «es que el reparto es gratis». No hay problema con que sea algo gratis, pero si eso supone un menoscabo de las condiciones de prestación del servicio, es una elección que debe tener el cliente del proyecto.

En muchas ocasiones he podido observar que en el coste de instalación gratis y no incluir la formación del personal, se despacha un arranque de producto con tres videos de youtube y la documentación que ha hecho el último consultor junior que, posiblemente, aprobó comprensión lectora haciendo trampas. Si no se quiere pagar por la formación de la implementación es una opción legítima, pero esta decisión debe ser informada: contar en qué condiciones se prestará un servicio sin costes y las alternativas de pago, y se elige la parte que corresponda a cada caso.

Las condiciones laborales: cuando el criterio no es el ahorro

Un último punto a tener en cuenta es que el reparto es un trabajo con unas condiciones laborales que no son especialmente buenas. Horarios ajustados, rutas calculadas al milímetro, precariedad, etc. En el caso de la consultoría de proyectos de software las condiciones no son económicamente tan dramáticas, pero las exigencias son realmente complicadas. Personalmente, mi etapa como consultor en el sector fue de las peores profesionalmente (y he trabajado casi gratis en la universidad española sin cotización)… y mi caso no era de los peores. La cuestión es que en muchos casos estos problemas son fruto de un mercado en el que determinados hábitos consolidan una dinámica en la que el beneficio no viene del aumento de valor, sino del ahorro de costes de implementación.

El problema ya no es tanto que la industria funcione como funciona, que lo es, sino que la Administración en su política de compra pública lo incentiva de manera importante. El predominio de criterios objetivos de adjudicación como el coste-hora de la mano de obra o la duración estimada del proyecto son, precisamente, el caldo de cultivo para todo este tipo de problemas. Si, además, todos estos criterios «a granel» se juntan con una compra de tecnología sin entender en profundidad el entorno tecnológico y organizativo en el que se trabaja, el riesgo de fallar en estas cuestiones es alto.