Vous pensez que Agile ne peut pas travailler avec un progiciel de gestion intégré? 7 mythes communs démystifiés

Partie 1 de la série « DevOps pour ERP » en 3 parties

Le développement agile est une méthodologie éprouvée adoptée par de grands éditeurs de logiciels du monde entier convaincus de leurs avantages. il peut livrer. Alors pourquoi est-ce que je rencontre tant de gens qui, malgré l'évidence du contraire, semblent croire que des processus modernes de livraison d'applications comme Agile et DevOps ne font tout simplement pas, ou ne peuvent pas, s'appliquer à les applications les plus critiques de leur activité – leur suite de planification des ressources d'entreprise (ERP)?

C'est un sujet qui me préoccupe beaucoup en ce moment, car je travaille avec plusieurs entreprises qui ont constaté d'énormes avantages après une transition. développement agile dans leurs applications ERP.

Le fait est que de nombreuses organisations informatiques modernes subissent une énorme pression pour offrir des avantages commerciaux plus rapidement, et que les anciennes méthodes de travail ne la réduisent tout simplement plus. J'ai déjà parlé des avantages et de la valeur qu'un modèle agile peut apporter au logiciel ERP, je vais donc adopter un point de vue opposé et expliquer pourquoi certains des mythes et idées fausses les plus répandus concernant l'ERP agile ne retenez pas l'eau.

Mythe n ° 1: La stabilité et la résilience sont essentielles. Agile ne fait qu’ajouter des risques.

Les systèmes ERP ont été conçus sur la base de la stabilité et de la résilience, de sorte qu’il est généralement admis qu’ils ne devraient pas être modifiés rapidement. Cette perception est fondamentalement motivée par la crainte (et les conséquences) de casser des choses.

Bien sûr, l’ERP est traditionnellement considéré comme un «système d’enregistrement», mais dans de nombreux cas, c’est aussi le moteur qui permet «systèmes d’engagement» visibles, tels que les sites Web et les applications mobiles. Les entreprises et leurs clients exigent de plus en plus de tels systèmes d’engagement, qui changent constamment. Les systèmes ERP doivent évoluer à un rythme correspondant s'ils peuvent continuer à fournir la différenciation précieuse qui distingue une entreprise de ses pairs.

Des processus et outils agiles permettent aux développeurs ERP de satisfaire aux exigences apparemment contradictoires du système. résilience et changement rapide. La gestion et le déploiement des changements incrémentiels plus modestes observés dans l'agilité sont en réalité beaucoup moins risqués.

Mythe n ° 2: Agile ne peut fournir la conformité, la documentation et les approbations dont nous avons besoin.

OK, il ne fait aucun doute que certains Les secteurs industriels tels que les soins de santé ou le gouvernement exigent beaucoup plus de conformité, de gouvernance et de documentation. À première vue, cela peut sembler aller à l’encontre d’une approche agile, étant donné que le Agile Manifesto accorde explicitement plus de poids aux logiciels qu’à la documentation. En réalité, ce n'est pas le cas.

Agile améliore considérablement l'efficacité des processus d'ingénierie et de développement, ce qui signifie que les bonnes solutions peuvent être fournies plus rapidement – un résultat bénéfique même dans les industries réglementées où une documentation et une conformité spécifiques sont requises. [19659003] Quels que soient les processus prescrits, il est plus probable que vous testiez, approuviez et documentiez les choses plus rapidement avec une approche agile, en particulier si vous intégrez la bonne quantité de réglementation et de connaissances du secteur dans l’équipe de développement. Avec des processus appropriés et des outils automatisés, la conformité pourrait même devenir plus simple et moins fastidieuse.

Ce rythme accéléré de changement permet également aux organisations de réagir plus rapidement lorsque la législation change. C’est potentiellement un avantage commercial et certainement un moyen de réduire les risques.

Mythe n ° 3: La cascade fonctionne.

La méthodologie de la cascade – où les exigences sont entièrement définies à l’avance et mises en œuvre dans une grande et grande pièce – a été à la base de nombreux projets de mise en œuvre d’un système de gestion intégré et, dans de nombreux cas, a parfaitement fonctionné. Alors, pourquoi changer quelque chose que tout le monde connaît et dont on a prouvé qu’il était efficace (du moins dans certains cas)?

Eh bien, pour ne pas trop insister sur le fait, la cascade ne fonctionne souvent pas. Ou du moins pas aussi bien qu'il le devrait. Les projets sont souvent lents et dépassent le budget. Le long délai de livraison encourage le glissement de la portée tout en réduisant les chances que le produit final réponde aux besoins des clients. Même la pression exercée par une seule date limite stricte peut être contre-productive, ce qui encourage le déploiement de code inachevé pour ne pas dépasser le calendrier prévu.

Agile peut résoudre tous ces problèmes en proposant des itérations fréquentes, une hiérarchisation claire des priorités et un retour constant. J'ai constaté que les approches agiles fonctionnaient très bien dans certaines énormes organisations qui exécutent l'ERP, même si cela peut prendre du temps pour bien faire les choses.

Mythe n ° 4: Une approche hybride cascade + agile est préférable.

une réticence à prendre des mesures pour devenir agile sans preuve définitive que cela fonctionne: une situation de poule et d'œuf. Le confort et la familiarité avec le type de projets ERP pré-budgétisés à prix fixe que je viens de mentionner peuvent également constituer un obstacle.

