Llegamos a ustedes gracias a:



Reportajes y análisis

TI y Operaciones: Cómo evitar colisionar

TI y Operaciones

[10/12/2015] ¿Qué haría si descubriera que algunos de los programas que ejecuta su empresa están atrasados en la aplicación de docenas de parches y actualizaciones -incluyendo los parches de seguridad críticos? Se podría pensar que nunca podría suceder. Pero podría estar equivocado.

Los CIO de muchas industrias están descubriendo que las operaciones de sus empresas son soportadas por aplicaciones sorprendentemente anticuadas y personalizadas, controlando todo -desde el equipo de bombas hidráulicas, sistemas de calefacción y refrigeración y energía eléctrica.

Este es el mundo de la tecnología operativa, un mundo que ha existido desde que el primer ingeniero puso un limitador de velocidad en una máquina de vapor en la década de 1800. Desde entonces, la tecnología operativa ha sido completamente independiente de TI en la mayoría de las organizaciones. Pero en estos días, varias fuerzas convergentes -dispositivos digitales cada vez más complejos, la creciente preocupación por la seguridad y el deseo de beneficiarse de big data y la Internet de las Cosas- están obligando a que operaciones y TI trabajen juntos. Y no siempre es fácil.

"La tecnología operacional es el dominio del personal de ingeniería y operaciones que es independiente de TI", señala el analista de Gartner, Kristian Steenstrup. "En la mayoría de las empresas, están en edificios separados y nunca hablan entre sí. ¿Cómo maneja las cosas en su organización cuando tiene más tecnología y tráfico de datos fuera del control de TI?".

Esto puede sonar como TI en las sombras, pero es muy diferente, advierte. TI en la sombra ocurre cuando un departamento, con una tradición de utilizar la tecnología proporcionada por TI, decide salirse de este marco; por lo general, por la frustración sobre sus reglas acerca de qué tecnología utilizar o la impaciencia en el tiempo necesario para evaluar y adoptar una nueva tecnología. Casi siempre implica una implementación en la nube.

"Con el movimiento de una mano, los departamentos de TI podrían vigilar su contraparte en la sombra", anota Steenstrup. "Los departamentos de TI, del modo como están estructurados actualmente, no pueden ejecutar la tecnología operacional. No están familiarizados con la arquitectura, los proveedores, las aplicaciones, los requisitos de disponibilidad y criticidad en tiempo real involucrados. Es algo completamente diferente a la mayoría de departamentos de TI".

Más allá de la "brecha de aire"

¿Por qué TI y operaciones no pueden seguir operando por separado, como lo han hecho durante años? Debido a que los cambios en la mayoría de las organizaciones industriales han hecho que ese enfoque deje de ser práctico. En primer lugar, están las crecientes preocupaciones de la alta dirección sobre ciberseguridad, a veces acompañadas de preocupaciones sobre el cumplimiento de las regulaciones gubernamentales recién promulgadas.

"Lo que ha pasado en los últimos tres a cinco años para que éstas dos áreas se unan es la seguridad", anota Peter Zornio, director estratégico de Emerson Process Management, parte de Emerson Electric, una empresa de fabricación global de 24 mil millones de dólares. Emerson Process Management ofrece equipos de automatización, soluciones y servicio para las empresas de petróleo y gas, refinación y químicos industrias, entre otros. "Los problemas de seguridad en torno a estas instalaciones son muy diferentes de lo que le ocupaba a TI", anota Zornio. "TI por lo general se preocupa por alguien que entra y roba información. En el control del proceso, usted se preocupa por alguien que entre y cambie algo en el equipo que ejecuta un proceso. Algunos de estos son procesos peligrosos que, si se rompen, podrían dar lugar a accidentes, lesiones, daños al medio ambiente o incluso la muerte".

A medida que la alta dirección es cada vez más consciente de estos peligros, se preocupan de que las operaciones estén seguras, algo que los 'techies' saben cómo hacer y los ingenieros no. En el pasado, muchas empresas industriales mantuvieron su tecnología operativa relativamente segura con una "brecha de aire" -es decir, el equipo de operaciones no estaba conectado a Internet o al resto de la red corporativa.

