Solía trabajar para una empresa donde todas las aplicaciones que les dimos nos llevaron a la pregunta: ¿Podemos exportar estos datos a Excel?

Después de un tiempo, decidí que tenía que saber por qué estaban obsesionados con las exportaciones de Excel para todo. Resultó que muchos departamentos tenían una persona que era experta en Excel y podía escribir una aplicación útil de análisis de datos en poco tiempo. Estas aplicaciones se propagarían por todo el departamento como un incendio forestal y nosotros, los técnicos, ni siquiera sabíamos que existían.

¿Por qué no vinieron a nosotros primero? Porque había una reputación de que el equipo técnico tenía mucho que hacer y, si lo pedían, podrían (si tenían suerte) hacerlo cola seis meses después.

Esa no fue una acusación injusta y nunca nos pidieron que admitiéramos sus aplicaciones de Excel, por lo que nadie realmente pensó que era un problema. Cuando estos desarrolladores de Excel se fueron, siempre lograron encontrar a alguien más para recogerlo.

Se podría argumentar que significaba que estábamos priorizando incorrectamente, que el trabajo importante no se estaba realizando. Pero yo diría que liberó a los desarrolladores más pagados para hacer un trabajo más difícil. ¿Qué puede doler?

Ahora prohibiría el software que actualiza la base de datos que se está escribiendo fuera del equipo de desarrollo. Y me negaría a admitir aplicaciones escritas fuera del equipo de desarrollo. Pero no trataría de prohibir que todo el software sea escrito por la propia empresa, y felizmente escribiría datos exportados para permitirles hacerlo (siempre que eso no exponga datos que no deberían ver, obviamente ).

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.

También se debe considerar el caso de las compañías en las que el departamento de TI contiene personas incompetentes, mientras que la aplicación oculta sería creada por un desarrollador hábil que tiene un trabajo de no desarrollador dentro de la empresa. En mi experiencia, esos casos son extremadamente frecuentes.

Imagina que tienes un perfil doble de un desarrollador de software y un contador. Te contratan como contador porque esta fue una oportunidad para que obtengas un trabajo bien pagado. Usted ve rápidamente que sus colegas (y ahora usted) pasan horas haciendo cosas repetitivas que un programa puede hacer en unos pocos segundos.

Pasas algunas noches para escribir la aplicación que hará todo el trabajo. Se lo muestra a sus colegas en su computadora portátil personal, y lo encuentran muy útil. Desea instalarlo en las PC de la empresa, pero debe contar con el acuerdo del departamento de TI. Lo pides, pero lo rechazan porque no admiten tu aplicación.

¿No suena estúpido?

Aparte de este caso particular, el problema con el soporte no es muy diferente de uno que muchas empresas encuentran con todos el software, incluso uno escrito dentro del departamento de TI: si el departamento de TI no aplica las mejores prácticas , el código estará mal / no documentado, escrito por personas sin experiencia que no se preocupan por el mantenimiento y que se fueron hace años.

Para concluir, la pregunta principal es la rentabilidad . Si a usted, el departamento de TI, se le pide que mantenga una aplicación desarrollada por un empleado que no comprende las reglas más básicas de desarrollo de software, no importa lo agradable que sea esta tarea, todavía tiene que hacerlo. si aporta mucho dinero a la empresa . O bien, vuelva a escribirlo desde cero si es la forma más barata de hacer las cosas.

No puedes completamente controlarlo ...

Yo diría que nunca puede controlarlo TOTALMENTE, ya que los empleados siempre tendrán medios para producir un código deshonesto y difundirlo por medios alternativos. Por lo tanto, no hay mucho uso de obsesionarse con él, una vez que haya redactado y aplicado algunas reglas y procesos básicos, y haya configurado algunas herramientas.

La idea es que sea lo más atractivo posible para que las personas respeten estas reglas y utilicen estas herramientas, en lugar de hacer que sea tan imposible hacer cosas nuevas que no producen nada.

Pero puedes crear un entorno amigable con el código

Muchas empresas, a menudo muy grandes, hacen esto. Un buen ejemplo es Google, para el cual los representantes han dicho que usan un solo SCM para toda la empresa, para que todos puedan monitorear y ver el código de otros.

Te recomiendo que hagas lo siguiente:

• permita el acceso público a algunas áreas de su SCM,
• facilita la solicitud de acceso a los servidores de integración continua e inspección continua,
• aliente a las personas a crear trabajos de creación para sus herramientas.

El problema es entonces la proliferación de tecnologías. Obviamente, algunos preferirán usar X sobre Y y ahí es cuando se hace más difícil que encajen dentro de su arquitectura. Sin embargo, no es imposible, y si quieren que se mantenga su código, probablemente obtendrán la milla extra si, bueno, es solo una milla.

