je doit choisir un ERP et j'hesite entre compiere et tiny?
comment faire pour fixer mon choix et il y a t il d'autre erp gratuit
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Quel ERP choisir ?
je doit choisir un ERP et j'hesite entre compiere et tiny?
comment faire pour fixer mon choix et il y a t il d'autre erp gratuit
Bonjour,
Il faudrait prioriser vos besoins avant d'établir une short liste d'ERP qui répondent aux besoins. Ensuite, regarder en détail chacun afin d'identifier le meilleur. Tester le et en cas de surprise revenir à l'étape précédente... il faut juste espérer que cela se produise vite. Il existe beaucoup d'autres ERP gratuits (Adempiere, ERP5, ZIIA EIS, OpenBravo, et bien d'autres), mais Compiere est sans doute le plus populaire actuellement.
Réunion aujourd'hui: Un équipementier (pour lequel j'interviens sur un une application spécifique (non ERP) mais qui s'intègre avec l'ERP) qui au bout de 2 ans d'effort autour d'Axapta (ERP Microsoft) à décidé de se retourner (à grand frais) vers SAP (à grand frais aussi). Je prédis que ça se passera mal aussi (avec 10 personnes), et qu'ils finiront pas revenir à la méthode initiale (moins high tech mais opérationnelle). Axapta a été un fiasco retentissant (production chaotique pendant plusieurs mois et plusieurs affaires perdues). Je pense que SAP finira pareil.
Moralité, la première question est sans doute : Etes-vous certain d'avoir vraiment besoin d'un ERP ???
Chris,
GHR Software, ZIIA EIS, free Enterprise Information System
www.ghrsoftware.com
Pourquoi SAP ne conviendrait il pas?Envoyé par Chris2R
Sur quel critères vous vous basé?
Pourquoi "A grand frais"?
Depuis quand un ERP SAP pris en charge par un bon intégrateur fait-il perdre des opportunités ou affaires?
SAP ne permet-il pas une évolution beaucoup plus important que les autres ERP?
Ne couvre t-il pas un périmètre beaucoup plus large? (pas besoin de 50 appli).
Je serais très friand de vos réponses.
Consultant fonctionnel SAP CRM - SD/MM
Bonjour,
TinyERP et Compière sont 2 solutions open source performantes mêmes si elles n'ont pas tout à fait les mêmes cibles en terme de taille d'entreprise.
Compière est plus orienté pour les "Grosses PME voire plus" TinyERP étant plus destiné aux TPE et aux PME.
L'avantage TinyERP à mon sens est qu'il mets à votre disposition une base de départ saine autour de laquelle vous pouvez ajouter plus de 200 modules fonctionnels.
MD
www.héonium.com
Réponse à Bill54,
QU: "Pourquoi SAP ne conviendrait il pas? Sur quel critères vous vous basé?"
RE : Je pense simplement qu'il ne conviendra grosso modo ni plus ni moins que Dynamics AX
QU: Pourquoi "A grand frais"?
RE: Car c'est la cas, SAP est budgété peu ou prou idem qu'Axapta (le budget sur 3 ans équivaut à environ 12% de la masse salariale (au sens comptable), ce qui est énorme…)
QU: Depuis quand un ERP SAP pris en charge par un bon intégrateur fait-il perdre des opportunités ou affaires?
RE1: Le bon intégrateur (sans doute vous même par exemple), ils le cherchent encore, comme beaucoup il semble... Vu la difficulté à en trouver, c'est à se demander si ce n'est pas les outils qui sont trop mal conçu, inaccessible, fermé, …
QU: Depuis quand un ERP SAP pris en charge par un bon intégrateur fait-il perdre des opportunités ou affaires?
RE2: Lorsque les clients ne sont plus livrés car on ne peut plus fabriquer car les stocks de matière sont vides et le planning des ressources machine est chaotique on perd des affaires… Voilà assez concrètement ou peut amener une démarche ERP ratée…
QU: SAP ne permet-il pas une évolution beaucoup plus important que les autres ERP?
RE: Non, je ne pense pas. ADempiere par exemple est bien plus ouvert pour les évolutions (TinyERP aussi par exemple, sans même parler du notre), avec communauté ouverte etc. Je pense que SAP, Axapta, Oracle etc se valent de ce point de vue, à mon sens, ils sont tous issus de "l'ancienne école" de l'ERP, avec l'objectif de générer du profit pour les précieux partenaires intégrateurs (qui en retour vendent les licences).
QU: Ne couvre t-il pas un périmètre beaucoup plus large? (pas besoin de 50 appli)?
RE: Large certe, mais de façon pertinente/adaptée j'en doute, vue les efforts colossaux habituellement nécessaires à la mise en place (de SAP par exemple). La largeur c'est ce qui permet de le rendre attrayant aux directions... La pertinence c'est ce qui coince pour les opérationnels, avec la réserve exprimée plus bas, pour les processus "standards".
QU: Je serais très friand de vos réponses.
RE: De façon générale, je connais (personnellement) plusieurs sociétés utilisatrices d'ERPs "old school" (SAP et Navision principalement) qui exploitent grossièrement l'ERP comme BD centralisée (sauf pour la partie Compta/Finance/GRH, voir NOTE à la fin).
Pour ce qui est de la gestion quotidienne (de nouveau hormis Compta/Finance et parfois GRH), ils se retrouvent à copier/coller (même pas à exporter/importer !, j'atteste) des données entre l'ERP et des outils plus light et souple (souvent autour d'Excel, petites applications spécifiques, MS Project, …). J'ai participé à des séances de travail avec l'ERP, et vue les lourdeurs globales, ceci est parfaitement compréhensible (lourdeur ergonomique d'une part, mais aussi et surtout fonctionnelle).
Ceci est un fait (malheureux, certes) que j'observe (et qui ne nous arrange pas particulièrement, soit dit au passage). Evidemment, ils ne s'en ventent pas dans les journaux spécialisés, cela ne ferait pas sérieux vis-à-vis de leurs clients (qui en réalité font de même, je le sais, car je travail avec des couples clients/fournisseurs sur certains projets). Mais derrière les apparences, les dents grinces.
NOTE (analyse perso/subjective pour expliquer ce phénomène): Il semble que dès qu'on sort des activités réglementées et/ou gérées de façon standard (genre compta, finance, RH dans nos cas) pour aller vers les activités différenciées (genre ingénierie, conception, chaîne de valeur, innovation, R&D, industrialisation, …) les problèmes arrivent.
Ceci tient certainement au fait que l'adaptation de l'outil à l'entreprise (sur les aspects très différenciés) est trop lourde d'une part (déjà que sans cela l'ERP est coûteux) et que d'autre part "abaisser" l'entreprise à l'outil (comme le veut implicitement la philosophie des ERPs "old school") n'est pas une option car elle perdrait ses avantages concurrentiels. Donc une sorte de compromis est tenté avec les résultats que j'ai rapporté ci-dessus (utilisation des anciens outils spécifiques et adaptés pour la vraie gestion et utilisation de l'ERP comme BD, mise à jour uniquement si la pression de la direction l'impose)
Par ailleurs, il est intéressant de voir comment par exemple le vrai PLM (Product Lifecycle Management, genre Windchill/VPM/Enovia/MatrixOne/…) arbore une approche plus adaptée à cette problématique, avec des résultats pas toujours satisfaisants encore, mais c'est tout de même une piste intéressante pour essayer d'enrailler les échecs ERP (et notamment les "anciens" SAP, Nav, ...).
Amicalement,
Chris
RE : Je pense simplement qu'il ne conviendra grosso modo ni plus ni moins que Dynamics AX
RE2 : je ne pense pas que cette argument soit vraiment pertinent. Pour ma part il m'en faut plus.
RE: Car c'est la cas, SAP est budgété peu ou prou idem qu'Axapta (le budget sur 3 ans équivaut à environ 12% de la masse salariale (au sens comptable), ce qui est énorme…)
RE2 : Cela dépend encore de l'intégrateur. Des processus à mettre en place, c'est très variable! Il ne faut pas généraliser!
RE : Lorsque les clients ne sont plus livrés car on ne peut plus fabriquer car les stocks de matière sont vides et le planning des ressources machine est chaotique on perd des affaires… Voilà assez concrètement ou peut amener une démarche ERP ratée…
RE 2 : Il en va de même avec un TinyERP ou tout autre ERP !!! Pas applicable que à SAP et Dynamic!
RE: Non, je ne pense pas. ADempiere par exemple est bien plus ouvert pour les évolutions (TinyERP aussi par exemple, sans même parler du notre), avec communauté ouverte etc. Je pense que SAP, Axapta, Oracle etc se valent de ce point de vue, à mon sens, ils sont tous issus de "l'ancienne école" de l'ERP, avec l'objectif de générer du profit pour les précieux partenaires intégrateurs (qui en retour vendent les licences).
RE 2 : Je demande franchement à voir, SAP est orienté SOA! et communique avec pas mal d'outils! Il est très évolutive (spécifique à souhait)!! adaptable à beaucoup plus d'industrie que tout autre ERP.
RE 2 bis : un passage sur SDN, help.sap, USP... et vous verrez que la communauté SAP est beaucoup plus grande que ce que l'ont peut croire! Encore faut-il être dedans pour en juger
Pour conclure, je ne pense pas que l'ont peut juger de SAP sans être dans le domaine. Il est bien de défendre ses ERP préféré pour une raison X ou Y mais il ne faut pas descendre les autres sans arguments pertinent!
Il faut vraiment savoir de quoi ont parle pour se permettre ces jugements. Avoir une certaine expérience. Pas seulement avoir participé à un projet ou 2! et prendre comme exemple les projets ou ça na pas marché!
Bonne journée
Consultant fonctionnel SAP CRM - SD/MM
Sans vouloir vous ennuyer messieurs:
- SAP marche surement très bien pour de nombreuses entreprises. Il est néanmoins je pense soumis à un logique de logiciel propriétaire et tout ce que cela implique.
- Les ERP libres en général, sont eux aussi éfficaces, mais souffrent d'un déficit d'image et n'ont pas derrière eux une entreprise aussi importante que SAP ou Microsoft.
Néanmoins:
- De par son essence un Logiciel Libre (dont on connait le code) mets l'interopérabilité avec d'autres logiciels au coeur de son developpement.
- La communauté au sens ou on l'entends dans le libre est completement différente ce que vous entendez autour d'un logiciel propriétaire: Ce sont des développeurs qui contribuent à améliorer et developper des produits.
Enfin, je pense que la question était d'aider une personne a choisir en TinyERP (qui s'apelle maintenant OpenERP) et Compière (ou Adempière).
MD
www.heonium.com
Bonjour,
Il s'agit la encore d'une remarque non fondée si je peux me permettre.
C'est quoi un logiciel libre?
Si d'après votre définition il s'agit d'un logiciel dont nous avons accès au code et pouvons le modifier alors SAP est libre, oui nous pouvons améliorer SAP, nous avons créer un module et soumis à SAP. (un /h permet de voir ce qui ce passe dans le code!) un SE80 permet de le modifier via des User exit ou un copie en Z du programme standard! (je ne m'explique pas sur ces points car je pense que donnant votre opinion vous êtes connaisseurs de la solution donc vous connaissez déjà ces termes
SAP développe des connecteurs avec d'autre système! Possibilité de Webservice de façons simple. Facilité d'intégration d'un ETL ...
Je répété SAP est orienté SOA!
Arguments toujours pas convainquant (pour ma part).
Essayez encore
Consultant fonctionnel SAP CRM - SD/MM
Je tiens juste à préciser que je ne suis pas la pour vendre du SAP ni le promulguer.
Je suis plutôt là pour empêcher les gens de s'en faire une mauvaise idées sur des arguments plus que non fondés, par des personnes qui n'ont l'aire non utilisatrices/intégrateurs.
Descendre SAP je veux bien, mais encore faut-il avoir des Vrai bon arguments car je ne pense pas en effet qu'il soit adapté à toute les entreprise, loin, très loin de là.
Donner des vrai critères plutôt que des spéculations ferait avancer très grandement le débats. (pour ma part j'ai des arguments pour ne par intégrer SAP dans certaines boites, avant de vous les proposer j'aimerais juste voir les votre d'une manière presque qu' exhaustive).
Merci
Consultant fonctionnel SAP CRM - SD/MM
Je veux juste répondre là dessus.
Je plussoie Bill54, ce n'est pas uniquement applicable à SAP ou Dynamic. Tout dépend uniquement du paramétrage !
Je travaille sur X3 et s'il était mal paramétré, nous aurions exactement le même problème...
Licence commerciale ou open source, le problème reste le même
Bonjour (réponse à Bill54) ,
Soyons claire… Je ne cherche certainement pas à descendre SAP ou Dynamics, il se trouve simplement que dans ce dernier mois, j'ai été confronté à deux indiscutables "ERP Failure" et ce sont ces deux là.
Je suis complètement d'accord que le même problème peut se poser avec n'importe quel ERP (libre ou propriétaire).
La compétence de l'intégrateur est évidemment prépondérante… Je n'ai aucun doute sur le fait qu'il vaut mieux un "ERP moyen avec un bon intégrateur" (voir même dans certains cas "pas d'ERP du tout et de bons développeurs") plutôt qu'un "excellent ERP avec mauvais intégrateur".
Quoi qu'on en dise, vu le taux d'échecs des démarches ERP (dont SAP est l'incontestable leader, honneur au leader…), j'en conclu que les clients doivent sans cesse choisir de mauvais intégrateurs … ou alors c'est autre chose …et je réfléchis à cela.
Je pense que le problème fondamental que partage la majorité des ERP historiques est lié aux remarques dans ma "NOTE" (sur lesquels vous n'avez pas réagi, alors que c'était la principale partie "opinion perso" du poste, le reste n'étant que des faits relatés).
Je complète cette note avec un exemple : Je pense (et j'ajoute que j'observe que de plus en plus d'industriel prennent cette voie. Voir la monté en force du PLM pour s'en convaincre) que souvent lorsqu'on sort du standard, il vaut mieux une approche EAI "Best Of Breed", réunissant des softs "standards et peu coûteux/gratuits (éventuellement eux-mêmes des ERPs, mais utilisés uniquement là ou ils conviennent)" avec des "softs plus spécifiques et souples", par exemple (dans l'industrie manufacturière):
- du standard pour la compta, finance, RH (dans l'industrie manufacturière, ces activités ne sont généralement pas porteurs d'avantage concurrentiel important)
- du spécifique pour les process de fabrication, l'ingénierie concurrente, la gestion de l'innovation, la gestion de projets développement, la vision "cycle de vie produit", la gestion des risques industriels, … Remarque: Se baser sur un ERP pour le spécifique n'a souvent aucun intérêt (l'intégration avec la finance par exemple se faisant très bien via l'EAI) et implique par contre beaucoup de contraintes (propriétaire, licences, compétences chères, rigidités architecturales, technologies imposées, …)
En somme, et c'est sans doute cela le fond de ce débat, il ne faut pas penser que l'informatique d'entreprise se résume à la compta, les clients et la gestion des stocks (ce que font très bien une multitude d'outil "ERP", pas uniquement SAP), aujourd'hui elles veulent aller beaucoup plus loin, et pour certains cela passe par un fiasco avant de changer de voie (d'autres, plus clairvoyante et pragmatique choisissent directement la bonne voie, j'en observe aussi).
Lorsque je parle d'ERP, je parle au sens Informatique d'Entreprise, et non simplement de compta/stocks/clients/produits/... car c'est de cela que parle nos partenaires. Je devrais peut-être le spécifier plus tôt afin d'éviter les malentendus.
Chris
PS: Pour ce qui est de savoir si SAP sera mieux armé que l'était Dynamics, je ne doute pas que le clamp Dynamics (pas très représenté ici il semble) n'hésiterait pas à prendre position. De toute façon, l'histoire le dira.
...
Peut être qu'un vrai intégrateur fera fonctionner SAP. Et donc le taux d'échec sera moin important. Peut être qu'avec le taux de réussite votre taux d'échec sera plus que faible. (On parle toujours des trains en retard...)
Pour ce qui est du spécifique.
Pouvez vous me parler d'IS-U, IS-M, IS-Oil, SRM, CRM. Pouvez vous me parler de leurs limites (non connu à ce jour).
Ne pas limiter SAP à FI, CO serait pas un mal
Bonne soirée
Consultant fonctionnel SAP CRM - SD/MM
Bonjour,
Si en résumé vous êtes en train de dire que SAP fait et inclut tout ce qui est possible de faire de façon informatique dans une entreprise (que cela soit spécifique ou non n'a pas l'aire de compter d'après vous), il doit en effet y avoir des modules de SAP dont je n'ai pas connaissance…
Est-ce cela que vous dites ? Si oui, j'aimerai creuser plus... comme en plus dans de nombreux autres messages vous ne manquez pas de mettre en avant le coût modique de la solution SAP, je me dis que si pour quelques milliers d'Euros, tous les besoins sont remplis, je ne vois pas pourquoi regarder ailleurs... (et du coup je ne comprend pas pourquoi les projets SAP coûte si chère et requiert tellement de monde) …
... ou alors dites vous qu'il est possible de "créer" (j'évite "développer" car je sais que dans le monde SAP on n'aime pas ce mot, on préfère parler de simple "customisation/paramétrisation") dans SAP tous les modules qu'on peut souhaiter, dans quel cas je renvoie à mes précédents messages (sur l'EAI et le non intérêt de faire du développement spécifique dans SAP).
Je pense que SAP, comme d'autres ERPs, est un bon produit, lorsqu'il est utilisé avec justesse, là ou il est pertinent (autrement dit, là ou les besoins sont suffisamment standard (donc peu porteur d'avantage concurrentiel et peu stratégique au sens chaîne de valeur) pour être supporté de façon satisfaisante dans l'ERP/SAP). C'est lorsque on essaye de le sortir de son cadre que les problèmes et coûts explosent…
Bonne après midi et à plus tard
Chris
Vous résumez très mal
Je pense juste que SAP permet d'intégrer plus de processus que tout autre ERP, je me trompe peut être et surement mais là n'est pas le débat.
Je n'ai jamais dit que SAP sera à coup sur la bonne solution pour toutes entreprises!
Nous avons déjà refusé des projets pour ces raisons.
Nous utilisons très bien le termes développer pour SAP. La custo ou le paramétrage est tout autre.
En vous citant les autres modules de SAP (IS = Idustry Specific) je vous montrer qu'il ne faut pas se prononcer sur un sujet que l'on ne maitrise pas en l'occurrence ne pas dire que SAP se résume a R/3. Plus précisément : ne pas descendre une techno que l'ont ne connait pas sans Vrai arguments
Pourriez vous être exhaustif quand vous citez mes autres commentaires ???
Je parlais bien d'un cout moins élevé qu'auparavant, je ne suis jamais allé jusqu'à parlé de quelque milliers d'euros (j'aimerais que vous me citiez ce message!)
Ce que j'ai dis c'est qu' il existe des prépackgé qui permettent une intégration plus rapide et moins onéreuse. On me parlé de 1millions d'€, j'ai bien précisé qu'en 300 voir 400 j/h (200j/h pour CRM!!!) il était possible d'intégrer SAP.
Que SAP AG fait d'énorme effort pour permettre au PME d'intégrer SAP.
Je trouve cela un peu meskin de citer qu'un bout d'infos
Consultant fonctionnel SAP CRM - SD/MM
Aucun problème sur le coût... j'ai quelque peu ironisé avec les quelques milliers d'Euros, ce ne sont pas vos termes, mais les miensJe trouve cela un peu meskin de citer qu'un bout d'infos. Cela est rectifié ici, et j'ajoute que je suis évidemment conscient qu'un deploy SAP coûtera bien plus chère que cela. Cela dit, notez au passage que le deploy d'autre ERP, dans des situations SIMPLES (voir très simple), est tout à fait envisageable autour de 10/20K€ (sans compter frais "interne").
J'ai bien noté votre liste de solutions IS, dont j'ai (évidemment) connaissance. N'empêche, et ceci semble vous "échapper" depuis le début, Indutrie Spécifique ce n'est pas Entreprise Spécifique, et j'y vois une différence fondamentale (celle de l'obtention ou non d'avantage concurrentiel par rapport aux concurrents dans la même industrie, ce qui d'après M. PORTER par exemple est difficile si tout le monde fait pareil, mais ici on s'éloigne du "petits" monde ERP...).
Je me répète, car j'ai un peu l'impression que vous évitez soigneusement mon propos de fond (pour ramener le sujet systématiquement à une histoire d'expertise pointue sur SAP, comme si quelqu'un qui ne connaitrait pas chaque module et toutes ces transactions sur le bout des doigts serait incapable d'avoir un avis... dans ce cas, je plains ceux qui doivent choisir entre SAP, Dynamics, Oracle Apps, Compiere, ...) :
Il est clair que SAP s’intéresse au marché PME (celui grand compte devenant saturé entre SAP, MS, Oracle, … et aussi attaqué par d’autres types de démarche d’entreprise, plus récentes), mais force est de constater que celui-ci ne s’intéresse pas beaucoup à SAP (d'ou la monté en force d'autres solutions). On n’efface pas des décennies d'images, de techno, de stratégie et de savoir faire orienté grand groupe en quelque mois/années (et du «re-branding »).Je pense que SAP, comme d'autres ERPs, est un bon produit, lorsqu'il est utilisé avec justesse, là ou il est pertinent (autrement dit, là ou les besoins sont suffisamment standard (donc peu porteur d'avantage concurrentiel et peu stratégique au sens chaîne de valeur) pour être supporté de façon satisfaisante dans l'ERP/SAP). C'est lorsque on essaye de le sortir de son cadre que les problèmes et coûts explosent…
Cordialement,
Chris
Vous aviez résumé SAP à R/3 dans votre poste (pas terrible pour quelqu'un qui connais (évidemmentJ'ai bien noté votre liste de solutions IS, dont j'ai (évidemment) connaissance. N'empêche, et ceci semble vous "échapper" depuis le début
Je me répète, car j'ai un peu l'impression que vous évitez soigneusement mon propos de fond (pour ramener le sujet systématiquement à une histoire d'expertise pointue sur SAP, comme si quelqu'un qui ne connaitrait pas chaque module et toutes ces transactions sur le bout des doigts serait incapable d'avoir un avis... dans ce cas, je plains ceux qui doivent choisir entre SAP, Dynamics, Oracle Apps, Compiere, ...) :
Chris
Puis que vous les "maitrisé" (j'ironise aussi un peu
Qui l'améliore et le perfectionne à SA sauce. Avec un bon intégrateur les coûts ne seront pas astronomique comme auparavant!
Croire qu'une intégration d'un IS sera identique chez 2 clients différent me dépasse...
J'espère n'avoir rien évité cette fois-ci
Cdlt,
PS : je pense que nous sommes d'accord sur certains point, mais le fait de grossir certain arguments (plus d'actualité) c'est cela qui me gêne
Consultant fonctionnel SAP CRM - SD/MM
Bonjour,
Je pense en effet que nous sommes d'accord sur les grandes lignes, et je pense que notre point IS vs ES est intéressant, car pour moi c'est cela qui place les limites hors desquelles l'ERP bascule du coté "obscure". Tant qu'on accepte d'opérer (dans les grandes lignes, en prenant en compte les possibilités de paramétrage) comme le prévoit l'ERP (quelque soit le module, ERP, IS, ...), on peut rester dans l'ERP, si on sort de sa façon d'opérer, il vaut mieux aller vers du spécifique (qui sera intégré à l'ERP en EAI). Ceci est très important, car c'est relié directement à la stratégie d'entreprise et à l'avantage concurrentiel.
Voici une autre façon de voir les choses (voir mon PS aussi) :
Réfléchissons un instant à SAP NetWeaver :.... pourriez vous nous expliquer leurs limites et Surtout la liberté de pouvoir le mettre en accord avec les processus propre à chaque entreprise? ...
Si SAP NetWeaver existe, c'est pour répondre aux manques et "limites" des modules existants (qu'ils soient "SAP ERP", "IS" ou "xAPPs").
En effet, SAP n'aurait pas pondu une telle solution (Netweaver est plutôt riche et "complexe") si elle ne connaissait pas elle même les limites de ses propres "modules".
Par NetWeaver, SAP passe le message que SAP peut tout faire, car SAP est une plateforme de développement (J2EE/ABAP). C'est le contre argument de SAP face à l'Open Source (dont la monté en puissance doit (devrait) l'inquiéter et dont l'un des principaux arguments crédibles (car le TCO ne l'est pas toujours) est la possibilité de faire ce qu'on veut basé sur la dispnibilité des sources, ce qui, par ailleurs, est largement discutable).
Ceci est vrai et c'est exactement là ou je veux en venir :
La seule solution viable (le paramétrage/bricolage/customisation devenant trop coûteux et risqué) pour pouvoir réellement faire du Spécifique Entreprise (à opposer aux IS de SAP) est de faire du vrai développement spécifique. L'avantage concurrentiel de l'entreprise en dépend (sinon ce n'est pas la peine de faire les choses de façon spécifiques, sans même parler d'ERP).
SAP lui même le reconnaît via NetWeaver.
Seulement, SAP NetWeaver n'est pas le seul et encore moins le meilleur des choix comme plateforme de développement, et je pense que ceci est objectif.
D'autres, beaucoup moins coûteux ou gratuits (VS, .NET, JBOSS, ...) offre plus pour le développement spécifique, en étant bien plus accessibles (simplicité d'utilisation, compétences moins rares, communauté ouverte, ...).
Et l'EAI (via SOA par exemple) avec SAP est architecturalement une meilleure solution : plus modulaire, plus indépendant, les développements spécifiques peuvent être multi ERP, moins contraignant techniquement (choix des technos), ...
Chris
PS : Plutôt qu'une réponse basée sur des expériences personnelles (et particulières/confidentielles/contestables), j'ai préféré répondre avec des éléments accessibles et compréhensibles pour tous (je pense).
Apparement je ne suis ni intégrateur ni utilisateur, je vais donc juste faire une remarque hors technique:
- Apparement, la libération du Code source est effective chez SAP....A quand la licence GPL !!!
- SAP PME (SAPbuisiness ONE) si je ne me trompe pas, n'a pas été développé chez SAP sur les bases de l'ERP (grand comptes) SAP... la solution PME SAP est un ERP racheté et renommé SAP.
- Je pense que SAP est une super solution, très fonctionelle et avec une grosse notoriété. Mais, il existe de nombreux echec de projets, comme dans tout les porjets ERP.
- La technique n'est pas forcément le point central sur lequel l'utilisateur va faire son choix ou va être satisfait du produit. Je pense que les processus métiers et l'adaptabilité de l'outil ERP à ces processus compte tout autant.
- Libre et propriétaire ne sont pas incompatibles, loin de moi cette idée, ils doivent coexister
MD
www.heonium.com
Le code source SAP n'est pas libre, encore faut-il connaitre la philosophie de SAP... Tu peux lire le code standard mais pas le modifier( sauf par des endroit où SAP te laisse le modifier ce sont les USER EXIT, ou des Buisiness add-in "BADI"). De plus tu peux toujours créer tes propres report ou faire une copie du standard puis le modifier.
Je ne parlais pas de Sap Buisiness One. Mais bien de SAP ECC et CRM.
Merci quand même pour ton point de vue, pour la peine je laisse ta signature
Consultant fonctionnel SAP CRM - SD/MM
Bonjour,
Pour faire le choix d'un ERP tu dois évaluer plusieurs points.
1) Il va de soit, les besoins de ton entreprise.
2) Ton budget.
3) Le service après vente (support). Correction de bug oui, mais aussi support fonctionnel.
4) La force de ton équipe informatique, s’il y a une équipe.
5) Une solution qui peu évoluer avec l’évolution de ton entreprise.
Pour faire un petit résumer, j’ai plus de 10 ans d’expérience dans le développement, l’implantation, le support de système financier (Non ERP et ERP) et de paie/RH.
Je ne connais pas vraiment tiny ERP, et je travail avec Compiere depuis près de 4 ans à développer/implanter et suppoter un système de paie et ressources humaines intégré a Compiere
Les principaux problèmes des gros ERP sont les coûts d’implantation, les ressources humaines sont rare et onéreuse et l’énergie nécessaire à leurs implantations, il ne faut pas penser adapter le logiciel au processus de l’entreprise, mais bien l’inverse, adapter les processus de l’entreprise au logiciel si tu veux une chance de succès.
Et l’inverse, si tu vas vers OpenSource, le support « peu » être plus faible, ton équipe informatique avoir à travailler d’avantage. Les coûts d’achat et les frais de supports sont moindre, si tu décide d’avoir un contrat de support.
Tiny versu Compiere
Mon opinion, Compiere à un avantage, l’interface peut être web ou client, pour de la saisie massive de données, je continue de penser qu’une interface client est préférable à un interface web. Si ton entreprise saisie 10 factures / bon de commandes par jours l’interface n’est pas un problème, si c’est dans les 4000 à 5000 comme certain de mes clients, c’est différent.
L’outil de développement de Compiere, son dictionnaire de donnés est vraiment très bien fait. N’importe qui, même non informaticien, peu développer de nouveaux écrans, ou personnaliser des écrans existant en quelques minutes.
Les points faibles de Compiere, l’interface à quelques des limitations, au niveau fonctionnel, le logiciel est fortement influencé par le monde manufacturier, la notion de «produit » y est important, exemple la création de l’imputation comptable d’une commande ou d’une facture peut ne pas répondre au besoin de ton entreprise.
Si tu évalue Compiere, regarde aussi OpenBravo, surtout si tu as plus d’intérêt pour une version Web.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager