ESPECIFICACIONES TÉCNICAS PARA EL DESARROLLO, IMPLEMENTACIÓN Y OPERACIÓN DEL SISTEMA INFORMÁTICO DE APOYO EN LA GESTIÓN DE INSTRUCCIONES AL FIDUCIARIO DE METROBÚS.

1. Introducción

El presente Anexo tiene como objetivo describir las características, funcionalidades y requerimientos mínimos para LA PRESTACIÓN DEL SERVICIO DEL DESARROLLO, IMPLEMENTACIÓN Y OPERACIÓN DEL SISTEMA INFORMÁTICO DE APOYO EN LA GESTIÓN DE INSTRUCCIONES AL FIDUCIARIO que automatice el pago de kilometraje y participación establecidas en las Concesiones vigentes de las empresas operadoras que conforman el Sistema de Corredores Metrobús, para atender  las necesidades actuales y futuras de dichos pagos y otros posibles.
El objetivo es contar con un sistema automatizado del pago del kilometraje semanal y participación con una tecnología que permita el cálculo automático del importe a pagar por corredor y por concesionario, dicho pago puede ser mediante dos vías: 1. Mediante una instrucción firmada por la Directora General de Metrobús al fiduciario utilizando los recursos del FIDEICOMISO y 2. Utilizando recursos enviados por la Secretaría de Administración y Finanzas de la Ciudad de México en la partida SUBROGACIÓN. En ambos casos, el monto a pagar por concepto de kilometraje se calcula con base en el resultado de un proceso de conciliación semanal que se realiza en el Comité de Empresas Operadoras.
Para materializar el pago de kilometraje semanal y participación, es necesario que se realicen una serie de oficios según sea el caso (FIDEICOMISO o SUBROGACIÓN).  Para ello, necesitamos una solución que calcule el importe a pagar del kilometraje semanal y que genere automáticamente un documento y/o oficio por concesionario y Línea del Metrobús para que se realice el  pago de kilometraje con mayor orden, eficiencia y en forma automática.
Este documento está conformado por los siguientes apartados:

• Numeral 2 Definiciones. Apartado con la descripción de los términos utilizados en el documento. Para cada uno de estos se presenta una abreviatura y una definición.
• Numeral 3 Fideicomiso irrevocable de administración, inversión y pagos número 6628. Dicho apartado explica qué es el fideicomiso y cómo se constituyó, asimismo, explica los procesos necesarios para el cálculo del importe semanal a pagar de kilometraje y su pago por las dos vías, fideicomiso y subrogación.
• Numeral 4 Arquitectura del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario. Dicho alcance incluye los requerimientos que las empresas operadoras deben cumplir para llevar a cabo esta implementación.
• Numeral 5 Especificaciones Técnicas del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario. Este apartado explica los aspectos técnicos y funcionales que debe de cumplir dicho desarrollo.
• Numeral 6. Obligaciones del Proveedor en la puesta en marcha del Desarrollo del Sistema.

2. Definiciones

3. Fideicomiso irrevocable de administración, inversión y pagos número 6628

Parte central del desarrollo de una ciudad es un sistema efectivo de transporte público. Para la mayoría de la población de las ciudades, el transporte público es el único medio para acceder a su empleo, educación y servicios públicos, por lo que la Ciudad de México tiene una demanda constante de mayor movilidad. Por ello en marzo de 2005 se creó el Organismo Público Descentralizado Metrobús perteneciente al Gobierno de la Ciudad de México, sectorizado a la Secretaría de Movilidad. 

El objetivo de MB es el de planear, administrar y controlar el Sistema de Corredores de Transporte Público de Pasajeros de la Ciudad de México, y disminuir los tiempos de recorrido ofreciendo un transporte eficiente, seguro y de calidad.

Metrobús es un sistema de transporte BRT (Bus Rapid Transit) diseñado para mejorar los servicios de transporte de superficie en la Ciudad de México, buscando generar una red de transporte colectivo de pasajeros que se interconecte con la red del Metro de la ciudad y otros medios de transporte.

Asimismo, es un sistema de transporte basado en autobuses de alta tecnología, que brinda movilidad urbana rápida y eficiente por medio de la integración de una infraestructura preferente, operaciones frecuentes y excelencia en la calidad en el servicio. 

El 18 de junio del 2008 se constituyó el fideicomiso denominado “Fideicomiso Irrevocable de Administración, Inversión y Pagos Número 6628” el cual se encarga de administrar los recursos que se generan en los “Corredores de Metrobús”  a partir de la recaudación de dinero en efectivo y pagos bancarios provenientes de la venta de las tarjetas o plásticos, así como de su cargo y de su recarga, que sirven para pagar mediante la citada debitación de su saldo y de medios de pago EMV sin contacto, las tarifas fijadas a cargo del pasajero por el uso del servicio, que se administran en el Fideicomiso 6628, constituído ante el Banco Interacciones, S.A., en su carácter de Fiduciario.

El Fideicomiso se integra por diferentes subcuentas denominadas de acuerdo al nombre del Corredor que corresponda del Metrobús, tienen como finalidad la concentración, administración y el manejo de todos los ingresos cobrados en las terminales bancarias, alcancías y expendedores de tarjetas o plásticos instalados en todas las estaciones de los “Corredores de Metrobús” y en validación de medios de pago EMV sin contacto, para una adecuada administración, inversión y distribución de los recursos, bajo condiciones de transparencia y confiabilidad.

El principal objetivo del Fideicomiso es recibir las aportaciones, bienes, derechos, dinero efectivo, prestaciones y contraprestaciones. Las aportaciones que reciba el Fiduciario las administrará en forma individual y separada por cada "corredor de Metrobús" las cuales se identificarán con un nombre y número para cada subcuenta. El nombre de cada subcuenta iniciará con la denominación que se asigne a cada Corredor seguida de los dígitos de la cuenta bancaria receptora de los fondos. 