Pero ese enfoque significa sacrificar la eficiencia y los ahorros de inventario disponibles, cuando una empresa fabricante le da una conexión directa a sus sistemas a sus proveedores y otros socios de negocio. También impide el análisis de datos que puede beneficiar a la línea de fondo, proporcionando la información necesaria para, por ejemplo, dirigir material para las máquinas que están operando por debajo de su capacidad, predecir lo que los clientes quieren o identificar las máquinas que de pronto pueden necesitar mantenimiento o sustitución. A medida que los ejecutivos principales comienzan la búsqueda de algunos de esos Beneficios -a menudo preguntándole a TI- la estrategia de seguridad de brecha de aire se ve cada vez menos factible.

La mayoría de los ingenieros de operaciones no están preparados para trabajar con seguridad. Ese fue el caso de Hunter Douglas North America, que es parte de Hunter Douglas, fabricante de cortinas y productos de decoración basado en Rotterdam, Holanda. Este año, el departamento de TI y los ingenieros de producto colaboraron en un nuevo tratamiento motorizado de ventanas que podría ser controlado por una aplicación de teléfono inteligente.

La gente de TI se sorprendió de que los ingenieros de productos no se hayan preocupado mucho por la seguridad cibernética, señala el CIO de Hunter Douglas Norteamérica, Rob Meilen. Pero, señala, si su trabajo siempre ha sido el diseño de tratamientos de ventanas, y nunca antes se ha conectado a la Web, tiene sentido que la seguridad cibernética no sea su mayor preocupación. "Nuestros equipos de TI no estaban muy seguros de cómo tratar con un grupo de ingenieros de producto que se preguntaba por qué tendría que diseñarlo desde el principio", anota. "No se resistieron, pero nunca habían pensado en ello. Pensar en la seguridad cibernética es una segunda naturaleza para nosotros".

Otro factor que empuja a que operaciones y TI trabajen juntos es la forma en que la tecnología operativa está evolucionando. El software que ejecuta dispositivos operacionales depende cada vez más de los sistemas operativos tradicionales de TI, a menudo de Windows. Esa es una tendencia que probablemente continúe, porque resulta económica. "Las empresas como la nuestra usan la tecnología 'off-the-shelf' porque es mucho más rentable que crearla nosotros mismos", anota Zornio. "Hace que la integración con los sistemas de TI sea más fácil y se aprovecha de la relación costo-rendimiento de una PC Dell. Dell está haciendo millones con esto; si lo hiciéramos, podríamos hacer un par de millones".

Esto significa que los ingenieros de operaciones, entrenados y acostumbrados a tratar con equipo pesado, ahora se encuentran manejando una cartera creciente de software, a menudo basada en Windows. También deben gestionar las frecuentes actualizaciones y parches que van con Windows -y eso es un problema.

"Nuestros sistemas son cada vez más sofisticados, y cada vez más digitales. Nuestra gente parece cada vez más especialista en TI que ingenieros", anota Chris Heimgartner, asistente del gerente general de los servicios de distribución y de ingeniería en Snohomish County Public Utility (SnoPUD). "No tenemos las habilidades", anota. "Los ingenieros arreglan cosas que están rotas".

De este modo, al igual que un creciente número de jefes de ingeniería, Heimgartner buscó al CIO de SnoPUD, Benjamin Beberness, y a su equipo de TI para obtener ayuda con parches del sistema operativo y de mantenimiento. Cuando Heimgartner se sentó a discutir este cambio con uno de los ingenieros que trabajaron en el software de control de supervisión y adquisición de datos (SCADA), preguntó si el equipo de ingeniería de SnoPUD era bueno en la manipulación de parches.

"Fue entonces cuando él sacó el récord de parches", recuerda Heimgartner. Resultó uno de los sistemas SCADA de SnoPUD estaba detrás de 28 parches, y algunos parches críticos estaban desactualizados por tres años. "Me dijo: 'No, no somos buenos en esto'".

