26 errores en la gestión de servicios

El día a día

Sí, asegurar que los servicios estén operando es labor de todos los días.

El tema es cómo lo logramos.

Buscamos realizar esta titánica labor considerando la coyuntura, presupuestos [de seguridad, entre otros], recursos, capacidades, compromisos, niveles de servicio existentes, proveedores, la propia organización –su modelo de gestión, su cultura.

Sabemos que los recursos son tanto materiales como humanos, tangibles como intangibles, y que son escasos.

Es más, las cosas pueden no ir tan bien como deseamos.

Además, reconozcamos que durante nuestra gestión también cometemos errores o estamos sujetos a problemas o a fallas.

Veamos.

Durante toda gestión existen errores o fallas

Error 01: no contar con un caso [real] de negocio

No olvidemos que al negocio le interesa ganar dinero, y que está en el ADN de los gerentes el invertir sobre la base de un caso de negocio.

Así, es mejor orientar nuestras necesidades de inversión en infraestructura de TI sobre la base de un enfoque de negocios, no sobre aspectos técnicos de la inversión.

En adición, todo caso de negocio debe propiciar valor para el negocio; entonces, implica que TODO caso de negocio debe estar apoyado por el un ejecutivo que lidere/apueste/necesite la propuesta.

Error 02: no realizar [nosotros] el planeamiento estratégico

Complicado si realmente no conocemos la estrategia del negocio ¿cierto? ¿Nosotros debemos buscarla o es algo que nos la tienen que proporcionar? ¿La entendemos, en toda su extensión? ¿Participamos en su formulación?

Lo cierto es que la planificación estratégica de TI debe estar firmemente enraizada en el plan estratégico del negocio. El mejor plan de TI ya no es simplemente un resumen de la inversión financiera requerida o una lista de tecnologías para implementar. Más bien, es una evaluación de los cambios exigidos para lograr los objetivos del negocio.

Los entendidos sugieren no encargar a alguien que lo haga por nosotros porque, finalmente, el entregable dormirá en algún estante; tal vez esperando presupuesto [que tal vez no llegará]; tal vez porque era un mero cumplimiento; tal vez porque el contenido no es lo esperado y, más bien, atenta contra el statu quo.

Tampoco es buena idea tratar que nuestros colaboradores implementen algo de lo que no han sido partícipes, de lo que no se sienten [porque no han sido] parte, o que se comprometan a aquello que consideran responsabilidad de otros.

Seguramente existen muchos otros posibles tal vez, quizá, intenciones, obligaciones. Cada organización los identificará. Lo cierto es que el entregable [el planeamiento estratégico de TI] no se pone en práctica; o, en todo caso, [como es usual] no resulta como se esperaba.

Para evitar esto, Gartner aconseja crear un proceso “claro y realizable” para desarrollar el plan estratégico, utilizando cualquier plan existente o usado previamente como punto de partida, planear rápido, enfocándonos en el mediano plazo, definiendo los componentes esenciales, desarrollando métricas para el éxito [estableciendo indicadores de rendimiento clave basados en resultados], atando los principios rectores a la visión corporativa, haciendo coincidir la frecuencia de la planificación con la marcha del negocio.

Error 03: presupuesto escaso o inapropiado

El presupuesto de TI dice mucho sobre sus propietarios: si los ejecutivos tienen una hoja de ruta para el futuro y si están dispuestos a pagar por ella, si los líderes de la compañía valoran la innovación, o si aún ven la tecnología como una función detrás de bambalinas.

Todo se reduce a la cuestión de si la empresa desea crecer y prosperar o si permite que sus competidores la dejan atrás.

Consideremos nuestro presupuesto en comparación con otros [realmente] similares en el mercado, en la medida de lo posible; entender [razonadamente] si es mejor el CAPEX por sobre el OPEX [o al revés], garantizando siempre que cada alternativa elegida cumpla con las normas contables; trasladando el gasto a las líneas de negocios [¿ABC costing? ¿conocemos realmente el costo/consumo del servicio provisto por cada unidad de negocio?] de manera que éstas estarían más interesadas en que sus inversiones rediman los resultados de negocio comprometidos.

Necesitamos asignar fondos para el presente (sostenibilidad operativa) y futuro (sustentabilidad, innovación, transformación digital, modernización de la tecnología, re-entrenamiento, actualización de procesos), sin olvidar asignar fondos para arreglar [mantener] lo legado.

Error 04: promover al candidato equivocado

No olvidemos que un candidato no sólo debe calzar en el puesto, sino que también debe calzar con la filosofía de la organización.

Así, la organización tiene que definir con claridad qué está buscando en términos de habilidades, carácter y competencias.

No son buenas razones promover por recompensa, o para proporcionar una línea de carrera, o para sentirse como un buen gerente.

Debemos elegir de forma inteligente.

Error 05: aplicar metodología ágil a los sistemas centrales

Y, sobre todo, cuando creemos que aplican donde se requiere un fuerte y riguroso control de cambios.

Por ejemplo, en servicios netamente de TI como correo electrónico, telefonía, ERP, aplicaciones de oficina, entre otros.

Tenemos que establecer límites claros –los riesgos son muchos, y mayores en impacto. La agilidad [velocidad] para los sistemas del negocio; rigurosidad [prudencia] para los sistemas nucleares.

Se necesita un enfoque disciplinado. Pensemos en una empresa bimodal. Entendamos el propósito de DevOps.

Según Gartner, las organizaciones deberían embarcarse en una “destrucción creativa”: replantear la arquitectura, los procesos y la gente que se requieren en el ámbito de tecnología para enfrentar las cargas de trabajo de la siguiente generación, incluyendo el IoT.

Error 06: subestimar riesgos

Y hasta no identificarlos oportunamente o no dimensionar [mejor] su impacto.

Uno de los primeros aspectos a considerar en la implantación de la ISO27001/ISO27002 es el análisis de riesgos, y establecer su gestión.

Probablemente necesitemos ayuda. Reconozcamos nuestras fortalezas y debilidades, y actuemos en consecuencia.

Error 07: cautiverio –de proveedores (internos o externos)

Por ejemplo, sabemos que las relaciones con los proveedores, tanto internos como externos, pueden ser frágiles, que podríamos quedar cautivos de ellos (bajos precios, innumerables promesas, supuesta integración, transición), vernos impactados por sus errores o fallas, estar sujetos a sus agendas ocultas, o hasta afrontar problemas de corrupción y sus implicancias legales.

Claro, todas las áreas internas relacionadas deberían tener presente lo que se espera de ellas (OLA), y no olvidemos lo que se espera [mejor dicho, requiere] de los proveedores externos (UC) con relación a la entrega del servicio.

Debemos garantizar para nuestro cliente [o usuario] el valor del servicio provisto. Y esto es una labor de todos, así como la seguridad de la información.

Muchas veces blandimos y hasta nos escudamos en leyes o regulaciones, normas o políticas, para ‘cumplir’ con nuestras funciones. Pero ‘seguimos’ estas leyes, regulaciones, normas, o políticas, de forma ciega, buscando [algunas veces] realizar el menor esfuerzo.

Error 08: la solución es la nube –por la nube

Tal vez pensamos que la nube es una buena opción [y lo es, si planeamos las cosas bien].

Todos hemos escuchado sobre los modelos de nube y sus ventajas.

Pero si creemos que adoptar un modelo híbrido conlleva simplicidad porque pensamos que este modelo de nube lo podemos administrar como una extensión de nuestro centro de datos, bueno, pensemos nuevamente –y planifiquemos mejor, factores como costo, disponibilidad requerida, estabilidad, requerimientos de configuración, niveles de servicio, licencias de software.

Empecemos por realmente conocer nuestro ecosistema, y de qué pie cojeamos. Hagamos un análisis de brecha.

Recordemos que la nube no es para todos, y tampoco para todo.

Mantengamos nuestras opciones, evitemos depender [o ser cautivos] de un solo proveedor de nube.

Error 09: contrataciones inadecuadas

