Blog éclectique & sans sujet précis - Mot-clé - ERP - Commentaires<p>Si ça me passe par la tête, si ça n’intéresse que moi, alors c’est peut-être ici. Ou pas.</p>2024-02-13T09:44:49+01:00L'éditeur est le propriétaire du domaineurn:md5:bf83720a7189bba489682d945b972671Dotclear“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:488dab253077b652dddf6b32854b90182021-06-25T17:06:01+02:002021-06-25T16:06:01+02:00Le webmestre<p>@Kazan : oui, je ne pense pas que le domaine se soit amélioré en 10 ans (je l'ai quitté depuis, DBA ça occupe assez et on ne s'embête plus avec des cliquodromes).</p>
<p>Déjà il y a 10 ans on voyait le NoSQL, la non-modélisation, le datalake (aka gros foutoir), la self-BI où l'utilisateur final se débrouille tout seul dans son coin pour contourner l'informatique trop lente à répondre, tout ça n'a rien arrangé.</p>
<p>Je pense surtout que les modélisateurs n'ont pas vraiment été formés. Il y en a qui confondent BI et simple copie de tables via un ETL, sur lequelles l'utilisateur final plaquera un Qlickview ou un Tableau ou le truc à la mode ce jour-là. Et comme il veut tout, tout de suite, on n'a jamais le temps de faire un truc carré.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Kazanurn:md5:e3debbed8f636f9f15da4145d86ff1222021-06-25T16:28:14+02:002021-06-25T15:53:08+02:00Kazan<p>Je découvre un confrère en SGBDR, dix ans après !<br />
J'ai lu ce bouquin de Kimball, il y a 3 ans entre deux missions, et il est très inspirant ! Si certains concepts sont discutables, c'est très clairement la praticité et le bon sens qui prennent le dessus.</p>
<p>Et c'est d'autant plus drôle que, lorsque je reprends des DWH (une demi-douzaine avant la lecture de ce bouquin, deux ou trois après) la plupart des modélisateurs font tout l'inverse ou ignorent (pas de tables de dimension temps, on mélange les relations N/M, on veut absolument tout historiser parce que "on sait pas ce que veut l'utilisateur, donc pour être sûr on lui fournit l'historique...")</p>Les joies de l’ERP et du CRM (I) - Le webmestreurn:md5:0c9ec21d4766e4a76b3f500bc30a329f2018-05-18T09:17:19+02:002018-05-18T08:17:19+02:00Le webmestre<p>@GRCedric : CDiscount et Leboncoin ont les contraintes des sites très lourdement sollicités, et ont le mérite de viser le simple et efficace pour Mme Michu.</p>
<p>Pour les ERP, il y a eu la contrainte des transitions plus ou moins forcées depuis le client lourd (je crois que SAP en a encore un, qui a le mérite de la réactivité) et de ne pas avoir à changer et revalider une montagne de code mille fois débugué et dont plus personne ne doit savoir comment il fonctionne vraiment. L'ergonomie ils s'en fichent : les personnes sont formées et finissent par prendre leurs habitudes.</p>Les joies de l’ERP et du CRM (I) - GRCedricurn:md5:03f7a4124fa6265be4f0b538d1d76e0e2018-05-18T07:26:56+02:002018-05-18T07:40:56+02:00GRCedric<p>J'aime bien ta 6ème note :) Je les déteste aussi visuellement mais c'est souvent ce qu'il y a de plus efficace !</p>
<p>On peut faire le parallèle avec l'UI de certains sites web. Pourquoi à votre avis des sites comme Leboncoin ou CDiscount gardent leur interface dégueulasse ! Parce que c'est super efficace et plus accessible qu'une interface 2.0 avec du JQuery qui rame.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:0eead601fceba919215a8055711600d92012-09-06T19:03:01+02:002012-09-06T18:03:01+02:00Le webmestre<p>@vpo : Pour un décisionnel c'est pire car c'est transverse, pas directement lié à un domaine, ça pose plein de questions, parfois gênantes, ça oblige les gens à réfléchir, ça n'a pas forcément d'utilité directe pour les personnes impliquées (leurs données serviront à d'autres, mais ils seront bien contents d'avoir accès aux données d'autres domaines), et ça finit souvent par prouver que tous les rapports existants autrefois, sur lesquels des carrières se sont bâties, calculaient n'importe comment.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - vpourn:md5:54f7d5f774564cdc542a5f719fc6a7082012-09-06T13:00:54+02:002012-09-06T12:00:54+02:00vpo<p>règle n°1 : se trouver un sponsor de poids capable d’imposer aux autres de bosser pour le projet datawarehouse que tout le monde attend sans vouloir lui consacrer une seconde</p>
<p>C'est le cas pour tout projet. Si le sponsor du projet n'a pas le pouvoir ET la volonté de soutenir le projet cela risque fatalement d'être un fiasco. C'est le grand classique du projet stratégique voulu par les chefs mais qui ne veulent pas mettre de sous dedans / de gens dessus car, "tu comprends, y a pas le temps / de ressource / etc".</p>
<p>Bah faut pas le faire alors ça économisera un poste de chef de projet pour un truc voué à l'échec.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:e7709f3e3afc1d8a1ebc370f4a30d2762012-09-05T21:10:59+02:002012-09-05T20:10:59+02:00Le webmestre<p>@Eric : Quand je dis que le bouquin n'est pas pour les débutants dans le métier, je sous-entends que c'est le cas aussi pour le billet. Ce qui fait une intersection vachement réduite avec mon lectorat habituel :-)</p>
<p>DW = datawarehouse (je viens de corriger). Le modèle en étoile c'est une table de faits avec que des indicateurs (~chiffres) et des clés étrangères vers des tables de dimensions. Floconner c'est ajouter des tables de deuxième niveau (FAIT-VENTES -> DIM-MAGASIN -> DIM-VILLE -> DIM-DEPT ->DIM-REGION : 3 niveaux de floconnage) alors que le mieux est quand même une étoile pure (FAIT-VENTES contient les clés vers toutes les autres ; oui c'est redondant mais dans ce genre de base on ne normalise pas, on pense aux perfs pures).</p>
<p>Le « grain » de la table de faits, c'est en gros sa clé primaire, un regroupement de certaine des clés étrangères (mois/magasin/produit par exemple). On essaie de faire des tables au grain le plus fin possible. Le choix de floconner ou pas dépend en partie des différents grains nécessaires.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Eric C.urn:md5:02505412861f00e600e2b84526563a8b2012-09-05T10:41:54+02:002012-09-05T09:41:54+02:00Eric C.<p>Ma curiosité polythématique superficielle chronique fait qu'il y a peu de domaines dont le vocabulaire m'est totalement étranger (ce qui ne veut pas dire que j'y comprends quelque chose), mais là, en lisant<br />
"Autre grand moment de modélisation : je floconne, ou je floconne pas <a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/11" title="11" rel="ugc nofollow">11</a> ? Kimball et son équipe sont des adversaires déclarés de la normalisation dans DW (l’étoile, rien que l’étoile, ça allège les jointures), et plus le temps passe, plus j’évolue comme ça aussi. Après, faut voir si les grains des tables collent."<br />
j'avoue que je n'ai pas pu m'empêcher de réprimer un sourire du genre "mais keskidi ?" :)</p>Par paquets de 5 - taryckurn:md5:d5730f0886462d54619b59264f31dbc82011-11-16T15:51:53+01:002011-11-16T15:51:53+01:00taryck<p>Le paramètre par défaut de 5 est dans le paramètre base de donnée : rsdb/max_in_blocking_factor & rsdb/max_blocking_factor<br />
modifiable via RZ11, voir note SAP 881083.<br />
On peut ainsi faire monter pour tout les FOR ALL ENTRIES la taille des paquets de 5 à xx. Chez nous 50.<br />
Pour certaines requettes (celle ou on a la clé primaire par exemple) on peux juger que 50 serait alors trop faible, mais que pour ces requêtes là. On utilise alors le %_HINTS ORACLE avec ;<br />
- '&max_blocking_factor 20&'<br />
- ou '&max_in_blocking_factor 20&'<br />
SAP ne peut être plus puissant que la base de donnée qu'il utilise pour des extractions seules.<br />
Donc dans ton cas :</p>
<pre> SELECT * FROM vbap
FOR ALL ENTRIES IN tab_articles
WHERE vbap~matnr = tab_articles-matnr
%_HINTS ORACLE '&max_in_blocking_factor 500&'</pre>
<p>devrait avoir l'efficacité souhaitée.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:e19b986daf1968df7964216cafd269402010-06-15T19:18:12+02:002010-06-15T18:18:12+02:00Le webmestre<p>@Arialia : Ah, SAP n'a pas le mérite de la souplesse, et surtout veut que tout passe par lui, et à sa sauce. Quant à s'intégrer à l'ergonomie du XXIè siècle… ils savent pas faire.</p>
<p>Au passage, il y a un inconvénient aux jolies interfaces fonctionnelles à façon : elles sont souvent spécifiques, donc soit à maintenir en interne, soit faites par un plus ou moins petit éditeur qui, lui, a forcément d'autres failles, le premier étant le manque de ressources disponibles sur le marché sur son produit (alors que du personnel SAP, chaque SSII en a).</p>
<p>Quant à Ciel ou autres, j'ai lu assez de messages d'horreur à leur sujet, mais je ne connais pas de première main. Ce n'est pas le même marché. Ce qui n'est pas une excuse pour SAP, l'ergonomie est universelle (ou devrait l'être). Mais l'investissement ne se justifie pas puisqu'on vend à des gens qui jugent les fonctionnalités, pas l'utilisation quotidienne (le contraire du particulier ou du petit entrepreneur).</p>
<p>Ah oui : se passer des programmeurs est possible même avec SAP. Mais il faut décider de se limiter à ce que sait faire le produit. Et il faut quand même le paramétrer. Éternel débat entre prêt-à-porter et sur mesure :-) (Réponse rapide : prendre du standard quand ce n'est pas le cœur de métier, faire du spécifique quand on a de bonnes compétences ou que c'est un point qui permettra de se différencier de la concurrence.)</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Arialiaurn:md5:c98c07772b94426fad881c11a71843802010-06-15T11:40:14+02:002010-06-15T10:40:13+02:00Arialia<p>Merci beaucoup pour cet article très intéressant.</p>
<p>Je comprends enfin ce qu'est SAP et plains tout ceux qui ont à migrer des 'ERP' maisons vers SAP, mon mari est dans ce cas et je comprends maintenant son désarroi et celui de ses collègues utilisateurs habitués depuis 2000 à de jolies interfaces fonctionnelles et réalisées en fonction de leurs besoins, tout ça parce qu'un commercial à réussi à vendre SAP à un haut dirigeant qui n'a même pas vu le produit ...</p>
<p>Il m'a parlé des limitations d'interrogation de Sap où tout doît être prévu à l'avance, quelle régression face à la solution SGBDR/application spécifique/Infocentre (Bi-Query ou Bussinessobject avant son rachat)</p>
<p>Si au moins SAP fournissait quelque chose clés en mains du genre les logiciels de Ciel qui aurait permis de se passer des programmeurs , mais c'est apparemment loin d'être le cas ...</p>
<p>Bref quel intérêt de prendre SAP?</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:74944b3819903b0de9d1b920a726cc202010-02-18T18:58:19+01:002010-02-18T18:58:19+01:00Le webmestre<p>@lookcheed : C'est une blague ? L'amoncellement de spécifiques est un défaut propre à l'organisation et non au logiciel. J'ai connu des clients qui avaient tellement patché SAP qu'ils étaient incapables de migrer aux nouvelles versions, il a déjà fallu remigrer à la version classique.<br />
Quand au spécifique buggé, c'est pire sous SAP à cause de ce langage de merde qu'est l'ABAP (y a plusieurs billets sur le sujet).</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - loockheedurn:md5:d2840a61690da860fd709129d480e9992010-02-17T11:59:30+01:002010-02-17T11:59:30+01:00loockheed<p>Oui SAP est destiné au business et pas au developpeur. Au moins avec SAP on se retrouve pas avec une montagne de dev specificique buggé et inexploitable.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:c25cc3108f62e016dbc5b9e9fee5d0a92009-12-02T16:02:41+01:002009-12-02T16:02:41+01:00Le webmestre<p>@jhon : Faut savoir lire : je m’étonne que le terme employé par SAP soit une translittération directe du « Abbrechen » allemand (« Interrompre »), traditionnel dans le Windows de là-bas, et non le terme « Annuler » familier aux utilisateurs francophones.</p>
<p>Windows oui c’est mal, mais pour d’autres raisons.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jhonurn:md5:267c1ee12856b04bbeef1db660f7cf1a2009-12-02T14:04:53+01:002009-12-02T14:04:53+01:00jhon<p>messieu si vous ditez que la reponse ANNULER pour sortir sans rien faire d’une boîte de dialogue cest mal ;;;alors windows cest mal aussi?</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jhonurn:md5:1a2b2901bbae74dc0c40fe0ab5ff59ea2009-12-02T14:04:51+01:002009-12-02T14:04:51+01:00jhon<p>messieu si vous ditez que la reponse ANNULER pour sortir sans rien faire d’une boîte de dialogue cest mal ;;;alors windows cest mal aussi?</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:0fa95cbe83cd207ca43785f18350e6452009-09-07T20:49:56+02:002009-09-07T19:49:56+02:00Le webmestre<p>@Jérôme F : Oui, l'informaticien de base ne peut dire au client ce qu'il veut. C'est pour cela que le métier de « fonctionnel », plus financier/logisticien/chef de produit qu'informaticien est là : il connaît tout le paramétrage possible (y a des cours pour ça) et comprend les besoins.</p>
<p>Un bon spécifique, oui, il communique par API et par les endroits prévus. Tout gros ERP a des endroits privilégiés pour cela, plus ou moins intrusifs.</p>Les joies de l’ERP et du CRM (II) - Jerome F.urn:md5:c6751b008a1f1c1f8d64c26ca16ecc182009-09-07T17:45:10+02:002009-09-07T16:45:10+02:00Jerome F.<p>"soumettre l'entreprise à la logique de l'ERP"<br />
Ca c'est une bien mauvaise idée : l'informaticien (et consultant) que je suis est incapable de dire au responsable logistique, production, commercial,... comment ils doivent travailler. C'est pas crédible. C'est le genre de situation que j'ai du mal à supporter.</p>
<p>"Je n'en ai vu aucune SANS spécifique."<br />
Mette du spécifique dans l'ERP c'est pas forcement la meilleure solution. Le spécifique interfacé avec l'ERP mais hors ERP, partageant dans l'idéal la base de données (en écrivant dans les tables de l'ERP via des APIs) c'est plus souple.</p>
<p>"automatiser les tâches répétitive, (rôle de l'informatique en général)" 100% d'accord avec vous.</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:d848a3cc262332b2c460eff521a0d2b12009-09-05T11:54:45+02:002009-09-05T10:54:45+02:00Le webmestre<p>@Jerome F : Quoi qu'en disent les commerciaux, un ERP ne sait pas tout faire, vu que chaque entreprise a ses habitudes, ses combines, sa tradition, et des clients qui ont aussi les leurs. Il y a aussi ce qui possible manuellement, et ce qu'on aimerait bien automatiser selon des règles maison.</p>
<p>Éternel dilemme : soumettre l'entreprise à la logique de l'ERP ou patcher l'ERP pour l'adapter à l'entreprise ? Parle-t-on paramétrage (SAP est le roi) ou programme spécifique ? Un spécifique doit être maintenu à chaque migration et est une nouvelle source de bugs. J'ai vu une société qui avait tellement amendé SAP qu'elle était devenue incapable de migrer à la version suivante. Je n'en ai vu aucune SANS spécifique.</p>
<p>À la base je dirais que les spécifiques doivent :<br />
- automatiser les tâches répétitives qui ne le sont pas déjà (rôle de l'informatique en général) ;<br />
- porter sur le cœur de métier, les spécificités de l'entreprise, ce qui fait sa valeur ajoutée : par exemple une entreprise de logistique mettra sa compta dans l'ERP, mais créera ses propres logiciels logistiques.</p>Les joies de l’ERP et du CRM (II) - Jerome F.urn:md5:ef0ab81e36a6210b987236f6787671832009-09-05T11:23:19+02:002009-09-05T10:23:19+02:00Jerome F.<p>Travaillant dans le domaine des ERPs des problèmes de ce genre j'en vois souvent. Les clients ont des processus très complexes et espèrent sérieusement les gérer avec un logiciel standard.<br />
Souvent la solution de loin la moins chère à ce type de besoin c'est le développement spécifique d'un programme hors de l'ERP. Mais cela casse le principal argument de vente de ces usines à gaz : elles sont sensées tout faire.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:ffacb5042683ff8c4abacbf2682a359a2009-06-13T20:26:43+02:002009-06-13T19:26:43+02:00Le webmestre<p>@renommeur : Condoléances. Perdre 2 ans de vie à ce genre de choses, j’aurais pas supporté. J’espère que ton système est réutilisé ailleurs...</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - renommeururn:md5:7f9e6c66804bbe6ee2a1f5cd2bb0e6752009-06-13T11:00:59+02:002009-06-13T10:00:59+02:00renommeur<p>J'ai passé mes deux dernières années de ma vie à renommer environ 16000 comptes utilisateurs SAP sur 70 systèmes et 220 mandants. Car le nom d'utilisateur est en même temps sa clé. Il y a environ une quarantaine d'objets liées à cette clé, dont un bon nombre en 1:1 (et non pas 1:n ce qui rendrait la tâche plus simple). J'ai donc développé une solution en ABAP qui gère le processus de renommer un utilisateur, y compris la génération et l'envoi d'email de son nouveau compte et mot de passe avec un message en la langue de l'utilisateur.... je migre les favoris, variantes ALV, variantes programmes, parametrage du workbench, L'infotype 0105/0001, le business partner (à travers la central person), planstellen, autorisations etc. etc. Donc j'ai du boulot grâce à SAP! Mais je suis d'accord que tout cela aurait était trivial si SAP avait un identificateur technique distincte du nom d'utilisateur... si vous voulez renommer vos utilisateurs et en passant faire de l'ordre dans ces comptes - contactez moi...</p>Par paquets de 5 - Le webmestreurn:md5:04cbb750a85d5b27017b33e5888837fd2009-03-12T21:46:03+01:002009-03-12T21:46:03+01:00Le webmestre<p>@taryck : Oui, en gros c’est le problème : le SQL généré par l’ABAP est « basique » et ne tient pas compte de la puissance de la base sous-jacente et la sous-utilise…</p>Par paquets de 5 - taryckurn:md5:e94646a39c8623655cbb41cb66a15c592009-03-12T18:04:26+01:002009-03-12T18:04:26+01:00taryck<p>Je pense que le point qui a été “zappé” est simplement que le code SQL en ABAP est de l’OPEN SQL transcrit en SQL-Natif Oracle, mais pas seulement. Il est donc possible que certaines limites présentes sur les autres BdD supportées par SAP amène à cette limite constatée de 5 clés.<br />
Même si je n’ai aucune idée de la raison…</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:ad834af6e825cd862c18101f8d24ae132009-01-27T15:12:51+01:002009-01-27T15:12:51+01:00Le webmestre<p>@FrédéricLN : Focalisé sur les données ? On va souvent être d’accord alors, j’ai une vision des choses très orientée « SQL über alles ». Voir notamment le tag « SQL » à gauche.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - FrédéricLNurn:md5:5466f39f836d8bcd4e162d9dca0ff2532009-01-25T19:10:48+01:002009-01-25T19:10:48+01:00FrédéricLN<p>Bonsoir et… merci. Formé aux SGBD il y a plus d’une décennie, j’avais entrepris de me remettre à jour avec des bouquins, mais on en apprend bien plus et bien plus vite sur ce blog ;-)</p>
<p>(PS - je sais bien que pour former un développeur, ce blog ne suffirait pas tout à fait, mais mon ambition est plus modeste, niveau utilisateur éclairé, focalisé sur les données elles-mêmes).</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - akounturn:md5:ee947a5e5e7a85e0640bdd7abba0689a2009-01-18T20:48:46+01:002009-01-19T20:24:29+01:00akount<p>vos conseils sont benefiques et interessants merci</p>Prise de tête en ABAP - Eoganurn:md5:c58cd6a271b857f81ea1816871080be32008-07-30T15:43:26+00:002008-07-30T15:43:26+00:00Eogan<p>Et voilà, j'ai refais la première solution et ça marche.<br />
<br />
<br />
L'ABAP est plein de mystère ...</p>Prise de tête en ABAP - Eoganurn:md5:6c1eb37b381fcc61b253cc4c61bcaee42008-07-30T15:39:00+00:002008-07-30T15:39:00+00:00Eogan<p>450€ par jour, je précise :D</p>Prise de tête en ABAP - Eoganurn:md5:8c1dea76d8251c77484b07e7c1d654532008-07-30T15:38:35+00:002008-07-30T15:38:35+00:00Eogan<p>Je ne peux que confirmer ce qui a été dit précédemment (je suis aussi stagiaire dans une SSII et je fais du développement ABAP).<br />
<br />
Un exemple sur lequel je me bats depuis tout à l'heure :<br />
<br />
IF VTTK-DTDIS IS NOT INITIAL OR VTTK-DPREG IS NOT INITIAL OR VTTK-DPLBG IS NOT INITIAL.<br />
PERFORM MAJ_FLAG.<br />
ENDIF.<br />
<br />
Cette condition paraitrait logique. Seulement, non, le OR enchainé ainsi marche avec des expressions algébriques, pas avec le "IS NOT INITIAL" (qui équivaut à dire différent de null)<br />
<br />
J'ai ensuite essayé (à l'aide du message d'erreur de compilation et en réflechissant pendant 3 bonnes minutes):<br />
<br />
IF VTTK-DTDIS OR<br />
VTTK-DPREG OR<br />
VTTK-DPLBG IS NOT INITIAL.<br />
PERFORM MAJ_FLAG.<br />
ENDIF.<br />
<br />
Ca ne marche toujours pas. Je me dis qu'il faut utiliser des parenthèses:<br />
<br />
IF (VTTK-DTDIS OR<br />
VTTK-DPREG OR<br />
VTTK-DPLBG) IS NOT INITIAL.<br />
PERFORM MAJ_FLAG.<br />
ENDIF.<br />
<br />
Mais non. Cruelle erreur, il faut des espaces.<br />
<br />
IF ( VTTK-DTDIS OR<br />
VTTK-DPREG OR<br />
VTTK-DPLBG ) IS NOT INITIAL.<br />
PERFORM MAJ_FLAG.<br />
ENDIF.<br />
<br />
Là en fait, ça marche toujours pas. J'ai toujours pas trouvé la solution. (Erreur de compil : Relational Operator OR is not supported (au moins, les erreurs de compil sont en anglais ... mais bon, celles d'éxecution sont en allemand))<br />
<br />
Quand, on ajoute à ça que le programme met 45 secondes à afficher un message pour confirmer la demande de compilation puis qu'on en a après pour une bonne minute. Croyez moi, on s'arrache les cheveux.<br />
<br />
On notera au passage le nom des variables qui sont super explicites.<br />
<br />
<br />
<br />
Par contre, ceux qui réussisse à passer outre cet environnement anti-convivial et ergonomique et cet enfer du développeur réussisse à bien gagner leur vie, c'est sur (un indépendant a refusé une mission de 6 mois à 450€ devant moi. Sachant que je gagne 600€/mois. Ca frustre).</p>Prise de tête en ABAP - Nicourn:md5:6d909feb2a0680ca98fe71fcb9df41cf2008-07-01T18:17:51+00:002008-07-01T18:17:51+00:00Nico<p>Ah la laa... Arrivé en fin d'école d'ingénieur, j'ai tenté un stage en SAP car je ne connaissais pas du tout. Je suis arrivé plein d'espoir avec mon bagage informatique prêt à accueillir un nouveau langage, tout heureux et naîf, quittant son eclipse et son visual studio pour arriver dans les locaux d'une SSII ou on m'a dit : 'Tu vas voir, SAP, c'est enorme'. Et puis, je me suis retrouvé en face de mon écran, et là tout à coup, l'énorme décéption... J'ai jms vu un langage aussi moche, aussi pourri, aussi mal traduit, aussi syntaxiquement maladroit. J'ai eu envie de vomir la première fois que j'ai vu qu'il fallait mettre un point à la fin de toutes les instructions, que les variables ne pouvaient pas faire plus de 15 cars, qu'il n'y avait pas de casse, que les programmes standards étaient en allemands.... AAAAAH..... il me reste plus que 2 mois mais je suis trop pressé de partir... Je ne supporte pas du tout... Certes, l'ABAP remplit bien ses fonctions quand on voit le monstre qu'est SAP... Mais franchement, ils ont fait des efforts pour rendre le système hyper moche et non-convivial pour tous, développeurs comme utilisateurs... Les seuls qui y trouvent leurs comptes sont les non-informaticiens qui se plaisent à gagner un bon salaire pour paramétrer un système hyper lourd... </p>Le rôle des NULL en ABAP et PL/SQL - Le webmestreurn:md5:157ef2610c19ccde0a06fa12c7c218192008-06-15T11:49:12+00:002008-06-15T11:49:12+00:00Le webmestre<p><b>@ninurs</b> : NVL(toto, "x") renvoie toto si toto n’est pas NULL, et la valeur par défaut "x" si toto est NULL (sus réserve que les types collent bien sûr).</p>Le rôle des NULL en ABAP et PL/SQL - ninursurn:md5:c250dfa0351c725b90b2c68cc82bffa22008-06-13T11:33:22+00:002008-06-13T11:33:22+00:00ninurs<p>La comparaison des champ NULL ou possèdant une valeur est très bien expliqué! Par contre, tu n'explique pas la commande NVL ? Je suis peu être un peu trop novice... !</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - sara saraurn:md5:b2410a7d1a4ee6f24ff53ab9d25754902008-06-07T14:30:51+00:002008-06-07T14:30:51+00:00sara sara<p>bonjour tt le monde<br />
<br />
En fait, je suis actuellement en phase de fair une etude de la mise en place de SAP dabs une soété industielle.et je voudrais bien que qlq'un maide à trouver une documentation sur les differents types de SAP.Mon mail est le suivant : <a href="mailto:suplaylogistic@gmail.com" rel="ugc nofollow">suplaylogistic@gmail.com</a> <br />
<br />
Merci d'avance<br />
</p>Service après-vente - Momourn:md5:3adb1814a623cffea4b0a28a613b38502008-06-02T14:42:45+00:002008-06-02T14:42:45+00:00Momo<p>Purée qu'est-ce que Vista a réussi à se faire désirer ! J'ai acheté mon PC peu après sa sortie, en me débrouillant pour avoir xp (mais en me disant "c'est beau vista")... 3 mois après j'installais Ubuntu, 1 mois après je tombe sur la démo de Beryl. j'ai évité une belle bétise ^^</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - ilouisurn:md5:075050e2bb55fb9d3cc5ae42f71724e42008-06-02T12:17:55+00:002008-06-02T12:17:55+00:00ilouis<p>je suis administrateur des bdd oracle, j aimerai juste ajouter le point suivant:<br />
vous parlez plus sur les interfaces et design mais je croix que le plus important c la cohérence des données, la sécurité des données, la lecture et la fiabilité de votre information (rapports, recherches, statistiques, etc.) <br />
Des procédures exemplaires, bien planifiées, bien conçues et bien communiquées favorisent l'intégrité de l'information.<br />
eeeeeeeet je pense que oracle reste le meilleur de tout ça .<br />
<br />
merci</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:76360a0f97a897c380b510393fe603742008-01-29T22:42:09+00:002008-01-29T22:57:47+00:00Le webmestre<p><b>@Petergun_1</b> :À propos de l’interface : Dieu merci, elle n’est PAS ludique ! Mais elle est moche, sous SAP ou Oracle Appli. Et pas du tout ergonomique par pas mal d’aspects. Après, on peut pinailler sur tel ou tel point mais il est indéniable que ce n’est pas le souci majeur des éditeurs. Il y a des progrès avec le temps, et éventuellement des régressions. Et je suis d’accord pour le processus qui est ce qu’il est, mais la limite n’est même pas là, rien de ce que j’ai évoqué ci-dessus n’aa à voir avec des limitations fonctionnelles !</p>
<p>Pour les produits cartésiens sous BO, c’est un problème complètement différent (et BO ne se sent vraiment bien qu’avec un <i>datawarehouse</i> alimenté par derrière dont le schéma de données est incompatible avec celui d’un ERP optimisé pour du transactionnel. Je sais, ce n’est qu’un exemple, mais il est mauvais. Sur le principe je n’ai rien contre les ERP, au contraire, c’est l’implémentation qui pêche (surtout du point du développeur et surtout sur SAP...)
<p>À propos des petits éditeurs : il est vrai qu’un petit éditeur, aussi talentueux soit-il, aura du mal à répondre au cahier des charges s’il faut supporter 20000 points de vente dans 200 pays et 50 langues...La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Petergun_1urn:md5:f4aec2ecd958cc7ccf24605db47747a62008-01-28T17:19:29+00:002008-01-28T17:19:29+00:00Petergun_1<p>Oups j'ai omis de laisser mon mail pour signer mon précédent roman qui à mon regret, dsl, comporte bcp de fautes... ah qd la passion aveugle ;)<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Petergun_1urn:md5:597db747fca5971493946d301b7d598f2008-01-28T17:06:22+00:002008-01-28T17:06:22+00:00Petergun_1<p>Bonjour,<br />
<br />
Pour ma part, je suis consultant SI Oracle Financials et j'ai travaillé par ailleurs sur SAP auparavant lorsque j'étais contrleur financier.<br />
<br />
Je vous rejoints sur certains points et évidemment m'éloignerai sur certains et tant qu'à faire, je m'éloignerai en évoquant d'autre -/+...<br />
<br />
1/ Je vous rejoints sur......... mais.........!<br />
<br />
- L'interface, de manière générale et quelque soit les produits R/3 ou EBS, ou encore JD Edwards, cela ne brille pas une interface magnifique truffée d'animation flash, de photos de vacance et j'en passe et des meilleurs décoration. Mais je reconnais que travailler avec une interface visuelle agréable, ergonomique, ludique devrait être davantage pris en compte par les développeurs/éditeurs.<br />
- Les restrictions, là je vous rejoint sans vous rejoindre: oui il y a de nombreuses restrictions, mais celle-ci sont le reflets du paramétrage soit imposé par la "business line" client (exemple: un workflow d'approbation multi-niveaux à développer, des process internes figés nécessitant d'adapter l'outil au besoin et non l'inverse à savoir l'organisation à l'outil). Je suis le premier à dire que l'outils est imparfait et que mettre en place un ERP implique souvent plus qu'un équilibre entre adaptation au nouvel outils et adaptabilité de l'outil avec le Business. Dans bien des cas (la majorité) on espère que le client va s'adapter à l'outils et refondre nombre de ses processus. La réalité saute vite au yeux: les raisons sont nombreuses / politique / entreprise client vieillissante (je ne prétendrai aps qu'il faille mettre à la porte les récalcitrants pollué par leur système qu'ils ont utilisé durant 30 ou 40 ans... mais un minimum d'ouverture et de flexibilité est une condition de la réussite de l'implémentation...<br />
<br />
Bref pour réusmé ces 2 idées : l'interface n'est pas le fort de ces outils ce qui n'empêche pas une certaine flexibilité pour s'adapter au besoins. Flexibilité ne rimant pas avec 0 limite, ces limites sont souvent issues de la rigidité des process client avant tout. Maintenant la rigidité de base du système est aussi une volonté de cadrer l'utilisation. Un projet ERP réussit est un projet ERP pour lequel le client aura compris que même si quelques besoins spécifiques peuvent être satisfaits, il devra s'adapter à un outils fourni de bases avec des fonctions standards répondant à 80-90% de ses besoins. Les 10-20% étant la part de contingence dédié au développement support...<br />
<br />
La réalité saute vite aux yeux... la tendance 80/20 est plus du 65/35...mais bon...<br />
<br />
Maintenant je m'éloigne et ne suis plus trop d'accord / lol<br />
<br />
- un ERP est comme une toile d'arraignée : un noyau central autour duquel gravites des modules complémentaires ou non, reliés directement ou indirectement. L'objet est de créer un réseau multi métiers sur une seule toile avec comme finalité de pouvoir croiser les données et éviter ce que vous voyez tout le temps en travaillant avec Business Object lorsqu'un univers est mal paramétré: Erreur/ Calcul cartésien!!!!!!!! insupportable je peux vous l'assurer...<br />
Tout cela pour dire cet outils sur lequel nous passons des savons sur ce débat à une vertue: la rationalisation des process et cela on ne peut lui enlever.<br />
<br />
- Maintenant oui la concurrence est limitée : 2 éditeurs et cela est regrettable même si avant il y en avait potentiellement d'autres (SAS, etc...) le choix est encore une fois : politique mais aussi stratégique. Faire appel à un petit éditeur lorsque vous vous appeler Total et que vous devez déployer X licences est une impossible pour toutes les raisons que la logique emporte. <br />
<br />
Bon c'est sur, un bon ERP ne vendra pas sans approbation multi niveau pour 4,7 milliard d'€uros les positions de la Société Générale ;)<br />
<br />
Bien à vous pour d'autre aventure ERP iterrative ;)</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jeromeurn:md5:a5f4a435f186ba64cc57663b588950012008-01-13T10:15:10+00:002008-01-13T10:15:10+00:00jerome<p>Bonjour,<br />
<br />
je suis comme toi Hora, je redige une thèse aussi sur les ERP peux tu prendre contact avec moi j'aimerais discuter avec toi des ERP et te poser quelques questions.<br />
<br />
Cordialement jerome</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - horaurn:md5:42ae577b7d57170b59f0161e7e99d2dc2007-12-19T14:19:13+00:002007-12-19T14:19:13+00:00hora<p>Bonjour,<br />
Je trouve votre article très intéressant, d'autant puisque je rédige actuellement une thèse sur les ERP et leur impact au plan organisationnel.<br />
J'ai cherché vos cordonnées sur le blog mais pas trouvé.<br />
Est-il possible de vous rencontrer pour un entretien ayant pour but d'approfondir le sujet, notamment par rapport à la philosophie (différente) de ces ERP, au plan méthodologique, des processus métiers, etc...<br />
Vous remerciant d'avance,<br />
Cordialement</p>Prise de tête en ABAP - Le webmestreurn:md5:6044450b72d481d1becc7d092454558a2007-12-15T10:46:54+00:002007-12-15T10:46:54+00:00Le webmestre<p><b>@BERNARD</b> : « il vaut mieux chercher du boulot que de continuer à faire de l’Abap » : et bien justement, l’Abap a justement une sacrée tendance à être délocalisé en Inde, il vaut mieux essayer de se trouver une autre branche...</p>Prise de tête en ABAP - BERNARD"'urn:md5:648a84e379fcc176125a2b9dfcd77f472007-12-14T17:55:35+00:002007-12-14T17:55:35+00:00BERNARD"'<p>Ben celui qui n'aime pas l'Abap n'a qu'a continué avec les langages exotiques ou soit disant plus puissant je supposes que le C C++ j'en passe et des meilleurs vous satisfont surement plus sauf que là comme vous dites on s'adresse à un ERP qui est capable de faire plus qu'un simple calcul donc il vaut meiux chercher du boulot que de continuer à faire de l'Abap<br />
A+</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Gurn:md5:be9df4dd0c1a048c901b12af2c9e7ec52007-12-09T12:07:29+00:002007-12-09T12:07:29+00:00G<p>Bonjour,<br />
Je n'ai pas d'expérience dans les ERP mais j'ai trouvé cette petite video qui reprend vos idées sur Oracle et SAP.<br />
Cette pub a été faites par Lawson, un autre editeur de solution ERP :<br />
<a href="http://www.dailymotion.com/relevance/search/lawson/video/x32dmt_pub-lawson-chat_ads" title="http://www.dailymotion.com/relevance/search/lawson/video/x32dmt_pub-lawson-chat_ads" rel="nofollow" rel="ugc nofollow">www.dailymotion.com/relev...</a><br />
En tout cas, merci pour votre retour d'expérience :)<br />
G</p>Les joies de l’ERP et du CRM (II) - anteaneurn:md5:c4ff88c8521bc1974d27a04329cb7a122007-12-06T19:22:30+00:002007-12-06T19:22:30+00:00anteane<p>Je reviens sur ce post ou j'avais ecrit ce petit billet pour vous dire que nous avons mis en ligne un article traitant de la rédaction d'un cahier des charges gpao avec un exemple complet de cahier des charges à télécharger :<br />
<br />
<a href="http://www.anteane.fr/index.php/GPAO-et-pmi-soft/Rediger-un-cahier-des-charges-pour-un-logiciel-de-gpao.html" title="http://www.anteane.fr/index.php/GPAO-et-pmi-soft/Rediger-un-cahier-des-charges-pour-un-logiciel-de-gpao.html" rel="nofollow" rel="ugc nofollow">www.anteane.fr/index.php/...</a></p>Le rôle des NULL en ABAP et PL/SQL - Antoineurn:md5:e138f104474c9ffa6dee856c34c353852007-11-20T14:17:54+00:002007-11-20T14:17:54+00:00Antoine<p>Plus familier de PostgreSQL, le mieux au final est de penser le NULL comme "indéterminé", au sens de l'indétermination mathématique. <br />
On est alors beaucoup moins surpris du résultat du "WHERE champ <> 4". On ne renvoie pas les lignes où champ IS NULL, car on ne sait pas dans ce cas (indéterminé) si champ est vraiment différent de 4.<br />
En tout cas, une fois expliqué comme ça, les développeurs de l'équipe on arrêté de ronchonner et ont commencé à utiliser COALESCE(...,...).</p>La Guerre des ERP : SAP vs Oracle Applications (4) : Philosophie opposées - Le webmestreurn:md5:dd021c3ac1cfef245124559ffb244bfc2007-10-05T20:17:20+00:002007-10-05T20:17:20+00:00Le webmestre<p><b>@Vincent</b> : Oui, tu as raison ! J‘ai confondu parce que MySQL a bien participé au développement, mais Adabas/MaxDB est bien plus ancien. Je corrige. Merci !</p>La Guerre des ERP : SAP vs Oracle Applications (4) : Philosophie opposées - Vincenturn:md5:3672d4b8474854f1add0b1c23e0bc84e2007-10-05T11:09:08+00:002007-10-05T11:09:08+00:00Vincent<p>Attention, mySQL et MaxDB sont bien deux bases de données distinctes. La seconde, initialement connue sous le nom de SAPDB, est distribuée sous forme de partenariat entre SAP et mySQL. Il semblerait d'ailleurs aux dernières nouvelles (sept 07) que SAP ait repris la main sur MaxDB, indépendamment de mySQL.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - LDEurn:md5:34335855d5320d93aa667fd512b25cef2007-10-02T18:06:05+00:002007-10-02T18:06:05+00:00LDE<p>Bonjour <br />
Soit SAP n'est pas une modèle d'ergonomie mais l'outil évolue (en 1998 on était en version 3.1 qui je vous l'assure ne ressemble pas du tout aux copies d'écrans des version 4.6 et suivantes)<br />
<br />
De plus SAP "embarque" en lui un outil de modificétaion d'écran plutôt bien fait : le GUIXT avce lequel vous pouvez redisgner vos écrans (transformer des listes en boutons radio, créer de nouveaux boutons pour des chainements d'écrans...)<br />
<br />
J'essayerai de faire à l'occasion un post sur ce sujet <br />
<br />
A bientôt<br />
<br />
</p>Par paquets de 5 - Le webmestreurn:md5:a72d893d426c79f15a6ed7642adac2722007-09-14T07:39:34+00:002007-09-14T07:39:34+00:00Le webmestre<p>@ECIR : Le SELECT...ENDSELECT, c'est ce que j'utilisais justement... Quant aux jointures, évidemment, comme en SQL il vaut mieux tenter de tout faire en une seule requête. Par contre c'est loin d'être toujours possible, et l'ABAP n'a pas la souplesse du SQL quand il s'agit de faire des « requêtes de feu » (écrire à la main des requêtes SQL de 2 pages avec 5 niveaux de sous-select ne me fait pas peur, donc je suis assez exigeant sur le sujet, mais quand même).</p>Par paquets de 5 - ECIRurn:md5:7ee7bdd172496ab4a1f2db1145a3ce6f2007-09-13T22:03:40+00:002007-09-13T22:03:40+00:00ECIR<p>Bonsoir,<br />
<br />
remarque pertinent du webmestre: le FOR ALL ENTRIES découpe les requêtes par plage de 5 valeur contenues dans la table interne. si la table interne contient 2000 enregistrements, il y a aura donc 400 requêtes SQL exécutées.<br />
<br />
Il y a plusieurs solutions possibles:<br />
- utiliser le select ... endselect, tel que c'est recommandé dans la transaction SE30<br />
- utiliser les possibilités de jointures, de sous-requêtes<br />
<br />
(:))</p>Par paquets de 5 - Le webmestreurn:md5:ec2b362544799e13bd2dd6b69334c9852007-07-22T19:42:49+00:002007-07-22T19:43:18+00:00Le webmestre<p><b>@bob</b> : Et non, il fait 5 fois moins d'accès en base que de WRITE (de lignes ramenées), mais c'est encore beaucoup trop, et c'est bien ce que je lui reproche. <br>Au lieu d’une requête dont chaque ligne est utilisée (bête curseur), il crée une requête <i>différente</i> pour cinq lignes de paramètres !<br>Qu’une table interne permette de contourner/éviter le problème, pourquoi pas (et ce serait après tout la moindre des choses), mais ce n’est pas forcément possible ou souhaitable, et de mon point de vue cela en rajoute encore dans la lourdeur de programmation (alors que le SELECT...ENDSELECT a le bon goût d’exister).Par paquets de 5 - boburn:md5:ae3254c341b086b01de66f2b72638c732007-07-19T15:17:13+00:002007-07-19T15:17:13+00:00bob<p>le prob, c'est que tu fais autant d'accès en base que de write ...<br />
<br />
essaye plutôt ça avant de critiquer un langage que tu ne connais pas !<br />
DATA : matable TYPE TABLE OF vbap WITH HEADER LINE.<br />
<br />
SELECT * FROM vbap<br />
INTO TABLE matable<br />
FOR ALL ENTRIES IN tab_articles<br />
WHERE vbap~matnr = tab_articles-matnr.<br />
<br />
LOOP AT matable.<br />
WRITE :/ matable-matnr, matable-vbeln, matable-posnr .<br />
ENDLOOP.</p>Le rôle des NULL en ABAP et PL/SQL - Le webmestreurn:md5:203d8dc92a7e5cbce591e8767e5804202007-07-05T19:59:36+00:002007-07-05T19:59:36+00:00Le webmestre<p><b>@Mardouks</b> : Une table interne pour toi tout seul, c'est effectivement trop lourd. Il y a par exemple une limite probablement paramétrable de 1 Go ou plus pour chaque processus. Par contre, sous Oracle Appli, vu que tu tapes directement dans les tables et que c'est Oracle qui s'occupe de la cohérence et de la gestion de la mémoire, tu peux faire joujou avec ta méga-table bien plus facilement (en général, et faut aussi faire gaffe aux perfs évidemment).
</p>Le rôle des NULL en ABAP et PL/SQL - Mardouksurn:md5:63d691cd245df574f8a1e328388c0a872007-07-05T15:09:08+00:002007-07-05T15:09:08+00:00Mardouks<p>On se fait toujours avoir la première fois, mon meilleur cas je crois était sur VBFA... une table interne de 80 millions de lignes c'est mon rêve, mais y me faut un SAP pour moi tout seul...</p>Prise de tête en ABAP - Mardouksurn:md5:f76722f76c9b33de8e9e07bffc6c80d82007-07-05T14:59:26+00:002007-07-05T14:59:26+00:00Mardouks<p>Bonjour,<br />
<br />
Il est vrai que ce language impose ses règles synthaxiques un peu particulières. Je travaille sur SAP depuis bientôt deux ans et j'ai débarqué avec mon php en tête. <br />
<br />
Il ne faut pas oublié le contexte:<br />
<br />
- Effectivement le language est aussi vieux que SAP (30ans et des poussières )<br />
- Il est très difficile de faire évolué un language sur sa synthaxe tout en gardant une rétro-compatibilité. On change pas de version de SAP comme de version PHP. SAP tente de passer à l'objet par exemple mais très difficilement vu son large domaine d'application.<br />
- Je trouve que l'ABAP est très orienté traitement de données en masse et sa 'simplicité' synthaxique aide beaucoup pour ce type de travail.<br />
<br />
<br />
<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - urainienurn:md5:c872227ca4228d131518394969bf9d2f2007-06-25T11:09:08+00:002007-06-25T11:09:08+00:00urainien<p>Bonjour,<br />
<br />
Pour cléopatre et les autres, allez sur www.fnac.com, mon livre est en prévente. Méthode de formation sur l'ABAP, en français. Méthode éprouvée depuis 3 ans, et avec les remerciements d'une grande SSII.<br />
Le titre est SAP et ABAP, aux éditions ENI. Un accès est sur mon site.<br />
Pour ceux qui le souhaitent, j'ai mis en place des forums sur l'ABAP, une base de connaissance sur l'ABAP, le tout en accès libre.<br />
<br />
Cordialement,<br />
<br />
Yann SZWEC<br />
<br />
PS : mon objectif n'est pas de convertir le webmestre à l'ABAP (:))</p>Les joies de l’ERP et du CRM (II) - Nicolas MARTINurn:md5:f03486c05d1dbb379363af91fe63ae4f2007-05-10T14:24:36+00:002007-05-10T14:24:36+00:00Nicolas MARTIN<p>il semblerait que <a href="http://www.anteane.fr/dotclear/index.php?q=erp+gpao" title="http://www.anteane.fr/dotclear/index.php?q=erp+gpao" rel="nofollow" rel="ugc nofollow">www.anteane.fr/dotclear/i...</a> fonctionne...</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Heptaeonurn:md5:27a0cb41bb5b8bd3d2fc47ef21ce980a2007-05-08T21:52:02+00:002007-05-08T21:52:02+00:00Heptaeon<p>Je suis a 100% de ton avis. SAP a la même politique que IBM avec ses mainframes. On sais comment ça a terminé. <br />
<br />
De mon coté je cherche l'ERP qui remuera les hautes sphères. Un ERP saint et clair (de conception), Ergonomique et Accessible, avec des technologie d'avenir, qui ne font pas de protectionisme sur l'information, et qui ont une politique commercial du win/win plutôt que de la sangsue. <br />
<br />
ps: Pour ceux qui diront que SAP ne disparaitra jamais, je leur dirais que certaine société sont toujours sur mainframe. </p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:d852f896d25bad19671cf53689d5bfb62007-04-19T18:58:34+00:002007-04-19T19:05:25+00:00Le webmestre<p><b>@montana</b> : C’est une bonne remarque, mais je ne l’ai jamais vue, cette version. Je peux juste répéter l’avis d’un collègue qui a développé dessus : c’est totalement inflexible, pas customisable, inadapté pour une SSII qui aime facturer du conseil (et tant mieux pour le client :-). Et un commercial m’a dit qu’il avait du mal à le vendre : « SAP » est une marque qui fait <i>peur</i> aux PME.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - montanaurn:md5:93e1f29b84561166af4f138da9a7e0272007-04-19T12:17:17+00:002007-04-19T12:17:17+00:00montana<p>Vos informations sont correctes et très instructive mais il serait intérréssant de se pencher sur la version déstinée au PME de SAP: Business One. Elle est nétement plus simple d'utilisation et beaucoup plus finie.</p>Service après-vente - Eric C.urn:md5:6969ab46dd6f57df9f4f306677e5ca632007-04-16T10:50:05+00:002007-04-16T10:50:05+00:00Eric C.<p>Une preuve que la veille bloguesque (à ne pas confondre avec la vieille blogueuse) sert à quelque chose : le billet d'Eolas m'avait échappé.<br />
</p>Le rôle des NULL en ABAP et PL/SQL - Le webmestreurn:md5:95c56f95daf1bb49db0cd744efd7edd02007-03-12T18:32:04+00:002007-03-12T18:32:04+00:00Le webmestre<p><b>Jid </b> : Tu fais encore du Cobol ?</p>Le rôle des NULL en ABAP et PL/SQL - Jidurn:md5:76e90c7139123abda93a977a7eaef2b12007-03-12T13:14:02+00:002007-03-12T13:14:02+00:00Jid<p>Bien intéressant (et surtout bien expliqué).<br />
Ne travaillant pas avec des etraction de tables je ne m'étais jamais posé la question.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:8899ce905d0319a93e553af99dfb2bd02007-02-26T19:14:08+00:002007-02-26T19:14:08+00:00Le webmestre<p><b>@cleopatre</b>: En français ??? Heu... Désolé, j'en connais pas. De toute façon dans ce métier faut savoir acheter en anglais voire ici en allemand... </p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - cleopatreurn:md5:4a1c08a19d3c3c5db4f3da76357358242007-02-25T22:35:09+00:002007-02-25T22:35:09+00:00cleopatre<p>bonjour, je recherche un livre en francais pour Abap.Merci d'avance j'en ai vraiment besoin.à bientôt.</p>Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:d5ecf17f1f5056854df26457b7563e012007-02-14T11:07:47+00:002007-02-14T11:07:47+00:00UKRAINIEN<p>Remerciement partagé. J'aurai aussi appris.</p>Des millions de lignes à travers le millefeuille - Le webmestreurn:md5:be7e030ca9e38156a130e1dd240235f62007-02-13T21:19:17+00:002007-02-13T21:21:22+00:00Le webmestre<p><b>@UKRAINIEN</b> : <br>- Quitter SAP ??? Le choix d’un ERP ne se remet pas en cause à la légère, quel que soit le coût de la licence : le tarif de la migration (que ce soit d’Oracle Applications vers SAP ou l’inverse) est prohibitif, avec tous les spécifiques et interfaces à réécrire, les flux métiers à revoir (et Dieu sait qu’un ERP est structurant de ce point de vue...). Ça n’est envisageable sérieusement qu’en cas de dépérissement de l’éditeur de l’ERP originel ou de consolidation de plusieurs ERP après fusion de deux entreprises...). Le prix des licences est un détail à côté du coût d’implémentation et de maintenance. (Même si ça se rentabilise, mais c’est vrai pour la plupart des ERP).</p>
<p>- Le lien avec le dictionnaire de données a ses côtés pratiques, et n’est pas trop mal implémenté (pour du SAP), mais d’un autre côté mélanger allègrement le technique et le fonctionnel n’est pas non plus une si bonne idée, les contraintes au développement sont parfois assez pénibles. Dans R/3, passe encore, mais en ABAP objet, les problèmes de transtypage que je citais étaient inconnus dans aucun autre langage, forçaient à une orgie de transtypage manuel et surtout n’étaient pas repérés à la compilation mais faisaient dumper à l’exécution !
<p>- Le SQL de SAP n’a pas de syntaxe si particulièrement spéciale (sinon ces pénibles histoires de parenthèses et de virgules, il est SURTOUT très limité par ce qu’on peut faire faire à la base (sauf à faire du SQL natif mais dans ce cas pourquoi acheter SAP ?).
<p>- Les tables internes ne sont pas trop mal gérées mais le problème est leur existence même : sous Oracle, l’utilisation des tables « en direct » (ou par des fonctions d’API) était tout aussi pratique - mais on tirait parti de la gestion des commit, des curseurs, du fait que les SELECT pouvaient être beaucoup plus complexes. Et cela faisait un code nettement moins verbeux (moins de lignes par tâche, quoique cela dépende pas mal du développeur).<br>Au final, le code était pondu beaucoup plus vite pour des programmes un peu importants.
<p>- La gestion des écrans n’est pas simpliste, elle est bizarre : jamais vu ailleurs, jamais compris la cohérence. Pour des écrans texte 80 colonnes ça devait aller mais nous sommes au XXIè siècle. Oracle utilise un outil du genre de ce qu'on trouvait en RAD dans les années 90, <i>Forms</i> (moche et assez limité mais à peu près utilisable, créant de vrais fenêtres avec ascenseurs, boutons...), en attendant le <i>full web</i>.<br>Par contre, pour les sorties papier, <i>Smartforms</i> (un cauchemar d’ergonomie) n’arrive pas à la cheville de Oracle Reports, un outil de dix ans plus ancien.
<p>Un bémol, la gestion des <i>matchcodes</i>, SELECT-OPTIONS, PARAMETER, l’intégration avec les filtres... est un point fort de SAP/ABAP que je regretterais si je retournais sous Oracle Applications.
<p>- La programmation objet, je suis d’accord, n’est pas vraiment adaptée au fonctionnement des ERP, mais c’est une question de style ; le point fort est plutôt dans la gestion des interfaces graphiques, encore faut-il que cela soit fait correctement, l’adaptation au CRM m’a semble inutilement complexe (un défaut très SAP, je dirais même très allemand, la lourdeur façon ''Panzer'').
<p>- Oracle fait ça tout aussi bien, de manière plus agréable à mon goût car il se base sur une collection d’outils plus ou moins « standards » et non liés forcément à l’ERP, et le langage de développement est plus moderne et plus agréable (PL/SQL, proche du Pascal et du SQL). On pourrait rêver d’un mix des deux, du PL/SQL intégrant les <i>matchcodes</i> et éventuellement le typage « fonctionnel » des données.
<p>- Ouais, à moi aussi le temps manque... Merci des critiques constructives, en tout cas.
Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:d97998c207b5d228d72a29949fa3af852007-02-13T17:37:45+00:002007-02-13T17:37:45+00:00UKRAINIEN<p>D'accord pour le côté commercial, j'ai connu 2 projets qui ont planté pour un mauvais choix de l'ERP, à savoir SAP, qui n'était pas le meilleur choix pour le métier du client.<br />
<br />
Mais tous les clients ne font pas confiance qu'aux commerciaux dans leur choix. En fait la pertinence du choix repose sur le fait que l'on peut quitter SAP, car en fait cela représente très peu en rapport du C.A. des grandes sociétés, parfois 1 ou 2%. Et ces sociétés ne le font pas.<br />
<br />
L'ABAP OBJECT a de bons points, en rapport à JAVA, la gestion des données en permettant de se référer au dictionnaire de données. Le problème de transtypage est commun à tous les langages, l'ABAP n'y échape pas.<br />
<br />
Je suis resté sur ORACLE au PL/SQL, je ne peux pas me permettre de comparer au-delà. Cela étant dit, il faut donc voir toutes les facettes du langage.<br />
<br />
Pour l'abap : <br />
le SQL (avec ses syntaxes particulières)<br />
la gestion par des tables internes (que je trouve excellente, car figée les données à un instant me semble très important)<br />
la gestion des écrans, simpliste (parfois un peu trop)<br />
La programmation interactive<br />
la programmation object (encore faut-il l'aimer, parfois pas très adaptée au besoin, et complexifie la programmation, quelle que soit le langage. Ce n'est que mon avis).<br />
<br />
Oracle fait-il tout cela? Personnellement je ne sais pas. Et je ne connais pas le niveau de complexité pour le faire.<br />
<br />
<br />
Pour ce qui est de mes stagiaires, tous ne sortent pas d'école, certains avaient plus de 15 ans de programmation derrière eux.<br />
<br />
J'ai lu aussi tes réponses sur les autres messages. Pardon, je ne peux y à répondre à toutes, le temps me manque. Je n'ai pas essayé de te convaincre, juste de présenter mon point de vue.<br />
<br />
</p>Des millions de lignes à travers le millefeuille - Le webmestreurn:md5:7b06eaf564bfb3efa5bc59c92612db302007-02-12T21:22:30+00:002007-02-12T21:26:57+00:00Le webmestre<p><b>@UKRAINIEN</b> : Oui, j’avoue une préférence pour Oracle (du moins j’aime la base de données, et l’utiliser ; l’administrer est plus chinois ; l’ERP est mieux foutu mais moins puissant que SAP, avec ses propres limites ; les autres outils sont très inégaux ; quant à l'entreprise elle-même, elle est à baffer.<br>Pour le mandant, je n’ai pas voulu détailler. Ça fait partie des bonnes idées du produit (je passe sur quelques incohérences d’implémentation, du genre des Sapscripts mandants-dépendants quand les programmes sont interdépendants, mais bon...).<br>L’ABAP a pas mal évolué, oui, mais R/3 ne se programme pas encore en ABAP objet là où je bossais. Le peu que j’ai vu du développement sur le CRM avec sa boulimie de classes m’a effrayé ; j’ai failli pleurer quand je me suis aperçu que l’utilisation en paramètres de fonctions de variables de même type sous-jacent (entiers, chaînes...) mais de domaines différents que celui attendu provoquait des plantages (à l’éxécution !!!), obligeant à une orgie de transtypage. (Mais bon, l’expert qui me pilotait sur ce sujet précis était peut-être une burne qui ne connaissait pas les astuces...).<br>Les points positifs, il y en a, mais comme dit sur un autre billet, il ne sont pas liés au développement (sinon à la facilité de trouver des gens pour écrire les programmes, en général en Inde). Quant à l’argument d’avoir été choisi par les plus grandes sociétés... je connais assez le milieu et les commerciaux pour savoir que c’est l’antithèse même du critère d’excellence technique :o)</p>Prise de tête en ABAP - Le webmestreurn:md5:d4d2d652b922daf0b961f0a54eab201b2007-02-12T21:05:43+00:002007-02-12T21:07:43+00:00Le webmestre<p><b>@UKRAINIEN</b> : La facilité d’un langage est un piège, il peut être conceptuellement simple (et l’ABAP n'est pas, sur le principe, très compliqué) tout en rendant fastidieux tout développement important, tout comme le BASIC de 1985 était simple mais encourageait des habitudes de programmation détestables. D’autre part, c'est en pratiquant que l’on découvre les limites d’un outil, je ne pense pas que des stagiaires soient très qualifiés.<br>La comparaison avec le PHP me semble osée : concepts, syntaxe et utilisation n’ont rien à voir. VB est aussi différent, mais plus « brouillon » (du moins le VB6 - et en tout cas plus polyvalent.<br>Je suis d’accord qu’il ne faut surtout pas commencer par l’ABAP comme premier langage, évidemment, un premier langage se doit d'avoir des concepts « propres » (j’aimais bien le Pascal...).<br>Pour revenir au sujet de ce billet : le problème principal tenait à la rigidité syntaxique sur des choses toutes bêtes comme IF 1>2, les espaces autour des parenthèses, ou l’impossibilité d’utiliser des fonctions en ligne. Aucun langage digne de ce nom que je connais n’a ces restrictions arbitraires.<br>J’ai une objection de principe contre les tables internes (miroir de ce qui se trouve en base avec d’inévitables problèmes de synchro, au lieu de tirer parti de celle-ci et de la notion de transaction), mais je pardonne à cause de l’historique chargé du produit, et c’est implémenté de manière acceptable.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:b43b5dc368247053a5f4f49c9811ac7c2007-02-12T20:47:03+00:002007-02-12T20:47:53+00:00Le webmestre<p><b>@UKRAINIEN</b> : Il faut distinguer deux choses dans le développement : la logique interne, et la facilité de le faire avec des outils correct. Pour la première, c’est un choix ; la seconde en découle cependant directement même si ce n’est que de la « technique » ; une erreur de <i>design</i> et un programme marche, mais en claudiquant.<br>SAP a choisi de ne pas tenir compte de décennies de recherche sur les bases de données (car fondamentalement c'en est une, avec des tables bien rangées), et de s'en tenir à un modèle de données antédiluvien (développé il y a longtemps) ou démentiellement moderne (CRM) ; idem pour le langage qui a des limites et une rigidité qui ne se sont plus de ce siècle, et rendent le développement très pénible pour qui est attaché à un minimum d’élégance et de compacité ; les outils sont plus ou moins imposés et représentent un <i>patchwork</i> de générations différentes, et ce ne sont pas les plus récents les mieux conçus (j’ai une haine particulière pour le pourtant récent <i>Smartforms</i>) ; la base sous-jacente est sous-exploitée (le SQL de l’ABAP n’arrive pas à la cheville de celui de la base Oracle sous-jacente ) ; l’interface est le type même de ce qu’il ne faut pas faire en ergonomie. Il est clair qu’une masse énorme de travail permet à la chose de tenir debout, mais c'est d'abord à sa richesse fonctionnelle qu’elle le doit (et là, chapeau). Je ne nie pas que quelques gadgets embellissent parfois la vie (je regretterai les <i>matchcodes</i>), mais si peu... La doc ne manque pas mais elle est boursouflée et très lourde. Les interfaces de programmation (fonctions, BAPIs, <i>user exits</i>...) se sont empilées au fil des modes et leur maniement est parfois délicat ou abscons. Dernier et très gros reproche, les standards sont totalement méprisés sur à peu près tous les plans (SAP se veut le standard).<br>En tant que développeur, ce fut un calvaire, mais comme je l’ai dit, je ne suis pas la cible et la facilité de développement n’est pas l’argument de vente. </p>Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:3837c11fcd2dff6171adad705ecfe4e32007-02-12T13:35:51+00:002007-02-12T13:35:51+00:00UKRAINIEN<p>Décidément,<br />
<br />
vou seriez pour oracle que je ne serai pas surpris. (:)) Mais c'est votre droit.<br />
<br />
La notion de mandant va au-délà de ce que vous enoncez. Il est aussi possible de rajouter des index sur les tables, jusqu'à 12, mais comme vous le savez "trop d'index tue l'index". C'est une décision à prendre par les administrateurs SAP.<br />
<br />
il y a eu de nombreuses améliorations dans les requêtes ABAP, sans que vous le voyez. Comme c'est un langage interprété compilé, les optimisations peuvent être faite sans pour autant changer la syntaxe.L'ABAP est un langage qui a beaucoup évolué au cours des 5 dernières années.<br />
<br />
SAP n'est pas considéré comme une bête de course, je partage votre point de vue. Mais comme il a été choisi par les plus grandes sociétés dans le monde, il a aussi des points positifs.<br />
</p>Prise de tête en ABAP - UKRAINIENurn:md5:92d2fae1315885e362fa400baac01d182007-02-12T13:26:17+00:002007-02-12T13:26:17+00:00UKRAINIEN<p>Bonjour,<br />
<br />
Je suis désolé que l'ABAP présente autant d'incovénient à votre égard. Personnellement, je forme des développeurs dans ce langage, des chômeurs ou des étudiants, et je constate ceci:<br />
il est plus facile de développer en ABAP qu'en VB,<br />
il est facilement apparenté par mes stagiaires à du PHP, dans son mode de fonctionnement.<br />
<br />
Ceux sont les propos de mes stagiaires.<br />
<br />
Il a des obligations syntaxiques : mais comme tout langage. La notion des tables internes lui est propres, ainsi que certaines syntaxes SQL.<br />
<br />
Personnellement je ne recommande pas d'apprendre à développer en premier en ABAP, mais plutôt dans les autres langages (C, VB, PHP). après mes stagiaires le trouvent extrèmement simple, facile à utiliser.<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - UKRAINIENurn:md5:485315adeaae500f7a1d0a28e8fd91252007-02-12T13:17:40+00:002007-02-12T13:17:40+00:00UKRAINIEN<p>Bonjour,<br />
<br />
Le principe de SAP se résume en 3 mots : intégrité, portabilité, scalabilité. Pour ce qui concerne l'intégrité, je ne répondrai que sur la partie développement, c'est mon métier et il y a déjà beaucoup à dire.<br />
Si vous allez intégrer directement dans les tables, c'est tout à faite possible, mais vous ne respecterez pas les règles métiers définies par le consultant fonctionnel. Les réintégrer dans un programme est refaire le travail du consultant fonctionnel, ou de SAP.<br />
<br />
Les problèmes que vous présentez dans la gestion des données concerne un problème de réplication, avec des données modifiées. Cela se gère très bien dans SAP, en passant par les fonctions adéquates, ou même dans un programme spéficique, à la condition de connaitre les bonnes zones.<br />
<br />
Il est vrai qu'il n'est pas toujours facile de travailler avec SAP, et on peut parfois s'arracher les cheveux. Mais si SAP est numéro 1, ce n'est pas pour rien. Il a aussi de nombreux avantages.<br />
<br />
Vous aurez en juillet/aout prochain un livre en français sur l'ABAP, qui présentera les concepts SAP. J'en suis l'auteur. Aux editions ENI.</p>Initialiser tu n’oublieras pas ! - Le webmestreurn:md5:d173155340981db1812b2b943bf5841d2006-12-21T21:37:00+00:002007-02-11T11:19:36+00:00Le webmestre<p><b>@Stéphane</b> : Oui, un peu. Disons que le vrai problème, là, est que le compilo laisse passer le fait qu'on rencontre deux fois la même variable à la suite, plus que le fait qu'il ne veuille pas recréer la case mémoire qui va bien.
Courage, plus que 2 semaines à subir ce langage...</p>Initialiser tu n’oublieras pas ! - Stephurn:md5:6ba0debb161a04ee9fd34e6e166a85562006-12-20T18:46:59+00:002006-12-20T18:46:59+00:00Steph<p>OK, là du coup c'est plus effrayant, oui.<br />
C'est un équivalent d'un "static" en C qui serait implicite... ?</p>Initialiser tu n’oublieras pas ! - Le webmestreurn:md5:bfbf68b88c4e3d6be2ab537d5da843352006-12-20T17:15:47+00:002006-12-20T17:15:47+00:00Le webmestre<p><b>@Stéphane</b> : Heu... C'était pour voir s'il y avait quelqu'un qui <strike>lisait</strike> suivait... :o)<br> Sérieusement, oui, la ligne DATA est au-dessus du IF, et effectivement ça ne passerait pas, et elle n'est pas non plus réinitilalisée. D'ailleurs le code foireux que tu as pointé compile aussi, j'ai vérifié, et c'est également effrayant... </p>Initialiser tu n’oublieras pas ! - Stephurn:md5:a90ee54c023de062cc55faa1e831a5b42006-12-20T11:28:40+00:002006-12-20T11:28:40+00:00Steph<p>Je ne connais pas ABAP du tout, mais dans ton exemple<br />
----------<br />
IF x-un_champ = ... .<br />
. DATA v TYPE c VALUE '0'.<br />
. v = c_une_valeur.<br />
.ENDIF.<br />
. compteur = compteur + v + x-un_autre_champ.<br />
----------<br />
tu déclares bien v à l'intérieur du IF/ENDIF, et tu l'utilises pourtant en dehors dans ta sommation ?<br />
<br />
Je ne vois pas comment il devrait réagir, mais en C si tu fais.<br />
---------------<br />
if x->champ {<br />
montype v = 0;<br />
v = c->valeur;<br />
}<br />
compteur = compteur + v + x->un_autre_champ;<br />
---------------<br />
tu vas te prendre une erreur du compliateur, bien sur...<br />
<br />
Qu'ABAP le permette me parait plus une faute que le fait qu'il n'initialise pas.</p>Initialiser tu n’oublieras pas ! - Baliseurn:md5:c326dc9b08e6d75b218efb5f57ce1e362006-12-19T22:37:48+00:002006-12-19T22:37:48+00:00Balise<p>AAAAAAAAH mais quelle horreur :(((</p>Par paquets de 5 - Le webmestreurn:md5:71f6d6cc5da6a5bc3aac0e897194c67f2006-11-17T09:41:35+00:002006-11-17T09:42:16+00:00Le webmestre<p><i>Balise</i>>Effectivement, mon entretien annuel, ça a donné à peu près ça :o) <br>Et j’en ai tiré les conséquences puisque je pars et du client et de ma SSII trop spécialisée sur SAP dans la région.</p>Par paquets de 5 - Baliseurn:md5:6f8ee6678b545d70311218c1ed2f1f072006-11-16T22:35:48+00:002006-11-16T22:35:48+00:00Balise<p>J'aime. Et après, en entretien : « Y a-t-il des choses que vous ne souhaitez pas faire ? - Du SAP. - Ah, pouquoi ça ? ».</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:e11a47ebfc5546f7ecb9771a4298a8af2006-11-09T17:54:07+00:002006-11-09T17:57:33+00:00Le webmestre<p><i>Raspberry92</i> > Les modèles de données complets comportent des milliers de table. Et cela dépend du nombre de modules installés. Dans le cas d’Oracle, on peut se débrouiller un peu avec les nom, mais le modèle de SAP R/3 est vraiment cryptique, avec ses noms de tables de 4 lettres, acronymes de mots en allemand. C’est pour quelle utilisation ?
<br>Soit dit en passant, toutes les docs que j’ai vues sur le sujet indiquent que l’information est confidentielle (non que ce soit vraiment un joyau, mais la chose doit ).
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Raspberry92urn:md5:048d983a546f85f550c08dc475ab241d2006-11-09T17:40:22+00:002006-11-09T17:40:22+00:00Raspberry92<p>Bonjour,<br />
savez vous si il est possible de récupérer les datamodels de ces deux ERP ?<br />
Cordialement,<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - JELMANSurn:md5:61d049832a8456b564d73b750719a4612006-10-23T21:34:46+00:002006-10-23T21:34:46+00:00JELMANS<p>bonjour..pourriez vous m'avoir les codes et types de mouvements pour sap r/3 de magasinage du stock... out-ind-mix-ensachage produits ect.....merci a+++</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:0b1494d5a6617ac43d172ec965c356832006-10-01T15:31:16+00:002006-10-01T15:31:16+00:00Le webmestre<p>Corrigé le lien...</p>Les joies de l’ERP et du CRM (II) - anteaneurn:md5:a6d17e91f01abb1e13c1fc59ffd37c2d2006-09-28T17:08:36+00:002006-10-01T15:29:57+00:00anteane<p>Bonjour,<br />
<br />
Je viens de rédiger un article sur les grandes étapes de la mise en place d’un ERP( <a href="http://www.anteane.fr/dotclear/index.php?2006/09/28/17-erp-gpao-quelles-etapes-pour-la-mise-en-place-l-exemple-pmi-soft" title="http://www.anteane.fr/dotclear/" rel="nofollow" rel="ugc nofollow">www.anteane.fr/dotclear/...</a> Je prends l’exemple de PMI SOFT. Je pense qu’aujourd’hui les ERP s’ouvrent vers de nouveaux marchés, les PME par exemple et que la mise en place se simplifie de plus en plus tout en gardant l’essentiel et surtout la fonctionnalité et l’efficacité. J’attends des réactions à ce sujet.<br />
<br />
merci </p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:36170a9053424a28804b83254bd753272006-09-05T20:44:20+00:002006-09-05T20:44:20+00:00Le webmestre<p>Et bien giao, profite d’Oracle tant que tout le monde n’est pas encore passé sous SAP :o)</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - giaourn:md5:3b5310ffd844076dd88833654e7c76482006-09-05T18:47:49+00:002006-09-05T18:47:49+00:00giao<p>merci pour ce début de commencement d'explication sur les différences intrinsèques entre Oracle et SAP. Je travaille sur OAP depuis 1999 et je trouve ton exposé très pertinent. Malheureusement, ma connaissance de SAP est nulle mais l'étude comparée permet d'en concevoir quelques aspects. bien cordialement.</p>Prise de tête en ABAP - Le webmestreurn:md5:bbf126b980bb6984d074230ba27103bb2006-07-19T18:38:49+00:002006-07-19T18:38:49+00:00Le webmestre<p>Ouais, le cobol peut pas être pire. Je connais pas mais d’après ce que j’en vois et entends, ça m’ennuierait assez vite... L’ABAP, lui, m’énerve.</p>