Effectivement, j'aborde surtout les aspects techniques et fonctionnels, parce qu'ils sont les seuls communs à toutes les sociétés. Pour les aspects de gestion de projet et d'organisation, ça varie beaucoup d'une société à l'autre et on ne peut pas faire de retour d'expérience général.
Combien de temps ça prend à déployer ?
En moyenne, pour un projet avec des développements spécifiques à réaliser et des reprises de données : 6 mois.
Mais pour un projet sans reprise de donnée (autre qu'une balance comptable au premier jour de l'exercice) et sans développement spécifique (par exemple, une boutique en ligne qui va bénéficier de tous les modules matures qu'on a développé sur les connecteurs Magento, Amazon, eBay et bientôt PrestaShop et qui n'a pas de besoins "supplémentaires" dans un premier temps), cela peut être beaucoup plus rapide, genre 1 mois.
Comment se passent les récupérations de donnés ?
Quand les anciennes données sont mal structurées dans des bases sur lesquelles le client ne connaît même pas le mot de passe (voir n'y a pas accès car il avait une offre de SaaS propriétaire et l'accès à la base de donnée lui a été refusé) : pas très bien.
Quand les anciennes données sont bien structurées dans des bases propres : ça se fait bien, même si ce n'est pas la partie la plus "fun" du métier.
Quelles sont les résistances internes ?
Dans les petites boites avec un seul niveau de hiérarchie : il n'y en a généralement pas.
Dans les PME de plusieurs dizaines de personnes avec des chefs de service qui ne sont pas d'accord entre eux, ça peut être plus difficile. Si le chef de projet OpenERP côté client n'a pas de pouvoir dans sa boite, c'est un vrai frein.
Dans la partie "La comptabilité avec OpenERP", je parle spécifiquement de l'acceptation de la comptabilité d'OpenERP par les comptables.
Comment le produit résiste à l'épreuve des ans ?
En terme de croissance de la base de donnée : aucun pb. Postgres rulèz.
Il y a la problématique des migrations d'une version à l'autre, qui n'est pas facile et que je n'aborde pas pour le moment dans le document. Ca serait bien d'en parler, il y a pas mal de choses à dire sur le sujet.
Faut-il intervenir souvent chez le client ?
Oui, on intervient souvent (à distance). Comme je l'ai montré, OpenERP a pas mal de bugs, et, même si la plupart du temps ils ne sont pas trop durs à corriger, il faut quand même prendre le temps de le diagnostiquer, le reproduire, le corriger, tester le patch, le déployer et le remonter à l'éditeur. On a aussi beaucoup de questions "comment je fais telle chose dans l'ERP ?" ou "j'ai fait telle bêtise, comme on répare/revient en arrière ?". Après, ce n'est pas non plus anormal : on a installé le logiciel qui est au centre de l'informatique de gestion de la société, c'est une pièce maîtresse de son système d'information, c'est logique qu'on soit plus sollicité qu'un installateur d'IPBX ou de VPNs.
Vous dites :
> Mais en fait ce document est une analyse technique d'OpenERP.
> C'est bien, mais ça ne donne aucune idée de l'intérêt du logiciel pour une entreprise. Qu'il soit bien ou pas techniquement n'est qu'un point relativement mineur.
Tout d'abord, le document ne parle pas que de la technique, mais aussi des aspects fonctionnels, qui sont clé dans le choix d'un ERP. A mon sens, ces deux critères sont les plus importants pour choisir le logiciel de gestion de votre entreprise (en plus de l'aspect libre/opensource et des critères économiques). Le critère technique est particulièrement important pour les sociétés qui vont faire des développements spécifiques importants sur leur ERP. Quand une boite investi des dizaines ou des centaines de milliers d'euros en développements spécifiques sur son ERP, ça serait bien qu'elle s'intéresse à la technologie dans laquelle elle investi !
[^] # Re: Rabat joie
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Expérience de déploiements d’OpenERP dans des entreprises françaises. Évalué à 9.
Effectivement, j'aborde surtout les aspects techniques et fonctionnels, parce qu'ils sont les seuls communs à toutes les sociétés. Pour les aspects de gestion de projet et d'organisation, ça varie beaucoup d'une société à l'autre et on ne peut pas faire de retour d'expérience général.
Combien de temps ça prend à déployer ?
En moyenne, pour un projet avec des développements spécifiques à réaliser et des reprises de données : 6 mois.
Mais pour un projet sans reprise de donnée (autre qu'une balance comptable au premier jour de l'exercice) et sans développement spécifique (par exemple, une boutique en ligne qui va bénéficier de tous les modules matures qu'on a développé sur les connecteurs Magento, Amazon, eBay et bientôt PrestaShop et qui n'a pas de besoins "supplémentaires" dans un premier temps), cela peut être beaucoup plus rapide, genre 1 mois.
Comment se passent les récupérations de donnés ?
Quand les anciennes données sont mal structurées dans des bases sur lesquelles le client ne connaît même pas le mot de passe (voir n'y a pas accès car il avait une offre de SaaS propriétaire et l'accès à la base de donnée lui a été refusé) : pas très bien.
Quand les anciennes données sont bien structurées dans des bases propres : ça se fait bien, même si ce n'est pas la partie la plus "fun" du métier.
Quelles sont les résistances internes ?
Dans les petites boites avec un seul niveau de hiérarchie : il n'y en a généralement pas.
Dans les PME de plusieurs dizaines de personnes avec des chefs de service qui ne sont pas d'accord entre eux, ça peut être plus difficile. Si le chef de projet OpenERP côté client n'a pas de pouvoir dans sa boite, c'est un vrai frein.
Dans la partie "La comptabilité avec OpenERP", je parle spécifiquement de l'acceptation de la comptabilité d'OpenERP par les comptables.
Comment le produit résiste à l'épreuve des ans ?
En terme de croissance de la base de donnée : aucun pb. Postgres rulèz.
Il y a la problématique des migrations d'une version à l'autre, qui n'est pas facile et que je n'aborde pas pour le moment dans le document. Ca serait bien d'en parler, il y a pas mal de choses à dire sur le sujet.
Faut-il intervenir souvent chez le client ?
Oui, on intervient souvent (à distance). Comme je l'ai montré, OpenERP a pas mal de bugs, et, même si la plupart du temps ils ne sont pas trop durs à corriger, il faut quand même prendre le temps de le diagnostiquer, le reproduire, le corriger, tester le patch, le déployer et le remonter à l'éditeur. On a aussi beaucoup de questions "comment je fais telle chose dans l'ERP ?" ou "j'ai fait telle bêtise, comme on répare/revient en arrière ?". Après, ce n'est pas non plus anormal : on a installé le logiciel qui est au centre de l'informatique de gestion de la société, c'est une pièce maîtresse de son système d'information, c'est logique qu'on soit plus sollicité qu'un installateur d'IPBX ou de VPNs.
Vous dites :
> Mais en fait ce document est une analyse technique d'OpenERP.
> C'est bien, mais ça ne donne aucune idée de l'intérêt du logiciel pour une entreprise. Qu'il soit bien ou pas techniquement n'est qu'un point relativement mineur.
Tout d'abord, le document ne parle pas que de la technique, mais aussi des aspects fonctionnels, qui sont clé dans le choix d'un ERP. A mon sens, ces deux critères sont les plus importants pour choisir le logiciel de gestion de votre entreprise (en plus de l'aspect libre/opensource et des critères économiques). Le critère technique est particulièrement important pour les sociétés qui vont faire des développements spécifiques importants sur leur ERP. Quand une boite investi des dizaines ou des centaines de milliers d'euros en développements spécifiques sur son ERP, ça serait bien qu'elle s'intéresse à la technologie dans laquelle elle investi !