Se requiere un equipo para construir una empresa exitosa, pero solo se necesita un empleado incompetente con una mala actitud para derribar a todos y a todos.

Debemos buscar contratar el nivel de destreza y habilidad requeridos para que el servicio proporcione el valor que se espera de él.

Error 10: no ser asertivo

Y, decir no cuando debemos decir no, pero de forma positiva –postergando la respuesta en lo posible.

No es que bloqueemos la innovación en la empresa, o busquemos detener su crecimiento.

Démonos tiempo para evaluar la sensibilidad, el impacto, los riesgos.

Decir que sí con demasiada frecuencia hace que sea imposible mantener todo parchado y en cumplimiento; generamos desconfianza.

Error 11: pecar de controlista

Si TI no está en el circuito cuando alguien en marketing o en alguna otra unidad de negocio lanza alguna iniciativa de shadow IT, bueno, aceptemos y reconozcamos que TI perdió el control hace años  y no puede recuperarlo; pero, avancemos, capitalicemos.

TI sigue siendo relevante, pero solo si se adapta. No dejemos que se piense que TI es únicamente quien mantiene operando el correo electrónico, y no es gravitante [no aporta valor] para el negocio.

Consideremos una adecuada verificación o aprobación de los equipos de TI o seguridad frente a este tipo de iniciativas. El objetivo no es evitar que existan, sino facultar a los equipos que decidieron utilizar estos servicios a cumplir con los requisitos mínimos de protección de datos establecidos en y por la organización.

Error 12: propiciar el oscurantismo

No perdamos credibilidad; garanticémosla.

Las malas noticias nunca mejoran por sí mismas. Y cuanto antes la gente empiece a lidiar con eso, tenemos más oportunidad de recuperar el proyecto y retomar el camino –o, al menos, perder menos.

Busquemos crear oportunidades para hablar con el director financiero y otros líderes empresariales cuando no están en modo crisis.

Error 13: elección incorrecta del outsourcing

Podríamos considerar que la elección de un servicio tercerizado simplifica nuestra labor. Y, dependiendo de nuestra organización, posiblemente esta premisa es correcta; pero, para un verdadero éxito, debemos tener presente los siguientes consejos:

  • Al tomar un servicio de TI, tomemos el tiempo necesario para comprender completamente nuestro rol como cliente para una relación de aprovisionamiento exitosa, en lugar de culpar [siempre] al proveedor del servicio. Si hicimos bien nuestra tarea de búsqueda inicial de un proveedor idóneo, identifiquemos la causa raíz y evitemos perder tiempo en cambiar de proveedores.
  • Enfoquemos nuestros esfuerzos en identificar el problema [analizar la demanda y el BIA], para el que requerimos una solución [o herramienta], y cómo podemos solucionarlo, antes de buscar soluciones en el mercado a las que después deberemos adaptarnos. Esto es, la solución debe resolver nuestra necesidad; principalmente, y lo mejor posible, no olvidemos el principio del 80/20.
  • La innovación empieza y termina en casa, no en el proveedor –y sus soluciones; así, debemos construir un ambiente y cultura que fomente eso, pero dentro de nuestra organización.
  • No hay plantillas, ya que cada organización es diferente, tiene problemas diferentes, y los afronta de manera diferente. Las mejores prácticas de outsourcing requieren determinar el alcance, el marco financiero y el perfil de riesgo adecuados para su empresa y sus objetivos, objetivos y cultura.
  • Durante la contratación, el objetivo de la negociación debe ser garantizar la alineación con los requisitos de la organización y no poner al proveedor en la situación más apretada. Esto, finalmente, juega en contra de la organización.
  • No subestimar el factor humano (en toda la empresa). Debemos planear para el cambio requerido en un entorno subcontratado, que [seguramente] requerirá una amplia supervisión ya que [seguramente] será significativo. Es vital comunicarse de manera activa y honesta, atendiendo las inquietudes y necesidades específicas del grupo de interesados.
  • No desestimar la transición, incluyendo procesos, sistemas, niveles de servicio, volúmenes, contratos y excepciones, y planifiquemos explícitamente el proceso de transferencia de conocimiento.
  • Implantar un modelo y marco de gobierno robusto, que incluya el equipo de gestión de entrega de servicios, los interesados en el negocio, los ejecutivos y el equipo de gestión del proveedor.
  • Gestionar el SLA, no blandir el contrato.

Error 14: presionar el outsourcing

Expectativas poco realistas y falta de gobernanza a intereses desalineados y mala comunicación son, usualmente, causas por las que no se alcanzan los resultados esperados, pero no las únicas.

Aumentar el desgaste de los recursos de outsourcing nunca es una buena señal. Puede ocasionar una alta rotación del personal del proveedor, disidencia interna, cambios en el liderazgo, apatía en la innovación, corrupción del alcance, fallas en cumplir los SLA, métricas inalcanzables, costos crecientes.

Los cambios frecuentes a menudo indican que el cliente, el proveedor o ambos no han podido establecer procesos de trabajo efectivos.

Mantener los canales de comunicación abiertos y fomentar un ambiente de confianza con los proveedores actuales ayudará a garantizar que los clientes estén al tanto si hay alguna actividad que impactarían negativamente en los resultados del negocio.

Error 15: no cerrar la brecha de habilidades –¿o debilidades?

Las empresas deben tomar algunas decisiones difíciles sobre cómo llenar las necesidades de personal y qué debe hacerse, interna y externamente; especialmente en seguridad.

Surgen las preguntas de siempre, pero no limitadas a las siguientes: ¿qué se hará? ¿será necesario capitalizar sobre nuestro personal clave? ¿será necesario tercerizar? ¿quiénes son candidatos? ¿a quién elegimos? ¿por qué la elección? ¿cuándo necesitamos? ¿cómo se hará? ¿cómo lo hará? ¿con qué? ¿para cuándo lo necesitamos? ¿hasta cuándo es necesario? ¿cuáles son los riesgos de no hacerlo? ¿cuáles son los riesgos al hacerlo? ¿hemos definido/acotado el alcance real/necesario? ¿quién será el responsable de rendir cuentas? ¿quién será responsable de ejecutar? ¿contamos con los procesos necesarios y suficientes, vigentes, actualizados, entendidos, realmente implantados [no sólo implementados]? ¿están las normas correctamente planteadas y apoyan las políticas? ¿las políticas apoyan esta ‘iniciativa’?

Error 16: ‘ahorrar’ en las capacitaciones

Actualmente, la premisa burda, errada y antigua de que mantenerse al día con la tecnología es responsabilidad de cada empleado, no es más vigente que antes.

Creemos ser efectivos al buscar un especialista con mucha experiencia y muchas certificaciones, y pretender pagarle centavos.

El mundo de este siglo habla de retención del personal clave como un factor estratégico, ya que las habilidades de este personal son el diferenciador clave para las organizaciones.

Si bien este personal puede ‘disfrutar’ de su trabajo, el reentrenamiento es muy útil para mantenerlo de esa manera.

Esto es especialmente cierto si la tecnología, que sabemos, cambia constantemente, y lo que queremos es reducir la curva de aprendizaje, asegurar la entrega de valor (con los servicios), garantizar la estabilidad de la plataforma tecnológica, que se incremente el valor de vida de los clientes, alcanzar los resultados que el negocio espera –y para los que ha comprometido recursos y capacidades.

Los profesionales de TI calificados, capacitados y certificados son esenciales para que las inversiones en tecnología redunden en obtener los resultados económicos que el negocio se ha planteado.

Error 17: no caracterizar TI

Las empresas deben tomar algunas decisiones difíciles sobre cómo llenar las necesidades de personal y qué debe hacerse, interna y externamente; especialmente en seguridad.

Y podemos caracterizar la disyuntiva (opciones, alternativas, problemas) con herramientas básicas como 6W-2H, matriz RACI, técnica MoSCoW, FODA, entre otras.

Error 18: adquirir ‘soluciones’ antes de establecer requisitos