Cada una de las subcuentas registrará individualmente las aportaciones o incrementos que se reciban y a ella se le cargarán los egresos que autorice el Comité Técnico, siempre que estuvieren relacionados con el o los prestadores de servicios de transporte vinculados con el corredor de que se trate.

El fiduciario puede aplicar los recursos del fideicomiso en los siguientes casos:

1. Pago de honorarios del fiduciario;
2. Pagos de créditos y/o Arrendamientos de unidades transporte del Fideicomitente inicial B y los Fideicomitentes adherentes para la adquisición de los autobuses con que iniciarán actividades y/o infraestructura de recarga para autobuses eléctricos.
3. Pago de las cantidades que resulten por el kilometraje recorrido, a los FIDEICOMITENTES INICIALES y a los ADHERENTES con base a los títulos de concesión.
4. Pago de la participación de acuerdo a los títulos de concesión.
5. Las cantidades que correspondan al Metrobús.
6. Honorarios de la empresa Prestadora y Operadora de Servicios de Peaje y Control de Accesos, así como el reembolso de tarjetas.
7. Contratos de servicios conexos.

El fiduciario sólo puede aplicar los pagos correspondientes si y sólo sí existe una instrucción de pago elaborada por la Jefatura de Unidad Departamental de Administración Fideicomisos con la firma de la Directora General de Metrobús.

Asimismo, de acuerdo a los convenios de pago de participación de la tarifa a las concesionarias, cuando sea el caso, Metrobús realizará las gestiones ante la Secretaría de Administración y Finanzas de la Ciudad de México, de acuerdo a la normatividad vigente para el ejercicio de los recursos presupuestales autorizados en el ejercicio fiscal que corresponda a través de la partida presupuestal 3993 Subrogaciones y destinarlos al pago del kilometraje recorrido semanal y la participación mensual de la “CONCESIONARIA”.

3.1 Proceso de pago de kilometraje

Las Empresa Operadora recibirán un pago semanal, de acuerdo con el número de kilómetros recorridos en servicio, los cuales serán conciliados semanalmente y a los que se aplicarán las deducciones o compensaciones a que haya lugar, conforme a las Reglas de Operación, para determinar el total de kilómetros a pagar a la Empresa Operadora.
El pago que recibirán las Empresas Operadoras se calculará mediante el producto del pago por kilómetro establecido y el número total de kilómetros a pagar, recorridos por el parque vehicular registrado en el Corredor correspondiente.

Para los efectos de la conciliación del kilometraje, se deberán considerar los siguientes componentes:                     
I. El kilometraje recorrido en servicio corresponde a la distancia semanal realizada por el parque vehicular de la Empresa Operadora en los viajes comerciales que hayan quedado registrados en los sistemas del Centro de Control, los que incluyen los kilómetros recorridos según el o los programas de operación y los asignados por apoyos.
II. El kilometraje no recorrido consiste en la distancia no realizada por la Empresa Operadora previamente establecido en los programas de operación y los asignados por apoyos. El kilometraje no recorrido se clasifica en:    

a) Incumplimientos: Son los kilómetros no realizados por las Empresas Operadoras por causas que están en su control, tales como ausencias laborales, fallas de autobuses, faltas de autobuses, despachos tardíos o no realizados, choques, lesionados y situación médica y otros de naturaleza análoga, y 
b) Afectaciones: Corresponde a la distancia programada no recorrida por las Empresas Operadoras, por contingencias fuera del control de dichas empresas, según lo determine Metrobús.    

III. El kilometraje de apoyo consiste en los kilómetros extraordinarios por cambios en la oferta y/o demanda del servicio generado por causas que afectan la movilidad de las personas. Los tipos de apoyos podrán ser diarios, programados o para atender situaciones emergentes en rutas temporales fuera de los corredores del Sistema.
IV. El kilometraje a pagar consiste en el kilometraje recorrido en servicio por la Empresa Operadora en la conciliación correspondiente, al que se le descuentan las deducciones y se suman las Compensaciones correspondientes.    
V. A partir del último trimestre de 2023, la fuente principal de información para el reconocimiento del kilometraje recorrido en servicio serán los registros captados por el Sistema de Ayuda en la Explotación (SAE) de Metrobús de los viajes realizados y considerados como válidos. La Empresa Operadora tendrá acceso a los reportes del SAE para facilitar la revisión diaria de la operación, generar análisis, reportar observaciones e informar sobre posibles incidencias, fallas, desviaciones o desacuerdos sobre el registro.     
La fuenta actual de los datos, y en un futuro, la fuente en caso de fallas con el sistema de contabilización de kilómetros del SAE, las Empresas Operadoras deberán registrar lo siguiente:

1. Nombre de la Empresa.
2. Período de afectación, con fecha y horas.
3. Kilometraje total programado.
4. Kilometraje programado por autobús.
5. Kilometraje recorrido.
6. Kilometraje no recorrido, indicando el motivo del incumplimiento: fallas en los autobuses, afectaciones u otros.
7. Números, fechas y horarios de las corridas afectadas.
8. Tramos o puntos sin información de registro en caso de fallas intermitentes. 

Para la revisión del kilometraje a pagar, las Empresas Operadoras deberán haber presentado en forma oportuna toda la información a la que estén obligados en términos de estas Reglas de Operación, así como cualquier otra que Metrobús les requiera para verificar diferencias de la conciliación del kilometraje relacionadas con el reconocimiento del kilometraje recorrido o no recorrido. 