También puedes adoptar una postura más arbitraria y decidir que solo se permiten el lenguaje L y Stack S, pero luego obtendrás algunas cosas maliciosas aquí y allá, por lo que te recomiendo ampliarlo un poco. Algunos sistemas de CI harán maravillas con algunos complementos, si sus empleados están dispuestos a escribir un poco de código de pegamento o algunos scripts de configuración para que encajen.

Dale algo de libertad a los equipos

Es importante dar a los equipos algo de libertad para ir a su antojo y comenzar algunos pequeños proyectos nuevos con cosas experimentales. Los mantiene alerta y usted, al igual que lo obliga a considerar estas tecnologías en lugar de quedarse atascado en una pila para siempre, hasta que le cause problemas.

Así que asegúrese de que tengan la capacidad de instalar sus propios sistemas para probar sus proyectos favoritos. Pero, asegúrese de que tengan el hábito de hablar con TI al respecto.

Habla con TI, haz que se involucren

Es mucho mejor si sus empleados desarrollan el reflejo de enviar una solicitud de correo electrónico a TI y preguntarles si pueden configurar algo para ellos y acomodarlos. Se rechazarán la mayor parte del tiempo, pero al menos hay una noción de control y quién debería estar a cargo y le da a TI cierta visibilidad sobre las demandas de los diferentes equipos.

Una vez que los proyectos adquieren una masa más crítica, puedes solicitarlos nuevamente y los reconsiderarán. La comunicación es clave, y necesita que sus equipos de desarrolladores, consultores, personal de soporte de TI o cualquier persona que trabaje con el código trabajen juntos. Ninguno de ellos quiere programas extraviados, por lo que es en el mejor interés de todos. Es mucho más fácil hacer cumplir las reglas si las respaldan ellas mismas.

No puede detener estas aplicaciones "ocultas" porque las personas las hacen para resolver problemas de negocios del mundo real. Todo lo que puedes hacer es ayudarlos a hacerlo de la manera "correcta". Y con "derecho" me refiero a hacer que las aplicaciones puedan mantenerse después de que la persona que las inicia se haya ido. Recomiendo usar el lenguaje sugerido en Up or Out : em> Necesito que documente este proceso en detalle para que cualquier yahoo pueda entenderlo dentro de un año después de que se haya ido. Ayuda para configurar el control de versiones (y mostrarles cómo usarlo), una wiki (para mantener notas informales sobre cómo se realiza realmente el trabajo) y un simple sistema de seguimiento de errores. Si desea que las cosas sean realmente fáciles, configure la integración continua en un servidor de reserva (si tiene uno).

Verás el gran deseo de integración con Excel (o al menos importar / exportar) porque todas las escuelas de negocios ahora enseñan Excel y es una herramienta importante que se usa en muchos cursos de negocios.

Sarbanes-Oxley y una legislación similar fuera de los EE. UU., combinadas con las leyes de privacidad y las políticas y los procesos de seguridad y privacidad internamente autoimpuestos son el "martillo" que puede y, a menudo, se utiliza para reprimir el fenómeno de las TI en la sombra.

Tan pronto como la información de identificación personal del cliente o empleado (o de cualquier información que no quiera obtener) comience a circular en estas hojas de cálculo, tendrá un accidente pendiente de suceder.

De manera similar, tan pronto como uno de estos proyectos de skunkworks IT tome esa hoja de cálculo de Excel y la use como datos detrás de una aplicación web externa que se piratee, su CIO y su CEO irán a la oficina de quienquiera que haya construido esa aplicación en un fin de semana viene a explicar las consecuencias.

Y luego está el problema de que al ver estos esfuerzos multiplicados por los cientos (o miles) de departamentos en una empresa Fortune 500, pronto encontrará que su empresa tiene más de 100 bases de datos "maestras" de clientes. Sus clientes comienzan a quejarse de que actualizaron su información de contacto en un lugar, pero aún está desactualizada en otros 10, o que ni siquiera sabe cuánto negocio hace con sus grandes socios porque la información está distribuida en 10 sombras. Bases de datos de TI.

Todo esto da lugar a procesos de auditoría y cumplimiento onerosos que no son divertidos para nadie pero son los hechos concretos de la vida de TI en un entorno empresarial.

Una buena estrategia es mirar a todos los departamentos que están haciendo esto y hacer un caso para mover su inversión en TI en la TI a la TI, haciendo que el argumento de que la TI pueda lograr una economía de escala y hacer este trabajo sea más eficiente. que el actual modelo skunkworks distribuido ad-hoc. Esto puede ser una venta difícil en un entorno donde las restricciones presupuestarias de TI y la velocidad de entrega dieron origen a los trabajos de Skunk en primer lugar, pero combinados con la auditoría / riesgos fiduciarios pueden hacer un buen golpe de uno a dos.