Cuanto mejores sean los procesos de involucramiento/compromiso y soporte, más eficiente y productivo será el negocio, incrementará la satisfacción, la resolución de incidentes en el primer contacto, reducción en costos de soporte (por ejemplo, transporte, si se utilizan herramientas de soporte remoto apropiadas).

Conviene establecer los procesos antes que buscar una solución en el mercado. Apliquemos la regla del 80/20, y utilicemos cuantas herramientas estén a nuestro alcance.

Error 19: no establecer los procesos adecuados para que los servicios sobrevivan los cambios organizacionales

Porque, usualmente, estamos sujetos a alguna agenda oculta, que busca sus propios intereses, mantener la zona de confort, el statu quo, el feudo, el control local; pero sin interesar los resultados que el negocio espera.

Es así importante que las organizaciones identifiquen las necesidades reales de servicios e implante las acciones correctivas concretas requeridas, incluso organizacionales, en favor del negocio.

Gobernanza, auditorías, controles efectivos, son aquí mandatorios.

Error 20: considerar la seguridad como un proyecto –un producto terminado

Un reciente estudio de seguridad de Forrester descubrió que el 82% de las organizaciones tienen problemas para identificar y proteger los dispositivos conectados a la red. Peor aún, la mayoría no tenía claro quién es responsable de administrar los dispositivos.

Creemos que estamos seguros tras implementar una determinada seguridad –y nos engañamos pensando que este sentido de seguridad permanecerá en inmutable.

Seguimos cometiendo los mismos errores. Ahí están las diferentes noticias que de tanto en tanto nos llegan sobre violaciones perpetradas, incluso a grandes empresas.

Error 21: no haber establecido un modelo de seguridad de la información en la organización

Un modelo de seguridad de la información nos dice que tengamos presente:

  • La seguridad de los datos: estando almacenados, al ser procesados, cuando son transmitidos.
  • Los pilares de la seguridad de la información: confidencialidad, integridad, disponibilidad.
  • Capacitación, procesos, políticas, y su correcta y oportuna implantación.

¿Hemos considerado todo esto en nuestra actual plataforma tecnológica, en nuestros actuales sistemas de información? ¿Lo estamos considerando en un futuro cercano? ¿Hemos establecido una línea de tiempo? Si es así, ¿están los recursos y capacidades necesarios, entendidos, aceptados, y comprometidos?

Error 22: ignorar consejos básicos de seguridad de la información

Si se desea mantener la seguridad de toda la información de la organización, se deberán considerar activamente mínimamente los siguientes consejos de seguridad:

Error 23: confiar únicamente en el hacking ético como norma de seguridad

En seguridad, hay hermanos, mucho que hacer.

Empezando por casa, primero es hacer nuestra tarea; es decir, identificar y provisionar la seguridad en profundidad y líneas de defensa necesarias.

  • Incorporar mecanismos de control de acceso suficientes y apropiados.
  • Asegurar la vigencia de los mecanismos de autenticación y autorización.
  • No depender únicamente de los cortafuegos.
  • Implantar mecanismos [incluyendo políticas, procesos y sus procedimientos] contra código malicioso (malware), phishing, y todo tipo de X-ware pernicioso para la seguridad –y productividad.

Error 24: no gestionar correctamente el cambio

El cambio es una constante, especialmente en la era digital, ya que las tecnologías y las formas de trabajo que evolucionan rápidamente transforman el lugar de trabajo; y no entender que se necesita procesos establecidos y consistentes para gestionar el cambio, es una fórmula para el fracaso.

Sí, el miedo a lo desconocido, en el paradigma del cambio, puede ser una fuerza poderosa y negativamente motivadora; esperemos por tanto, resistencia al cambio, pero también afrontémoslo y gestionémoslo.

Pero, la transformación, bien llevada a cabo, representa nuevas oportunidades de crecimiento y ventaja competitiva.

Error 25: mantener [y hasta insistir en] una arquitectura de TI incorrecta [o inadecuada]

¡Imposible! ¡eso no ocurre en nuestra empresa! ¡todo está controlado! Bueno, así nos podrían decir los entendidos en TI; pero, para los no iniciados, ¿cómo podríamos darnos cuenta? Porque existe una o más de las situaciones siguientes:

  • Reingreso manual de [los mismos] datos, conducente a su inconsistencia –pero que calificamos de verificación y/o validación.
  • Colecciones de soluciones puntuales -que enmascaramos como ‘personalizadas’.
  • Aplicaciones redundantes que no ofrecen nuevas funcionalidades para el negocio.
  • Datos redundantes, y además inconsistentes, al no mantener la sincronización de datos en múltiples bases de datos de forma correcta, lo que genera un esfuerzo desperdiciado en las actividades de conciliación.
  • Necesitamos [nosotros] ‘interfacear’ con varias aplicaciones para realizar nuestras funciones u obtener un entregable, con el consiguiente error humano.
  • Debemos alimentar un sistema con los datos de otro –una acción propensa a errores si esta tarea no se automatiza lo suficientemente bien.
  • Tenemos, incluso, una configuración de software o hardware [o más] que, aunque poco elegante, ineficiente, torpe o [hasta] parcheada, tiene éxito [aparente] al resolver un problema específico o realizar una tarea en particular –y le denominamos ‘solución alternativa’.
  • Mantener tecnología obsoleta, que hace más difícil la integración con nuevos sistemas y equipos.

Consideremos, además, que, cuantos más sistemas y bases de datos tengamos, más interfaces terminaremos construyendo y que, cuantas más interfaces tengamos, más frágiles serán nuestros sistemas y, consecuentemente, más difícil será darles mantenimiento.

Claro, podemos resolver este dilema de múltiples interfaces con un elegante sistema de integración de aplicaciones empresariales, o un bus de servicios, o alguna otra forma de middleware-más-metadatos que mantenga todo limpio.

Pero consideremos que esta [y, para todo efecto, cualquier] engañosa integración [aunque elegante] es tan frágil y difícil de mantener como el exceso de interfaces.

Aumenta, por supuesto, nuestra incapacidad para adaptar los sistemas a los requisitos comerciales nuevos y cambiantes.

Incluso, las ‘soluciones alternativas’ vuelven frágil nuestro sistema e incrementa el costo de mantenimiento con cada solución innecesaria, al igual que el tiempo de inactividad, el costo de la capacitación del personal y la complejidad de cada proyecto posterior.

Estas situaciones, en mayor o menor grado, agotan los recursos de la empresa, la apartan de su actividad primaria de creación de valor, ralentizan los procesos del negocio, aumentan los costos de capacitación porque requieren interfaces del sistema, y las plataformas que las sustenten y que deben ser compatibles entre sí.

Consideremos que las planificaciones de arquitectura de TI a largo plazo ya son cosa del pasado. Recordemos, debemos tener un plan que sea flexible (habiendo escuchado las necesidades de nuestros patrocinadores e interesados), y considerar que probaremos y fallaremos, pero debemos hacerlo rápido, para recuperarnos aún más rápido y con mínimo impacto negativo –sobre todo en el aspecto de la seguridad.

Error 26: fallar en nuestro liderazgo

Cierto, ya conocemos las frases [motivadoras]: “hacer más con menos”, “sí podemos”, “es coyuntural”, “saldremos adelante”, “quedamos los buenos”, “eliminamos la grasa”, entre otras.

Buscan esconder, tras presionar fuerte por alcanzar [muy] buenos resultados, que la moral del personal se impacta negativamente.

