Le parcours de mise en œuvre logicielle de mille kilomètres commence par la phase zéro (James Monaghan)

Toutes nos félicitations. Vous avez décidé d'implémenter un logiciel et souhaitez que cela réussisse. Sera-ce Agile ou Waterfall ou Lean ou Scrum ou autre chose de complètement. Même si la mise en œuvre réussie d'un projet a ses propres exigences pour son exécution, il
Il y a de nombreuses choses à considérer avant le coup d’envoi.

Le modèle opérationnel cible a-t-il été correctement défini ?

Se précipiter dans la mise en œuvre d'une nouvelle technologie comporte de nombreux pièges, mais aucun n'est plus courant que de commencer à déployer/intégrer un système sans considérer à quoi ressemblera la situation globale une fois celui-ci terminé. Beaucoup trop de projets ont blessé
au début parce qu’un élément technologique clé n’était pas pris en compte dans le projet global. Avec toutes les fintechs et les perturbateurs présents sur le marché aujourd'hui, tous s'efforceront de s'intégrer de manière transparente les uns aux autres, mais sans une compréhension complète.
of how vous voulez qu'ils se connectent et pour quelle raison, vous pouvez facilement vous retrouver à refaire votre modèle opérationnel cible à mi-chemin et devoir gaspiller tous les efforts et les ressources que vous avez dépensés jusqu'à présent. C'est comme essayer de construire un avion tout en
le faire voler ou changer le pneu de la voiture pendant que vous le conduisez. Les TOM typiques disposeront d'un système de type gestion de la relation client (CRM) que le personnel en contact avec le client pourra utiliser, se connectant à un système de gestion du cycle de vie du client intégrant un moteur de flux de travail et de règles.
transmettre les tâches nécessaires aux personnes concernées pour terminer la saisie des données/le téléchargement/la validation et la vérification des documents. Il peut exister un système de gestion des données de référence (MDM) qui est traité comme la source d'enregistrement/la copie dorée, mais il s'agit trop souvent d'un système cloisonné.
système de plusieurs magasins de données agrégées ou intégrées avec divers systèmes capables de mettre à jour les enregistrements. Il peut y avoir des systèmes de transactions/négociations/prêts avec des services de surveillance des transactions intégrés ou intégrés. Il peut y avoir des fournisseurs tiers pour les données/documents
ou à des fins d’actualités/actualités négatives/projection. Tout ou partie d’entre eux peuvent également être basés sur le cloud ou sur des systèmes sur site. Alors maintenant encore, je vous demande, avez-vous réfléchi à la place de cette nouvelle technologie dans votre TOM global et s'agit-il d'une version finale ou êtes-vous
l'intégrer dans la configuration actuelle mais prévoyez de changer cela à l'avenir

Pour tous vos systèmes actuels, combien de temps prévoyez-vous de les prendre en charge/de les conserver ?

Il existe une erreur courante connue sous le nom d’erreur du coût irrécupérable selon laquelle, simplement parce que vous avez dépensé X dollars/euros/livres pour un système, il est trop avancé pour admettre sa défaite et l’abandonner. Ou qu’il n’est pas cassé et ne nécessite donc pas de réparation. Ou que c'est trop ancré
dans les systèmes actuels pour pouvoir le supprimer ou le remplacer. Si tel est le cas, vous vous êtes probablement retrouvé avec un seul point de défaillance sans même vous en rendre compte. Les solutions technologiques modernes sont flexibles et doivent être conçues pour s’adapter au changement. Fusions/acquisitions antérieures
ou la fusion des systèmes a forcé l'intégration de la technologie et le processus habituel consiste simplement à la faire fonctionner. Celles-ci doivent être considérées comme des opportunités de reconsidérer la manière dont quelque chose est fait et de s’efforcer de parvenir à une manière plus efficace. Deuxième
à cela, la plupart des nouvelles technologies auront ou prétendront avoir des offres/modules/fonctionnalités similaires telles que le reporting, les tableaux de bord, le workflow, les moteurs de règles de gestion de cas, le studio de configuration. L'objectif est de toucher le public le plus large possible et a
certaines personnes se demandent « Pourquoi dois-je acheter X alors que Y a déjà cette capacité ? ». Mais dans cette optique, souhaitez-vous vraiment transformer votre CRM en un système de suivi des transactions ? Ou votre système de compte dans la passerelle de votre MDM ? Ou votre MDM comme principal
point de saisie des données. Vous savez que vous allez vous retrouver avec des milliers d’enregistrements avec des numéros de téléphone tels que 12345678.

Personnel/Rôles

Pour que toute mise en œuvre réussisse, vous aurez vos rôles définis des deux côtés du projet. Le vôtre et celui des vendeurs. Cela dépend évidemment du budget, de la portée et du calendrier. Vous pouvez avoir une mise en œuvre basée sur le cloud de 4 semaines qui nécessite 2 employés de
le fournisseur ou il pourrait s'agir de 10 phases de versions majeures de 12 semaines avec une approche agile des exigences de 2 semaines composée d'analystes métier/produit, de développeurs, d'experts en la matière, de testeurs d'assurance qualité, qui ont tous besoin de rôles juniors et seniors, de projets
des responsables pour chaque secteur d'activité/région/juridiction et un responsable de programme pour tout superviser. Ajoutez à cela un sponsor de projet et il est facile de comprendre pourquoi les logiciels d’entreprise deviennent chers, parfois de manière prohibitive. C'est également avant de considérer les niveaux de personnel
que vous devez allouer pour correspondre. N’oubliez pas que les membres de votre personnel impliqués dans ce projet seront absents de leurs tâches quotidiennes pendant une période considérable. Il est important de s’assurer que le personnel du fournisseur est expérimenté et n’a pas été
récemment embauché pour répondre à la demande de votre projet.