El resultado de la conciliación del kilometraje se informa a la Dirección Ejecutiva de Administración y Finanzas de METROBÚS para el trámite del pago correspondiente, en los términos que establezca la concesión o autorización correspondiente.

3.2 Cálculo de kilometraje conciliado

Este apartado 3.2 es solo informativo para que “LA EMPRESA” tenga la referencia de el proceso, sin embargo, no formará parte de su alcance, por lo cual, por medio del procedimiento descrito se cuantifica, analiza y acredita los kilómetros de servicios programados y realizados por las Empresas Operadoras, con base en la información y documentación generada tanto de apoyo a la programación del servicio, como la obtenida por el Centro de Control analizando la misma para el cálculo correspondiente para conciliar los kilometrajes reales de la operación del servicio. 

Para realizar la cuantificación del kilometraje realmente recorrido por las empresas operadoras, el personal de la Jefatura de Operación Técnica y Estadística realiza el siguiente procedimiento:

1. Recibe la información de asignación de kilometraje por parte de la JUD de Programación de Unidades de Transporte, la cual se recibe mediante correo electrónico del Coordinador de Conciliación.
2. El Coordinador de Conciliación valida el kilometraje programado para cada línea del sistema, esta validación se realiza comparando los kilómetros programados, asignados por tipo de autobús para cada empresa operadora.
3. El Coordinador de Conciliación proporciona la asignación de kilometraje por corredor al personal de analista de conciliación mediante correo electrónico.
4. El Analista de Conciliación recopila información de Controles de Salida y Terminales, así como los Formatos de Desincorporaciones en Centro de Control Metrobús, asegurándose de que la información se encuentre debidamente firmada por el responsable de generarla; en caso de que no se encuentre organizada por línea, fecha y periodo y debidamente firmada con nombre y cargo del responsable de su generación, no deberá de recibir la información notificando al Coordinador de Conciliación para que este solicite al Jefe inmediato de la JUD de Gestión del Centro de Control Metrobús la corrección de la información.
5. El Analista de Conciliación una vez que cuenta con la información operativa, deberá cuantificar y capturar los kilometrajes por incumplimientos, por afectaciones, de apoyos y generar el resumen de kilometraje de servicio conciliado; esta actividad deberá realizarla en los formatos anexos a este Mecanismo, los cuales deberá enviar mediante correo electrónico al Coordinador de Conciliación.
6. El Coordinador de Conciliación deberá revisar y validar el resultado del kilometraje conciliado de cada Analista de Conciliación, haciendo el comparativo del km programado total con la diferencia de los kilómetros reales, validando que el proceso de conciliación se cumpla.
7. En caso de contar con alguna notificación de deductivas por parte de la Dirección Ejecutiva de Operación Técnica y Programática, conforme el Título 9, Capítulo I, Regla SEPTUAGÉSIMA SEXTA, Fracción IV; así como la Título 11, Capítulo 11, Regla OCTOGÉSIMA NOVENA, Título 12, Capítulo 12, Regla CENTÉSIMA VIGÉSIMA PRIMERA de las Reglas de Operación de Metrobús, publicadas en la Gaceta Oficial del Distrito Federal del 31 de diciembre de 2021, se aplica la deductiva correspondiente para obtener el resultado del kilometraje conciliado.
8. El Coordinador de Conciliación deberá revisar y validar el resultado del kilometraje conciliado de cada Analista de Conciliación, haciendo el comparativo del km programado total con la diferencia de los kilómetros reales, validando que el proceso de conciliación se cumpla.
9. El Analista de Conciliación envía el resumen de kilometrajes conciliados a las empresas operadoras, con la finalidad de que éstas revisen y validen la información vía correo electrónico.
10. Las Empresas Operadoras envían la confirmación de la conciliación vía correo electrónico.
    

El personal de la Jefatura de Unidad Departamental de Operación Técnica y Estadística deberá tener la documentación soporte para su validación y firma en conjunto con el Acta de Comité de Empresas Operadoras, esta documentación será la justificación que valida y sustenta la acreditación de kilometrajes conciliados totales a pagar.

Figura 1. Proceso de conciliación de kilometraje actual.

3.3 Conciliación de importes entre la DEAF y la DEPETI

Al estar conciliado el kilometraje por parte de la DEPETI y de la DEOTP, dicha información se pasa a la Jefatura de Unidad Departamental de Administración de Fideicomisos (JUD Fideicomisos) mediante correo y en formato PDF para determinar en hojas de cálculo el importe a pagar, mediante la multiplicación del kilometraje conciliado menos las deducciones (o más las compensaciones, según sea el caso) por la tarifa de pago por kilómetro asignada a cada concesionario.

La DEPETI comparte semanalmente los oficios editables de solicitud de pago por kilómetro del concesionario (éstos están clasificados por cada corredor) a través del drive de Metrobús a la JUD de Administración de Fideicomisos donde se validan los montos a pagar por concesionario, posteriormente son firmados por el Director Ejecutivo de la DEPETI y  enviados mediante oficio a la DEAF.

La JUD de Administración de Fideicomisos, en algunos casos realiza deducciones, por retenciones de créditos que son contratados por los concesionarios para la sustitución de su flota, previo a determinar el importe final a pagar.

Figura 2. Conciliación del importe a pagar.

Ya que se calcularon los importes finales por línea y por concesionario se define la forma de pago. Existen dos vías a) La primera con cargo al Fideicomiso Irrevocable de Administración, Inversión y Pagos Número 6628 (pago vía fideicomiso) o b) La segunda con cargo a los recursos presupuestales de Metrobús designados por la Secretaría de Administración y Finanzas de la Ciudad de México (pago vía subrogación). Los siguientes subapartados explican los procesos necesarios para la realización de los pagos por las dos vías anteriormente mencionadas.

3.4 Pago vía subrogación

