Creo que a la gente le falta el punto general aquí:
Si no te gusta todo el desarrollo personalizado que está ocurriendo,
prohibirlo es resolver el problema incorrecto, deberías ser
preguntando por qué lo están haciendo, no solo diciéndoles que no es
permitido. Recuerde que usted (IT) existe para ayudarles a hacer su trabajo
Mejor, y que la gente no usa software porque es genial o limpio.
o nuevo, lo usan porque resuelve un problema que tienen.
¿Por qué se crean estas aplicaciones en primer lugar?
En todos los casos que he visto, hay una razón común:
Los grupos empresariales priorizan sus propias necesidades por encima de las mismas necesidades y se priorizan en el contexto de toda la empresa
El marketing solo es responsable del marketing, por lo que las iniciativas que benefician sus objetivos parecen ser fundamentales para ellos, al tiempo que se consideran una pelusa para otros grupos y tienden a tener una prioridad más baja cuando se trata de recursos limitados como TI. La priorización solo entra en juego cuando quieren usar un recurso compartido: si mantienen el proyecto completamente dentro de su propio departamento, entonces solo el jefe de departamento debe preocuparse por el presupuesto y el cronograma.
No hay ninguna razón por la que prohibiría este tipo de desarrollo, dentro de la misma razón: alivia las restricciones en los recursos compartidos (principalmente TI), y permite que cada grupo se capacite para resolver sus propios problemas (como las personas versadas en Excel avanzado son bastante común, ya que este es un problema común, la mayoría de los departamentos tienen al menos uno).
Sin embargo, no se puede esperar que resuelva ningún problema que surja de estas aplicaciones, o que las respalde después de que el desarrollador original abandone la empresa. Como lo mencionó otra publicación, esto no impide que el gran jefe le exija que lo respalde, pero si se da cuenta de los tipos de aplicaciones o procesos personalizados que existen, puede sentir cuándo algo se vuelve crítico y usted podría necesitar involucrarse para traerlo "en casa". Además, si algo se conecta y modifica los sistemas que están bajo el control de TI, entonces debe involucrarse, aunque solo sea para garantizar la seguridad y la integridad de sus sistemas centrales. Sin embargo, si es algo que se limita al escritorio de un usuario, ¿por qué sentir la necesidad? ¿Para prohibirlo?
Pero aquí hay algo para recordar: Cada aplicación personalizada que se haya desarrollado fuera de TI corresponde a una necesidad que no está siendo satisfecha por TI . Puede haber una buena razón por la que no se cumplen: no es una prioridad en la empresa, un problema muy especializado, no es tan bueno como otras opciones, lenguaje personalizado que su personal de TI no conoce, etc., y la falta de participación de TI puede ser legítimo, pero estas soluciones se crearon porque algún departamento tenía una necesidad que TI no podía (o no) satisfacer.
Trate de ayudarlos a resolver sus problemas, y si no tiene el tiempo o los recursos, déjelos resolverlos por su cuenta. Mandar un lenguaje que tiene una curva de aprendizaje empinada, con el único propósito de mantener a las personas fuera de su negocio, solo sirve para mejorar la actitud elitista que la mayoría de los usuarios de negocios perciben que TI tiene, y al final, ese tipo de actitud de élite solo lleva a más del mismo problema, ya que los usuarios tienen miedo de acercarse a la TI y están convencidos de que la TI no entiende sus necesidades o deseos. Abra la relación: entender lo que necesitan es la única forma de evitar que lo rodeen.