LAUDO ARBITRAL

LAUDO ARBITRAL

Bogotá D.C., once (11) xx xxxxx de dos mil veinticuatro (2024)

Cumplido el trámite legal sin que se advierta causal alguna de nulidad y dentro de la oportunidad para hacerlo, procede el Tribunal Arbitral a proferir el Laudo en derecho que pone fin al proceso promovido por BMC BOLSA MERCANTIL DE COLOMBIA S.A., como parte convocante, DATAiFX S.A.S. como parte convocada y SEGUROS DEL ESTADO S.A., como llamada en garantía, previo un recuento sobre los antecedentes y demás aspectos preliminares del proceso.

I. ANTECEDENTES

1. ACTUACIÓN PROCESAL:

1.1. El día diecisiete (17) de febrero de dos mil veintitrés (2023), se presentó demanda arbitral por parte de BMC BOLSA MERCANTIL DE COLOMBIA S.A., (en adelante la Convocante, BMC o La Bolsa) contra DATAiFX S.A.S., (en adelante la Convocada o DATAiFX) y se solicitó la vinculación de la sociedad SEGUROS DEL ESTADO S.A., como llamada en garantía (en adelante la Llamada en Garantía).

1.2. El veintiocho (28) xx xxxxx de dos mil veintitrés (2023) mediante sorteo público se designaron como Árbitros para conformar el Tribunal a los Doctores XXXX XXXXXXX XXXXXX XXXXXXXX, XXXXX XXXXXXXX XXXXXXX XXXXXXX y XXXXX XXXXXXX XXXXXXX XXXXXXX. Este último declinó su designación por lo que se procedió a comunicar la designación al Doctor XXXX XXXXXXXX XXXXXX XXXXXX como primer Árbitro suplente designado en el sorteo público. Los Árbitros aceptaron el encargo y cumplieron con el deber de información.

1.3. Como se señaló, previa información de la designación, aceptación y cumplimiento del deber de revelación por parte de los árbitros designados, se llevó a cabo la audiencia de instalación el día cuatro (4) xx xxxx de dos mil veintitrés (2023).

1.4. En la audiencia de instalación, el Tribunal se declaró legalmente instalado y nombró como Presidente a la doctora XXXXX XXXXXXXX XXXXXXX XXXXXXX y como Secretario al doctor XXXXXXXXX XXXXXXX XXXXXXX XXXXXXXX. De igual forma, fijó como lugar de funcionamiento y secretaría el Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, ubicado en la Xxxxx 00 Xx. 00-00 y reconoció personería al apoderado de la Convocante. Así mismo, inadmitió la demanda y el llamamiento en garantía.

1.5. El día ocho (8) xx xxxx de dos mil veintitrés (2023) la Parte Convocante presentó escrito por medio del cual subsanó la demanda arbitral y el

llamamiento en garantía, siendo estos admitidos mediante Auto No. 4 del día dieciséis (16) xx xxxx de dos mil veintitrés (2023).

1.6. El 16 xx xxxx de 2023 por secretaría, se le notificó el auto admisorio de la demanda y el llamamiento en garantía a las partes.

1.7. El 18 xx xxxx de 2023 la Llamada en Garantía interpuso recurso de reposición contra el auto admisorio de la demanda. Después de corrido su traslado, el Tribunal mediante Auto No. 5 del 29 xx xxxx de 2023 decidió negar el recurso y confirmar la decisión.

1.8. El 20 xx xxxxx de 2023 la Convocada contestó la demanda, presentó demanda de reconvención y escrito de excepciones previas.

1.9. La demanda de reconvención fue inadmitida por Auto No. 6 del 29 xx xxxxx de 2023, providencia en la cual también se declaró improcedente la excepción previa presentada.

1.10. El 29 xx xxxxx de 2023 la Llamada en Garantía contestó la demanda y el llamamiento en garantía en un solo documento.

1.11. La Convocada subsanó dentro del término xx xxx la demanda de reconvención y esta fue admitida mediante Auto No. 7 del 11 de julio de 2023, que fue debidamente notificado a las partes el 12 de julio de 2023.

1.12. El 17 de julio de 2023 la Convocante interpuso recurso de reposición contra el auto admisorio de la demanda de reconvención. Después de corrido su traslado, el Tribunal mediante Auto No. 8 del 26 de julio de 2023 decidió negar el recurso y confirmar la decisión.

1.13. El 22 xx xxxxxx de 2023 la Llamada en Garantía contestó la demanda de reconvención.

1.14. El 28 xx xxxxxx de 2023 la Parte Convocante contestó la demanda de reconvención.

1.15. Dentro del término xx xxx las Partes descorrieron el traslado de las mutuas excepciones de mérito y objeciones a los respectivos juramentos estimatorios.

1.16. El 22 de septiembre de 2023 se llevó a cabo la audiencia de fijación de honorarios, en la cual el Tribunal por Auto No. 11 procedió a fijar las sumas por concepto de honorarios y gastos del proceso a cargo de las Partes y la Llamada en Garantía.

1.17. La Convocante pagó oportunamente las sumas a su cargo fijadas para honorarios y gastos del proceso, así como las de la Parte Convocada.

1.18. En lo que se refiere al llamamiento en garantía, la Parte Convocante pagó las sumas adicionales fijadas en razón de la intervención xxx xxxxxxx, por cuanto la Llamada en Garantía no lo hizo.

1.19. El día veintitrés (23) de octubre de dos mil veintitrés (2023), el Tribunal Arbitral llevó a cabo la primera audiencia de trámite y, dentro de ella profirió los Autos Nos. 13, 14 y 15, por medio de los cuales se declaró competente para resolver en derecho la controversia, decretó las pruebas solicitadas por las partes y estableció el cronograma de pruebas del proceso.

1.20. El día veintitrés (23) de octubre de dos mil veintitrés (2023), la Convocante solicitó la expedición de la constancia del pago de los honorarios y gastos por ella realizado en nombre de la Convocada, según lo previsto en el artículo 27 de la Ley 1563 de 2012. La certificación fue expedida por el Tribunal el veinticinco (25) de octubre de dos mil veintitrés (2023).

1.21. El treinta (30) de noviembre de dos mil veintitrés (2023), la Llamada en Garantía remitió comunicación en la cual informó sobre el reembolso de los honorarios decretados a su cargo y que habían sido pagados inicialmente por la Convocante.

1.22. Las pruebas fueron practicadas en diferentes sesiones a instancia del Tribunal y con la comparecencia de las Partes, testigos y peritos según fue requerido en cada momento.

1.23. El día cuatro (4) xx xxxxx de dos mil veinticuatro (2024) mediante Auto No. 26 se decretó el cierre de la etapa probatoria y se dejó expresa constancia de la conformidad de las partes sobre la manera en que se evacuaron las pruebas y el ejercicio de sus derechos y garantías constitucionales.

1.24. El día ocho (8) xx xxxxx de dos mil veinticuatro (2024), las Partes y la Llamada en Garantía, alegaron de conclusión y se expidió el Auto No. 27 que señaló fecha como para el pronunciamiento xx xxxxx el día once

(11) xx xxxxx de dos mil veinticuatro (2024) a las tres de la tarde (3:00 P.M.).

2. CLÁUSULA COMPROMISORIA:

BMC y DATAiFX suscribieron los siguientes contratos:

(i) CONTRATO MARCO DE SERVICIOS TECNOLÓGICOS ENTRE LA BOLSA MERCANTIL DE COLOMBIA S.A. Y DATAiFX S.A.S. No. CO-2020-0051, que en la cláusula segunda establece como objeto: “DATAIFX se obliga para con la BOLSA a ejecutar bajo la modalidad de un Contrato Llave en Mano, el Proyecto Refactoring,

conforme con el alcance tecnológico y condiciones señaladas en la Invitación, en la Propuesta y en los Documentos de Discovery.

DATAIFX se obliga a cumplir con los requerimientos del alcance plasmado en la Invitación, para las funcionalidades de los sistemas SIB, SIG, SEGAs, Oferta de Comisión, requisitos técnicos, no funcionales y de seguridad, así como el detalle que DATAIFX recopile en la etapa de Levantamiento de Información y que reflejan las necesidades operativas de la BOLSA, el cual se plasmará en los Documentos de Discovery y que complementarán el objeto del Contrato y sobre las cuales se realizará el Refactoring”.

(ii) CONTRATO DE PRESTACIÓN DE SERVICIOS TECNOLÓGICOS PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE LA SOLUCIÓN TECNOLÓGICA PARA EL PROYECTO BACK OFFICE, CELEBRADO ENTRE LA BMC BOLSA MERCANTIL DE COLOMBIA S.A. Y DATAiFX S.A.S. NO. CO-2020-0060, que en la cláusula segunda establece como objeto: “DATAIFX se obliga para con LA BOLSA a ejecutar, bajo la modalidad de un Contrato Llave en Mano, el Proyecto Back Office, de conformidad con las condiciones señaladas en el presente Contrato, así como en la Invitación y en la Propuesta, las cuales forman parte integral del Contrato.

PARÁGRAFO: En desarrollo del objeto contratado, DATAIFX adelantará todas las gestiones necesarias para la ejecución y correcta prestación de los servicios. DATAIFX acepta la aplicación de las multas y sanciones cuando la prestación del servicio no sea realizada en óptimas condiciones y dentro de los tiempos establecidos por LA BOLSA y conforme al Cronograma que hace parte integral del Contrato”.

En los dos contratos celebrados, las partes pactaron una cláusula compromisoria con idéntica redacción, en los siguientes términos:

CONTRATO MARCO DE SERVICIOS TECNOLÓGICOS ENTRE LA BOLSA MERCANTIL DE COLOMBIA S.A. Y DATAiFX S.A.S. No. CO-2020-0051:

“TRIGÉSIMA NOVENA. -MECANISMOS DE RESOLUCIÓN DE CONTROVERSIAS Y CLÁUSULA COMPROMISORIA: Toda

controversia relativa a la celebración, ejecución y liquidación de este Contrato se resolverán amigablemente entre LAS PARTES, dentro de los quince (15) días hábiles siguientes a la solicitud que curse por escrito una de ellas a la otra. En caso de no lograrse un acuerdo, se someterá a la decisión de un Tribunal de Arbitramento, el cual sólo tendrá competencia para dirimir conflictos de carácter declarativo, en los términos de esta Cláusula. El Tribunal se regirá por las normas vigentes en el momento en el que se lo convoque, y se ceñirá a las siguientes reglas.

39.1 Si la cuantía de la disputa o controversia es igual o superior a cuatrocientos (400) salarios mínimos legales mensuales vigentes, el Tribunal estará integrado por tres (3) árbitros. De lo contrario, se acudirá a un (1) sólo árbitro.

39.2 Los árbitros serán designados por LAS PARTES de común acuerdo, de conformidad con la Ley, si no se lograre un acuerdo, los designará la Cámara de Comercio de Bogotá, de conformidad con el procedimiento establecido para el efecto.

39.3 La organización interna del Tribunal, el procedimiento aplicable en cuanto al trámite arbitral y de funcionamiento del Tribunal, así como los costos y honorarios aplicables, se sujetará a las reglas previstas para el efecto por el Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, si LAS PARTES, en cuanto a la Ley se los permita, no conviene otra cosa.

39.4 El Tribunal fallará en Derecho.

39.5 El Tribunal sesionará en Bogotá D.C., República de Colombia, en el Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, o, si la Ley lo permitiere, en el sitio que los árbitros decidan, habiendo oído a LAS PARTES. Toda controversia o diferencia, de hecho, o de derecho, que surja entre las partes con motivo de la ejecución, modificación, suspensión, terminación o liquidación del presente contrato se resolverá de común acuerdo entre LAS PARTES, las cuales se reunirán a efectos de zanjar los inconvenientes que se presenten”.

CONTRATO DE PRESTACIÓN DE SERVICIOS TECNOLÓGICOS PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE LA SOLUCIÓN TECNOLÓGICA PARA EL PROYECTO BACK OFFICE, CELEBRADO ENTRE LA BMC BOLSA MERCANTIL DE COLOMBIA S.A. Y DATAiFX S.A.S. NO. CO-2020- 0060:

“TRIGÉSIMA PRIMERA. -MECANISMOS DE RESOLUCIÓN DE CONTROVERSIAS Y CLÁUSULA COMPROMISORIA: Toda

controversia relativa a la celebración, ejecución y liquidación de este Contrato se resolverán amigablemente entre LAS PARTES, dentro de los quince (15) días hábiles siguientes a la solicitud que curse por escrito una de ellas a la otra. En caso de no lograrse un acuerdo, se someterá a la decisión de un Tribunal de Arbitramento, el cual sólo tendrá competencia para dirimir conflictos de carácter declarativo, en los términos de esta Cláusula. El Tribunal se regirá por las normas vigentes en el momento en el que se lo convoque, y se ceñirá a las siguientes reglas.

31.1 Si la cuantía de la disputa o controversia es igual o superior a cuatrocientos (400) salarios mínimos legales mensuales vigentes, el Tribunal estará integrado por tres (3) árbitros. De lo contrario, se acudirá a un (1) sólo árbitro.

31.2 Los árbitros serán designados por LAS PARTES de común acuerdo, de conformidad con la Ley, si no se lograre un acuerdo, los designará la Cámara de Comercio de Bogotá, de conformidad con el procedimiento establecido para el efecto.

31.3 La organización interna del Tribunal, el procedimiento aplicable en cuanto al trámite arbitral y de funcionamiento del Tribunal, así como los costos y honorarios aplicables, se sujetará a las reglas previstas para el efecto por el Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, si LAS PARTES, en cuanto a la Ley se los permita, no conviene otra cosa.

31.4 El Tribunal fallará en Derecho.

31.5 El Tribunal sesionará en Bogotá D.C., República de Colombia, en el Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, o, si la Ley lo permitiere, en el sitio que los árbitros decidan, habiendo oído a LAS PARTES. Toda controversia o diferencia, de hecho, o de derecho, que surja entre las partes con motivo de la ejecución, modificación, suspensión, terminación o liquidación del presente contrato se resolverá de común acuerdo entre LAS PARTES, las cuales se reunirán a efectos de zanjar los inconvenientes que se presenten”.

De las cláusulas compromisorias transcritas, se advierte la intención de las Partes de deferir el conocimiento y resolución de las controversias que surjan en relación con los negocios jurídicos celebrados, a un tribunal de arbitramento.

En el mismo orden de ideas, el pacto arbitral, contenido en los Contratos celebrados entre las partes, fue suscrito por personas capaces (representantes legales de las partes), sin que se haya invocado algún vicio del consentimiento en su celebración (Arbitrabilidad subjetiva).

El objeto del pacto arbitral es lícito, pues busca dirimir “toda controversia relativa a la celebración, ejecución y liquidación” de los contratos, siempre que estas tengan “carácter declarativo” y no se ha invocado ni acreditado que el pacto tenga causa ilícita. Adicionalmente, el pacto arbitral está referido a asuntos de contenido patrimonial y de libre disposición, en los términos del inciso inicial del artículo 1º de la Ley 1563 de 2012 (Arbitrabilidad objetiva).

Se tiene entonces que el pacto arbitral reúne los requisitos de existencia y validez exigidos por la ley.

3. PARTES INTERVINIENTES EN EL PRESENTE PROCESO ARBITRAL:

3.1. Parte Convocante y Demandada en Reconvención:

BMC BOLSA MERCANTIL DE COLOMBIA S.A., (en adelante la Convocante, BMC o La Bolsa) sociedad anónima, identificada con Nit. 860.071.250-9, representada legalmente por XXXXXX XXXXXXX XXXXX, identificada con la cédula de ciudadanía 52.690.727, según consta en el certificado expedido por la Superintendencia Financiera de Colombia, aportado al expediente1.

La Convocante otorgó poder al Doctor XXXXXXXXX XXXXXXX XXXXXXX XXXXXXXXX, para su representación judicial dentro de este trámite2, a quien el Tribunal le reconoció personería para actuar en la audiencia de instalación llevada a cabo el 4 xx xxxx de 20233.

3.2. Parte Convocada y Demandante en Reconvención:

DATAiFX S.A.S. (en adelante la Convocada o DATAiFX), sociedad por acciones simplificada, identificada con Nit. 900.365.835-4, representada legalmente por XXXX XXXXX XXXXX XXXXXX, identificado con la cédula de ciudadanía 10.023.679, según consta en el certificado de existencia y representación legal expedido por la Cámara de Comercio de Bogotá, aportado al expediente4.

La Convocada otorgó poder al Doctor XXXX XXXXXXX XXXXXXX XXXXXX, para su representación judicial dentro de este trámite5, a quien el Tribunal le reconoció personería para actuar mediante Auto No. 6 del 29 xx xxxxx de 20236.

3.3. Llamada en Garantía:

SEGUROS DEL ESTADO S.A. (en adelante la llamada en garantía, la Aseguradora o Seguros del Estado), sociedad anónima, identificada con Nit. 860.009.578-6, que según el Certificado expedido por la Superintendencia Financiera de Colombia aportado al expediente7, está representada legalmente por el señor XXXXXXXX XXXX XXXXXXXX identificado con la cédula de ciudadanía 00.000.000.

La llamada en garantía otorgó poder al Doctor XXXX XXXXX XXXXXXX XXXXXX, para su representación judicial dentro de este trámite8, a quien el Tribunal le reconoció personería para actuar mediante Auto No. 6 del 29 xx xxxxx de 20239.

1 Expediente virtual 141365 - Cuaderno Principal_01 Documento 002_CERTIFICADO

2 Expediente virtual 141365 - Cuaderno Principal_01 Documento 009_Poder_Convocante

3 Expediente virtual 141365 - Cuaderno Principal_01 Documento 031_Instalación

4 Expediente virtual 141365 - Cuaderno Principal_01 Documento 006_Certificado cámara DATAiFX

5 Expediente virtual 141365 - Cuaderno Principal_02 Documento 19_Poder_DATAIFX

6 Expediente virtual 141365 - Cuaderno Principal_02 Acta_4

7 Expediente virtual 141365 - Cuaderno Principal_02 Documento 23_CERTIFICADO_SEGUROS_DEL_ESTADO

8 Expediente virtual 141365 - Cuaderno Principal_02 Documento 22_PODER_SEGUROS_DEL_ESTADO

9 Expediente virtual 141365 - Cuaderno Principal_02 Acta_4

4. CONTROVERSIAS SOMETIDAS A CONOCIMIENTO DEL PRESENTE TRIBUNAL:

Las controversias sometidas al conocimiento y decisión del presente Tribunal Arbitral se encuentran contenidas en la demanda principal y la demanda de reconvención, según se transcribe a continuación:

4.1. Demanda Principal.

4.1.1. Pretensiones de la demanda arbitral Principal:

El escrito de la demanda presentado por la Convocante señaló como pretensiones las siguientes10:

“DECLARACIONES Y CONDENAS:

PRETENSIÓN PRIMERA PRINCIPAL:

Que se declare que la sociedad DATAIFX incumplió parcialmente lo pactado en el Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060, celebrado entre la BMC y DATAIFX, según se relatará en los hechos de la presente demanda.

PRETENSIÓN ÚNICA CONSECUENCIAL DE LA PRIMERA PRINCIPAL:

Que como consecuencia de la anterior declaración se condene a la sociedad DATAIFX a pagar a mi mandante, a título de daño emergente, la suma de $ 453’517.551,66 como indemnización de los perjuicios materiales que le causó el incumplimiento culpable del Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060, celebrado entre la BMC y DATAIFX.

PRETENSIÓN SEGUNDA PRINCIPAL:

Que se declare que la sociedad DATAIFX incumplió su obligación de “GARANTÍA” pactada en la CLÁUSULA VIGÉSIMA del Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060 celebrado entre la BMC y DATAIFX, según la definición y durante el “PERÍODO DE GARANTÍA” determinado en la CLÁUSULA PRIMERA del Contrato, según se relatará en los hechos de la presente demanda.

10 Las pretensiones fueron transcritas en el presente laudo tal cual como aparecen en demanda presentada por BMC.

PRETENSIÓN ÚNICA CONSECUENCIAL DE LA SEGUNDA PRINCIPAL:

Que como consecuencia de la anterior declaración se condene a la sociedad DATAIFX a pagar a mi mandante, a título de daño emergente, la suma de $295’436.704,oo. como indemnización de los perjuicios materiales que le causó el incumplimiento de su obligación de “GARANTÍA” pactada en la CLÁUSULA VIGÉSIMA del Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060 celebrado entre la BMC y DATAIFX, según la definición y durante el “PERÍODO DE GARANTÍA” determinado en la CLÁUSULA PRIMERA del Contrato.

PRETENSIÓN TERCERA PRINCIPAL:

Que se declare que la sociedad DATAIFX incumplió totalmente lo pactado en el Contrato Xxxxx de Servicios Tecnológicos No. CO- 2020- 0051 (Refactoring), celebrado entre la BMC y DATAIFX, según se relatará en los hechos de la presente demanda.

PRETENSIÓN ÚNICA CONSECUENCIAL DE LA TERCERA PRINCIPAL:

Que como consecuencia de la anterior declaración se condene a la sociedad DATAIFX a pagar a mi mandante, a título de daño emergente, la suma de $3.566’134.272,oo como indemnización de los perjuicios materiales que le causó el incumplimiento culpable del Marco de Servicios Tecnológicos No. CO-2020-0051 (Refactoring), celebrado entre la BMC y DATAIFX.

PRETENSIÓN CONSECUENCIAL DE TODAS LAS ANTERIORES:

Que se condene a la demandada a pagar las costas del proceso y las agencias en derecho, al tenor de lo dispuesto por los artículos 365 y 366 del Código General del Proceso”.

4.1.2. Hechos de la demanda arbitral Principal:

La Convocante fundamenta sus pretensiones en ciento veintisiete (127) hechos que relaciona en la demanda y clasifica en distintos apartados, a los cuales la Parte Convocada y la Llamada en Garantía se refieren en las respectivas contestaciones a la demanda.

El Tribunal al estudiar los temas materia de decisión se referirá a ellos.

4.2. Llamamiento en garantía

4.2.1. Pretensiones del llamamiento en garantía

El escrito de llamamiento en garantía presentado por la Convocante señaló como pretensiones las siguientes11:

“DECLARACIONES Y CONDENAS:

PRETENSIONES RELACIONADAS CON LA PÓLIZA DE SEGURO DE CUMPLIMIENTO PARTICULAR 00-00-000000000:

1. Que se declare que en el evento en que el demandado DATAIFX

S.A.S. (en adelante DATAIFX) sea condenado a pagar alguna suma de dinero por cualquier concepto en favor de la demandante en el proceso referenciado, en su condición de beneficiaria de la prestación asegurada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000 expedida por SEGUROS DEL ESTADO S.A., la totalidad de dicha suma, hasta concurrencia del valor asegurado, sea sufragada por SEGUROS DEL ESTADO S.A., en su condición de garante de la sociedad DATAIFX en el cumplimiento con las prestaciones que asumió en virtud del contrato CO-2020-0060, afectando las Coberturas de Cumplimiento y de Calidad del Servicio contenidas en la póliza de seguro anotada, debido a la ocurrencia del siniestro que se relatará en el acápite de hechos de este llamamiento en garantía.

2. Que en consecuencia se condene a SEGUROS DEL ESTADO S.A. a pagar a mi mandante, en su condición de beneficiaria designada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000, a título de reparación del daño, por concepto de daño emergente, la suma de $ 342’114.666,20, que corresponde al valor asegurado en el amparo de cumplimiento en la póliza en mención, ya que los perjuicios directos sufridos por mi mandante debido al incumplimiento del afianzado de las obligaciones que asumió en virtud del contrato cuyo cumplimiento garantizó SEGUROS DEL ESTADO S.A., son superiores a la suma asegurada pactada en la póliza para el Amparo de Cumplimiento.

3. Que en consecuencia se condene a SEGUROS DEL ESTADO S.A. a pagar a mi mandante, en su condición de beneficiaria designada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000, a título de reparación del daño, por concepto de daño emergente, la suma de $ 295’436.704,oo, que corresponde al valor de los perjuicios directos sufridos por mi mandante debido al incumplimiento del afianzado de las obligaciones que asumió en virtud del contrato cuyo cumplimiento garantizó SEGUROS DEL ESTADO S.A., afectando la garantía de calidad del servicio contenida en la póliza en mención.

11 Las pretensiones fueron transcritas en el presente laudo tal cual como aparecen en el llamamiento en garantía presentado por BMC.

4. Que en consecuencia se condene a SEGUROS DEL ESTADO S.A. a pagar a mi mandante, en su condición de beneficiaria designada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000, a título de reparación del daño, por concepto de lucro cesante, el valor de los intereses moratorios calculado sobre la sumas que se señalan en las pretensiones anteriores, a la máxima tasa permitida por la legislación vigente al momento de cada período xx xxxx, desde la admisión del presente llamamiento en garantía y hasta cuando se lleve a cabo el pago respectivo.

PRETENSIONES RELACIONADAS CON LA PÓLIZA DE SEGURO DE CUMPLIMIENTO PARTICULAR 00-00-000000000:

1. Que se declare que en el evento en que el demandado DATAIFX

S.A.S. (en adelante DATAIFX) sea condenado a pagar alguna suma de dinero por cualquier concepto en favor de la demandante en el proceso referenciado, en su condición de beneficiaria de la prestación asegurada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000 expedida por SEGUROS DEL ESTADO S.A., la totalidad de dicha suma, hasta concurrencia del valor asegurado, sea sufragada por SEGUROS DEL ESTADO S.A., en su condición de garante de la sociedad DATAIFX en el cumplimiento con las prestaciones que asumió en virtud del contrato CO- CO-2020-0051, afectando la Cobertura de Cumplimiento contenida en la póliza de seguro anotada, debido a la ocurrencia del siniestro que se relatará en el acápite de hechos de este llamamiento en garantía.

2. Que en consecuencia se condene a SEGUROS DEL ESTADO S.A. a pagar a mi mandante, en su condición de beneficiaria designada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000, a título de reparación del daño, por concepto de daño emergente, la suma de $ 827’097.600,oo, que corresponde al valor asegurado en el amparo de cumplimiento en la póliza en mención, ya que los perjuicios directos sufridos por mi mandante debido al incumplimiento del afianzado de las obligaciones que asumió en virtud del contrato cuyo cumplimiento garantizó SEGUROS DEL ESTADO S.A. son superiores a la suma asegurada pactada en la póliza para el Amparo de Cumplimiento.

3. Que en consecuencia se condene a SEGUROS DEL ESTADO S.A. a pagar a mi mandante, en su condición de beneficiaria designada en la Póliza de Seguro de Cumplimiento Particular 00-00-000000000, a título de reparación del daño, por concepto de lucro cesante, el valor de los intereses moratorios calculado sobre la suma que se señala en la pretensión anterior, a la máxima tasa permitida por la legislación vigente al momento de cada período xx xxxx, desde la admisión del presente llamamiento en garantía y hasta cuando se lleve a cabo el pago respectivo”.

4.2.2. Hechos del llamamiento en garantía

La parte Convocante fundamenta sus pretensiones frente a la Llamada en Garantía en ciento veinticuatro (124) hechos que relaciona en el llamamiento y clasifica en distintos apartados, a los cuales la Llamada en Garantía se refiere en la respectiva contestación.

El Tribunal al estudiar los temas materia de decisión se referirá a ellos.

4.3. Demanda de reconvención

4.3.1. Pretensiones de la demanda de reconvención

El escrito de demanda de reconvención presentado por la Convocada señaló como pretensiones las siguientes12:

“1. Pretensión primera principal:

Que se declare que la BMC incumplió el Contrato Back Office y con dicho incumplimiento, la BMC le causó a DATAIFX daños y perjuicios.

1.1. Pretensión consecuencial de la primera principal:

Que se condene a la BMC a pagar los costos directos incurridos por parte de DATAIFX como resultado de la aplicación del método RUP-SCRUM, la suma de COP$1 030 087 787,994 menos el valor de los pagos hechos por la BMC a DATAIFX, netos de IVA y retenciones, es decir la suma de COP$000 000 000,55, para un valor neto de COP$239 486 668,44.

2. Pretensión segunda principal:

Que se declare que la BMC incumplió el Contrato Refactoring y con dicho incumplimiento, la BMC le causó a DATAIFX daños y perjuicios.

2.1. Pretensión consecuencial de la segunda principal:

Que se condene a la BMC a pagar los costos directos incurridos por parte de DATAIFX como resultado de la aplicación del método RUP-SCRUM, la suma de COP$2 634 224 073,275 menos el valor de los pagos hechos por la BMC a DATAIFX, netos de IVA y retenciones, es decir la suma de COP$1 424 832 000,00, para un valor neto de COP$1 209 392 073,27.

3. Pretensiones consecuenciales conjuntas de la primera y segunda principales:

12 Las pretensiones fueron transcritas en el presente laudo tal cual como aparecen en la demanda de reconvención presentada por DATAIFX.

3.1. Que se condene a la BMC a pagar el endeudamiento, sus intereses corrientes y moratorios, que incurrió DATAIFX para desarrollar los contratos de Refactoring y Back-Office, es decir la suma de COP$527 955 936,006.

3.2. Que se condene a la BMC a pagar a DATAIFX el margen de los contratos que se vio forzada a ceder DATAIFX por la situación de iliquidez que causaron los incumplimientos de la BMC, que le impedía cumplir esos contratos, es decir la suma de COP$992 032 491,167.

3.3. Que se condene a la BMC a pagar las liquidaciones laborales y de seguridad social que DATAIFX no ha podido pagar por la situación de iliquidez que causaron los incumplimientos de la BMC, es decir la suma de COP$424 547 080,008.

3.4. Que se condene a la BMC a pagar los intereses y sanciones por concepto de impuestos que DATAIFX no ha podido pagar por la situación de iliquidez que causaron los incumplimientos de la BMC, es decir la suma de COP$700 719 200,009.

El total de las pretensiones anteriores es la suma de COP$ 4 094 133 448,87.

4. Que se pague la cláusula penal contemplada en ambos contratos, a saber:

• Contrato de Back Office la condena por concepto de la aplicación de la cláusula penal por valor de: COP$ 287.491.316

• Contrato de Refactoring la condena por concepto de la aplicación de la cláusula penal por valor de: COP$ 695.040.000

5. Que se declare que la propiedad intelectual de todo el trabajo elaborado por DATAIFX para la BMC es propiedad de DATAIFX.

6. Que se condene a pagar intereses moratorios a la BMC desde la fecha xxx xxxxx hasta el momento efectivo de pago.

7. Que se condene en costas a la BMC”.

4.3.2. Hechos de la demanda de reconvención

La Convocada fundamenta sus pretensiones en ciento un (101) hechos que relaciona en la demanda de reconvención y clasifica en distintos apartados, a los cuales la Parte Convocante y la Llamada en Garantía se refieren en las respectivas contestaciones a la demanda de reconvención.