Como se mencionó anteriormente, el pago vía subrogación se refiere a aquellos pagos que se hacen con cargo a los recursos presupuestales del Metrobús designados por la Secretaría de Administración y Finanzas de la Ciudad de México. 

1. Ya que se tiene la relación de los pagos que se harán vía subrogación, la JUD de Fideicomisos solicita las facturas por concepto del pago del kilometraje mediante correo electrónico a los concesionarios para la comprobación de la aplicación de los recursos a las SAF.
2. Una vez enviadas las facturas a la JUD de Administración de Fideicomisos, se realizan tres documentos como se enlista a continuación: 
1. El formato de revisión de pagos, firmado por la JUD de Administración de Fideicomisos, la JUD de Contabilidad y Control Presupuestal y el Tesorero. (serealiza 1 documento por cada factura de pago)
2. La requisición de pago, firmado por la JUD de Administración de Fideicomisos y la Directora Ejecutiva de Administración y Finanzas. (se realiza 1 documento por cada factura de pago)
3. Y la solicitud de pago a la JUD de Contabilidad y Control Presupuestal. (se realiza un documento por toda la relación de pago de kilometraje semanal y participación mensual)
   

   Estos documentos son enviados a la JUD de Contabilidad y Control Presupuestal con el objetivo de solicitar los recursos presupuestales a la Secretaría de Administración y Finanzas. Una vez solicitado el recurso, el pago es ejecutado por la Tesorería de Metrobús

3. La JUD de Administración de Fideicomisos genera los oficios de notificaciones de pago en formato PDF dirigidos a las empresas concesionarias para informarles que el pago ha sido realizado, estos oficios deben de ser firmados por la Directora Ejecutiva de la DEAF. y enviados mediante correo electrónico a los concesionarios.
4. Los pagos realizados deben de ser registrados y cargadas las facturas correspondientes en el sistema GRP INTELISIS para su posterior validación de la JUD de Contabilidad y Control Presupuestal. El sistema INTELISIS es un sistema GRP (Government Resource Planning) el cual, es un software de gestión integral que sistematiza la gestión presupuestal, contable y patrimonial de los recursos financieros, materiales y humanos del Gobierno.
5. Cabe mencionar que todos los pagos realizados por esta vía deben de ser registrados en el FEF.

Figura 3. Proceso de pago vía subrogación.

3.5 Pago vía fideicomiso

Para el proceso de pago con cargo al fideicomiso, una vez conciliado el kilometraje y calculado el importe final a pagar por concesionario y corredor 

1. Se elaboran manualmente las instrucciones de pago en formato editable con los datos del kilometraje a pagar, las subcuenta del corredor donde se registra el egreso y la cuenta bancaria de la Empresa Operadora donde se realiza la transferencia. 
2. Una vez elaboradas las instrucciones y derivado del margen de error que se tiene se realiza un proceso de validación y autorización por el Director de Finanzas y el Director Ejecutivo de Administración y Finanzas (DEAF), quienes rubrican el documento previo a ser firmadas por la Directora General de Metrobús.
3. Una vez recaba la firma de la Directora General de Metrobús, éstas son escaneadas y enviadas al fiduciario a través de correo electrónico por el JUD de Administración de Fideicomisos; como parte del proceso de pago se elabora un LAYOUT en formato .xlsx que contiene los siguientes datos de las instrucciones:
   
   1. Cuenta origen
   2. Cuenta CLABE destino
   3. Banco
   4. Importe
   5. Número de Fideicomiso
   6. Concepto
   7. Fecha de pago
   Estos pagos y el formato LAYOUT debe de ser enviado antes de las 12:00 horas del día para proceder al pago el mismo día.
4. Se registran las salidas de dinero en el FEF por el Director de Finanzas.
5. La JUD de Administración de Fideicomisos da seguimiento a los pagos a través de la banca electrónica.
6. Se descargan los comprobantes de pago por el JUD de Administración de Fideicomisos y se  envían a las empresas.

Figura 4. Proceso de pago vía Fideicomiso.

4. Arquitectura del sistema 

Para lograr tener el desarrollo, implementación y optimización del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario de Metrobús, es necesario un sistema que procese el kilometraje conciliado para el cálculo del importe a pagar a los concesionarios y que genere las instrucciones de pago y notificaciones de pago. Para ello, necesitamos una solución que nos brinde el mecanismo para automatizar el cálculo del pago del kilometraje y la generación de la documentación necesaria para proceder al pago. 

A continuación, mostramos la arquitectura propuesta, la cual puede variar a propuesta del proveedor con el objetivo de cumplir con las funcionalidades descritas en este documento:

Figura 5 Arquitectura de alto nivel del desarrollo, implementación y operación del sistema informático de apoyo en la Gestión de Instrucciones al Fiduciario de Metrobús

Dicha arquitectura está conformada por tres niveles que interactúan entre sí. Cada nivel presenta unos elementos representados por unas cajas en el diagrama. El diagrama presenta tres tipos de flechas, la flecha azul continua representa el canal de alimentación de insumos, la flecha naranja discontinua representa un modo alternativo de alimentar el sistema de manera manual, esto en caso de caídas del SAE. Las flechas en ambos sentidos representan la comunicación entre las distintas APIs.

• Nivel 0: El nivel cero engloban los insumos a partir de los cuales el sistema será alimentado, el cuál puede ser de dos formas, uno vía automática a través de los datos que serán alimentados por el SAE a través de la API desarrollada por la empresa ganadora; la segunda vía podrá ser a través de método utilizado cotidianamente a través de los oficios de solicitud de pago enviados por la DEPETI a la DEAF con la conciliación del kilometraje y las deducciones por reglas de operación; según su caso.
• Nivel 1: engloba la interacción entre la API del Sistema de Ayuda a la Explotación con una API desarrollada por el ganador de la nueva implementación. Asimismo, el nuevo desarrollo debe de convertir de manera automática el kilometraje conciliado en importe a pagar para cada empresa y por línea, con base en el pago por kilómetro vigente.
  - API del Sistema de Ayuda a la Explotación.
  - API del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario
• Nivel 2: en este nivel se debe desarrollar el Sistema Central donde se alojarán las APIs, bases de datos, acceso y control de usuarios, respaldo de la información y un software de analítica de datos que permita analizar rápidamente los indicadores financieros más relevantes. Se presenta un listado con las características mínimas que deberá tener el Sistema Central.
  - Las API´s requeridas que permitan tener la conexión con los diferentes sistemas como SAE e Intelisis.
  - La Base de Datos de toda la información.
  - Control de acceso de Usuaríos, tanto del Organismo como las EO y los requeridos para el funcionamiento correcto del Sistema, deberán tener permisos correspondientes a las funciones.
  - Respaldo de la información almacenada.
  - Software de analitico de datos que permita tener los indicadores financieros más relevantes para el Organismo Metrobús para la presentación ante los directivos de Metrobús con el objetivo de tener una mejor toma de decisiones
• Nivel 3. En este nivel será dónde el usuario interactúe con el sistema y mostrará todos los archivos de salida para la operación de los pagos vía Fideicomiso y Subrogación, las notificaciones a las EO por los pagos realizados vía Subrogación. Con el objetivo de mostrar el orden de la documentación se elaboró la siguiente lista.
  - Herramienta que permita la selección de vía de pago, ya sea Subrogación o Fideicomiso.
  - El formato de revisión de pago es el documento de control interno que se envía a la JUD de Contabilidad y Control Presupuestal para la solicitud de la suficiencia presupuestal a la Dirección de Finanzas de MB.
  - Se requieren las Requisiciones de pago para la entrega a la JUD de Contabilidad y Control Presupuestal y la Tesorería de MB para la solicitud del pago vía Subrogaciones.
  - Elaboración de la Solicitud de pago con las firmas de la JUD de Administración de Fideicomisos y la DEAF para la ejecución del pago vía Subrogación.
  - Una vez ejecutado el pago se requiere la creación de la Notificación de Pago que será enviada a la EO con las firmas de la DF y la DEAF.
  - Para el caso de la ejecución de los pagos vía Fideicomiso, se requiere la creación de la instrucción de pago con los datos relevantes de cálculo de kilometraje y datos bancarios de las EO, que será firmada por la Directora General con la rúbrica de la DEAF, DF y JUD de Administración de Fideicomisos para su posterior envío al Fiduciario.
  - Dashboard con los datos financieros más relevantes para el Organismo Metrobús en diferentes gráficos.
  - Base de datos histórica que guarde los datos para rendición de cuentas e información solicitada. 
  - API que permita la conexión con el Sistema Intelisis para la carga de información para la armonización contable del Organismo Metrobús.

5. Especificaciones del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario.

Este alcance contempla las funcionalidades y aspectos técnicos que debe de tener el sistema de pago de kilometraje.

5.1 Descripción general del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario.

El Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario suministrada por "LA EMPRESA" debe:

a) Debe poder consumir la API del Sistema de Ayuda a la Explotación (SAE) y PEAJE para poder consumir los datos del módulo de conciliación de kilometraje.

b) En caso de caídas del SAE, este debe de tener la capacidad de subir manualmente la información.

c) Calcular automáticamente el importe a pagar por línea (CORREDOR) y CONCESIONARIO.

d) Ya que el sistema calcule los importes finales por línea y concesionaria, debe de generar una herramienta que permita la clasificación de los pagos, es decir, señalar la vía de pago, ya sea SUBROGACIÓN o FIDEICOMISO.

e) Incluir  herramienta en caso de descuento por retención de crédito en el importe final.

f) El sistema debe incluir el pago mensual de participaciones a las empresas concesionarias. (Se realizan 40 operaciones por semana, considerando un plan de crecimiento a 120 operaciones por semana)

g) El personal de Metrobús debe tener usuarios específicos con permisos de acuerdo a las necesidades del Organismo.

h)Los concesionarios deberán tener usuarios específicos para que les permita revisar que facturas deberán de generar (solo en caso de pago vía Subrogación).

i) Las facturas generadas podrán ser subidas al sistema en la cuenta de los concesionarios.

j)Validación de facturas electrónicas de manera automática a través de API del SAT. (Se valida promedio de 40 facturas a la semana, y el plan de crecimiento esperado es hasta 200 facturas mensuales. La empresa adjudicada deberá de consumir los servicios dispuestos por el SAT para realizar la validación de las facturas por el mecanismo que mejor les acomode, colocando alertas en caso de que la validación NO sea favorable.

k) Si el pago es vía SUBROGACIÓN, éste deberá solicitar automáticamente a los concesionarios la factura por el monto señalado vía correo electrónico, asimismo, el sistema le deberá permitir a los CONCESIONARIOS subir las facturas directamente al sistema, las cuáles deberá validar automáticamente en el portal del SAT. Posteriormente el sistema debe de generar los siguientes  archivos:  

1. Formato de revisión de pago por cada factura (Se anexa ejemplo);
2. Requisición de pago por cada factura (Se anexa ejemplo);
3. Solicitud de pago por el importe total.
4. Generar notificaciones de pago vía SUBROGACIÓN por cada factura;
5. Solicitud de CLC al área de Contabilidad (Se anexa ejemplo)

l) Si el pago es vía FIDEICOMISO, este debe de generar las instrucciones de pago automáticamente y se debe poder generar un soporte que valide la información contenida en la instrucción de pago. Posteriormente el sistema debe de generar un documento.

