Comment puis-je communiquer les risques de modification du logiciel du fournisseur?

Nous avons un problème majeur où je travaille, et son nom est "personnalisation". Nous avons un ancien système logiciel de fournisseur (10 ans et plus) que nos services informatiques et comptables aimaient auparavant personnaliser. Quelque part le long de la ligne, ce logiciel a commencé à devenir très bogué. Ensuite, j'ai été embauché après la majeure partie de la personnalisation.

Presque tous les problèmes que j'ai rencontrés avec le système sont le résultat direct de la personnalisation; tout ce que nous changeons risque de briser les logiciels financiers critiques. Pourtant, le service de comptabilité continue de suggérer des changements (parce que nous avons toujours dit oui!) Et il semble y avoir peu de respect pour l'impact potentiel des changements.

Certains changements ne posent aucun problème; les formulaires peuvent être (et sont censés être) personnalisés dans le logiciel du fournisseur, nous pouvons déplacer les champs de formulaire, les supprimer, etc. Mais pour chaque personnalisation inoffensive comme celle-ci, ils suggèrent également des modifications telles que des procédures stockées et des déclencheurs pour manipuler les données dans la base de données pour l'application du fournisseur.

Je leur ai récemment (à peine) fait cesser d'essayer d'importer des clients d'un programme fournisseur dans un autre car les informations étaient complètement incompatibles. Mon problème avec la façon dont cela a été résolu est parce que j'ai trouvé que le système ne fonctionnait pas du côté utilisateur; la tâche était plus compliquée qu'ils ne le pensaient, alors ils ont abandonné. Quelle que soit la facilité de la tâche côté utilisateur, l'opération qu'ils souhaitaient n'aurait pas dû être effectuée.

Comment puis-je communiquer que le changement de fonctionnement de ce système comporte des risques, en particulier lorsque la validité des données est en jeu? Je suis un nouvel embauché (6 mois) et c'est devenu le statu quo, mais cela met en péril la validité de nos données financières et de nos contrats de support - une fois que le support du vendeur entend "X a été personnalisé", ce qui leur donne beaucoup de raisons de ne pas pour nous soutenir ou nous dire que c'est de notre faute.

Le risque / récompense de la personnalisation des systèmes est de fournir un avantage concurrentiel qui permet à votre entreprise d'offrir quelque chose différemment des autres entreprises de votre espace.

Les grandes organisations avec lesquelles j'ai travaillé tirent un avantage concurrentiel de la personnalisation et, dans cet état d'esprit, elles leur permettent de faire les choses plus efficacement, de fournir plus de fonctionnalités ou de gagner plus d'argent.

Le fait que je communique dans ces situations est que c'est un compromis. En apportant ces changements à un système, l'organisation développe sa propre base de connaissances / expertise interne de ses systèmes qu'elle ne pourra pas facilement utiliser sans. Cette base de connaissances interne doit être mieux entretenue et organisée afin que ces changements puissent être suivis et gérés. Cela signifie également qu'il pourrait invalider les contrats de support des fournisseurs et d'autres aspects que les actifs informatiques que l'entreprise utilise pour ce processus.

Le plus grand risque dont je parle est la mise à niveau des versions des logiciels des fournisseurs lorsqu'une entreprise adopte cette philosophie de gestion des données. C'est l'un des risques les plus probables où quelque chose va se casser. L'entreprise doit comprendre les compromis qui sont faits et tout le monde doit être à bord avec le processus qu'il faut pour les soutenir.

Pour votre culture, vous pouvez introduire une analogie ou une philosophie, mais vous avez besoin que quelqu'un qui est responsable de l'entreprise se rende compte qu'il crée un environnement qui a encore plus de dépendances d'un spécialiste commercial interne qui apporte des modifications à ces systèmes.

Pour l'analogie avec la voiture, ce n'est pas le mécanicien qui a besoin de savoir quels changements sont apportés à une voiture, c'est le propriétaire qui doit comprendre qu'il peut prendre des mécaniciens spéciaux, plus d'argent ou la perte de ce service pendant une période de temps. Éduquer le propriétaire est la clé de cette conversation.

Communiquer avec les habitants des bureaux? J'irais avec des analogies.

Dites-leur que tous ces changements transforment votre berline domestique 4 portes typique en une voiture étrangère exotique. Chaque fois que vous l'amenez dans l'atelier de mécanique, de la mise au point, à la lumière écrasée, à la révision de la transmission, cela va coûter plus cher. "Nous n'avons pas les pièces, seul le concessionnaire ayant des connaissances particulières peut y toucher, nous avons essayé mais le manuel est en allemand".

Vous êtes le mécanicien chargé de le faire fonctionner. La base de données est le moteur. Tout le système est la voiture. Les comptables conduisent la voiture. Le mignon petit lapin que les comptables ont hésité à manquer est un tréma au nom de famille d'un nouveau client. Le poteau lumineux autour duquel ils ont enveloppé leur voiture est le bug critique qui a été introduit lorsqu'ils voulaient ajouter une boule disco à l'intérieur de la voiture.

