Retour Expérience projet PMU - Club utilisateurs des solutions Oracle

Transcription

Retour Expérience projet PMU - Club utilisateurs des solutions Oracle
Retour Experience Migration R12 –
Finance et Achats
16 Avril 2015
Ordre du jour
1
Retour Expérience projet PMU
2
Retour Expérience projet GFS
2
Retour d’expérience – Projet PMU
 Contexte:
 Après une étude menée en 2012, le PMU a décidé de réaliser la montée de version R12.1.3 par
migration technique. Ce choix s’expliquant par une volonté de conserver le paramétrage
structurant et par le cout moindre d’une migration technique par rapport à une fresh Install.
 Le projet a démarré début 2014 pour une bascule en production début Février 2015.
 Le PMU a souhaité intégrer dans son projet de migration
 Un changement de matériel (HP vers AIXP7)
 Des évolutions fonctionnelles : Le paramétrage de 2 nouvelles sociétés, la désactivation des engagements,
le passage en provision fin de mois pour les achats non stockés, l’utilisation des devises étrangères et la
mise en œuvre des formats électroniques directement à partir d’Oracle (SEPA/ISO).
 Périmètre :





Modules 11i : AP, AR, GL, AX, PO, IP, IC, OM, FA
Reporting : Discoverer
Scan de facture : Itesoft
Une seule société juridique
25 flux (utilisation ISIE comme ETL)
3
Retour d’expérience – Projet PMU
 Les grandes phases du projet
2015
2014
Fév.
Mar.
Avr.
Cadrage
Architecture
Mai.
Conception
Jeu 1
Jun.
Jul.
Aut.
Sep
Oct.
Nov.
Intégration
Réalisation
Jeu 2
Jeu 3
Déc.
Recette
Jan.
Fév.
Mar.
Avr.
MEP
Production
 Jeu 1 : Identification de l’ensemble des étapes et actions de la migration
 Jeu 2 : Fiabilisation des étapes et des temps d’arrêt de la migration
 Jeu 3 : Validation du scénario de bascule et de l’indisponibilité totale de la production
4
Retour d’expérience – Projet PMU
 Les difficultés rencontrées
 Identification de données mal migrées à corriger par datafix post-upgrade (Lignes de facture AP,
migration du référentiel bancaire, SLA, …)
 Les limitations de la migration technique sur le paramétrage
 Pas de remise en cause de paramétrage structurant (Clés, Organisations, …)
 L’activation de nouvelles fonctions implique un effort de paramétrage plus important : Désactivation
de paramétrage et re-paramétrage (Ex: E-Tax)
 Les points d’attention
 Tax : Module E-Tax complexe
 SLA : La construction de l’historique est chronophage (fonction de la profondeur de l’historique)
 Workflow: les processus en cours ne peuvent pas être repris après migration
 Les améliorations de la R12
 La souplesse de SLA qui permet une large personnalisation des libellés des écritures
 Nouveautés AP : Charges Constatées d’Avance, les factors, les paiements
 Le MOAC
5
Principales difficultés
 Absence des dernières mises à jour de documentation client (Ex:
Spécifications des composants à porter)
 Certaines données peuvent être mal migrées
 SLA : Des tables XLA (Balances) . Perte de liens entre les distributions AP et SLA.
 AP : Le niveau ligne a généré des écarts de TVA et de liens avec les distributions
 Mise en œuvre du calcul automatique de TVA dans AP:
 Paramétrage additionnel important des règles de calcul automatique
 Passage de patchs complémentaires
 Configuration des règlements AP
 Les PPP (Profils De Traitement Des Règlements) et formats de règlement sont à re-paramétrer
pour limiter les listes de valeurs en saisie des règlements AP et recréer les liens formats/compte
bancaire/mode règlement
 Problème de performance SLA AP.
 Mise à jour des menus spécifiques PMU
6
Points d’attention
 Ne pas négliger les impacts fonctionnels et donc l’accompagnement au
changement
 Taxe : La complexité du module implique l’écriture de modes opératoires dédiés pour les
opérations courantes (Ex: Création d’un nouveau taux de taxe)
 Paiements AP : La nouvelle ergonomie « web » (OAF) nécessite un accompagnement
personnalisé des utilisateurs de la comptabilité fournisseur
 SLA : Les possibilités qu’offre le paramétrage SLA (personnalisation des écritures) requiert des
ateliers dédiés afin de mettre en évidence les apports.
 Revoir les traitements planifiés
 Des traitements standards disparaissent au profit de nouveaux (Ex: Comptabilisations)
 De nouveaux paramètres R12 (Ex: OU pour la compatibilité MOAC ou Ledger au lieu de SOB)
 Interface utilisateur : Responsabilité/Menus/Traitements/Dossiers
 Les dossiers sur les écrans impactés sont perdus pour les évolutions majeures (Facture AP)
 Responsabilités et menus à revoir pour les nouveaux menus (SLA, E-Tax, …)
 Les groupes de traitements sont à modifier avec les nouveaux états (SLA, E-Tax, XML, …)
7
Points d’attention
 Gestion des workflows en cours
 Maximiser la finalisation des workflow en cours par les utilisateurs et minimiser le démarrage de
nouveaux workflow à l’approche de l’échéance de bascule
 Certains Workflow non finalisés devront être abandonnés techniquement pour être initialisés à
nouveau en R12 : Approbation de facture AP (Nouveau workflow) et Approbation de DA (si la
création automatique est activée pour les DA catalogues)
 Workflows non impactés : Approbation de commandes PO et exécution de commande et ligne de
commande OM
 Les anciennes tables sont toujours présentes:
 Pouvant faire croire qu’un spécifique fonctionne toujours alors qu’il ne ramène pas les nouvelles
données saisies
 Des volumétries peuvent être « doublonnées » et impacter les calculs de statistiques (AX versus
SLA)  Revoir la planification des traitements de calcul des statistiques
 Evolutions Procurement
 Ergonomie des commandes :Nouvelle ergonomie Web versus Forms toujours présente
 Catalogue unifié : Impact sur la gestion des catalogues dans iProcurement.
8
Points d’attention
 Méthodologie
 Pas de base Master: Tout le paramétrage complémentaire doit être réalisé sur chaque
environnement
 Il faut tout tracer  Mise à jour d’un document projet de Post-Upgrade fonctionnel.
 Ordre de grandeur : Le document de Post-Upgrade fonctionnel au PMU
contient plus de 250 pages
9
Ordre du jour
1
Retour Expérience projet PMU
2
Retour Expérience projet GFS
10
REX Projet GFS – Global Financial System
 Contexte:
GFS est le système financier du groupe Capgemini, basé sur une solution globale utilisant les modules Finance et
Projet de la E-Business Suite Oracle.
Plus de 80% du revenu du groupe est couvert par la solution. Avec une disponibilité 7/7 24/24, et environ 900 000
traitements durant chaque clôture financière, GFS est une des applications les plus sensibles au sein du Groupe
Capgemini.
 Projet:
La fin annoncée du support de la version 11.5.10 a amené le lancement du projet d’upgrade GFS vers la R12.
La migration technique permet de conserver le paramétrage existant et de diminuer l’interruption de service vis-à-vis
des utilisateurs.
L’objectif de l’upgrade technique est de passer de la version 11.5.10.2 à la 12.2.3.
Le version 12.2.3, publiée en Septembre 2013, a été choisie car elle bénéficie :
•
d’un support étendu jusqu’en Septembre 2021.
•
de la fonctionnalité ‘Online Patching’ permettant un minimum d’interruption de service lors d’application de patchs.
•
de l’expérience de la version 12.1
•
de nouvelles fonctionnalités légales liées à certaines localisations.
Le projet a démarré en Octobre 2013 pour une bascule en production en Janvier 2015.
11
REX Projet GFS – Périmètre
 Argentina
 Australia
 Belgium
 Canada
 China – HK
 Denmark
 Finland
 France
 Germany
 India
 Ireland
 Italy
 Japan
 Luxembourg
 Malaysia
 Morocco
 Netherlands
 Norway
 Philippines
 Portugal
 Poland
 Singapore
 Spain
 UK
 Sweden
 Switzerland  USA
 Vietnam
 Taiwan
 United Arab Emirates
Périmètre du projet GFS :
• 31 pays
• 65 Entités Légales
• 98 Unités Opérationnelles
• 2 500 Utilisateurs
• 136 000+ Employés
• 100 000+ Projets
GFS/BO déployés
12
REX Projet GFS – Périmètre du projet de migration R12
 Approche :