m) Generar LAYOUT en formato .xlsx que tenga la siguiente información por instrucción de pago:

1. Cuenta origen
2. Cuenta CLABE destino
3. Banco
4. Importe
5. Número de Fideicomiso
6. Concepto
7. Fecha de pago
8. Folio (debe de estar vacío para poder llenarse manual posteriormente)

n) El sistema debe de tener una base de datos de todos los pagos realizados por ambas vías, el cual pueda exportarse a hoja de cálculo para su manipulación y análisis.

o) El sistema debe de tener una serie de dashboard que analicen el comportamiento de los pagos por línea, por concesionario, por tipo de pago, el kilometraje pagado, recorrido y/o cualquier variable que requiera Metrobús.

p) El sistema debe de tener la opción de crear dashboard dinámicos.

q) Debe desarrollar una API que pueda ser consumida por el sistema INTELISIS para el registro de pagos.

r) Herramienta de flujo de efectivo de entradas y salidas de recursos. La EMPRESA debe  generar una herramienta que muestre a través de un tablero o flujo, el control de entradas y salidas de dinero semanal. Los formatos los va a otorgar Metrobús para poder tener dicha visualización.

s) La Dirección de Finanzas y la JUDAF deberán de tener usuarios que les permitirá hacer las siguientes acciones:

1. Ser los únicos que pueden acceder y utilizar la herramienta de selección de vía de pago con autorización de la Dirección de Finanzas.
2. Ver las facturas que los concesionarios deben de subir.
3. Hacer modificaciones a las instrucciones de pago en caso de ser necesario con autorización de la Dirección de Finanzas.
4. Hacer modificaciones a las notificaciones de pago en caso de ser necesario con autorización de la Dirección de Finanzas.
5. Modificaciones necesarias al flujo de efectivo con autorización de la Dirección de Finanzas.
6. Serán los únicos usuarios con acceso a la base de datos de la cual se alimenta la creación de las notificaciones y las instrucciones.
7. En el caso hipotético de que exista alguna falla en el SAE y que no pueda proveer información automáticamente a través de su API, la implementación debe de permitir alimentar el sistema de forma manual en alguna contingencia, para que el resto de los procesos puedan continuar funcionando, asimismo, los usuarios de la JUD de Fideicomiso y la Dirección de Finanzas son los que podrán ingresar manualmente los datos de kilometraje conciliado siempre y cuando se tenga la solicitud de pago por parte de la DEPETI.

t) El sistema debe de ser escalable y de poder integrar nuevas funcionalidades a partir de actualizaciones, según lo requiera Metrobús.

5.2 Aspectos técnicos

El Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario y automatización suministrado por "LA EMPRESA" debe incluir:

a) Capacitación al área de TI.
b) El sistema debe de hospedarse en la nube, la cual deberá de ser proveída por “LA EMPRESA”
c) El acceso al sistema y a la nube debe de ser dado por lo menos usando un mecanismo por doble filtro o mejor, y bajo una conexión segura, recomendando el uso de VPN.
d) El servicio deberá ser proporcionado como un híbrido de SaaS (Software como un servicio) e IaaS (Infraestructura como un servicio).
e) La política de respaldos es totalmente necesario que se maneje la política 3-2-1 (realiza 3 copias de los datos (con una diferencia máxima de 15 minutos) en 2 soportes diferentes (nunca en la misma infraestructura operativa) y aloja la tercera copia en 1 lugar físico distinto (que deberá ser entregado a Metrobús, en formato estándar). Lo cual será totalmente auditable en cualquier momento por personal de Metrobús.
f) Es COMPLETAMENTE necesario el contar, y detallar el BCP (Plan de continuidad de Negocios) y un DRP (Plan de recuperación de Desastres), con el que se contará; donde por la naturaleza de la información y la operación se tengan los siguientes parámetros, en el entendido que de no cumplirlos se aplicara una pena convencional del 5% de la contraprestación por cada día de pérdida de datos ó tiempo de recuperación de la funcionalidad:

1. RPO (RECOVERY POINT OBJECTIVE; Determina la cantidad máxima aceptable de pérdida de datos (en minutos u horas) que la empresa está lista / se puede permitir. Debe ser acordado tanto por el propietario / director de Finanzas como por la JUD de TI), recomendando un tiempo no mayor a 15 minutos.
2. RTO (RECOVERY TIME OBJECTIVE; en esta etapa, el sistema se recupera y vuelve a estar en línea, pero aún no está listo para la producción. El objetivo de tiempo de recuperación (RTO) determina la cantidad máxima de tiempo tolerable necesario para que todos los sistemas críticos vuelvan a estar en línea. Esto cubre, por ejemplo, restaurar datos de una copia de seguridad o corregir un fallo. En la mayoría de los casos, esta parte la lleva a cabo el PROVEEDOR). Se recomienda un tiempo NO mayor de 1 hora (que es totalmente alcanzable al hablar del uso de la nube).
3. WRT (WORKING RECOVERY TIME; es el tiempo en que se recuperan todos los sistemas, se verifica la integridad del sistema o de los datos y todos los sistemas críticos pueden reanudar las operaciones normales. El Tiempo de recuperación del trabajo (WRT) determina la cantidad máxima de tiempo tolerable que se necesita para verificar el sistema y / o la integridad de los datos. Esto podría ser, por ejemplo, verificar las bases de datos y registros, asegurándose de que las aplicaciones o servicios se estén ejecutando y estén disponibles. En la mayoría de los casos, esas tareas las realiza el administrador de la aplicación, el administrador de la base de datos, etc. Cuando todos los sistemas afectados por el desastre se verifican y / o recuperan, el entorno está listo para reanudar la producción nuevamente. Es deseable un tiempo no mayor a 2:00 hrs

Figura 6. Plan de recuperación de desastres

g) Se recomienda que el DRP y el sistema productivo se encuentren en diferente infraestructura, para garantizar la máxima disponibilidad.