El Tribunal al estudiar los temas materia de decisión se referirá a ellos.

4.4. Contestación de la demanda principal por parte de DATAiFX

La Convocada contestó la demanda principal, admitió unos hechos y negó otros y se opuso expresamente a la prosperidad de las pretensiones.

Al efecto, la Convocada esgrimió en su defensa las excepciones que denominó:

- Incumplimiento previo de la BMC (excepción de contrato no cumplido)

- Abuso del derecho

- Inexistencia de las obligaciones porque nunca se concretó su objeto

- Inexistencia de las obligaciones porque el objeto era físicamente imposible

- Ausencia de modificación del contrato

- Ejecución de mala fe

- La obligación de garantía del contrato Back Office nunca nació

- Aplicación de la teoría del acto propio. Consecuencias del actuar

- Cláusula penal no es exigible

- Excepción genérica

Sobre las excepciones de mérito propuestas se pronunciará el Tribunal más adelante.

4.5. Contestación a la demanda principal y al llamamiento en garantía por parte de SEGUROS DEL ESTADO S.A.

La Llamada en Garantía contestó la demanda principal y el llamamiento en garantía en un solo escrito, admitió unos hechos y negó otros y se opuso expresamente a la prosperidad de las pretensiones.

Al efecto, la Llamada en Garantía esgrimió en su defensa las excepciones que denominó:

Frente a la demanda principal:

- No se configuran los elementos de la responsabilidad contractual frente a DATAIFX SAS

- Excepción de contrato no cumplido

- El actor va contra sus propios actos previos

- No podría la parte actora beneficiarse de su propia culpa

- Xxxxx está obligado a lo imposible - xxxxxxxx xxxxxxx

- Inexigibilidad de la obligación de garantía

- Ausencia de daño indemnizable Frente al llamamiento en garantía:

- Los amparos de la póliza de cumplimiento son independientes entre sí

- Ausencia de demostración de la ocurrencia y cuantía de la pérdida

- Terminación del contrato de seguro por agravación objetiva del estado del riesgo

- Reducción de la indemnización del beneficiario, por permitir la propagación del siniestro - perdida de la indemnización por participar en la ocurrencia del siniestro

- Ausencia de cobertura de la cláusula penal

- Prescripción de acciones y derechos derivados del contrato de seguro

- Compensación

- Límite del valor asegurado y aplicación del deducible

- Excepción genérica

Sobre las excepciones de mérito propuestas se pronunciará el Tribunal más adelante.

4.6. Contestación a la demanda de reconvención por parte de BMC

La Convocante contestó la demanda de reconvención, admitió unos hechos y negó otros y se opuso expresamente a la prosperidad de las pretensiones.

Al efecto, la Convocante esgrimió en su defensa las excepciones que denominó:

- Ausencia de prueba del incumplimiento de las obligaciones contractuales a cargo de mi mandante

- Excepción de contrato no cumplido

- Indebida acumulación de pretensiones

Sobre las excepciones de mérito propuestas se pronunciará el Tribunal más adelante.

4.7. Contestación a la demanda de reconvención por parte de SEGUROS DEL ESTADO S.A.

La Llamada en Garantía contestó la demanda de reconvención, admitió unos hechos y negó otros y respecto de las pretensiones manifestó no oponerse “a ninguna de las pretensiones deprecadas por el demandante en reconvención contra la BMC BOLSA MERCANTIL DE COLOMBIA S.A.”.

Respecto de las excepciones, manifestó que en tanto no se oponen a las pretensiones deprecadas por el demandante en reconvención contra la BMC BOLSA MERCANTIL DE COLOMBIA S.A., en relación con la demanda de reconvención no se presentaba excepción alguna.

5. PRUEBAS:

En la primera audiencia de trámite, el Tribunal decretó todas las pruebas solicitadas por las partes en las oportunidades procesales establecidas para

el efecto. En esta oportunidad, el Tribunal señaló fechas para la práctica de las diligencias.

A continuación el Tribunal realiza un recuento de la práctica de las pruebas dentro del proceso:

5.1. Xxxxxxx solicitadas por la parte convocante en la demanda inicial, al contestar la demanda de reconvención, en el llamamiento en garantía, y en los escritos con los cuales descorrió los traslados de excepciones de mérito y objeciones al juramento estimatorio.

5.1.1. Documentales

Se decretaron como pruebas, con el valor que les atribuye la ley, los siguientes documentos:

(i) Los aportados con la demanda que obran en el expediente virtual (141365_02_Pruebas_Pruebas_02_00_Demanda)

(ii) Los aportados al contestar la demanda de reconvención que obran en el expediente virtual (141365_02_Pruebas_Pruebas_02_05_Links_Contestación_Dema nda_Reconvención_Convocante)

(iii) Los aportados con el llamamiento en garantía que obran en el expedientevirtual(141365_02_Pruebas_Pruebas_02_01_Pruebas_ Documentales_Llamamiento_En_Garantía)

5.1.2. Interrogatorios de Parte

Se decretó la práctica de interrogatorio de parte al representante legal de la sociedad convocada, DATAiFX.

Esta prueba fue practicada en audiencia celebrada el 30 de noviembre de 2023.

Se decretó la práctica de interrogatorio de parte al representante legal de la llamada en garantía, SEGUROS DEL ESTADO.

Esta prueba fue practicada en audiencia celebrada el 30 de noviembre de 2023.

5.1.3. Declaración de Parte

Conforme lo permiten los artículos 165, 191 inciso final y 198 del C.G.P., se decretó la declaración de parte del representante legal de la convocante BMC BOLSA MERCANTIL DE COLOMBIA S.A.

Esta prueba fue practicada en audiencia celebrada el 30 de noviembre de 2023.

5.1.4. Testimonios

Se decretaron, de conformidad con los artículos 208 y siguientes del C.G.P. y en los términos indicados en la respectiva petición, los siguientes testimonios:

- Xxxxxxxx Xxxxx Xxxxxxxx. Esta prueba fue practicada en audiencia celebrada el 17 de noviembre de 2023.

- Xxxxxxxx Xxxxxx Xxxxxx. Esta prueba fue practicada en audiencia celebrada el 17 de noviembre de 2023.

- Xxxxxxx Xxxxxxxx. Esta prueba fue practicada en audiencia celebrada el 13 de febrero de 2024.

- Xxxx Xxxxx Xxxxx Xxxxxx. Esta prueba fue practicada en audiencia celebrada el 28 de noviembre de 2023.

- Xxxxxx Xxxxxxx Xxxxxx Xxxxxxxxx. Esta prueba fue practicada en audiencia celebrada el 28 de noviembre de 2023.

5.1.5. Dictamen Pericial

En virtud del artículo 277 del C.G.P., el Tribunal otorgó un plazo para que la convocante aportara el dictamen pericial anunciado en el memorial mediante el cual se descorrió traslado de la contestación de la demanda, así como el anunciado en el memorial que descorrió traslado de la objeción al juramento estimatorio presentada por SEGUROS DEL ESTADO.

Una vez aportado el dictamen el Tribunal corrió traslado y posteriormente en audiencia celebrada el 4 xx xxxxx de 2024, se practicó el interrogatorio de los peritos XXXXX XXXXXX XXXXXXX y XXXXXXX XXXXXX XXXXXXX.

5.1.6. Prueba por Informe

Se decretó, en los términos del artículo 275 del C.G.P, prueba por informe a cargo de INFORMÁTICA Y TECNOLOGÍA XXXXXXXXX S.A., ordenando se atendiera la solicitud de información contenida en la contestación a la demanda de reconvención, en los siguientes términos:

- “Se servirá informar entre qué fechas exactas celebró un contrato de prestación de servicios con la BOLSA MERCANTIL DE COLOMBIA S.A.

- Se servirá informar cuál fue el objeto del contrato anotado en el punto anterior.

- Se servirá informar cuál fue el resultado de la gestión que se le encomendó en desarrollo del contrato en mención”.

Esta información fue allegada al proceso el 7 de noviembre de 2023, se incorporó al expediente y fue puesta en conocimiento de las Partes.

5.2. Xxxxxxx solicitadas por la parte convocada al contestar la demanda inicial, en la demanda de reconvención, y con el escrito con el cual descorrió los traslados de las excepciones de mérito y de la objeción al juramento estimatorio.

5.2.1. Documentales

Se decretaron como pruebas, con el valor que les atribuye la ley, los siguientes documentos:

(i) Los aportados con la contestación de la demanda inicial que obran en el expediente virtual (141365_02_Pruebas_Pruebas_02_02_Pruebas_Contestación_De manda_Inicial_DATAiFX)

(ii) Los aportados con la demanda de reconvención que obran en el expediente virtual (141365_02_Pruebas_Pruebas_02_03_Demanda_De_Reconvenci ón)

5.2.2. Interrogatorio de Parte

Se decretó la práctica de interrogatorio de parte al representante legal de la sociedad convocante, BMC.

Esta prueba fue practicada en audiencia celebrada el 30 de noviembre de 2023.

5.2.3. Declaración de Parte

Conforme lo permiten los artículos 165, 191 inciso final y 198 del C.G.P., se decretó la declaración de parte del representante legal de la convocada DATAiFX.

Esta prueba fue practicada en audiencia celebrada el 30 de noviembre de 2023.

5.2.4. Testimonios

Se decretaron, de conformidad con los artículos 208 y siguientes del C.G.P y en los términos indicados en la respectiva petición, los siguientes testimonios:

- Xxxxxxxx Xxxxx Xxxxxx. Esta prueba fue practicada en audiencia celebrada el 28 de noviembre de 2023.

- Xxxxx Xxxxxxx Xxxxx Xxxxxx. Esta prueba fue practicada en audiencia celebrada el 27 de noviembre de 2023.

- Xxxxxxxx Xxxxxx Xxxxxxxxxxx Xxxxxx. Esta prueba fue practicada en audiencia celebrada el 27 de noviembre de 2023.

- Xxxxxxx Xxxxxxxxx Xxxxxx Xxxxxxxxx. Esta prueba fue practicada en audiencia celebrada el 17 de noviembre de 2023.

- Xxxxxx Xxxxxxx Xxxxxx Xxxxxxxxx. Esta prueba fue practicada en audiencia celebrada el 28 de noviembre de 2023.

5.2.5. Dictámenes Periciales

Frente a los dictámenes periciales solicitados por la parte convocada, en los términos del artículo 31 de la Ley 1563 de 2012, junto con los artículos 226 al 235 del C.G.P, y por considerar el Tribunal la prueba útil para la verificación de los hechos relacionados con las alegaciones de las partes, se decretaron en los siguientes términos:

5.2.5.1. Dictamen pericial a cargo xx xxxxxx contable, para efectos de probar el objeto de la pericia anunciada en la petición de la parte convocada.

Para tales efectos se designó como perito a XXXXXX XXXXXX XXXXXXX miembro de la lista de peritos del Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, quien tomó posesión ante el Tribunal, momento en el cual se estableció el plazo para la presentación del dictamen y los honorarios provisionales xxx xxxxxx.

Una vez aportado el dictamen el Tribunal corrió traslado y posteriormente en audiencia celebrada el 4 xx xxxxx de 2024 se practicó el interrogatorio de la perito.

5.2.5.2.Dictamen pericial a cargo xx xxxxxx en sistemas de información, para efectos de probar el objeto de la pericia anunciada en la petición de la parte convocada.

Para tales efectos se designó como perito a XXXXXX XXXX XXXXXX XXXXXXXXXXX, miembro de la lista de peritos del Centro de Arbitraje y Conciliación de la Cámara de Comercio de Bogotá, quien posteriormente fue relevado de su cargo, procediendo a designar al perito XXXX XXXXXX XXXXXX igualmente miembro de la lista de peritos del Centro de Arbitraje.

Posteriormente, mediante Auto 21 del 22 de enero de 2024 se determinó tener por desistido el dictamen pericial a cargo xx xxxxxx en sistemas de información, decretado en el numeral 2.5.2 del Auto No. 14 del 23 de octubre de 2023, con ocasión del no pago de los honorarios provisionales decretados a cargo de DATAiFX.

5.2.6. Exhibición de Documentos

Se decretó en los términos de los artículos 265 y siguientes del C.G.P, la exhibición por parte de BMC, de los documentos relacionados en la contestación a la demanda principal, esto es:

“Exhibición por parte de la BMC de las grabaciones que la misma hizo de reuniones de avance de ambos contratos, con las cuales DATAIFX estuvo de acuerdo, que fueron compartidas en su momento en un SharePoint al cual DATAIFX ya no tiene acceso”.

Los anteriores documentos fueron incorporados al expediente, luego de surtido el procedimiento establecido por el Tribunal para su exhibición.

5.2.7. Prueba por Informe

Se decretó, en los términos del artículo 275 del C.G.P, informe a cargo de INFORMÁTICA Y TECNOLOGÍA XXXXXXXXX S.A., ordenando se atendiera la solicitud de información contenida en la contestación a la demanda de reconvención, en los siguientes términos:

“Se servirá informar cuál fue el resultado de la gestión que se le encomendó en desarrollo del contrato en mención”.

Esta información fue allegada al proceso el 7 de noviembre de 2023, se incorporó al expediente y fue puesta en conocimiento de las Partes.

5.3. Pruebas solicitadas por la llamada en garantía, SEGUROS DEL ESTADO S.A. al contestar la demanda inicial y el llamamiento en garantía.

5.3.1. Documentales

Se decretaron como pruebas, con el valor que les atribuye la ley, los siguientes documentos:

Los aportados con la contestación de la demanda inicial y del llamamiento en garantía que obran en el expediente virtual (141365_01_Principal_Principal_02_32_Contestación_Seguros_Del_E stado)

5.3.2. Interrogatorios de Parte

Se decretó la práctica de interrogatorio de parte al representante legal de la sociedad convocante, BMC.

Se decretó la práctica de interrogatorio de parte al representante legal de la sociedad convocada, DATAiFX.

Estas pruebas fueron practicadas en audiencia celebrada el 30 de noviembre de 2023.

5.3.3. Exhibición de Documentos

Se decretó en los términos de los artículos 265 y siguientes del C.G.P., la exhibición por parte de BMC, de los documentos relacionados en la contestación a la demanda principal por parte de SEGUROS DEL ESTADO S.A., esto es:

“4.4.1.1. El o los documentos contentivos de los requerimientos, correos electrónicos, comunicaciones, cartas, correspondencia que se haya cruzado Bolsa Mercantil de Colombia con la sociedad de DATAIFX SAS, su representante legal o cualquiera de sus funcionarios , desde el 25 xx xxxx de 2020 a la fecha, con ocasión del Contrato de Prestación de Servicios Tecnológicos No. CO-2020-0060.

4.4.1.2. Las certificaciones de cumplimiento expedidas por la Bolsa Mercantil de Colombia con ocasión de la ejecución del Contrato de Prestación de Servicios Tecnológicos No. CO-2020-0060

4.4.1.3. Los comprobantes de pago de las sumas canceladas por la BMC a DATAIFX SAS con ocasión de la ejecución del Contrato de Prestación de Servicios Tecnológicos No. CO-2020-0060

4.4.1.4. Las actas periódicas semanales y mensuales que con ocasión de la ejecución del de Prestación de Servicios Tecnológicos No. CO- 2020-0060 las partes suscribían o se cruzaban vía correo electrónico.

4.4.1.5. Documentos que den cuenta de la ejecución del Contrato de Prestación de Servicios Tecnológicos No. CO-2020-0060

4.4.1.6. El o los documentos contentivos de los requerimientos, correos electrónicos, comunicaciones, cartas, correspondencia que se haya cruzado Bolsa Mercantil de Colombia con la sociedad de DATAIFX SAS, su representante legal o cualquiera de sus funcionarios, desde el 04 de noviembre de 2020 a la fecha, con ocasión del Contrato Marco de Servicios Tecnológicos No. 2020-0051

4.4.1.7. Las certificaciones de cumplimiento expedidas por la Bolsa Mercantil de Colombia con ocasión de la ejecución del Contrato Marco de Servicios Tecnológicos No. 2020-0051

4.4.1.8. Los comprobantes de pago de las sumas canceladas por la BMC a DATAIFX SAS con ocasión de la ejecución del Contrato Marco de Servicios Tecnológicos No. 2020-0051

4.4.1.9. Las actas periódicas semanales y mensuales que con ocasión de la ejecución del Contrato Marco de Servicios Tecnológicos No. 2020 - 0051, las partes suscribían o se cruzaban vía correo electrónico.

4.4.1.10. Documentos que den cuenta de la ejecución del Contrato Marco de Servicios Tecnológicos No. 2020-0051”.

Respecto de esta información, en memorial de fecha 3 de noviembre de 2023, la BMC manifestó “revisada la documentación completa, encontramos que toda la que tiene relación con los hechos que la llamada en garantía pretende demostrar enunciados en la petición de la prueba, ya obra en el expediente y por tanto no hay más documentos que aportar”.

Con base en lo anterior, en Auto No. 16 del 17 de noviembre de 2023, el Tribunal ordenó a BMC que procediera a identificar de manera precisa los documentos que obraban en el expediente virtual y que según lo indicado en el memorial del 3 de noviembre de 2023 correspondían a aquellos cuya exhibición se ordenó a favor de la llamada en garantía.

El 22 de noviembre de 2023, el apoderado judicial de BMC presentó memorial en el cual manifiesta dar cumplimiento a lo ordenado por el Tribunal en Auto No. 16 del 17 de noviembre de 2023, por lo que mediante Auto No. 19 del 27 de noviembre de 2023, el Tribunal dispuso correr traslado a la llamada en garantía del memorial presentado por la BMC.

Dentro del traslado otorgado, la Llamada en Garantía, manifestó “Respecto de las demás manifestaciones, para todos los efectos, y en atención al principio de la buena fe, damos por cierto, que los documentos allegados ya al plenario son los únicos con los que cuenta la parte demandante”.

6. ALEGATOS DE CONCLUSIÓN:

La audiencia de alegatos de conclusión se celebró el (8) xx xxxxx de dos mil veinticuatro (2024), en la que los apoderados judiciales de las partes presentaron oralmente sus alegaciones finales y presentaron una versión escrita de los mismos conforme se advierte en el Acta No. 20.

7. TÉRMINO DE DURACIÓN DEL PROCESO:

Según el artículo 10 de la Ley 1563 de 2012 si en el pacto arbitral no se señalare término para la duración del proceso, este será de seis meses, contados a partir de la finalización de la primera audiencia de trámite, lapso en el que deberá proferirse y notificarse, incluso, la providencia que resuelve la solicitud de aclaración, corrección o adición.

En el presente caso, la primera audiencia de trámite finalizó el día veintitrés

(23) de octubre de dos mil veintitrés (2023), fecha a partir de la cual inició el

cómputo del mencionado término para proferir el laudo arbitral o la providencia que aclare, corrija o adicione.

Al respecto, si bien el término vencería el veintitrés (23) xx xxxxx de dos mil veinticuatro (2024), en virtud de lo establecido en el artículo 11 de la Ley 1563 de 2012, al término del proceso se adicionarán los días de suspensión, así como los de interrupción por causas legales.

Conforme a lo anterior, al término del proceso se adicionan los días hábiles durante los cuales el proceso estuvo suspendido, conforme se relaciona a continuación:

- Mediante Auto No. 20 del 30 de noviembre de 2023, por solicitud de las partes y en los términos del artículo 11 de la Ley 1563 de 2012, se decretó la suspensión del proceso durante 23 días hábiles, esto es, entre el 15 de diciembre de 2023 y el 19 de enero de 2024, ambas fechas inclusive.

- Mediante Auto No. 26 del 4 xx xxxxx de 2024, por solicitud de las partes y en los términos del artículo 11 de la Ley 1563 de 2012, se decretó la suspensión del proceso durante 21 días hábiles, esto es, entre el 5 xx xxxxx de 2024 y el 5 xx xxxxx de 2024, ambas fechas inclusive.

- Mediante Auto No. 27 del 8 xx xxxxx de 2024, por solicitud de las partes y en los términos del artículo 11 de la Ley 1563 de 2012, se decretó la suspensión del proceso durante 37 días hábiles, esto es, entre el 9 xx xxxxx de 2024 y el 31 xx xxxx de 2024, ambas fechas inclusive.

De esta manera, a la duración del trámite arbitral, se adicionan los 81 días hábiles durante los cuales el proceso ha estado suspendido, en virtud del inciso 3° del artículo 11 de la Ley 1563 de 2012, por lo que el término de duración del presente proceso arbitral se extiende hasta el 23 xx xxxxxx de 2024.

Así las cosas, el presente laudo arbitral es proferido dentro del término señalado en la ley.

II. CONSIDERACIONES DEL TRIBUNAL

1. DEL CUMPLIMIENTO DE LOS PRESUPUESTOS PROCESALES:

De entrada, ha de acotarse la presencia de los presupuestos procesales necesarios para que el litigio pueda ser decidido en el fondo. En efecto, el Tribunal es competente para decidir sobre las pretensiones que delimitó en la audiencia que fijó su competencia; se evidencia la capacidad de las Partes y la Llamada en Garantía, para ser parte y para comparecer al proceso; la demanda introductoria del proceso, la de reconvención y el llamamiento en

garantía, reúnen los requisitos mínimos xx xxx y, aunado a ello, no se advierte vicio que deba ser declarado de oficio.

2. ANÁLISIS DEL CASO EN ESTUDIO:

1. Conducta de las partes

El artículo 280 del Código General del Proceso, establece en la parte final de su inciso primero que “el juez siempre deberá calificar la conducta procesal de las Partes y, de ser el caso, deducir indicios de ellas”.

En el caso que ocupa al Tribunal las partes y sus respectivos apoderados tuvieron un comportamiento ceñido a la ética y a las prácticas de buena conducta procesal, lealtad y respeto que eran de esperarse de unas y de otros, defendieron sus posiciones a través de los mecanismos legales y que tuvieron a su disposición durante el trámite. Cada una de ellas participó activamente en la práctica y contradicción de la prueba, interviniendo oportunamente en el proceso.

En consecuencia, no cabe censura o reproche alguno, y menos la deducción de indicios en su contra.

2. Alcance y naturaleza de los Contratos definidos entre DATAiFX y BMC

Procede el Tribunal, en primer lugar, a fijar el alcance y naturaleza de los contratos definidos entre DATAiFX y BMC para el desarrollo de los programas de ordenador (SOFTWARE) denominados REFACTORING y BACKOFFICE, según fueron bautizados por ellas mismas, a partir de lo previsto en los convenios suscritos, particularmente en relación con su objeto, la responsabilidad y riesgos asumidos, sin entrar en este punto a hacer un análisis pormenorizado de las obligaciones contraídas por cada parte, que se llevará a cabo más adelante, cuando se verifique lo relativo a su ejecución.

Lo anterior, a partir de unas transcripciones pertinentes de los documentos suscritos entre las partes, que permitirán enmarcar tales aspectos contextuales, según se detalla enseguida.

Es así como en el Contrato de Prestación de Servicios Tecnológicos para el análisis, diseño y desarrollo de la solución tecnológica para el proyecto Back Office, No CO-2020-0060, se expresó:

“PRIMERA. DEFINICIONES.

“LLAVE EN MANO”: Este tipo de Contrato conocido también en su denominación inglesa como “turnkey contract”, es aquel en que DATAiFX se obliga frente al cliente o contratante, a cambio de un precio, a concebir, construir y poner en funcionamiento una obra determinada. En este tipo de Contrato el énfasis ha de ponerse en la

responsabilidad global que asume DATAiFX frente al cliente para la entrega de la Solución Tecnológica. Se trata de la modalidad de Contrato solicitada por la BOLSA a DATAiFX y que para los efectos del presente Contrato significa que en su ejecución deberán ser respetados tanto los valores como los tiempos propuestos por DATAiFX para la ejecución de las actividades descritas en la Invitación, los cuales son fijos. DATAiFX , acepta y se obliga a la prestación de estos servicios a través de esta modalidad contractual. Esta modalidad fue aceptada expresamente por DATAIFX el día 3 de septiembre de 2020”.

“SCRUM” Proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar de manera colaborativa y en equipo para obtener el mejor resultado posible de un proyecto. En Scrum se realizan entregas parciales y regulares del producto final” (negrilla al margen del texto).

“SEGUNDA. -OBJETO: DATAIFX se obliga para con LA BOLSA a ejecutar, bajo la modalidad de un Contrato Llave en Mano, el Proyecto Back Office, de conformidad con las condiciones señaladas en el presente Contrato, así como en la Invitación y en la Propuesta, las cuales forman parte integral del Contrato. PARÁGRAFO: En desarrollo del objeto contratado, DATAIFX adelantará todas las gestiones necesarias para la ejecución y correcta prestación de los servicios. DATAIFX acepta la aplicación de las multas y sanciones cuando la prestación del servicio no sea realizada en óptimas condiciones y dentro de los tiempos establecidos por LA BOLSA y conforme al Cronograma que hace parte integral del Contrato”.

“TERCERA. ALCANCE… DATAIFX acepta que sus obligaciones son de resultado y, por ende, no podrá eximirse del cumplimiento de las mismas, sino por fuerza mayor, caso fortuito, un incumplimiento grave de la BOLSA o por otra causal de exoneración prevista en la legislación aplicable al Contrato”.

“OCTAVA. VALOR Y FORMA DE PAGO… PARÁGRAFO TERCERO.

Teniendo en cuenta la estimación de riesgos de este Contrato y la inclusión de estos en el valor, DATAiFX expresamente reconoce que no serán procedentes reajustes, compensaciones, indemnizaciones, ni reclamos por causas o factores que se produzcan durante el desarrollo de este Contrato. Por lo anterior, DATAiFX reconoce que ha contemplado dentro de los precios pactados los impuestos y las retenciones aplicables y vigentes actualmente, y declara que es de su cargo el riesgo de que tales impuestos o retenciones se incrementen durante la vigencia del Contrato, sin perjuicio de que cualquier variación que se presente en la tarifa del Impuesto al Valor Agregado deba ser asumida por la BOLSA”.

“DÉCIMA CUARTA. -AUTONOMÍA TÉCNICA Y ADMINISTRATIVA:

DATAIFX ejecutará por su propia cuenta, bajo su total responsabilidad jurídica, con libertad, autonomía técnica y administrativa. Por consiguiente, asumirá todos los riesgos que se originen debido al cumplimiento del presente Contrato y asegurará la prestación de los servicios”.

Por su parte, en el contrato marco de servicios tecnológicos entre la BMC y DATAiFX No. CO-2020-0051, relativo al proyecto REFACTORING, en términos similares a los del contrato anterior, pero con mayor énfasis en un proceso progresivo de descubrimiento del objeto contratado, se pactó lo siguiente:

“ANTECEDENTES:

“OCTAVO. Que, como resultado de un proceso de Evaluación, y por sugerencia de un consultor contratado por la BOLSA para realizar sugerencias al respecto, se llegó a la conclusión que para el tipo de actividad solicitada por la BOLSA se requería de una propuesta "Llave en Mano" o "Turnke”, por medio de la cual no existan variaciones en los valores o tiempos propuestos. El 17 xx xxxxx de 2020, DATAiFX ratificó que su propuesta se acomodaba a este tipo de esquema contractual y en tal sentido confirmó su propuesta bajo ese entendido y extendió la vigencia de la misma”.

“PRIMERA. REGLAS DE INTERPRETACIÓN Y DEFINICIONES:

"DOCUMENTO(S) DE(L) DISCOVERY": Se trata del compendio de documentos por medio del cual DATAiFX revelará los resultados de la actividad "Análisis y levantamiento de las reglas de negocio", compuesto por el Documento de Especificaciones Funcionales, el Prototipo no funcional de Interfaz de Usuario, el Documento de Arquitectura y el Documento de Diseño detallado y las Historias de Usuario. Los Documentos del Discovery serán elaborados por DATAiFX y aprobados por la BOLSA, y serán documentos de carácter técnico que complementan tanto la Invitación, como el Contrato y por medio del cual se detalla el Alcance del Proyecto. Los Documentos del Discovery obrarán como "Anexo 4- Documentos del Discovery" del presente Contrato. La BOLSA, por medio de su área encargada del seguimiento (según se define en la Cláusula Décima) será la encargada de aprobar los Documentos del Discovery. Durante la ejecución del Contrato cualquiera de las Partes podrá proponer modificaciones a los Documentos del Discovery, sin embargo, dichas modificaciones deberán ser aceptadas expresamente y por escrito por la otra Parte, para tener efectos”.

"GERENTE DE PROYECTO- SCRUM MASTER" Es la persona

designada por la BOLSA para coordinar y dirigir el proyecto con el fin de

llevarlo a cabo dentro del plazo propuesto. Para ello deberá entre otros, gestionar una disponibilidad oportuna de los usuarios de las áreas de negocio e IT, para la aclaración del alcance de las funcionalidades y documentación técnica, en caso que se requiera; gestionar la disponibilidad oportuna de los usuarios involucrados en el Proyecto para las validaciones y autorizaciones de los documentos generados por el Proyecto; y gestionar la entrega oportuna de información, componentes o documentación técnica requeridos para el desarrollo de este Proyecto, que dependan de otro proveedor de desarrollo o área interna de la BOLSA en caso que aplique”.

"MARCO DE TRABAJO ÁGIL SCRUM": Se trata de la metodología de desarrollo que permite adaptar la forma de trabajo a las condiciones del Proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el Proyecto y su desarrollo a las circunstancias específicas del entorno, permitiendo la entrega de incrementos de producto en periodos de tiempo cortos y bajo la cual se celebra el presente Contrato. Y que para el presente Contrato significará La metodología mediante la cual el Proyecto se irá desarrollando por entregas y un proceso de creación” (negrillas al margen del texto).

"LLAVE EN MANO": Este tipo de Contrato conocido también en su denominación inglesa como ''tumkey contract”, es aquel en que el contratista se obliga frente al cliente o contratante, a cambio de un precio, a concebir, construir y poner en funcionamiento una obra determinada. En este tipo de Contrato el énfasis ha de ponerse en la responsabilidad global que asume el contratista frente al cliente para la entrega de la Solución Tecnológica. Se trata de la modalidad de Contrato solicitada por la BOLSA a DATAiFX y que para los efectos del presente Contrato significa que en su ejecución deberán ser respetados tanto los valores como los tiempos propuestos por DATAiFX para la ejecución de las actividades descritas en la Invitación y en los Documentos del Discovery, los cuales son fijos. DATAiFX , acepta y se obliga a la prestación del mencionado servicio a través de esta modalidad contractual.

"PROYECTO": Se entenderá como el conjunto compuesto por todas las actividades a cargo de ambas Partes, necesarias para la (i) estructuración, (ii) implementación, (iii) puesta en marcha del Refactoring, así como la ejecución de las actividades previstas en el presente Contrato y sus anexos, en las diferentes Fases previstas.

