Evitar dependencias excesivas del proveedor de software: qué acordar

La dependencia de un proveedor de software no se nota mientras la relación funciona. Se descubre el día en que hay que cambiar algo, el proveedor o la cuota o la persona que seguía el proyecto, y nadie en la empresa sabe decir dónde están los datos, a nombre de quién están registrados los servicios y qué hace falta para hacerlos funcionar en otro sitio. No es una cuestión de confianza: es una cuestión de inventario, y se hace hoy, con un proveedor en el que confiáis.

El objetivo no es poder cambiar de proveedor mañana. Es que quedarse sea una elección y no el único camino posible.

El inventario: qué existe, y a nombre de quién

El primer ejercicio es una lista. Se hace una vez, se actualiza cuando cambia algo, y sirve para descubrir los puntos en los que la empresa no es titular de lo que usa cada día.

Los datos: exportarlos no basta, hacen falta las relaciones

Una exportación de los clientes en una hoja de cálculo es un listado de nombres, no vuestro archivo. Un archivo está hecho de vínculos, y los vínculos son la parte que se pierde primero.

• Los identificadores: si los clientes tienen un código interno, debe aparecer también en las exportaciones de los pedidos, de lo contrario volver a vincularlos es un trabajo manual.
• El historial: estados anteriores, fechas de modificación, quién ha hecho qué. A menudo solo se exporta el último estado.
• Los adjuntos: contratos, fotografías, documentos firmados. Son archivos, no líneas, y deben exportarse indicando a qué estaban vinculados.
• Los campos calculados: totales, vencimientos, puntuaciones. Si no se conservan hay que reconstruirlos conociendo la fórmula, que por tanto debe estar escrita en algún sitio.
• El formato: abierto y legible sin el programa que lo generó. Un archivo exportado en un formato propietario sigue dependiendo de la misma herramienta.

Soporte, mantenimiento y evolución son tres cosas distintas

Hay que llamarlas con tres nombres distintos, de lo contrario se descubre en el momento de necesitarlo que lo que hacía falta no estaba incluido en la cuota.

• Soporte: resolver un fallo de funcionamiento. Hay que definir qué es un fallo, cómo se notifica y con qué plazos de atención.
• Mantenimiento: actualizaciones de los componentes, seguridad, adaptaciones cuando cambia algo alrededor. Hay que definir quién decide hacerlo y si está incluido.
• Evolución: modificaciones y funciones nuevas. Hay que definir cómo se presupuestan y quién las autoriza.
• Traspaso de la relación: qué se entrega, en cuánto tiempo y en qué forma si la relación termina. Es el punto que casi nadie pone por escrito al principio, es decir, cuando es fácil hablar de ello sin tensión.

La prueba: una exportación real, al menos una vez

Un listado de garantías nunca probadas vale poco. La verificación cuesta media jornada y hay que hacerla cuando todo va bien, no cuando hace falta.

1. Pedid una exportación completa de los datos, no una muestra elegida por otros.
2. Abridla en un ordenador de la empresa, sin usar herramientas que os preste el proveedor.
3. Tomad tres casos reales y complejos, un cliente con muchos pedidos, un expediente con adjuntos, un caso con una historia larga, y reconstruidlos a partir de los archivos. Si no lo conseguís, la exportación está incompleta.
4. Intentad restaurar una copia de seguridad en un entorno separado. Una copia nunca restaurada es una copia de la que no se sabe nada.
5. Anotad qué falta y qué no es reconstruible: este listado es el verdadero resultado de la prueba.

Un paquete de entrega de ejemplo

Ilustrativo, hay que adaptarlo al tamaño del proyecto. Es el listado de lo que debería existir en la empresa y seguir actualizado, con independencia de quién lo mantenga.

• Listado de los accesos, con el titular de la empresa indicado para cada uno.
• Dirección del archivo del código, cuando la entrega está prevista en el acuerdo, con las instrucciones para ponerlo en marcha.
• Descripción de la arquitectura en pocas páginas: qué piezas hay y cómo se comunican entre sí.
• Listado de los componentes de terceros y de las respectivas condiciones de uso.
• Procedimiento de las copias de seguridad: dónde están, cada cuánto, durante cuánto tiempo se conservan, cómo se restauran.
• Una muestra de exportación de los datos con la explicación de los campos.
• Los contactos operativos y qué hacer en caso de bloqueo.

Lo que esta guía no cubre

Aquí se habla de continuidad técnica: accesos, datos, documentación, pruebas. La propiedad del código, los derechos de uso, las cláusulas contractuales y las condiciones de rescisión están en un plano distinto y hay que verificarlas en el contrato y con un asesor legal, porque lo que aquí se describe como disponible depende en primer lugar de lo que se haya escrito en el acuerdo. La elección entre sistema de gestión estándar y software a medida, y los controles sobre permisos y copias de seguridad, tienen guías dedicadas.