h) Debe contar con una contraseña de SUPERADMINISTRADOR, tanto a la infraestructura, el aplicativo, y la base de datos, la cual estará en poder de Metrobús.

i)Los datos son totalmente propiedad de Metrobús, y no podrá condicionarse bajo ninguna circunstancia el acceso a los mismos, asimismo, se debe de cumplir lo siguiente:

1. Implementar solo imágenes y logos institucionales
2. Hacer uso de colores institucionales
3. El sistema no deberá contener ninguna marca de agua ni logotipo de ninguna empresa.
4. La interfaz debe de tener un diseño responsivo que permita la visualización en distintos dispositivos.

j) Deben de documentar que se proporcionará un sistema de monitoreo automatizado y que cuente con alertas configurables sobre:

1. Desempeño de servidores.
2. Espacio Libre de almacenamiento.
3. Tasa de carga y descarga de información.
4. Aviso de intentos de intrusiones.

k) Antivirus que se actualice de manera automática y que pueda ser monitoreado desde alguna plataforma. 

l) Debe de manejar una Base de Datos relacional, que permita extraer información y analizarla.

m) Módulo de Inteligencia de Negocios que permita el desarrollo de manómetros e indicadores a demanda por parte del cliente sin incurrir en costos extras por desarrollo de estos mismos, ni limitar el número de KPI (indicadores de negocio). Se debe basar en ingeniería ó minería de datos basados en cubos, paretos, debiendo permitir que el usuario final seleccione los indicadores en los cuales se basan estas proyecciones, y la modalidad de la presentación. De manera tal que se tenga una visión integral de los datos del organismo, permitiendo un análisis flexible de autoservicio. Estos procesos deben de incluir lo siguiente:

1. Minería de datos: Uso de bases de datos, estadísticas y aprendizaje automático para descubrir tendencias en grandes conjuntos de datos.
2. Generación de informes: Compartir el análisis de datos con las partes interesadas para que puedan sacar conclusiones y tomar decisiones.
3. Valores de referencia y métricas y de rendimiento: Comparar los datos de rendimiento actuales con los datos históricos para realizar un seguimiento del rendimiento en función de los objetivos, normalmente utilizando dashboards personalizados.
4. Análisis descriptivo: Uso de análisis de datos preliminares para averiguar qué sucedió.
5. Generación de consultas: Para extraer las respuestas de los conjuntos de datos, la BI hace preguntas específicas sobre los datos.
6. Análisis estadístico: Tomar los resultados de análisis descriptivos y explorar aún más los datos utilizando estadísticas para determinar cómo sucedió esta tendencia y por qué.
7. Visualización de datos: Convertir el análisis de datos en representaciones visuales como cuadros, gráficos e histogramas para consumir datos con mayor facilidad.
8. Análisis visual: Explorar datos a través de la narración visual para comunicar ideas sobre la marcha y mantenerse dentro del flujo de análisis.
9. Preparación de datos: Compilar múltiples fuentes de datos, identificando las dimensiones y medidas, preparándolos para el análisis de datos.

n) Proporcionar pruebas semestrales de:

1. Funcionamiento de BCP
2. Funcionamiento de DRP.
3. PENTESTING (Pruebas de penetración).
4. Estas pruebas se realizarán en conjunto con personal de Metrobús.

o) En la entrega del proyecto, deberá proporcionar los programas (código fuente) de cada uno de los módulos y apartados, así como memoria técnica, y los accesos del SUPERADMINISTRADOR.

p) Entregar los manuales de Políticas y Procedimientos relacionados al sistema.

q) Entregará diagramas de Entidad-Relación a los que tenga lugar durante el desarrollo del sistema.

r) Entregará los diccionarios de datos del sistema.

s) Interface para envío de información al portal del SAT y validar facturas, teniendo y actualizando la información de las mismas en el sistema.

t) Repositorio de documentos generados por el sistema.

u) Al término del contrato la empresa deberá de entregar todo lo necesario a Metrobús (códigos fuentes, programas, librerías, APIs, contraseñas, etc.), y acompañarle durante su implementación en la infraestructura donde Metrobús así lo decida, reservándose la aplicación de la fianza hasta por 3 meses posteriores a la conclusión o el cumplimiento en este punto, lo que ocurra primero, así como la documentación explicativa necesaria.

5.3 API para interacción con otros Sistemas Informáticos de Metrobús

La API para interacción con el Sistema de Ayuda a la Explotación debe:

1. Facilitar la aceptación de los Sistema Informáticos que Metrobús indique.
2. La API se debe poder instalar en dispositivos de distintos proveedores y referencias técnicas, siempre y cuando estos cumplan con las especificaciones exigidas en este anexo.
3. Ser desarrollada por “LA EMPRESA”, quien debe entregar el código fuente de dicha API y su documentación técnica a Metrobús para facilitar la evolución del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario, y la futura integración de hardware de distintos proveedores.
4. Ser desarrollada para poder ser incorporada en dispositivos con sistemas operativos Windows, Linux, Android y iOS.
5. Ser entregada como una serie de librerías precompiladas con sus correspondientes archivos de encabezados, los cuales deben definir el nombre, parámetros y tipo de retorno de las funciones que hacen parte de cada librería.
6. Incluir el código fuente con su documentación, un manual de usuario y la documentación técnica que describa el uso e implementación de cada una de las capas descritas anteriormente y ejemplos sencillos de esto.

5.4 Sistema Central