Une solution dans cette situation pourrait être de "tester" de manière agile des éléments spécifiques du processus de développement via une approche de «chute agile de l'eau». Ici, la phase de construction du projet est effectuée en itérations, tandis que la phase de conception et les tests d'intégration complets se déroulent de manière traditionnelle. Cette approche hybride peut être utilisée pour conserver la planification et la budgétisation initiales bien connues, puis les tests en aval et leur publication ultérieure.

C'est une idée séduisante: tous les meilleurs éléments des deux approches sans les inconvénients.

Soyez un exemple éloigné où ce type d’approche hybride reste le plus approprié. En réalité, cela signifie que votre entreprise n’appréciera jamais toute la valeur de l’agilité. Il devrait s'agir d'une solution temporaire fournissant les éléments de preuve à l'appui d'un déploiement complet.

L'un des éléments clés de l'ERP est une grande intégration entre les processus métier, pouvant être répartis entre différentes équipes et domaines fonctionnels avec une collaboration limitée. Cette situation complexe renforce souvent l'idée que l'agile ne peut pas fonctionner.

Cependant, un facteur de succès majeur dans une telle situation est une compréhension claire des dépendances inhérentes à la solution, de sorte qu'elles puissent être gérées efficacement, et l'objectif reste le même. sur les résultats commerciaux requis.

Une partie de cette compréhension découle d’une vision claire de la structure des équipes. Il est donc essentiel de disposer de connaissances métier et architecturales dans le cadre de la fourniture de la solution.

Agile aide réellement dans cette situation. La gestion efficace des arriérés et la planification des sprints permettent de gérer correctement les dépendances entre les processus et les équipes. Il en résulte des exigences qui sont mises en œuvre dans le bon ordre et garantit le maintien de l'intégrité de la solution.

Mythe n ° 6: Agile ne fonctionne pas pour les nouvelles mises en œuvre.

On dit souvent que l'agile peut fonctionner dans un ERP, mais pas si votre projet est une nouvelle installation ou si vous déployez un programme important où il y a trop de travail à gérer.

Il est vrai que, dans ce cas, le projet pourrait durer plusieurs mois, voire plusieurs années, avant qu'une solution ne soit fournie. pour une utilisation en production. Mais cela ne signifie pas pour autant que l’entreprise doive attendre des mois avant de pouvoir se pencher sur ce qui est construit. C’est la recette de l’échec.

Dans ce scénario, les chefs d’entreprise agiles sont intégrés au processus dès le début afin de pouvoir agir en tant que propriétaires de produits et d’orienter en permanence le développement et la configuration. Ils peuvent également voir et tester ce qui a été construit à un stade précoce. Cela évite le développement prolongé de solutions sous-optimales qui pourraient être observées dans les approches en cascade où l'entreprise n'a aucune visibilité sur les résultats avant la livraison finale du projet.

Mythe n ° 7: Agile ne fonctionne pas avec des équipes externalisées et offshore.

] Dans de nombreuses organisations ERP, les équipes sont réparties et comprennent souvent une combinaison de fournisseurs externalisés. Cela peut constituer un défi pour l'adoption de l'agilité en raison de la perception que la communication sera entravée si les membres de l'équipe ne sont pas dans la même pièce.

La première étape pour franchir cet obstacle est simplement l'ouverture des équipes et des partenaires. méthodes agiles. C'est peut-être déjà le cas, ou cela pourrait nécessiter un peu de travail, mais cette attitude est en train de devenir monnaie courante pour la plupart des fournisseurs, car il est nécessaire de prendre en charge des méthodes agiles et similaires pour rester compétitif.

En fait, l'agilité peut être un avantage dans cette situation. modèle distribué. Les points de presse quotidiens, ainsi que les réunions de planification et rétrospectives, garantissent que tous les membres de l’équipe sont alignés sur le propriétaire du produit. Ils comprennent les priorités et les dépendances et ont une communication constante et des points de contrôle permettant une gestion plus efficace des risques. Cela réduit en fait un risque majeur du modèle offshore: la défaillance de la communication.

Conclusions

La résistance au changement n'est pas un phénomène rare. Il est compréhensible que le passage à l'agile soit inconfortable pour certains, en particulier dans les progiciels de gestion intégrés, où il n'a pas encore été vu très souvent.

Pour obtenir un travail agile, vous devez disposer des bonnes personnes possédant à la fois des compétences fonctionnelles et techniques. , qui sont ouverts à travailler d'une manière différente, et on peut faire confiance à cela. Il faudra du temps pour s'adapter, mais cela peut être fait!

Bien que les projets ERP soient souvent longs et complexes, dans de nombreux cas, plus il y a de résultats à fournir, plus une approche agile peut être efficace. Agile excelle dans les systèmes complexes comme l'ERP, où de nombreuses choses ne peuvent pas être anticipées, en tant que méthode pour traiter les problèmes que vous ne pouvez tout simplement pas planifier.

Si vous êtes intéressé par l'agile pour ERP – ou peut-être cet article vous a-t-il convaincu qu'il vaut la peine de regarder – jetez un coup d'œil à ce livre électronique pour obtenir des conseils pour vous aider à démarrer.

Cet article a paru à l'origine sur le Blog de Basis Technologies. Cette version adaptée est republiée avec permission. Basis Technologies est un partenaire Silver de SAP.