D'autres ont fourni de bons exemples d'utilisation d'analogies et d'autres langages pour répondre à votre question principale, qui était "Comment puis-je communiquer que le changement de fonctionnement de ce système comporte des risques, en particulier lorsque la validité des données est en jeu?"

Mais sur la base de votre commentaire clarifiant sur la façon dont la tâche vous parvient, je ne suis pas sûr que toute analogie va vous aider dans la situation - il ne semble pas vraiment que les gens comprennent mal ce qu'ils demandent, mais plutôt qu'ils ne s'en soucient pas. J'ai été là - nous avons probablement tous été là - et dans ces situations, j'ai tendance à faire plus d'efforts pour être parfaitement clair sur les questions, plutôt que de les formuler en termes destinés à enseigner plutôt qu'à avertir .

Concentrez-vous sur ce que vous pouvez faire, ce qui ne change pas à lui seul l'esprit de tous ceux qui demandent des personnalisations qui mettent en péril l'intégrité des données et les contrats de support des fournisseurs, mais parle plutôt directement à votre CTO (et à son tour, le directeur financier) et est très clair quant aux problèmes à résoudre.

Plus précisément:

• Demandez à votre CTO ou CFO (ou à quiconque le détient) de voir le contrat de service avec le fournisseur, car (et je dirais ces mots) on vous demande d'effectuer des tâches qui sont potentiellement en violation de l'accord et que vous souhaitez être en mesure de le souligner dans votre rapport de faisabilité de la tâche. Ils ne vous le donneront peut-être pas, mais le fait de dire ces mots a souvent fait comprendre aux gens de ces postes que vous êtes sérieux et que la situation est potentiellement grave.

• Si vous faites obtenir une copie de l'accord, lorsque vous rédigez votre rapport de faisabilité de la tâche, citer directement quand il y a une violation flagrante.

• Si vous n'obtenez pas de copie de l'accord, faites clairement vos réserves quant à la façon dont le changement pourrait mettre l'entreprise en mauvaise position en ce qui concerne la relation avec le vendeur.

• Si votre problème n'est pas problématique en raison de l'accord avec le fournisseur mais est "simplement" problématique en raison des effets en cascade du changement, expliquez ce que cela signifie: si c'est aussi compliqué que vous le dites, alors vous n'en avez probablement qu'un ou deux des puces avant de pouvoir utiliser la ligne "et il s'écroulera comme un château de cartes".

En bref, faites ce que vous pouvez pour souligner très clairement et de manière concise le problème et ses effets, même un pas ou deux plus tard. Que vous ayez déjà la possibilité de présenter un rapport de faisabilité aux décideurs est une bonne chose; vous n'avez pas la structure ou le support de gestion (ou éthos) pour dire "j'ai besoin que vous signiez ceci en disant que vous comprenez que c'est une mauvaise chose et je ne le recommande pas et je ne vais pas être responsable des effets de cela" mauvaise décision "(comme vous le feriez si vous étiez un vendeur et un client), mais vous pouvez toujours mettre beaucoup de choses sur papier qui montrent que vous considérez ce qui est dans le meilleur intérêt de l'entreprise et de ses actifs.

S'ils vous demandent d'implémenter des procédures stockées et des déclencheurs, vous avez un problème de processus métier majeur.

Votre plus grand défi est d'amener les utilisateurs ici à changer leur façon de penser. Ils doivent vous fournir le problème ou l'exigence. Par exemple, nous avons besoin que les données se déplacent d' ici à ici .

Ce devrait être vous qui implémentez la solution avec le moins de risques / le plus de gains, et c'est vous qui pouvez le faire d'une manière qui aidera à prévenir les problèmes de développement futurs.

Un certain contrôle sous la forme d'une approbation de l'utilisateur ou d'exigences, puis la signature du développement livré seront également utiles. Si l'utilisateur doit assumer une certaine responsabilité pour ce qu'il demande, il peut y réfléchir un peu plus.

Vous semblez sous-entendre que votre choix se situe entre une mise en œuvre risquée d'une exigence commerciale ou aucune. C'est rarement aussi noir et blanc. J'ai du mal à croire que les comptables demandent directement des procédures stockées, mais s'ils le sont, vous devez leur donner ce qu'ils signifient au lieu de ce qu'ils demandent. Découvrez quelle est l'exigence métier, puis trouvez la manière la moins risquée de la mettre en œuvre.

Si votre fournisseur ne fournit pas les crochets dont vous avez besoin pour implémenter en toute sécurité les exigences souhaitées par vos utilisateurs, ce problème vient du fournisseur, pas de vos utilisateurs.

Vous développez essentiellement des logiciels et vous avez donc besoin d'une méthodologie de développement. Comment les changements sont-ils documentés? Testé? Déployé en QA? Déployé en production? etc. Je pense que si vous commencez à proposer une méthodologie et les coûts qui y sont associés, ils commenceront à comprendre. Peut-être que les coûts sont bien justifiés et qu'il vous suffit de mettre en œuvre une procédure pour que la voiture ne s'enroule jamais autour d'un poteau lumineux.