TERCERA. ~ALCANCE: Para la correcta ejecución del objeto del Contrato, se deberá tener en cuenta que se trata de un Contrato Llave en Mano, el cual se desarrollará mediante la Metodología Ágil y gestión PMI, y para su debida ejecución se tendrá en cuenta lo señalado en la Invitación, en la Propuesta, así como lo que quede consignado en el Anexo 4- Documentos del Discovery.

De acuerdo con los términos del presente Contrato, DATAiFX deberá brindar los servicios profesionales de análisis, diseño, desarrollo e implementación, bajo el Marco de Trabajo Ágil SCRUM, para cumplir con el alcance y requisitos plasmados en la Invitación a la BOLSA según resulte del Levantamiento de Información y conforme se describa de manera más minuciosa en los "Documentos del Discovery" conforme con las definiciones del Contrato y que será acordada mutuamente por las Partes. Tanto lo incluido en la invitación y la Propuesta, como lo complementado por medio de los Documentos del Discovery deberá ser desarrollado en el marco del Refactoring. Una vez concluida la Fase de Análisis de levantamiento - Reglas de Negocio. DATAiFX deberá elaborar los Documentos del Discovery con el fin de complementar y detallar el Objeto del Contrato. Los Documentos del Discovery deberán ser aprobados por la BOLSA por medio de su área técnica según se define en la Cláusula Décima.

Una vez analizados y aprobados los Documentos del Discovery por parte de la BOLSA el área encargada del seguimiento tomará las decisiones que considere del caso. La BOLSA aprobará un cronograma para el desarrollo del Proyecto (el "Cronograma"), el cual obrará como "Anexo 5

- Cronograma del Proyecto". Al firmar este Contrato, la BOLSA y DATAiFX aceptan que los Documentos del Discovery o demás negociaciones entre DATAiFX y la BOLSA que se relacionan con los Servicios, se realizarán de acuerdo con los términos establecidos en este Contrato.

XXXXxXX acepta que sus obligaciones son de resultado y, por ende, no podrá eximirse del cumplimiento de estas, sino por fuerza mayor, caso fortuito o por otra causal de exoneración prevista en la legislación aplicable al Contrato. Adicionalmente, acepta la aplicación de las multas de conformidad con lo previsto en la Cláusula Vigésima Segunda - Multas-.

SÉPTIMA. -DURACIÓN Y PLAZOS: En tanto se ha establecido que el presente Contrato se ha celebrado llave en Mano, se tiene que la estimación de los tiempos del mismo, conforme con la Invitación, la Propuesta, los Documentos del Discovery y el Cronograma, se constituye en una obligación de las Partes. En tal sentido, DATAiFX se obliga conforme al presente Contrato a que las actividades señaladas en la Propuesta respecto a la entrega de la totalidad de las Fases se realizará en un periodo de VEINTE (20) MESES contados a partir del perfeccionamiento del presente Contrato y terminando el día hábil siguiente más cercano a esa fecha. Sin embargo, la duración del presente contrato se extenderá por doce meses más, hasta la finalización del Periodo de Garantía.

OCTAVA. -VALOR, PAGOS Y FACTURACIÓN: El presente Contrato tendrá un valor fijo total de $3.475.200.000 (TRES MIL

CUATROCIENTOS SETENTA Y CINCO MILLONES DOSCIENTOS MIL

PESOS COLOMBIANOS) más IVA. En tanto se trata de un Contrato Llave en Mano, no se podrán presentar variaciones en este valor sin autorización escrita por parte de la Bolsa,

PARÁGRAFO TERCERO. Teniendo en cuenta la estimación de riesgos de este Contrato y la inclusión de estos en el valor DATAiFX expresamente reconoce que no serán procedentes reajustes, compensaciones, indemnizaciones, ni reclamos por causas o factores que se produzcan durante el desarrollo de este Contrato. Por lo anterior, DATAiFX reconoce que ha contemplado dentro de los precios pactados los impuestos y las retenciones aplicables y vigentes actualmente, y declara que es de su cargo el riesgo de que tales impuestos o retenciones se incrementen durante la vigencia del Contrato, sin perjuicio de que cualquier variación que se presente en la tarifa del Impuesto al Valor Agregado deba ser asumida por la BOLSA.

NOVENA. -CAMBIOS AL ALCANCE: Las Partes aceptan y reconocen que, con posterioridad a la elaboración de los Documentos del Discovery, durante el transcurso del desarrollo del Refactoring puede surgir la necesidad de introducir cambios al alcance del Proyecto, así como cambios regulatorios, optimizaciones, desarrollos y otras modificaciones que pudieran surgir en relación con el alcance del Proyecto. Estas situaciones se regularán mediante el siguiente procedimiento:

Las solicitudes de cambios al alcance podrán ser aprobadas o no por la BOLSA y caso que sean aprobadas serán pagadas por la BOLSA conforme a la tabla de costos establecida en el presente artículo. En cualquier caso, para que se dé inicio al desarrollo respectivo, la BOLSA deberá estar de acuerdo con lo propuesto por DATAiFX en relación con:

i) la cantidad de horas requeridas para implementar el desarrollo correspondiente al cambio, ii) los eventuales cambios del valor del Contrato y iii) los eventuales cambios en el Cronograma.

Requerimientos adicionales~BMC Valor por hora de desarrollo $125.000 Descuento 20%

$100.000

PARÁGRAFO: Una vez aprobado un cambio en el Cronograma, se implementará un nuevo Cronograma que será reconocido y aplicado por las Partes para todos los efectos, pudiendo modificar el término señalado en la Cláusula Séptima -Duración y Plazos.

De lo transcrito, se concluye entonces que las partes buscaron celebrar unos contratos de prestación de servicios, para el desarrollo y construcción de programas informáticos, según especificaciones dispuestas y aquellas que surgieran de un proceso evolutivo de descubrimiento de requerimientos y

funcionalidades, con la participación de las partes, bajo una modalidad flexible y una estructura llave en mano, con precio y plazo fijos, para obtener un resultado esperado, radicando los riesgos derivados de este proceso en cabeza de DATAIFX.

Bajo estas consideraciones, entonces resulta pertinente que el Tribunal haga algunas reflexiones sobre este alcance y los efectos que las partes definieron para llevar adelante su relación contractual, a partir de la definición de su objeto.

2.1. Objeto de los Contratos

En primer lugar, en cuanto al objeto de los contratos, fue el de producir bienes inmateriales de construcción compleja, cuyas funcionalidades y características son fundamentales para cumplir con las expectativas del usuario final y que, en consecuencia, permiten establecer el contenido de las obligaciones del contratista y considerar eventuales responsabilidades por incumplimiento o cumplimiento tardío o defectuoso.

En torno a las características de este tipo de bienes encontramos algunas referencias doctrinales que las enfatizan, como la obra escrita por el profesor español Xxxxxxx Xxxxx, que al respecto apuntó:

En primer lugar, en cuanto a la definición de programa de computador:

“Definición de software, se entiende por tal «toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático para realizar una función o una tarea o para obtener un resultado determinado, cualquier que fuere su forma de expresión o fijación».

El software es un bien intangible, fruto del ingenio humano, generalmente expresado en formato digital, que precisa de un medio material para manifestarse en el mundo externo.

Por último, el programa de ordenador puede consistir en un software standard o en un software a medida, distinción que tiene gran relevancia en su contratación” 13.

2.2. Tipo contractual, típico o atípico

Teniendo en cuenta lo especial del alcance del objeto sobre el cual recae el contrato, tal y como fue definido, la pregunta a responder es si los contratos celebrados por las partes pueden considerarse como típicos, atípicos o complejos, para determinar si están o no definidos por elementos esenciales que los estructuren o, si por el contrario, al no estar anclados en ellos su

13 Xxxxx, X. (2006). Contratos Internacionales de Software. Editorial Tirant Lo Xxxxxx, Valencia.

definición corresponde de manera absoluta a la libertad de autodeterminación de los contratantes.

En otras palabras, como lo señala el profesor Xxxxx Xxxxxx Albán14, se trata de llevar a cabo un análisis de la convención respectiva, a partir de su calificación, es decir, de la definición de si corresponde a un contrato regulado por la ley o no, de su integración, que toca con las normas que le son aplicables según la primera determinación (fuentes), y de su interpretación, etapa esta última en la cual es mayor la tarea del operador jurídico y resulta mucho más relevante lo que haya sido definido por los contratantes en la esfera de su autonomía.

De igual manera, como se ha reconocido a nivel doctrinario y jurisprudencial, en este proceso analítico el arbitrio judicial tendrá mayor relevancia entre más flexible resulte la definición de las fuentes y el límite de lo imperativo sea más liviano, para desentrañar la verdadera intención y el espíritu y finalidad que orientó la celebración del acuerdo, así como para la aplicación de reglas provenientes de los usos que surjan de la aplicación práctica de contratos que guarden semejanza con el objeto de estudio, a partir de la interacción social y económica de los agentes.

Precisamente, en cuanto a la modalidad contractual el profesor español Xxxxxxx Xxxxx, citado en el punto precedente, señala lo siguiente:

“De los contratos internacionales de software se puede predicar su carácter atípico. La razón de ello es doble.

En primer lugar, las especiales características que rodean a los programas de ordenador —carácter técnico, complejo, de naturaleza jurídica indeterminada y, sobre todo, intangible— llevan a las partes a rehuir los esquemas contractuales clásicos y a otorgar a sus relaciones, en virtud de la autonomía de la voluntad, una configuración especial alejada de los tipos previstos en la ley. En algunos supuestos, el desconocimiento por las partes del Derecho les puede llevar a otorgar a sus relaciones jurídicas una calificación que no se corresponde con lo que establece la ley. El aplicador jurídico debe evitar confusiones pues las relaciones contractuales no son lo que las partes deciden sino lo que la ley dice que son. (negrillas del Tribunal).

En segundo lugar, los operadores económicos tienden a utilizar modelos contractuales exportados de otros ordenamientos, generalmente sistemas de Common Law, para la contratación de software. En unas ocasiones, la utilización de estos modelos es debida a que las partes entienden que se adaptan mejor al objeto del contrato. En otras, se debe a la propia dinámica del comercio internacional actual en el que los destinatarios del software son personas domiciliadas en distintos

14 Xxxxxx Xxxxx, X. (2024). El Contrato. Editorial Tirant Lo Xxxxxx.

Estados. La utilización de un mismo modelo contractual permite a los proveedores informáticos reducir costos económicos y de información. A pesar de no tener un reconocimiento legal, estos contratos gozan de carta de naturaleza jurídica en nuestro ordenamiento gracias a la práctica comercial y jurisprudencial: son socialmente típicos pero legalmente atípicos. Esto no exime, sin embargo, de la necesidad de acoplar estas figuras a los tipos legales existentes en el Derecho del foro para determinar su régimen jurídico.

Cuestión distinta de la atipicidad, aunque íntimamente relacionada, es la interrelación del contrato internacional de software con otros contratos informáticos. La adquisición de un programa de ordenador puede realizarse en solitario o puede estar englobada dentro de una operación mediante la cual el proveedor informático se compromete a satisfacer un conjunto o la totalidad de las necesidades informáticas de una empresa. Ejemplos de estas operaciones informáticas complejas vienen constituidos por el contrato de integración de sistemas, el Turn-Key Contract o contrato llave en mano, el Outsourcing informático, el contrato de Facilities Management o, el más moderno, Application.Service Provisioning.

Estas operaciones informáticas complejas pueden presentar dos estructuras: a) un contrato complejo, en el que las obligaciones que nacen del contrato vinculen a todas las partes participantes entre sí y en el que existe un equilibrio contractual único; b) un contrato-grupo, en el que cada una de las prestaciones se lleva a cabo a partir de un contrato autónomo con lo que, al final, se trata de una pluralidad de contratos entre las mismas partes que, debido a la finalidad económica común que los une, están interrelacionados.

La constitución de un contrato complejo puede derivarse de la propia voluntad de las partes, aunque es muy frecuente que los contratantes ni siquiera se planteen si están celebrando uno o varios contratos: simplemente acomodan sus intereses en función de la finalidad perseguida y, como resultado, el contrato adquiere ese carácter. Aparte de los problemas para determinar el régimen jurídico aplicable a la relación que se deriva de la atipicidad de estas operaciones, debe tenerse en cuenta que la invalidez, cumplimiento defectuoso o inejecución de una de las prestaciones afecta a la totalidad del contrato. Contrato internacional de desarrollo de software a medida (Bespoke software, Contrat de développement de logiciel spécifique). Es aquél en el que una empresa informática se obliga a elaborar un programa de ordenador, siguiendo las indicaciones de la empresa cliente, para que cumpla unas funciones específicas.

Se trata de un contrato en que la autonomía de la voluntad material de las partes y los tratos preliminares juega un papel importante en atención a la relevancia económica que puede adquirir y el carácter

eminentemente técnico de su objeto. En esta fase se plasman, a través del «cuaderno de especificaciones funcionales», las funciones y características que debe cumplir el programa de ordenador. Gracias a este «cuaderno», en cuya elaboración ambas partes deberán colaborar, quedará fijado el objeto del contrato y podrá determinarse el grado de cumplimiento de la prestación por el proveedor informático. Asimismo, es un contrato intuitu personae en el sentido en que programador y empresa cliente deberán colaborar estrechamente para el buen fin del contrato. De hecho, con carácter accesorio, la empresa software se puede comprometer a prestar servicios de mantenimiento y de adaptación del programa de ordenador una vez elaborado.

La gran relevancia que, por lo general, tienen estos contratos y su complejidad técnica llevan a las partes a autorregularlos de manera pormenorizada. (negrillas del Tribunal).

En estos contratos, la prestación del servicio consiste en la elaboración de un programa de ordenador específico, encargado por la empresa cliente, o bien la adaptación de uno ya existente. Aunque, resulta discutido si el desarrollo o modificación del software debe ser calificado como un contrato de ejecución de obra o como un arrendamiento de servicios, ambos supuestos constituyen una prestación de servicios” 15.

Precisamente, respecto del último punto de la transcripción anterior, a partir de la interpretación de los artículos 2.063 y 2.064 del Código Civil, nuestro régimen legal ordena aplicar al contrato de arrendamiento de servicios inmateriales varias disposiciones del contrato de obra, generando un régimen común cuando se trata precisamente de obras inmateriales en las cuales predomina la inteligencia sobre la mano de obra, como en la realización de una composición literaria o en la construcción de un programa lógico de computador.

De todas maneras, de la relación contractual que surgió entre la BMC y DATAiFX, que el Tribunal califica como compleja, al tomar notas propias de los contratos de prestación de servicios y de obra, así como elementos derivados de la voluntad de las partes y del esquema que consideraron apropiado para cumplir con su propósito, para los efectos de lo que se debe decidir es evidente que surgen principalmente obligaciones de hacer, sin perjuicio de las prestaciones de entrega que, como en la elaboración de un software o programa de computador, puedan resultarles inherentes, tal y como se reconoció en los convenios celebrados, en los cuales se dio cuenta de cuáles eran los entregables que debían ser puestos a disposición de La Bolsa.

Como complemento de lo dicho, teniendo en cuenta esa naturaleza, el Tribunal para las decisiones que adoptará, a partir de las normas que lo regulan y a los criterios adoptados por la doctrina, concluye que este tipo de contrato tiene las

15 Xxxxx, X. (2006). Contratos Internacionales de Software. Editorial Tirant Lo Xxxxxx, Valencia

siguientes características: Es bilateral, oneroso, conmutativo, consensual y de ejecución sucesiva, según la forma en que se cumple con su objeto.

2.3. Alcance del Contrato llave en mano

Desde otro punto de vista, en un laudo internacional al cual se refirió la sentencia proferida por la Corte Suprema de Justicia, al resolver el recurso de anulación formulado por Puerto Brisa S.A., con soporte en las causales previstas en los literales c) y d) del numeral 1º del artículo 108 de la Ley 1563 de 2012, del 16/12/2021, con radicado número 11001-02-03-000-2021-00697- 00, ponente Xxxxxxx Xxxxxxx Xxxxxxx Xxxxx), se hizo un análisis pormenorizado del contrato denominado “llave en mano”, que aunque derivadas de una controversia con ese carácter internacional, no por ello dejan de ser aplicables en el escenario interno, ante la poca literatura que a nivel nacional se encuentra sobre este tema.

“Elementos del contrato bajo la modalidad “llave en mano”:

En primera medida, es menester para este panel indicar que los contratos “llave en mano” o "turnkey contract" o “ clé en main”, son aquellos contratos en los que “(…) el contratista se obliga frente al cliente o contratante, a cambio de un precio, a concebir, construir y poner en funcionamiento una obra determinada que él mismo previamente ha proyectado”, es decir, el contratista tiene la obligación “(…) de entregar un producto plenamente terminado y en marcha”. Así las cosas, el contratista asume una responsabilidad global frente al cliente, comoquiera que en estos contratos el contratante transfiere la totalidad de los riesgos inherentes al contrato al contratista.

Este tipo de contratos se denomina precisamente “llave en mano”, toda vez que “(…) el contratista desarrolla, dirige y emprende el proyecto y, al finalizarlo, lo entrega y el mandante, por su parte, recibe "la llave" de la obra, a la espera de la entera satisfacción del mandante o comitente que la encarga”.

En consecuencia, se han identificado dos rasgos esenciales de los contratos "llave en mano", a saber: “a) la fusión de las actividades xx xxxxxxxxxx y ejecución de la obra en una sola persona, y b) la obligación global asumida por el contratista frente al cliente de entregar una obra completamente equipada y en perfecto estado de funcionamiento”.

En adición a los rasgos esenciales antes mencionados, resulta posible resaltar las siguientes características o elementos principales de los contratos bajo la modalidad llave en mano:

La obligación del contratista consiste, en suma, en “(…) entregar una obra completamente equipada y en estado de funcionamiento”, dada su especialidad. Lo anterior implica entonces que, por su parte, el

contratante “(…) se debe concentrar exclusivamente en el financiamiento de las obras, asumiendo como obligación esencial la de entregar, en forma oportuna, el pleno y oportuno acceso a los terrenos o las servidumbres (sin retardo) y toda la información disponible concerniente al expedito acceso a los mismos y del lugar donde se emplazará la obra”.

La autonomía del contratista sobre el desarrollo del proyecto, lo cual “(…) implica a su vez una pérdida de control sobre el proyecto por parte del cliente y una reducción considerable en las funciones del ingeniero que en este tipo de contratos actúa generalmente como representante del cliente, siendo posible incluso en los casos más extremos que se prescinda de su participación”. Así las cosas, “(…) la intervención del mandante es mínima ya que el ingeniero y las instrucciones que transmite por cuenta de quien representa, se limitan a "funciones de vigilancia respecto de la adecuada ejecución de la obra"”. Sin perjuicio de todo lo anterior, el contratista emprende la obra “(…) en la medida en que se cumpla con todos los presupuestos de la modalidad contractual que se elija, esto es, que se asegure el acceso oportuno a los terrenos donde se va a emplazar; que la información sea fidedigna y que el objeto de la misma no experimente modificaciones ni aumentos de obras en su desarrollo y ejecución que requieran de una mayor extensión”.

Ahora bien, sin perjuicio de las características indicadas, doctrinalmente se ha considerado que la tipología de llave en mano no se deriva de la existencia de una cláusula o disposición contractual que así expresamente lo disponga, comoquiera que dicha característica proviene de la integralidad del clausulado acordado por las partes, y del alcance de las prestaciones obligacionales definidas por ellas, bien expresamente o configuradas por su comportamiento contractual. (Negrilla del Tribunal).

2.4. Contrato a precio global fijo

En cuanto a los contratos a precio global fijo y la alternativa de generar modificaciones o adiciones que afecten la estructura económica sobre la cual se construyó el contrato, el profesor Xxxxxxxx Xxxxx, al aludir a citas de otros autores que se han ocupado de este tipo de asuntos, resalta:

“En Colombia, algunos han señalado que debe distinguirse el contrato de obra a precios unitarios y el contrato a precio global. A tal efecto se ha indicado que, en el contrato a precios unitarios, el contratante puede introducir modificaciones a los planos y a las obras contratadas, sin que el contratista se pueda oponer, porque por la naturaleza del contrato tiene derecho a que esas mayores obras se las paguen por separado. Por el contrario, se señala que en el contrato a precio global fijo:

“El contratante no puede introducir ninguna modificación a la obra o a los planos, pues habiéndose establecido un precio global único e inmodificable, resultaría a todas luces inequitativo que el contratante pudiera introducir modificaciones o adiciones unilaterales a la cantidad de obra que el contratista tuvo en mente al formular su propuesta y cobijarla bajo un precio global fijo” 16.

De hecho, como un reconocimiento, tímido, pero diciente, de su real voluntad, en torno a la circunstancia de que la relación que estaban definiendo no podía enmarcarse propiamente dentro de un precio global fijo y a un plazo definido, en el contrato de Refactoring las partes incluyeron una alternativa de modificación del precio a partir del cambio en el alcance de las obligaciones del contratista, como aparece en la cláusula NOVENA antes transcrita, que para sorpresa del Tribunal no fue utilizada por ellas oportunamente, ni siquiera surgió de las pruebas recogidas un indicio en tal sentido, que no fuera la reacción del contratista, a juicio del Tribunal tardía, de plantear, tanto en el contrato de Refactoring, como en el de Back Office, un ajuste en precio y tiempo, cuya propuesta fue rechazada por la Bolsa con posterioridad a la finalización del plazo pactado para la entrega de los productos totalmente terminados.

2.5. Obligaciones de medio o resultado

Finalmente, desde el punto de vista de responsabilidad en acuerdos que conllevan obligaciones de hacer, como los que han sido definidos entre DATAiFX y la BMC, las partes pueden responder por el incumplimiento o inejecución de sus obligaciones hasta el grado de la culpa leve, por su carácter conmutativo y bilateral (artículos 63 y 1.604 del Código Civil), salvo disposición contractual en contrario, que permiten eximirse de la inejecución con la simple observancia de la diligencia y el cuidado debidos.

A su turno, en relación con aquellas que puedan conllevar prestaciones de resultado, en cuanto a la entrega de un bien o producto final fruto de la prestación de los servicios contratados, la exoneración estará atada al rompimiento del nexo causal a través de la prueba de la fuerza mayor, del caso fortuito, del hecho de un tercero o de la culpa exclusiva de la misma contraparte.

Precisamente, frente a las obligaciones de resultado, encontramos que cuando se pacta una obligación de este tipo el deudor asume todos los riesgos previsibles que pueda incidir en que la ejecución de la prestación se torne más difícil o costosa.

Es así que, como ocurre en la contratación estatal, la asignación de estos riesgos a partir de generar un lineamiento con el descrito, surge de la definición de quien, por su experticia, conocimiento, capacidad operativa, patrimonial o

16 Xxxxxxxx Xxxxx, X. (2021). Contratos. Editorial Legis, Bogotá.

financiera, pueda evaluarlos, controlarlos, administrarlos, mitigarlos y prevenirlos.

En tal sentido, de preferencia los riesgos los debe asumir aquel que puede tomar las medidas para evitar que se produzcan o que pueda asegurarlos de mejor manera.

En torno a este tema, el profesor Xxxxxxxx, en la obra antes referida, señala lo siguiente:

“Xxxxxxx, quien fue el autor de la clasificación de las obligaciones, de medio y de resultado, distinguía si el objeto era prestar los servicios propios de una profesión liberal o no. En el primer caso, la obligación era de medio y en el segundo, de resultado. Sin embargo, es claro que en cada caso puede haber obligaciones de medio o resultado. En efecto, el ingeniero que diseña un edificio tiene una obligación de resultado.

Sin embargo, existe otro criterio que ha sido adoptado por parte de la doctrina y jurisprudencia, que parece más claro el cual se funda en la previsibilidad del resultado.

En efecto, cuando con los medios normalmente empleados se obtendría el resultado, debe entenderse que la obligación es de resultado, pues es de presumir que las partes quisieron que se lograra el resultado. Por el contrario, si empleando los medios normales no se podría garantizar el resultado la obligación sería de medio” 17.

De manera similar, la Corte Suprema de Justicia, Sala de Casación Civil, en sentencia del 5 de noviembre de 2013, radicado número 20001-3103-005- 0000-00000-00, citada por el mencionado autor, señaló en cuanto a la definición de este tipo de obligaciones:

“El criterio más aceptado para distinguir uno y otro tipo de obligación se encuentra en la incidencia que en el concepto de cumplimiento pueda tener el que con la conducta debida se realice el interés primario del acreedor, es decir, que éste efectivamente obtenga el resultado útil o la finalidad práctica que espera lograr”.

Así mismo, para definir el alcance de la obligación cuando de este tipo de contratos se trata, hay que partir de la base de que la obra contratada debe realizarse o el servicio prestarse cumpliendo con las reglas de la ciencia o del arte involucrados, en este caso, de aquella que se ocupa precisamente de la construcción de programas lógicos de computador.

Sobre este particular, el mismo profesor Xxxxxxxx, citando x Xxxxxxx define el tema así:

17 Ibid.

“……el comportamiento técnico apropiado accesible al conjunto del cuerpo profesional y cuya aplicación corresponde al estado de la técnica al realizar el acto. El experto debe tener conocimientos actualizados, pues el servicio debe ser conforme a las reglas del arte cuando se realiza el acto”.

2.6. Conclusiones iniciales

En síntesis, de lo analizado en esta primera parte xxx xxxxx, en cuanto al contexto dentro del cual se debe resolver la controversia, se puede concluir que el marco contractual que las partes quisieron darle a sus relaciones jurídicas, se desdibujó, en la medida en que no se trató propiamente de un contrato llave en mano a precio global fijo, por las varias formas en que el contratante pudo incidir en su alcance y en la definición del producto final.

Por su parte, los riesgos por su ejecución no podían recaer totalmente en una de las partes y, aunque se podían exigir responsabilidades inherentes a obligaciones de resultado, su marco y alcance dependía de actividades posteriores a la celebración del contrato a las cuales debían concurrir las partes, al no estar totalmente definidas las funcionalidades y características del software que iba a construirse, lo que dependía en buena parte de definiciones que estaban destinadas a ser perfiladas a lo largo de su ejecución bajo una metodología flexible, ágil o scrum, como lo informa la copiosa prueba documental y testimonial que se recogió a lo largo del proceso, tal y como se podrá desglosar de manera detallada en los siguientes apartes xxx xxxxx.

Al punto, el Tribunal trae nuevamente la cita textual en relación con el alcance de esta metodología: “Proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar de manera colaborativa y en equipo para obtener el mejor resultado posible de un proyecto”.

Mejor resultado posible obtenido a partir de un trabajo colaborativo y en equipo lleva el asunto a un escenario diametralmente diferente a aquel dentro del cual las partes pretendieron enmarcar su relación contractual.

Se trató entonces de sendos contratos que dieron pie a una relación de confianza y xx xxxxx colaboración, que exigía en las partes un alto grado de comunicación e interacción, para construir, en el caso del contrato Back Office, y de reconstruir, en el caso del Refactoring, unas plataformas y programas que permitieran ejecutar múltiples funciones operativas, administrativas y comerciales, en torno a las actividades principales de la Bolsa y de sus aliados, los comisionistas de Bolsa, bajo funcionalidades y requerimientos de usuario que debían ser definidos durante la ejecución misma de los contratos.

En tal sentido, entonces, se reitera, no fue apropiado acudir a un modelo económico contractual de precio fijo, como tampoco partir del supuesto de un tiempo máximo de ejecución, ni colocar en cabeza del contratista la totalidad de los riesgos a partir de la definición de obligaciones de resultado perfilado

de manera previa, para el cumplimiento de prestaciones cuyo objeto y alcance final debían ser definidos posteriormente a la celebración de los acuerdos.

Para el Tribunal fue irresponsable, particularmente en lo que toca con la conducta y comportamiento precontractual del contratista, experto y profesional en la ejecución de este tipo de actividades, e igualmente no correspondió con lo esperado de un profesional diligente y cuidadoso en el desarrollo de este objeto, el comprometerse bajo un esquema contractual como el escogido y asumir o exponerse conscientemente a riesgos que de antemano era previsible que podían fácilmente materializarse, como en efecto ocurrió, circunstancia que igualmente será ponderada por el Tribunal para la adopción de las decisiones que resuelvan la controversia planteada, tanto en la demanda inicial, como en la reconvención.

Resalta el Tribunal que tanto la BMC como DATAiFX, son sociedades comerciales debidamente inscritas en el registro mercantil y adicionalmente son reconocidas y así está demostrado en el proceso, con una amplia trayectoria en el campo comercial y por ello, no cabe duda alguna que se trata de dos profesionales, de la clasificación de los comerciantes, tanto desde el punto de vista subjetivo (Art 19 No 1 del C.Cio) sino y muy especialmente, desde el punto de vista objetivo. (Art 10 ibidem).

Esta especial cualificación en la parte contratante y contratista les impone unos deberes de conducta, denominadas cargas, y desplegar entre otras conductas, las de diligencia, cuidado, sagacidad, previsión y claridad en la celebración de los negocios jurídicos entre ellas ajustados, –acto dispositivo de intereses particulares-, en especial en la modalidad de contratos, a cuyo texto el artículo 864 del C.Cio dispone: “El contrato es un acuerdo de dos o más partes para constituir, regular o extinguir entre ellas una relación jurídica patrimonial, y salvo estipulación en contrario, se entenderá celebrado en el lugar de residencia del proponente y en el momento en que éste reciba la aceptación de la propuesta. Se presumirá que el oferente ha recibido la aceptación cuando el destinatario pruebe la remisión de ella dentro de los términos fijados por los artículos 850 y 851.” En concordancia con el artículo 1.602 del Código Civil Colombiano, según el cual “El contrato es una ley para las partes”.

De otro lado, estamos en presencia de un contrato complejo, en buena parte atípico, es decir, que no encuentra una descripción expresa y completa en la legislación colombiana y por ello debemos atenernos a la denominada tipicidad social, como se ha sostenido previamente, pero poniendo énfasis en las disposiciones contractuales ajustadas entre las partes, en ejercicio de la autonomía de la voluntad, de conformidad con lo previsto en el artículo 4 del C.Cio, según el cual “Las estipulaciones de los contratos válidamente celebrados preferirán a las normas legales supletivas y a las costumbres mercantiles.”

Para finalizar este análisis preliminar, en torno a la actitud de las partes al momento de estructurar el contrato, el profesor Xxxxxx Xxxxxxx Xxxxxxx, al

hablar del llamado deber de sagacidad que tiene que observar cada parte para la construcción del mejor contrato posible, indicó que debe estar acorde con su objeto y con el interés positivo de alcanzarlo, logrando el beneficio esperado para cada uno de los contratantes, que en el caso bajo examen brilló por su ausencia.

Dice el profesor Xxxxxxx:

“Al lado del deber de buena fue en los negocios jurídicos, se invoca uno denominado de “sagacidad”, que algunos llaman de “diligencia”, consistente en que cada parte debe ocuparse de estudiar debidamente los intereses que la llevan a contratar, buscar la información que se requiere para hacerlo en las mejores condiciones y tratar de llegar a la mejor posición que le sea posible en el respectivo acuerdo de voluntades. Teniendo en cuenta que cada una de las partes al obligarse busca unas consecuencias que le interesan, según los defensores de este principio, a cada una de ellas le corresponde el deber de estar atenta para lograr el resultado al cual aspira…”18.

3. Incumplimientos imputados al contratista

3.1. Contrato de Back Office

3.1.1. Posición de las partes

Solicita la Convocante en su Pretensión Primera Principal “Que se declare que la sociedad DATAIFX incumplió parcialmente lo pactado en el Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060, celebrado entre la BMC y DATAIFX, según se relatará en los hechos de la presente demanda”.

En la Pretensión Segunda Principal la BMC solicita “Que se declare que la sociedad DATAIFX incumplió su obligación de “GARANTÍA” pactada en la CLÁUSULA VIGÉSIMA del Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060 celebrado entre la BMC y DATAIFX, según la definición y durante el “PERÍODO DE GARANTÍA” determinado en la CLÁUSULA PRIMERA del Contrato, según se relatará en los hechos de la presente demanda”.

Como fundamento de su solicitud, en los hechos de la demanda la Convocante hace un recuento de los antecedentes del Contrato de Back Office, de su suscripción así como de algunas definiciones contenidas en el mismo. Frente a estos primeros hechos (1 al 35) la Convocada en su contestación de la demanda manifiesta que son ciertos.

18 Xxxxxxx Xxxxxxx, X. (2020). Obligaciones. Editorial Temis, Bogotá.

Más adelante, en los hechos relativos a la ejecución del Contrato de Back Office la Convocante hace referencia a requerimientos por parte de la BMC a DATAiFX sobre incidencias reiterativas encontradas en el aplicativo LEO, mejoras que debían ser implementadas y la construcción de historias de usuario.

Adicionalmente, la BMC se refirió a correos electrónicos enviados entre el 22 de noviembre de 2021 al 29 xx xxxxx de 2022 relacionados con defectos en los módulos de Vinculación y LEO que no fueron ajustados por DATAiFX “incumpliendo nuevamente con el compromiso adquirido”.

Así mismo la Convocante manifiesta que terminado el Contrato por expiración del término, DATAiFX no entregó la totalidad de los productos acordados en el Contrato y tampoco cumplió con su obligación de garantía.

La Convocada al contestar la demanda manifestó que el módulo LEO fue ajustado en cumplimiento con el soporte del mismo. También señaló que el 22 xx xxxxx de 2022 DATAiFX le entregó a la BMC los ítems trabajados, ajustados y desplegados en ambiente QA así como cuatro Hojas de Usuario distintas al alcance del proyecto.

Adicionalmente anotó que, no obstante el Contrato terminó por expiración del término, XXXXxXX trabajó seis meses adicionales sin recibir contraprestación alguna.

Así mismo se refirió a las garantías establecidas en el Contrato y diferenció la garantía posterior a la terminación del Contrato, de la garantía que se debía prestar frente a los módulos objeto de certificación durante la ejecución del Contrato.

Finalmente, manifestó que no es cierto que DATAiFX haya admitido no haber cumplido con las prestaciones a su cargo y adujo incumplimientos por parte de la BMC en la definición del alcance de los módulos lo cual la exime de cualquier obligación.

3.1.2. Consideraciones del Tribunal

Según las pruebas aportadas al expediente, la BMC elaboró documento denominado “Requerimiento de Sistemas de Información, Bienes o Servicios Tecnológicos” de fecha 15 de noviembre de 201919 (RFP o Invitación) en el que definió el objetivo del Proyecto de Back Office y las actividades principales para su desarrollo.

El objetivo principal del Contrato Back Office según el RFP era “desarrollar una plataforma robusta e integrada, que contemple las actividades de apoyo y gestión del negocio, para Sociedades Comisionistas Miembros de Bolsa -

19 Expediente Virtual 141365 – 02 Pruebas – Pruebas_02 – 00_Demanda – Pruebas Documentales - 4.2.Back Office

– 4.2.1. Proyecto_ Back_Office_SCB_General_v1.pdf

SCB, que les permita tener el correcto funcionamiento de sus empresas y el fortalecimiento del Core.”

Para el desarrollo del Proyecto el documento definió las actividades principales las cuales se verían reflejadas en diferentes módulos así:

- Parámetros del sistema: i.) Administración perfiles roles y permisos, ii.) Administración de usuario, iii.) Consulta de Usuarios.

- Vinculación (Clientes, Comerciales, Operativos): i.) Registro de visitas, ii.) Formulario único de vinculación, iii.) Vinculación de clientes.

- Libro Electrónico de Ordenes (-LEO-).

- Registro de Facturas

- Post - Negociación: i.) Complementación – Comisiones, ii.) Comprobantes, iii.) Liquidación de Operaciones, iv.) Garantías, v.) Adición y prorroga, vi.) Cumplimiento de Operaciones

- Contabilización Operativa

- Tesorería: i.) Bancos, ii.) Cierre Operativo

- Conexión con: i.) Sistemas de Negociación, ii.) Registro de Operaciones, iii.) Terceros Proveedores de Información, iv.) ERP

- Generación de Reportes: i.) Comprobantes, ii.) Certificados, iii.) Estadísticas

Para cada módulo, la BMC especificó detalladamente los requerimientos tecnológicos dentro de los cuales incluyó diagramas, actividades, escenarios, opciones etc., según se observa en el documento referido a páginas 4 a 189.

Con base en este documento, XXXXxXX presentó su Propuesta según obra en el expediente20 en la cual acreditó su amplia experiencia en el mercado financiero y liderazgo en el desarrollo de softwares financieros, entre otros. Así mismo detalló cada uno de los objetivos y lineamientos del Software enmarcados en los requerimientos de la Invitación. Adicionalmente, presentó un cronograma con estimativos de tiempos dando como resultado una duración de 15 meses.

XXXXxXX propuso que el proyecto se realizara siguiendo los principios de la metodología ágil Scrum con sprints cada dos semanas y entregables durante ese mismo período.

20 Expediente Virtual 141365 – 02 Pruebas – Pruebas_02 – 00_Demanda – Pruebas Documentales – 4.2. Back Office

–4.2.2. Propuesta.pdf

En la página 28 de su propuesta, XXXXxXX estableció que: “DATAiFX basa su filosofía en el trabajo de la mano con el cliente. Las entregas rápidas permiten que el cliente participe en el desarrollo del proyecto y le permite al cliente ir realizando ajustes menores sobre la marcha, realizar pruebas de concepto, e ir haciéndole mejoras al software inicialmente planeado, sin que conlleve un incremento en el costo. La metodología propuesta y utilizada por DATAiFX a lo largo de su experiencia garantizará el seguimiento y alcance del proyecto bajo parámetros de calidad e integra los fundamentos de la Metodología de gerencia de proyectos del PMI para la gestión de la ejecución del proyecto y de las Metodologías de Desarrollo RUP y SCRUM para la construcción de la funcionalidad del sistema de información. Así mismo, nuestra metodología incluye los procesos de apoyo para el Aseguramiento de la Calidad, Control de cambios, Control de versiones y configuración, necesarios para asegurar el éxito del proyecto.”

Aceptada la propuesta de DATAiFX por la BMC, las partes suscribieron el 2 de diciembre de 2020 el Contrato de Prestación de Servicios Tecnológicos para el análisis, diseño y desarrollo de la Solución Tecnológica para el Proyecto Back Office, No. Co-2020-0060 que obra en el expediente21 (Contrato Back Office).

De conformidad con el Contrato Back Office, DATAiFX se comprometió con la BMC a “ejecutar, bajo la modalidad de un Contrato Llave en Mano, el Proyecto Back Office, de conformidad con las condiciones señaladas en el presente Contrato, así como en la Invitación y en la Propuesta, las cuales forman parte integral del Contrato” (Cláusula Segunda - Objeto).

Como se mencionó en el capítulo que antecede, las características principales de la modalidad Llave en Mano son las de determinar un precio y un plazo fijo para la entrega del Proyecto.

Para el desarrollo del Proyecto, DATAiFX debía (i) diseñar, desarrollar e implementar una Solución Tecnológica que incluyera los 9 módulos determinados en la invitación y la propuesta, (ii) desarrollar una arquitectura del software que permitiera la implementación rápida de nuevas funcionalidades, optimizar recursos y llevar una correcta trazabilidad de los diferentes procesos, así como establecer controles y puntos de mejora concretos y (iii) desarrollar e implementar la Solución Tecnológica requerida de conformidad con los requerimientos tecnológicos, descripción técnica de las tecnologías, arquitectura, estrategia para despliegue continuo establecidos en la Invitación y en la Propuesta (Cláusula Tercera – Alcance).

XXXXxXX aceptó que sus obligaciones eran de resultado según quedó expresado en el inciso final de la Cláusula Tercera antes referida.

21 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office-3. Contrato CO-2020-0060- Back Office.pdf

Dentro de sus obligaciones DATAiFX se comprometió entre otras a: “(…) 4.2. Entregar la Solución Tecnológica conforme los términos y condiciones previstos en la Invitación y la Propuesta y este Contrato, mediante la modalidad Llave en mano, en el término previsto en la Cláusula Séptima del Contrato de acuerdo con el detalle señalado en el Cronograma”, (…) “4.7. Notificar e informar a la BOLSA de cualquier hallazgo, anomalía, dificultad, o evento sobreviniente que pudiera de cualquier forma modificar la duración del Contrato o el costo de este”, (…) “4.10 Realizar todos los ajustes y desarrollos que requiera la BOLSA para el correcto funcionamiento de la Solución Tecnológica, sin que ello implique costos adicionales a los estipulados en la Propuesta”, (…) “4.11. Cumplir con el Cronograma que se pacte entre las PARTES para el desarrollo del Proyecto y cumplir con el tiempo de ejecución del Proyecto planteado en la Propuesta” y (…) “4.12. Usar el Enfoque RUP - SCRUM como metodología del Proyecto”.

De conformidad con la Cláusula Séptima del Contrato, su duración sería de 15 meses contados a partir “del perfeccionamiento del Contrato o hasta la culminación efectiva del proceso de instalación y estabilización de la plataforma tecnológica, momento en el cual iniciará el Periodo de Garantía que durará doce (12) meses”.

Las partes acordaron que el valor del Contrato sería de $1.437.456.581,00 más IVA, (Cláusula Octava) el cual se distribuiría según el plan de pagos incluido en el numeral 8.1.

De las cláusulas acordadas, destaca el Tribunal que las partes pactaron un plazo y un tiempo específico para la entrega de la Solución Tecnológica y que DATAiFX aceptó que sus obligaciones eran de resultado. Así mismo DATAiFX se obligó a “Realizar todos los ajustes y desarrollos que requiera la BOLSA para el correcto funcionamiento de la Solución Tecnológica, sin que ello implique costos adicionales a los estipulados en la Propuesta y a ejecutar “por su propia cuenta, bajo su total responsabilidad jurídica, con libertad, autonomía técnica y administrativa” y a asumir “todos los riesgos que se originen debido al cumplimiento del presente Contrato” asegurando “la prestación de los servicios” (Cláusula Cuarta). Todo lo anterior acorde con la modalidad Llave en Mano escogida por las partes.

No obstante lo anterior, las partes también pactaron utilizar el Enfoque RUP - SCRUM como metodología, lo cual, como lo definió la misma DATAiFX en su Propuesta, implicaba que la BMC pudiera participar en el desarrollo del Proyecto, realizar ajustes sobre la marcha, pruebas de concepto e ir haciéndole mejoras al software inicialmente planeado, lo cual, claramente desdibujaba la modalidad Llave en Mano.

Cabe anotar que la utilización de la metodología Scrum fue propuesta por DATAiFX y en consecuencia incluida en el Contrato.

Tal como se anota en la primera parte de este laudo, no es apropiado ni conveniente combinar un modelo económico contractual de precio fijo, tiempo máximo de ejecución, totalidad de los riesgos en cabeza del contratista y obligaciones de resultado, con una metodología que implique una alta injerencia del contratante en la elaboración del producto.

Cabe resaltar en este aparte lo dicho por el testigo Xxxxxx Xxxxxxx Xxxxxx Xxxxxxxxx, ingeniero de sistemas con especialización en construcción de software al contestar una pregunta del Tribunal:

“DRA. XXXXXXX: [00:23:34] Una pregunta: entiendo entonces que es normal que estos contratos llave en mano tengan la metodología de se hagan a partir de metodologías ágiles?

XX. XXXXXX: [00:23:51] Ese es un juego de términos, porque cuando se habla de llave en mano es: tú piénsalo bien, tú contratista, dime cuándo y cuánto; cuando se habla de modelos de negocio ágiles, obviamente basados en metodologías ágiles, es cuánto es el límite o el precio referencia ya no es tan estricto entonces sin embargo, llave en mano, también alguien puede decir es que yo espero que usted me entregue todo además, esto requiere la integración con este otro sistema o algunas tareas paralelas: espero que usted me entregue todo y me entregue llave en mano porque es figurativo al carro que te entregan ya está listo para que usted lo opere.

Si le entregó las llaves de su carro, se las entregó a la mano, de ahí sale el término. Entonces no me entregue las llantas, ni me entregue el timón aparte, no, entrégueme el carro todo armadito y obviamente cuánto vale y cuándo me lo entrega. Es por eso el concepto, en cambio en el otro, es si yo puedo recibir un carro con el timón cuadrado y en una segunda fase cuando yo tenga más presupuesto, lo redondeamos.

DRA. XXXXXXX: [00:25:26] Podría decirse que es un poco contradictorio.

XX. XXXXXX: [00:25:29] Es un poco contradictorio sí, llave en mano a metodologías ágiles.

DRA. BARRIOS: [00:25:34] Cuando uno desarrolla esas tecnologías, metodologías, perdón, ágiles, puede tender a que se abran más espacios de desarrollo y se sigan abriendo y cambie los precios de los contratos?

XX. XXXXXX: [00:25:53] Claro, el terrible problema de los contratos llave en mano y precio cerrado es que los procesos de estimación, por más libros que existan, no son exactos no es una ciencia como la matemática se puede basar en la matemática y hay modelos de estimación basados en la matemática que requieren un proceso muy exhaustivo, estadístico, sobre historial de productividad de un equipo,

pero siempre va a ser estimación el mismo ejercicio de calcular las horas hombre que consume un requerimiento.

Pero por otro lado, el gran riesgo es que ese requerimiento a la hora de escribirse no está tan detallado como a la hora de codificarse; entonces el desarrollador pregunta: bueno, y entonces qué pasa si la TRM xx xxx es más barata en el ejercicio que les acabé de hacer, está menor que la de ayer hoy no hemos pensado, eso dice el contratista. Entonces necesito que me hagas una fórmula de redondeo eso no lo tenía estimado son más horas de desarrollo, pero cómo no hay más plata y eso hace que los contratos se compliquen entonces, si dos compañías se quieren realmente complicar, firmen un contrato llave en mano a precio cerrado hasta ahí el día.

En los únicos dos días felices son el día de la firma y el día de la entrega como logramos entregar de resto es de un contrato muy tirante la metodología ágil lo permite manejar si hay buenas, pero suele pasar, no estimé bien y además hay muchos más requerimientos va saliendo y es en la TRM un cambio en este otro requerimiento, otro cambio y otro cambio muchas veces excede definitivamente consume el margen de utilidad y además empieza a generarse pérdidas si el contratista tiene que ser muy habilidoso en explicarlas, mostrarlas al cliente y el cliente, tener la mente abierta para decir sí, entiendo que es más de esfuerzo y que toca hacer una adición al contrato o irnos a un Tribunal de

arbitramento”.22

De lo anterior, concluye el Tribunal que los principales problemas que afrontaron las partes durante la ejecución del Contrato surgieron en gran parte por su estructuración.

Por otro lado, en cuanto al tema de las garantías, la Cláusula Vigésima del Contrato dispone lo siguiente:

“DATAiFX Garantizará el buen funcionamiento de todas las etapas del Proyecto Back Office así:

● Garantía y soporte durante el desarrollo del Proyecto: DATAiFX realizará el Mantenimiento Correctivo sobre los desarrollos que vayan saliendo a producción, y desde su Certificación por parte de la BOLSA por un término de sesenta (60) días calendario con el fin de que LA BOLSA asegure su puesta en producción de conformidad con la Invitación y la Propuesta.

● Garantía y soporte técnico posterior a la culminación del Proyecto: Una vez realizada la entrega final, DATAiFX proporcionará una garantía extendida que incluirá cualquier Mantenimiento Correctivo, así como el Acuerdo de Niveles de Servicio previsto en la Propuesta por un (1) año

22 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxx Xxxxxxx Xxxxxx Xxxxxxxxx

a partir de la entrega final Certificada por la BOLSA con la cual finaliza el proyecto. Las obligaciones de Garantía de DATAiFX durante el Periodo de Garantía consistirán en llevar a cabo el Mantenimiento Correctivo de todos los módulos o desarrollos de la Solución Tecnológica correspondientes a cada uno de los entregables objetos de Certificación, y consiste, pero sin limitarse, en la corrección de los errores funcionales detectados por cualquiera de las Partes, así como la resolución de dudas sobre la utilización y administración de dichos módulos.”

En el marco de las estipulaciones contractuales arriba referidas, procede el Tribunal a hacer un análisis de la forma en la que se ejecutó el Contrato con el fin de determinar si DATAiFX lo incumplió como lo solicita la Convocante.

Para lo anterior, es preciso distinguir, en primer lugar, los incumplimientos a los que se refiere la BMC. De la lectura de la demanda, el Tribunal encuentra que son básicamente dos los que le indilga la BMC a DATAiFX y que tienen que ver con (i) no haber cumplido con su obligación de garantía y (ii) no haber entregado la totalidad de los productos acordados dentro del término contractual, por lo que el análisis del Tribunal se centrará en estos dos temas.

(i) Garantías

Como se observa en la Cláusula Vigésima arriba transcrita, el Contrato establece dos tipos de garantías: la primera que debía prestar DATAiFX durante el desarrollo del proyecto con el fin de realizar “el Mantenimiento Correctivo sobre los desarrollos que vayan saliendo a producción, y desde su Certificación por parte de la BOLSA por un término de sesenta (60) días calendario con el fin de que LA BOLSA asegure su puesta en producción de conformidad con la Invitación y la Propuesta” y la segunda que se llevaría a cabo una vez culminado el Proyecto.

Dado que no se dio la entrega final del Proyecto, como se detallará más adelante en este Laudo, el Tribunal concluye que la garantía de la cual debe ocuparse es la que debía adelantar durante la ejecución del Contrato que tiene que ver con los módulos entregados. Con base en lo anterior, el Tribunal declarará que la excepción formulada por DATAiFX denominada “La Obligación de garantía del Contrato Back Office nunca nació” prospera parcialmente, solamente en relación con la garantía que debía prestar con posterioridad a la culminación del Proyecto.

De las pruebas aportadas al proceso se evidencia que el 22 de octubre de 2021 la BMC otorgó certificación de recibo de los módulos Parámetros del Sistema, Vinculación y Libro Electrónico de Órdenes. En las cartas de certificación, la BMC manifestó que se habían realizado las pruebas operativas y funcionales del aplicativo referente a los módulo respectivos y que se habían

recibido los manuales correspondientes y el diccionario de permisos del sistema, con un resultado exitoso23.

Entregados y certificados los módulos de Parámetros del Sistema, Vinculación y Libro Electrónico de Órdenes, DATAiFX tenía la obligación de realizar el mantenimiento correctivo sobre aquellos, por un término de sesenta (60) días calendario.

De los documentos que obran en el expediente, en la carpeta denominada Correos Soporte Back Office24, el Tribunal constata que una vez certificados los tres módulos, las partes empezaron a cruzarse diversas comunicaciones encaminadas a ajustarlos y a corregir las inconsistencias que reportaban la Sociedades Comisionistas de Bolsa (SCB).

Se evidencia en las comunicaciones entre las partes, que por lo general XXXXxXX contestaba las solicitudes con prontitud y estaba dispuesta a solucionar cualquier inconveniente y a reunirse de ser el caso25. En varias de aquellas, se observa que la BMC respondía que el ajuste era correcto26.

El testigo Xxxxxxxx Xxxxx quien trabajaba para DATAiFX, por ejemplo, en su declaración manifestó:

“[00:34:22] Pues una vez entregamos el módulo, me acuerdo mucho que nos reunimos con Xxxxx, con Xxxxxxxxxx, con Mi Agro, pues no me acuerdo exactamente de los nombres de las firmas comisionistas, pero con muchas nos reuníamos casi que todos los días cuando entró en producción. Al principio para resolver esas no era yo solo, porque pues inclusive en ese caso yo hacía más el fronting de discutir, pero pues ya era un tema mucho más técnico que tenían que manejar los ingenieros de sistemas, que se tenían que reunir con ellos y hacer las modificaciones y cosas, pero pues podíamos cuando estuvo en producción por ahí yo digo que nos estábamos reuniendo por ahí dos o tres veces por semana antes de que abriera la rueda, quiere decir antes de las 09:00 a.m. por un período de una o dos horas y por lo menos durante tres meses siempre nos estábamos reuniendo para ver que eso estuviera funcionando, que no hubiera novedades o que funcionara el sistema; a veces no se presentaba ninguna novedad, pero siempre teníamos que estar ahí disponibles para que el sistema y las órdenes quedaran registradas en el libro electrónico de órdenes”.27

23 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 7. Actas de entrega Back Office- 20211022 LEO certificación.pdf y 20211022 Parámetros y Vinculación certificación.pdf

24 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 8. Correspondencia cruzada Proyecto Back Office – Correos BMC – Correos Soporte Back Office

25 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 8. Correspondencia cruzada Proyecto Back Office – Correos BMC – Correos Soporte Back Office – 20220223_RE_SOLICITUD ORDEN No. 171.msg, 20220104-RE_SOLICITUD REVISION LEO APLICATIVO.msg, 20211130-RE_NOVEDADES EN SISTEMA DEL LEO BACKOFFICE_msg

26 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 8. Correspondencia cruzada Proyecto Back Office – Correos BMC – Correos Soporte Back Office - 20220713 RE_Soporte orden 189, 20211129_RE_Pruebas Modulo de Ordenes - Notificaciones

27 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxx Xxxxxx

Por otra parte, vale la pena resaltar que según lo estipulado en la Cláusula Vigésima, esta garantía consistía en que DATAiFX realizara mantenimiento correctivo sobre los elementos entregados y certificados, con lo cual el Tribunal entiende que DATAiFX debía garantizar el buen funcionamiento del módulo, es decir, corregir errores, pero no mejorarlo ni mucho menos construir elementos adicionales, como en algunas ocasiones la BMC le solicitó.

Entiende el Tribunal que dado que el módulo ya había sido entregado y aprobado por la BMC después de varias pruebas, lo que le correspondía a DATAiFX era solamente corregir errores y resolver dudas pero no seguir creando historias de usuario.

Según el dicho de la propia convocante, después de certificados los módulos de Vinculación y LEO, la BMC requirió a DATAiFX para que implementara mejoras y construyera nuevas historias de usuario (Hecho 40 Demanda).

Según la definición de Garantía que las partes acordaron (la Cláusula Primera): “GARANTÍA. Se trata de la obligación de DATAiFX de corregir los problemas y fallas (Mantenimiento Correctivo) que surjan del uso e implementación de los módulos de la Solución Tecnológica entregados por DATAIFX y que hayan sido objeto de Certificación por la BOLSA. Así mismo, incluye la resolución de dudas sobre la utilización y administración de los módulos de la Solución Tecnológica que hayan sido objeto de Certificación. Esta obligación tendrá la duración prevista en la “Cláusula de Garantías” (Vigésima Primera) del presente Contrato”. (subraya del Tribunal)

No era obligación entonces de DATAiFX, después de certificados los módulos, cambiarlos, mejorarlos o complementarlos, pues DATAiFX simplemente debía corregir problemas y fallas, así como resolver dudas sobre su funcionamiento y operación.

El Tribunal encuentra que el principal problema que se presentó después de certificados los tres primeros módulos fue que las SCB empezaron a hacer requerimientos más allá de lo entregado, lo cual desbordó el trabajo que debía realizar DATAiFX.

De la lectura de la Invitación, la Propuesta y el Contrato, se concluye que la recopilación de información con las SCB la hizo la BMC, y con base en esta información elaboró la Invitación.

Adicionalmente, según el informe enviado por la sociedad INFORMÁTICA Y TECNOLOGÍA XXXXXXXXX S.A. (Xxxxxxxxx):

La BMC celebró con Xxxxxxxxx un contrato de prestación de servicios el 16 de septiembre de 2019 en el cual Xxxxxxxxx se obligó “a prestar los servicios de suministro de personal para levantamiento de requerimientos de los diferentes módulos del proyecto Back Office para las sociedades Comisionistas de la BMC, a través de la modalidad de outsourcing administrado. En desarrollo del

objeto contratado, Xxxxxxxxx asignó personal especializado de su compañía en las oficinas de la BMC”

Xxxxxxxxx informó igualmente que “cumplió a satisfacción de la BMC con las obligaciones derivadas del Contrato plenamente de acuerdo con el último informe de seguimiento suscrito por la persona encargada de realizar el seguimiento al Contrato.” y que “Tanto Xxxxxxxxx como la BMC se declararon mutuamente x xxx y a salvo por concepto de la celebración, ejecución, y liquidación del Contrato, en todas sus partes. Lo anterior, teniendo en cuenta que las Partes cumplieron en debida forma con la ejecución de las obligaciones derivadas del Contrato.28”

Queda claro entonces para el Tribunal que el levantamiento de requerimientos de los diferentes módulos del Back Office para las SCB se adelantó con anterioridad a la firma del Contrato y con base en aquel se elaboraron los documentos precontractuales.

Volviendo a la garantía, el Tribunal reitera que una vez entregados los módulos, DATAiFX debía resolver dudas de funcionamiento pero no implementar lo entregado. Ahí estuvo el principal error de las Partes, pues entregados los módulos y certificados se entendía que habían cumplido con los requerimientos de la Invitación elaborada a partir de la información recopilada con las SCB, quienes no tenían la facultad de hacer nuevos requerimientos. Claramente el Contrato fue suscrito entre la BMC y DATAiFX. Las SCB eran terceros que si bien utilizarían la Solución Tecnológica, no tenían porqué interferir en la ejecución del Contrato, ni mucho menos hacer requerimientos adicionales. Ingenuamente DATAiFX continuó implementando los módulos ya certificados, lo cual desbordó sus obligaciones.

Destaca el Tribunal que DATAiFX tenía la obligación de “Notificar e informar a la BOLSA de cualquier hallazgo, anomalía, dificultad, o evento sobreviniente que pudiera de cualquier forma modificar la duración del Contrato o el costo de este”(Obligación 4.7 Cláusula Cuarta), la cual ha debido ejercer ante los requerimientos desbordados de las SCB, que por cierto no hacían parte de la garantía y claramente modificaban la duración y el costo del Contrato; pero no lo hizo.

Por otra parte, en cuanto a la duración de la garantía es importante resaltar que aun cuando esta se agotaba el 22 de diciembre de 2021, por cuanto según el Contrato, operaba durante 60 días a partir de la certificación del módulo, DATAiFX continuó trabajando después de dicha fecha según requerimientos de la BMC29.

Teniendo en cuenta lo anterior, el Tribunal concluye que no se probó el incumplimiento por parte de DATAiFX respecto a la garantía según las

28 Expediente Virtual 141365 - Principal 02-109_respuesta_prueba_informe_informatica_tecnologías_Stefanini.pdf

29 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 8. Correspondencia cruzada Proyecto Back Office – Correos BMC - Hecho 52. Reporte URL y Hecho 51 Ajustes items e historias de usuarios. – Correos DATA – 20220811 RE_Cambio de Operador Back Office, 20220613 Valida Error

disposiciones contractuales, por lo que negará la Pretensión Segunda Principal de la Demanda Principal y acogerá en parte la excepción respectiva.

(ii) Entrega del producto dentro del término acordado

De conformidad con la Cláusula Séptima, el Contrato tenía una duración de 15 meses contados a partir de su perfeccionamiento, es decir, de la firma del acta de inicio. Según consta en las pruebas aportadas, el acta de inicio se firmó el 14 de diciembre de 202030 por lo que el término del Contrato venció el 14 xx xxxxx de 2022.

Según las pruebas que obran en el expediente, desde el inicio del Contrato se presentaron retrasos en la ejecución de los trabajos que XXXXxXX debía entregar, los cuales se fueron acumulando.

De acuerdo con el reporte semanal de fecha 3 xx xxxxx de 2022, es decir, a once días de vencerse el término del Contrato, de 14 compromisos referenciados, sólo 4 estaban terminados, 9 en proceso y 1 pendiente31. En el siguiente informe de fecha 11 xx xxxxx de 2024 (a 3 días del vencimiento del término del Contrato) se observan varias actividades en proceso, cambios de fechas en los cronogramas y tareas nuevas.

Obra en el expediente comunicación de fecha 11 xx xxxxx de 2022 en la que DATAiFX hace un balance general del Proyecto Back Office con la cual queda probado que a esa fecha, es decir, casi un mes después de vencido el término del Contrato, el proyecto no había sido terminado. Es de resaltar que en esta comunicación, XXXXxXX presentó una propuesta para “terminar exitosamente el proyecto” con un nuevo presupuesto, lo que claramente va en contravía de lo estipulado por las partes según la modalidad “Llave en mano”.

El mismo representante legal de la Convocada al rendir la declaración de parte aceptó que no se cumplió el Contrato, pues según lo dicho por el señor Xxxx Xxxxx Xxxxx:

“[01:16:15] El motivo de terminación del contrato es porque no se cumplió el contrato según la Bolsa lo que yo digo es yo acepto que no cumplí el contrato porque yo no entregué el software completo de lo que estaba establecido ahí lo que creo profundamente es que no fue culpa de nuestra.”32(subraya del Tribunal).

De las pruebas analizadas se evidencia que DATAiFX no entregó “la Solución Tecnológica conforme los términos y condiciones previstos en la Invitación y la Propuesta y este Contrato, mediante la modalidad Llave en mano, en el término previsto en la Cláusula Séptima del Contrato de acuerdo con el detalle señalado en el Cronograma”(Obligación 4.2), no notificó o informó “a la

30 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – 5. Acta de Inicio Proyecto Back Office

31 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Back Office – Seguimiento BMC Back Office 02032022

