jump to navigation

Quelques enseignements à tirer des ERPs (2/2): une organisation pour construire le SI avril 17, 2006

Posted by vincent poncet in Organisation.
trackback

Les concepteurs des ERPs ont réussi à réunir de manière homogène et cohérente de nombreuses fonctions métiers disparates. C’est une révolution dans l’histoire de l’information de gestion, parce qu’auparavant les applicatifs n’étaient conçus qu’en fonction d’une typologie de besoin métier. L’ambition pouvait sembler démesurée, mais force est de constater qu’au moins une partie du chemin a été accompli. L'ERP a apporté une homogénéisation du SI, mais il a aussi apporté son propre lot de rigidités. On peut tirer parti de cet enseignement pour esquisser une organisation de la DSI capable d'avoir un système homogène et évolutif aux besoins de changements de l'entreprise.

Ayant bien identifié que le problème essentiel était la dissémination des informations, leur solution a été de bâtir les différents modules applicatifs autour d’un modèle de données unique. De même, étant parti des besoins globaux de l'entreprise, les processus métiers ont été conçus de manière transverse dès le départ. Dans un ERP, les objets métiers sont présents de manière unique et les processus métier sont identifiables à l'intérieur de la solution. De son côté, le développement par applications nous a laissé un paysage applicatif avec des duplications de données, des différences de représentation et même des différences de valeur de ces données. De même, ce mode de développement ne permet pas d'avoir une visibilité sur l'implémentation des processus métiers. Les processus métiers sont enfouis et éclatés dans pléthore d'applications à travers tout le SI. L'informatique héritée de l'âge du développement applicatif permet certes d'exécuter des opérations, mais elle ne permet pas d'en suivre l'exécution. Enfin, elle ne permet surtout pas de se reconfigurer rapidement pour répondre aux besoins changeant de l'entreprise.

La difficulté d’assurer la cohérence aussi bien des objets métiers que des processus métiers réside dans le fait que ces deux entités sont interdépendantes. D’un côté, les objets métiers sont utilisés par plusieurs processus, de l’autre, les processus manipulent plusieurs objets métiers. L’objet « Client » est utilisé par de nombreux processus, comme par exemple, « Prise de Commande » ou « Retour SAV ». De son côté, le processus « Prise de Commande » manipule aussi bien l'objet « Client » que l'objet « Produit ».

Le développement par applications conduit à une incohérence et non-homogénéité des objets et des processus à travers le système d'information. En effet, se limitant à une vue centrée sur une typologie de besoins spécifiques, l'application ne traduit qu'une vue incomplète des objets et des processus de l'entreprise.

« Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. »
Loi de Melvin Conway, 1968

Pour arriver à faire cohabiter des définitions globales des objets métiers et des processus métier de l’entreprise sans en dupliquer des instances, les éditeurs d’ERP ont dû construire et raffiner les objets métiers en même temps qu’ils ont construits et raffinés les processus métiers. Pour arriver à ce résultat, il est fortement probable que leur organisation interne distingue des responsables du développement des objets métiers d’une part et des responsables de processus métiers, d’autre part. Nous n'avons pas trouvé de documents tangibles sur l'organisation interne des éditeurs d'ERP, mais il y a des éléments qui corroborent cette thèse. En juillet 2003, SAP a annoncé qu'ils redéfinissaient l'organisation du développement de leur produit.

Following the creation in February 2003 of SAP’s Technology Platform organization (formerly Technology Development) led by Shai Agassi, member of the SAP Executive Board, SAP also announced today the newly created Application Platform & Architecture (AP&A) group, led by Peter Zencke, member of the SAP Executive Board. This group will drive the SAP Enterprise Services Architecture, enabling the BSGs to rapidly develop, configure and assemble industry and solution-specific capabilities. The AP&A group will develop reusable core business objects (such as cost/profit centers); business process patterns and user interface patterns as well as engines that are used in multiple industries (such as pricing engines); and product suite elements. The AP&A group will also facilitate and streamline all global research and innovation activities at SAP, focus on further improving time-to-market and enhance overall product quality.

Les DSIs doivent apprendre de l’organisation des éditeurs d’ERP, car si elles arrivaient à intégrer leur modèle en leur sein, elles pourraient avoir ce qu’elles recherchent, c’est à dire un SI cohérent, aligné sur le business et l’accompagnant dans ses évolutions.

Tant que les DSIs continueront à être organisées par responsabilité d’applications, elles souffriront de ce manque de cohérence, de ces coûts d’intégration et de ce manque d’agilité qui les caractérisent tant. Ces problèmes ont une source organisationnelle. Il est inutile de courir après la dernière technologie quand son organisation ne peut pas permettre de mettre en œuvre l’agilité. Les seuls éléments qui ont du sens vis-à-vis de l’entreprise ne sont pas les applications, mais les objets métiers et les processus de l’entreprise.

La DSI doit donc abandonner son organisation par application. Elle doit désormais s’organiser par responsabilités de processus et d’objets métiers. Le chemin sera long et difficile, il y aura de nombreuses réticences à ce changement. Mais ce changement est inévitable pour tendre vers une DSI partenaire du métier qui ne soit plus un partenaire limitateur mais un partenaire facilitateur.

Commentaires»

No comments yet — be the first.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :