Volver al blog
comparativa

Piloto de software en una asesoría: 6 criterios

Cómo probar un software en una asesoría antes de contratarlo: cartera de prueba, métricas, datos personales, salida y criterios de decisión fijados de antemano.

Daniel Vega14 de octubre de 20267 min
Equipo de una asesoría revisando resultados de una prueba de software en la oficina

Un piloto con documentos reales del propio despacho es la forma más fiable de decidir si un software de asesoría merece contratarse, porque una demo comercial muestra el caso que mejor funciona y la cartera de un despacho se compone sobre todo de casos medios y de excepciones. Este artículo recoge seis criterios para diseñar esa prueba y para decidir con ella.

La guía se aplica a cualquier categoría de software (contabilización, recepción documental, nóminas, conciliación). Los criterios sobre qué evaluar en cada categoría están en otros artículos del blog, como el de integración entre OCR y ERP. Aquí se trata el método de prueba.

Por qué una demo no sustituye a un piloto

Una demo se prepara con documentos que el proveedor ya sabe que se procesan bien: facturas nítidas, proveedores conocidos, un único tipo de IVA. El resultado es real, pero no es representativo de una cartera con autónomos en módulos, clientes con facturas manuscritas o proveedores extranjeros.

Un piloto cambia la pregunta. En lugar de "¿puede hacerlo?", pregunta "¿con qué frecuencia lo hace bien en este despacho y qué cuesta corregir el resto?". La segunda pregunta es la que determina si la herramienta ahorra trabajo. Si ya se ha valorado si conviene automatizar una tarea, el artículo cinco preguntas antes de automatizar una asesoría ayuda a ordenar esa decisión previa.

Criterio 1 - Una muestra que represente la cartera

La muestra se construye por perfiles, no por comodidad. Un reparto razonable incluye un autónomo en módulos, un autónomo en estimación directa, una sociedad pequeña, un cliente con operaciones intracomunitarias o con facturas en otro idioma y un cliente de volumen alto. Cinco a diez clientes suelen bastar para cubrir los perfiles.

Elegir solo a los clientes más ordenados produce un piloto que siempre sale bien y una implantación que después no cumple lo previsto. Conviene incluir de forma deliberada al menos un cliente que hoy genere trabajo extra.

Criterio 2 - Una línea base medida antes de empezar

Sin un dato de partida no hay comparación posible. Antes de la prueba se mide, con el método actual y durante un periodo equivalente, el tiempo por documento o por tarea, el porcentaje de errores detectados en revisión y el número de consultas al cliente para completar la documentación.

Estas mediciones no necesitan ser exactas; necesitan ser las mismas antes y después. Una hoja de cálculo con una muestra de cien documentos o de diez expedientes es suficiente para tener un punto de comparación defendible.

Criterio 3 - Umbrales de aprobado escritos antes de la prueba

Los criterios de decisión se fijan por escrito antes de abrir la primera cuenta de prueba. Un ejemplo de formato: "al menos X % de documentos sin corrección, tiempo de revisión por documento inferior a Y y cero asientos descuadrados en los cierres de prueba". Los valores concretos dependen de cada despacho y de lo que cuesta hoy el proceso.

Fijar los umbrales después sesga la lectura de los datos, porque cualquier resultado se puede interpretar a favor del producto que ya gusta. Con umbrales previos, un resultado intermedio se trata como lo que es y se puede pedir una segunda fase de prueba con cambios concretos.

Criterio 4 - Datos personales y contrato de encargado

Subir facturas o nóminas de clientes a una herramienta de prueba es un tratamiento de datos personales. El despacho actúa como responsable o encargado según el caso, y el proveedor pasa a ser encargado o subencargado. El art. 28 del Reglamento (UE) 2016/679 exige un contrato o acto jurídico que regule ese tratamiento, y el art. 5.1.c establece el principio de minimización.

En la práctica, antes del piloto se revisa que el proveedor ofrezca contrato de encargado también para la fase de prueba, que identifique a sus subencargados y que indique dónde se almacenan los datos. Más detalle sobre qué exigir está en el artículo de ciberseguridad en software fiscal. Cuando el contrato no esté disponible, la alternativa es anonimizar los documentos de la muestra.