32 Expediente Virtual 141365 – Transcripciones – 142365 Xxxx Xxxxx Xxxxx Xxxxxx

BOLSA de cualquier hallazgo, anomalía, dificultad, o evento sobreviniente que pudiera de cualquier forma modificar la duración del Contrato o el costo de este” (Obligación 4.7), no cumplió “con el Cronograma que se pacte entre las PARTES para el desarrollo del Proyecto” ni “con el tiempo de ejecución del Proyecto planteado en la Propuesta” (Obligación 4.11).

El Tribunal encuentra que las causas del incumplimiento por parte de DATAiFX son consecuencias de la confusa estructuración del negocio, pues, como se ha venido reiterando, la modalidad llave en mano no es compatible con la metodología propuesta por DATAiFX y acordada en el Contrato.

Es claro que, desde el inicio de la relación contractual, las obligaciones de resultado se desdibujaron pues no era compatible entregar un producto dentro de un plazo fijo y sin variación del precio, cuando al mismo tiempo la BMC participaba activamente en su ejecución y tenía gran injerencia en la construcción y aprobación de la solución tecnológica.

De conformidad con el artículo 1622 del C.C. el juez podrá interpretar las cláusulas de un contrato “por la aplicación práctica que hayan hecho de ellas ambas partes, o una de las partes con aprobación de la otra parte”, llamada interpretación auténtica. Del comportamiento de las partes durante la ejecución contractual, el Tribunal puede interpretar que su intención no era la de ejecutar un contrato llave en mano con obligaciones de resultado previamente definidas, pues la BMC participaba activamente en la construcción del producto, es decir, el alcance del producto y sus funcionalidades debían construirse en alguna medida durante la ejecución del contrato, lo cual claramente terminó afectando los tiempos y los costos.

Pero también puede interpretar que ello en buena parte es imputable a la falta de diligencia, pericia y a los errores que cometió DATAiFX y que no pueden esperarse de un profesional experto en este tipo de actividades.

En tal sentido, si bien ambas partes contribuyeron a la estructuración del Contrato, es claro que en buena parte por la impericia de DATAiFX no se pudo entregar la Solución Tecnológica completa (solamente 3 módulos) y, por lo tanto, el contratista incumplió parcialmente el Contrato de Back Office, lo cual declarará el Tribunal en la parte resolutiva.

En cuanto a los posibles incumplimientos de la BMC a los que se refiere DATAiFX, el Tribunal se pronunciará más adelante en este laudo.

3.2. Contrato de Refactoring

3.2.1. Posición de las partes

Solicita la Convocante que el Tribunal “declare que la sociedad DATAIFX incumplió totalmente lo pactado en el Contrato Marco de Servicios Tecnológicos No. CO- 2020-0051 (Refactoring), celebrado entre la BMC y

DATAIFX, según se relatará en los hechos de la presente demanda” (Contrato Refactoring).

Como fundamento de su solicitud, en los hechos de la demanda la Convocante hace un recuento de los antecedentes del Contrato de Refactoring, de su suscripción, así como de algunas obligaciones y definiciones contenidas en el mismo. Frente a estos primeros hechos la Convocada en su contestación manifiesta que son ciertos la gran mayoría.

Afirma la Convocante que “Las Partes aceptaron y reconocieron que, con posterioridad a la elaboración de los Documentos del Discovery, durante el transcurso del desarrollo del Refactoring podría surgir la necesidad de introducir cambios al alcance del Proyecto, así como cambios regulatorios, optimizaciones, desarrollos y otras modificaciones que pudieran surgir en relación con el alcance del Proyecto” (Hecho 30 Demanda).

En cuanto a la ejecución del Contrato, la Convocante hizo referencia a varios correos electrónicos enviados a la Convocada y afirmó, que conforme se desprende de aquellos, desde el comienzo de la ejecución contractual, se presentaron retrasos en el cumplimiento de las prestaciones de DATAiFX.

Adicionalmente señaló que, a la fecha de expiración de la vigencia del Contrato, DATAiFX no había cumplido la totalidad de sus obligaciones.

La Convocada por su lado argumentó que los Documentos de Discovery nunca llegaron a materializarse porque el alcance del Contrato siempre fue cambiante. Así mismo manifestó que XXXXxXX dio respuesta a los correos de la BMC los cuales buscaban continuar con el plan de acción planteado y resolver las vicisitudes oportunamente.

3.2.2. Consideraciones del Tribunal

Con el fin de modernizar su actividad, la BMC elaboró una Solicitud de Propuesta o Invitación33 en búsqueda de tecnologías que hicieran más eficientes sus negocios.

Según lo señalado en la introducción de la Invitación, el alcance del Proyecto de Refactoring no era reescribir el código de los sistemas anteriores, sino generar nuevos desarrollos que abarcaran los tipos de negocios de La Bolsa mediante servicios, con el fin de que si le llegasen nuevos tipos de negocios, fuera fácil adaptar los nuevos requerimientos a los servicios construidos, optimizando costos y tiempos de puesta en marcha.

La Invitación en su numeral 4.3.2. denominado “A futuro” dispuso que “se espera que después del refactoring, los sistemas estén en la capacidad de

33 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Refactoring – 1. Contrato DATAiFX S.A.S. 2020-0051 Anexos. Pag 40

adaptarse a cambios de manera rápida y sencilla” y que “el desarrollo de nuevas funcionalidades o ajuste de las existentes sea más fácil”.

Así mismo en la Invitación la BMC estableció lo siguiente: “se requiere que la nueva arquitectura esté basada en microservicios que soporten las líneas de negocio actuales de La Bolsa y permita incorporar nuevos productos y/o servicios”.

En el marco de dicha Invitación, DATAiFX presentó su Propuesta34 en la que manifestó conocer los términos de la invitación y aceptar las consecuencias del incumplimiento. Así mismo señaló en la Descripción del Servicio que abstraería las principales reglas de negocio y la gestión de los tipos de productos de La Bolsa de manera que serían desarrollados como servicios y microservicios con el fin que estas pudieran ser “entidades independientes, fáciles de actualizar, reemplazar y reutilizar, entre otros beneficios”.

De lo anterior, puede concluir el Tribunal que, según la Invitación y la Propuesta, la Solución Tecnológica del Proyecto de Refactoring debía permitir incorporar nuevos productos y/o servicios y que a futuro se adaptara fácilmente a cambios e incorporara nuevos desarrollos.

Para la puesta en marcha de los aplicativos, DATAiFX estimó un tiempo de 20 meses y un valor de $3.475.200.000.

Como consecuencia del proceso precontractual referido anteriormente, las partes firmaron el 6 de octubre de 2020 el Contrato Marco de Servicios tecnológicos No. 202-0051 (Contrato de Refactoring) mediante el cual DATAiFX se obligó para con la Bolsa “a ejecutar bajo la modalidad Llave en Mano, el Proyecto de Refactoring, conforme con el alcance tecnológico y condiciones señaladas en la Invitación, en la Propuesta y en los Documentos de Discovery” (Cláusula Segunda – Objeto del Contrato). Adicionalmente, en el objeto del Contrato quedó estipulado que DATAiFX recopilaría información que reflejara las necesidades operativas de la BMC la cual se plasmaría en los Documentos de Discovery con lo que se complementaría el objeto del Contrato.

En cuanto a su alcance, las partes acordaron que el Contrato sería Llave en Mano y se desarrollaría mediante Metodología Ágil y gestión PMI, teniendo en cuenta lo señalado en la Invitación, la Propuesta y los documentos de Discovery (Cláusula Tercera).

Como se puede observar, tanto el objeto como el alcance del Contrato se remiten a la Invitación y a la Propuesta, así como a los Documentos de Discovery, los cuales debía construir DATAiFX durante el desarrollo del Contrato.

34 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Refactoring – 1. Contrato DATAiFX S.A.S. 2020-0051 Anexos .Pag 118

De la lectura del Contrato, el cual a su vez se remite a la Propuesta y la Invitación, el Tribunal entiende que, las partes pactaron que su alcance debía permitir incorporar nuevos productos y/o servicios, para lo cual DATAiFX debía elaborar los Documentos de Discovery a medida que se ejecutaba el Contrato, con lo cual complementaria y determinaba el alcance final del Proyecto.

En la cláusula Novena del Contrato, las partes reconocieron que con la elaboración de los Documentos de Discovery, el alcance del Contrato podía cambiar para lo cual previeron ciertas reglas relacionadas con los cambios en los cronogramas y los costos del Proyecto, lo cual desvirtuó la modalidad Llave en Mano acordada, según las Cláusulas Segunda y Tercera arriba mencionadas.

El Tribunal considera que es válido que las partes en un contrato decidan que el alcance del mismo se vaya complementando a medida que este se ejecute. El doctrinante Xxxxxxxx Xxxxxxxxxx señala que “Para que pueda surgir la obligación (art. 920 x.xx.) la prestación ha de ser suficientemente determinada, desde un principio o más tarde (tempestivamente); esto es, ha de ser determinada o determinable (art. 1864 (2) c.c.). Ello quiere decir, lógicamente, que en oportunidad el deudor debe saber qué es lo que debe y cómo lo debe, lo mismo que el acreedor ha de saber qué es lo que puede esperar (…). En cuanto a la oportunidad de la determinación, y dejando sentado que en la mayoría de los casos la determinación corre en el propio título, ha de observarse que cuando queda pendiente, por tarde, se deberá hacer al momento en que haya de ejecutarse la prestación, y que si esta es continuada puede ser susceptible de ajustes y precisiones varios a lo largo del tiempo”35. (subraya del Tribunal).

En el caso bajo estudio, según las cláusulas xxxxxxx transcritas, las partes acordaron que el alcance del Contrato se fuera complementando a medida que se construía y se elaboraban los Documentos de Discovery por medio de los cuales se detallaba el Alcance del Proyecto, según lo dispuesto en la definición incluida en el Contrato .

Quedó probado en el proceso, tanto con los documentos aportados con la demanda como con las grabaciones de las reuniones allegadas en la exhibición de documentos, que el alcance del Contrato no estaba del todo determinado, pues si bien la idea era que la aplicación permitiera incorporar nuevos servicios, DATAiFX en su ejecución debía elaborar los Documentos de Discovery mediante los cuales se precisaba dicho alcance. Sin embargo, es importante anotar que de esto estaban al tanto ambas partes pues así lo admitieron ellas mismas en el Contrato. El problema fue que las partes no lograron detallar el alcance durante la ejecución.

35 Xxxxxxxxxx, X. (2002). Tratado de las Obligaciones. (Pág. 276) T. I. Universidad Externado de Colombia.

Vale la pena en este aparte hacer alusión a algunas de las grabaciones de reuniones exhibidas por la BMC y seleccionadas por DATAiFX para ser incorporadas al expediente.

Por ejemplo, en reunión llevada a cabo el 20210507 el señor Xxxxxx Xxxxxxxx de la BMC manifestó (min. 33:26 al min. 34:42):

“Perdóneme que le diga, yo creo que ese ejercicio que está planteando no es. Porque nosotros no estamos tratando de replicar la infraestructura actual en una nueva infraestructura, como lo vimos desde el principio; si claro, la nueva infraestructura va a tener que contemplar los productos actuales, pero la plataforma es agnóstica a cualquier producto, luego eso implica que la parametrización de los motores tiene que ser por fuera del motor, y siento que con esta visión estamos cerrando el “scope” a los productos de bolsa, y ese no es el alcance del proyecto. (…) Pero, pero el límite, o sea, el límite no lo conocemos. Ese es el punto.”

Más adelante señala:

“Pero volvemos a lo mismo. Es que nadie tiene ese “scope” que ustedes están pidiendo, es que eso es lo que le estoy poniendo sobre la mesa, nadie lo tiene.” DL: “Exacto, pero seguramente o sea, entiendo que los que tenemos que buscar “scope” pues somos nosotros” FV: “pues es que el “scope” del proyecto no tiene un fin determinado. ¿Entonces no, no puede ser, dígame usted que cuál es el alcance máximo? Pues no lo sé, porque el alcance máximo lo que nosotros planteamos. El alcance máximo es desarrollar los motores agnósticos, que hemos explicado 5 o

6 veces en estas reuniones. Ese es el alcance. Entonces acotar el universo, yo no lo veo”36.

En los alegatos de conclusión, XXXXxXX argumentó que nunca fue posible acotar el objeto de los contratos por el simple hecho de que la BMC no tenía idea clara de lo que quería. Sin embargo, el Tribunal considera que el que no se haya logrado acotar el detalle del alcance del Proyecto durante la ejecución contractual, no fue error exclusivo de la BMC sino también de DATAiFX, quien contaba con amplia experiencia en el desarrollo de soluciones tecnológicas y conocía a la BMC, pues ya había trabajado con ella, como ella misma lo señaló en los hechos de su demanda de reconvención37

También quedó demostrado mediante las respuestas dadas por el testigo Xxxxxxxx Xxxxx quien trabajaba con XXXXxXX.38

Desde el inicio de la relación contractual, DATAiFX asumió la responsabilidad de elaborar los Documentos de Discovery con los cuales se complementaría el alcance contractual. Por otra parte, cabe resaltar que estaba claro que para

36 Expediente Virtual 141365 – 02 Pruebas – Pruebas_02-10.Pruebas_Grabaciones_Seleccionadas

37 Hecho 2.1.1.3

38 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxx Xxxxxx

su elaboración, XXXXxXX aplicaría la metodología Scrum, la cual esta misma empresa había introducido en su Propuesta.

Es importante anotar que DATAiFX no era ningún desconocido en el ámbito tecnológico financiero pues tenía amplia experiencia. Como lo manifestó su representante legal:

“DATAIFX se dedicaba a desarrollar softwares para el sector financiero principalmente para la Bolsa de Valores de Colombia y nosotros desarrollamos la primera plataforma transaccional de acciones en Colombia con Correval en su momento y después fuimos creciendo en ese tema, en la medida que íbamos avanzando conseguimos esos clientes en la bolsa mercantil”39.

Al no estar limitado el objeto y alcance del Proyecto desde un principio y no haberlo determinado las partes a medida que se ejecutaba, el desarrollo contractual se extendió indefinidamente sin lograr su culminación. Sin embargo, la concreción del alcance no era un asunto que le correspondiera a la BMC exclusivamente, pues ambas partes habían estructurado el Proyecto y DATAiFX era la responsable de la elaboración de los Documentos de Discovery, como quedó plasmado en el Contrato. Lo anterior, con el agravante de la combinación pactada de la modalidad Llave en Mano con aplicación de “metodologías ágiles”.

De los informes semanales y mensuales elaborados por DATAiFX aportados al expediente40, se observa que varios de los compromisos técnicos iban quedando pendientes y en proceso, a medida que avanzaba el Proyecto. Así mismo, se puede observar cómo en las diferentes reuniones de seguimiento surgían nuevos compromisos. Por lo general, desde el inicio de la ejecución contractual, el avance esperado no coincidía con el real y la deuda técnica iba pasando de un sprint a otro sin resolverse en un 100%.

En la carta enviada por DATAiFX a la BMC el 11 xx xxxxx de 2022, DATAiFX hace un balance del estado de avance del Proyecto y propone un nuevo presupuesto con un nuevo cronograma, lo cual nuevamente desvirtúa la modalidad Llave en Mano acordada originalmente por las partes.

Nuevamente recurre el Tribunal en este punto a la interpretación auténtica del Contrato y concluye que las partes estuvieron de acuerdo en desdibujar la modalidad Llave en Mano y las obligaciones de resultado mediante su conducta en la ejecución contractual.

Teniendo en cuenta que el término del Contrato era de 20 meses según la Cláusula Séptima que recoge la Propuesta presentada por DATAiFX, y que el Acta de Inicio se firmó el 4 de noviembre de 2020, según consta en el

39 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxx Xxxxxx

40 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Refactoring – 4. Documentos Soporte Reuniones Contrato Refactoring

cronograma que obra en el expediente41, el término pactado del Contrato se venció el 4 de julio de 2022.

Al igual que en el Contrato de Back Office, se evidencia que DATAiFX no entregó el Proyecto de Refactoring y que para hacerlo hubiera requerido de plazo y presupuesto adicional a lo cual no accedió la Convocante. El propio representante legal de la convocante admitió que no había cumplido el Contrato al no haber entregado el software completo42.

Así mismo, varios de los testigos coincidieron en afirmar que el producto no se terminó y además, que no se utiliza hoy en día ninguno de los avances desarrollados por DATAiFX. Es así como el testigo Xxxxxxxx Xxxxx, quien trabajó con DATAiFX, manifestó lo siguiente:

“XX. XXXXX: [00:43:31] Es un producto nuevo ese no entró en producción no salió en vivo ni lo terminaron utilizando, pero lo que yo sí creo es que desarrollamos una cosa bastante potente el motor de registro tiene unas capacidades muy buenas en sistemas. Lo que pasa es que hasta no estar completo, pues no puede ser utilizado para lo que requeriría la bolsa hoy como está pues no es un producto terminado, pero no quiere decir que las partes que se hicieron y que en gran parte son la estructura de todo el software no sea un buen producto yo la verdad me siento muy orgulloso de lo que logramos desarrollar ahí y de esos motores porque fueron requirieron mucho trabajo y tenían muchas funcionalidades.

DR. SERENO: [00:44:21] Sí, pero no está operativo en este momento?

XX. XXXXX: No señor, que yo sepa no, porque pues nosotros ya no tenemos el dominio sobre ese software, pero hasta cuando yo estuve y hasta que estuvo con el contrato DATAiFX pues no es operativo para las funcionalidades que necesita la bolsa, no” 43(Subraya del Tribunal).

Por su parte, la representante legal de la BMC señaló que “del contrato de refactoring no se está utilizando nada”.44

El testigo Xxxxxxxx Xxxxxxxxx Xxxxx también declaró en ese mismo sentido y manifestó lo siguiente45:

“XX. XXXXX: [00:50:08] Sé que se entregaron varios de los componentes o módulos individuales como tal.

XX. XXXXXXX: [00:50:15] ¿Eso se usa hoy en día?

41 Expediente Virtual 141365 – 02 Pruebas – Pruebas_01 – Demanda – Refactoring – 3. Cronograma Refactoring Final

42 Expediente Virtual 141365 – Transcripciones – 142365 Xxxx Xxxxx Xxxxx Xxxxxx

43 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxx Xxxxxx

44 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxx Xxxxxxx

45 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxxxxxx Xxxxx

XX. XXXXX: [00:50:18] No, ninguno de lo que se desarrolló se utilizó hoy en día”.

De acuerdo con la cláusula Quinta del Contrato DATAiFX se obligó a: (…) 5.10. Ejecutar las actividades necesarias atinentes a lo señalado en la Invitación, los Documentos del Discovery y en la Propuesta con el fin de cumplir con la obra encomendada Refactoring en los términos de tiempo, calidad y precio conforme lo ha señalado en la Propuesta”, con lo cual no cumplió según las pruebas arriba analizadas.

Es importante resaltar que DATAiFX contaba con la posibilidad de “Notificar e informar a la BOLSA de cualquier hallazgo, anomalía, dificultad, o evento sobreviniente que pudiera de cualquier forma modificar la duración del Contrato o el costo de este (…)” lo cual no sucedió. Simplemente se llegó la fecha de vencimiento del Contrato sin que el Proyecto de Refactoring culminara y sin que XXXXxXX entregara en tiempo según estaba obligado a hacerlo.

Como aconteció en el Contrato de Back Office, en este caso, gran parte del fracaso del proyecto se debió a la forma en que se estructuró desde un principio y a la incapacidad de las partes de determinar el alcance de la solución tecnológica. Si bien el Contrato fue elaborado de común acuerdo con base en la Invitación y la Propuesta y ambas partes son responsables de incluir modalidades y metodologías contrarias, esto no excusa a DATAiFX de su obligación de cumplir con la entrega de la solución tecnológica pactada.

Ello da lugar a que el Tribunal pueda tomar partido por el criterio de que aunque no puede endilgarse responsabilidad a DATAiFX por la frustración del objeto contractual bajo el contexto del alcance de obligaciones propiamente de resultado, sí es posible concluir que su actuar no correspondió a la diligencia y al cuidado que podría esperarse en la prestación de un servicio para construir una solución tecnológica acorde a las necesidades y requerimientos del cliente, por parte de un profesional experto en la industria, que estaba en posibilidad de estructurar y ejecutar un contrato afín y acorde con la información disponible y aquella que debía obtenerse durante su ejecución.

Teniendo en cuenta lo anterior, el Tribunal declarará que, al igual que en el caso de Back Office, DATAiFX incumplió con la obligación de entregar en tiempo la solución tecnológica, fruto de la indefinición e imprecisión del resultado que debía alcanzarse con ella, que no pudo cerrarse durante la vida del contrato por las varias circunstancias que afectaron el proceso y que fueron resaltadas atrás, que en buena parte surgen de la falta de pericia del contratista.

Si bien DATAiFX no entregó ni siquiera una parte de la solución tecnológica, el Tribunal encuentra que su incumplimiento, al igual que en el Contrato de Back Office, fue parcial y no total, pues quedó probado con el Otrosí No. 1 que

DATAiFX construyó un 16% del Proyecto Refactoring, el cual la Bolsa estuvo de acuerdo en pagarle. Si bien ese porcentaje no fue objeto de certificación, lo anterior se debió a que para la entrega de la solución tecnológica debía culminarse el 100% del proyecto y no era posible entregar por partes, como si lo fue en el Contrato de Back Office.

No quedó probado en el proceso si el trabajo construido por DATAiFX funciona o no, así como tampoco si a futuro pueda utilizarse para finalizar el proyecto, lo que si quedó probado fue que DATAiFX culminó el 80% de la Fase 1, por lo que su incumplimiento no puede determinarse como total.

Por lo anterior, el Tribunal declarará que prospera parcialmente la Pretensión Tercera Principal de la demanda.

4. Incumplimientos endilgados a la BMC

La sociedad convocada y reconviniente ha señalado como fundamento tanto de sus excepciones, como de sus pretensiones, tres (3) hechos basilares:

(i) El cambio de naturaleza del objeto del contrato de Refactoring por cuanto no se trataba de crear un nuevo software sino migrar el actual sistema a uno nuevo, excediendo en su criterio el objeto del contrato sin permitírsele el acceso al sistema actual en operación.

(ii) En cuanto al Contrato de BackOffice, la creación de una aplicación nueva que no estaba prevista, la cual se vio obligado a construir, ante la exigencia de la autoridad de control competente y por instrucción de la BMC, debiendo realizar ajustes y adaptar el programa de software existente para que pudiera interactuar con las sociedades comisionistas de bolsa (SCB), así como la falta de acotación del objeto del Contrato, ante la indefinición por parte del contratista de los límites de la actividad contratada.

(iii) En los dos casos anteriores, la falta de entrega de la información oportuna y completa por parte de la BMC para desarrollar las historias de usuario (HS) y la negativa sistemática del contratante para permitir la relación directa de DATAiFX con los usuarios finales del programa de Refactoring y las sociedades comisionistas de bolsa (SCB), lo cual impidió acceder a la información necesaria y oportuna para poder cumplir oportunamente con los desarrollos contratados.

Dentro del anterior escenario, el Tribunal analizará el tema objeto de debate de conformidad con las pruebas en el trámite, empezando con el Contrato de Refactoring (1) y posteriormente el contrato de Back Office (2), habida cuenta de la acumulación de pretensiones contenida en la demanda arbitral reformada.

4.1. Contrato de Refactoring

En los considerandos del Contrato CO-2020-0051 del seis (6) de octubre de 2020, denominado: “Contrato Marco de Servicios Tecnológicos”, se señaló:

CUARTO: Que la BOLSA en el mes xx xxxxx de 2020 elaboró un “Request for Proposal-RFP- ( en adelante la Invitación) la cual obra como “Anexo 1- Invitación” del presente Contrato, por medio de la cual busca hacer más eficiente sus procesos de negocios, apalancándose en tecnologías actuales para la arquitectura de software, plataforma de nube y servicios especializados, transformado los CORE actuales en unos que puedan dar una mayor eficiencia, escalabilidad y sean adaptables a las últimas tendencias tecnológicas (en adelante Refactoring). (Resaltado del Tribunal).

Las partes expresamente se refirieron al cronograma del desarrollo del programa señalando: “ El Cronograma se elaborará una vez se elaboren los Documentos del Discovery”. (Resaltado del Tribunal).

Por su parte, el Documento de Discovery, según lo acordaron las partes, es “..el compendio de documentos por medio del cual DATAiFX revelará el resultado de la actividad “Análisis y levantamiento de las reglas de negocio”.

Encuentra el Tribunal de capital importancia el concepto de levantamiento de la información, frente al cual las partes acordaron que “se trata de las actividades previstas en la fase 1 “Análisis y levantamiento de Reglas de Negocio-Arquitectura de Microservicios” y por medio de las cuales se busca la elaboración de los Documentos de Discovery para las actividades previstas en el Refactoring”. (Resaltado del Tribunal).

Definieron igualmente el Proyecto, indicando que “Se entenderá como el conjunto compuesto por todas las actividades a cargo de ambas Partes, necesarias para la (i) estructuración, (ii) implementación, (iii) puesta en marcha del Refactoring, así como la ejecución de las actividades previstas en el presente Contrato y sus anexos, en las diferentes fases previstas.”

Por Refactoring entendieron ambas partes, porque así lo señalaron expresamente, lo siguiente: “En el proceso de REFABRICAR el código fuente de los aplicativos de la BOLSA, a través de microservicios, utilizando herramientas y servicios y en la nube (cloud) buscando optimización de recursos y bajo un entendimiento de los procesos de negocios de toda la BOLSA, de la forma como se solicitó en la invitación y conforme se complemente en los documentos del Discovery” (Resaltado y subrayado del Tribunal).

Finalmente, el concepto de solución tecnológica para las partes es “…. el software que desarrollará DATAIFX en el marco de las actividades de Refactoring del proyecto objeto del presente contrato”.

Dentro de las obligaciones de la contratante se destacan: “Proveer, de acuerdo con los cronogramas acordados la información requerida para el adecuado desarrollo de cada una de las fases que serán desarrolladas por parte de DATAiFX en el Refactoring conforme a la Invitación, la Propuesta y el Documento de Discovery” (4.1. ) y Ejecutar oportunamente todas las actividades a su cargo que se encuentren plasmadas en los Documentos del Discovery, la Invitación, la Propuesta, el Cronograma, es decir, en los Anexos del presente Contrato”. (Resaltado del Tribunal).

En el numeral 4.11 dispusieron: “Proporcionar acceso al personal de DATAiFX a las instalaciones de la BOLSA, entendidas éstas tanto el espacio de oficinas, como el acceso a los equipos de telecomunicaciones y de computación y sistemas de esta, así como a cualquier otro equipo que sea razonablemente necesario con el fin de que DATAiFX pueda prestar los servicios señalados en el presente Contrato”. (4.11). (Resaltado del Tribunal).

DATAiFX, se obligó a ”Elaborar las historias de usuario con base en la información entregada por la BOLSA con el fin de llevar a buen término la elaboración de la Solución Tecnológica”( 5.8) y a “notificar e informar a la BOLSA de cualquier hallazgo, anomalía, dificultad, o evento sobreviniente que pudiera de cualquier forma modificar la duración del contrato o coste de este” (5.11). (Resaltado del Tribunal).

Finalmente y de acuerdo con lo expresado por las partes en el Contrato, declararon que: “Xxxxxxx y aceptan los documentos establecidos en el Contrato, especialmente los contenidos en la Invitación, la Propuesta, la Aceptación y los Documentos del Discovery” (6.1.) y que “Tuvieron la oportunidad de solicitar aclaraciones y modificaciones a los documentos del proceso y DATAiFX recibió de la BOLSA, respuesta oportuna a cada una de sus inquietudes.” (6.2.). (Resaltado del Tribunal).

Como se indicó al acotar los incumplimientos que se endilgan a la Bolsa, las partes disienten del alcance del objeto del contrato suscrito, en cuanto la contratante considera que con la información entregada por la BMC el Contratista debía y estaba en capacidad de desarrollar su labor de conformidad con el objeto contratado. Por su parte, el Contratista, atendiendo al significado de la palabra Refactoring, entendió que su trabajo se contraía a replicar en la nueva plataforma lo que ya se encontraba operando en el software que manejaba la contratante bajo un sistema moderno.

Es así como sobre el concepto de refactoring señaló el señor Xxxxx Xxxxxxx Xxxxx Xxxxxx, antiguo funcionario de DATAiFX, ingeniero de sistemas y especialista en arquitectura empresarial, en la declaración rendida el día 27 de noviembre de 2023 señaló:

“XX. XXXXXXX: [00:04:05] Muchas gracias señora presidente. ¿Señor Xxxxx podría ser tan amable de explicarnos en qué consiste el Refactoring?

XX. XXXXX: [00:04:15] Sí, el Refactoring dentro de las soluciones de software consisten en tomar capacidades de software existentes, eliminando la obsolescencia tecnológica, en este caso de EMC (sic), se planteaba, la aplicación del sistema de información que ellos tenían, tomarlo, reescribir el código en una arquitectura diferente usando AWS de Amazon y una arquitectura de microservicios. Entonces, reescribir esas capacidades de negocio con nueva tecnología, qué busca esto, eliminar obsolescencia tecnológica, porque pues el software que tiene o tenía BMC en ese momento, pues ya estaba sin soporte y bastante, no sé, como bastante obsolescencia

tecnológica.”46 (Resaltado del Tribunal).

Para el testigo, entonces, la actividad se limitaba a reescribir el código que utilizaría la BMC en una arquitectura diferente usando AWS de Amazon, teniendo en cuenta la obsolescencia del sistema sobre el cual venía trabajando la contratante.

Ahora, sobre las historias de usuario, base para la construcción del programa, señaló el testigo Xxxxx Xxxxxx lo siguiente:

“XX. XXXXXXX: [00:16:39] Gracias señora presidente. Podría puntualizar un poco a qué se refiere por historias de usuario, es decir, ¿si existen muchos usuarios y tienen sus propias funcionalidades o qué es una historia de usuario?

XX. XXXXX: [00:16:55] Sí, la historia de usuario es el documento que define cada una de las características que debe tener el sistema o el módulo que voy a construir, dentro de eso se consigna qué personas lo van a usar, cómo debe funcionar, qué salida va a tener el módulo o el componente que voy a desarrollar qué restricciones debería tener, eso es de la parte funcional; con ese documento, con esas características se inicia el proceso de construcción, obviamente con definición técnica también, esa es la historia de usuario.

Esas historias de usuario, pues para el alcance de este proyecto están enfocadas en lo que ya existe, en el módulo, en el software que ya estaba usando la Bolsa Mercantil, nuevamente, reitero el tema del refactoring, es reescribir el código con nueva tecnología, entonces esas historias de usuario, primero, se desviaron a esa otra definición técnica de dinamismo de que yo quisiera poder capturar cualquier tipo de información, textualmente que si la Bolsa Mercantil hubiese inventado un nuevo negocio, pues tenía que caber dentro de ese módulo, pues eso en términos de software se vuelve imposible, es otro