Por ejemplo, como líderes:

  • Fallamos en comunicar [si acaso lo hacemos] completa, apropiada y oportunamente cómo cada actividad que realizamos se relaciona con los objetivos y la estrategia del negocio.
  • Fallamos cuando entre nuestros objetivos no se encuentra el incluir capacitación y otras formas de desarrollar habilidades técnicas y / o comerciales, mínimamente al colaborador clave –se supone que los que quedan, son clave ¿verdad?
  • Fallamos si demoramos en proporcionar las herramientas en cantidad suficiente y con las características necesarias, si acaso lo hacemos.
  • Fallamos si no buscamos identificar, priorizar, y automatizar las tareas repetitivas.
  • Fallamos si no identificamos, desarrollamos e implantamos formas innovadoras para que el usuario [cliente] se auto-atienda –es decir, ahorrar tiempo para todos, justamente para hacer más.
  • Fallamos si continuamos seleccionando indicadores de rendimiento solamente importantes para TI y no para el negocio.
  • Fallamos cuando agotamos a nuestros colaboradores cada vez que insistimos en asignarles proyectos con poco tiempo de aviso, sin presupuesto y no previstos, con requisitos olvidados, sujetos a complicaciones imprevistas, mala gestión y errores humanos [como el código incorrecto] sin tener en cuenta [considerar] los que ya tienen en sus portafolios pendientes de entregar.
  • Fallamos si no propiciamos que nuestros colaboradores celebren las victorias rápidas –y, como gestores, además nos las apropiamos.
  • Fallamos en describir las contribuciones que cada uno de nuestros colaboradores puede hacer para entregar resultados hasta el siguiente nivel.
  • Fallamos cuando evitamos que cada colaborador reconozca el valor de los logros de los objetivos y cómo sus contribuciones afectan la realización de los beneficios esperados
  • Fallamos cuando insistimos en el micro control del colaborador –hostigando incluso. ¿Delegamos mal?
  • Fallamos al no considerar enfoques y métodos nuevos, y nos cegamos ante soluciones más simples que se alinean mejor con los procesos comerciales y son mucho más fáciles de implementar. ¿Ego?
  • Fallamos mientras sigamos considerando a nuestros colaboradores como recursos complementarios (Gestión 1.0) o sólo gestionamos procesos (Gestión 2.0), y no reconocemos la complejidad del entorno operativo actual y el poder de personas motivadas y motivadas para resolver problemas (Gestión 3.0).
  • Fallamos cuando pecamos de auto-suficientes, soberbia, o [incluso] negligencia, y no buscamos ayuda externa.
  • Fallamos cuando no entregamos el resultado esperado por el negocio. Podemos ser eficaces y hasta eficientes, pero si no somos efectivos [apreciación de nuestro cliente o usuario], fracasamos, lo que impacta negativamente nuestra credibilidad, imagen, reputación, ganancias o ingresos.

Y luego nos quejamos de alta rotación del personal, baja en el rendimiento, reducción de la calidad de los entregables, incremento de errores, deterioro de la credibilidad, entre otros factores negativos.

Y, para concluir

Busquemos un sentido de pertenencia, para lograr compromiso.

No olvidemos ser transparentes, tengamos una cultura de apertura, busquemos ser resilientes, mantengámonos abiertos al debate.

De lo contrario, las expectativas de los patrocinadores e interesados no se verán satisfechas; tampoco se alcanzarán los resultados que el negocio espera; menos entregaremos el valor que los usuarios y clientes esperan de los servicios que reciben.

ITIL®, COBIT®, PMBOK®, entre otros frameworks

Sabemos que para gestionar las TI existen diferentes framework o marcos. Están también los viejos conocidos como COBIT® y el PMBOK®.

Recordemos que un marco es una estructura real o conceptual destinada a servir como un soporte o guía para la construcción de algo que expande dicha estructura en algo útil. Es necesaria para evitar re-inventar la rueda (la tecnología, y su eficiencia) y enfocar esfuerzos (recursos, capacidades, presupuestos, entre otros) en las reglas del negocio. La necesidad de emplear un marco es variable, y hasta cierto punto. No olvidemos que hay que adoptar y adaptar las cosas a nuestra realidad.

Por ejemplo, ayer un exalumno estaba esperando rendir su examen de certificación en ITIL® Fundamentos, el cual aprobó, y me contó mientras esperaba, que recién con el curso que le di entendió todo lo que en su empresa existía desplegado referente a ITIL®.

Bueno, lo cierto es que ITIL® estaba desplegado, implantado, pero no estaba interiorizado, no había sido adoptado. Este mismo exalumno lo reconoció. Los usuarios internos no tienen conciencia de por qué hacen las cosas; simplemente las hacen -cumplen. Los que apoyan o administran los servicios, tampoco, ya que se preocupan por que sus ‘indicadores’ no arrojen resultados negativos. En general, la empresa no entiende lo que es una apropiada gestión de servicios –y este ex alumno me comenta que hay varios certificados en ITIL. Esto último es una mala propaganda y por ello muchas empresas no confían en las buenas prácticas de ITIL (no ahondaré si es la empresa la que ocasiona esto con su cultura o es producto de una adecuada aplicación). Los usuarios utilizan las herramientas principalmente para controlar tickets. Aparte de utilizarla mal, encima desconocen las verdaderas capacidades de la herramienta. Los nuevos usuarios no son capacitados; la capacitación utiliza el método Inca (de boca en boca); y otras situaciones que me enteré. Una pena, por la empresa y por sus clientes –mi opinión, ya que no importa cuán brillante es el producto o si hace mil cosas; si no estamos proporcionando el resultado que el usuario final espera (el valor del servicio que está pagando), estamos fracasando. Una noticia al respecto aquí (ojo, no es la empresa de la que hablo) que generan costos innecesarios de compensación y remediación, querellas judiciales, pago de moras, auditorías inopinadas, pérdida de beneficios, demandas judiciales, entre otros aspectos negativos. No es de extrañar saber de proyectos ‘de éxito reservado’, por asignación inadecuada o inoportuna de recursos, plazos excesivamente agresivos –algunas veces exigidos sin base o beneficio para el negocio, costos subestimados, requisitos olvidados –o mal identificados, complicaciones imprevistas –que no faltan, un mal gobiernos, y los [consabidos y omnipresentes] errores humanos como código defectuoso.

Lo anterior nos hace preguntarnos ¿para qué me servirá aplicar el marco tal o cual? Ojo, aplicar, no imponer. Resulta obvio revisar nuestra necesidad concreta y el enfoque de nuestra necesidad, alternativas –reales- de solución, compromiso con la adopción correctamente elegida, no mero cumplimiento –o moda.

Recordemos que hay una herramienta correcta para cada necesidad, la cual debe utilizarse en el momento preciso y por quien conoce cómo utilizarla –desde la primera vez.

Al igual que con cualquier proyecto, siempre se debe mantener las líneas de comunicación abierta entre las distintas partes, medir y monitorear el progreso de la implementación y buscar ayuda externa si es necesario.

Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

Cómo crear un plan contra violación de datos en 9 pasos

Cómo crear un plan contra violación de datos en 9 pasos

Primero tengamos presente que se pueden considerar varios escenarios posibles en un plan contra violación de datos.

Esto porque no podemos anticiparnos a todas las situaciones posibles en que un determinado hackeo se puede desarrollar, y aun así este plan debe ser flexible, como un planeamiento para la recuperación de desastres y planificación de continuidad de negocio (la colaboración en lugar del aislamiento) –y veremos que es muy parecido. Interesante, varios proyectos pueden salir de este esfuerzo.

De hecho, conviene realizar un análisis de los procesos de negocio y las necesidades de continuidad, sin olvidar las necesidades de seguridad de la información, algo que cada empresa debe emprender, y dependerán de los objetivos de la organización sobre el punto de recuperación (RPO) y el tiempo de recuperación (RTO).