Criterio 5 - Los límites de la propia prueba

Cada proveedor limita su periodo de prueba de forma distinta, por días, por número de documentos o por funciones. A modo de ejemplo, el periodo de prueba de AutoApunte (ver producto) es de 7 días o 100 documentos, lo que se cumpla antes. Con esos límites, la muestra debe elegirse con cuidado, porque no admite desperdiciar documentos en casos triviales.

Antes de empezar se pregunta qué funciones quedan fuera de la prueba, si la integración con el programa contable del despacho está incluida o solo se simula, y qué ocurre con los datos cargados al terminar. Un piloto que no puede probar la integración real mide solo la mitad del proceso.

Criterio 6 - La salida forma parte de la prueba

Al final del piloto se ejecuta la salida: exportar los datos cargados, comprobar el formato y verificar que se pueden abrir y reutilizar en otro programa. El art. 28.3.g del RGPD exige que el encargado suprima o devuelva los datos personales al terminar el servicio, a elección del responsable, y la prueba es el momento de menor coste para comprobar que eso ocurre en la práctica.

Los criterios para no quedar atado a un proveedor se desarrollan en el artículo sobre portabilidad de datos y cambio de software. Probar la salida durante el piloto evita descubrir limitaciones cuando ya hay un año de datos dentro.

Cómo leer los resultados

Los resultados se comparan con los umbrales fijados y con la línea base, y se clasifican en tres salidas posibles: cumple, no cumple, o cumple con condiciones. La tercera suele ser la más frecuente y requiere dejar por escrito qué condición falta (por ejemplo, una regla para un tipo de IVA concreto) y quién la resuelve.

Un resultado depende también de la adopción interna: quién del equipo revisa, con qué frecuencia y con qué criterio. Dos despachos con el mismo software pueden obtener resultados distintos por esa razón, de modo que conviene registrar quién ejecutó el piloto y con qué dedicación.

Diseñar la prueba con los documentos de cada despacho

Desarrollamos software a medida para asesorías y despachos. Una primera reunión sirve para ver cómo se trabaja hoy en el despacho y si tiene sentido.

Fuentes: Reglamento (UE) 2016/679 (RGPD), arts. 5.1.c, 28 y 32 - Agencia Española de Protección de Datos.

Preguntas frecuentes

¿Cuánto debe durar el piloto de un software para una asesoría?+

Depende del ciclo que se quiera medir. Para herramientas de contabilización o de recepción documental suele hacer falta al menos un cierre completo (mensual o trimestral), porque es donde aparecen las excepciones. Una prueba de pocos días sirve para descartar, pero no para decidir.

¿Se pueden usar datos reales de clientes en una prueba de software?+

Se puede si existe base legitimadora y contrato de encargado del tratamiento con el proveedor (art. 28 RGPD), y si se aplica el principio de minimización (art. 5.1.c). Si el proveedor no ofrece ese contrato para la fase de prueba, la alternativa es anonimizar los documentos o usar los de un cliente que lo haya autorizado.

¿Cuántos clientes hacen falta en la muestra del piloto?+

No hay una cifra normativa. Un criterio práctico es elegir entre cinco y diez clientes que representen los perfiles de la cartera (autónomo en módulos, sociedad pequeña, cliente con operaciones intracomunitarias, cliente con volumen alto) en lugar de un número grande de clientes parecidos.

¿Qué métricas conviene medir durante el piloto?+

Las que cambian la decisión: porcentaje de documentos que pasan sin corrección, tiempo de revisión por documento, tipos de error más repetidos y tiempo de respuesta del soporte ante una incidencia real. Cada una se compara con el mismo dato medido antes con el método actual.

¿Qué hacer si el proveedor no permite un piloto con documentos reales?+

Es una señal que conviene registrar. Si solo se ofrece una demo con datos propios del proveedor, se puede pedir una prueba con documentos anonimizados de la propia cartera. Si tampoco se acepta, la decisión se toma con menos información y debería reflejarse en la cláusula de salida del contrato.

¿Quieres automatizar la contabilidad de tu asesoría?

Prueba AutoApunte con tus facturas o cuéntanos cómo trabaja tu despacho.

software para asesoríaspilotocriterios de decisiónRGPDimplantaciónasesorías