46 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

tipo de arquitectura, otro tipo de sistema, de otro tipo de proyecto, pues

básicamente eso con respecto a historias de usuario.”47 (Resaltado del Tribunal).

Por su parte, en punto de la entrega de la información señaló, ante la pregunta del apoderado de la Convocante:

“XX. XXXXXXX: [00:43:34] Xxxxxx Xxxxxxxx, y que él sorpresivamente les dijo que tenían una información o usted descubrió que tenía una información.

XX. XXXXX: [00:43:42] Sí, no sorpresivamente, nosotros la vimos y la solicitamos, él, digamos que en su compartir de pantalla vimos oiga, esa es la información que necesitamos.

XX. XXXXXXX: [00:43:54] ¿Por qué, por qué necesitaba esa información?

XX. XXXXX: [00:43:56] Esa información, como les digo nuevamente, era la información de las características funcionales que necesitábamos construir, igual fue muy tarde porque ya llevábamos año y medio de ejecución, entonces en ese momento ya como que, no nos servía de a mucho.

XX. XXXXXXX: [00:44:22] ¿Esa información no era precisamente a la que usted tenía que construir?

XX. XXXXX: [00:44:30] La información que yo tenía que construir. Yo tenía que construir unas historias de usuario, con base en unas capacidades de negocio existente; las historias de usuario las construimos las 120 que le conté, las capacidades de negocio existentes, que era lo que reposaba en esa información y no la tuvimos, la levantamos nosotros durante año y medio, y la levantamos con otra visión, como le dije, no de Refactoring, sino de una vaina dinámica, agnóstica, que sirviera para todas las líneas de negocio.

Claro, nosotros tenemos que escribir historias de usuario y buscar la aprobación, la validación, porque como les dije, este es el insumo, entonces esa información que les cuento, la información de cómo funciona el sistema, los sistemas que teníamos, los módulos, el detalle, tenía hasta cronograma, pero bueno, pues digamos que el cronograma no, pero la información de esas capacidades de cómo funcionaba esa sí

era súper relevante para nosotros.”48 (Resaltado del Tribunal).

47 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

48 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

Respecto del alcance del contrato de Refactoring, refirió el testigo:

XX. XXXXXXX: [00:48:05] Gracias. Manifestó usted que la BMC quería que cualquier nueva necesidad tecnológica tuviera la posibilidad de ensamblarse ahí, de ser utilizada allí en lo que ustedes estaban trabajando, le pregunto, ¿eso tiene algo que ver con el tema de que acaba de explicar de ser agnóstico o son temas distintos?

XX. XXXXX: [00:48:28] No, es por esa línea, es igual a esa línea. XX. XXXXXXX: [00:48:30] ¿Podría explicar, por favor?

XX. XXXXX: [00:48:32] Claro. La BMC tiene cinco negocios, negocio de registro de facturas, el negocio de, no sé, se me olvidó el término, registro mercantil, la información que se registra para ese negocio debe pasar por ese componente, almacenarse y cumplir las reglas de negocio, la necesidad de no alcancé, si yo mañana pienso en otro negocio diferente, oiga voy a negociar acciones, ese modelo debería soportarlo, entonces eso es lo que hace que el esfuerzo y la pensada y la construcción de ese componente fuera diferente, porque tiene que estar preparado para cualquier cosa, qué, pues, no sé, y qué reglas de negocio voy a tener para capturar, tampoco sé, y cuál es la salida, tampoco sé.

Entonces fíjense que ya no es Refactoring, ya es un componente que me pueda soportar cualquier cosa, y en términos de un cronograma establecido por unos módulos específicos llegar a esta construcción, eso, pues digo que eso no es imposible construir, sino que requiere un alcance

diferente y unos tiempos diferentes.”49 (Resaltado del Tribunal).

Para el deponente se debía partir del software existente y sobre sus funcionalidades escribir nuevamente el código que permitiría a la BMC realizar su CORE de negocios.

Por otro lado, en el interrogatorio del representante legal de DATAiFX, en cuanto al objeto del contrato de Refactoring señaló:

“XX. XXXXXXX: [00:17:08] Claro sírvase indicar con toda exactitud que quede claro que eso lo estoy tomando textualmente de la contestación de la demanda en qué consistió la manipulación por parte de la BMC del acceso a la información requerida con el objeto de obtener algo por lo que no había pagado?

XX. XXXXX: [00:17:36] Nosotros suscribimos un contrato de re factoring, que es coger un software que está en tecnología vieja y pasarlo a tecnología nueva y para eso hay unos alcances limitados en múltiples ocasiones la bolsa Mercantil en el tema del levantamiento

49 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

de información manifestó que quería que fuera un programa agnóstico quiere decir que cualquier tipo de actividad comercial que pudiera transarse en un mercado pudiera caber dentro del software y eso es abiertamente superior al alcance de pasar un software de lo que hace, hoy a lo que va a seguir haciendo dentro de unos lenguajes y una arquitectura más acorde a la tecnología actual.”

“XX. XXXXXXX: [00:18:42]. Pregunta No. 13. Sírvase indicar con toda exactitud cuál fue el software totalmente nuevo que creciera indefinidamente en la medida en que crecieran los negocios de la Bolsa mercantil que la Bolsa Mercantil le exigió elaborar a DATAiFX?

XX. XXXXX: [00:18:56] Era un software indeterminado que pudiera servir para cualquier cosa.

XX. XXXXXXX: [00:28:14] Pregunta No. 6. Por qué no nos cuenta algo, era posible prever desde el punto de vista financiero, antes de suscribir el contrato estas eventuales dificultades, que a la postre tuvo en su ejecución, para precaver ese debacle que usted nos acaba de contar.

XX. XXXXX: [00:28:40] No, la verdad no, yo partí la verdad es que yo conocía bastante bien a la Bolsa mercantil, previo a estos dos contratos, nosotros le hicimos un estudio de arquitectura empresarial y qué es la arquitectura empresarial, la arquitectura empresarial es venga cómo está usted, en sus sistemas cuál es entonces uno lo parte con el Asis y el Tubi, Asís es como lo tengo hoy y xxxxx como lo quisiera tener.

Entonces nosotros llegamos y les pintamos venga esto es lo que ustedes tienen y qué es lo que tenía la bolsa, la bolsa tenía a qué me estoy refiriendo mucho al contrato de re factoring, principalmente lo que tenía la bolsa era un sinnúmero de softwares que se hicieron de manera independiente que de alguna manera se tenían que interconectar y el uno que necesitaba información del otro entonces se generaban unos procedimientos para jalar información y para llenarse ida y vuelta y se armaba un tema relativamente complejo de mantenimiento de eso.

(…)

Nosotros conocíamos qué era lo que necesitaba la bolsa y dentro de la propuesta que nosotros hicimos, sabíamos que lo podíamos lograr con el entendimiento de qué es lo que hacía hoy la Bolsa qué es lo que empieza a pasar en el desarrollo del contrato es que al quererlo volver agnóstico yo ya quiero que se pueda negociar un tema de opciones futuras sobre café y el mercado de café no existe en la bolsa entonces yo tenía que desarrollar un software que en la hipótesis que ellos quisieran jugar con opciones de café, eso cupiera dentro del sistema a ellos y les dijimos muchas veces

venga, eso es imposible no hay ningún software que pueda hacer eso en el mundo.

Entonces nos dijeron hágalo lo más paramétrico posible y entonces ahí cuando paramétrico, es que yo le dejé la mayor cantidad de variables administrables dentro del sistema para que un eventual caso que llegue requiera el menor desarrollo posible, porque tengo muchas variables contempladas y en eso hicimos una labor que hoy ya es más un romanticismo mío del mundo de la tecnología muy fuerte y muy chévere porque logramos en el motor de registro, en el motor de reglas, en un tema de la generación de parámetros, hacer algo muy robusto donde le cabían muchas cosas.

Y parte de lo que hicimos que creo que es de gran valor sirve de base para todo lo que no se alcanzó a hacer porque muchas de las cosas futuras había un porcentaje muy alto de parametrización frente al tema de desarrollo de código nuevo entonces no sé si me fui por las ramas y

si contesté la pregunta.”50 (Resaltado del Tribunal).

El Tribunal resalta, para la solución de la controversia, el conocimiento que la convocada tenía de la operación comercial que adelantaba la BMC, porque había hecho estudios previos y conocía las debilidades de la organización y su posible solución. También evidencia que el problema estaba en el alcance del Contrato, porque la BMC quería un software agnóstico, es decir, que tuviera la posibilidad de realizar a través de la plataforma cualquier tipo de negocio futuro y, por ello, señaló que para tratar de dar cumplimiento a la exigencia del contratante (acordada por ambas partes en el Contrato) llevaron a cabo una parametrización con la mayor cantidad de variables posibles.

En un sentido similar al que plantea el representante legal de DATAiFX, las testigos Xxxxx Xxxxxxxx Xxxxxx Xxxxxx y Xxxxxxxx Xxxxxxxxx Xxxxx Xxxxxxxx, funcionarios de la BMC, señalan al unísono que el concepto de Refactoring, como lo entiende la convocada, no fue el propuesto ni en la RFP, ni en el Contrato, señalando además que intervinieron en su fase preparatoria.

Sobre el tema, en efecto dijo la xxxxxx Xxxxxx Xxxxxx:

“XX. XXXXXXX: [00:24:13] Gracias ¿Y qué se pretendía con la celebración del contrato refactoring?

XXX. XXXXXX: [00:24:20] Bueno, digamos que el objetivo de este contrato era tomar toda esta funcionalidad que tenemos sobre todos estos sistemas, hacer una abstracción de las reglas de negocio que se tienen implementadas sobre el mismo, sobre los mismos sistemas y organizar de una manera distinta, como les decía, estos son sistemas acoplados rígidos, es decir, hoy por hoy, de hecho nos prestan la operación pero son rígidos, queríamos

50 Expediente Virtual 141365 – Transcripciones – 142365 Xxxx Xxxxx Xxxxx Xxxxxx

abstraer las reglas de negocio a través de un modelo de arquitectura distinto, que fuera más compatible con la nube, que fuera más flexible a través de microservicios, de manera que yo pudiera tener diferentes funcionalidades implementadas en microservicios. De manera que yo pudiera ir activando una u otra funcionalidad e ir conformando. (Subrayado fuera del texto)

Por ejemplo, para un nuevo negocio que llegara a la bolsa, bueno este negocio necesita compensación aquí tengo la herramienta o el servicio de compensación, lo activo onboarding y aquí tengo onboarding de los productos que se van a hacer por ese negocio, aquí tengo un servicio de liquidación listo es este servicio y hacer pequeños ajustes y ya. (Resaltado y subrayado fuera del texto)

Hoy por hoy qué nos toca hacer y desde que empezamos refactoring que hemos venido teniendo que hacer, construir prácticamente xx xxxx. Entonces llegó un negocio nuevo, entonces toca volver desde ceros a construir todo eso y no es posible aprovechar esas funcionalidades que ya tenemos, ese era como como el objetivo y lo decíamos en el RFP que no era rehacer lo que ya teníamos como lo teníamos, era abstraer de todos estos sistemas, esas reglas de negocio para construirlo bajo la nueva concepción.”

XX. XXXXXXX: [00:26:09] ¿Esa última manifestación suya les quedó clara a los proponentes que pretendían celebrar el contrato de refactoring?

XXX. XXXXXX: [00:26:19] Sí, mire que en la etapa de las propuestas, bueno como lo digo en el RFP, primero está y está explícito que no se trata de replicar tal cual los módulos como se tienen hoy en día, no. Ahí se dice que es abstraer las reglas de negociación y traducir eso a microservicios bajo la nueva arquitectura y demás, y construir el sistema.

Incluso hicimos sesiones aclaratorias con todos los proponentes donde se lo explicábamos nuevamente, incluso les hicimos recorridos en esas sesiones, sobre los diferentes sistemas que tenemos para que tuvieran como un dimensionamiento ya visual de

que era todo eso que nosotros estábamos solicitando.”51(Subrayado del Tribunal).

De acuerdo con el testimonio anterior, además del conocimiento previo de la Convocada respecto a los sistemas de la Bolsa, antes de suscribir el Contrato se les explicó el entendimiento que sobre la nueva herramienta tenía la contratante, es decir, la construcción de un código nuevo que permitiera la incorporación de futuras funcionalidades, lo cual se reflejó especialmente en el RFP.

Por su parte, sobre este aspecto el señor Xxxxx Xxxxxxxx, igualmente señaló:

“DRA. XXXXXXX: [00:26:29] ¿En ese contrato de refactoring había que desarrollar un software o entiendo que solamente coger el software que tenían ellos y mandarlo allá a esa nube que usted nos dice?

XX. XXXXX: [00:26:40] ¿No, había que desarrollar un nuevo software. Toda la plataforma de nosotros ya estaba en la nube de AWS sobre ciertos sistemas. Nuestros sistemas ya estaban funcionando y son tipo acoplado, qué se estaba pidiendo hacer ahorita, lo que yo tenía del sistema desacoplarlo para agarrar las funcionalidades de la nube y que fuera como lo que se llama microservicios, que es descomponer la aplicación, nosotros en el sistema hoy en día en el sistema electrónico bursátil, hay un proceso donde está la notificación y el reporte, pero usted está contemplado en un solo sistema.

Nosotros lo que pedíamos era a hacer a nivel de microservicios o separación de los componentes desacoplados, yo necesito que tenga un componente de notificación, de forma que si yo pongo cualquier otro sistema que esté desarrollando yo pueda mandar con solo este notificación lo que necesito, sea notificación a correo electrónico, sea notificaciones a celulares.

Entonces qué se pedía, ya nosotros sabíamos que funcionaban nuestros sistemas, si no se pedía crear un nuevo sistema desde cero que lleve toda la funcionalidad y las reglas del negocio de este nuevo componente, qué nos permitía eso, que con esta modernización si yo necesitaba generar un nuevo sistema, no tenía que generar todo el sistema de notificación, reporte auditoría, sino que ya reutilizaba los que ya tenía y solo generaba los módulos necesarios adicionales para el nuevo

negocio.”52 (Resaltado del Tribunal).

Se deduce de este último testimonio que era claro para todos aquellos que participaron en la invitación a ofertar que el sistema solicitado por la BMC era la construcción de un software nuevo, para pasar de un sistema anacrónico a un sistema novedoso y flexible en la nube a través del servicio de AWS.

De las estipulaciones contractuales, así como de los relatos arriba transcritos, el Tribunal interpreta que la obligación que se le planteaba al Contratista no era simplemente la de reescribir el código obsoleto existente, pues el programa se debía realizar con el levantamiento de las historias de usuarios para la agregación en el futuro de eventuales aplicaciones que permitieran el posible desarrollo de nuevas líneas de negocios, lo cual no permitía el software existente.

La palabra software agnóstico ha enrarecido la interpretación del Contrato, frente a lo cual el Tribunal insiste en que tal concepto incluía la posibilidad de

52 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxxxxxx Xxxxx Xxxxxxxx

desarrollar y adicionar por cuenta de la BMC nuevas aplicaciones ante eventuales oportunidades de negocios.

Ello también de conformidad con el Contrato, en cuyo considerando número 4 aparece claramente que la BMC buscaba transformar los CORE actuales en unos que “puedan dar una mayor eficiencia, escalabilidad y sean adaptables a las últimas tendencias tecnológicas”, es decir, tener la posibilidad de desarrollar nuevas alternativas de negocios, en un área tan dinámica como es la intermediación comercial en la colación de bienes y servicios, que constituía la actividad principal de la BMC.

En tal sentido, no constituyó un incumplimiento del Contrato, ni un abuso de sus facultades, ni una actitud de mala fe, la circunstancia de que la BMC exigiera que el alcance del programa se realizara bajo los términos descritos, pues así fue pactado y discutido desde la etapa precontractual y de tal manera quedó reflejado en el Contrato y en los documentos que lo complementaron.

En cuanto a la glosa realizada por la parte convocada por la falta de entrega de la información y la inexistencia de contacto directo con los usuarios finales, desde el Contrato mismo se señaló que la BMC entregaría la información que considerara necesaria.

En este sentido, en la declaración rendida Xxxxx Xxxxxxx Xxxxx Xxxxxx, dicho testigo señaló:

XX. XXXXXXX: [00:06:23] Para el desarrollo de esos módulos se requería levantar información, nos podría explicar, ¿cómo fue la fase de levantamiento de información o qué tipo de información recibió DATAiFX?

XX. XXXXX: [00:06:36] Bueno, sí, en este tema de refactoring, como les decía, como es reescribir lo que ya existe, la primera necesidad es conocer el software existente, entrar al sistema, validar su funcionamiento, corroborar que los módulos de alcance estén funcionales, mirar cuál es el flujo de la información.

Entonces, digamos que, en primera instancia era necesario conocer el software, nosotros realmente nunca conocimos el software, levantamos unas historias de usuario; las historias de usuario son el detalle de esas funcionalidades, específico, que deberían estar alineadas a esos refactoring, a las capacidades de negocio ya existentes, o sea, al registro, notificaciones, lo que les contaba.

Por su parte, DR. SERENO: [01:01:06] Una última pregunta. Usted manifestó que, o sea, dentro del contrato hay una obligación de recoger una información para desarrollar el proyecto; se ha manifestado que había una información previa que estaba en poder de la BMC que no les

fue entregada, la pregunta es, ¿si usted tiene conocimiento por qué la BMC no les entregó esa información?

XX. XXXXX: [01:01:33] No, no señor, no señor. Nosotros iniciamos nuestro proceso de levantamiento de información, como les digo, sin llegar al usuario final, lo que recogimos de la ingeniera Xxxxxxx, lo que recogimos de los decretos que nos pusieron a leer, y con eso escribimos, pero no más, bueno, tal vez documentación adicional que escribimos en compañía xx Xxxxxxx en las reuniones, digamos hasta ahí, y lo que les contaba del director de operaciones, con el director de

operaciones levantamos información, alto nivel.”53 (Resaltado del Tribunal).

Según esta declaración DATAiFX no tuvo acceso al programa que debían reescribir ni a los usuarios funcionales, lo cual, en su criterio, dificultó la realización del trabajo, pero el testigo admite que construyeron las historias de usuario que son la base fundamental de la obligación de realizar el Discovery, por cuanto éste, es el punto xx xxxxxxx para estructurar el cronograma que permitía desarrollar el proyecto de construcción del software. Dijo que “siempre teníamos de frente a la ingeniera Xxxxxxx” la persona que maneja el tema funcional en la BMC, delegada por la entidad para entregar al contratista la información que la contratante considerara pertinente para adelantar el proyecto.

¿Se pregunta el Tribunal, entonces, cómo pudieron construir historias de usuario si no se les entregó la información?

Por otro lado, sostienen los testigos Xxxxxx Xxxxxx y Xxxxx Xxxxxxxx, que de acuerdo con la metodología del Contrato, la información sí fue entregada.

“XX. XXXXXXX: [00:28:56] ¿Usted participó en la fase de análisis del levantamiento de las reglas del negocio?

XXX. XXXXXX: [00:29:05] No en todas las sesiones, en algunas sesiones estuve yo. Digamos que de mi equipo estaba otra persona, Xxxxxxx Xxxxxxxx, que sí estuvo acompañando y también DATAiFX tenía sesiones directas con los usuarios funcionales, directamente de las áreas.”

XX. XXXXXXX: [00:46:57] En la parte en la que usted trabajó o en la parte en la que usted desarrolló sus funciones ¿usted puede señalar que se le entregó toda la información que DATAiFX solicitaba para desarrollar su trabajo?

XX. XXXXX: [00:47:15] Sí, se le entregó información y adicionalmente hubo muchas sesiones técnicas, en donde nosotros le decíamos cómo queríamos hacer sistema. En algunos casos cómo podían ellos

53 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

definir la estrategia, cómo podían hacer las integraciones en las dudas que ellos tenían para poder aclararles y ellos poder avanzar en ese punto.”54 (Resaltado del Tribunal).

Lo anterior se corrobora con lo señalado por el señor Xxxxx Xxxxxx, quien manifestó:

“XX. XXXXXXX: [00:44:22] ¿Esa información no era precisamente a la que usted tenía que construir?

XX. XXXXX: [00:44:30] La información que yo tenía que construir. Yo tenía que construir unas historias de usuario, con base en unas capacidades de negocio existente; las historias de usuario las construimos las 120 que le conté, las capacidades de negocio existentes, que era lo que reposaba en esa información y no la tuvimos, la levantamos nosotros durante año y medio, y la levantamos con otra visión, como le dije, no de Refactoring, sino de una vaina dinámica, agnóstica, que sirviera para todas las líneas

de negocio.”55 (Resaltado del Tribunal).

Al analizar las declaraciones anteriores en conjunto se puede colegir que la BMC entregaba la información relativa a los negocios que actualmente operaba y, sobre ella, bajo la modalidad de ejecución del contrato acordado, se fueron construyendo las historias de usuario y se solicitaron ajustes para lograr el objetivo propuesto.

No podemos olvidar que la metodología RUP-SCRUM fue propuesta por la convocada y que a partir de su experiencia sabía o debió saber cuáles eran las consecuencias de esa decisión negocial, más aún cuando ya había realizado un estudio previo sobre las necesidades de la BMC.

Por tanto, el Tribunal concluye que la BMC si aportó la información para la construcción del software contratado, toda vez que XXXXxXX logró construir según el dicho del testigo, 120 historias de usuario, no obstante que las partes diferían del enfoque que tenía el proyecto, es decir, reescribir el código existente o crear uno nuevo que albergara las funcionalidades del anterior y que permitiera la ampliación o recepción de nuevas líneas de negocios.

Por otro lado, en cuanto al relacionamiento con los usuarios, en parte alguna del Contrato se señaló expresamente que la BMC estuviera en la obligación de poner en contacto directo al contratista con aquellos. Lo que allí se indicó es que se le entregaría la información necesaria, obviamente sobre la operación del negocio para poder desarrollar su labor, entre otras cosas, porque DATAiFX, sabía del giro de los negocios de La Bolsa, por cuanto ya había prestado servicios previamente, entre otros temas, en materia de gas, como ella misma lo señaló en su demanda de reconvención (Hecho 2.1.1.3).

54 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxxx Xxxxxx Xxxxxx

55

Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxxx Xxxxx Xxxxxx

En este punto considera oportuno el Tribunal traer x xxxxxxxx lo expuesto por el profesor Xxxxxxxx Xxxxxxxxxx quien anota que “… parecería lo más indicado sustituir la expresión “acto jurídico” por la más perspicua de “negocio jurídico”, comprensiva de los distintos medios del ejercicio de la autonomía privada, es decir, dentro de la categoría de los actos lícitos, de todos aquellos actos cuya razón de ser y función es la disposición de intereses, y solamente ella”56.

Agrega el citado autor: “Entendidas acá las cargas como aquellos deberes en los cuales la persona habiendo escogido entre varios intereses suyos uno determinado, ha de hacer esfuerzos y sacrificios (actos necesarios) para alcanzarlo, en esta perspectiva, hablando de autonomía privada y de su ejercicio, es preciso tener en cuenta los cuidados y miramientos que incumben a cada sujeto negocial, si que también a quien aspira a serlo o ya no lo es. Así, la carga de legalidad, la de lealtad y corrección, las cargas de claridad, de previsión, de plenitud, de sagacidad, de advertencia. Su incumplimiento, o sea el no realizar el o los actos necesarios del caso, exponen al sujeto a verse en condiciones adversas, al no poder disfrutar de la protección del derecho o no poder oponer el suyo a otras personas, o a ser calificado adversamente”57

En línea con lo señalado por el profesor Xxxxxxxxxx, la parte debe cumplir, no sólo con el nexo obligacional, sino además, en las etapas preliminares y durante la ejecución del Contrato, desplegar todas aquellas cargas - conductas- en procura de la protección de sus propios intereses, so pena de verse expuesto y no poder disfrutar de la protección del derecho o no poder oponer el suyo a otras personas, o a ser calificado adversamente.

Por las razones anteriores, el Tribunal en torno a este Contrato acogerá la excepción planteada por la convocante y reconvenida “AUSENCIA DE PRUEBA DEL INCUMPLIMIENTO DE LAS OBLIGACIONES CONTRACTUALES A CARGO DE MI MANDANTE”.

4.2. Contrato de Back Office

En el Contrato CO-2020-0060 del día dos (2) de diciembre de 2020, denominado: “Prestación de servicios tecnológicos para el análisis, diseño y desarrollo de la solución tecnológica para el proyecto Back Office”, en el numeral cuarto de las consideraciones expresamente se indicó:

“CUARTO: Que la Bolsa identificó la necesidad de establecer una sinergia entre sus actividades propias y las de las diferentes Sociedades Comisionistas de la Bolsa (en adelante SCB) con el fin de incentivar el correcto desarrollo de los procesos operativos y de interacción de las SCB con la BOLSA; dándole seguridad al mercado, centralizando la información, simplificando la actividades, mejorando los tiempos de respuesta, generando fluidez en las

56 Xxxxxxxxxx, X. (2015). Tratado de las Obligaciones II, De las Fuentes de las Obligaciones. El Negocio Jurídico.

Volumen I. Pág. 66. Universidad Externado de Colombia

57 Xxxxxxxxxx, X. (2015). Tratado de las Obligaciones II, De las Fuentes de las Obligaciones. El Negocio Jurídico.

Volumen I. Pág. 382. Universidad Externado de Colombia

comunicaciones, fortaleciendo las relaciones entre los diferentes actores, generando un mayor valor a los clientes, reduciendo costos, entre otros beneficios”.

QUINTO: Que, con base en lo manifestado en el considerando anterior, LA BOLSA, decidió adelantar un proceso de contratación con el fin de adquirir los servicios profesionales para el diseño y desarrollo de una Solución Tecnológica que permita integrar los diferentes procesos administrativos relacionados con el Back Office de las SCB, y que a su vez, fomente el desarrollo y la interacción del funcionamiento de sus sistemas en los de la BOLSA”.

SEXTO: Que DATAiFX   ha acompañado a la BOLSA, en sus diferentes desarrollos tecnológicos y de sistemas, y por tal motivo, resulta eficiente que este mismo proveedor desarrolle las aplicaciones que permitan integrar las aplicaciones de las SCB con las aplicaciones actuales y futuras de la BOLSA. (Resaltado del Tribunal).

SÉPTIMO: Que la BOLSA evaluó la propuesta presentada, determinado la suscripción del presente Contrato con DATAiFX, dado que cumple con las calidades técnicas exigidas, trayectoria y seriedad requeridas, y además ofrece condiciones de precio y plazo acordes con la conveniencia de LA BOLSA. OCTAVO: Que LAS PARTES entienden que poseen la capacidad y la experiencia necesaria para desarrollar el objeto del presente contrato y, por ello, manifiestan su ánimo de celebrarlo”. (Resaltado del Tribunal).

En cuanto al alcance de esta solución tecnológica y la forma en que fue desarrollada, particularmente por el requerimiento de la Superintendencia, el testigo Xxxxxxxx Xxxxxx Xxxxxxxxxxx Xxxxx, quien trabajó para DATAiFX, señaló:

XX. XXXXXXX: [00:11:22] Listo. ¿Explique en qué consiste el proyecto de back office?

“XX. XXXXXXXXXXX: [00:11:32] Bueno, el proyecto de back office en el cual yo estaba al frente, el proyecto tenía que ver con una integración, un proyecto robusto, que nosotros le íbamos a entregar a unas firmas comisionistas; este proyecto dependía de 14 módulos, si no me equivoco en este preciso momento, de los cuales nosotros estábamos adelantando tres módulos que debían salir a producción; salir a producción en qué sentido, en el sentido en que por una premura con la Superintendencia, fue necesario que nosotros abarcáramos solamente estos tres módulos como tal.

Esto nosotros lo sacamos con el objetivo de cumplir con esta solicitud o con esta normativa que nos está dando la Superintendencia en ese momento, y esto hizo cambiar pues como los planes del proyecto, en qué

sentido, en que nosotros teníamos que trabajar completamente todos los módulos, y al final pues se hacía una entrega completa; con esta normativa que sale, que era más que todo para el libro electrónico de órdenes, que es el que nosotros conocemos como XXX, y en el proyecto lo conocemos como el módulo de LEO, esto fue lo que nos hizo cambiar las, digamos, las circunstancias y como el plan de trabajo que llevamos en ese momento.

Adicional a eso, teníamos también al principio solamente que íbamos a trabajar un módulo, una versión que le entregábamos a las personas de la Bolsa, que pues en ese caso yo trabajaba directamente era con el señor Xxxx Xxxxx, con Xxxxx Xxxxxxxx, que era como mi partner en ese momento, y le estábamos apuntando a solamente a esta URL o este acceso a la página para que ellos pudieran hacer las pruebas.

Por la normativa y por este tema de la Súper, lo que tocó hacer fue que nos tocó crear esta versión ya para nueve clientes, nueve firmas diferentes, o sea el primer, el proyecto que teníamos convertirlo en 10 URL totalmente diferentes, en este momento, pues que nos tocó hacer, reunirnos con el señor Xxxxx Xxxxxxxx con cada una de las firmas y empezar a solicitar toda la información que necesitábamos, porque no la teníamos como lo que eran logos corporativos, paletas de colores, toda esta situación, pues empezó a generar unos retrasos, había temas que pues todavía no se tenían detallados completamente, por esa razón pues nos tocaba reuniones constante con las firmas para poder llevar este producto a buenos términos, lo que íbamos a sacar.

De estos módulos, lo que se proyectó en ese momento para cumplir con la Súper fueron tres módulos, que era el de parámetros del sistema, vinculación digital y lo que tiene que ver con el libro electrónico de órdenes; durante todo este transcurso nosotros tuvimos reuniones prácticamente semanales, más o menos como de a tres firmas, cuando hablo de firmas pues me refiero a las firmas comisionistas, en las cuales se agendaba estos espacios para mostrarles a las firmas cómo iba el proyecto, qué íbamos avanzando y con esto obtener un okey por parte de ellos para poder salir a producción en ese preciso momento.

La salida a producción nosotros la hicimos el 30 de septiembre, y a partir del 1 de octubre empezamos a recibir el respectivo feedback de cada una de las firmas; cada vez que lo iban utilizando directamente en producción ellos iban validando y nos iban reportando a nosotros temas que tocaba empezar a ajustar.” (Resaltado del Tribunal).

Y más adelante agrega el mismo deponente:

“El momento en que nosotros entregamos este módulo, que pues inicialmente salía como un mockup o como una parte dumi, demo, para

