Qué es el Shelfware y cuál es su origen
Cada tanto aparecen términos nuevos relacionados con el mundo de TI en el que nos movemos. En este caso me gustaría explicar qué es el shelfware y qué es lo que lo produce.
Si buscamos una traducción de shelfware llegaríamos a algo parecido a software en una estantería.
Cuando se hace referencia al shelfware estamos hablando de software que fue comprado pero que nunca llegó a implementarse, o que nunca logró un nivel de adopción dentro de la organización como para considerarse en producción.
El concepto no es nuevo. Desde que el software se vendía por caja que los fabricantes intentaban armar bundles de productos para vender más con descuentos por volumen. Las compras se hacían en cantidades, por productos que no se necesitaban y que nunca se llegaban a poner en marcha.
En criollo, el shelfware es software que se compró y no se usa.
Son pocos los casos donde se compra algo sabiendo que no se va a poner en marcha o que el nivel de adopción no será el buscado.
El shelfware es un costo que tiene varias aristas. La primera es la compra original del software y la segunda, el pago anual de su mantenimiento.
Este es el listado de las cosas que producen shelfware:
No elegir el socio tecnológico adecuado
Muchas veces, la evolución de la tecnología no es acompañada por la evolución del canal que la comercializa.
En los últimos 5 años pudimos observar tantos avances en el mundo de virtualización, cloud privada, cloud pública y multicloud que hace que a más de uno se le confundan los conceptos.
Pero si los conceptos se llegan a confundir, imaginen tener un proveedor que no evoluciona con la tecnología.
El partner o socio tecnológico tiene que evolucionar junto con los fabricantes. Adaptarse para poder ofrecer servicios que garanticen no solo la implementación, sino también la adopción tecnológica.
Si el partner no evoluciona, tampoco podrá hacer evolucionar tecnológicamente a sus clientes.
Incluir software en los contratos que no son necesarios
Muchas veces vemos que por alguna promoción se accede a comprar software que nos gustaría en algún momento probar, pero que al momento de la compra no tiene lugar en el roadmap tecnológico.
Si a la falta de un socio tecnológico a la altura de lo que necesitamos le sumamos la falta de un caso de uso concreto para la tecnología, estamos en una encrucijada.
Estamos invirtiendo dinero en algo que no necesitamos y no tenemos quién lo ponga en funcionamiento.
Ahora supongamos que tenemos un socio adecuado que lo puede implementar. Si no existe el interés real, probablemente nunca se ponga el compromiso del cliente de trabajar sobre dicha implementación.
Algunas veces los que compran también tienen parte de culpa en todo esto.
Incluir una solución compleja en un backlog de trabajo cargado
Querer hacer más de lo que se puede lograr también es parte del problema.
Uno tiene que reconocer las limitaciones propias y del equipo de trabajo para entender si existe capacidad ociosa suficiente como para encarar la implementación y adopción de una nueva tecnología.
Si en la planificación de trabajo del año, fuera de las actividades del día a día y del espacio para las no planificadas, queda algo de lugar, se puede contemplar sumar el trabajo de la puesta en marcha de una nueva tecnología.
En cambio, si es muy reducido el recurso tiempo que tenemos del equipo, no se debería incluir la compra de nueva tecnología hasta estar en condiciones de poder llevarla adelante.
Si existe la necesidad, la capacidad del equipo y tenemos el socio tecnológico adecuado, cada vez se hace más chico el espacio para el shelfware.
En un próximo post les voy a contar las 5 formas de prevenir o eliminar directamente el shelfware dentro de sus organizaciones.