La decisión de escribir una nueva solicitud a menudo se basa en un análisis de costo-beneficio de la solicitud; así como el valor global para el negocio. A la vez que se toman en consideración muchos otros factores, como los recursos de TI disponibles, el alcance de la solicitud, los objetivos comerciales y la dirección, solo por mencionar algunos. Muchas veces se niega la solicitud de un departamento específico porque el gerente / director del departamento no ha mostrado un ROI razonable o simplemente no sigue el proceso establecido.

Independientemente de la razón, el "Departamento de TI" suele ser el chivo expiatorio, incluso si la decisión estuvo fuera de su control. Por lo tanto, aunque la denegación de la solicitud no se refleje de manera deficiente en el departamento de TI, la percepción a menudo es completamente diferente.

A pesar de esto, encontrará aplicaciones fraudulentas en casi todas las organizaciones empresariales del mundo. Algunos bien escritos y otros que contienen código que nunca debería haber visto la luz del día.

Si bien debemos hacer todo lo posible para satisfacer las necesidades internas de nuestros clientes, hay momentos en que simplemente no podemos. Cuando eso suceda, buscarán otro problema para resolver su problema.

Si el grupo de TI participa activamente en el proyecto, podemos exigir el cumplimiento de nuestros estándares, ayudar al consultor a seguir las pautas de codificación internas y comprender las interacciones de las aplicaciones con nuestros sistemas (base de datos, red, firewall, ... ). Sin esa participación, nos sorprenderemos y dedicaremos mucho tiempo a tratar de averiguar por qué nuestros sistemas de producción no cumplen con los SLA.

Ya sea que el departamento de TI los apruebe o no, pueden o pueden tener un impacto directo en términos de soporte, los compromisos de OLA y SLA por los que se mide cualquier departamento de TI.

Están prohibidos en nuestra empresa por estos motivos:

• Macros de Excel protegidas por contraseña donde la única persona que conoce la contraseña ha dejado la empresa,
• Ser responsable de los informes incorrectos escritos por personas sin experiencia porque es TI '
• Se le pide que modifique un informe que nunca antes hemos visto o escuchado.

Entiendo que puede ser frustrante para los usuarios cuando la TI está ocupada, y pueden estar inclinados a "hacerlo ellos mismos". Pero TI no puede ser responsable de las cosas que tiene, ni siquiera sabe que existe, y si nadie es responsable de la TI en general, hay grandes problemas por delante.

Si hay un problema aquí, es con el departamento de TI.

No hay nada de malo en permitir que las personas con conocimientos especializados de dominio / negocios manipulen y procesen sus propios datos.

El departamento de TI necesita reconocer esto y apoyarlo. Al proporcionar interfaces reutilizables, entregar datos en formatos convenientes como EXCEL o Access DBs, y proporcionar herramientas flexibles (COGNOS, Jasper Reports, etc.).

El departamento de TI también debe reconsiderar sus prioridades: está ahí para servir a la empresa, no para implementar la metodología más reciente o para instalar el hardware más atractivo.

Una frustración que muchas empresas o departamentos en las empresas tienen es que sus departamentos de TI se interponen en el camino y les dificulta realizar su trabajo o hacer cosas nuevas. Esto lleva a los departamentos, que sienten que están siendo retenidos por las políticas de TI, para intentar resolver sus propios problemas. La comunicación es clave. Si los departamentos trabajan alrededor de TI, lo que realmente tiene es un problema de TI. No puede permitirse ser visto como el enemigo. Las empresas, y especialmente los departamentos de TI, deben darse cuenta de que necesitan trabajar juntos en lugar de enfrentarse entre sí. Si los departamentos se comunican con su personal de TI (especialmente los que deberían tener supervisión) y les dicen sus necesidades y cómo están trabajando para resolver sus propios problemas, al menos TI tendrá la opción de ayudar a resolver problemas en lugar de descubrirlo después de la Hecho cuando una crisis llega a pasar. Manténgalo informado.

Casi siempre existe una necesidad válida para estas herramientas especiales, ya sean aplicaciones u hojas de cálculo. Un departamento de TI tiene dos opciones. Pueden ser habilitadores o deshabilitadores. En mi experiencia, los incapacitantes pierden porque interfieren con las necesidades comerciales válidas y se convierten en un enemigo común. Los habilitadores, por otro lado, ayudan genuinamente a una empresa.

Esto no significa que el desarrollo financiado por el departamento debe tener un reinado libre. Se deben hacer cumplir algunos requisitos, como los siguientes:

• Todo el código debe comprometerse regularmente con un sistema de control de versiones ejecutado por TI. TI debería crear libremente cuentas y directorios para hacer esto posible. Es posible que incluso quiera proporcionar alguna instrucción.
• Todo lo relacionado con PII (información de identificación personal), autenticación, autorización, criptografía, datos protegidos por ley o datos que la empresa considere críticos debe incluir y ser aprobado por un consultor de TI. TI / el consultor debe proporcionar asistencia, bibliotecas, etc. para proteger adecuadamente el negocio mientras se habilita el desarrollo de aplicaciones.
• Las bases de datos primarias deben estar protegidas. Dependiendo de la base de datos, el acceso de lectura debería ser relativamente fácil de obtener y el acceso de escritura más difícil. Es posible que TI deba proporcionar cuentas, registro o auditoría.

La habilitación tiene muchos beneficios.

• TI aprende más sobre satisfacer las necesidades de sus clientes. Esto conduce a una mejor priorización y compartir.
• TI se ve como un amigo y un beneficio, en lugar de un problema.
• Se satisfacen las necesidades comerciales reales.
• Los datos comerciales están protegidos adecuadamente porque la TI estaba involucrada, lo que evita la necesidad de puertas traseras.
• Las herramientas de departamento no se pierden debido a la rotación de personal y se pueden mover más fácilmente a TI, si es necesario.

No pude evitar identificarme contigo. El problema que describe parece ser universal, abarcando culturas, idiomas y continentes.

Las cosas que puedes hacer:

• Restrinja la creación de cuentas de base de datos , solicitando la aprobación de un supervisor. Forzarlos a usar una máquina local como un servidor de base de datos o escribir las aplicaciones para que sean independientes, disminuye enormemente su utilidad.

• Haga que todos los pasantes de las carreras relacionadas con TI sean contratados a través de TI solamente.

• Restricción a través de la política del sistema operativo la instalación de software . Cada instalación de software debe canalizarse a través de la mesa de ayuda de TI, que requiere la aprobación de un supervisor. De esa manera, la instalación de algo como MS Access, PHP, Visual Basic, etc., será más difícil de pasar inadvertida.

• Emita una política que indique que cada nuevo desarrollo, para que se le brinde soporte, debe escribirse, diga Java, C #, C ++ , o cualquier otro idioma que requeriría una curva de aprendizaje empinada . De esa manera, reduce el universo de personas con "un cierto conocimiento de programación" para desordenar.

• Los requisitos las personas deben analizar las "soluciones Excel" de la empresa, porque eso refleja las necesidades de TI de la empresa.

• Implementando un almacén de datos y una minería de datos fácil de usar por el usuario final y herramienta de informes . De esa manera, se reduce la necesidad de pequeñas aplicaciones escritas a medida y escritas internamente.

Pero: ni una sola cosa que hagas superará a una llamada de un Gran Jefe , llamará al Gerente de TI y le pedirá que apoye la aplicación que realizó un interno.

Una de las formas en que mi compañía ayuda en este tipo de situaciones es no ser agnóstico del idioma. Si desea que se considere una aplicación / programa, debe estar en el idioma de nuestra elección (java). Podríamos estirar un poco las reglas para algunos JQuery o js, pero tendría que ser una aplicación bien compuesta que respondiera a una necesidad crítica. No venga y diga "Tengo esta aplicación PHP que necesito que me alojes" porque probablemente solo te entreguen una hoja de políticas.

Es importante cortar las cosas antes de que se vuelvan demasiado grandes, porque una vez que están, es mejor que haya alguien a quien pueda dedicar a aprender o a reescribirlo. Porque una vez que la peluca grande de arriba decide que le gusta, probablemente nunca lo deshará de mi experiencia.

¡La arrogancia de los Geeks!

En muchos casos, los usuarios empresariales pueden usar las herramientas para hacer cosas que la gente de TI no entiende. Esto no es porque sean intrínsecamente malos, sino porque conocen el negocio, cómo funciona y cómo les gustaría que funcionara.

Por ejemplo, una compañía de software desarrolló una aplicación para optimizar (por costo) el acceso a las fuentes de datos del mercado. Como idea adicional, proporcionaron un complemento de Excel para que los usuarios pudieran acceder al último precio de las acciones a través de una hoja de cálculo. Un año después, y casi todos los comerciantes de la empresa para la que trabajé tenían una o más hojas de cálculo increíblemente complejas para respaldar su estrategia comercial. De vez en cuando tendrían un problema con las macros y pedirían ayuda a uno de los chicos de TI, la mayoría se negó (y se preguntan por qué el negocio nos odia). Sin embargo, tuve una oportunidad y aunque pude solucionar problemas técnicos con varios parámetros de función y referencias circulares, puedo decir honestamente que no tenía la menor idea de lo que realmente tenía toda la hoja de cálculo. No porque estuvieran mal organizados o mal programados, sino porque no tenía el conocimiento o la experiencia para apreciar la sutileza de lo que los comerciantes estaban tratando de lograr. Además, estimaría un proyecto de 5 años más de TI para replicar la funcionalidad de una de estas hojas de cálculo en un lenguaje de programación "adecuado" como un proyecto de TI estándar.