Description du marché
Le Back-Office (BO) ventes voyageurs a pour objet l’acquisition, le contrôle et l’enrichissement, à des fins comptables et de pilotage, des actes de ventes et d’après-ventes en provenance des canaux de distributions (guichet, automates, agences de voyages, …).
Les principales fonctions comptables mises en œuvre sont la constitution d’une comptabilité auxiliaire et d'axes analytiques, la facturation interne et externe, le calcul des compensations, des répartitions et de la TVA, le contrôle des séances vendeurs, et les clôtures comptables.
Pour le pilotage, il s’agit essentiellement de publications de données de vente sur deux principaux axes, l’offre et les produits du trafic. Les publications se font à partir du collecteur des ventes vers des application tierces. On trouve y trouve notamment la publication des écritures de la comptabilité auxiliaire vers la comptabilité générale et la mise à disposition des données des ventes aux utilisateurs métiers via des publications dans des outils de type Business Intelligence.
Les applications qui composent le BO ventes voyageurs sont conçues dans des technologies hétérogènes, l’ensemble formant un tout fonctionnellement cohérent. Actuellement, 13 applications sont identifiées, ce périmètre varie au fil de l’évolution du système d’information avec de nouvelles applications et des décommissionnements. Depuis fin 2017, le programme Reboot est progressivement mis en production et permet le dé-commissionnement d’applications anciennes. Ces mises en service s’échelonnent à court et moyen termes.
L’objet du marché est de servir la maintenance applicative sur les applications du périmètre BO ventes voyageurs sous la forme d’une Tierce maintenance applicative (TMA).
Cette Tierce maintenance applicative (TMA) consiste à externaliser la maintenance et la gestion des évolutions des applications.
À ce titre, le titulaire se voit transférer la responsabilité de la maintenance du périmètre composant le BO ventes voyages, de leur performance, de leur disponibilité et du service rendu au client final.
Concernant l’exploitation, la maintenance et l’évolution de l’infrastructure technique applicative en environnement de production, elle reste prise en charge par la SNCF.
La tierce maintenance applicative inclue, les maintenances correctives, adaptatives et préventives, le suivi de production, la gestion d’incidents en niveau 3, et le support. Un service d’évolutions est également demandé.
Les enjeux de cette consultation pour SNCF sont:
— une TMA sur site titulaire sachant délivrer un niveau de service optimal sur le périmètre applicatif qui lui sera confié dont les principales technologies sont SAP, ODI et BI,
— une présence sur site SNCF Nantes, une fois/semaine, afin de rencontrer les responsables d’applications régulièrement,
— une bonne réactivité,
— une relation partenariale entre la SNCF et le titulaire,
— une maîtrise des coûts,
— la conservation et l’amélioration de la performance des applications.
À titre indicatif, volumes traités depuis début 2017:
2017, il y a eu:
— 298 ddes de travaux, et
— 31 anos à corriger dont 3 bloquantes,
— 19 ddes de support sur incidents,
— 2018, jusque août,
— 151 ddes de travaux,
— 22 ddes de support sur incidents dont 116 sur Reboot.
Éléments de complexité des applications et leur techno listés ci-après:
ORFEE: SQL, Teradata, ODI, J2E-Flex, Unix;
PDI OPALE: 24 shell; 168 ODI,17 Cognos//Cognos, ODI, Teradata;
SAFE: 7 shell, 24 ODI// MS SSIS, VB,SQL Server,MySQL, PHP (ODI);
SIPS: Cognos,MS DTS, VB, C#, Java J2EE, SQL server;
Spartacube: Cognos, MS SSIS, Java;
Financial Data Center: Power BI, SQL Server, Windows Server, IIS, MS SSRS, MS SSIS, .NET Framework, Qlikview, SSO (OpenAM);
FC12K: 63 prog ~1000 lignes par prog//SQL Teradata, Cobol PL1, MVS, UNIX;
REBOOT: ECC: 40000, CAR: 23000//SAP, ODI, Stream Serve, MQ Series, CFT;
REV: MDM, ODI;
ADES et Meursault: MQ Series, CFT, J2EE;
TIMC: ODI, Mainframe, Teradata;
HOC: SQL Teradata, ODI,XML Serv, Unix.