L'autre considération est le modèle de partenariat. De nombreux fournisseurs établis ont des partenaires certifiés, certaines entreprises boutique et certains des 4 grands, qui peuvent également être rédigés pour aider les implémentations, mais qui ont également un prix.

Migration de données

L’un des thèmes majeurs intégrant un nouveau logiciel est la prise en compte de l’accès aux données et/ou de la migration des données. Si le nouveau système interroge votre ou vos bases de données actuelles selon les besoins, quand aura-t-il accès, quels utilisateurs ont quelles autorisations
pour y accéder, l'accès est-il en lecture seule ou les utilisateurs peuvent-ils modifier ou créer de nouveaux enregistrements et lorsqu'ils mettent à jour l'enregistrement central, quels systèmes ont un ordre de priorité pour effectuer ces modifications ? Que se passe-t-il si un autre système tente d'effectuer une modification alors qu'un autre utilisateur
de votre nouvelle technologie est en train de l'éditer ? Cela signifie-t-il désormais que toutes les demandes de modification de données doivent être acheminées via cette nouvelle technologie ? Que se passe-t-il lorsque toutes les nouvelles technologies demandent le même ordre de priorité ? Ceux-ci concernent uniquement les systèmes d’enregistrement des clients actifs.
Et si on créait un nouveau système unique consolidé ? Devez-vous adopter l’approche big bang pour migrer toutes les données dès le premier jour ? Imaginez les risques. Qu'en est-il d'une période de transition, par exemple lorsqu'un examen est programmé, vous faites appel à une ou plusieurs sources pour effectuer l'examen ?
puis publiez l'enregistrement vierge dans la nouvelle base de données centrale. Cela permettrait plutôt une migration sur une période de 12 à 18 mois. Il ne s’agit pas d’une approche universelle. C’est tout avant de commencer à envisager de gérer les doublons.

Intégration

Lorsque vous envisagez d'ajouter une nouvelle technologie à votre écosystème, vous devez vous assurer qu'elle fonctionnera de manière transparente avec votre configuration actuelle. Il existe initialement 2 options, soit comme nouvel ajout net pour résoudre un problème spécifique, soit comme remplacement d'un système existant.
ou des systèmes en place. Quoi qu’il en soit, vous voulez vous assurer qu’il a accès aux systèmes pertinents dont il a besoin pour la consommation en amont et en aval. Vous devez également être sûr que toute la plomberie existante du système en cours de mise hors service peut être entretenue.
Il y a aussi la question des autorisations qui est systématiquement négligée. Contrôle d'accès des utilisateurs pour déterminer les autorisations dont disposent les utilisateurs pour la nouvelle technologie concernant les données auxquelles elle a accès, tout en garantissant qu'il n'y a aucune exigence d'autorisation d'administrateur.
Mais lorsque vous ajouterez une technologie plus récente à l’avenir, devrez-vous à ce stade affiner le contrôle d’accès pour tous les systèmes historiques ? Comme ci-dessus également, n'oublions pas la nécessité de déterminer quelle technologie a un ordre de priorité pour les modifications/mises à jour des données. Sinon
comment vous assurer que le système A effectue un changement aujourd'hui, que le système B l'inverse demain et que le système A réessaye le lendemain.

Accès au système – Politiques Infosec

Avez-vous engagé les équipes concernées en interne pour fournir des ressources et un accès aux systèmes pertinents en temps opportun ? Si vous prévoyez d'attendre le dernier moment avant de demander une autorisation pour un environnement ou un accès à une base de données, etc. Vous
vous constaterez peut-être que vos dates cibles sont soudainement irréalisables.

Acheteurs vs utilisateurs

Les utilisateurs finaux de la nouvelle technologie sont-ils impliqués dans le processus de décision ? Quel est l'intérêt de prendre une décision au nom des autres utilisateurs, si en fin de compte ils décident que ce qui est construit n'est pas adapté à leurs objectifs. La bataille entre les entreprises et
C'est un problème constant qui se produit partout et qui oscille en fonction de qui décide. Trop souvent, la conception du système est censée résoudre parfaitement chaque problème, pour chaque utilisateur. Suringénierie de la technologie pour résoudre à 100 %
est admirable mais en fin de compte, une entreprise gourmande en ressources. L'objectif initial devrait être de résoudre le problème pour la majorité et d'attendre la réussite avant de tenter les cas extrêmes. Ces derniers 20 ou 10 % des émissions ne devraient pas freiner l'objectif principal de l'acquisition.
la technologie, mais trop souvent elle devient épuisante. La question à vous poser est de savoir ce qui est définitivement requis le premier jour et de limiter vos options à un sous-ensemble car la réponse par défaut est toujours, toujours, tout.

Alors maintenant, lorsque nous examinons ce qu'il faut prendre en compte pour réussir la mise en œuvre d'un projet, nous devons réaliser qu'il y a d'autres éléments pertinents avant de commencer, qui doivent être inclus. Ceux-ci auront également un impact sur la décision concernant le logiciel à sélectionner lors de la première
lieu. Tout ce qui brille n'est pas d'or. Assurez-vous que ce que vous sélectionnez est adapté à toutes les considérations et pas uniquement à un seul résultat final attendu.