poderlo manejar fue necesario que, como se iba a demorar tanto la integración para tener esa respuesta con Xxxxx, pues no era un servicio que nosotros fuéramos a construir, sino que nos tenía que entregar Bolsa a nosotros; como se iba a demorar este servicio, pues cogimos este demo y empezamos a integrarlo y empezamos a darle una funcionalidad; por esa razón cuando nosotros salimos a producción con un producto mínimo viable, este producto con qué sale, con los tres módulos que estaban contemplados en el proyecto, más dos módulos adicionales que fueron construidos y no quedaron por ningún lado, digámoslo así, inscritos en historias de usuario o requerimientos de todo el RFP que se tenía.”

“En esas reuniones también hubo un momento en que se hizo una reunión con el señor Xxxx Xxxxx, con Xxxx Xxxxx Xxxxx, pues con Xxxx, estaba yo presente, y se empezó a revisar de lo que nos quedaba, qué era bloqueante en el sistema, o sea que sí era obligatorio trabajarlo en ese momento, qué no era bloqueante, y qué se iba para una segunda fase, y qué cosas definitivamente no aplicaban en el sistema, o sea, con las cuales no se iba a continuar, porque pues podría ser algo temas de customizar el sistema a lo que quería la firma en ese momento, pero pues como era el proyecto, y pues como lo mencionaba el mismo señor Xxxx Xxxxx, todo iba igual, todas las firmas lo utilizaban igual, lo único que cambiaba era el tema de los colores, pues los logos corporativos.”

“XX. XXXXXXX: [00:24:45] La siguiente pregunta, ¿podría explicarnos en qué consistió el módulo LEO y a qué se refiere con ese requerimiento de la Superintendencia Financiera?

XX. XXXXXXXXXXX: [00:24:55] Este módulo tenía que ver con el libro electrónico de órdenes, en el cual la Superintendencia, pues hasta donde recuerdo, estaba haciendo solicitud de cambiar la manera en que lo manejaban anteriormente, por esa razón nació la parte de del back office y estaba anexándose este módulo, porque era un módulo mucho más robusto para poder hacer todas estas operaciones de manera automática.

XX. XXXXXXX: [00:25:23] En ese sentido, ¿se informó previamente o tenía conocimiento de este tipo de requerimiento por parte de la Superintendencia Financiera antes de iniciar el desarrollo de ese módulo?

XX. XXXXXXXXXXX: [00:25:35] No señor, pues hasta donde yo tengo entendido todo iba en el cronograma, igual que lo que mencionaba la parte del soporte; el soporte nosotros lo teníamos que entregar era cuando ya se terminara todo el proyecto, pero pues esta salida y esta solicitud de la Super, nos hizo cambiar pues esa parte y empezar a dar

soporte también a lo que ya estábamos entregando”.58 (Resaltado del Tribunal).

Sobre estas vicisitudes, para el Tribunal es pertinente señalar nuevamente que el sistema fue propuesto en módulos para su desarrollo bajo la modalidad rup- scrum, es decir con entregas parciales (Sprint), que permitía a las partes realizar un seguimiento y ajustes a los trabajos adelantados. Por ello, el hecho de priorizar el módulo Leo junto con los dos módulos previos (parámetros y vinculación del sistema), teniendo en cuenta la modalidad de ejecución del contrato, no implicó, como lo señala la demandada, una afectación seria y relevante en el desarrollo del proyecto. Además, es preciso resaltar, que desde la Invitación quedó establecido que los primeros módulos que debían desarrollarse eran los de Parámetros del Sistema, Vinculación y Leo.

Precisamente, frente a lo relativo a la priorización del libro de órdenes XXX y su posible incidencia en el cronograma, el mismo testigo Xxxxx indicó:

XX. XXXXXXX: [00:11:12] Concentrémonos en el libro electrónico de órdenes esa actividad o ese módulo ¿Tuvo alguna priorización por orden de la bolsa mercantil?

XX. XXXXX: [00:11:27] Sí.

XX. XXXXXXX: [00:11:28] A nivel de priorización, más allá de la priorización de la bolsa, era que como lo nombré, estaba todo el tema de la parametrización, la vinculación y de terceras estaba el libro electrónico para sacar el libro electrónico a producción, pues necesitaba parametrización y vinculación y explico un poquito el por qué necesitamos el libro electrónico de órdenes desde el punto de vista de bolsa, la parametrización es donde yo voy a ingresar los usuarios, los cuales pueden ingresar al sistema desde el punto de vista, llámese el trader, llámese el comisionista o llámese el operativo o el oficial de cumplimiento, que son los que pueden validar cuales son esos clientes del cliente de la sociedad comisionista.

A partir de ahí hago la parametrización, después hago la vinculación, en la vinculación, obviamente en compañía de Data hicimos todo el tema de vinculación desde el punto de vista de la información que se necesitaba a nivel de la información básica del cliente, entiéndase la cédula, el nombre, primer apellido, segundo apellido, fecha de expedición, todas implicaciones que tiene que más o menos eran unas

272 campos que teníamos que ingresar desde el punto de vista de vinculación, más todo lo que conllevaba a los anexos, los anexos de la fotocopia de la cédula, si era persona natural, si era obviamente existía el apoderado o el que daba las instrucciones, en este caso obviamente los voy a llevar un poquito al libro electrónico, no es necesariamente la misma persona que es el cliente es el que da las instrucciones.

58 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxxx Xxxxxxxxxxx Xxxxx

Entonces aparece el ordenante que lo vamos a en el libro electrónico y a partir de ahí si tenía un tema financiero, cuál es la relación que tenía con la compañía, si conocía la sociedad comisionista, si no conocía la sociedad comisionista, el tema de cuentas bancarias, todo eso era el tema de la vinculación como tal, con esa información en vinculación hay un una parte donde se decía qué tipo de operaciones usted va a realizar ante la bolsa, va a ser registro de facturas, va a ser el mercado de compras públicas y el mercado de compras públicas va a ser comprador o vendedor en el mercado de compra entre privados va a ser usted comprador o vendedor en el de financieros usted va a ser realmente operaciones repos, o sea, operaciones con pacto de recompra financieramente, cómo lo van a manejar y si en algún momento se tenía convenios con el Ministerio de Agricultura, hay un tema de vinculación

Con esa información llegábamos ya al libro electrónico de órdenes por qué hago esa historia porque dentro del libro electrónico de órdenes es todas las operaciones que pasen por bolsa alguien tiene que dar esa instrucción, esa instrucción puede ser a través del medio verificable, puede ser teléfono, puede ser escrito o puede ser a través de un correo electrónico, esa información era la que llegaba al libro electrónico de órdenes. Con esa información se empezaba a capturar la orden, en la orden quien tiene que quedar en la parametrización hablábamos del comisionista, entonces en ese momento estábamos ingresando, si efectivamente quién fue el que le dio la instrucción, si fue el cliente el ordenante que previamente estaban en la vinculación o el mismo cliente como tal daba la instrucción de comprar o vender una actividad de las que había hecho anteriormente a nivel de la bolsa y se registra esa información si esa información no queda registrada, por ende el comisionista no puede ir a hacer negociaciones en la bolsa ese es el libro electrónico.

XX. XXXXXXX: Y por qué se priorizó ese módulo o esa actividad de elaboración del libro electrónico del libro?

XX. XXXXX: [00:14:59] La priorización se dio a mediados xx xxxxx, después que inclusive nosotros comenzamos desarrollos a finales de enero, comienzos de febrero y se priorizó en marzo por qué, porque a través de la misma bolsa, en unos capítulos a nivel del reglamento se les decía a las sociedades comisionistas de Xxxxx que tenían que tener un libro electrónico a través de un requerimiento que un año atrás le había hecho la Superintendencia Financiera a las 10 sociedades comisionistas donde ellas tenían que tener ese libro electrónico como su nombre lo indica, el libro electrónico de ordenes electrónico hoy por hoy, en su momento, las firmas comisionistas que tenían el libro electrónico, pero algunas las tenían en Excel y otros lo tenían con unos back office que realmente ellos manejaban pero un poco desactualizados a nivel de desarrollo.

La Bolsa qué hizo en su momento, es decir, los vamos a apoyar y los vamos a hacer, pero justo cruzó el tema de priorización qué tenemos que hacer primero, pues démosles orden a estos tres proyectos, a estos tres primeros módulos, démosle la priorización para poderlos sacar, en su momento la bolsa decía que teníamos que sacarlos en junio, pues obviamente los terminamos sacando en octubre y realmente eso fue lo que se hizo. Por eso el tema de la priorización que se le dio a estos tres primeros módulos.” (Resaltado del Tribunal).

En cuanto a los efectos de la priorización y los efectos sobre el tiempo de ejecución del contrato señaló:

“XX. XXXXXXX: [00:16:54] En su criterio, esa priorización la actividad o el módulo de libro electrónico de órdenes significó una modificación de las obligaciones de ese contrato que usted dice conocer.

XX. XXXXX: No, porque estaban inclusive en orden que como las acababa de nombrar parametrización, vinculación, libro electrónico, después seguía ID y registro de facturas y mire que lo estoy nombrando en orden y esos tres se les dieron en orden.

XX. XXXXXXX: [00:17:18] O sea, no hubo una alteración del orden de las actividades?

XX. XXXXX: No.

DRA. BARRIOS: [00:17:25] No hubo alteración en el orden, pero en los tiempos hubo alteración.

XX. XXXXX: [00:17:30] En los tiempos sí, claro desde el comienzo la alteración se veía, se revisaba por qué, porque desde el punto de vista que nosotros arrancamos a medidas de desarrollo a mediados de febrero ya llevábamos un mes de atraso porque pues el contrato se firmó en diciembre, lo único que en diciembre, comienzos de enero y empezamos a los desarrollos a mediados de febrero más o menos los desarrollos, como ya entonces ya llevamos un mes de atraso sí o sí teníamos que ir a nivel del cronograma que les dije inicialmente existía un cronograma donde decíamos que teníamos que sacar todos los 14 módulos aproximadamente puedo estar equivocado 15 meses y en esos 15 meses teníamos que atacar a medida que yo iba haciendo los desarrollos con compañía de data si yo me voy atrasando en esa entrega, pues le iba a pegar directamente a los demás módulos, que fue que efectivamente fue lo que al final pasó.

DRA. XXXXXXX: [00:18:24] Y ese primer atraso se debió a qué, ese que usted dice que llevan como atrasados en un mes.

XX. XXXXX: [00:18:30] El tema pues al inicio de los desarrollos porque el kick off fue a mediados de enero y los desarrollos los comenzamos en los primeros días de febrero.

DRA. XXXXXXX: [00:18:39] ¿Y por qué se demoraron en empezar los desarrollos?

XX. XXXXX: [00:18:42] Ya es un tema ya que tocaba revisarlo desde el punto de vista de lo que dice el contrato es data, tenía que haber entregado a nivel de desarrollo se llaman ambientes ambiente de desarrollo, lo tenía que manejar Data ambiente de Cuba y preproducción y producción los manejaba la Bolsa en el mientras se generaba toda esa parte del lado de data, pues fue el tema xx xxxx en el inicio de los desarrollos.” (Resaltado del Tribunal).

Agregó frente a los cronogramas pactados:

“DRA. XXXXXXX: [00:19:07] Ese cronograma del que usted habla era preciso con fechas y tiempos?

XX. XXXXX: Sí.

DRA. XXXXXXX: Y ese iba en el RFP del que usted nos habló?

XX. XXXXX: No, ese se armó después en el RFP uno en el RFP uno dice yo que quiero después las casas nos dicen oiga, yo me voy a gastar X meses y le voy a cobrar X plata después de entendimiento decir venga efectivamente, porque inclusive me acuerdo que una de esas sociedades con esas casas de software decía mire, yo me le voy a gastar 24 meses si es demasiado, o sea otra decía 36 meses, entonces obviamente inclusive una dijo yo me les gasto ocho meses, tampoco iba y Data dijo más o menos 15 meses si mi memoria no me falla 15 meses, xxxx, ese ya está como que por el estilo, que si lo podríamos aterrizar, pero después de eso, ya con el entendimiento que se hace, empieza uno a decir efectivamente cómo se va a manejar.

Después inclusive el cronograma como tal terminó saliendo después a finales de febrero, porque ya realmente teníamos con la conceptualización de todo lo que se tenía que hacer, ya data como tal, sabía qué era lo que tenía que desarrollar y Data empezó a decir en el primer módulo me gasto, qué sé yo, siete semanas, cinco semanas y empezó por semanas hasta llegar, obviamente a los 15 meses.

DRA. XXXXXXX: [00:20:29] Pero esto fue en la propuesta o fue ya firmado el contrato.

XX. XXXXX: [00:20:32] Después de firmado el contrato”59.

59 Expediente Virtual 141365 – Transcripciones – 142365 Xxxx Xxxxx Xxxxx Xxxxxx

Así las cosas, para el Tribunal no existe evidencia de que la Convocada haya puesto reparo alguno de forma oportuna al supuesto cambio y manifestara la afectación de los tiempos. Antes, por el contrario, de manera decidida acometió la tarea, hasta el punto que sólo estos tres (3) de catorce (14) fueron entregados, los cuales fueron objeto de recibo y aprobación por parte de la contratista. Si el trabajo realizado no correspondía a lo que tenía previsto el Contrato, cuál fue la razón para someter y obtener de la contratante su aprobación?

En cuanto al tema de que DATAiFX haya construido módulos adicionales, por fuera del objeto contratado, ante la pregunta del Xx. Xxxxxx el testigo señaló:

“XX. XXXXXX: [00:54:43] Bueno, otra pregunta que quería hacerle en algún testimonio anterior se dio cuenta de que XXXXxXX tuvo que construir dos módulos adicionales que no estaban contratados uno de operaciones para simular las operaciones con la bolsa para poder construir precisamente lo relativo al libro de órdenes de transacciones electrónicas y otro de parametrización general, usted podría comentarle al Tribunal, si conoce sobre ese particular de que se han construido esos dos módulos adicionales.

XX. XXXXX: [00:55:21] Pues de plano se construyeron, pero no fueron adicionales en el contrato dice que tenía que construir ahora se me olvidó la palabra el primero cuál es que les he dicho parametrización, el primero dice parametrización obviamente yo tengo que saber en dónde voy a construir mi casa en un lote, que eso es parametrización y en el otro, en todo el contrato habla de Interoperabilidad e interfaces a lo que se llama “el módulo de operaciones” pues es una interfaz de muchas que tenían que hacer y ahí inclusive en el contrato dice que tienen que desarrollar las interfaces.

Es más, hay un documento que se le envió a todas las casas de software donde decían oiga, ustedes son conscientes que van a ser interfaces con un tercero y la respuesta de data fue sí y lo tengo por escrito en ese momento o sea, módulos adicionales no había.”

XX. XXXXXX: [00:56:21] También quiero preguntarle si durante la ejecución del contrato se dieron circunstancias, digamos, en cuanto al alcance de lo que debía construirse, que desbordaron lo que se señaló cuando se construyó ese documento inicial y cuando se fijó el alcance del objeto contractual.

XX. XXXXX: [00:56:45] Que se haya desbordado no, porque vuelvo a lo mismo, es data. Tenía que construir lo que se decía ahí lo que sí pasó fue que en el momento en que salió a producción nos faltaron cosas digo data nos faltaron cosas entre los dos, obviamente como proyecto, oigan, nos faltó hacer una conexión entre el

parametrización versus vinculación, porque eso nos pasó e inclusive nos pasó que en el número de la cédula colocábamos como número de cédula, número de cédula, colocábamos separadores de miles y pues eso no está bien en cédulas o en el Nit inclusive nos faltó, oiga, el guioncito, digamos 860-9 nos faltó, oiga, tener en cuenta el guion nueve entonces es un tema de detalle, pero pues que realmente otra vez contrata una fábrica de software que más o menos le va diciendo a uno cómo se deben llenar algunas cosas, que efectivamente eso que acabo de detallar, eso sí, no estaba en el RFP, pero que nos tocaba ajustar y en los requerimientos del cómo, el por qué y el cuándo teníamos

que hacerlo, pero eso sí es normal.60 (Resaltado del Tribunal).

Ahora, en cuanto al sistema de interoperabilidad, el acercamiento con los comisionistas de bolsa y la actividad que hubo necesidad de adelantar para ejecutar el Contrato, el Tribunal encuentra oportuno resaltar lo dicho por el testigo citado quien señaló:

“XX. XXXXXXX: [00:27:06] ¿Podría explicarnos en qué consistieron el mockup cuando hizo referencia en su declaración?

XX. XXXXXXXXXXX: [00:27:17] El mockup nació porque, nosotros es algo que siempre estuvimos hablando e incluso tuvimos ya después, en el año 2022 más o menos, unas historias de usuarios en las cuales ya empezábamos a utilizar el término de interoperabilidad, fue porque al principio cada uno de los módulos iba quedando como una isla aparte; llegó el momento en el cual nos tocó hacer un alto, sentarnos entre ambas partes y mirar venga, qué nos está haciendo falta y empecemos a integrarlo, en ese momento fue que empezamos a ver esas interoperabilidades.

Para que el módulo LEO cumpliera con lo que estaba solicitando la Superintendencia, necesitábamos un servicio que nos tenía que entregar la Bolsa a nosotros; como ese servicio todavía no estaba listo, nosotros qué tuvimos que hacer, crear un pequeño diseño en el cual un módulo iba a simular una respuesta por parte de la Bolsa; la firma comisionista enviaba un folio, enviaba una operación como si fuera enviarse a la Xxxxx, y la Bolsa tenía que devolverme una respuesta para yo poder dar como finalizada esa operación; como nosotros no teníamos ese servicio todavía, nos tocó crear este módulo y empezar a simular esas respectivas comunicaciones como si fuera entre el sistema back office hacia Bolsa, y Bolsa hacia el sistema back office.

XX. XXXXXXX: [00:28:41] ¿Hubo durante el desarrollo del proyecto elementos adicionales respecto a la información que no se tenía por parte, o que no se había presentado por parte de la Bolsa Mercantil, y que tuvieron que requerir a las sociedades comisionistas de bolsa directamente?

60 Expediente Virtual 141365 – Transcripciones – 142365 Xxxx Xxxxx Xxxxx Xxxxxx

XX. XXXXXXXXXXX: [00:29:01] Pues como tal, como tal la información, que, pues desconozco, pero lo que sí tuvimos que hacer en varias ocasiones fue sentarnos con las firmas, en pocas palabras, no era responsabilidad mía, pero yo recibía la solicitud por parte de Xxxxx y el señor Xxxx Xxxxx, en la cual me indicaba Geo será que hoy nos puedes acompañar con tal firma, por si nos hace falta algo tú les puedas explicar a las firmas y poder recopilar esa información, entonces así lo hicimos en varias ocasiones, lo hicimos con diferentes firmas.

Hasta donde yo tenía entendido el acercamiento con nosotros hacia las firmas, pues no se tenía que dar porque nosotros éramos solamente un tercero, el puente siempre iba a ser la Bolsa, pero en dado caso, en esos casos precisos lo que tocó hacer fue de esa manera, yo me sentaba con ellos, entraba a las reuniones, apoyaba mucho al equipo de BMC para qué, pues para que las firmas pudieran entender mucho más el sistema y pudieran darnos la respectiva certificación que estábamos buscando.

XX. XXXXXXX: [00:30:05] ¿Y sobre esa información tuvieron o requirieron, más bien, subir los clientes de esas sociedades comisionistas de bolsa?

XX. XXXXXXXXXXX: [00:30:15] Sí señor; en esa parte en la cual nosotros estábamos haciendo toda esta integración, y pues por la premura para poder cumplir con la fecha de la normativa, tuvimos que tener una parte en la cual por parte de nuestro director de infraestructura, crear como un sistema adicional en el cual las firmas nos entregaban a nosotros una información que podía ser en un Excel, él la tenía que transformar, montarla al sistema y que se hiciera una migración automática y que quedara toda montada directamente en el en el proyecto, con esto qué se buscaba, que cuando ya saliéramos a producción y las firmas entraran, pues encontraran toda su información cargada en el sistema, no tener que empezar ellos a hacer qué, uno por uno meter los datos al sistema, entonces esa parte sí fue necesaria hacerla.

XX. XXXXXXX: [00:31:09] ¿Y a quién le correspondía esa labor?

XX. XXXXXXXXXXX: [00:31:13] Esa labor pues la terminó haciendo Xxxxx Xxxxx que era el director de infraestructura, pero pues en los correos que en los cuales siempre yo estaba en copia, en los correos, pues tengo uno donde el señor Xxxx Xxxxx hacía esa solicitud formal de que por favor les colaboráramos por la premura de la salida a producción.

XX. XXXXXXX: [00:31:33] ¿Pero le correspondía a DATAiFX realizar esa subida de información?

XX. XXXXXXXXXXX: [00:31:38] De lo que tengo entendido no nos correspondía a nosotros.” (Resaltado del Tribunal).

El apoderado de la parte convocante sobre estos mismos tópicos inquirió:

“XX. XXXXXXX: [00:40:12] Usted tenía unos módulos que desarrollar, lo tenía claro, en virtud del contrato.

XX. XXXXXXXXXXX: [00:40:18] Sí señor.

XX. XXXXXXX: [00:40:19] ¿Esa planeación que hubo en qué se vio alterada?

XX. XXXXXXXXXXX: [00:40:25] ¿En qué se vio alterada? Que cuando se tiene esta parte de lo que tiene que salir para la Superintendencia, se tuvo que volcar todo el esfuerzo a cumplir con esta normativa o con esta solicitud, entonces, los otros módulos que nosotros teníamos nos tocó frenarlos en esos momentos, que por el orden que llevábamos eran el de ID de facturas, perdón, registro de facturas ID complementación y el de, ID de negociación y el de complementación, perdón, esos eran los módulos que tenían que seguir; nosotros ya estábamos teniendo unos avances, la parte de desarrollo ya venía avanzando en estos módulos, pero por la premura con el módulo de LEO, tocó suspender o colocar en standby estos módulos para poder continuar con lo que estábamos haciendo y poder cumplir a cabalidad con las fechas que solicitaban.

XX. XXXXXXX: [00:41:15] ¿Esos módulos, perdóneme la expresión, que había que desarrollar para darle gusto a la Superintendencia o para cumplir la normativa de la Superintendencia, no estaban en el contrato?

XX. XXXXXXXXXXX: [00:41:27] Sí, claro, sí señor, esos estaban, sino que como hasta donde yo tengo entendido, el contrato iba de que se tenían que desarrollar todos completos y ahí se hace la entrega y pasar a producción.

XX. XXXXXXX: [00:41:35] ¿Y al final, frente al resultado, hay alguna diferencia entre priorizar unos módulos en un momento determinado, dejar en standby otros y luego desarrollarlos?

XX. XXXXXXXXXXX: [00:41:49] Sí, claro, sí hay una gran diferencia, por qué razón, porque impacta los tiempos; nosotros podíamos estar hablando de que si íbamos terminando cada módulo seguíamos con el que seguía, pero si en el momento nos toca poner en standby todos para poder solamente trabajar unos, pues fueron tiempos que impactaron en ese momento para seguir avanzando con esa construcción de los otros módulos.

XX. XXXXXXX: [00:42:13] No lo entiendo. A ver, usted tiene que desarrollar diez módulos, le voy a poner un ejemplo, desarrollarlos al tiempo.

XX. XXXXXXXXXXX: [00:42:22] No, no se desarrollan al tiempo. XX. XXXXXXX: [00:42:24] ¿Entonces?

XX. XXXXXXXXXXX: [00:42:25] Porque es que cada módulo es independiente del otro, para que yo pudiera tener LEO, yo tenía que tener parámetros del sistema, qué hace referencia a parámetros del sistema, pues para que todos los presentes tengan conocimiento, parámetros del sistema tenía que ver con todos los permisos, todos los roles, no solamente una pantalla donde yo meto mi usuario y mi contraseña, sino era mucho más allá, yo podía entrar al sistema, pero tenía que asignarle unos permisos a unas personas, yo le asigno los permisos al doctor para que usted use el módulo de LEO, porque no todos los perfiles iban a utilizar ese módulo, por esa razón tocaba construir módulo por módulo y después sí hacer esa integración.

XX. XXXXXXX: [00:43:06] sí, totalmente de acuerdo. Pero insisto, qué diferencia hay en que usted construya, me dice que no es al tiempo, entonces igual, ¿si construye unos y luego otros, no es lo mismo?

XX. XXXXXXXXXXX: [00:43:19] Sigo insistiendo, no señor.”

Frente a la necesidad de relacionarse directamente con las sociedades comisionistas de Bolsa, que plantea DATAiFX es pertinente volver al testimonio del señor Xxxxxxxxxxx quien al respecto indicó lo siguiente:

“XX. XXXXXXX: [00:45:44] Según le entendí yo en una respuesta, usted menciona aquí que hasta donde tenía entendido no tenía, o no deberían tener ustedes interacción con los comisionistas, ¿ese conocimiento de dónde lo obtuvo? O sea, ese hasta donde tenía entendido, ¿de dónde salió ese entendimiento?

XX. XXXXXXXXXXX: [00:46:05] Porque es que sencillamente la Bolsa Mercantil era el único que tenía la comunicación directa en ese momento con las firmas comisionistas, todo lo que solicitara las firmas comisionistas siempre se iba a hacer con un puente, que el puente era Bolsa Mercantil, DATAiFX; la firma le reportaba a BMC, BMC nos reportaba a nosotros, y siempre fue ese canal, en ningún momento, y si buscamos, digamos, en el historial del correo, en ningún momento ustedes van a ver que exista un correo de DATAiFX directamente a las firmas comisionistas, porque siempre se hacía en el canal.

Cuando ya Xxxxx Xxxxxxxx sale que queda a cargo de Xxxxxxxxx, siempre se hizo de la misma manera, incluso cuando solicitaban las partes del soporte que les siguiéramos colaborando, ninguna vez llegó directamente de la firma comisionista hacia nosotros DATAiFX para colaborarles de esa manera, siempre el puente fue BMC.

XX. XXXXXXX: [00:46:59] O sea, ¿siempre el puente fue BMC? XX. XXXXXXXXXXX: [00:47:01] Claro, sí señor.

Más adelante agrega:

XX. XXXXXXX: [00:54:53] Por qué no hablamos un poquito más sobre eso, por qué razón tenían que complementar esa información, era información privilegiada que no podía ser pública, tenían que estructurar ustedes algún tipo de encriptamiento. ¿Cómo funcionaba ese tema?

XX. XXXXXXXXXXX: [00:55:07] Bueno, pues hasta esa parte técnica no tengo todo el conocimiento, pero pues de la parte que yo tengo conocimiento le puedo indicar, para que cada una de las firmas pudiera funcionar, que fue algo que nos sucedió cuando recién arrancamos esta parte del multitenant, nosotros teníamos una URL genérica, la URL, pues era el sitio como tal, que era la que tenía que utilizar BMC, la Bolsa Mercantil, entonces, Xxxxx entraba a esta URL, y él no podía ver lo que fuera a ver, digamos Xxxxxxxx Xxxxxxxxxxx con mi firma Xxxxxxxx Xxxxxxxxxxx.

Por esa razón tocaba hacer, bueno, tengo entendido que son como una parte de encriptamiento en el cual lo que yo estoy viendo en esta URL no lo puede ver otra persona, por qué, pues porque es data sensible, es información sensible, porque las mismas, así pueda que yo Xxxxxxxx Xxxxxxxxxxx yo esté afiliado a Reika, esté afiliado a On Broker, a Corredores, a todas las firmas que sea, yo en mi usuario de Corredores no voy a poder entrar a ver lo mismo que tengo en Reika, son empresas totalmente diferentes, ninguna puede

ver lo de la otra”61. (Negrilla del Tribunal).

También en torno a este tema, el testigo Xxxx Xxxxx Xxxxx Xxxxxx, quien ostentaba el cargo de Director de Tecnología de la BMC, indicó:

“XX. XXXXXXX: [00:20:36] Gracias, doctora. Cuéntenos ¿cómo era la interacción entre los funcionarios de DATAiFX encargados de la ejecución de las obligaciones del contrato y los corredores de bolsa?

XX. XXXXX: [00:20:55] No había interacción con ellos Data nunca interactuó con ellos a nivel de desarrollo, con las sociedades comisionistas, nunca interactuó, interactuó con mi equipo, que éramos cuatro personas que eran las que hicimos obviamente el entendimiento de qué era lo que querían las sociedades comisionistas hicimos el filtro en el RFP como tal, estaba todo el tema de lo que necesitábamos y adicional a eso normalmente no se utiliza, pero nosotros con el conocimiento de expertis que teníamos de la sociedad comisionista, hicimos unos mockups que son las pantallitas de lo que yo necesito y lo

61 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxxxxx Xxxxxx Xxxxxxxxxxx Xxxxx

que yo me imagino como un Xxxxxxxxx no sé si esté bien dicho a nivel de lo que uno se imagina a través del plano como tal.

Eso es lo que necesitamos hacer y lo hicimos obviamente en Excel lo pintamos de qué es lo que se tenía que hacer, qué interactuaba con cada una de esas cosas eso lo hicimos nosotros y nos sentamos con el equipo de Data al comienzo efectivamente empezamos a fluir porque hicimos realmente como un equipo, o sea, hicimos llave con ellos y efectivamente empezamos a entendernos y empezamos a revisar el tema y empezamos a fluir bastante bien.”

“XX. XXXXXXX: [00:22:01] Uno podría decir que ese trabajo era como un demo, como una demostración más o menos, usted nos quiere describir cómo era el proceso frente a la interacción con los comisionistas específicamente?

XX. XXXXX: [00:22:19] La interacción con las comisionistas se hizo previo a ocho meses antes, cuando les nombré que habíamos contratado x Xxxxxxxxx para que realmente fuimos, hicimos las 420 reuniones con ellos en ese momento fue la interacción con la sociedad comisionistas, se escribió el RFP íbamos a las sociedades comisionistas esto es lo que usted realmente quiere tener en su back office desarrollo verificar sí mire, yo necesito que realmente tengamos que el cliente, el corredor tenga un código que el corredor pueda ingresar, que él pueda seleccionar a qué tipo de operación puede hacer que solamente hay corredores que pueden negociar mercado de compras públicas, otros solamente financieros o el otro solamente de mercados que es el tema de físicos. Y hay uno empezaba a seleccionar es que adicional a eso yo necesito que ese corredor como se tiene que certificar ante el AMB, que yo pueda ingresar mis datos de en el sistema y que si el corredor, la certificación se le vence, que el sistema me lo controle. Eso fue previo a la entrega del RFP o sea, ahí no hubo comunicación de entre data y las sociedades comisionistas a nivel de desarrollo no hubo comunicación directa.

XX. XXXXXXX: [00:23:24] Entonces precisando, ellos les entregaban a ustedes el demo, es decir, Data le entregaba la bolsa del demo?