"Usted no es mi jefe

Aunque muchos líderes de TI y de operaciones reconocen la creciente necesidad de trabajar juntos, todavía hay algunos obstáculos formidables. Para empezar, puede haber profunda desconfianza entre el personal de TI y de operaciones (especialmente esta último), quienes están acostumbrados a operar de forma independiente.

"Hay un ambiente de 'no eres mi jefe'", anota Rick Davidson, presidente de Cimphoni, una consultora que proporciona servicio de liderazgo de TI y soluciones de IoT en muchas industrias.

A pesar de que ahora está en un papel de liderazgo tecnológico, Davidson ha pasado años en el lado de la fabricación, por lo que tiene una buena visión de ambas disciplinas. "En la fábrica veíamos a TI como una organización insular", añade. "Un ingeniero dirá: "Todo lo que hay que hacer es una capa sobre una gran cantidad de burocracia y controles que no son necesarios". La realidad es que algo de ello es necesario. Pero TI está trabajando en contra de los deseos de una gran cantidad de personas de la fábrica que solo quieren hacer sus propias cosas".

Incluso cuando miembros del personal de ingeniería reciben atención de TI, los expertos en tecnología pueden ser reacios a tratar con la tecnología que dirige las operaciones. Y no se les puede culpar. "A menudo, hay más problemas que soluciones", anota Steenstrup. "Algunos son culturales y organizacionales. En algunas empresas el área de ingeniería y de TI no registran un historial de trabajo conjunto. Y si TI se involucra, que van a heredar siete proveedores diferentes de los que nunca han oído hablar, ejecutar tecnología obsoleta que no puede ser parchada y que no tiene una arquitectura fácil de manejar".

Por ejemplo, "En operaciones hay una gran cantidad de sistemas de tecnología que se ejecutan en Windows 95 y Windows NT 4.0", señala el ejecutivo. "Los proveedores de estos sistemas también son ingenieros, y les gusta la estabilidad por lo que no han sido tan diligentes en el envío de parches o incluso en la aprobación de las actualizaciones", explica.

Incluso cuando a veces unen sus esfuerzos por mantener su software remendado, son rechazados por sus clientes ingenieros. "Solíamos pensar que necesitábamos emitir grandes lanzamientos cada año y medio, y nuestros clientes, dijeron, '¡demasiado rápido! Tres años es mejor'", informa Zornio. "La industria de TI se las ha ingeniado para programar a los CIO con la idea de que, por supuesto, siempre deben estar actualizados y nosotros no vamos a apoyar esta cosa que tiene más de seis años de antigüedad. Y creen que esa es la forma en que tiene que ser. Pero los ingenieros no piensan de esa manera, antes de lo que uno piensa tiene que reemplazar el motor en su carro solo porque tiene 10 años de edad".

Detrás de estas actitudes diferentes ante los parches se encuentra una diferencia fundamental en los enfoques, prioridades e incluso la cultura del trabajo, que nace de las profundas diferencias en el propósito y el funcionamiento del área de operaciones y de TI. Puede empezar a entender esta diferencia al considerar una acción simple que sirve como el primer paso para solucionar la mayoría de problemas de TI: el reinicio. Reiniciar la PC, servidor o red es una cuestión de rutina para TI. Pero cuando un sistema ejecuta una operación de fabricación 24/7, un reinicio que detenga las cosas no suele ser una opción. Tampoco han previsto el tiempo de inactividad, las actualizaciones y mejoras que se hacen los fines de semana, o muchas otras prácticas que son parte normal de un departamento corporativo de TI.

"El enfoque de resolución de problemas es en realidad muy diferente", señala Steenstrup. "Si tiene que resolver un problema de ingeniería, nos fijamos en características físicas, la temperatura, el tiempo y lo que se habría hecho en otros lugares en una situación similar. Usted hace que funcione tan bien como pueda, y luego lo asegura o suelda en su lugar".

