Agilité & Données de la
fonction Finances-Risques	
  
	
  7	
  Novembre	
  2013
	
  
-­‐
	
  
Xavier	
  Warzee	
  &	
  Ala...
Qui	
  sommes	
  nous	
  ?
	
  
Alain	
  Maginot
	
  
2011-­‐2013	
  
InspecBon	
  Générale	
  

1998-­‐2000	
  :	
  Responsable	
  de	
  
département	
  ...
Xavier	
  Warzee
	
  
2012:	
  IG	
  Trained	
  Facilitator	
  
2013:	
  Orga	
  du	
  Scrum	
  Gathering	
  
Paris	
  @	
...
Pourquoi	
  ce`e	
  problémaBque	
  ?
	
  
PosiBonnement	
  parBculier	
  :
	
  
Le	
  domaine	
  bancaire
	
  
Un	
  Service	
  MéBer	
  «	
  Agile	
  »	
  ?!
	
  
Vraiment	
  Agile	
  !!!
	
  
Contexte
	
  

	
  	
  	
  4	
  -­‐	
  	
  ProposiBons	
  
d’amélioraBons	
  dont	
  :	
  
• AutomaBsaBon	
  du	
  
rappro...
Une	
  applicaBon	
  
	
  
originale	
  et	
  significaBve
	
  
Originale	
  	
  
«	
  approche	
  service	
  »	
  de	
  la...
MoBvaBon	
  de	
  ce	
  projet
	
  
>	
  La	
  volonté	
  de	
  la	
  DirecBon	
  Générale
	
  
qui	
  avait	
  idenBfié	
 ...
Les	
  étapes	
  clés	
  !
	
  
Partage,	
  
PriorisaBon,	
  	
  

1-­‐	
  Revue	
  de	
  processus	
  

IdenBficaBon	
  de...
Périmètre	
  MéBer	
  concerné
	
  
Etat	
  des	
  lieux	
  applicaBfs
	
  
Sources	
  de	
  données	
  hétérogènes	
  !
	
  
Complétude	
  

Etat	
  des	
  lieux	
  des	
  procédures	
  MéBer
	
  
>	
  Rapprochement	
  Compta-­‐GesBon	
  perfecBbl...
IdenBfier	
  les	
  axes	
  d’amélioraBon	
  possibles
	
  
•  Travailler	
  à	
  la	
  qualité	
  des	
  données,	
  	
  
...
Cible	
  foncBonnelle	
  :	
  
référenBel	
  unique	
  de	
  données	
  unifiées
	
  
Règlements	
  / 	
  
Livraisons

Trés...
La	
  cible	
  :	
  un	
  Système	
  d’InformaBon	
  	
  urbanisé
	
  

Bloom
berg
Reuter

Situation cible mi -2007

Middl...
LE	
  POINT	
  DE	
  VUE	
  DE	
  L’AGILISTE	
  
Vue	
  du	
  Management	
  :
	
  
Agilité	
  =	
  «	
  plus	
  de	
  règles	
  »
	
  
Vue	
  de	
  l’IT	
  :	
  
Agilité	
  =	
  «	
  UBlisateurs	
  à	
  gérer	
  »
	
  
RelaBons	
  MOA/MOE	
  ?	
  
Ou	
  MéBer/IT	
  ?
	
  
Première	
  étape
	
  
AmélioraBon	
  les	
  éléments	
  du	
  SI
	
  
En	
  mode	
  Agile	
  J	
  

AMÉLIORATION	
  DU	
  SOCLE	
  
Une	
  approche	
  itéraBve	
  et	
  incrémentale	
  
avec	
  tests	
  d’acceptaBon
	
  

*	
  	
  

*	
  CRI	
  :	
  Comp...
Processus	
  itéraBf	
  et	
  incrémental
	
  
•  De	
  plus	
  en	
  plus	
  de	
  comptes,	
  et	
  de	
  contrats,	
  t...
Agilité	
  

Classique	
  

• Ouverture	
  au	
  
changement	
  

• Planifier	
  
complètement	
  	
  
Phase	
  SOCLE	
  	
  

LA	
  DYNAMIQUE	
  DE	
  COLLABORATION	
  
Equipe	
  pluridisciplinaire	
  
	
  
• 
• 
• 
• 
• 

OrganisaBon,	
  comptabilité,	
  IT,	
  …	
  
1	
  Consultant	
  agi...
Le	
  parB	
  pris	
  de	
  la	
  facilitaBon
	
  
• 
• 
• 
• 
• 

ValorisaBon	
  des	
  «	
  sachants	
  »	
  méBer	
  
R...
Agilité	
  

Classique	
  

•  Interac(ons	
  
•  Personnes	
  

•  Processus	
  
•  Ou(ls	
  
Avantages	
  pour	
  les	
  «	
  sachants	
  »
	
  
Conduite	
  du	
  changement
	
  
•  Ils	
  deviendront	
  les	
  «	
 ...
Agilité	
  

Classique	
  

• Collabora(on	
  
avec	
  les	
  
u(lisateurs	
  

• Echanges	
  
contractuels	
  
Bénéfices	
  de	
  la	
  soluBon
	
  
•  Tests	
  d’acceptaBon	
  réalisés	
  durant	
  le	
  développement	
  :	
  
–  Com...
Agilité	
  

Classique	
  

•  Logiciel	
  qui	
  
fonc(onne	
  

•  Documenta(on	
  
Deuxième	
  étape
	
  
Changer	
  les	
  usages	
  du	
  SI
	
  
Compléter	
  les	
  services	
  et	
  les	
  données	
  pour	
  
répondre	
  à	
  tous	
  les	
  besoins	
  MéBers
	
  
• ...
TransformaBon
	
  
•  Les	
  acteurs	
  du	
  côté	
  des	
  MéBers	
  ont	
  été	
  	
  
–  moteurs,	
  contributeurs	
  ...
Barriers	
  to	
  Further	
  Agile	
  AdopBon
	
  
Why	
  is	
  Culture	
  important?
	
  
L’agilité	
  
Le	
  travail	
  est	
  organisé	
  
en	
  cycles	
  courts	
  

Le	
  management	
  
n’interrompt	
  pas	
 ...
Conclusion	
  d’un	
  point	
  de	
  vue	
  Agile
	
  
•  Confiance	
  dans	
  la	
  soluBon	
  
–  Tests	
  de	
  non-­‐ré...
Conclusion	
  d’un	
  point	
  vue	
  MéBer	
  

>	
  AutomaBsaBon	
  de	
  la	
  jusBficaBon	
  du	
  plan	
  de	
  compte...
Références
	
  
•  ArBcle	
  Revue	
  Banque	
  
–  «	
  Unifier	
  les	
  données	
  de	
  la	
  foncBon	
  finances-­‐risq...
Retour expérience Agilité & Données fonction finances risques - Agile Tour Lille 2013
Retour expérience Agilité & Données fonction finances risques - Agile Tour Lille 2013
Retour expérience Agilité & Données fonction finances risques - Agile Tour Lille 2013
Prochain SlideShare
Chargement dans…5
×

Retour expérience Agilité & Données fonction finances risques - Agile Tour Lille 2013

1 953 vues

Publié le

Publié dans : Business
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 953
Sur SlideShare
0
Issues des intégrations
0
Intégrations
477
Actions
Partages
0
Téléchargements
26
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Retour expérience Agilité & Données fonction finances risques - Agile Tour Lille 2013

  1. 1. Agilité & Données de la fonction Finances-Risques    7  Novembre  2013   -­‐   Xavier  Warzee  &  Alain  Maginot        
  2. 2. Qui  sommes  nous  ?  
  3. 3. Alain  Maginot   2011-­‐2013   InspecBon  Générale   1998-­‐2000  :  Responsable  de   département  Syscom,  Missions  de  Conseil     chez  Ges(tres,  Abbey  Na(onal,  Verne  Artésia,   Crédit  Lyonnais,  Société  Générale   2006-­‐2011   1991-­‐1998   Directeur  Back  Office  Marchés   Directeur  de  l’OrganisaBon     Consultant  interne,  Responsable  de   services  opéraBonnels   2004-­‐2006   1988-­‐1991   Directeur  de  Missions,  Conseil  au  sein  des   groupes  Société  Générale,  Caisse  d’Epargne  et  CFF   Organisateur,  Responsable  Back-­‐ Office  Marchés   2000-­‐2004     1985-­‐1988   Directeur  de  Missions,  Conseil  au  sein  des   Responsable  BureauBque,  Réseaux   locaux   groupes,  Société  Générale,  SGAM,  BNP  (Genève)    
  4. 4. Xavier  Warzee   2012:  IG  Trained  Facilitator   2013:  Orga  du  Scrum  Gathering   Paris  @  SCRUM  CONSEIL   2011,  2012,  2013:  Orga  Scrum  Day   2006:  Agile  Alliance  @   VALTECH   2001:  Internet/Web   applica(ons  @  VALTECH   2010:  French  Scrum  User  Group   President  @  MICROSOFT   1995:  Simula(on/Design  of   complex  systems  @  THALES/ UC  BERKELEY   2006:  Cer(fied  Scrum  Master  @   VALTECH   1989:  Object  Oriented   Technologies  @  THALES  
  5. 5. Pourquoi  ce`e  problémaBque  ?   PosiBonnement  parBculier  :   Le  domaine  bancaire  
  6. 6. Un  Service  MéBer  «  Agile  »  ?!  
  7. 7. Vraiment  Agile  !!!  
  8. 8. Contexte        4  -­‐    ProposiBons   d’amélioraBons  dont  :   • AutomaBsaBon  du   rapprochement   compta-­‐gesBon   3  -­‐  Ecoute  &   ObservaBons   1  -­‐  SituaBon   d’un  Back  Office   OpéraBons   Financières   2  -­‐  DiagnosBc   organisaBonnel     • Compréhension  des   dysfoncBonnements,   • IdenBficaBon  des   axes  d’amélioraBons   possibles  
  9. 9. Une  applicaBon     originale  et  significaBve   Originale     «  approche  service  »  de  la  mise  à  disposiBon  de   donnée  côté  «  Back  Office  opéra(ons  financières  »,   •  cadrées  comptablement,   •  enrichies  et  mises  en  qualité,  pour  répondre  aux  besoins  de   la  foncBon  «  Finances-­‐Risques  »,   •  avec  le  développement  d’un  collecteur  de  données  unique.   Significa(ve   Back  Office  responsable  de  la  gesBon  d’opéraBons,   120  milliards  de  total   bilan  consolidé  (en  2007)   représentant  
  10. 10. MoBvaBon  de  ce  projet   >  La  volonté  de  la  DirecBon  Générale   qui  avait  idenBfié  une  situaBon  perfecBble   depuis  quelques  années   qui  souhaitait  ré-­‐aborder  la  quesBon  des   modalités  d’amélioraBon  de  la  situaBon  en   acceptant  de  sorBr  des  schémas  classiques   qui  a  opté  pour  la  conduite  :   •  d’un  diagnosBc  organisaBonnel  complet,       •  d’une  revue  de  processus,  jusqu’à  faire  évoluer  les   processus  de  la  sphère  «  OPERATIONS  FINANCIERES  »  
  11. 11. Les  étapes  clés  !   Partage,   PriorisaBon,     1-­‐  Revue  de  processus   IdenBficaBon  des   axes   d’amélioraBons   Plan  d’acBons   2-­‐  IndustrialisaBon  du   rapprochement  Compta-­‐ GesBon   EvaluaBon  des   modalités  de   réalisaBon   Proof  of  concept,   développement   agile   3-­‐  IdenBficaBon  des   données  uBlisées   par  la  foncBon   Finances-­‐Risques   Recensement  de   toutes  les  sources   uBlisées   Analyse  des   données,   DicBonnaire  de   données   4-­‐  Enrichissement   du  CRI  nécessaire   au  rapprochement   Compta-­‐GesBon   Analyse  des  écarts   entre  existant   (disponible)  et   besoins   Enrichissement  de   l’existant   5-­‐  Mise  à   disposiBon  des   données  à  la   foncBon  Finances-­‐ Risques   Leur  uBlisaBon   SécurisaBon  des   travaux  des   méBers   Réduc(on  des   délais  de  livraison   des  mé(ers   Sécurisa(on  de  la   communica(on   Financière  
  12. 12. Périmètre  MéBer  concerné  
  13. 13. Etat  des  lieux  applicaBfs   Sources  de  données  hétérogènes  !  
  14. 14. Complétude   Etat  des  lieux  des  procédures  MéBer   >  Rapprochement  Compta-­‐GesBon  perfecBble   •  Chacun  des  comptables  du  Back  Office   Comptes   jusBfiait  une  parBe  du  plan  de  compte   avec  ses  propres  méthodes   –  Problèmes  de  complétude   Pierre   Paul     Jacques   Blanc   …   –  Pas  d’approche  systémaBque   –  Lenteur,  écarts  de  délai  dans  les  livraisons   –  Pas  de  documentaBon  /  transparence   Périmètre  non  pris  en  compte  
  15. 15. IdenBfier  les  axes  d’amélioraBon  possibles   •  Travailler  à  la  qualité  des  données,     –  praBquer  des  revues  de  données  détaillées,     –  enrichir  les  bases  des  données  manquantes,     –  fiabiliser  le  cas  échéant…   •  OpBmiser,  sécuriser,  urbaniser  les  traitements  et  les   ouBls  (STP),   •  Mutualiser  les  moyens  alloués  aux  travaux  de   cadrage  comptable.  
  16. 16. Cible  foncBonnelle  :   référenBel  unique  de  données  unifiées   Règlements  /   Livraisons Trésorerie Paiements  /   Flux  de  cash Suivi  des   confirmations Analyse  des   opérations,  suivi des  paramètres  de marché,  leurs  impacts dans  le  t emps Middle,   Reporting Caractéristiques   élémentaires   nécessaires  à   l’administration   des     Opérations Maitrise  de   l’activité,  Contrôle Reporting Contrôle  des   échéanciers Notations Opérations  e t Flux  de  cash Comptabilité French  /  IFRS Rapprochements   compta    gestion Information  de  Synthèse Comptabilité   Générale,  dont     COREP  e t  FINREP Contrôle  de   Gestion Les  données  sont   cadrées   comptablement,     mises  en  qualité,   enrichies,  avant   d’être  mises  à   disposition  des   métiers   utilisateurs
  17. 17. La  cible  :  un  Système  d’InformaBon    urbanisé   Bloom berg Reuter Situation cible mi -2007 Middle et Risques Front DOF Calcul de VAR Reuter Fin info Risque de contreparties ALM et CDG saisie Fin info Application Back Office Flux Contrôle de Gestion ’ ’ Interface Dérivés logés dans des filiales de Crédit Bail Couverture des comptes à terme structurés ALM Stock et Flux l Bloom berg Appli Front Application Front Interface Autres Fronts Autres Back Offices crédits Appli Back Office Back des autres Fronts Outil de Back Office Financier Comptabilit é Réglementaire + Consolidation Groupe Middle et Risques Format pivot Unicit é des donn ées Situation en 2006 Analyse des opérations / marchés Risque de contreparties / Limites ALM et CDG ALM Taux / liquidite Contrôle de Gestion Unicité / cohérence des donn es é Piste d’audit
  18. 18. LE  POINT  DE  VUE  DE  L’AGILISTE  
  19. 19. Vue  du  Management  :   Agilité  =  «  plus  de  règles  »  
  20. 20. Vue  de  l’IT  :   Agilité  =  «  UBlisateurs  à  gérer  »  
  21. 21. RelaBons  MOA/MOE  ?   Ou  MéBer/IT  ?  
  22. 22. Première  étape   AmélioraBon  les  éléments  du  SI  
  23. 23. En  mode  Agile  J   AMÉLIORATION  DU  SOCLE  
  24. 24. Une  approche  itéraBve  et  incrémentale   avec  tests  d’acceptaBon   *     *  CRI  :  Compte-­‐Rendu  d’Inventaire  
  25. 25. Processus  itéraBf  et  incrémental   •  De  plus  en  plus  de  comptes,  et  de  contrats,  traités  à   chaque  itéraBon  (>  21  000  contrats)   •  Traitements  adaptés  et/ou  étendus  à  chaque  itéraBon   •  Tests  d’acceptaBon  à  chaque  fin  d’itéraBon  
  26. 26. Agilité   Classique   • Ouverture  au   changement   • Planifier   complètement    
  27. 27. Phase  SOCLE     LA  DYNAMIQUE  DE  COLLABORATION  
  28. 28. Equipe  pluridisciplinaire     •  •  •  •  •  OrganisaBon,  comptabilité,  IT,  …   1  Consultant  agile,   1  InformaBcien,   2  Consultants  expérimentés  AMOA,  les  comptables,   La  combinaison  de  savoir-­‐faire  pour  :   –  Délivrer  au  plus  tôt  des  résultats  effecBfs  et  uBles   •  AmélioraBon  conBnue,  pragmaBsme,   •  Vélocité,  prédicBbilité,   –  Délivrer  mieux  en  collaboraBon  des  résultats  partagés     •  Refactoring,  découpage  par  lots  gérables,   •  Reconnaissance  de  l’apport  de  chacun  
  29. 29. Le  parB  pris  de  la  facilitaBon   •  •  •  •  •  ValorisaBon  des  «  sachants  »  méBer   Respect  des  individus  dans  la  durée   ImplicaBon  conBnue  des  «  sachants  »   ObjecBf  de  résultat  à  moyen  terme       Lâcher  prise  favorisant  créaBvité  et  innovaBon  dans   les  soluBons  développées  
  30. 30. Agilité   Classique   •  Interac(ons   •  Personnes   •  Processus   •  Ou(ls  
  31. 31. Avantages  pour  les  «  sachants  »   Conduite  du  changement   •  Ils  deviendront  les  «  uBlisateurs  »  de  la  soluBon   –  Ils  vont  bénéficier  de  la  valeur  ajoutée  dégagée  avant  tout   pour  eux,   –  Avantages  :  confort,  efficacité,     –  Maîtrise  foncBonnelle,  pas  de  perte  du  contenu   •  Ils  pourront  se  consacrer  à  l’analyse  des  écarts  –  à   leur  jusBficaBon  dans  de  meilleures  condiBons   –  Les  comptables  consacrent  une  plus  grande  parBe  de  leur   temps  aux  travaux  à  forte  valeur  ajoutée  
  32. 32. Agilité   Classique   • Collabora(on   avec  les   u(lisateurs   • Echanges   contractuels  
  33. 33. Bénéfices  de  la  soluBon   •  Tests  d’acceptaBon  réalisés  durant  le  développement  :   –  Comparaison  du  solde  reconsBtué  avec  le  solde  issu  de  la   comptabilité  pour  chacun  des  comptes,   –  Approche  itéraBve  compte  par  compte,  jusqu’à  couvrir   l’ensemble  du  plan  de  comptes,   •  DocumentaBon  du  processus  mécaniquement  à  jour  et   disponible  à  tous  (et  aux  auditeurs  !)   •  CollaboraBon  en  équipe  pluridisciplinaire  -­‐>  bons   critères  d’acceptaBon  (foncBons,  usages)   •  Respect  des  individus  -­‐>  contribuBons  complètes,   garantes  de  le  présence  de  tous  les  critères  nécessaires    
  34. 34. Agilité   Classique   •  Logiciel  qui   fonc(onne   •  Documenta(on  
  35. 35. Deuxième  étape   Changer  les  usages  du  SI  
  36. 36. Compléter  les  services  et  les  données  pour   répondre  à  tous  les  besoins  MéBers   •  •  •  •  •  •  •  Echanges,  ateliers  avec  les  MéBers   Cartographie  des  sources  uBlisées  par  les  MéBers   Analyse  des  données  contenues  dans  chacune  des  sources   Dédoublonnage  des  données   IdenBficaBon  des  écarts  par  rapport  à  la  soluBon  socle   Enrichissement  de  la  soluBon  Socle     Mise  à  disposiBon  des  données  aux  MéBers  
  37. 37. TransformaBon   •  Les  acteurs  du  côté  des  MéBers  ont  été     –  moteurs,  contributeurs   –  associés  au  changement   •  Dynamique  de  collaboraBon  préservée    
  38. 38. Barriers  to  Further  Agile  AdopBon  
  39. 39. Why  is  Culture  important?  
  40. 40. L’agilité   Le  travail  est  organisé   en  cycles  courts   Le  management   n’interrompt  pas   l’équipe  pendant  un   cycle   L’équipe  décide  du   travail  qu’elle  peut   faire  en  un  cycle   L’équipe  rend  des   comptes  au  client,  pas   au  manager   L’équipe  esBme  le   temps  qu’il  lui  faut     L’équipe  décide   comment  faire  le   travail  pendant  un   cycle   L’équipe  mesure  ses   propres  performances   Les  objecBfs  à   a`eindre  sont  définis   avant  le  départ  de   chaque  cycle   Les  objecBfs  sont   définis  par  des  usages   du  produit  :  ‘user   stories’   Chercher  à   systémaBquement   lever  les  obstacles  
  41. 41. Conclusion  d’un  point  de  vue  Agile   •  Confiance  dans  la  soluBon   –  Tests  de  non-­‐régression  au  niveau  foncBonnel   •  AcceptaBon  «  automaBsées  »   •  Valeur  crée  réelle     •  Accueil  du  changement  posiBf  -­‐>  fait  du  sens  au  niveau   méBer  /  sachants   •  Maitrise  des  risques  coûts  /délais   •  ProducBon  de  valeur  immédiate  par  les  itéraBons,  et   couverture  de  l’ensemble  du  plan  de  comptes  en  3  mois  
  42. 42. Conclusion  d’un  point  vue  MéBer   >  AutomaBsaBon  de  la  jusBficaBon  du  plan  de  comptes   RaBonalisaBon   DocumentaBon   Homogénéité  des   méthodes   Couverture   complète  «  du   plan  de  comptes  »   Transparence   RéducBon  des   délais  d’arrêté   comptable  
  43. 43. Références   •  ArBcle  Revue  Banque   –  «  Unifier  les  données  de  la  foncBon  finances-­‐risques  »   -­‐  h`p://bit.ly/19UBt48     –  Format  papier  disponible  J   •  Revue  Banque   –  h`p://www.revue-­‐banque.fr   •  Scrum  Conseil   –  h`p://www.scrumconseil.fr  

×