Interdire ou contrôler “l'informatique cachée…” Qui devrait écrire et gérer des applications logicielles ad hoc?


61

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)?


3
Cela dépendrait de l'environnement. Vous pouvez configurer le système d'exploitation du poste de travail de manière à ce que seuls les administrateurs puissent installer un nouveau logiciel. Vous pouvez également interdire l'accès aux ressources pertinentes du serveur (bases de données, système de fichiers) auxquelles ce logiciel devrait accéder. Vous pouvez le faire de manière technique, de sorte qu'il est impossible, d'éviter de donner des mots de passe, des adresses IP et des informations similaires, ou simplement en faire une politique d'entreprise et renvoyer tous ceux qui ne se conforment pas. J'ai vu plus ou moins tout cela.
Thorsten Müller

40
Mais si ces "programmes cachés" sont réellement critiques et qu'ils ne peuvent pas être mis en œuvre par le vrai service informatique, que gagnez-vous en leur interdisant? Après tout, ils sont critiques , vous ne pouvez donc tout simplement pas vous permettre de ne pas les avoir. Peut-être restructurer votre service informatique? Ou redéfinir les priorités? Il me semble compréhensible que des personnes habiles accomplissent des tâches en dehors du flux de travail normal, si ledit flux de travail ne répond pas ...
Andres F.

13
@ thorstenmüller A ce stade, vous finissez par avoir des programmes cachés mis en œuvre sous forme de formules Excel pour une maintenabilité de plusieurs ordres de grandeur inférieure à celle de Excel VBA. La création de feuilles de calcul Excel étant une capacité indispensable à de nombreux employés de bureau, vous ne pouvez pas l'interdire comme une plate-forme de développement plus adaptée.
Dan Neely

5
@ thorstenmüller Ce que je veux dire, c'est que peu importe ce que vous essayez de faire, attendez plusieurs jours (sinon plusieurs mois à cause de burrocrazy), passez plusieurs heures à le faire manuellement ou faites un bout de chemin autour de la politique faire le dernier. En supposant que vous puissiez l'arrêter, c'est délirant. Le mieux que vous puissiez espérer est d’avoir un processus efficace pour trouver et adopter ces outils après coup.
Dan Neely

16
Qu'est-ce qui ne va pas avec les «gens ordinaires» qui automatisent leurs processus métier? Tant que cela leur fait réellement gagner du temps, ce qui est probablement le cas, je considère que c'est une bonne chose . Si un outil d'automatisation 'ad hoc' 'particulièrement désordonné' devient fortement dépendant, il pourrait être utile que les développeurs écrivent une version maintenable. Dans le pire des cas, ils doivent recommencer à faire les choses manuellement lorsque les exigences changent, mais au moins ils ont déjà gagné beaucoup de temps!
Philip

Réponses:


79

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 ).


36
J'ai travaillé dans un environnement similaire, et la réaction de notre département face à ces applications était toujours frustrante. Un grand nombre de mes collèges du département informatique se sont sentis menacés par ces applications pour une raison quelconque, mais je les ai considérées comme merveilleuses. Cela permettait aux utilisateurs du service de préciser ce dont ils avaient réellement besoin, et lorsque cette base de données Access unique ne fonctionnait pas pour eux, ils pouvaient simplement nous la remettre et nous construisions une "vraie" solution SQL prenant en charge les mêmes fonctionnalités. Je tuerais encore pour un tel projet. Toutes les exigences étaient connues dès le premier jour.
Graham

8
+1 Bien énoncé. L’autonomisation des utilisateurs de nos logiciels devrait être l’une de nos principales priorités.
Steven Evers

Je suis d'accord pour l'essentiel avec votre réponse. Mais le résultat final est que des requêtes mal écrites peuvent faire tomber un serveur de base de données. même si écrit dans Excel ou Access. Once doit trouver un équilibre entre les engagements SLA de l'informatique et les besoins de l'entreprise.
Steve

@Stephen: Oui. Et c’est pourquoi il est préférable de donner aux utilisateurs les moyens de faire leur propre travail plutôt que de les laisser gérer les données de production. Qu'il s'agisse d'une copie quotidienne en lecture seule des données, d'exportations Excel ou d'un DSL, cela dépend beaucoup de vos besoins en matière de sécurité / SLA et de leurs exigences en matière de données.
pdr

1
@ Mattnz: Je recommanderais fortement contre cela. Cela donne aux gens un moyen de demander à l'équipe technique de hiérarchiser ses problèmes par rapport au reste de l'entreprise, simplement en assemblant quelque chose et en indiquant "Pouvez-vous comprendre pourquoi cela ne fonctionne pas?" Avez-vous déjà rencontré un développeur capable de résister à un tel défi?
pdr

50

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.


2
+1 point sur. Je ne vois personne ici mentionner ce qui a tendance à être un énorme problème avec ces pratiques que j'ai vu dans plusieurs entreprises. Ce qui fonctionne à court terme pour une ou deux personnes se transforme rapidement en un désordre logiciel complexe de 30 petites applications qui ont pris de l’ampleur au fil des ans. La moitié de leur travail et leur maintenance coûtent dix fois plus cher que si le service informatique embauchait des employés. faire tous pour qu'ils soient cohérents et avaient une base de propriété informatique centrale.
Jimmy Hoffa

4
En tant que personne travaillant en tant que programmeur "black-ops", je peux vous dire que souvent, le service informatique ne possède pas les compétences nécessaires pour comprendre les besoins d'un service technique particulier. Certains de nos programmes les plus critiques et les plus novateurs ont débuté sous le nom de programmes «opérations noires». L'informatique n'est pas un lieu où l'innovation est récompensée. Innovation et expérimentation signifient souvent beaucoup de projets échoués pour chaque projet réussi. Une fois qu'un programme "Black Ops" est bien adopté, il est généralement transféré au service informatique.
Bill