El equipo de TI de Hunter Douglas North America se encontró con esa mentalidad de los ingenieros de producto cuando estaba dando los toques finales a la aplicación de tratamiento de ventana. "Alguien en la parte de ingeniería hizo el comentario, 'Construimos la aplicación. Creo que hemos terminado'", recuerda Meilen. "La gente de TI se rascaba la cabeza y dijo: 'Por lo general las aplicaciones evolucionan con el tiempo'".

Ese tipo de evolución es algo natural para TI, sobre todo en esta época de desarrollo ágil y magro. "TI dice: 'Estos son los estándares de la tecnología. Aquí está la solución más rápida y barata posible, y luego vamos a prepararnos para el cambio. La actualizaremos más adelante'", anota Steenstrup. "Son dos psicologías completamente diferentes, ninguna de los cuales puede ser desechada", añade.

Deshágase de los estereotipos

Entender que ambas actitudes son legítimas y que las dos deben ser combinadas, es el primer paso hacia la alineación efectiva de TI y operaciones. "Los ingenieros no son realmente buenos con los parches, y no tan bueno como TI en la implementación de software y realizar cambios en la tecnología", comenta Beberness. "Pero TI no es tan bueno en saber cuál sería el impacto de un cambio".

Los ingenieros se quejan de que TI no "entiende", cuando se trata de tecnología operativa, pero Beberness dice: "Yo creo que no. A veces necesitan ser educados un poco, pero no toma mucho tiempo para que entiendan la criticidad y urgencia que existe alrededor de la tecnología operacional". Siendo ese el caso, añade, "las dos organizaciones tienen que deshacerse de los estereotipos y hacer que sus equipos trabajen en conjunto".

Suena bien, pero ¿cómo hacer para que esto funcione? Comience con un marco de referencia que ayudará a los ingenieros a entender el panorama general, sugiere Davidson. "Como ingeniero, tener un modelo mental -una foto de la planta de producción a través de la ejecución, a través de un sistema MRP tradicional [planificación de los requerimientos de material]- es una gran ayuda", comenta. "Un ingeniero puede mirar eso y decir: 'Ahora entiendo mi papel en el gran esquema de las cosas'".

Más allá de eso, anota Steenstrup, necesita un plan específico de cómo va a integrar la tecnología operacional con los sistemas de TI. "Tiene cosas como el mantenimiento de los estándares de datos, arquitectura de datos y la capacidad de transformar los datos del sensor y utilizarlos en un entorno de TI". Este no es un proceso que se completará con rapidez, añade.

Lograr la integración de TI y las operaciones requiere el apoyo de la alta dirección y de los líderes de ambas disciplinas -y los líderes deben trabajar en estrecha colaboración. "Un CIO me dijo hace un tiempo que podía ver que cada proyecto futuro de su compañía sería un proyecto híbrido de TI-operaciones", anota Steenstrup. "Y podría tener una batalla cada vez, o bien hacerlo una vez y ordenar las normas, proveedores y métodos -y entonces todos esos otros proyectos serían más rápidos".

Algunas empresas con visión de futuro están tomando un paso más allá y han creado equipos multi-funcionales de TI y operaciones. "En Codelco, una gran empresa minera en Chile, tienen la innovación a cargo de los ingenieros y los científicos de datos que están allí para ayudarles a trabajar mejor en la mina", comenta Kim Smith, vicepresidente de Innovación Digital en Capgemini. "Pero se dieron cuenta de que necesitaban infundir algunas capacidades de TI en la relación, como la tecnología de la nube y vehículos operados a control remoto."Esa compañía creó un centro de innovación donde los ingenieros y profesionales de TI pueden explorar juntos nuevas tecnologías. Se creó un matrimonio de ingeniería y TI", añade la ejecutiva.

Cuando eso sucede, agrega Steenstrup: "he visto a veces que las paredes comienzan a bajar por completo. Si tiene inversiones y arquitecturas conjuntas, no tendrá estos problemas en el futuro. Así que la gente que construye cosas como plataformas petroleras, ahora está buscando empezar a trabajar en la creación de la alineación".