El sistema central suministrado por "LA EMPRESA" debe:

a) Proveer toda la información relacionada con las operaciones vinculadas al pago de kilometraje en los tiempos y con las características requeridas para controlar la correcta operación de este, así como hacer seguimiento a las operaciones, asegurando en todo momento la disponibilidad de esta información.

b)Tener la capacidad de migrar la información almacenada en la base de datos a otros sistemas que Metrobús le solicite.

c) Permitir a Metrobús el acceso ilimitado y completo a la base de datos.

d) Cumplir con una alta capacidad de parametrización, misma que se verá reflejada en el sistema (pago por kilometraje vigente, nuevas rutas o corredores, nuevas empresas o modificación de empresas existentes, formato de oficios, cambio en el representante legal, cambios en los datos bancarios para transferencia, cambios en la estructura orgánica de Metrobús, cambio en el Fondo Presupuestal, año, número de oficio de documentos soporte, número de semana al que se refieren, fecha de pago semanal, fecha), los parámetros deben ser modificables desde el sistema central.

e) Estar en idioma español latinoamericano.

f) Estar hospedado en la nube. Esta debe ser un centro de datos certificado bajo los estándares Uptime Institute Tier III, ICREA nivel IV, ANSI/TIA 942 Rated III o cualquier otro superior o equivalente, para garantizar condiciones de redundancia y alta disponibilidad.

g)Contar con una base de datos relacional bajo la estructura de datos que Metrobús proporcionará, donde se almacene toda la información necesaria para garantizar la correcta operación de todas las funcionalidades que aloja el sistema central, las cuales serán descritas más adelante.

h) Permitir la gestión de usuarios, de manera que se pueda dar o restringir acceso a las funcionalidades que aloja de acuerdo con los permisos asignados a los usuarios, los cuales son definidos por Metrobús. Esta gestión debe permitir:

1. Crear cuentas con un nombre de usuario y contraseña.
2. Asignar información del usuario como nombres, apellidos, identificación, rol, entidad, responsabilidades.
3. Actualizar la información del usuario.
4. Actualizar y recuperar contraseñas.
5. Asignar permisos de acceso a las funcionalidades del sistema central del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario de acuerdo con el rol de usuario asignado.
6. Deshabilitar cuentas de usuario.

i) Permitir como mínimo la administración y distribución de los siguientes parámetros:

1. Kilometraje: debe ser capaz de modificar el monto de pago por kilómetro a los diferentes concesionarios, por autobús o línea del Sistema Metrobús. 
2. Fechas y horarios: debe ser capaz de actualizar las fechas y horarios
3. Empresas: debe de ser capaz de agregar, quitar o remover empresas.
4. Corredores: debe de ser capaz de agregar nuevas.
5. Formatos de oficios: Debe de ser capaz de integrar cambios requeridos en los formatos solicitados. Dichos oficios deberán de ser firmados dentro del sistema con la firma CDMX en su versión WEB, o en su defecto con alguna otra firma que en un futuro pueda determinar Metrobús, para anexar el documento firmado al expediente electrónico de cada oficio.
6. Cambios en el representante legal: en caso de que cambie el representante legal de la empresa que se vea reflejado en los oficios generados.
7. Cambios en los datos bancarios: Cuenta CLABE, número de cuenta y nombre del banco.
8. Cambios en la estructura orgánica de Metrobús.
9. Cambio en el Fondo Presupuestal: cada año se actualiza el fondo con base a la Ley de Ingresos de la Ciudad de México.
10. Año vigente.
11. Números de oficios de documentos los cuáles soportan la información contenida en el nuevo oficio generado.
12. Que se actualice el número de semana automáticamente.
13. Se debe modificar la fecha de pago semana con semana.
14. Se debe de poder actualizar la fecha del oficio.

j) Contar con un sistema de respaldo o backup que garantice la continuidad en la operación de todas las funcionalidades que aloja ante una falla en el sistema principal.

k) Contar con interfaces web para todas las funcionalidades.

l) Contar con las API necesarias para que el Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario y sistemas informáticos de terceros puedan interactuar e intercambiar información con el sistema central. Lo anterior para que dichos sistemas se puedan integrar a la solución, y enviar y recibir los datos que se requieran para garantizar la correcta operación. Esto con el objetivo de garantizar una solución abierta, escalable y flexible.

6. Obligaciones del Proveedor en la puesta en marcha del Sistema Informático de apoyo en la Gestión de Instrucciones al Fiduciario.

1. Generar los desarrollos e implementar un sistema que automatice los procesos para la realización del pago por kilometraje y participación a los CONCESIONARIOS vía Fideicomiso y Subrogación, que permita almacenar la información para elaborar análisis históricos;
2. Entregar un plan de implementación del Desarrollo, Implementación y Operación del Sistema Informático de Apoyo en la Gestión de Instrucciones al Fiduciario a Metrobús.
3. Realizar las adecuaciones al sistema que solicite Metrobús y las actualizaciones necesarias para el correcto funcionamiento del sistema.
4. Garantizar la seguridad del sistema y de la información contenida ante cualquier intento de robo de información o ataque cibernético.
5. Dar mantenimiento y actualizaciones para mantener la seguridad requerida.
6. Hacer seguimiento a las incidencias reportadas por Metrobús. (Personal de soporte técnico y mesa de ayuda de “LA EMPRESA”). Esta mesa de ayuda deberá estar disponible de lunes a viernes de 08:00 a 22:00 horas y sábados de 10:00 a 18:00 horas.
7. Tener SIEMPRE respaldada la información de acuerdo a las especificaciones técnicas.
8. En todo momento Metrobús tendrá el derecho para supervisar el cumplimiento de todas las obligaciones del servicio.
9. Capacitación al personal que Metrobús designe.