- La mise en œuvre commence par un prototype, dans lequel des chaînes de processus métier ont déjà été implémentées, qui peuvent être acceptées par le client comme cible. Dans le même temps, il peut y avoir des différences qui doivent être éliminées au cours du projet.
- Pour travailler sur le projet, une seule équipe est constituée, composée de consultants, de représentants clients de l'entreprise et du service informatique. Les représentants des clients sont formés pendant le projet et, avec des consultants, testent des prototypes de systèmes, formulent les exigences du système et acceptent leur mise en œuvre. Le service informatique prend une part active, met en œuvre certaines des exigences et à la fin du projet prend le système pour le soutien.
- Au cours du projet, plusieurs autres prototypes sont mis en place, qui à chaque itération se rapprochent des exigences du client. Au cours du projet, les exigences sont spécifiées et modifiées plusieurs fois.
En fait, dans un grand projet d'implémentation ERP, les principes agiles sont appliqués - les personnes et l'interaction sont plus importantes que les processus, un produit fonctionnel est plus important que la documentation, la coopération avec un client est plus importante qu'un contrat et la préparation aux changements est plus importante que de suivre un plan initial.
Cependant, dans les conditions d'un contrat signé à prix fixe, fonctionnant avec un grand système unifié, ces principes doivent atterrir. Sans conditions et restrictions supplémentaires, le projet ne sera probablement pas achevé et ira certainement au-delà du budget.
Premièrement, il ne s'agit pas d'un développement d'un système qui peut être démarré par parties, comme c'est souvent le cas dans les projets agiles, lorsque chaque itération doit se terminer par le développement d'un bloc fonctionnel complet prêt à l'emploi. Un système ERP ne peut être exécuté que dans son intégralité et non en partie.
Deuxièmement, si vous ne limitez pas les exigences, leur clarification et leur changement seront sans fin, le projet s'étendra et nécessitera un financement supplémentaire.
Ainsi, le premier problème est que le système ERP est constitué de parties étroitement interconnectées, imprégnées de processus de bout en bout. Par conséquent, nous avons besoin d'un système holistique dans toute sa portée à chaque itération. La tâche est facilitée par le fait que le système n'est pas créé à partir de zéro, c'est un produit fini. Il existe souvent une solution industrielle ou un système préconfiguré avec des processus standard que vous pouvez utiliser comme premier prototype fonctionnel.
Il faut du temps pour préparer le prochain prototype. Le système est grand, complexe, il y a beaucoup de participants au projet, il faut donc au moins deux mois pour préparer un prototype, le tester et formuler des commentaires dessus. Dans notre cas, les itérations ne sont pas de deux semaines, comme dans un agile typique, mais de 2 à 5 mois.
À chaque itération, nous créons un système complet, mais il existe des différences entre eux. Dans la première itération, il s'agit d'un système typique avec des processus standard ou spécifiques à l'industrie. Les processus standard peuvent être assez éloignés de ce que le client s'attend à voir à la fin. Les processus au plus haut niveau sont les mêmes, mais les détails seront très différents. Quand je dis «client», je veux dire les personnes qui utiliseront le système - quelle que soit la relation qui le relie à l'entrepreneur - contractuel, ou c'est un projet interne de l'entreprise, où l'entrepreneur peut être le service informatique.
Après avoir collecté les exigences en fonction des résultats des tests du premier prototype, nous avons mis en place le deuxième prototype, dans lequel toutes les exigences pouvant être implémentées avec les paramètres sont mises en œuvre, les données de test du client sont chargées, toutes les questions qui ont surgi lors des tests du premier prototype sont résolues. Le client parcourt les processus métier du système, vérifie comment la mise en œuvre actuelle lui convient, l'efficacité du système et répond à ses exigences.
Lors de la deuxième itération, les futurs utilisateurs du système ne le voient pas pour la première fois, se sentent plus à l'aise, proposent de nouvelles exigences déjà plus significatives et détaillées. Idéalement, tous les problèmes clés devraient être résolus pendant cette période, car les changements deviennent plus coûteux moins il reste de temps avant le lancement.
À la troisième itération, nous pouvons déjà nous permettre de commencer à développer des extensions ou, comme nous l'appelons dans le jargon, des «personnalisations» du système. Il peut s'agir de rapports, de procédures, de formulaires absents du système standard, mais ils sont très nécessaires, car il n'est pas toujours possible d'ajuster les processus métier au standard du système. La décision de développer des extensions est prise après avoir considéré toutes les autres possibilités, car leur développement et leur accompagnement sont un plaisir assez coûteux, et c'est de l'argent supplémentaire.
Nous préparons le troisième prototype depuis plusieurs mois pour qu'il devienne un système à part entière proche de celui visé. En règle générale, le système est entièrement configuré, avec une quantité substantielle de données chargées et toutes les extensions critiques installées. Il est testé de manière très approfondie avec un grand nombre d'utilisateurs. Ces tests durent généralement environ un mois.
Après avoir testé le troisième prototype, des commentaires et des questions subsistent, sur lesquels nous élaborons un plan pour leur développement. Et toutes les remarques critiques doivent être éliminées dès le lancement.
Le rythme du projet à ce moment-là devient très intense, le temps est comprimé, comme lors d'un combat. Il est nécessaire de préparer des instructions, de former les utilisateurs, de convertir les données, d'effectuer des changements organisationnels. Des problèmes auparavant non résolus émergent, quelqu'un se souvient qu'il a oublié d'annoncer une circonstance importante ... Avant le lancement, un autre, des tests d'acceptation est effectué - et en avant, le démarrage d'un nouveau système.
Ceci, bien sûr, est une description très superficielle de l'approche itérative de la mise en œuvre d'un système ERP. La méthodologie décrit en détail tous les processus, y compris la documentation, la formation de l'équipe de projet et des utilisateurs, la conversion des données, la réalisation de changements organisationnels, etc., qui ne diffèrent en fait d'aucune autre approche de la gestion de projet.
Une question raisonnable se pose: comment organiser le processus de manière à ne pas passer à la quatrième, puis à la cinquième ou sixième itération? Comment éviter le risque de changements incontrôlés et de clarification des exigences, qui se développent naturellement au fur et à mesure que vous approfondissez les détails, et parfois en raison de changements commerciaux?
Bien sûr, il existe un tel risque, et il est très important. À l'entrée du projet, les exigences sont fixées dans le contrat, mais en règle générale, elles sont formulées de manière générale et le diable est dans les détails.
Avec «l'approche en cascade» au début du projet, les exigences sont fixées, la mission technique est signée, ce qui devient une base formelle plus tard pour refuser de modifier les exigences ou demander des fonds supplémentaires pour le changement. Dans une approche itérative, cette astuce n'est pas applicable.
Nous comprenons que les exigences sont sujettes à changement et changeront sans faute. Nous investissons du temps et de l'argent pour cela. La question est l'ampleur de ces changements. On peut faire une grosse erreur, et obtenir une vague de nouveaux commentaires à la fin, surtout si le client se réfère dans un premier temps à la participation au projet "slipshod", sélectionne les mauvaises personnes pour la participation, ne formule pas clairement les exigences, espère que "tout ira bien" s'appuie sur des consultants - alors à la fin nous avons de sérieux problèmes.
Par conséquent, la composante la plus importante pour réduire le risque d'étalement des exigences à la fin du projet est l'implication du client. La même mise en œuvre du principe du développement agile, selon lequel l'équipe travaille ensemble - le client et le développeur, en contact étroit dès le début du projet. Cela a plusieurs conséquences importantes. Premièrement, l'identification précoce des besoins réels et le non-respect de ces besoins du système. Deuxièmement, étant impliqué dans le processus de préparation du système, le client devient son propriétaire non pas au moment de son transfert dans sa forme finie, mais progressivement, tout au long du projet. Cela devient le résultat de son travail, et à la fin du projet, il devient impossible de faire des déclarations comme «votre système ne fonctionne pas», parce que c'est son système.
C'est une bonne pratique lorsque les personnes les plus qualifiées capables de prendre des décisions sont affectées au projet 100% du temps. Dans notre pratique, il s'agissait de propriétaires de processus commerciaux, de leurs adjoints ou d'employés qui jouissent de la pleine confiance des gestionnaires de services. Oui, c'est difficile, oui - il n'y a pas de personnes supplémentaires, oui - il est difficile de donner le meilleur. Mais c'est le seul moyen de réaliser rapidement un projet et d'obtenir un système de haute qualité. Les participants au projet font un énorme pas en avant dans la compréhension du fonctionnement d'une entreprise, acquièrent de nouvelles connaissances, apprennent à travailler d'une nouvelle manière et, en règle générale, cela leur crée de nouvelles opportunités de carrière. Vous pouvez considérer le projet d'implémentation ERP comme un événement de développement personnel extrêmement puissant, comme la création d'une nouvelle réserve de personnel pour les managers.
La deuxième chose à noter est les contraintes de temps serrées du projet. Le calendrier du projet doit être agressif et la date de lancement ne doit pas changer. Si le projet est étendu, la probabilité de modification des exigences commerciales augmente. Si la date du projet change, de nouvelles exigences apparaissent et la situation se répète: encore une fois, le système n'est pas prêt, reportons le lancement. La perfection des systèmes n'atteindra pas même avec de très longues durées de projet, et toutes les exigences ne seront jamais entièrement identifiées avant le lancement. Seule une exploitation réelle montre tous les goulots d'étranglement et ce qui est vraiment important. Par conséquent, après le lancement, il y a une période de stabilisation d'au moins trois mois, pendant laquelle l'équipe de projet aide et éduque les utilisateurs, corrige les erreurs, reçoit les nouvelles exigences et apporte les améliorations nécessaires.
Pour résister à la tentation de repousser les délais et d'élargir les demandes, chacun doit être fortement incité à respecter ces délais. Pour l'entrepreneur, bien entendu, il s'agit d'obligations contractuelles et d'un budget. La motivation du client est généralement formée d'en haut, de la direction ou des actionnaires de l'entreprise. Par exemple, un PDG qui prend une décision de préparation au lancement peut être entravé par une obligation envers les actionnaires. Le chef de projet et l'équipe projet peuvent être motivés par un bonus à la fin du projet, sous réserve de délais. Les chefs de service seront confrontés à la nécessité de démarrer par ordre de l'entreprise.
Cela arrive très rarement lorsqu'il y a une volonté sincère de lancer le système le plus tôt possible en raison des attentes agréables des nouvelles opportunités qu'il offre. Le nouveau système est, tout d'abord, le stress et la nécessité de passer de l'interface familière à l'interface initialement peu pratique, à plus de contrôle, à la nécessité de saisir plus d'informations. Les utilisateurs finaux n'apprécient presque jamais un nouveau système. Il leur faut du temps pour s'entendre et y trouver des avantages. Et si la motivation interne de lancer à temps n'est pas initialement intégrée au projet, le lancement sera reporté, car les systèmes ne seront jamais prêts à être lancés à 100%.
Compte tenu des dates de lancement serrées, il devient impossible d'étendre et d'affiner sans cesse les exigences. L'équipe projet, qui comprend des représentants du client, arrête de les nommer et commence à réfléchir aux priorités, aux possibilités de reporter quelque chose, face à une échéance inévitablement imminente. La tâche du chef de projet est dès le début du projet de former ce sentiment de lancement précoce, de manque de temps. Une atmosphère trop calme dans la première moitié du projet signifie que la seconde moitié sera extrêmement stressante en raison de la course qui est inévitable. Pour ce faire, des objectifs intermédiaires doivent être fixés et le calendrier du projet est formé de manière à ce que les premières phases du projet soient comprimées dans le temps et, de ce fait, une réserve est formée pour les dernières phases avant le lancement. Il existe différentes stratégies de course à pied,mais ici, la stratégie doit être la même - vous devez courir rapidement dès le début, vous n'avez peut-être pas assez de force pour accélérer à la fin.
Résumé de tout ce qui précède:
- L'approche itérative donne un bien meilleur résultat en termes de proximité du système avec les exigences exprimées et implicites du client.
- La pleine implication du client dans le projet est absolument essentielle pour mettre en œuvre cette démarche.
- Pour éviter la prolifération et le raffinement sans fin des exigences, les échéanciers des projets doivent être strictement limités et les participants au projet doivent être motivés pour y répondre.
Bien sûr, ce ne sont que les principes de base, il reste encore de nombreuses subtilités qui dépendent des conditions spécifiques, des caractéristiques de l'entreprise et de la personnalité des participants. Dans chaque cas, tout est décidé individuellement.