Bueno, al grano –y con anticipación porque es importante, de modo que podamos reducir las urgencias o el riesgo durante las urgencias.

  1. Sabemos que debemos empezar con una evaluación de riesgos, para priorizar qué sistemas recuperar y restaurar primero (establecer los componentes esenciales –inventario de por medio del hardware necesario y del software requerido para restaurar la producción; los datos, su tipo y sensibilidad, almacenado/procesados/transportados haciendo uso de estos componentes) –porque ponernos a pensar durante la emergencia podría ser contraproducente. Conviene realizar un análisis de impacto sobre el negocio (BIA) para identificar los procesos críticos (con sus procedimientos por supuesto) y priorizarlos de acuerdo con su impacto en la organización.
  2. No olvidemos implementar controles preventivos (con sus procesos estandarizados, normalizados, documentados), como primer paso tras analizar las brechas, de seguridad de la información, y de recursos y capacidades existentes (financieros, organizacionales, de personal, competencias, experiencia, entre otros).
  3. Conviene establecer umbrales y adecuarlos a los niveles correspondientes de respuesta que hayamos establecido –o que podamos establecer, así como los criterios de evaluación correspondientes al tipo de datos que se verían comprometidos, con base en nuestros recursos y capacidades internos o los que podamos conseguir.
  4. Así como los médicos en la sala de urgencias seleccionan y clasifican a los pacientes para evaluar la prioridad de su atención de acuerdo con sus posibilidades de supervivencia y recursos disponibles, igual debemos realizarlo nosotros, determinando el alcance de ese impacto, cuáles son los sistemas más importantes (misión crítica) y datos (más importantes) y que, por lo tanto, necesitan atención en primer lugar, cómo aislar y proteger los datos (nivel de seguridad necesario para los datos y aplicaciones, ubicación), y cuánto tiempo se espera que dure la interrupción –antes de activar otros medios de continuidad.
  5. De hecho, debemos construir flexibilidad de modo que la empresa pueda responder de la manera que, coyunturalmente (no siempre contará con los recursos y capacidades suficientes o apropiados), le convenga (para no incurrir en problemas legales por incumplimiento con la ley de protección de datos personales, por ejemplo).
  6. Es muy importante establecer, difundir, y mantener vigente la matriz RACI correspondiente, y que ésta sea lo más granular posible, para asegurar que los roles, funciones, y responsabilidades (del personal clave tanto interno como externo, y de apoyo, considerando su disponibilidad y la capacidad de su ubicación oportuna) sobre un conjunto de actividades sean conocidas, claras, justas, entendidas, asumidas, adoptadas, interiorizadas, comprometidas, evitando una situación de juez y parte. Por ejemplo, habría que identificar las personas en la organización que tienen la autoridad para declarar un desastre y por ende, colocar el plan en efecto.
  7. No olvidemos detallar cuándo y cómo invertir en el equipo ejecutivo de gestión de crisis para que se cumplan los requisitos legales y normativos adecuados con respecto a las infracciones de datos. Las personas de relaciones públicas de la compañía pueden ayudar a informar adecuadamente a los clientes y consumidores.
  8. El negocio deberá establecer sistemas alternativos, como decidir cuál de las funciones de la organización son esenciales, y repartir el presupuesto disponible conforme a este criterio, o a establecer acciones manuales (considerando por supuesto la sensibilidad de los datos) que se disparan ante un evento, en la medida que sea posible lo que requeriría posiblemente un esfuerzo de capacitación adicional.
  9. Por supuesto, debemos ejecutar simulacros [lo más reales posibles] de eventos basados en tipos específicos de desastres [no idea, sino realidad], incluyendo brechas de seguridad. Así, la organización deberá proveer los recursos necesarios, establecer si necesita ayuda externa, planificar y programar los simulacros (al elefante nos lo comemos por tajadas), difundir su realización, establecer las estrategias de recuperación, diseñar los escenarios, priorizarlos, evaluar cada qué tiempo realizarlos y obtener la autorización del cuándo realizarlos (no vaya a ser que programemos una prueba justo cuando existe en el mismo día un evento crucial para la organización), cómo los va a realizar (la creación previa de plantillas de verificación ayuda a simplificar este proceso), afinar los planes y mantenerlos vigentes (como dijo Dwight ‘Ike’ Eisenhower, “el plan es nada, la planificación lo es todo”), entre otros factores.

Revisemos lo de cultura de productividad

Una de las premisas de la propuesta lean es que se debe fallar rápido. Ojo, no bastante, que es lo que veo cuando reviso los reportes de QC de la organización donde laboro. No se preocupen, como en otra entidad donde hace unos años hubo oportunidad de realizar mejoras, ya estoy involucrándome aquí.

Este concepto de fallar rápido (o probar temprano) también se asocia con las diferencias entre los enfoques de cascada (que propicia una entrega final y completa, y que funciona bien cuando la demanda es [o era] estable[1]) y ágiles (que propicia entregas incrementales, y donde se requiere personal con versatilidad y agilidad de aprendizaje) para el desarrollo de software[2]. Inherentemente, propugna que el conocimiento obtenido de un intento fallido en realidad aumenta la probabilidad de un eventual éxito.

Claro, debemos tener en cuenta las especializaciones, certificaciones, cultura organizacional, apetito por el riesgo, orientación, vocación, necesidades propias de la empresa, demanda de ciertas habilidades (encontrar el candidato perfecto con exactamente las calificaciones adecuadas, la educación y las expectativas salariales puede ser una tarea desalentadora – si no imposible[3]), preponderancia de género[4], esquemas de reclutamiento, línea de carrera, motivación, incentivos, entre otros, y no sólo de la empresa, importante considerar al diferenciador clave por sus capacidades individualizadas: el colaborador comprometido.

Al respecto, hoy escuché que si alguien está interesado por la calidad, aporta a ella. Es un buen pensamiento. Lo lamentable es que el equipo de calidad tuvo que ser llamado por ese alguien porque ninguno había  comenzado a trabajar. Lo peor, en mi opinión, es que ese alguien evidenció que la calidad le interesaba por motivos egoístas de ganar un premio –como ya lo había hecho antes. Bueno, todos trabajaremos en disque mejorar la productividad de unos pocos para satisfacer el ego de un alguien que muy pronto se retira de la institución y desea dejar a su sucesor sólo la tarea de presentar la documentación para la evaluación del premio. Me pregunto si habrán pensado en la sostenibilidad y sustentabilidad futuras.

El departamento de TI debe cambiar su conjunto de habilidades[5], no sólo por el advenimiento de la nube y su posible [o ya existente] adopción, sino porque los cambios exigidos por el entorno serán cada vez más frecuentes y diversos e impactarán incluso en la seguridad de la información o, por lo menos, en cómo la manejamos, incluso cuando vivimos hoy una cultura global de movilidad y cuya gestión no puede permanecer estática[6]. De hecho, Gartner nos informa que en 2017[7], cada organización tenderá a contar con una mezcla de cinco plataformas tecnológicas digitales: Sistemas de información, experiencia del cliente, análisis e inteligencia, Internet de las Cosas y ecosistemas empresariales. Debemos tomar en serio la gestión del riesgo de TI (no sólo el riesgo cibernético y el cumplimiento). Tengamos presente que las organizaciones están desarrollando iniciativas de transformación digital para mejorar los procesos de negocios, servicio al cliente[8], entre otras. Así, resulta vital asegurarnos que nuestro equipo de TI esté comprometido con la estrategia digital de la organización[9].

Como dijimos, el tema es aprender, transformar información en verdadero conocimiento y éste en sabiduría. Lo único constante es el cambio (Heráclito)[10]. Algunas mejores prácticas apoyan en esto del cambio a través de la formulación y operación de servicios; otras mejores prácticas permiten lograrlo a través del desarrollo de proyectos.

[1]  Fuente: http://searchcio.techtarget.com/tip/CIO-outlook-2017-Five-elements-of-the-new-IT-operating-model?utm_medium=EM&asrc=EM_NLN_70027032&utm_campaign=20161221_CIO%20outlook:%20Five%20imperatives%20for%202017&utm_source=NLN&track=NL-1808&ad=911795&src=911795; disponible en dic/2016

[2]  Fuente: http://whatis.techtarget.com/definition/fail-fast; disponible en dic/2016

[3]  Fuente: http://searchcio.techtarget.com/definition/IT-skills-gap-information-technology-skills-gap; disponible en dic/2016

[4]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Industria-de-datacenter-enfrenta-crisis-de-habilidades-al-reemplazar-a-ingenieros; disponible en dic/2016