Después de todo, los ingenieros son ingenieros -así trabajen con algoritmos o cintas transportadoras. "Los ingenieros de fabricación e ingenieros de software", señala Davidson, "se preocupan por diseñar sistemas que funcionen y no se quiebren".

Construya una red inteligente, juntos

En SnoPUD, el CIO Beberness y Heimgartner, asistente del gerente general de los servicios de distribución y de ingeniería, siempre se han visto a los ojos. Y Heimgartner sabía que necesitaba la experiencia de TI para completar el proyecto para el que fue contratado.

"Empezamos [alrededor del 2006] con un sistema con el que Thomas Edison se hubiera sentido cómodo, y hemos convertido a SnoPUD en una utilidad del siglo 21 en los últimos siete u ocho años", señala.

Un elemento vital de esa transformación fue la creación de una red inteligente, algo que requiere la experiencia de ingeniería y de la informática. Y eso significaba poner una cuidadosa reflexión sobre cómo se compartirían responsabilidades y tareas. "En todas nuestras subestaciones tenemos equipos de puerta de enlace que se ejecutan en una plataforma de Microsoft", comenta Heimgartner. "En el fondo, son PCs. ¿Quiero que mi gente de ingeniería se encargue de los parches?".

La respuesta a esa pregunta es no. Por otra parte, se pregunta, "¿Quiero que el personal de TI vaya a las subestaciones para hacer esos parches?" Una vez más, la respuesta es no, porque una subestación es un entorno peligroso de alto voltaje que requiere un entrenamiento especial para navegar con seguridad. La solución: un sistema en red que le permite a TI parchar las computadoras de la subestación de forma remota. Este es solo un ejemplo de un proyecto que requiere que TI y operaciones trabajen juntos de manera efectiva.

Cuando se trataba de la creación, despliegue y mantenimiento de la red inteligente, Beberness y Heimgartner reconocieron que necesitaban un desglose claro de las responsabilidades entre TI y operaciones. "Cuando llegué aquí hace cuatro años, la organización de TI no apoyaba ninguna tecnología operativa", anota Beberness. "Chris y yo hablamos de lo que tenía sentido y dónde estaba la línea". En el caso de SnoPUD, la línea se sitúa entre las redes, servidores y parches del sistema operativo, de las que se encarga TI; y las estaciones físicas, tecnología de las comunicaciones y el software SCADA, que gestiona operaciones.

Para mantener todo correcto, y para asegurarse de que no quedaba nadie desinformado, los dos líderes crearon un diagrama RACI -responsable, consecuente, consultado e informado, por sus siglas en inglés- para establecer simplemente qué miembros de cada uno de sus equipos debía ser consultado y/o mantener el circuito sobre la toma de decisiones. "Consultados e informados es donde la mayor parte de los problemas surgen", señala Beberness.

"Llevamos a todos a una habitación de la que eran responsables y les dimos el diagrama RACI, y fue tan eficaz que desaparecieron las barreras de silos que tuvimos en torno a esas cuestiones", anota Heimgartner. Una razón por la que esto funcionó tan bien es que él y Beberness discuten todo y están muy alineados en sus propios puntos de vista sobre cómo TI y operaciones deben trabajar juntos. "La gente se da cuenta que Benjamin y yo no estamos en páginas diferentes", comenta.

La nueva red inteligente pasó su primera gran prueba a finales de agosto, cuando una enorme tormenta de viento azotó la región, derribando sucursales en todo el condado de Snohomish y cortando el suministro de energía a 175 mil clientes de SnoPUD -más de la mitad de la base total de clientes que es de 335 mil. El apagón tardó cinco días en resolverse por completo, señala Heimgartner, mientras que una interrupción menor en el 2006 tomó siete días y medio para arreglarse, y un corte similar en 1993 tomó 10 días.

"Parte de ello fue gente importante que abordó el problema", señala Heimgartner. "Otra parte fueron nuestros procesos -y otra parte fue la visibilidad que tenemos ahora con la red inteligente", finaliza.

Minda Zetlin, Computerworld (EE.UU.)