Un proyecto informático puede empezar con una decisión empresarial perfectamente razonable, un proveedor solvente, una tecnología contrastada y unos objetivos aparentemente claros. Sin embargo, meses o incluso años después, cliente y proveedor pueden encontrarse defendiendo posiciones completamente enfrentadas ante un tribunal.
Leer artículo completo sobre peritaje SAP en este enlace páginas 56-57
¿Qué ha ocurrido entre ambos momentos?
Nuestra experiencia como auditores y peritos informáticos nos demuestra que, cuando un proyecto tecnológico acaba en juicio, raramente existe una única causa y todavía menos un único responsable. Lo habitual es encontrar una sucesión de decisiones, desviaciones, cambios, incumplimientos, problemas técnicos y deficiencias de gobierno que, acumulados durante el proyecto, terminan haciendo imposible su continuidad.
Precisamente sobre esta cuestión hablamos en nuestro artículo «La pericial informática en proyectos SAP: ni el software falla, ni el litigio es inevitable», publicado recientemente en las páginas 56 y 57 de la revista de AUSAPE.
Aunque el artículo parte de nuestra experiencia pericial en proyectos SAP, muchas de sus conclusiones pueden trasladarse prácticamente a cualquier proyecto informático complejo.
Un proyecto fallido no significa necesariamente que el software haya fallado
Cuando un proyecto tecnológico termina en conflicto existe una tendencia comprensible a simplificar lo ocurrido: “el software no funciona”, “el proveedor no ha cumplido” o, desde la posición contraria, “el cliente cambió continuamente los requisitos”.
Pero un proyecto informático es mucho más que software.
Detrás de una implantación ERP, un desarrollo a medida, una migración tecnológica, una plataforma SaaS o una integración de sistemas existen requisitos, procesos empresariales, datos, personas, contratos, planificación, desarrollos, pruebas, integraciones, decisiones y obligaciones de colaboración.
Por ello, la primera tarea del perito informático consiste precisamente en separar el problema técnico del problema de proyecto.
Puede existir software que realmente presente defectos. Pero también puede ocurrir que el producto funcione correctamente y que el fracaso tenga su origen en un alcance insuficientemente definido, una parametrización incorrecta, desarrollos adicionales deficientes, problemas de migración de datos, falta de recursos, requisitos cambiantes, pruebas insuficientes o una puesta en producción realizada sin las condiciones adecuadas.
Determinar técnicamente qué ha fallado es muy diferente de limitarse a constatar que el proyecto ha terminado mal.
¿Por qué acaba un proyecto informático ante un juez?
Los grandes conflictos tecnológicos rara vez aparecen de un día para otro.
Normalmente comienzan mucho antes de la demanda.
El alcance inicial empieza a modificarse. Aparecen funcionalidades que una parte considera incluidas y la otra considera adicionales. Los plazos comienzan a desplazarse. Se acumulan incidencias. Los datos no llegan con la calidad esperada. Las pruebas se retrasan. Se aceptan determinados hitos con reservas. Aparecen facturas que el cliente considera injustificadas. El proveedor entiende que está realizando trabajos fuera del alcance inicialmente contratado.
Y, progresivamente, un problema de gestión de proyecto se transforma en un problema contractual y finalmente en un problema judicial.
Cuando llegamos como peritos, debemos reconstruir esa historia.
La prueba del futuro litigio se está generando hoy
Esta es probablemente una de las principales conclusiones de nuestra experiencia pericial:
la prueba de un litigio informático no se construye cuando llega la demanda. Se construye durante la ejecución del proyecto.
Una reunión de seguimiento aparentemente rutinaria puede convertirse años después en una evidencia fundamental.
Una matriz de requisitos puede determinar si una funcionalidad estaba incluida en el alcance.
Un correo electrónico puede acreditar quién solicitó un cambio.
Un repositorio puede demostrar cuándo se realizó una determinada modificación.
Los resultados de las pruebas pueden acreditar si un entregable estaba realmente preparado para ser aceptado.
Los tickets pueden demostrar la existencia y evolución de determinadas incidencias.
Las actas de los comités pueden permitir reconstruir cuándo se conoció un problema y qué decisiones se adoptaron para solucionarlo.
Por eso, trazabilidad y evidencia son conceptos esenciales en cualquier proyecto informático, incluso cuando nadie contempla todavía la posibilidad de un conflicto.
Un informe pericial debe reconstruir el proyecto, no simplemente buscar errores
Cuando intervenimos en un procedimiento judicial, nuestro trabajo no consiste en recibir cientos o miles de documentos y seleccionar únicamente aquellos que favorecen la posición de quien nos ha contratado.
Una verdadera pericial informática debe ser capaz de reconstruir objetivamente el proyecto.
¿Qué se contrató?
¿Qué requisitos estaban incluidos?
¿Qué obligaciones correspondían al proveedor?
¿Qué obligaciones de colaboración correspondían al cliente?
¿Qué cambios se produjeron?
¿Quién los solicitó?
¿Qué impacto tuvieron sobre coste y planificación?
¿Qué se entregó?
¿Qué se probó?
¿Qué se aceptó?
¿Qué incidencias existieron y cuál era su gravedad real?
¿Existía un plan razonable de subsanación?
¿Era técnicamente viable continuar el proyecto?
Responder estas preguntas permite transformar una enorme cantidad de información técnica y documental en una explicación comprensible para abogados, partes y, finalmente, para el tribunal.
Tener incidencias no significa que un proyecto haya fracasado
Otro aspecto especialmente importante es diferenciar entre un proyecto con problemas y un proyecto técnicamente fallido.
Prácticamente cualquier proyecto tecnológico de cierta complejidad experimenta incidencias, desviaciones, cambios o retrasos. La existencia de tickets abiertos o defectos pendientes no demuestra, por sí misma, un incumplimiento esencial.
El análisis debe profundizar mucho más.
Hay que determinar la gravedad de las incidencias, su impacto sobre los procesos críticos, la existencia de soluciones alternativas, el grado de cumplimiento global, el estado de las pruebas y, especialmente, si existía un plan técnicamente viable de reconducción.
Esta diferencia puede resultar fundamental en sede judicial.
Cliente y proveedor: la responsabilidad no siempre está en un solo lado
En numerosos litigios tecnológicos encontramos inicialmente dos relatos aparentemente incompatibles.
El cliente sostiene que el proveedor no ha entregado aquello que contrató.
El proveedor sostiene que el cliente modificó continuamente el alcance, no proporcionó información, no dedicó los recursos necesarios o retrasó las decisiones imprescindibles para avanzar.
Y puede ocurrir que ambas afirmaciones sean parcialmente ciertas.
Un proyecto informático es una actividad colaborativa. El proveedor tiene importantes obligaciones técnicas y contractuales, pero el cliente también puede tener obligaciones esenciales relacionadas con disponibilidad de usuarios clave, definición de requisitos, validación, aportación de datos, toma de decisiones o aceptación de entregables.
Por ello, una pericial rigurosa debe analizar las actuaciones de ambas partes y determinar, cuando las evidencias lo permitan, qué circunstancias contribuyeron al resultado y en qué medida.
La mejor pericial puede ser la que evita el juicio
Nuestra experiencia en procedimientos judiciales nos lleva también a una conclusión preventiva.
No siempre hay que esperar a que exista una demanda para llamar a un perito informático.
Cuando un proyecto empieza a desviarse significativamente, una auditoría independiente puede analizar el estado real de los trabajos, el cumplimiento del alcance, los entregables, las pruebas, las incidencias, los cambios y las obligaciones pendientes de cada parte.
Ese análisis puede servir para reconducir el proyecto, establecer un plan objetivo de recuperación, renegociar determinadas condiciones o, si la continuidad ya no resulta viable, preparar una terminación ordenada y técnicamente documentada.
Por eso defendemos cada vez más la figura del perito preventivo: aplicar la metodología y el rigor probatorio de una pericial cuando todavía existe un proyecto que salvar.
De los proyectos SAP a cualquier gran conflicto tecnológico
En nuestro reciente artículo publicado en las páginas 56 y 57 de la revista de AUSAPE analizamos estas cuestiones específicamente desde la perspectiva de los proyectos SAP.
Pero la conclusión trasciende una tecnología concreta.
Puede tratarse de SAP, Microsoft Dynamics, Odoo, un ERP propio, una plataforma SaaS, un desarrollo a medida, una migración de sistemas, una aplicación móvil o un gran proyecto de integración.
La pregunta fundamental será siempre la misma:
¿Podemos reconstruir técnicamente qué se contrató, qué ocurrió, qué hizo cada parte y qué evidencias permiten demostrarlo?
Ese es el verdadero trabajo del perito informático.
En Legal Auditors y PeritajeSAP.es trabajamos precisamente en esa frontera entre tecnología y derecho: cuando los hechos técnicos necesitan convertirse en prueba y esa prueba debe ser suficientemente sólida para resistir el análisis de la parte contraria y del tribunal.
Nuestra preferencia, sin embargo, sigue siendo intervenir antes.
Porque un proyecto informático con problemas todavía puede tener solución. Un proyecto que llega al juzgado ya necesita, además, demostrar qué ocurrió.
Leer artículo completo sobre peritaje SAP en este enlace páginas 56-57
