Comment conciliez-vous les changements de processus métiers avec les défis posés par l'évolution des logiciels?

Question

Au cours de ma carrière certes jeune, je me suis retrouvé à écrire un code qui prenne en charge des règles et des processus métier insolites. Inévitablement, ces changements ont toujours été dans une base de code extrêmement difficile et ont causé de nombreux problèmes. Ma question comporte deux parties:

1. Alors que les logiciels sont un outil permettant aux entreprises de simplifier la vie, à quel moment, en tant que développeurs, suggérons-t-il un changement de processus commercial plutôt que le logiciel, considéré comme la "solution miracle"? pour résoudre un problème particulier.

2. Comment les développeurs évangélisent-ils un certain respect pour le logiciel, ainsi que la difficulté d’apporter des modifications simplement pour répondre aux bizarreries de l’entreprise?

Je comprends que ces changements dans les processus commerciaux favorisent notre industrie, mais mon père comprendrait par analogie: ce qui est plus facile, faire fondre un marteau pour forger un tournevis pour enfoncer des vis ou simplement utiliser des clous puisque votre marteau est déjà en marche. génial ...?

Answer 1

Vous pouvez regarder

  

Sept habitudes de très efficace   Les gens

, car vous avez l’impression que vous devez développer une sphère d’influence suffisamment large pour pouvoir modifier les processus opérationnels.

Votre meilleur choix est de montrer que vous êtes très compétent dans votre travail et que vous développez des relations avec les gens d’affaires, afin que vous puissiez vous sentir à l’aise en dehors du travail pour discuter du processus d’affaires en question.

Le processus est lent, mais si vous essayez de vous dépêcher trop vite, votre entreprise va reculer et vous écraser comme un bogue. Si vous lisez

  

L'âge des hérétiques

Par exemple, vous verrez des exemples d’entreprises qui ont trop bien réussi à apporter des changements et l’entreprise les a détruites.

Pour le moment, la meilleure solution consiste à apporter des modifications, comme vous pouvez le faire, pour que le logiciel soit plus adaptable, afin que, si le processus change, vous puissiez facilement vous adapter aux nouvelles règles.

Answer 2

Avant de pouvoir faire quoi que ce soit, vous feriez mieux de prendre du recul et d'essayer de comprendre l'entreprise. S'ils réagissent au changement en adaptant leurs processus, c'est une bonne chose. C'est quand ils laissent les choses exactement la même chose pendant des années que vous pouvez oublier qu'ils restent une entreprise. Cependant, vous devez vous assurer que le changement auquel vous répondez n'aura pas d'impact négatif sur les processus métier en amont ou en aval. Les unités commerciales ne font pas souvent cette vérification. Mais, quand tout ira en enfer, vous savez à qui ils vont s'en prendre, n'est-ce pas? En faisant cela, vous pouvez éviter ces problèmes et évangéliser, "de meilleures façons". Ne pas le faire est une prescription pour la frustration éternelle.

Apprenez leur métier avant même de penser à le codifier.

En ce qui concerne les mécaniciens: Ce que j’ai toujours demandé à mes équipes d’écrire, c’est le "logiciel générique". Certaines unités commerciales auraient peut-être besoin d'un moyen de capturer un formulaire et de générer un rapport. Ok, assez facile, non? Faux. Considérez toujours une demande comme quelque chose * 200. Souhaitez-vous prendre en charge 200 de ces applications, toutes presque la même chose? Pas moi. Trop paresseux.

J'ai demandé à mes équipes de créer un système de formulaire générique et d'utiliser des mécanismes de génération de rapports génériques et autonomes. Et j'ai insisté sur l'utilisation de XML / XSLT autant que possible (sans compter, par exemple, sur les technologies de four à cuisson facile de Microsoft qui semblent rompre avec chaque nouvelle version). Ensuite, quand une autre unité commerciale voulait "quelque chose de similaire, mais avec des modifications", le noyau était déjà là - nous avions seulement besoin d'un nouveau dossier, XML / XSLT modifié et nous avions terminé.

Cela a toujours - TOUJOURS - facilité la gestion de ces modifications futures. "Besoin d'un nouveau champ?" Changer un fichier XML. Besoin de changer la façon dont un rapport est produit? Changer XSLT. Aucun changement de programme. & Quot; Trouver? AUCUN changement de programme. Gardez autant que vous le pouvez en dehors de la logique. Même les processus d’entreprise peuvent être représentés au format XML / XSLT.

En réalité, la plupart des applications que vous rencontrerez sont les mêmes roues de programmation (un bon livre d’algorithmes, en passant) qui ont été conçues pour toujours. Ils seront simplement moins bien traités par des personnes qui ne comprenaient pas le métier et comprenaient encore moins leur métier.

Ils ne vont pas créer leur entreprise autour de vous ou de votre logiciel, sauf si vous écrivez MS DOS pour la première fois. À la seconde où vous le suggérez, vous serez parti. Et ... tu devrais être.

Answer 3

L’une des choses les plus frustrantes que tout client final (c’est-à-dire un client de votre employeur ou de votre client) peut entendre est que "l’ordinateur ne me permet pas de le faire". Dites, ajoutez des articles à une commande après le calcul de l'expédition, ou annulez quelque chose avant que la taxe de vente ait été calculée, ou autre chose. Le logiciel devrait servir l'entreprise. Bien sûr, cela signifie que le logiciel doit beaucoup changer, et parfois, il change tellement de l'endroit où il était que vous devez recommencer. Au fur et à mesure que vous gagnerez en expérience, vous écrirez un logiciel plus facile à modifier, compte tenu de la réalité indéfinissable selon laquelle les processus métier changent, les lois, les codes de taxe, les clients, etc. Un jour, vous pourrez devenir un conseiller d’affaires de confiance auprès de vos clients. C'est inhabituel au début de votre carrière. Je suis dans cette phase maintenant mais je suis dans ma quatrième décennie d'être payé pour programmer. Je suggère rarement que l'entreprise héberge le logiciel. Il faut beaucoup de jugement pour savoir quand cela pourrait être la bonne chose à suggérer. Et quel que soit le respect que vous ressentez pour votre logiciel, faites de votre mieux pour le cacher aux personnes qui le paient. Ils le voient comme un outil pour soutenir la vraie entreprise dans laquelle ils se trouvent.

Answer 4

Je pense qu’il est utile de remettre en question le rapport coût-efficacité de la création de nouvelles solutions pour s’adapter aux processus métier existants, par opposition à une adaptation des processus métiers aux solutions existantes. Cependant, en réalité, je n'ai pas vu l'entreprise considérer cet angle.

Dans cet esprit, je pense que la meilleure chose à faire est d’anticiper les changements spécifiques que l’entreprise pourrait demander à l’avenir et de développer votre solution de manière à ce qu’elle puisse s’adapter facilement à ces changements.

Answer 5

Malheureusement, cela dépend entièrement de la situation.

Même avec beaucoup d'expérience dans les affaires ET les logiciels, le problème reste complexe.

En ce qui concerne vos questions spécifiques:

1. Dès que vous les voyez. L'important est de formuler votre suggestion de manière constructive. Également en utilisant des termes pertinents pour l'entreprise (ROI, NPV, etc.). Et trouver des avantages accessoires (). Par conséquent, si le changement de logiciel n'atténue vraiment pas le problème de l'entreprise, le coût est élevé et si la résolution du processus de gestion génère d'importantes économies de coûts auxiliaires, vous créez un scénario complètement différent du simple fait de dire "nous ne pouvons pas le faire car cela coûte trop beaucoup ".

2. Le logiciel appartient à l'entreprise. Vous ne lui devez pas plus de respect que tout ce que l'entreprise possède d'une valeur similaire.

Answer 6

• Si vous êtes confronté à une complexité croissante des règles de gestion en rapport avec la forme actuelle du logiciel, essayez de Aspect -Oriented-Software-Development , afin d’améliorer la modularité et la séparation des préoccupations. De cette manière, les règles commerciales nouvelles ou en évolution, telles qu'elles apparaissent, peuvent être intégrées à votre base de code existante en tant que plug-ins destinés uniquement aux modules qui en ont besoin, sans qu'il soit nécessaire de réécrire de grandes quantités de code non lié.
• L'idée est qu'après tout, bon nombre de règles métier découlent de législations spécifiques et que c'est la responsabilité de l'entreprise, transmise au logiciel également, de les mettre en œuvre et de les adapter. Personnellement, j’estime que c’est le manque de volonté de respecter les spécifications en raison de la difficulté perçue qui a conduit la plupart des navigateurs Web à prendre du retard par rapport aux normes Web. Les particularités de chaque navigateur. Essayez d'implémenter les nouvelles règles aussi rapidement qu'elles apparaissent ou qu'elles changent. Si vous ne le faites pas, le manque de prise en charge de nouvelles fonctionnalités s'accumule et vous rendez le logiciel obsolète.

Answer 7

Cela ressemble un peu au rôle / à la force du DSI. Si le service informatique parvient à convaincre les entreprises qu'il serait plus simple, moins coûteux et moins coûteux de modifier le processus métier que le code, vous avez un point. Sinon, les pratiques commerciales originales pourraient être plus utiles que vous ne le pensez. Je doute également que vous expliquiez clairement que si vous passez du temps à résoudre le problème insolite, vous ne délivrerez pas les fonctionnalités nécessaires à temps (bonne chance avec cela).

Si les technologues avaient réussi, l'interface graphique utilisateur et le pointeur / souris ne seraient jamais sortis du laboratoire. Pour les utilisateurs quotidiens, ils sont là pour rester.