Les grandes entreprises ont généralement le problème suivant: il n’est pas possible d’écrire tous les programmes souhaités par les employés (pour gagner du temps et optimiser les processus) en raison du manque de personnel et d’argent.

Ensuite, des programmes cachés seront créés par certaines personnes ayant au moins une expérience en codage (ou par des étudiants / stagiaires peu coûteux ...). Dans certaines circonstances, ces applications vont gagner en importance et se propager d'un utilisateur à un département entier.

Ensuite, il y a le point critique: qui va maintenir l'application, ajouter de nouvelles fonctionnalités, ...? Et cette application est critique. C'est nécessaire. Mais le stagiaire a quitté l'entreprise. Personne ne sait comment ça marche. Vous avez seulement un tas de sources et une sorte de documentation.

Est-il judicieux d'essayer de contrôler ou d'interdire le développement d'applications effectué de manière ad hoc en dehors du service informatique (à l'exception de choses mineures telles que les macros Excel)?

Auparavant, je travaillais pour une entreprise où chaque application que nous leur fournissions conduisait à la question suivante: pouvons-nous exporter ces données vers Excel?

Après un certain temps, j'ai décidé que je devais savoir pourquoi ils étaient obsédés par les exportations Excel pour tout. Il s'est avéré que de nombreux ministères avaient une personne qui était un expert d'Excel et pouvait écrire une application d'analyse de données utile en un rien de temps. Ces applications se répandraient dans le département comme une traînée de poudre et nous, les techniciens, n'avions aucune idée de leur existence.

Pourquoi ne sont-ils pas venus nous voir en premier? Parce qu'il y avait une réputation que l'équipe technique avait beaucoup trop à faire et, si elle le demandait, elle pourrait (si elle avait de la chance) se faire faire la queue six mois plus tard.

Ce n’était pas une accusation injuste et ils ne nous ont jamais demandé de prendre en charge leurs applications Excel. Personne ne pensait donc que c’était un problème. Quand ces développeurs Excel sont partis, ils ont toujours réussi à trouver quelqu'un d'autre pour le récupérer.

Vous pourriez prétendre que cela signifiait que nous n'étions pas en train d'établir les priorités, que d'importants travaux n'étaient pas effectués. Mais je dirais que cela a libéré les développeurs les mieux payés pour effectuer un travail plus difficile. Que peut-il faire mal?

Maintenant, je voudrais interdire les logiciels qui mettent à jour la base de données en cours d’écriture en dehors de l’équipe de développement. Et je refuserais de prendre en charge les applications écrites en dehors de l'équipe de développement. Mais je n'essaierais pas d'empêcher tous les logiciels d'être écrits par l'entreprise elle-même, et j'écrirais volontiers des exportations de données pour leur permettre de le faire (tant que cela n'expose pas des données qu'ils ne devraient pas voir, évidemment ).

Je pense que les gens manquent le point général ici:

Si vous n'aimez pas tout le développement personnalisé en cours, l'interdire, c'est résoudre le mauvais problème. Vous devriez plutôt vous demander pourquoi ils tournent autour de l'informatique, et pas seulement leur dire que ce n'est pas permis. N'oubliez pas que vous (les TI) avez pour but de les aider à mieux faire leur travail et que les gens n'utilisent pas de logiciels parce qu'ils sont cool, ordonnés ou nouveaux, ils l'utilisent parce qu'ils résolvent un problème qu'ils ont eux-mêmes.

Pourquoi ces applications sont-elles créées en premier lieu?

Dans tous les cas que j'ai vus, il y a une raison commune:

Les groupes d’entreprises accordent plus de priorité à leurs propres besoins que ces derniers ne sont prioritaires dans l’ensemble de la société

Le marketing étant uniquement responsable du marketing, les initiatives qui profitent à leurs objectifs leur paraissent essentielles, tout en étant considérées comme fluff pour d'autres groupes, et ont tendance à être moins prioritaires lorsqu'il s'agit de ressources limitées telles que l'informatique. La hiérarchisation des priorités n'entre en jeu que lorsqu'ils souhaitent utiliser une ressource partagée - s'ils conservent le projet entièrement dans leur propre département, seul le chef de département doit se préoccuper du budget et du calendrier.

Il n'y a aucune raison que j'interdise ce type de développement, car cela allège les contraintes sur les ressources partagées (principalement l'informatique) et permet à chaque groupe de s'autonomiser pour résoudre ses propres problèmes (comme les utilisateurs expérimentés d'Excel avancé sont assez courants, comme il s’agit d’un problème courant, la plupart des départements en ont au moins un).

Cependant, vous ne pouvez pas vous attendre à résoudre les problèmes liés à ces applications, ni à les aider après le départ du développeur d'origine. Comme le mentionne un autre posté, cela n’empêche pas le grand patron d’exiger que vous le souteniez, mais si vous gardez une idée du type d’applications ou de processus personnalisés, vous pouvez avoir une idée de ce qui devient critique et vous pourrait avoir besoin de s'impliquer pour l'amener "en interne". De plus, si quelque chose se connecte et modifie des systèmes sous contrôle informatique, alors le service informatique devrait être impliqué, ne serait-ce que pour assurer la sécurité et l'intégrité de leurs systèmes centraux. Cependant, si c'est quelque chose qui se limite au bureau d'un utilisateur, pourquoi en ressentir le besoin l'interdire?

Mais voici une chose à retenir: chaque application personnalisée développée en dehors du service informatique correspond à un besoin auquel le service informatique ne répond pas . Il peut y avoir une bonne raison pour laquelle ils ne sont pas respectés - pas une priorité dans l'entreprise, un problème très spécialisé, pas aussi performant que d'autres options, langage personnalisé que vos informaticiens ne connaissent pas, etc. - et le manque d'implication de l'informatique peut être légitime, mais ces solutions ont été créées parce que certains départements avaient un besoin que le service informatique ne pouvait pas (ou ne voulait pas) satisfaire.

Essayez de les aider à résoudre leurs problèmes, et si vous n'avez ni le temps ni les ressources, laissez-les résoudre eux-mêmes. Rendre obligatoire une langue nécessitant une courbe d'apprentissage abrupte, dans le seul but d'empêcher les gens de rester en contact avec votre entreprise, ne sert qu'à renforcer l'attitude élitiste que la plupart des utilisateurs estiment que l'informatique a plus du même problème, car les utilisateurs ont peur d’approcher le service informatique et sont convaincus que celui-ci ne comprend pas leurs besoins ou leurs désirs. Ouvrez la relation - comprendre ce dont ils ont besoin est le seul moyen de les empêcher de vous entourer.

Il convient également de prendre en compte le cas des entreprises dans lesquelles le service informatique contient des personnes incompétentes, alors que l'application cachée serait créée par un développeur habile qui a un emploi non développeur dans l'entreprise. D'après mon expérience, ces cas sont extrêmement fréquents.

Imaginez que vous ayez le double profil d’un développeur de logiciels et d’un comptable. Vous êtes embauché en tant que comptable parce que vous avez eu l'occasion d'obtenir un emploi bien rémunéré. Vous voyez rapidement que vos collègues (et maintenant vous) passent des heures à faire des choses répétitives, ce qui peut être fait en quelques secondes par un programme.

Vous passez quelques soirées à écrire l'application qui fera tout le travail. Vous le montrez à vos collègues sur votre ordinateur portable personnel et ils le trouvent très utile. Vous souhaitez l'installer sur les PC de l'entreprise, mais vous devez avoir l'accord du service informatique. Vous le demandez, mais ils le rejettent car ils ne soutiendraient pas votre demande.

Cela ne semble-t-il pas stupide?

A part ce cas particulier, la question avec le soutien n'est pas très différent de nombreuses entreprises une rencontre avec tous  les logiciels, même un écrit dans le service informatique: si le service informatique n'applique pas les meilleures pratiques, le code sera mal / non documenté, écrit par des personnes inexpérimentées qui ne se soucient pas de la maintenance et qui sont parties depuis des années.

Pour conclure, la question principale est la rentabilité . Si vous, le service informatique, êtes invité à maintenir une application développée par un employé qui ne comprend pas les règles les plus élémentaires du développement logiciel, peu importe si cette tâche est agréable, vous devez le faire si elle apporte beaucoup d'argent à l'entreprise . Ou vous réécrivez à partir de zéro si c'est le moyen le moins coûteux de faire avancer les choses.

Vous ne pouvez pas le contrôler complètement ...

Je dirais que vous ne pouvez jamais le contrôler COMPLÈTEMENT, car les employés auront toujours les moyens de produire un code non autorisé et de le diffuser par d'autres moyens. Il n’est donc pas très utile d’être obsédé par cela, une fois que vous avez rédigé et appliqué quelques règles et processus de base, et mis en place quelques outils.

L’idée est que vous rendiez le plus attrayant possible le respect de ces règles et l’utilisation de ces outils, plutôt que de rendre tellement impossible de faire de nouvelles choses sans produire quoi que ce soit.

Mais vous pouvez créer un environnement convivial

De nombreuses entreprises, souvent très grandes, le font. Un bon exemple est Google, pour lequel des représentants ont déclaré utiliser un seul SCM pour toute l'entreprise, afin que tout le monde puisse contrôler et consulter le code des autres.

Je vous recommande de faire ce qui suit:

• donner au public un accès à certaines zones de votre SCM,
• faciliter la demande d'accès à des serveurs d'intégration et d'inspections continues,
• encourager les gens à créer des emplois de construction pour leurs outils.

Le problème est alors la prolifération des technologies. Évidemment, certains préféreront utiliser X plutôt que Y et c’est à ce moment qu’il devient plus difficile de les adapter à votre architecture. Cependant, ce n'est pas impossible, et s'ils veulent que leur code soit maintenu, ils auront probablement un kilomètre supplémentaire si, eh bien, c'est juste un kilomètre.

Vous pouvez également adopter une position plus arbitraire et décider que seules les langues L et Stack S sont autorisées, mais vous obtiendrez alors des informations indésirables, alors je vous recommande de les élargir un peu. Certains systèmes CI feront des merveilles avec quelques plugins si vos employés sont prêts à écrire un peu de code collé ou des scripts de configuration pour les intégrer.

Donne de la liberté aux équipes

Il est important de laisser aux équipes un peu de liberté et d’entamer de nouveaux projets avec des projets expérimentaux. Cela les maintient sur leurs gardes et vous oblige à considérer ces technologies plutôt à rester bloqué pour toujours jusqu'à ce que cela vous cause des problèmes.

Assurez-vous donc qu’ils ont la possibilité d’installer leurs propres systèmes pour tester leurs projets. Assurez-vous toutefois qu’ils prennent l’habitude de s’adresser à l’informatique à ce sujet.

Parlez aux TI, impliquez-les

Il est bien préférable que vos employés développent le réflexe consistant à envoyer une demande par courrier électronique au service informatique et leur demandent s'ils peuvent configurer quelque chose pour eux et les adapter. La plupart du temps, ils seront refusés, mais au moins, il y aura une certaine notion de contrôle et de qui devrait être en charge, ce qui donne une certaine visibilité aux demandes des différentes équipes.

Une fois que les projets ont atteint une masse plus critique, vous pouvez demander à nouveau et les réexaminer. La communication est essentielle et vous devez faire travailler vos équipes de développeurs, de consultants, de personnel de support informatique ou de toute personne travaillant avec du code. Aucun d'entre eux ne veut de programmes errants, c'est donc dans l'intérêt de tous. Il est beaucoup plus facile d'appliquer des règles s'ils les sauvegardent eux-mêmes.

Vous ne pouvez pas arrêter ces applications "cachées", car elles sont conçues pour résoudre des problèmes commerciaux réels. Tout ce que vous pouvez faire est de les aider à le faire "correctement". Et par "juste", je veux dire que nous devons faire en sorte que les applications puissent être maintenues après le départ de la personne qui les a lancées. Je recommande d'utiliser le langage suggéré dans Up ou Out : j'ai besoin que vous documentiez ce processus en détail afin que tout yahoo puisse le comprendre un an après votre départ. Aide à configurer le contrôle de version (et à leur montrer comment l'utiliser), un wiki (pour conserver des notes informelles sur la manière dont le travail est effectué) et un système de suivi des bogues simple. Si vous voulez rendre les choses vraiment simples, configurez l'intégration continue sur un serveur de réserve (si vous en avez un).

Vous constaterez l'énorme désir d'intégration Excel (ou du moins d'importation / exportation), car toutes les écoles de commerce enseignent maintenant Excel et c'est un outil majeur utilisé dans de nombreux cours de commerce.

Les lois Sarbanes-Oxley et autres législations étrangères autres que les États-Unis, associées aux lois sur la protection de la vie privée et aux processus et politiques de confidentialité et de sécurité auto-imposés en interne, constituent le "marteau" qui peut et est souvent utilisé pour lutter contre le phénomène de l'informatique fantôme.

Dès que des informations personnellement identifiables du client ou de l'employé (ou des données que vous ne souhaitez pas divulguer) commencent à circuler dans ces feuilles de calcul, un accident vous attend.

De la même manière, dès que l'un de ces projets informatiques skunkworks utilise ce tableur Excel et l'utilise comme données derrière une application Web externe piratée, votre DSI et votre PDG font irruption au bureau de quiconque a créé cette application. un week-end venant expliquer les conséquences.

Et puis, il y a le problème qui se pose: lorsque vous examinez ces efforts multipliés par des centaines (ou des milliers) de services dans une entreprise Fortune 500, vous constatez rapidement que votre entreprise possède plus de 100 bases de données «maîtres» clients. Vos clients commencent à se plaindre d’avoir mis à jour leurs informations de contact à un endroit mais il est toujours obsolète dans 10 autres, ou de ne pas savoir combien vous faites avec vos grands partenaires car les informations sont réparties sur 10 Bases de données informatiques.

Tout cela engendre des processus de conformité et d'audit onéreux qui ne plaisent à personne, mais qui constituent l'essentiel de la vie des TI dans un environnement d'entreprise.

Une bonne stratégie consiste à examiner tous les départements concernés et à plaider en faveur du transfert de leur investissement dans l'informatique fantôme vers l'informatique proprement dite, en faisant valoir que l'informatique peut permettre de réaliser des économies d'échelle et de réaliser ce travail plus efficacement que l'actuel. modèle skunkworks distribué ad hoc. Cela peut être difficile à vendre dans un environnement où les contraintes budgétaires informatiques et la rapidité de livraison ont donné naissance à skunkworks en premier lieu, mais combiné aux risques d'audit / fiduciaire, il peut donner un bon coup d'un coup.

La décision de rédiger une nouvelle application est souvent basée sur une analyse coûts-avantages de la demande; ainsi que la valeur globale pour l'entreprise. Tout en prenant en compte de nombreux autres facteurs, tels que les ressources informatiques disponibles, la portée de la demande, les objectifs commerciaux et la direction, pour n'en nommer que quelques-uns. Souvent, une demande de service spécifique est refusée parce que le responsable / directeur de service n'a pas réussi à montrer un retour sur investissement raisonnable ou ne suit tout simplement pas le processus établi.

Quelle que soit la raison, le «département informatique» est souvent le bouc émissaire, même si la décision était hors de leur contrôle. Ainsi, même si le refus de la demande peut ne pas nuire au service informatique, la perception est souvent tout à fait différente.

Malgré cela, vous trouverez des applications malveillantes dans presque toutes les entreprises du monde. Certains, bien écrits et d’autres, contiennent du code qui n’aurait jamais dû voir le jour.

Bien que nous devions faire tout ce qui est raisonnablement possible pour répondre aux besoins de nos clients internes, nous ne pouvons tout simplement pas le faire. Quand cela se produira, ils chercheront ailleurs pour résoudre leur problème.

Si le groupe informatique est activement impliqué dans le projet, nous pouvons exiger le respect de nos normes, aider le consultant à suivre les directives internes de codage et à comprendre les interactions des applications avec nos systèmes et leurs exigences (base de données, réseau, pare-feu,…). Sans cette implication, nous serons pris au dépourvu et passerons beaucoup de temps à essayer de comprendre pourquoi nos systèmes de production ne respectent pas les niveaux de service.

Que le service informatique les tolère et les soutienne ou non, ils peuvent et auront un impact direct en termes de prise en charge, d'engagements en matière de support, de contrat de licence et de contrats de niveau de service, que tout service informatique est évalué.

Ils sont interdits dans notre société pour ces raisons:

• Macros Excel protégées par mot de passe lorsque la seule personne connaissant le mot de passe a quitté l'entreprise,
• Etre tenu responsable des rapports incorrects rédigés par des personnes inexpérimentées car c'est l'informatique '
• Être invité à modifier un rapport que nous n'avons jamais vu ou entendu parler auparavant.

Je comprends que cela peut être frustrant pour les utilisateurs lorsque le service informatique est occupé, et ils peuvent être enclins à «faire le travail eux-mêmes». Mais le service informatique ne peut pas être tenu pour responsable des choses dont il n'a pas connaissance n'existent même pas, et si personne n'est responsable de l'ensemble du système informatique, de gros problèmes se posent.

S'il y a un problème ici, c'est avec le service informatique.

Il n’ya rien de mal à permettre à des personnes ayant des connaissances spécialisées dans le domaine / entreprise de manipuler et de traiter leurs propres données.

Le service informatique doit en prendre conscience et le soutenir. En fournissant des interfaces réutilisables, en fournissant des données dans des formats pratiques tels que les bases de données EXCEL ou Access, et en fournissant des outils flexibles (COGNOS, Jasper Reports, etc.).

Le service informatique doit également repenser ses priorités - il est là pour servir l'entreprise, et non pour mettre en œuvre la méthodologie la plus récente, ou installer le matériel le plus sexy.

Beaucoup de sociétés ou de départements de sociétés sont frustrés par le fait que leurs services informatiques les gênent et les empêchent de faire leur travail ou de faire de nouvelles choses. Cela conduit les départements, qui se sentent comme retenus par les stratégies informatiques, à tenter de résoudre leurs propres problèmes. La communication est la clé. Si les départements travaillent autour de l'informatique, vous avez réellement un problème informatique. IT ne peut pas se permettre d'être vu comme un ennemi. Les entreprises, et en particulier les services informatiques, doivent prendre conscience de la nécessité de travailler ensemble plutôt que de s'affronter. Si les départements communiquent avec leur personnel informatique (en particulier ceux qui devraient être supervisés) et leur disent leurs besoins et comment ils s’efforcent de résoudre leurs propres problèmes, Au moins, l'informatique aura l'option d'aider à résoudre les problèmes au lieu de savoir après coup quand une crise se produira. Gardez l'informatique au courant.

Il existe presque toujours un besoin valable pour ces outils spéciaux, qu’ils soient des applications ou des feuilles de calcul. Un service informatique a deux choix. Ils peuvent être des facilitateurs ou des handicapés. D'après mon expérience, les personnes handicapées perdent parce qu'elles entravent des besoins commerciaux valables et deviennent un ennemi commun. Les catalyseurs, en revanche, aident réellement une entreprise.

Cela ne signifie pas que le développement financé par les ministères devrait être laissé libre. Certaines exigences doivent être appliquées, telles que:

• Tout le code doit être régulièrement engagé dans un système de contrôle de version exécuté par le service informatique. Le service informatique devrait créer librement des comptes et des répertoires pour rendre cela possible. Le service informatique peut même vouloir donner des instructions.
• Tout ce qui implique des informations d'identification personnelle (PII), une authentification, une autorisation, une cryptographie, des données protégées par la loi ou des données jugées critiques par l'entreprise doit être approuvé par un consultant informatique. Le service informatique / le consultant doit fournir une assistance, des bibliothèques, etc. pour protéger correctement l'entreprise tout en permettant le développement d'applications.
• Les bases de données primaires doivent être protégées. Selon la base de données, l'accès en lecture devrait être relativement facile à obtenir et l'accès en écriture plus difficile. Le service informatique peut avoir besoin de fournir des comptes, une journalisation ou un audit.

L'activation présente de nombreux avantages.

• Les TI en apprennent davantage sur la satisfaction des besoins de leurs clients. Cela conduit à une meilleure hiérarchisation et partage.
• L'informatique est considérée comme un ami et un avantage plutôt que comme un problème.
• Les besoins réels des entreprises sont satisfaits.
• Les données de l'entreprise sont correctement protégées, car les TI ont été impliquées, évitant ainsi le recours aux portes dérobées.
• Les outils de dépannage ne sont pas perdus en raison du chiffre d'affaires et peuvent plus facilement être transférés dans l'informatique, si nécessaire.

Je ne pouvais pas m'empêcher de m'identifier à vous. Le problème que vous décrivez semble être un problème universel, couvrant plusieurs cultures, langues et continents.

Les choses que vous pouvez faire:

• Restreindre la création de comptes de base de données en demandant l’approbation du superviseur. Le fait de les forcer à utiliser un ordinateur local en tant que serveur de base de données ou à écrire les applications pour qu'elles soient autonomes diminue considérablement son utilité.

• Faire en sorte que tous les stagiaires des carrières liées à l'informatique soient sous contrat avec l'informatique uniquement.

• Restreindre via le système d'exploitation l' installation de logiciels . Toute installation de logiciel doit être acheminée via le service d'assistance informatique, sous réserve de l'approbation du superviseur. De cette façon, l'installation de quelque chose comme MS Access, PHP, Visual Basic, etc., sera plus difficile à passer inaperçue.

• Publiez une politique stipulant que tout nouveau développement, pour bénéficier d'un support, doit être écrit en Java, C #, C ++ ou tout autre langage nécessitant une courbe d'apprentissage abrupte . De cette façon, vous réduirez l'univers des personnes possédant "une certaine connaissance de la programmation".

• Les besoins des utilisateurs doivent examiner les "solutions Excel" de la société, car elles reflètent les besoins informatiques de la société.

• Mise en œuvre d'un entrepôt de données et d'un outil d' exploration de données et de génération de rapports convivial . De cette façon, vous réduisez le besoin de petites applications personnalisées et écrites.

Mais: rien de ce que vous ferez ne dépassera l' appel d'un grand chef , appelant le responsable informatique et lui demandant de prendre en charge l'application créée par un stagiaire.

L'une des façons pour mon entreprise d'aider dans ce genre de situation est de ne pas être agnostique en termes de langue. Si vous souhaitez qu'une application / programme soit même pris en compte, il doit être dans une langue de notre choix (java). Nous pouvons étendre un peu les règles pour certains JQuery ou js, mais il faudrait que ce soit une application bien composée qui réponde à un besoin critique. Ne venez pas dire "J'ai cette application PHP que je dois héberger pour moi", car vous ne recevrez probablement qu'une feuille de politique.

Il est important d’étouffer les choses avant qu’elles ne deviennent trop grosses, car une fois qu’elles le seront, il est préférable d’avoir quelqu'un que vous pouvez dédier à l’apprentissage ou à la réécrire. Parce qu'une fois que cette grosse perruque à l'étage décide qu'il l'aime bien, vous n'allez probablement jamais vous en débarrasser, selon mon expérience.

L'arrogance des Geeks!

Dans de nombreux cas, les utilisateurs professionnels peuvent utiliser les outils pour effectuer des tâches que les informaticiens ne comprennent pas. Ce n'est pas parce qu'ils sont fondamentalement mauvais, mais parce qu'ils connaissent l'entreprise, son fonctionnement et comment ils aimeraient que cela fonctionne.

Par exemple, une société de logiciels a développé une application permettant d’optimiser (à prix coûtant) l’accès aux flux de données de marché. Après coup, ils ont fourni un plugin Excel afin que les utilisateurs puissent accéder au dernier cours de l'action via un tableur. Un an plus tard, presque tous les commerçants de la société pour laquelle je travaillais disposaient d’un ou de plusieurs tableurs extrêmement complexes pour appuyer leur stratégie de négociation. De temps en temps, ils rencontraient un problème avec la macro et demandaient de l'aide à l'un des responsables informatiques, mais la plupart refusaient (et se demandaient pourquoi l'entreprise nous détestait!). Cependant, je pouvais essayer de régler des problèmes techniques avec divers paramètres de fonction et des références circulaires, mais je peux honnêtement affirmer que je n’avais aucune idée de ce que le tableur entier faisait réellement. Non pas parce qu'ils étaient mal organisés ou mal programmés, mais parce que je n'avais pas les connaissances ou l'expérience pour apprécier la subtilité de ce que les traders essayaient de réaliser. De plus, j’estimerais qu’un projet informatique de plus de 5 personnes par an devait reproduire la fonctionnalité de l’un de ces tableurs dans un langage de programmation "approprié" en tant que projet informatique standard.