XX. XXXXX: [00:23:33] Sí hacían los desarrollos en su ambiente de desarrollo, nosotros qué hacíamos, nos lo pasaban a nuestro ambiente, que es de pruebas todo el tema lo revisamos, lo validamos, verificamos que efectivamente lo que estuviese escrito estaba ahí y a partir de las diferentes historias de usuario empezamos a hacer la certificación, a probar que efectivamente a partir de esa certificación aprobamos, ya lo recibíamos y ya lo recibía la bolsa como tal y se lo mostraba ante la sociedad comisionista y esto ya quedó así porque esto fue lo que usted me dice.

XX. XXXXXXX: [00:24:06] En esa muestra a los comisionistas, ellos presentaban algunas observaciones.

XX. XXXXX: [00:24:16] Sí, algunas observaciones o sea, siempre que uno pide algo a medida que va avanzando, lo mismo cuando uno va construyendo la casa, tenga una pared y va pidiendo más cosas, pero en su momento decíamos como tal, eso fue lo que usted pidió muy seguramente eso va a salir en una segunda o tercera fase de desarrollo, se va a pedir, pero se mantiene ahí, hubo cosas que realmente a nivel de que si nos tocó ajustar, porque a nivel de la interoperabilidad que les hablaba anteriormente es si yo hago el módulo de parametrización, pues por ende tiene que interoperar con el de vinculación y el de vinculación tiene que interoperar con el Leo.

O sea, esos tres se tienen que hablar llega un momento en que cuando ingresábamos el operador no me aparecía en vinculación, pues es un tema que tocaba ajustarlo porque pues porque algo nos quedó mal ahí después si yo ya tengo el tema de la vinculación dirige que solamente ese cliente iba a hacer negociaciones de repos, pues cuando yo voy a ingresar las órdenes qué tipo de órdenes tengo que ingresar solamente la de repos entonces ese tema de interoperabilidad en algún momento sí como todo sistema al comienzo del desarrollo falla, pues hay que ajustarlo y eso fue lo que se hizo.

XX. XXXXXXX: [00:25:32] Esas fallas se las comunicaba directamente el comisionista a DATAiFX?

XX. XXXXX: No, no se fue directamente el equipo nuestro.

XX. XXXXXXX: [00:25:43] ¿Y ustedes qué hacían con esa comunicación?

XX. XXXXX: [00:25:46] Nos sentábamos semanalmente, siempre hacíamos las reuniones porque fue un tema de una metodología híbrida, de hacíamos las reuniones, no recuerdo si eran los viernes o los lunes, hacíamos la reunión a comienzo decir qué era lo que estaba pasando, cómo estábamos haciendo las revisiones efectivamente, pues en su momento recuerdo que era Xxxxx y después llegó Xxxxxxxx, que es lo que más el tema del entendimiento con que lo estábamos trabajando con ellos ya claro, empieza uno a hacer llave de entender qué era lo que necesitábamos y ya se iba diciendo cómo deberíamos estar operando e inclusive en algún momento Data nos daba más luces de lo que nosotros imaginamos oiga, podríamos irnos por este lado, pues el tema de desarrollo pues porque ellos conocen el tema de cómo lo van a hacer y los ingenieros en su momento entregaban esa información, pero ahí era

sobre el tema, era de cómo podríamos ir avanzando para que no tuviésemos demasiados por llamarlos así, bug o errores en las pruebas.

XX. XXXXXXX: Uno supone que la corrección de esos errores demanda un trabajo adicional.

XX. XXXXX: Claro.

XX. XXXXXXX: O esas inconsistencias para no llamarlos errores esas inconsistencias constituyeron en su criterio o produjeron en su criterio la realización de actividades por fuera de las obligaciones del contrato?

XX. XXXXX: No”62. (Resaltado del Tribunal).

De la extensa transcripción de estos apartes de las declaraciones, se evidencia que la comunicación y la interacción entre la BMC y los usuarios finales, se mantuvo siempre, desde antes de la celebración del Contrato y durante su ejecución, y que no le correspondía a DATAiFX realizar esta actividad.

Por otra parte, en la medida en que el contratista ya venía prestando servicios de asesoría en temas de tecnología a la BMC, debía tener claro y partir del supuesto de que el sistema Back Office estaba dirigido a terceros competidores entre sí, razón por la cual la exigencia en la confidencialidad de la información debía estar garantizada, lo que generaba ciertas limitaciones en cuanto a su entrega y manejo

Finalmente, frente a la entrega de la información derivada del trabajo xx Xxxxxxxxx, afirmó:

“DR. SERENO: [01:00:13] Xxxx Xxxxx. ¿Ustedes le entregaron la información que recopiló Xxxxxxxxx?

XX. XXXXX: Sí el RFP.

DR. SERENO: [01:00:26] Perdón yo acabo la pregunta. XX. XXXXX: [01:00:28] Qué pena.

DR. SERENO: [01:00:28] No, es que la RFP se construyó con base en esa información que recopiló Xxxxxxxxx esa es la invitación a ofertar entiendo yo que es la RFP entonces no solamente tiene las entrevistas y en otros elementos del negocio la pregunta es si la Bolsa Mercantil le entregó la información que recopiló Xxxxxxxxx de esos perfiles de los que van a usar el sistema o fue un resumen que ustedes le hicieron de conformidad con sus necesidades?

XX. XXXXX: [01:00:58] Fue más allá de la necesidad de la bolsa, de la necesidad de las comisionistas, porque eran 10 formas de pensar donde teníamos que estandarizar uno solo entonces esa tarea, efectivamente, si cogimos exactamente, lo que pasa es que cuando hablamos xx Xxxxxxxxx era una persona, pero el equipo éramos cuatro, o sea, Xxxxxxxxx me apoyaba, pero el tema de metodología, pero el levantamiento de requerimientos lo estábamos haciendo en compañía de ellos o sea, xxxxxxxxx como tal era el tema de cómo teníamos que hacer ese levantamiento porque no éramos en la bolsa como tal los expertos en levantar requerimientos, pero esa información como tal la detallamos y la aterrizamos en el entendimiento de esas 10, a 1 o sea, la pregunta

es si le entregamos ese detalle que teníamos de las 10 a data, no”63.

(Resaltado del Tribunal).

En tal sentido, considera el Tribunal que la BMC no estaba obligada a entregar el documento previo elaborado sobre las sociedades comisionistas de Xxxxx con apoyo del estudio contratado con la sociedad Xxxxxxxxx SAS, por cuanto con fundamento en ese levantamiento de información le fueron suministrados a la contratista los insumos, que en consideración del contratante, eran necesarios para llevar a cabo la labor encomendada y así consta en el expediente en el documento anexo a la RFP, tal como resulta de la declaración anterior.

Así mismo, según el contrato la BMC era la obligada a entregar la información a DATAiFX, y no estaba previsto que esta última la obtuviera de los funcionarios de la contratante, ni de los comisionistas de bolsa, así se considerara más práctico acudir directamente a la fuente para evitar eventuales reprocesos.

Fue así como la intervención de los usuarios funcionales tuvo importancia para la validación de los procesos informáticos desarrollados por DATAiFX, y con ocasión de esa interacción, como era obvio, surgió la necesidad de hacer ajustes a los sistemas, y así se procedió.

Desde otro punto de vista, para el Tribunal DATAiFX, debía construir el BackOffice con la información entregada por la BMC, y la interoperabilidad de los sistemas y los usuarios era de la esencia del proyecto, pues éste era el propósito de los contratos, es decir, la creación de un nuevo aplicativo BackOffice.

También resulta claro para el Tribunal que el sistema apuntaba a la creación de una herramienta que permitiera a los comisionistas apoyarse en la nueva plataforma para interactuar con los productos actuales de la Bolsa, de ahí la necesidad de un sistema multicanal adaptable a cada uno de los usuarios, que no puede entenderse como una exigencia por fuera del Contrato, sino una consecuencia lógica del mismo, tal y como se menciona en el RFP.

Por ello la personalización o individualización del código URL para cada una de las SCB, además de su lógica, está expresamente incluida en la RFP, por lo que no tiene asidero alguno la glosa elevada por la demandada en este respecto.

Lo propio cabe decir de la customización o adecuación de los programas a las SCB, por cuanto expresamente en la definición del Contrato Back Office, las partes señalaron que este “significa el proyecto mediante el cual la BMC brindará a las Sociedades Comisionistas de Bolsa el acceso a un aplicativo tecnológico desarrollado por DATAiFX para la BOLSA mediante el cual se ofrecerán módulos elaborados a la medida de estas, para que realicen bajo su responsabilidad, los procesos de complementación y reporte ….” .

En tales términos, de la misma manera a lo acontecido frente al contrato de Refactoring, en relación con el de Back Office el Tribunal declarará probada la excepción de “AUSENCIA DE PRUEBA DEL INCUMPLIMIENTO DE LAS OBLIGACIONES CONTRACTUALES A CARGO DE MI MANDANTE” y, por

tanto, negará las pretensiones primera y segunda principales de la demanda de reconvención con sus respectivas pretensiones consecuenciales.

5. Perjuicios reclamados por la BMC

Probada la inejecución por parte de DATAiFX de los Contratos de Back Office y Refactoring por la omisión en sus obligaciones y deberes inherentes a su condición de profesional en la industria del software, que condujo a que no se hayan entregado las soluciones tecnológicas respectivas dentro del término contractual, pasa el Tribunal a ocuparse de las pretensiones consecuenciales de la demanda principal que solicitan la condena por indemnización de perjuicios materiales causados por su incumplimiento.

Es importante tener en cuenta que, en materia de responsabilidad contractual, los perjuicios a cuya reparación se aspira, deben ser en primer lugar, ciertos, es decir que, tanto su existencia como configuración deben estar debidamente probados en el proceso y, en segundo lugar, deben provenir del incumplimiento culpable de las prestaciones del deudor; esto es, que dentro de la inejecución o ejecución defectuosa de la prestación y el daño alegado debe existir vínculo o nexo causal y, finalmente, debe establecerse que se trate de daños previstos o previsibles al momento de la celebración del Contrato, de conformidad con lo señalado por el artículo 1616 del Código Civil.

Frente a lo primero se debe resaltar que el daño es elemento central de la responsabilidad contractual y, por consiguiente, el éxito de la pretensión resarcitoria supone que la convocante acredite debidamente dentro del proceso su existencia.

En consecuencia, además de demostrar la existencia de una obligación en cabeza del deudor al acreedor, le corresponde acreditar su incumplimiento

culposo y los perjuicios generados por dicho incumplimiento, los cuales deben acreditarse, a través de los medios de prueba conducentes.

En ese sentido solamente habrá lugar a la condena, si en el expediente queda demostrado un perjuicio real y cierto, no solamente fruto de especulaciones o conjeturas, pues frente a la incertidumbre del mismo el juez debe abstenerse de condenar so pena de inobservar la previsión contenida en el artículo 164 del Código General del Proceso, la cual dispone que “Toda decisión judicial debe fundarse en las pruebas regular y oportunamente allegadas al proceso”.

Es claro que entre el daño cuya indemnización se pretende y el incumplimiento contractual, debe existir un vínculo, toda vez que la reparación solamente debe cobijar aquellos perjuicios que hayan tenido origen en la inobservancia de las prestaciones negociales, es decir, debe obedecer a la inejecución en cabeza del deudor.

Con respecto al incumplimiento de DATAiFX, el Tribunal ya se pronunció, por lo que ahora ha de ocuparse de los perjuicios solicitados.

En tal sentido, como prueba de los perjuicios la Convocante acompañó los siguientes elementos de convicción:

(i) Informe Assesment Proyecto Refactoring e Informe Assessment Back Office - Xxxxx - 23 -06- 2022

La Convocante aportó con la demanda dos documentos en cuyo encabezado aparece la denominación Xxxxx, según el logo que contienen. Su objeto según allí se xxx, fue determinar el avance de lo construido por DATAiFX contra lo solicitado en la Invitación, para cada uno de los Proyectos (Refactoring y Back Office). Se anota que los informes tienen fecha del 23 xx xxxxx de 2022, fecha en la cual ya se había terminado el Contrato de Back Office y faltaban menos de 15 días para que se terminara el de Refactoring.

En dichos documentos, se concluye que:

- para el Contrato de Back Office: “De la aplicación de la estrategia de medición acordada con La Bolsa se puede decir que el esfuerzo realizado a la fecha en el proyecto BackOffice contribuye a la solución en el 33.45% del total del proyecto”,64 y

- para el Contrato de Refactoring: “De la aplicación de la estrategia de medición acordada con La Bolsa se puede decir que el esfuerzo realizado a la fecha en el proyecto Refactoring contribuye a la solución en el 41.5% del total del proyecto”65.

64 Expediente Virtual 141365 – 02 Pruebas – Pruebas 02 – 00 Demanda – Pruebas Documentales – 4.2. Back Office

– 4.2.14 1. Informe Assessment Back Office – Xxxxxx.pdf Pág. 23

65 Expediente Virtual 141365 – 02 Pruebas – Pruebas 02 – 00 Demanda – Pruebas Documentales – 4.3. Refactoring

– 4.2.12 1. Informe Assessment Refactoring – Xxxxxx.pdf Pág. 14

Se destaca que la autoría de estos documentos no fue demostrada, no obstante lo cual, como se analizará a continuación, el Tribunal valorará el dictamen pericial presentado que se apoyó en el referido informe atribuido por la convocante x Xxxxx.

En la contestación de la demanda ni la Convocada ni el Llamado en Garantía los descalificaron, pero sí se refirieron en sus alegatos de conclusión a la deficiencia anterior anotada.

(ii) Dictamen Pericial Contable y Financiero

Por otra parte, la Convocante aportó “Dictamen Pericial contable y financiero sobre el (i) cálculo del monto efectivo de los daños y perjuicios causados por el incumplimiento parcial de DATAiFX S.A.S dentro del Contrato de Prestación de Servicios Tecnológicos para el Análisis, Diseño y Desarrollo de la Solución Tecnológica para el Proyecto Back Office No. CO-2020-0060 (ii) cálculo del monto efectivo de los daños y perjuicios causados por el incumplimiento total de DATAiFX S.A.S del Contrato Marco de Servicios Tecnológicos (Proyecto Refactoring) No. CO-2020-0051”.

Las conclusiones del Dictamen aportado fueron las siguientes: “ Sobre el contrato 2020-0060 de BackOffice:

● - Hubo un incumplimiento parcial del mismo

● - Los perjuicios (directos e indirectos) aunados a las reclamaciones (clausula penal) equivalen a COP 1.975.306.017

Sobre el contrato 2020-0051 de Refactoring:

● - Hubo un incumplimiento total del mismo

● - Los perjuicios (directos e indirectos) aunados a las reclamaciones (clausula penal) equivalen a COP 4.608.955.974”. 66

Observa el Tribunal que los peritos financiero y contable, autores del citado Xxxxxxxx, concluyen que hubo un incumplimiento parcial en el Contrato de Back Office y un incumplimiento total en el Contrato de Refactoring con base en los documentos presentados por la convocante, elaborados por Xxxxx según afirma, y a partir de ahí calculan los perjuicios.

Es importante anotar que en el interrogatorio a los peritos llevado a cabo por solicitud de la Convocada con el fin de controvertir el dictamen arriba referido, el perito Xxxxx Xxxxxx manifestó que los soportes para el cálculo del perjuicio fueron las conclusiones técnicas a las que había llegado Xxxxx en sus informes. Así mismo, manifestó que no tuvo contacto con funcionarios xx Xxxxx y que sus informes le fueron entregados y explicados por la BMC:

66 Expediente Virtual 141365 – 02 Pruebas – Pruebas 02 – 07 Dictamen pericial apartado convocante – 20240115 Dictamen BMC V7.pdf

“XX. XXXXXXX: [00:10:20] Yo quisiera preguntarle lo siguiente. ¿Una única reunión con el equipo de tecnología informática de la Bolsa Mercantil le bastó para conocer de lleno ambos proyectos?

XX. XXXXXX: [00:10:32] En estricto sentido y como lo comenté, se realizaron varias reuniones. Desde la primera reunión se empezó a comentar cuál había sido la controversia, nuestra especialidad es financiera en cálculo de perjuicios por mi parte y por parte de la doctora Xxxxxxx, es la parte contable. Respecto a su pregunta, si nos bastó una reunión, mi respuesta es sí, si nos bastó porque queríamos comprobar cuáles eran los hechos con los cuales poder realizar el cálculo del perjuicio.

En ese sentido, se nos informó que ya una compañía especializada en temas informáticos denominada Xxxxx, había hecho una revisión pormenorizada del alcance y el cumplimiento de cada uno de estos dos contratos. Entonces, nuestra labor más allá del entendimiento narrativo y general de la controversia y por supuesto del entendimiento específico de cada uno de los aspectos que íbamos a analizar, la contabilidad respecto a los proyectos, la contabilidad respecto de los recursos humanos y la contabilidad en sí misma, pues no tuvimos que hacer un alcance adicional para entender la controversia desde el punto de vista técnico informático.

(…)

XX. XXXXXX: [00:16:55] Yo revisé los informes xx Xxxxx y sobre los mismos como ya lo mencioné, me fue indicado por la Bolsa que eran de terceros independientes. Y al haberlo revisado no recuerdo, y si es así, me gustaría poder verlo, que en algún momento el informe dijera que los resultados había sido dictados por la Bolsa, que es lo que entiendo que en la pregunta sugestiva usted afirma.

XX. XXXXXXX: [00:17:26] No que había sido dictado, que había sido elaborada de la manera en que se llegó a la conclusión mediante la medición. Y le voy a citar la página 6 que dice, estoy leyendo lo que reposa en el mismo informe suyo extraído de los informes de la Sociedad Xxxxx “de la aplicación de la estrategia de medición acordada con la Bolsa, se puede decir que el esfuerzo realizado a la fecha del proyecto de BackOffice contribuye a la solución en un 33.45%”. ¿La pregunta va dirigida, a usted no le pareció o no se le ocurrió cuestionar el hecho de que la medición haya sido acordada con la misma Bolsa de valores?

¿Cuál es el grado de independencia?

XX. XXXXXX: [00:18:11] No me cuestiona el hecho. Le voy a comentar, como ya lo mencioné, yo he presentado varios de estos dictámenes y estos dictámenes y estas instalaciones de software son modulares. Entonces me pareció que lo que se estaba midiendo ahí eran los

diferentes módulos de los proyectos, entonces me pareció que era algo totalmente razonable. De hecho, cada una de estas mediciones xx Xxxxx, daba cuenta precisamente del cumplimiento o incumplimiento de diferentes requerimientos funcionales. Yo aquí quiero volver a expresarlo de una manera muy solícita, yo no soy un experto técnico. Yo le pregunté a la Bolsa si existía un informe técnico, la Bolsa así me lo corroboró y me entregó el informe como tal. No tengo una capacidad técnica para poder cuestionar si esa estrategia de medición era independiente, dependiente. Lo único que puedo decir por mi experiencia reciente en este tipo de actividades es que la medición que yo vi era una medición en torno a las capacidades funcionales, a los módulos y que eso me pareció muy razonable con otros ejemplos que he visto” 67.

5.1. Valor probatorio de los documentos aportados

Respecto de los dos documentos que constituyen la fuente principal del dictamen pericial para el cálculo de los perjuicios solicitados por la convocante, precisa el Tribunal:

(i) No se aportó ningún documento que acredite la existencia de una persona jurídica denominada Xxxxx, quien aparentemente sería la autora de los documentos allegados con la demanda principal, denominados Assessment Proyecto Refactoring de Aplicaciones y Assessment Proyecto Back Office, según se ha afirmado durante el proceso.

(ii) El valor probatorio de los documentos se deriva de su autenticidad la cual define el artículo 244 de CGP así: “Documento auténtico: Es auténtico un documento cuando existe certeza sobre la persona que lo ha elaborado, manuscrito, firmado o cuando exista certeza respecto de la persona a quien se atribuya el documento”.

(iii) Derivado de lo anterior, para el Tribunal los documentos referidos carecen de fuerza probatoria y en consecuencia, el dictamen financiero y contable que los toma como fuente, tampoco puede conferir certeza alguna sobre las conclusiones allí referidas.

5.2. Conceptos del pretendido daño

Respecto del dictamen pericial aportado, aunque su fuente principal, como se dijo, no confiere certeza por lo que sus conclusiones no pueden ser tomadas como base para proferir las condenas solicitadas por la Convocante, encuentra el Tribunal pertinente ir más allá de las fuentes y del resultado de los cálculos efectuados a partir de la aplicación del algoritmo propuesto por los peritos, para analizar de todas maneras los conceptos tomados en cuenta para sus cálculos así como los anexos aportados con el dictamen.

Según el dicho xxx xxxxxx al ser interrogado en audiencia por la Convocada:

“El daño emergente se compone de todos aquellos egresos que han disminuido el patrimonio de quien está siendo afectado. Entonces como tal, la metodología implicó la identificación e individualización de tres tipos de pagos. El primero de los pagos aquellos realizados a DATAiFX.

El segundo de los pagos, aquellos realizados a compañías que tenían que ver con el proyecto como Rational por ejemplo, como Xxxxx por ejemplo. Y el tercer de los cálculos, el valor que tenía que ver con el gasto de personal que la misma Xxxxx había designado directamente, es decir, costo directo a este proyecto. Esas fueron las fuentes de información para calcular lo que usted menciona como perjuicio indirecto”68

Más adelante, el mismo perito se refiere a los perjuicios indirectos y dice lo siguiente:

“El perjuicio indirecto, como yo lo defino dentro del dictamen, son todos aquellos egresos necesarios o que gravitan alrededor de la compra del activo. Yo aquí utilizo y de pronto este es un neologismo, una adaptación del lenguaje contable al lenguaje de perjuicio. Y si es así y jurídicamente significa otra cosa, hago la aclaración porque perjuicio indirecto yo lo relaciono como un costo indirecto como lo mencioné anteriormente. Es decir, hay un costo directo que es el activo como tal que compra la Bolsa a DATAiFX y hay unos costos indirectos que son todos los necesarios para que ese activo funcione”.

Dado que los cálculos elaborados en el dictamen incluyen lo que el perito llama “perjuicios directos” y “perjuicios indirectos” el Tribunal encuentra que es importante tener claro estos conceptos.

Según el doctrinante Xxxxx Xxxxxxx Xxxx:

“La clasificación de directos e indirectos se refiere a la existencia de un vínculo causal entre el incumplimiento de la obligación y el daño producido. Ese daño es directo si es consecuencia inmediata, esto es, si éste explica plenamente el perjuicio. Se tratará de daño indirecto si es una secuela mediata del incumplimiento, de manera que no existe certeza sobre si aquel es una consecuencia necesaria de éste, pues podría provenir de otras causas distintas del incumplimiento”

(…)

El artículo 1616 antes transcrito permite inferir el principio general de que únicamente se repara el perjuicio directo, así el deudor incumplido haya obrado con dolo, lo cual exige la elaboración de criterios claros para

determinar hasta dónde van los perjuicios directos y dónde comienzan los indirectos.

Ahora bien, en estricto sentido y para una mayor claridad del tema, es del caso precisar, como lo hace el tratadista XXXXX XXXXXXX, que en realidad deben distinguirse dos vínculos de causalidad, de suerte que dos requisitos deben cumplirse: el primero en el sentido de que la actividad culposa del demandado debe haber causado la inejecución de la obligación. El segundo porque dicha inejecución debe haber causado el daño. Cuando este segundo vínculo de causalidad falta, es decir, entre inejecución de la obligación y el daño, se dice que el perjuicio es indirecto

En relación con el daño indirecto, nuestra ley, en materia contractual, expresamente señala que el deudor incumplido no está obligado a repararlo (art. 1616 del C.C.), regla que se basa precisamente, en la inexistencia de un vínculo suficiente de causalidad entre el incumplimiento culposo del deudor y el daño(…)”69

En los cálculos elaborados por el perito se observa que según éste, los perjuicios directos son los pagos de las facturas presentadas por DATAiFX y los indirectos son los pagos de facturas de Sofka Technologies SAS, Rational Software & IT SAS, Componente Digital Colombia SAS y gastos de personal.

Es preciso anotar que los peritos incluyen en su dictamen criterios jurídicos como incumplimiento, perjuicios directos e indirectos, lo que claramente no puede hacer un perito contable o financiero. Es tarea del Tribunal definir si hubo o no incumplimientos y determinar si los perjuicios a los que hace referencia son directos o indirectos, con el fin de aplicar los efectos que correspondan.

Como se señaló anteriormente, solamente hay lugar a reconocer los perjuicios directos, por lo que pasa el Tribunal a determinar cuáles de los señalados por el perito son realmente directos.

Concuerda el Tribunal que las facturas pagadas a DATAiFX están directamente relacionadas con la ejecución contractual por lo que sus pagos podrían ser catalogados como perjuicios directos, pero antes de llegar a dicha conclusión, es preciso determinar si este configura un daño causado por el deudor al acreedor.

Respecto a las facturas GP 02129 DT-1339 y GP 01915 DT-1305 aportadas con el dictamen70, el Tribunal considera que su pago no constituye un daño toda vez que corresponden a la entrega de los módulos LEO, Parámetros del Sistema y Vinculación, debidamente aprobados y certificados según las

69 Xxxxxxx Xxxx, X. (1996). Estudios de Derecho Civil y Comercial Contemporáneo, Tomo I. Primera Edición. Pág. 214 y siguiente

70 Expediente Virtual 141365 – 02 Pruebas – Pruebas 02 – 07 Dictamen pericial apartado convocante – 20240115 Dictamen BMC V7.pdf Pág. 19

estipulaciones contractuales. Lo anterior quiere decir que su pago corresponde a una parte del producto objeto del Contrato.

Frente a las facturas GP 02060 DT 894 y GP02378 DT 956 correspondientes al pago del primer 25% de los Contratos de Refactoring y Back Office respectivamente, las cuales debían ser pagadas una vez recibidas a satisfacción las pólizas de seguros según las condiciones de las cláusulas referentes a pagos, el Tribunal encuentra que tampoco puede calificarse su pago como daño pues cumplido el hito 1 de los Contratos (recibidas a satisfacción las pólizas), procedía el respectivo pago que garantizaba el comienzo de los trabajos. Si bien quedó probado que DATAiFX no entregó la totalidad de los productos a la BMC, también quedó probado que DATAiFX trabajó desde el inicio de ambos Contratos en los diferentes módulos y fases acordados. En el Contrato Back Office se probó que entregó 3 módulos que fueron aprobados y certificados y que hoy en día están siendo usados por la Convocante.

En cuanto al Contrato de Refactoring queda probado con el Otrosí No. 1 que DATAiFX adelantó gran parte de la Fase 1 la cual si bien no fue certificada, si fue pagada en un 80% según lo estipulado en el Otrosí No. 1.

Es importante destacar que según el Otrosí No. 1 las partes estuvieron de acuerdo en que la fase 1 se encontraba en la última etapa de cierre y presentaba un avance real del 60,4% frente al avance esperado del 62% y por consiguiente acordaron el pago del 80% exceptuando la certificación.

De lo anterior el Tribunal concluye que el pago de la factura GP-02349 DT 1377 por concepto del 16% del Proyecto Refactoring, habiendo sido aprobado mediante el Otrosí, con base en los avances de los trabajos de la Fase 1, no configura un daño pues finalmente la BMC estuvo de acuerdo en que ya había un trabajo elaborado y en consecuencia lo pagó. Si bien no se entregó esta parte del trabajo, lo anterior se debió a que para la entrega de la solución tecnológica debía culminarse el 100% del proyecto. Pero con el Otrosí queda claro que La Xxxxx aceptó los avances de la Fase 1 y el correspondiente pago por los trabajos llevados a cabo.

No quedó probado en el proceso si lo trabajado por DATAiFX funciona o no, así como tampoco si a futuro pueda utilizarse para finalizar el proyecto, sin embargo, si quedó que XXXXxXX construyó el 80% de la Fase 1.

En resumen, si bien las facturas pagadas a DATAiFX aportadas con el dictamen financiero y contable están directamente relacionadas con la ejecución del Contrato, en concepto del Tribunal su pago no constituye un daño por lo que no se configura el perjuicio directo.

Ahora bien, en cuanto a los perjuicios indirectos ha quedado claro que aquellos no se deben reparar por la falta de su vínculo causal. No quedó demostrado en el proceso que las facturas a nombre de Sofka Technologies SAS,

Componente Digital Colombia SAS y Rackspace tengan una relación directa con el desarrollo de los contratos respectivos, por lo contrario, estas pueden considerarse causadas por voluntad autónoma de la BMC.

Finalmente, en cuanto a los gastos de personal, estos si parecerían tener un vínculo directo con el desarrollo de los contratos bajo estudio, sin embargo, no se aportó la prueba idónea de su causación, toda vez que según lo admitió el mismo perito en la audiencia de interrogatorio, aquel no revisó la contabilidad de la empresa sino que se basó en una certificación emitida por “la persona xx xxxxxxx humano”71.

5.3. Conclusiones

Así las cosas, aunque se pueda predicar un incumplimiento culpable a cargo de DATAiFX, tanto en el Contrato de BackOffice, como en el de Refactoring, como se pudo definir en los apartes pertinentes de este laudo, la Convocante no pudo probar la existencia de un daño real, cierto y directo, que dicha inejecución le hubiere causado, por lo que no podrá accederse a condena alguna a su favor, y así se declarará.

Tampoco habrá lugar a condena alguna por concepto de cláusula penal, pues ella no fue solicitada de manera específica al Tribunal en las pretensiones de la demanda.

6. Demanda Principal

Como surge de lo planteado en los apartes anteriores, aunque se declarará un incumplimiento de las obligaciones a cargo de DATAiFX, tanto en el Contrato de Back Office, como de Refactoring, a partir de la integración e interpretación de los convenios suscritos, sus complementos y la ejecución respectiva, que dan cuenta particularmente de la desatención de sus deberes como profesional experimentado e informado en la construcción de programas de computador, no habrá lugar a condena en su contra por no haber sido demostrados los perjuicios alegados.

7. Demanda de Reconvención

En torno a la demanda de reconvención, no sólo por las conclusiones a las que llegó el Tribunal en torno a la falta de prueba de algún incumplimiento de sus obligaciones contractuales imputable al reconvenido, sino por la circunstancia de que cualquier posible pérdida, sobrecosto o erogación realizada por la parte reconviniente, que hubiera conducido a su precaria situación financiera y patrimonial, es atribuible, en primer lugar, a los errores que cometió al celebrar unos Contratos bajo la modalidad llave en mano, a precio y plazo fijos, no obstante la circunstancia de que varios de los alcances y funcionalidades de los programas contratados debían definirse precisamente

71 Expediente Virtual 141365 – Transcripciones – 142365 Xxxxx Xxxxxx y Xxxxxxx Xxxxxx 20240304. pág. 23