Migration Technique à iso-périmètre et iso-fonctionnalités.
 Migration technique Oracle E-Business Suite R11.5.10.2  R12
 Finance (GL, AP, AR, CE, FA, AX) - Project (PA Costing and PA Billing) - Achats : PO.

Nombre de composants spécifiques : 230.
 Implémentation de nouveaux modules R12 :

Payments, E-Business Tax, Subledger Accounting.
 Adaptation du Datawarehouse et des applications de Reporting
 Interfaces  Limitation au maximum des impacts sur les systèmes externes :
 Applications Groupe : SAP (Achats), IBX, Itesoft, Cash Pooler…
 Applications Locales : Saisie des temps, note de frais, systèmes HR, Paie…
13
REX Projet GFS – Planning
2013
Q4
2014
J
F
Design
5 Months
M
A
M
J
2015
J
A
S
SIT 1 - India, France, Italy
Transactions, BO reports excl P&L and KPIs
O
N
D
J
F
M
Validation
SIT 2 – Other countries except UK
= …, BO reports including P&L and KPIs
SIT 3 – FS, NL
= end-to-end scenarios
Validation
Validation
UAT - All countries
= full month end close
Sign-Off
Cut-over
Go-Live
Support
Change Management
BIA # 1
End – User
Knowledge &
Context Training
Training Design &
Development
Plan & Strategy
BIA # 2
SIT1
Train.
SIT2
Train.
SIT3
Train.
TTT
End-Users
training
14
GFS – New R12 functionalities : Suppliers & Customers
 New functionalities :



New Suppliers & Customers User Interface (OAF).
Centralized Trading management architecture for Suppliers, Customers and Banks.
Sites/Addresses were migrated in TCA and are now Global.
 Issues encountered :



New User Interface for Suppliers/Customers reported as not user friendly by the Business and not
homogeneous in AP/AR.
Issues with some of the APIs provided by Oracle to manage Suppliers related data.
TCA Addresses Validations issues for the United States, tightly integrated with Tax Validation for US Sales
tax.
 Solutions implemented :



Dedicated training throughout the project on the new Suppliers/Customers UI + Creation of User Guides &
Training materials (11i vs R12 changes).
SR raised for APIs issues and modification of the Suppliers Related interfaces.
Enrichment of US addresses during the project in 11i before the Upgrade : addition of State/Postal Code.
15
GFS – New R12 functionalities : AP Invoices
 New functionalities :


Invoice Lines are introduced as a new level between the invoice header and invoice distributions.
Tax setup now resides within new module eBTax instead of Payables.
 Issues encountered :




Data Inconsistencies between the new Invoice Line level and the Invoice Distribution level.
Cancellation of some AP 11i invoices was not accounted successfully after the upgrade.
Issues with some unvalidated invoices which prevented Period Close.
Performance issues for AP Invoice Validation.
 Solutions implemented :



Process & training changes on the new AP Invoice Lines feature.
Modifications of existing customs to default same information at Invoice Line level than at Distribution level.
SR raised for the AP Period Close Issues related to AP Invoices & AP Invoice Validation performance issues.
16
GFS – New R12 functionalities : Payments
 New functionalities :






Bank/Branches & Internal Bank Accounts creation moved to Cash Management.
External Bank Acounts created in Payables in the Suppliers UI.
Ownership of Bank Accounts by Legal Entities.
Setup of Payment Process Profiles & Payments Templates.
Payment formatting in XML Publisher.
Introduction of a new Payment Dashboard – new OAF User Interface.
 Issues encountered :


Familiarization with the new User Interface & Process for the Bank Model and Payments (PPP) in R12.
Cancellation of some AP 11i Payment and Prepayment were not accounted successfully after the upgrade.
 Solutions implemented :



Process & training changes for the Banks new functionalities.
Specific trainings for all Test phases (SIT & UAT) and before Go Live on the new Payments Process & User
Interface + Creation of User Guides.
SR raised for the AP Period Close Issues related to Payments & Prepayments.
17
GFS – New R12 functionalities : E-Business Tax
 New functionalities :



New Separate/Central module for Tax Setup/Engine.
No re-design of R11 Tax Codes as per new R12 EBTax Model due to the Project Scope and Timing
 Technical Upgrade of all existing tax codes.
Creation of Tax Codes as per R12 model for new Tax Codes Requirements only.
 Issues encountered :




R12 Tax Functionalities with errors for some countries/localizations :
 India
