Les deux logiciels sont en réalité un assemblage de plusieurs modules développés à part les uns des autres, parfois pour des commandes précises de client, parfois rachetés à d’autres entreprises, reliés à grand-peine et intégrés au chausse-pied.

Les modules financiers sont les plus anciens[1], et vus leur complexité et leur importance[2], ils n’ont jamais été totalement réécrits.
Du point de vue de l’organisation des données, ils ont le mérite d’une architecture simple et compréhensible. À l’utilisation, ils me sont à peu près incompréhensibles (mais je ne suis ni comptable ni formé sur ces modules).

À l’inverse les modules de CRM[3], à la mode depuis quelques années, bénéficient de tous les derniers gadgets d’interface ad nauseam : arborescences, tableaux intégrés genre Excel et pléthore d’onglets, sous-onglets, sous-sous-onglets, fenêtres imbriquées, paramétrage plus-flexible-tu-meurs....
En général ces innovations sont contrebalancées par la perte des avantages de l’interface « ancien style » (facilité de recherche des champs techniques, copier-coller facile, double-clic dans SAP...) et un degré de complexité de plus dans la programmation[4].

Oracle ayant racheté plusieurs de ses challengers (l’ERP Peoplesoft, lui-même acquéreur auparavant de JDEdwards, ou le CRM Siebel), les incohérences de logique et d’interface ne sont pas terminées dans l’unification de tout ce beau monde (projet Fusion d’Oracle). Ce qui était au départ une base de données qui faisait tourner des programmes PL/SQL se dirige vers un mille-feuilles de PL/Java/XML/SOA/BPEL intégrant l’ancienne suite d’Oracle, celle de Peoplesoft, etc.
SAP pour sa part cherche plus à tout redévelopper lui-même, mais fait évoluer son produit radicalement. R/3 (l’ERP « classique ») a peu évolué pendant que la partie CRM évoluait à fond, la différence est flagrante.

Partie 1 : Des interfaces hideuses

Partie 2 : Deux gros patchworks

Partie 3 : Des interfaces très particulières

Partie 4 : Philosophies opposées

Partie 5 : Schémas de données

Notes

[1] Rappelez-vous : ce sont les comptables qui ont payé le développement de l’informatique (avec les militaires).

[2] Un bon consultant dirait « criticité ».

[3] Gestion de la Relation Client, en pseudo-français ; rappelons que cela couvre aussi bien la télé- que l’après-vente.

[4] Sous SAP : La programmation à l’ancienne genre ABAP/Cobol avait le mérite de la clarté besogneuse. Tenter d’y rajouter des notions de programmation objet relève du mariage contre-nature, et la difficulté tient autant à l’environnement de développement lourdingue qu’à l’évolution du langage. Sous Oracle, la transition me semble plus facile, peut-être parce qu’on reste finalement au sein de triggers, programmes, packages PL/SQL en rajoutant juste quelques types d’objets différents ; je n’ai pas touché au Java.