+1 Mes pensées exactement, mais formulées beaucoup mieux.
Phil

16

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.


2
"D'après mon expérience, ces cas sont extrêmement fréquents." - Votre entreprise recrute donc d'excellents programmeurs pour des emplois autres que des programmeurs, puis de mauvais programmeurs pour des emplois de programmation? Je pense qu'il est plus probable que quelqu'un qui ne comprend pas les pratiques et les systèmes sous-jacents pense qu'il écrit de meilleurs logiciels. Juste mes 2 cents.
Ominus

2
@ Ominus: s'il y a un poste vacant pour un avocat, l'entreprise recherchera un avocat; si le candidat est également un développeur expérimenté, l'intervieweur peut même ne pas le savoir. Donc non, la société ne "recrute pas de grands programmeurs pour des tâches autres que celles de programmeur": elle recrute une personne qualifiée pour un travail, sans savoir précisément que cette personne est également un excellent développeur.
Arseni Mourzenko

@ Ominus: notez que lorsque vous êtes embauché, par exemple, en tant que commis, vous ne dites pas pendant l'entretien que vous êtes un excellent programmeur. Pour beaucoup de gens sans formation technique, programmeur = pirate = mec qui passera son temps à craquer les PC de l'entreprise = beaucoup de problèmes.
Arseni Mourzenko

1
@ Ominus - Il n'est pas nécessaire que la société embauche des informaticiens pour disposer d'un service informatique incompétent. De mauvais départements informatiques peuvent survenir parce que les services informatiques sont considérés comme des "frais généraux" par quelqu'un et sont réduits autant que possible. Cela les dépasse au-delà de leurs capacités réelles et devient une organisation incompétente - basculant constamment entre les tâches, mode panique permanent, ne communiquant avec personne, ne tenant pas ses promesses.
Michael Kohne

2
@ Ominus: Ce qui est plus probable ici, c’est que la société embauche les deux types de rôles de la même manière, mais le groupe informatique est alors accablé de bureaucratie, de priorités conflictuelles et d’un système de gestion des performances qui ne fait pas le travail, étouffant. l'innovation plutôt que de la nourrir. Une fois que leurs compétences sont remarquées, les techniciens expérimentés sont autorisés à se concentrer sur une tâche, puisque seul leur chef de département contrôle leur temps. Les personnes qui effectuent le travail ont une adhésion automatique à l’innovation, alors que le groupe informatique n’a pas le même point de vue sur les besoins.
SqlRyan

6

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.


3

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.


3

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.


2

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é.


1

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.


5
D'après ce que j'ai compris, l'informatique est là pour soutenir l'entreprise. ne pas avoir un département informatique pour aider les gens à faire leur travail? Comment peuvent-ils bien faire leur travail si on leur interdit de créer les outils dont ils ont besoin? Il n’ya rien de mal à dire "Ne nous tenez pas pour responsables de ce rapport inexact, c’est quelqu'un dans les ventes qui a créé cela".
Phil

@Phil - D'accord. Le service informatique est là pour aider l'entreprise à fonctionner, et non pour remplir elle-même une fonction. Il n'existerait pas s'il ne permettait pas à l'entreprise de mieux faire son travail, et tout ce que l'informatique accomplit doit être considéré à la lumière de les affaires marchent mieux grâce à leurs efforts. Chaque processus créé en dehors du département informatique correspond à un besoin que le groupe informatique ne répond pas et leur interdire une plus grande insécurité. Vous ne pouvez pas vous attendre à supporter des processus que vous n'avez pas développés, et je serais ferme, mais refuser de reconnaître que ces solutions "voyous" correspondent à des besoins réels est tout simplement obstiné.
SqlRyan

1
Je dois ajouter que des mesures ont été prises pour développer le service informatique afin de répondre à ces besoins.
Paul T Davies

Bien que l'informatique prenne en charge l'entreprise, celle-ci ne la prend souvent pas en charge. Les entreprises ne prennent souvent pas en compte le temps qu'il faudrait au service informatique pour prendre en charge ou conseiller des feuilles de calcul ou des applications complexes développées par l'utilisateur final. L’effet net est un département informatique en sous-effectif. Et nous savons tous comment cela fonctionne.
Mike Sherrill 'Cat Recall'

1

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.


1

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.


1

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.

0

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.


à propos du point 1, les applications autonomes peuvent être d'une grande aide pour le traitement des données, même sans base de données, à propos du point 4, une courbe d'apprentissage abrupte n'empêche jamais quelqu'un d'écrire des choses lorsqu'il se trouve à la base de celui-ci, dont le résultat sera encore pire soutien, ou même quelqu'un dit "meh je n'ai pas besoin de cette application prise en charge"
freak freak

Le point 3 sur la restriction du système d'exploitation ne fonctionne pas. Beaucoup d'entreprises ont déjà opté pour le modèle «apportez votre propre ordinateur portable».
Sulthan

5
Je suis d'accord avec le point 4 (sachez que les outils personnalisés peuvent refléter un manque de réponse de la part du service informatique), mais pas avec le reste. Les mesures axées sur les restrictions dégagent une odeur de bureaucratie. D'après mon expérience, le résultat final est que des choses ne sont pas faites et que, dans l'informatique, il est rarement impliqué de manière efficace. "Non, vous ne pouvez pas faire X. Demandez à un responsable et faites-le approuver." (résultat: X ne se fait jamais; le niveau de frustration augmente)
Andres F.

0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.