ERP Existant ou sur mesure

[2nis]

Bonjour,

1 an de recherche d'un ERP, on arrive au terme d'une pré-étude d'une quinzaine de journées (et quelques miliers d'euro) et ca n'a pas encore l'air concluant à 100%.

Etant donné qu'on a en interne une idée assez précise de l'outil dont on a besoin (mais pas de vrais informaticiens), que notre travail paraît très spécifique, est-il réaliste de songer à faire développer une appli. sur mesure ?

(ERP destiné à un seul siège au départ (+-30 personnes) et au groupe ensuite (+- 100 personnes).

[dbrun]

bonjour,
le choix de ton ERP va dependre des modules qui vont être le plus utilisés. chaque ERP possède ses points forts et ses points faible.
peux tu nous en dire un peu plus sur les besoins spécifiques de l'entreprise ?

[2nis]

Les besoins spécifiques sont trop vastes pour exliquer ici, en gros, les plus gros ennuis sont :

- Vente de marchandise pas encore achetée (sur base de couts budgétés)
- Les prix de vente sont négociés au cas par cas
- Les marchandises livrées ne sont pas forcément celles qui ont été vendues (rien que pour expliquer ce point, il faut plusieurs jours )
- Couverture du risque de change selon les ventes et non selon les achats
=> Valorisation des stocks en devises, masse des devises
- Important service shipping (affrètement et suivi de navires)
- .....

En bref, même si des sociétés de trading, il y en a beaucoup, on ne fait rien comme les autres (et ca ne doit pas changer, c'est peut-etre la clef du succes)

Je suis maintenant certain de savoir ce qu'il faut et je pense que les plate-formes de développement modernes doivent permettre un développement sur mesure rapide...... me trompe-je ??????

[dbrun]

la ou tu te trompe (je pense) c'est sur le mot : rapide. le monde de l'erp est en plein essor, la mise en place d'un erp complexe prend du temps projet de 30 à 400 jours chez nous. donc moins de disponibilité, de plus le développement rajoute encore du temps.

[2nis]

En disant rapide, je pense à quelque chose du genre 6 à 8 mois, pas 3 semaines.
Ca fait déjà plus d'un an qu'on cherche à changer notre "ERP" actuel sans aucun résultat satisfaisant, on n'est plus à quelques mois près.

Ma préoccupation est plutôt de savoir si une appli. dévelopée pour nous peut, avec un budget similaire, donner de bons résultats (simplicité et "beauté" de l'interface, relations avec Excel, Word,... , acces à distance sécurisé, modularité, développements futurs, ...).

On a eu droit à une démo. d'une appli. développée (en Delphi) pour une société +- similaire à la notre et j'ai trouvé ca tres tres mauvais.

[Chris2R]

Je pense qu'une solution crédible est de prendre un ERP existant afin de bénéficier de toute son architecture technique, de le dépouiller de tout ce qui ne va pas te servir (voir de toutes les fonctions) et d'ajouter le reste.

Je suis Chris de GHR Software, notre système gratuit (ZIIA EIS) se prête très bien à ce type de démarche. Il est entièrement à base de plugins, avec une indépendance complète des fonctionnalités par rapport à l'architecture (j'ai fait un petit poste par ailleurs pour le présenter, en bêta actuellement, et avec des fonctionnalités "business" limité).

Par contre, il n'est pas Open Source, donc si vous souhaitez le faire vous même je vous recommande la même démarche avec ADempiere ou Compiere par exemple (qui sont Open Source et plutôt riche en fonctionnalité).

Je pense que ce type de démarche a de l'avenir, car dans de nombreux cas, en partant d'une base technique solide, il est très rapide (quelques semaines/quelques mois) d'obtenir des premières versions fonctionnelles (avec une approche 20/80) . Cela évite aussi de devoir suivre l'uniformisation des entreprises pronées par les ERP "lourds" (ou l'alternative qui est de passée un temps monstrueux à le "customiser", avec consultant et toute la clique).

Cordialement,

Chris.

[2nis]

Merci Chris,

Quelqu'un peut-il chiffrer +- le gain de temps si on faisait développer sur une base existante par rapport à un développement complet ?

(hormis la belle présentation, je n'ai encore rien trouvé d'un ERP existant qu'il ne faille modifier ou recréer)

Comme je l'ai dit, il n'y a pas de vrais informaticiens dans la boîte, on n'a donc pas forcément besoin d'open source, mais d'un partenaire qui nous permette de nous investir avec eux dans la conception du projet.

[Chris2R]

Bonjour,

C'est clair que déjà avec des informations précises il est délicat de chiffrer un développement ou une adaptation. Il faudrait donc beaucoup d'information pour te renseigner (et aussi y passer beaucoup de temps).

Par contre, ce que je peux te conseiller, c'est d'adopter une méthode de développement Agile. Ceci peut t'éviter de devoir répondre "directement" à ta question.

Pour schématiser, l'idée est que dans tous les cas du auras besoin de ton système et qu'avec un développement Agile (et un prestataire compétent, et à mon avis une fondation technique solide) tu seras CERTAIN d'avoir le meilleur ROI possible, avec une maîtrise des délais et coûts plutôt qu'une maîtrise prédicitive du contenu fonctionnel exact.

Par exemple, tu pourrais t'engager avec un prestataire sur une durée et un volume de travail initial (genre 3 ou 6 mois avec 2 ou 3 personnes). Ensuite, très rapidemment durant le déroulement, tu pourras toi même juger en fonction du travail visible restant du temps restant estimée (et ajustée tes priorités en fonction). En attentant, en quelques semaines à peine, tu devrais avoir un système apportant déjà de la valeur (à condition de ne pas partir de rien, du moins c'est mon avis).

Cette approche est très moderne et pas toujours bien connue (même par les prestataire, qui souvent sont resté avec des méthodes des années 80 très séquentielles et rigides) et une des difficultés est de trouver un prestataire qui maîtrise réellement le développement Agile (Extreme Programming, Chrystal, Scrum, Agile Unified Process, ...), et pas uniquement dans le discours (très attention à ce point, il faut vraiment vérifier sa compétence Agile).

A+,

Chris

ps : J'ai un peu raté un autre coté de ta question. Je suis de retour ce soir et j'essaye de reprendre...

[Chris2R]

Ok, me revoici (après une après midi à discuter avec un (grand) industriel de ses problèmes de gestion des outillages spéciaux dans les BOM de SAP...).

Pour ce qui est de la question "Quelqu'un peut-il chiffrer +- le gain de temps si on faisait développer sur une base existante par rapport à un développement complet ?" :

La réponse dépend de deux choses il me semble (j’assume que la composante fonctionnel est négligeable) :

-tes besoins en fondations techniques (persistance, migration BD, rapport excel/word/..., GUI configurable, macros/automation, attachement, unités, mode déconnecté, rôles/users/droits, ...)

-la base existante choisie (Compiere, TinyERP, Adempiere, ZIIA EIS, mais aussi peut-être des choses comme Leonardi, SAP Netweaver, ...)

Moralité, si on a de large besoins en fondations techniques et qu'on choisit une bonne base, alors je pense qu'on gagne aux alentours de 8 à 24 mois de travail (ordre de grandeur pour le temps nécessaire pour développer une fondation technique (type ERP) vraiment solide, d'après mon expérience).

A l'inverse, si les besoins techniques sont faibles, et que J2EE ou .NET permettent grosso modo de les couvrir, alors avec une équipe expérimentée, les gains (obtenu par l'utilisation d'une base) peuvent tendre vers 0 (admettons quelques semaines le temps de mettre en place l'architecture technique générique autour des services J2EE ou .NET par exemple).

L’avantage de partir avec SAP ou Dynamics par exemple, est qu’il y a des chances de tomber sur des prestataires compétents (certifiés, formés, …) alors que sur d’autres systèmes (partir de scratch ou alors en Open Source), il peut être délicat d’être certain de son choix de prestataire. C’est un avis personnel (évidemment avec ZIIA EIS et GHR Software, ça se passe bien, … LOL).

Chris

[2nis]

Merci beaucoup Chris pour tes bons conseils éclairés

Une petite question ...

Comme je l'ai dis, il n'y a pas de vrai informaticien chez nous (moi, on me prend pour 1 pro parce que je fais des programmes en VBA sur Access lol).
Alors quand tu dis : "si on a de large besoins en fondations techniques", j'ai un problème, c'est que je ne sais même pas de quoi tu me parle

Par contre, je me suis renseigné sur l'extrème programming et ca me parait être une bonne solution dans notre cas (ca permet une étroite collaboration et d'éviter de partir trop loin sur une mauvaise voie). Non ?

Encore merci à toi.

Tout conseil toujours bien venu, ce projet, j'y tiens

[Chris2R]

Par fondations techniques j'entends le genre de services techniques qu'un système de type ERP doit rendre indépendemment des fonctions métiers qu'il va couvrir. Tes besoins en fonction technique peuvent être plus ou moins poussés.

Par exemple, l'export Word ou Excel sont des besoins techniques fréquents. Qu'importe ce qu'on exporte (des clients, des produits, des devis, ...), l'important est que le système prévoit ces types d'exports (et la customistion des rapports, ...).

Idem pour la "migration BD" : un système type ERP ce doit de pouvoir migrer automatiquement les bases de données d'une version à une suivante, quelles que soient les données en question. Bizarrement, peu d'ERP supportent ceci il me semble, c'est souvent une prestation de service qui permet d'upgrader vers une version plus récente de l'ERP (et le prestataire s'occupe de la migration avec des outils non Open Source, Compiere procède ainsi sauf erreur de ma part).

Autre exemple avec les unites : les valeurs entrées dans le système doivent pouvoir être transformées pour gérer les unitiés. L'exemple typique est la monnaie, par exemple transformer un devis en Euros en devis en Dollars. Mais il faut aussi penser aux distances, volumes, poids, ... Idem, quelles que soient les données métiers gérées, ce besoin de gestion d'unité persiste et doit être géré.

Curieusement, la notion de "fondation technique" (ou d'architecture technique générique) n'est pas si répandue. Le livre 2TUP de Pascal Roques (consultat de la société Valtech) est l'un des meilleurs à mon sens à développer ces concepts en chapitre 5 et 9... La difficulté sur cet aspect est le besoin d'abstraction et de généricité qui n'ai pas facile à cerner pour des équipes non habitués à ces réflexions.


Pour ce qui est de extreme programming (XP), je pense en effet que cela peut être d'une bonne aide dans ton cas. Un moyen intéressant de tester des consultants sur le sujet est de les confronter au fameux "The Case Against Extreme Programming" ici :

http://www.softwarereality.com/lifec...against_xp.jsp

C'est une critique pertinente et fondée de la méthode XP, et à mon sens, une vraie équipe Agile devrait être capable de la réfuter (par ses adaptations et pratiques propres).

En ce qui me concerne, j'ai tendance à pousser pour faire du Agile Unified Process, c'est à dire l'utilisation du très riche Unified Process en mode très Agile (des études montrent que XP est en fait une instance du Unified Process, ce qui attestent à mon avis de la pertinence de cette approche).

Chris

[Chris2R]

Vous êtes une société de trading ? Du trading de quoi (action en bourse, marchandise, ...) ?

Chris

[Chris2R]

Peut-être une autre possibilité d'approche pour toi pourrait être le "Best Of Breed", c'est une sorte d'alternative entre l'ERP "global" et le développement spécifique :

Il s'agit de prendre plusieurs logiciels, chacun bon dans leur domaine et de faire un développement type EAI (Enterprise Application Integration, avec SOA etc.) pour en faire un système intégré. Evidemment, il faut pouvoir identifier des logiciels bons dans les domaines nécessaires (note : s'il existe des trous pas trop nombreux, ils peuvent toujours être comblés par des développements spécifiques ponctuels, en même temps que les tâches d'EAI) et avoir une équipe EAI/SOA (et Agile sans doute dans ton cas).

La suite est un avis personnel certainement sujet à débats :

Au final, dans ce type de discussion, je retombe souvent sur la même idée. Je prône dans nos démarches une approche 20/80 (qu'elle soit basée sur un ERP, un développement spécifique, un "Best Of Breed" ou alors hybride), c'est à dire que 20% des fonctions apportent 80% de la valeur. Je vais un peu plus loin, en ajoutant une couche de 20/80 qui est que 20% de l'effort apportera 80% des 20% de fonctions nécessaires.

C'est sans doute un peu tiré par les cheveux, mais mon extrapolation est que souvent, avec environ 4% (20/100 * 20/100) de l'investissement (la difficulté étant de bien le cibler) on obtient environ 64% (80/100 * 80/100) de la valeur... Ensuite, en fonction des besoins, on peut toujours investir par la suite pour grimper vers les 100% de valeur. Bon, c'est un peu extrême, mais l'idée est là (et l'idée est confirmée par mon expérience et est inspirée/extrapolée/détournée de PARETO bien sûr).

Le défaut des démarches ERP habituels (ou des développements spécifiques sans fondation technique ou non Agile) est qu'à mon avis ils inversent ces chiffres et tendent à faire les 80% de l'effort avant d'obtenir 20% des résultats.


Pourquoi je dis tout cela (je me suis posé la question après l'avoir écris) ? ... Je pense que ces éléments peuvent être intéressants par rapport à ta question initiale : "ERP Existant ou sur mesure?".

A+

Chris

[Bill54]

Bonjour,

Désolé mais je ne peux te parlé ici que de SAP R/3.

R/3 car je pense que vous cherchez surtout un ERP pour le back office?

SAP est très 'flexible' tu peux l'adapter à tes processus. C'est d'ailleurs le rôle de l'intégrateur.

SAP est amalgamé avec "coût important", Or il existe des prépackagé moins onéreux. Si tu fais confiance à un bon intégrateur le ROI se fera sentir plus vite.

Concernant l'export vers Excel ou Word, SAP le gère très bien (DUET) tu as même par défaut des extract possible vers excel de certaine tables

[dbrun]

bonjour,
+1 pour bill 54
faire confiance à un bon integrateur me semble une bonne chose.
de plus pas mal d'ERP ont des modules que l'on peut acquerir idependamment et que l'on peut deployer ou non par la suite une fois que les modules de bases sont testés et approuvés.