: TDS Generation for AP Invoices.
 Italy
: Italy VAT Register Issues.
 US
: Issues with Location-based Taxes management.
 Argentina : Tax group handled in ex-11i table.
Remediated Custom not handling properly new Taxes for Oracle.
Tax Setup inconsistencies after modifications of migrated 11i Taxes.
Tax Calculations issues for some migrated transactions.
 Solutions implemented :



Application of Patches provided in SR to solve specific countries issues.
Datafixes provided in SR to fix Tax Setup and/or impacted Transactions (mainly in AP).
Custom remediation + Setup changes to handle Location-basedTax Management for US.
18
GFS – New R12 functionalities : SLA
 New functionalities :



Common / Flexible / Customizable Accounting Engine for all subledgers applications.
Extends and replaces Global Accounting Engine functionality.
Enhanced drilldow functionalities between GL and Subledgers.
 Issues encountered :



SLA Standard Setup & Reports not providing same level of details as in 11i.
SLA incorrect migrated information for Invoices, PrePayments, Payments preventing clean AP Period Closes
for a few OUs when there are actions done by the Business on those 11i transactions (ex : 11i Payment
cancelled in R12).
SLA incorrect migrated Balances.
 Solutions implemented :



Modified SLA description to provided same level of details (or more) in Journal Line description as in 11i.
Created a new custom report for Third Party Balances Report by Account for Reconciliation activities.
SR raised for incorrect migrated data in SLA => Use of Patches/Datafixes to solve issues.
19
GFS – New R12 functionalities : MOAC
 New functionalities :
Allows to access, process and report on data for several OUs within a single applications responsibility.
 For GFS, Project team was able to use one MOAC responsibility per module to access all Operating Units for
the Setup during Cutover activities.
 Issues encountered :
With 11i migrated responsibilities, India did not have the same functionality in R12 for the Period closing in the
Subledgers and scope for Exception Reports in terms of OUs.
 Solutions implemented :
New Security Profile + New MOAC responsibilities per module were created per Indian Legal Entities, to allow
smooth closing of Indian Ledgers and include all related OU in the Exception Reports.
20
REX Projet GFS – Key Focus
Pre-Upgrade :




Cleaning of Interfaces to be worked on by the Business & Project team throughout the project to prepare cutover.
Remediation of the Requests Scheduling (Remove/Replace obsolete 11i Requests and add new R12 Requests).
Remediation of the Responsibilities/Menus/Functions.
Depending on the services interruption duration for the Business, plan the interfaces load and scheduling restart
in advance and progressively before opening the system to the Users.
Change Management : Possible underestimation of Project impacts.
 Payments Processing :
Represents the biggest direct system driven change to Global Process.
 Suppliers & Customers User Interfaces :
No business process flow changes, requires additional training for the users, especially for the Suppliers UI.
 Banks / Accounts Management :
Process & Training changes for the Banks/Accounts creation in CE & AP modules.
21
GFS – Key Focus
Period Close Exceptions :
Throughout the R12 Project and after Go Live :
 Use AP/AR Master GDF Diagnostic to proactively detect & fix transactions that will/might cause issues during
closing.
Majority of issues on GFS were related to migrated 11i AP Transactions (Invoices, Payments, Prepayments).
 Use available GDF (Generic DataFix) to solve known issues preventing period closing detected by the MGD.
… and depending on the Project Scope :
 Localizations
22
A propos de Capgemini
Fort de plus de 130 000 collaborateurs et présent dans plus de
40 pays, Capgemini est l’un des leaders mondiaux du conseil, des
services informatiques et de l’infogérance. Le Groupe a réalisé en
2013 un chiffre d’affaires de 10,1 milliards d’euros. Avec ses
clients, Capgemini conçoit et met en œuvre les solutions
business et technologiques qui correspondent à leurs besoins et
leur apporte les résultats auxquels ils aspirent. Profondément
multiculturel, Capgemini revendique un style de travail qui lui est
propre, la « Collaborative Business ExperienceTM », et s’appuie
sur un mode de production mondialisé, le « Rightshore® ».
Plus d’informations sur : www.capgemini.com
Rightshore® est une marque du groupe Capgemini
www.capgemini.com
Les informations contenues dans ce document sont la propriété exclusive de Capgemini.
© 2014 Capgemini. Tous droits réservés.

Documents pareils