[5]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Diez-tendencias-de-la-nube-para-2017-segun-Tableau; disponible en dic/2016

[6]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Los-administradores-de-servicios-de-TI-ven-un-rol-para-ITIL-en-la-transformacion-digital-del-negocio?utm_medium=EM&asrc=EM_EDA_69283048&utm_campaign=20161207_El%20rol%20crucial%20de%20ITIL%20en%20la%20transformaci%C3%B3n%20digital&utm_source=EDA; disponible en dic/2016

[7]  Fuente: http://www.gartner.com/smarterwithgartner/gartners-top-10-technology-trends-2017/; disponible en dic/2016

[8]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Las-iniciativas-de-transformacion-digital-cosechan-valor-de-negocios; disponible en dic/2016

[9]  Fuente: http://searchdatacenter.techtarget.com/es/consejo/Cuatro-formas-de-crear-impulsores-de-valor-para-la-tecnologia-digital?utm_medium=EM&asrc=EM_EDA_69897476&utm_campaign=20161219_Principales%20tendencias%20de%20almacenamiento%20de%20datos%20para%202017&utm_source=EDA; disponible en dic/2016

[10]                Fuente: http://www.asesoriaterapeutica.com/blog/187-%E2%80%9Clo-%C3%BAnico-constante-es-el-cambio%E2%80%9D-her%C3%A1clito.html; disponible en dic/2016

Ah! la eficiencia –hacia una cultura de productividad

Peter Drucker dijo que la eficiencia es hacer bien las cosas[1].

El pensamiento lean[2] (sin grasa, ¿recuerdan el término de los ’90?) es lograr hacer las cosas correctas[3] dijo Pascal Dennis, teniendo como base fundamental para este “hacer” a los equipos de trabajo, y al cliente como centro[4] porque es el cliente quien define lo “correcto”, de modo que, en una cadena de producción o en la provisión de un servicio, aseguremos que sólo se usen recursos que agreguen valor al cliente final[5].

Desde un punto de vista productivo, el pensamiento lean busca eliminar desperdicios como: tiempos de espera innecesarios (entre etapas del proceso, plazos inadecuadamente comprometidos); por defectos (que tras una inspección –o varias- generan correcciones, iteraciones entre desarrollo del producto o servicio y el control de calidad); por movimientos innecesarios (de materiales en físico cuando puede emplearse medios digitales); mantener un inventario innecesario (inmovilizado ‘por si acaso’, excedente, no sólo de materia prima sino también de herramientas); por el procesamiento innecesario (muchas manos, pocos o ningún responsable, criterios no establecidos, delegación/empoderamiento inadecuado) o manipulación innecesaria (incremento de riesgos, accidentes, errores que se busca subsanar al final y no en la fuente[6] o de inmediato); por el transporte (o desplazamiento del colaborador cuando una acción remota puede ejecutarse) para su entrega al usuario final (cuando se puede emplear métodos alternativos como vídeo conferencia); y, por supuesto, sobredimensionamiento.

Desde el punto de vista de TI, en la era digital, el mandato de la tecnología se ha convertido en liderar como una ventaja competitiva a través de la diferenciación de [recursos y] capacidades y velocidad para explotar los cambios en los negocios[7]. En la siguiente figura se muestra cómo la TI empresarial propicia el cambio en el negocio, transformándose entre el paradigma tradicional (gestionar un proyecto para [buscar] garantizar el éxito de implementar una metodología secuencial, para entregar eficientemente el cambio de negocio a gran escala) y el paradigma digital (mentalidad en el producto, implementando una metodología iterativa, entregando cambios en pasos más pequeños, rápidos, confiables y eficientes):


picture4-100664754-orig

Fuente: http://www.cio.com/article/3078824/leadership-management/is-your-it-ready-for-the-digital-age.html

Esto implica ser adaptables y flexibles[8] como lo exige el ecosistema actual, en cuanto a la entrega de servicios, seguridad de la información, gobierno –recordemos que el valor diferencial de una compañía radicará en cómo gestiona y explota su información[9], más que en cómo gestiona la tecnología con paradigmas operacionales[10] obsoletos[11].

Requerimos entonces una TI eficiente. Pero también implica que debemos eliminar lo que no aporta, y tenemos una TI lean –lo que implica un cambio de paradigmas, de mentalidad, de procesos, como lo demostró Toyota, no de la fuerza laboral[12].

En la siguiente figura se muestra el valor incremental de la TI lean sobre la TI eficiente:

lean-it-levers-100687430-orig

Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html

El siguiente extracto del artículo es particularmente ilustrativo: “La calidad genera valor al abordar problemas en la fuente. Piense en una gota de tinta en una piscina. Con una acción rápida, la tinta se puede limpiar con una sola inmersión de un cubo. Si se retrasa, la tinta se difunde por toda la piscina y requiere que el agua de la piscina sea reemplazada por completo. Del mismo modo, los defectos que permanecen en el sistema bastante tiempo causan nuevos defectos, y una corrección se vuelve exponencialmente más costosa”.

El 2016 State of DevOps Report[13] nos recuerda que hay mucho más en el rendimiento de TI que en las prácticas técnicas. Con el fin de crear un alto rendimiento sostenido, las organizaciones necesitan invertir tanto en sus personas y procesos como lo hacen en su tecnología. Entre sus conclusiones cuentan que la seguridad es una parte integral de la entrega continua, que, al incorporar calidad y seguridad en el ciclo de desarrollo de software, las empresas de alto rendimiento gastan menos tiempo en trabajos no planificados, que estas empresas pasan menos tiempo resolviendo problemas de seguridad y pasan más tiempo en nuevos trabajos de valor añadido, entre otros factores distintivos.

Analicemos nuestra brecha digital y comprometámonos a cerrarla –rápido (consolidación, habilidades digitales, servicios gestionados, servicios compartidos, costo total de propiedad, entre otros aspectos[14]).

[1]  Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html; disponible en dic/2016

[2]  Fuente: http://aelit.congresoaelit.com/; disponible en dic/2016

[3]  Fuente: https://www.lean.org/WhoWeAre/LeanPerson.cfm?LeanPersonId=45; disponible en dic/2016

[4]  Fuente: http://aunclicdelastic.blogthinkbig.com/lean-it-una-declaracion-de-objetivos/; disponible en dic/2016

[5]  Fuente: http://www.ibermatica.com/sala-de-prensa/opinion/lean-it-aplicando-experiencias-industriales-para-la-mejora-de-la-eficacia-it; disponible en dic/2016

[6]  Fuente: http://www.cio.com/article/3143195/it-strategy/whats-next-for-enterprise-it.html?idg_eid=0f3e0907b81179ebb4f3b209b6424bae&token=%23tk.CIONLE_nlt_cio_enterprise_2016-11-30&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Enterprise%202016-11-30&utm_term=cio_enterprise#tk.CIO_nlt_cio_enterprise_2016-11-30; disponible en dic/2016

[7]  Fuente: http://www.cio.com/article/3078824/leadership-management/is-your-it-ready-for-the-digital-age.html; disponible en dic/2016

[8]  Fuente: http://www.cio.com/article/3143195/it-strategy/whats-next-for-enterprise-it.html?idg_eid=0f3e0907b81179ebb4f3b209b6424bae&token=%23tk.CIONLE_nlt_cio_enterprise_2016-11-30&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Enterprise%202016-11-30&utm_term=cio_enterprise#tk.CIO_nlt_cio_enterprise_2016-11-30; disponible en dic/2016

[9]  Fuente: http://www.silicon.es/lean-it-una-futura-tecnologia-delgada-y-valerosa-2209541; disponible en dic/2016

[10]                Fuente: https://www.standishgroup.com/sample_research_files/Modernization.pdf; disponible en dic/2016

[11]                Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/innovation-strategy/pdfs/ceb-strategy-putting-the-strategy-back-in-strategic-planning-summary.pdf; disponible en dic/2016

[12]                Fuente: http://www.cio.com/article/3146921/it-strategy/its-not-the-workforce-but-the-system-that-needs-a-fix.html; disponible en dic/2016

[13]                Fuente: https://techbeacon.com/sites/default/files/gated_asset/2016-state-of-devops-report.pdf; disponible en dic/2016

[14]                Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html; disponible en dic/2016

Transformación digital

McKinsey[1] nos dice que la transformación es quizás el término más usado en los negocios. A menudo, las empresas lo aplican libremente, a cualquier forma de cambio, por pequeño o rutinario que sea.

Así, el término “transformación digital” se ha utilizado para describir cualquier cosa, desde una aplicación técnica hasta el desarrollo de una estrategia de medios sociales, pero en realidad la verdadera transformación necesita involucrar mucho más que el producto final[2].

Veamos.

Las empresas han evolucionado, como lo muestra la siguiente figura, que propone una combinación de fuerzas económicas y tecnológicas que han cambiado el mundo y han creado y crean disrupción –nadie está a salvo. Interesante el trío de tecnologías habilitadoras:

the-digital-enterprise-wave

Fuente: High Level Digital Transformation Diagnostic, Agile Elephant

Forrester[3] nos alerta que el mundo se ha vuelto digital ‑la competencia se basa cada vez más en la fuerza de sus experiencias digitales y negocios digitales. Así, buscamos realizar hoy una transformación digital para competir mañana y lo hacemos por diversas razones:

  • Porque hemos fallado en evolucionar como empresa, nuestros proyectos no han sido exitosos, y es una cuestión de transformar o perecer[4], ya que la competencia lo está haciendo. Forrester nos informa que 46% de los ejecutivos encuestados por creen que para el año 2020 lo digital tendrá un impacto en más de la mitad de sus ventas[5].
  • Porque buscamos crecer. PWC[6] nos informa lo que los negocios realmente quieren tras esta iniciativa: aumentar las ganancias; aumentar los ingresos; crear una mejor experiencia del cliente.

pwc-chasing-digital-value

Fuente: PWC, 2015 Digital IQ Survey

  • Porque es una transformación del negocio lo que buscamos siendo que lo digital está [o debería estar] ya imbuido en el negocio y porque lo digital está muy arraigado en el consumidor actual o, como dice Altimeter[7] “un realineamiento de modelos de negocio y procesos para generar un nuevo valor para los clientes y empleados con el fin de competir efectivamente en una economía digital en constante cambio” –lo que podría potencialmente abarcar a todos los clientes.
  • Porque los proyectos de transformación digital deben producir algo valioso para el consumidor y el negocio y esto requiere de una visión clara del líder para que el negocio la compre y se comprometa, ‑porque si no, nada se transforma. Liderar el cambio digital requiere que los gerentes tengan una visión de cómo transformar su empresa para enfrentar un mundo digital. Algo valioso para el usuario podría ser, por ejemplo, la experiencia en la navegación y personalización, considerando además un muy probable comportamiento cambiante. Para el negocio, algo valioso podría ser, por ejemplo, una capacidad superior de analítica de datos (grandes volúmenes de datos y una aplicación avanzada), integración de tecnologías, agilidad y flexibilidad operativas para enfrentar nuevos requerimientos –teniendo siempre en cuenta el costo total de propiedad.
  • Porque buscamos una manera de decir que nos movemos a la nube [primero[8]], en cuyo caso, deberemos conocer los pasos que deberemos seguir, determinar si debemos crear nuevos puestos de trabajo o contratar consultorías especializadas, establecer la garantía del servicio, por ejemplo.

Lo cierto es que la transformación digital es imperativa para cualquier negocio, grande o pequeño ‑declaración bastante trillada además. Pero tengamos presente que la transformación digital implica invertir en la tecnología que sea y cuando sea apropiada, porque la tecnología por sí sola no es una solución –es un medio, no una estrategia; es un viaje, no un destino.

Según un artículo del MIT Sloan Management Review[9], cuanto mayor sea la madurez digital de una empresa, mejores serán sus resultados financieros. La madurez digital está dada por la intensidad digital, que es el nivel de inversión en iniciativas que son posibles con la tecnología y que significan cambiar la forma en que opera la empresa; y por la intensidad en la gestión de la transformación, que es el nivel de inversión en las capacidades de liderazgo necesarias para crear la transformación digital dentro de una organización, y el gobierno correspondiente. Y Deloitte[10] nos dice que es la estrategia digital la que impulsa la madurez digital, y la agenda digital se conduce desde arriba. El líder digital debe tener la capacidad de articular el valor de las tecnologías digitales con el futuro de la organización –no precisamente ser un experto en tecnología. Las empresas van desde una madurez temprana, pasando por un estado de desarrollo de la madurez, y van madurando digitalmente.

De hecho, PWC ha identificado las siguientes diez capacidades críticas que se correlacionan con un fuerte rendimiento financiero –evidentes, por cierto, todos los puntos, y especialmente el de ciberseguridad: liderazgo, de arriba para abajo, compromiso, estrategia compartida en toda la organización, abordar los temas desde afuera, impulsado por la ventaja competitiva, uso eficiente de los datos del negocio (analítica, tecnología adicional a las propuestas por Agile Elephant: nube, social, móvil), ciberseguridad, ruta digital clara, medición consistente y continua.

digital-iq-survey

Fuente: PWC, 2015 Digital IQ Survey

Crear una nueva forma interna de trabajar y comunicarse es parte del proceso. Es un cambio cultural para muchas organizaciones. Las personas, sus habilidades y la cultura de la organización son esenciales para que una transformación tenga éxito. Agile Elephant[11] nos sugiere emplear el modelo de las 7 S de McKinsey[12] para diseñar la transformación, y no olvidarnos de la parte “blanda” anterior, ya que usualmente nos enfocamos sólo en la parte “dura”, y es que la transformación digital es un problema de personas, y agregaría, motivadas:

mckinsey-7-s-model

Debemos fomentar la innovación [sin grandes volúmenes de datos de calidad que “alimente” la innovación, el proceso se detendrá], la capacidad de innovación, y nuevos modelos de negocio[13], buscar cambiar la organización de un enfoque legacy a nuevas formas de trabajar y pensar usando tecnologías digitales, sociales, móviles y emergentes con la finalidad de propiciar cambios en las relaciones con clientes, procesos internos y propuestas de valor[14]. Lo cual implica, según Gartner[15], modernizar las aplicaciones nucleares, extender las capacidades de estas aplicaciones, transicionar a nuevos modelos de consumo como SaaS, entre otras posibilidades de abordar el tema. Gartner también nos sugiere construir software diferenciado, innovador y no estándar o software con servicios profesionales (para requisitos de personalización e integración), o soluciones cada vez más originarias de empresas emergentes, disruptores o proveedores locales especializados, y no comprar aplicaciones ya hechas. ¿No les parece una ola esto?; es decir, ¿no lo habían escuchado antes?

Operar dentro de los límites de los paradigmas tradicionales sin propósito ni visión desafía finalmente la dirección, la capacidad y la agilidad para prosperar en una economía digital. El camino hacia la transformación suele ser moldeado por la persona o el grupo que dirige el esfuerzo, lo cual puede limitar la implementación de una transformación holística, persistente y significativa en toda la empresa; por ejemplo, impulsando las inversiones digitales desde una perspectiva operativa o tecnológica sin la empatía del cliente o el conocimiento de cómo y por qué las nuevas expectativas, preferencias y valores que generan la disrupción de los mercados. Crean lo que Schumpeter acuñó como “destrucción creativa”[16].

El cambio cultural requiere que las organizaciones desafíen continuamente el statu quo, experimenten a menudo –tomar riesgos es una norma cultural, y se sientan cómodos con el fracaso. El compromiso con los empleados y gerentes necesita tener un contexto, una visión y un llamado a la acción que resuene con cada persona individualmente. Este tipo de personalización es lo que motiva a una fuerza de trabajo. La incorporación de los procesos y enfoques de trabajo de la transformación en actividades cotidianas deben darse desde el inicio de la transformación para asegurar que el impulso del rendimiento continúe acelerándose después de la transformación.

Además, necesitamos saber dónde está ocurriendo el cambio[17], dónde tiene el mayor impacto –y cuán rápido está ocurriendo. Es importante mirar más allá de su propio sector: la interrupción digital no respeta las fronteras de la industria.

La optimización del contacto que tiene el cliente con la marca obliga a una empresa a identificar todas las herramientas y tecnologías –apropiadas para la tarea, procesos, capacidades y transiciones necesarias para ofrecerle una gran experiencia[18] -e incrementar el valor de vida del cliente[19] por supuesto.

La forma en que las organizaciones han estado planificando y administrando cambios a gran escala ya no funciona, se necesita ahora un enfoque iterativo, ágil (el ritmo del cambio en el mundo digital es [muy] rápido), automatizado, basado en los resultados y orientado a la experiencia del cliente. La transformación no es ensamblar cosas o combinar soluciones de las plataformas empresariales existentes. Es cuestionar cómo funciona la estructura y lo que se necesita para hacerlo mejor, no sólo reunir todo lo existente –incluyendo lo legacy- de formas diferentes –o “innovadoras”.

Así, es vital: la colaboración interna; la creación de procesos holísticos y no fragmentados[20] que apoyen la visión, no sólo la propuesta de actividades o metas; la creación de equipos multifuncionales que integren diversas funciones en el negocio, conformados por el personal correcto y adecuado para ejecutar la estrategia[21], competente, bien entrenado y capacitado, con la mentoría apropiada, o los proyectos fallarán; el desarrollo de incentivos para compartir por una entrega –final- exitosa; y cuidar de no subestimar necesidades o recursos y capacidades.

Para crear impulso, los equipos multifuncionales necesitan un apoyo visible de la alta dirección, un mandato claro para hacer las cosas con el empoderamiento oportuno y apropiado, suficientes recursos para construir un programa de trabajo donde las inversiones deberían estar ligadas al progreso y no a ciclos presupuestales fijos, y responsabilidad por las ganancias y pérdidas y rendición de cuentas.

Debemos tener presente que deberemos eliminar barreras y contar con una estrategia de visión transformadora, que nuestra cultura debe tender a ser integrada e innovadora, con un talento humano realmente comprometido que sigue un liderazgo con buenas habilidades digitales.

[1]      Fuente: http://www.mckinsey.com/business-functions/mckinsey-recovery-and-transformation-services/our-insights/transformation-with-a-capital-t; disponible en dic/2016

[2]      Fuente: https://www.marketingweek.com/2016/04/14/what-does-digital-transformation-really-mean/; disponible en dic/2016

[3]      Fuente: https://solutions.forrester.com/consulting/digital-business/; disponible en dic/2016

[4]      Fuente: https://enterprisersproject.com/what-is-digital-transformation; disponible en dic/2016

[5]      Fuente: http://blogs.forrester.com/nigel_fenwick/15-12-08-the_state_of_digital_business_2016_to_2020; disponible en dic/2016

[6]      Fuente: http://www.pwc.com/gx/en/advisory-services/digital-iq-survey-2015/campaign-site/digital-iq-survey-2015.pdf; disponible en dic/2016

[7]      Fuente: http://www.altimetergroup.com/pdf/reports/Six-Stages-of-Digital-Transformation-Altimeter.pdf; disponible en dic/2016

[8]      Fuente: http://www.businesswire.com/news/home/20151104005180/en/; disponible en dic/2016

[9]      Fuente: http://sloanreview.mit.edu/article/the-advantages-of-digital-maturity/; disponible en dic/2016

[10]    Fuente: https://dupress.deloitte.com/content/dam/dup-us-en/articles/digital-transformation-strategy-digitally-mature/15-MIT-DD-Strategy_small.pdf; disponible en dic/2016

[11]    Fuente: http://www.theagileelephant.com/digital-transformation-diagnostic/; disponible en dic/2016

[12]    Fuente: http://www.12manage.com/methods_7S_es.html; disponible en dic/2016

[13]    Fuente: http://www.theagileelephant.com/what-is-digital-transformation/; disponible en dic/2016

[14]    Fuente: http://sloanreview.mit.edu/article/the-nine-elements-of-digital-transformation/; disponible en dic/2016

[15]    Fuente: http://www.gartner.com/newsroom/id/3119717; disponible en dic/2016

[16]    Fuente: http://www.centroschumpeter.org/2015/05/la-innovacion-proceso-destruccion-creativa/; disponible en dic/2016

[17]    Fuente: http://www.mckinsey.com/business-functions/organization/our-insights/nine-questions-to-help-you-get-your-digital-transformation-right; disponible en dic/2016

[18]    Fuente: http://www.i-scoop.eu/digital-transformation/#Digital_transformation_and_the_customer_experience; disponible en dic/2016

[19]    Fuente: http://www.marketingguerrilla.es/que-es-el-customer-lifetime-value/; disponible en dic/2016

[20]    Fuente: http://www.cmswire.com/digital-experience/7-reasons-your-digital-transformation-project-may-fail/; disponible en dic/2016

[21]    Fuente: https://cloudfabrix.com/blog/digital-transformation/why-most-of-the-digital-transformation-projects-are-failing/; disponible en dic/2016

ITIL® Módulo de capacidad del servicio: Operational Support and Analysis (OSA)

Introducción

Este curso se preparó para ahondar en los aspectos relacionados con la operación del servicio.

Sumilla

ITIL® es un modelo de referencia que resume un extenso conjunto de procesos de gestión que ayudan a las organizaciones a lograr calidad y eficiencia en sus operaciones de TI. La adecuada gestión de los servicios de TI es clave para la Gobernabilidad de TI cuyo objetivo es asegurar que el área de TI, a través de indicadores y controles apropiados y confiables, está actuando como verdadero soporte de las estrategias del negocio y no como un silo, y así coadyuvar al negocio en lograr grandes ventajas competitivas. Por ejemplo, ITIL® ha sido adoptado por miles de organizaciones en todo el mundo, entre otras la NASA, Microsoft y HSBC.

El curso está dirigido a los interesados en obtener, entre otros pero no limitados a, los siguientes beneficios:

  • Incrementar la competitividad de la empresa al reaccionar efectiva y eficazmente conforme a las necesidades del Negocio.
  • Mejoras en el tiempo de entrega de los servicios, alineados con la demanda de los usuarios.
  • Incremento de la calidad de los servicios provistos por el negocio en conformidad con los requerimientos de los consumidores.
  • Incremento en la satisfacción del cliente y del usuario final.
  • Mejoras en la disponibilidad, confiabilidad, flexibilidad y seguridad de los servicios críticos de TI.
  • Justificación de los costos por los servicios que la organización de TI proporciona.
  • Mayor integración de la organización de TI con el Negocio al proporcionarle seguridad, precisión, velocidad y disponibilidad de los servicios entregados según los niveles de servicio acordados.
  • Roles y responsabilidades establecidos y documentados para delimitar la provisión de servicios.
  • Eliminación de la duplicidad de actividades.
  • Aprendizaje de la experiencia previa.
  • Provee indicadores de desempeño justificables.

MINEDU: AIT-OFIN -Estrategia de Innovación

MINEDU: AIT- OFIN -Estrategia de Innovación

La tarea correcta
con la herramienta correcta
en la oportunidad correcta

Esta propuesta considera lo siguiente:

  • Empleo de tecnología moderna -dimensionada esta vez de manera más acorde con los requerimientos actuales y cuantificada para un horizonte de cinco años.
  • Una estrategia moderna de servicios provistos haciendo uso de las Tecnologías de la Información y las Comunicaciones (TIC), desarrollados en cumplimiento de:
  • Estándares internacionales (ISO)
  • Buenas prácticas de la industria (ITIL)
  • Normas técnicas peruanas (NTP ISO/IEC27001) y otros documentos de carácter legal