Transformación Digital

¿Acelera el Shadow IT la transformación digital?

Este tema del shadow IT (coloquialmente conocido como tamagochies o maquinillos) es de los más sexys a los que te puedes enfrentar como CIO: consigue generar discusiones en toda la organización, evidencia una capacidad para hacer desarrollos en las organizaciones increíble, a la vez que pienso que es una muestra de desgobierno de una organización, sino le aplicas cierto criterio.

Transformacion Digial - CIO

Dicho lo anterior, reconozco que a medida que ha ido evolucionando la tecnología, y he tenido varias discusiones al respecto, también he ido evolucionando mi punto de vista sobre ellos.

Hace años, antes del mundo on-line, en la era CRM/ERP, donde los clientes no interaccionaban con las empresas, y el grado de automatización iba por barrios, había gente con tiempo, para dedicar esfuerzo a automatizar determinadas tareas que le permitía ganar en eficiencias, y que siempre que no cambiaran los datos maestros del proceso, podía convivir. Los procesos, en general, no eran automáticos, y había mucha intervención humana.

Siempre me ha fascinado la facilidad de otras áreas, no de sistemas, para burlar o torear a las áreas de control financiero, y disfrazar proyectos de TI como gastos varios. Mientras los proyectos de TI eran sometidos a todo tipo de revisiones y cuestionamiento. Me imagino que como ellos también lo hacían en algunos casos, eran juez y parte.

¿Por qué lo hacían? Según me han contado en infinidad de ocasiones porque éramos lentos, caros e inflexibles. No digo que algo de razón no tuvieran, pero creo que eso de buscarse la vida cada uno, a corto da resultados, pero según lo que hagas puede tener consecuencias a medio difíciles de gestionar en términos de evolución y sostenibilidad.

Cuando empezaron las páginas web, los canales on-line y las Apps, empezó el debate de quién gestiona qué, si la experiencia de cliente, si necesito agilidad y flexibilidad. Las áreas de marketing empezaron a contratar desarrolladores software con la excusa de la experiencia de cliente, y en ciertas ocasiones, había más una competencia interna, que un objetivo de dar una experiencia al cliente realmente diferencial. Cuando además había trabajo de sobra para todos, y no era el miedo a quedarme sin actividad.

Sí es cierto que los canales on-line, necesitaban otro modelo de gestión de construcción y cambio de software diferente al waterfall, y a las políticas tradicionales de cambios. Siempre he pensado que hablando se entiende la gente, y creo que se puede conseguir definir un modelo de trabajo donde marketing tenga la autonomía y flexibilidad que necesita, y el área técnica pueda garantizar los plazos y la disponibilidad que el negocio exige. Ahora lo llamarían agile, pero en aquel momento era sentido común de negocio.

El problema, desde mi punto de vista empieza, cuando equipos de otras áreas ajenas a sistemas, desarrollan piezas de software que hacen accesos a bases de datos de información de clientes, productos, y no sólo la actualizan, sino que hacen procesos paralelos al oficial. Esto lleva a problemas de calidad del dato, de dónde y quién es responsable de la información relevante de la compañía, y cómo se garantiza su integridad.

La tercera ola viene con la llegada del cloud, y el mensaje a los equipos fuera de tecnología: “No te preocupes que ya te lo hago yo, es gasto y ya no necesitas al área de sistemas”. Todo empieza como en la luna de miel, hasta que pasan cosas: no da el rendimiento esperado, lo que hace esa aplicación no se integra con el resto de los procesos de la compañía, o para actualizar el sistema ya no es tan sencillo como me lo contaron, o un día información relevante de la compañía es robada.

No quiero sacar la escoba de bruja, y amenazar a mis colegas con el fuego del infierno, pero en una compañía hay determinados elementos que para mí no son negociables, y que se deben respetar. Al igual que lo que hace un CFO o un CMO, es raro que se discuta, sobre las decisiones de TI, no sólo se crean debates colectivos, sino que en ocasiones hasta deciden sin preguntar.

Y esos elementos no negociables y competencia de un equipo técnico, lo llamemos como queramos son:

  1. Asegurar el modelo de datos de una compañía: es la base de la automatización y de que los procesos fluyan en la organización, y no tengamos problemas de calidad en el funcionamiento y prestación de los servicios. El famoso maestro de datos y el mantener su integridad es un termómetro de cuan automatizable y cuan eficientes son los procesos en una compañía.
  2. La arquitectura empresarial, o como encaja el modelo de negocio con los procesos, las personas y los sistemas. El asegurar una arquitectura de integración potente es la clave de su Time to Market en desarrollo, y tu agilidad para incorporar nuevas funcionalidades, o transformar tus procesos.
  3. La seguridad de la información y los accesos a la misma. No vale todo, y además todos en una compañía somos responsables de su cumplimiento.
  4. La eficacia y la calidad del proceso que se soporta en los sistemas y la tecnología, acorde a lo que necesita cada negocio. No vale el café con leche para todos. Todos sabemos dónde nos la jugamos y dónde hay que tener cinco 9 de disponibilidad, y dónde podemos permitirnos otros niveles.
  5. Dotar de las herramientas de desarrollo, modelos de datos, arquitecturas de integración y seguridad, para que los equipos que tengan competencias de desarrollo lo hagan dentro de un marco que permita a la empresa escalar y crecer de forma sostenible.

Y seguro que alguno no está de acuerdo en el punto 5, donde equipos fuera de sistemas o tecnología hacen software, pero os voy a explicar dónde yo creo que tiene todo el sentido y porqué deberíamos cambiar la aproximación y aprovechar la oportunidad.

Como decía al principio de este post, el escenario de tecnologías ha cambiado mucho y también los perfiles que se necesitan en las compañías en las áreas de Marketing, Finanzas, Operaciones, RRHH… El tener personas con perfil de desarrollador ayuda a redefinir y cambiar procesos, formas de hacer, automatizar, y además se necesita entender cómo la tecnología está cambiando el negocio y las formas de hacer. La necesidad de hacer análisis de datos en las áreas crea una demanda de perfiles técnicos, qué supone una potencia distribuida por toda la compañía, que bien gestionada estoy convencida que es una palanca clave para ir más rápido y ser más eficiente.

Si una compañía ha decidido tener perfiles de esas características en departamentos diferentes de sistemas, y creo que debe hacerlo, hay que aprovecharlo y conseguir que tengan autonomía, pero remando a favor. De ahí que se tengan que poner a su disposición las herramientas necesarias, pero a la vez exigirles cómo se haría a cualquier otro equipo de desarrollo. Tienen que tener los mismos objetivos y estar sometidos a las mismas reglas de auditoría y calidad que el resto.

Las nuevas formas de construir software basadas en scrum, agile, devops….  Nos obligan a repensar cómo organizar a los equipos no sólo técnicos, porque es una transformación transversal y exigen cambiar formas de hacer de los últimos 20 años.

Por tanto, la respuesta a la primera pregunta, el shadow IT tradicional no es una palanca de aceleración y sí de entropía, pero el conseguir que desde otras áreas se hagan desarrollo bajo los parámetros que os he contado, creo que es un acelerador clarísimo.

Comentarios

Iniciar sesión

Se muestran 1 comentarios

Actualizar mensajes

Próximos Eventos