Tag Archives: estrategias

Mar 15 2018

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.

Oct 29 2017

Fuerzas impulsoras – Fuerzas de resistencia [restricción]

Pongámonos en situación

Seguramente hemos enfrentado, en más de una oportunidad, resistencia al cambio.

¿Sabemos quiénes favorecen cambios en pro del negocio, y quiénes no?

¿Buscamos mejorar o no salir de la zona de confort [de mantener el statu quo]?

¿Buscamos que el negocio gane o que nosotros ganemos?

¿Cómo afectamos a la organización con nuestra decisión [o posición] al respecto?

Las anteriores son interrogantes importantes que debemos resolver. Sabemos que es importante que todos en la organización estemos alineados con los objetivos institucionales.

¿Dónde están establecidos los principios rectores para las decisiones anteriores? ¿Ética, moral, valores?

Apreciamos que están involucrados diferentes fuerzas de consideración: personas (conocimiento de nosotros mismos), hábitos, costumbres, actitudes, motivaciones.

Roosevelt (ex presidente de USA, 1939), nos invocaba a dejar de reaccionar ante los eventos y las emociones y aprender a elegir nuestra propia respuesta ante cualquier situación. Recordemos parte del célebre discurso de Kennedy (ex presidente de USA, 1961), y pongámoslo en contexto: “no pregunten qué puede hacer su país [la empresa] por ustedes, pregunten qué pueden hacer ustedes por su país [la empresa]”.

Si deseamos realizar cambios, primero identifiquemos los cambios y las fuerzas relacionadas

Significa que necesitamos caracterizar la naturaleza del cambio; esto es, identificar, clasificar y tratar con las fuerzas que están trabajando por y en contra de nosotros cuando estamos tratando de implementar cualquier tipo de cambio en la organización [o nuestro lugar de trabajo].

Sobre una organización, considerando que requiere realizar algún cambio (la expectativa, el deseo, la necesidad, el objetivo, el diferenciador), requerido por aspectos tan diversos como (fuerzas impulsoras):

Podríamos empezar por preguntarnos:

Tendríamos, por tanto, que identificar y evaluar las fuerzas de resistencia [restricción] que surgen por:

  • El temor a lo desconocido.
  • Estructuras organizativas existentes.
  • Actitudes ‘Así no es como lo hacemos aquí’.
  • Compromisos existentes con organizaciones asociadas.
  • Legislación o regulaciones gubernamentales.
  • Contratos previos.

Así que, podríamos continuar preguntándonos, buscando identificar:

Podemos considerar herramientas como la 6W-2H para caracterizar las opciones.

A tener en cuenta

Recordemos que, desde hace ya muchos años, vivimos en un estado de cambio. Este estado reemplazó la sensación de certeza, estabilidad y familiaridad a la que estábamos acostumbrados. Este tipo de entorno se puede describir utilizando el acrónimo “VUCA”, que significa “volátil”, “incierto”, “complejo” y “ambiguo”, por sus siglas en idioma inglés.

Tengamos en cuenta que una conciencia de las fuerzas representadas en el modelo VUCA y las estrategias para mitigar el daño que pueden causar son parte integral de la gestión de crisis y la planificación de la recuperación de desastres.

Para resolver las interrogantes anteriores, seguramente requeriremos la participación de otras personas, como los miembros del equipo o expertos dentro de nuestra organización, clientes, partes interesadas externas y personas de la industria, entre otros. Recordemos, no estamos solos. Seguramente habrá alguien más que comulgue con nuestras ideas. Démosles la oportunidad de aportar opciones y de fortalecer nuestros argumentos.

Sí, lo anterior es un impulsor, así como resulta ser un freno el ver que no existe compromiso, que no se evidencia una comunicación oportuna y suficiente, se observa incumplimiento en las actividades establecidas, existe una carencia de retro alimentación, entre otros factores. Importante tenerlos en cuenta.

Busquemos obtener, mediante procedimientos diversos, como lluvia de ideas, las fuerzas relacionadas con cada cambio identificado. Tratemos que no sean muchas [trabajemos tres o cinco] para cada caso, para no desviar demasiado la atención [diversificación y, por tanto, debilitamiento de fuerzas].

Segundo, evaluamos el esfuerzo

Debemos valorar la influencia de las fuerzas. Para ello, establezcamos primero los criterios con los que trabajaremos, definamos las escalas de valoración que utilizaremos.

Busquemos obtener el consenso [aceptación, aprobación, autorización] de estos criterios y escalas, a fin de evitar, en lo posible, “marchas atrás”, “arrepentimientos”, “claridad de ideas”, “re-enfoques”, “cambio de prioridades”, otros.

A continuación, por cada cambio identificado, contrastemos ambas fuerzas y valoremos su influencia, utilizando los criterios y escalas antes establecidos.

Ordenemos, evaluemos, y prioricemos, teniendo presente que, a veces, es más fácil reducir el impacto de las fuerzas restrictivas que fortalecer las fuerzas impulsoras.

Conviene, por tanto, una vez identificado el cambio a trabajar, realizar un análisis de brecha, con el fin de determinar a fin de gestionar, con mayor detalle, entre otros aspectos clave, los plazos, presupuestos, recursos, capacidades, el valor esperado del cambio.

Para ello, un análisis FODA podría ser de mucho interés, para responder a las situaciones siguientes, entre otras:

  • ¿Cómo se desempeña actualmente mi área/unidad/organización?
  • ¿Cuáles son nuestras fortalezas y cómo podemos capitalizarlas?
  • ¿Hay alguna debilidad en el rendimiento general de nuestra área/unidad/organización?
  • ¿Dónde podemos mejorar?
  • ¿Cuáles son los factores externos o internos que están impactando nuestro futuro?
  • ¿Cuál es el posible impacto en las personas/en el negocio de las perspectivas futuras actuales?

Recordemos darle el tiempo apropiado y oportuno a lo importante, para que lo [realmente] urgente no nos abrume.

Formulemos nuestras estrategias de acción

¿Dónde están establecidos los principios rectores decidir nuestro comportamiento frente a las diferentes fuerzas?

¿No están claros los objetivos, no han sido apropiada y oportunamente difundidos e interiorizados, o no existen?

¿No son apropiados nuestros enfoques o formas de abordar la evaluación de opciones para decidir la alternativa más apropiada?

¿Tenemos forma de decidir cuál de las fuerzas tiene cierta flexibilidad para el cambio?

¿Tenemos forma de identificar sobre cuál de las fuerzas se puede influir?

Si hemos calificado cada fuerza, pensemos [planeemos] ¿cómo se puede [primero] reducir las amenazas que presentan las fuerzas restrictivas, [segundo] aumentar las posibilidades de las fuerzas impulsoras, o ambos?, [tercero] actuemos en consecuencia.

Podríamos, por ejemplo, considerar establecer un sentido de urgencia, con el fin de que la organización entienda por qué el cambio ya no es opcional, y apoye a que se realice, porque desea incrementar [sino, al menos, mantener] su valor.

Este sentido de urgencia puede impulsar el cambio, y reunir a las personas correctas [esperamos que en la oportunidad correcta] que aportarían al cambio de forma efectiva.

Recordemos que debemos definir las acciones que se requiere sean completadas con el fin de cumplir con el cambio propuesto, y de establecer un plan de acción [las acciones enumeradas en este plan de acción deben comenzar con un verbo] para el cumplimiento correspondiente [operativo y de gestión, de acuerdo con la envergadura del cambio]; y de asignar una persona responsable para cada acción y una fecha concreta para su conclusión [podríamos apoyarnos con una matriz RACI y, además, con un cronograma].

Algunas tácticas

  • Pongamos sobre la mesa las consecuencias de la inacción
  • Comuniquémonos, de forma constante y transparente
  • Utilicemos nuestro lenguaje corporal para transmitir el sentido de urgencia
  • No temamos al diálogo [no sólo pongamos a disposición –o presionemos- informes]
  • Interesémonos en conseguir los resultados esperados [comprometidos]
  • Emponderemos [correctamente] las [buenas y correctas] acciones
  • Respaldemos nuestras palabras con hechos [lideremos con el ejemplo]
  • Ayudemos a evitar [eliminar] la cultura del “nosotros conocemos mejor”
  • Reconozcamos las complacencias [y trabajemos para erradicarlas]
  • Identifiquemos [tempranamente] y enfrentemos [con argumentos] a aquellos que siempre están trabajando duro para obstaculizar el cambio
  • Busquemos establecer una cultura centrada en los resultados (en lugar de enfocada en la tarea).

Probablemente necesitemos cambiar la cultura organizacional.

Conclusiones

No olvidemos que todo esto es subjetivo y, por tanto, aspectos relacionados con la salud o la seguridad de las propias personas podrían prevalecer [consciente o inconscientemente, y hasta ser esbozadas por conveniencia].

¿Necesitamos establecer que todo esto forma parte de la mejora continua [ciclo PDCA]?

Pongamos nuestra inteligencia emocional a trabajar.

Ago 10 2017

8 maneras de sortear [asumir] fallas

Todo profesional relacionado con las TI ha oído hablar de la ley de Murphy. Algunos creen no haberla experimentado; otros dicen no haberla experimentado; otros niegan haberla experimentado. Tal vez [aún] no se han dado cuenta.

Sabemos que un error es causa de una falla, y ambos pueden ocurrir por diferentes razones -pero, como dijo Churchill, por ni una sola excusa; y que una falla (que, dependiendo del impacto, podríamos considerar como problema), puede conducir a uno o más incidentes. Con una adecuada formación en gestión de servicios podremos determinar los ámbitos de actuación de cada uno de estos términos.

Siguiendo a Deming, luego que resolvemos la condición negativa que se presentó [y que impactó el servicio o la seguridad de la información relacionada], ¿tomamos alguna acción? ¿Evaluamos los resultados de los cambios implementados en el valor de los servicios que se entregan, y/o en la seguridad de la información? Verificar el éxito del cambio ejecutado para [al menos] mantener la calidad del servicio entregado o su seguridad es bueno pero, en adición, debemos validar que la necesidad del cambio haya sido satisfecha, desde el punto de vista de la entrega de valor del servicio (SLA, clientes) como para los stakeholder (beneficios, cumplimiento, reguladores, regulaciones, evitar demandas o pago de moras, entre otros aspectos a considerar).

La tecnología juega un papel importante en todo esto, como también lo hace la cultura [organizacional, de servicio, de calidad, de seguridad, …].

En lugar de tratar con una, digamos, oportunidad de mejora, de forma individual -y hasta aislada, ¿realmente aprendemos de esta(s) tras aplicar mecanismos sistémicos apropiados y de manera oportuna y correcta? ¿está nuestra cultura [institucional] lo suficientemente madura para esto? ¿somos realmente un referente en esto –o al menos buscamos estar en camino de serlo? ¿utilizamos herramientas apropiadas para analizar la causa raíz de las oportunidades de mejora? ¿Son estas herramientas utilizadas por colaboradores competentes? ¿Gestionamos apropiadamente el triángulo procesos-personas-tecnología? ¿Qué tan proactivos somos al respecto? ¿Están clara y completamente identificados todos los involucrados, así como los límites, restricciones, expectativas, y presiones relacionados? ¿Hay vacas sagradas o el cliente es nuestra meta, no sólo de palabra sino con acciones concretas, duela a quien le duela? ¿Entendemos que habrá efectos negativos si hacemos mal las cosas?

¿Aprendemos de los errores de los demás? A propósito de las últimas noticias sobre ransomware. ¿Están los procesos establecidos y son seguidos? ¿Tienen las evidencias necesarias –ya mismo?

¿Sabemos qué información está disponible para las personas que trabajan en resolver problemas y qué tan rápido pueden obtenerla, para que puedan desarrollar pautas claras para evitar complicar el problema debido al estrés, la confusión o la fatiga? Información contextual, oportuna, clara, correcta, vigente, y completa, así como, objetividad y enfoque en la tarea, son condiciones primordiales en estos casos.

Tal vez nos centramos en buscar culpables, primero y siempre, afectando la moral –y perdiendo tiempo valioso, sin que nos importe nuestro cliente. Evitamos, consciente (limitaciones, presiones, carencias, inexperiencia, otros) o inconscientemente (confiamos ciegamente que la acción correctiva evaluada, elegida, y llevada a cabo es la definitiva), responder a la pregunta: si asumimos que podría ocurrir nuevamente, ¿cómo responderíamos mejor esta vez? ¿Son nuestros reportes del tipo ‘lecciones aprendidas’ (en sentido positivo) o del tipo ‘post mortem’ (en sentido negativo)?

Claro, errar es humano, y las estadísticas nos dicen que el ‘error humano’ bordea el 70% como causa de accidentes de tránsito en Lima. Bueno, tenemos factores como condiciones físicas del conductor (estado de alerta/lucidez, velocidad de reacción, ingestión de elementos alucinógenos o de bebidas alcohólicas, fatiga-cansancio-somnolencia), atención a la tarea –y no al celular, a la radio, al copiloto(a), exceso de confianza, temeridad, condiciones del vehículo, velocidad, estado de las vías, [des]conocimiento del reglamento de tránsito, señalización adecuada (bueno, si ‘Pepe el vivo’ las respeta porque ‘no hay policía que me vea’ ‑cuando el policía debía estar dentro nuestro), estilos de conducta en contextos de tráfico en relación a las variables: edad cronológica; estado civil; grado de instrucción; lugar de procedencia; pertenencia del vehículo; la conducción como ocupación principal; tiempo en la conducción; accidentes de tránsito; papeletas recibidas por infracciones; problemas de salud; problemas auditivos; problemas de motricidad; problemas familiares y problemas emocionales, entre otros. Nos damos cuenta que hay fallos activos (errores y violaciones, actos inseguros que tienen un impacto directo y son cometidos por los trabajadores que operan el ‘sistema’), y condiciones latentes (resultado de decisiones de los diseñadores y gerentes, las que se expresan en las condiciones del entorno, la política y cultura organizacional; influyendo así el desempeño de los trabajadores). Listo, introduje la palabra ‘sistema’ así que no nos salvamos y aplicamos el caso a las TIC. El verdadero problema son las herramientas y los procesos que no impiden (o al menos emiten advertencias sobre) los errores inevitables que la gente hace, o la falta de automatización que significa, en primer lugar, que alguien está haciendo una labor manual –posiblemente propensa a errores y con errores en la fuente. Por ejemplo, podría haber carencia u obsolescencia de documentación, procesos, procedimientos; tal vez exista un desconocimiento del ecosistema tecnológico en la empresa; podría no existir o ser inadecuado o estar mal programado el monitoreo, control, supervisión; podría no haber auditoría interna de seguimiento o ser aceptados y trabajados sus resultados; podrían no darse de manera oportuna y completa, o no sustentarse apropiadamente las inversiones necesarias desde el punto de vista del valor para el negocio; entre otros factores de consideración.

Tengamos presente que los errores podrían ser tolerados, pero no el ocultarlos o encubrirlos. Entendamos que hay valor en invertir en el desarrollo y el fomento de una cultura en la que los colegas reconozcan errores y errores de juicio, y apoyarlos para que reporten aquellas cosas que casi originaron una falla. Tratar la TI y la seguridad como un servicio del negocio en lugar de un punto de control ayuda a crear ese tipo de cultura.

No olvidemos la deuda técnica -el costo y los intereses a pagar por hacer mal las cosas (presión en el cronograma, escasez o carencia de recursos apropiados o suficientes, entre otros factores, que obligan a saltarse pasos [o funcionalidad]) –y que no se ven desde fuera, pero causan daño dentro –no nos engañemos con la falacia del “costo hundido”. La famosa filosofía “si funciona, no lo toques”, puede ser un grave error. La modernización tecnológica (de los activos críticos del servicio) y su seguridad ([in]cumplimiento, riesgos para el negocio si el activo se ve comprometido) es algo mandatorio en estos tiempos; sin embargo, es necesario planificar esta modernización.

Recordemos que la información resultante debe transparentarse, difundirse, utilizarse, proactivamente. Evitemos reinventar la rueda. Avancemos. Contribuyamos con el conocimiento. ¿Somos lo suficientemente maduros verdad? Se nos mide por lo que hacemos, no por lo que decimos que hacemos.

Ago 3 2017

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.

Jul 13 2017

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.

Jul 12 2017

Varias maneras de mejorar tu SLA

Es importante revisar cómo este tema avanza y, aunque lo vemos a diario ya que las bases están cubiertas, aún no lo interiorizamos apropiadamente.

Ya hemos conversado sobre la importancia que reviste un SLA apropiado para colocar servicios en la nube, aunque los proveedores de servicios en nube son (normalmente) reticentes a cualquier modificación en sus SLA estándar.

También hemos comentado cómo para una TELCO 2.0, un SLA correctamente ideado e implementado es un diferenciador importante, y una garantía de éxito.

Has contratado un servicio que establece lo que está comprendido en él y lo que no (alineado con los objetivos del negocio –estando articulados TI y el negocio en primer lugar –objetivos, expectativas, planificación, rediseño de procesos pueden ser factores previos importantes de considerar), y su vigencia.

El servicio contratado contempla recursos y capacidades que se deben entregar, está sujeto a restricciones, a plazos, a una calidad en la prestación, disponibilidad comprometida, responsabilidades de cada parte, procedimientos de escalamiento, pago, compensaciones, entre otros factores. Decir que se entrega algo que ha sido contratado no es lo mismo que evidenciarlo. Lo que buscamos son evidencias de dicho cumplimiento. Para ello gestionamos el servicio al establecer los estándares de medición, procedimientos para los reportes (contenido, frecuencia, entre otros aspectos a considerar), procesos para resolver controversias, cláusulas de indemnización en caso de incumplimiento por propios o terceros, mecanismos de actualización del SLA sobre todo cuando cambian los requisitos del servicio por cambios en la coyuntura socio-económica-cultural, modernización de la tecnología subyacente, cambios en las cargas de trabajo, existen mejoras en los procesos y herramientas de medición, o los recursos o las capacidades del proveedor del servicio (interno, y lo llamamos OLA o nivel de servicio organizacional, o externo, los SLA).

Chris Drumgoole, de Terremark, nos dice que “todo el mundo sabe que las cosas se rompen – es la naturaleza de la vida. Es cómo responder a las cosas que se rompen lo que te diferencia como proveedor de servicios en la nube”.

Entonces, resulta razonable establecer criterios para desarrollar las métricas que ambas partes deberán utilizar para realizar sus mediciones. Comúnmente medimos la disponibilidad del servicio, la tasa de defectos, la calidad técnica (incluyendo precisión y exactitud), tiempo de respuesta del personal de soporte, nivel de seguridad, velocidad, capacidad de respuesta y la eficiencia. Todo esto y más dependiendo del servicio contratado. Es más, podríamos considerar como SLA los resultados del negocio, una evolución más para reflejar la adición de nuevos servicios. Lo importante es que estas métricas hayan sido definidas con cuidado, sean periódicamente revisadas y actualizadas, sean las realmente necesarias, puedan realmente obtenerse (si es automático, mejor), estén controladas, tengan sentido, y motiven un comportamiento apropiado de ambas partes.

No debemos olvidar nuestro ecosistema tecnológico, el que controlamos normalmente (independiente de nuestro modo de operación), y el que aparece con el Shadow IT el cual también debe ser apropiadamente gobernado. Es evidente debemos incluir la Shadow IT en la Gestión de eventos, incidentes, problemas y solicitudes y, por ende, estaría representada esta gestión en los contratos con terceros o UC según ITIL®, y formaría parte del sistema de reportes de rendimiento y cuadros de mando.

Esto ayuda a incrementar el reconocimiento del valor que entrega IT al negocio como un todo.

May 1 2017

¿Quién más desea ser un design thinker?

Para desarrollar una estrategia digital, tendremos que aprender (y usar) nuevas técnicas como el design thinking.

Este método está enfocado en fomentar la innovación en las organizaciones [con base en las personas, en sus conocimientos y en su habilidad por imaginar lo diferente] de una forma eficaz y exitosa.

Las organizaciones que son capaces de crear un clima de Innovación encuentran las grandes ventajas de la participación activa y entusiasta de sus equipos humanos, con ideas nuevas y proyectos motivadores.

Es obvio de lo anterior que el equipo de trabajo es la clave.

Hoy, a medida que el terreno de la innovación se expande para abarcar procesos y servicios centrados en el ser humano, así como productos, las empresas están pidiendo a los diseñadores que creen ideas en lugar de simplemente hacerlas estéticamente atractivas.

El design thinking lleva implícita la necesidad de observar a los usuarios [clientes] con el objetivo de buscar soluciones que se centren en ellos.

Entonces, en el ámbito actual de los negocios, podríamos anotar que es un enfoque en la empatía de los clientes y las soluciones de prototipado rápido a los problemas de los clientes (un sentido de urgencia para evitar que el pez chico se coma al grande), de una forma que sea tecnológicamente factible y comercialmente viable (que se obtenga valor para el cliente). Hablamos, por supuesto, del prototipado de las ideas más prometedoras, y no lo confundamos con el de una pantalla de menú de una aplicación de recursos humanos, por ejemplo.

Tradicionalmente son cinco pasos que se siguen [no precisamente de forma línea]:

  1. Empatizar con las personas que disfrutarán de nuestro trabajo, mediante observación y entrevistas, hay que entenderlas, intentar sentir lo que sienten, identificar lo que les interesa, es buscar descubrir y comprender los supuestos personales y organizacionales y las inclinaciones alrededor de un punto focal –cómo abordo el desafío.
  2. Definir, para identificar cuáles son sus actuales ideas, y poder seleccionar qué necesidades concretas del cliente vamos a solucionar, es identificar e interpretar las tendencias y patrones –cómo interpreto mis hallazgos.
  3. Idear, ya estamos listos para uno de los momentos más atractivos del método, la eclosión creativa para generar ideas (las reglas innegociables en toda sesión de lluvia de ideas son: no criticar las aportaciones de los demás, generar cuantas más ideas mejor y hacerlo en un clima distendido y de diversión profesionalizada), es desarrollar conjuntos de mapas divergentes y provocativos utilizando creatividad, datos, intuición e investigación –qué es lo que creo.
  4. Prototipar, convertir las mejores ideas en diseños reales que las personas puedan ver, tocar y con las que puedan interactuar, es informar esfuerzos de planeamiento de largo aliento, inspirar innovación, y crear hoy el futuro –cómo construyo mi idea.
  5. Testear, con una pequeña muestra, dejar que toquen y experimenten, aguantar la respiración [y esperar pacientemente saber qué funcionó y que no], sin perder la sonrisa, y escuchar sus opiniones finales (la bendita, esperada y preferible retroalimentación) –cómo pruebo y mejoro la idea

Bueno, creo que algunos de nosotros hemos estado utilizando este modelo (independiente a la profesión), por varios años, aunque no le llamamos así; de hecho, no le poníamos nombre y, a mi entender, y en algunos aspectos, es una cuestión de sentido común que se va ganando con la experiencia, compromiso y perseverancia.

No me malentiendan, evidenciarlo ahora, aunque no sea nuevo en concepto, resulta útil para todos, con o sin experiencia.

Design thinking no se trata de crear productos o empresas, sino de tomar medidas concretas para hacer de nuestro mundo un lugar mejor.

Es una forma de pensar, está centrada en las personas, es colaborativa, es optimista, es experimental. Busca una perspectiva adaptable, resistente y transformacional.

Mar 22 2017

Internet de las cosas -IoT

Según Gartner, el “Internet de las cosas (IoT) es la red de objetos físicos que contienen tecnología incorporada para comunicarse y detectar o interactuar con sus estados internos o con el entorno externo”[1]; y añade que “el valor real del Internet de las cosas va más allá de los dispositivos interconectados”[2][3].

La interacción crea más datos (más complejidad en su tratamiento, más aplicaciones, mejores y más seguras que los traten, mayor necesidad de almacenamiento y procesamiento); la comunicación acarrea más riesgos que deben ser apropiadamente gobernados, una necesidad de mayor y mejor gestión de servicios (decisiones de toda índole más difíciles, para usuarios y operadores); las condiciones actuales y posibilidades futuras requieren recursos y capacidades diferenciados para asegurar que se mantiene el valor de los servicios (que promulga ITIL®) que entregamos –la sostenibilidad operativa.

Todos estamos involucrados y somos responsables del buen o mal uso que hagamos del IoT, en todo nivel. Además, debemos considerar que hay muchas cosas que considerar[4]: capacitación, público objetivo, requisitos de construcción, servicios incorporados, dispositivos (tipos, compromiso de seguridad, manipulación no autorizada[5], otros), disponibilidad, aplicaciones, redes, conectividad, plataforma tecnológica, ecosistema, riesgos directos e indirectos, actualizaciones de firmware o de software, aplicaciones que incorporen la seguridad desde el diseño, la arquitectura de las aplicaciones a este respecto, cifrado de datos, protección de datos personales, categorización de datos, datos sensibles en general, control de acceso, normativas, regulaciones, estándares, metadatos de los dispositivos, sistemas de monitorización y de protección contra intrusiones y ataques, tanto a nivel individual como colectivo[6], monitoreo continuo, localización de los datos porque lo que es delito informático en un país puede no serlo en otro, resiliencia[7], confidencialidad, integridad y disponibilidad, entre muchas otras posibilidades.

IoT no es una cosa; es la integración de varias cosas en una solución de negocio, es el corazón del negocio digital –bueno, cuando ya no sea una buzzword y realmente se de una transformación digital y contemos con tecnología concreta utilizable hasta en nuestros hogares[8] y por todos (refrigeradoras que podrán avisar a sus dueños cuando no haya alimento en ellos[9] es la promesa ¿recuerdan?). Sería bueno saber cuántos y cuáles dispositivos están accediendo a nuestra red local, y algo ‘raro’ como deshabilitar el bluetooth y las funciones que los dispositivos no usan todo el tiempo[10]. No queremos que “alguien” nos haga “gastar” más electricidad de lo habitual. Ya conocemos las deficiencias de seguridad existentes, que no nos pesquen desprevenidos, por ellas al menos[11].

[1]       Fuente: http://www.gartner.com/it-glossary/internet-of-things/; disponible en marzo/2017

[2]       Fuente: http://www.gartner.com/technology/research/internet-of-things/?s=1; disponible en marzo/2017

[3]       Fuente: http://view.ceros.com/gartner/iot/p/1; disponible en marzo/2017

[4]       Fuente: https://ricveal.com/blog/10-retos-seguridad-iot/; disponible en marzo/2017

[5]       Fuente: http://aunclicdelastic.blogthinkbig.com/el-reto-de-la-seguridad-en-iot/; disponible en marzo/2017

[6]       Fuente: http://www.csuc.cat/es/internet-of-things-un-reto-para-la-seguridad; disponible en marzo/2017

[7]       Fuente: http://www.ibm.com/developerworks/ssa/library/iot-trs-secure-iot-solutions1/index.html; disponible en marzo/2017

[8]       Fuente: http://techcetera.co/el-reto-para-la-seguridad-para-el-internet-de-las-cosas/; disponible en marzo/2017

[9]       Fuente: http://www.nacion.com/tecnologia/informatica/Seguridad-principal-reto-Internet-Cosas_0_1571442852.html; disponible en marzo/2017

[10]     Fuente: http://techcetera.co/tiene-el-internet-de-las-cosas-iot-algun-riesgo-para-su-hogar/; disponible en marzo/2017

[11]     Fuente: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/insecurity-in-the-internet-of-things.pdf; disponible en marzo/2017

Dic 14 2016

Autoservicio de TI

Desplegar tecnología para lograr que los usuarios de ésta se ayuden cuando tienen dificultades con la tecnología (sí, más tecnología para la tecnología) es algo que por mucho tiempo se ha tratado –y en algunos casos esta “innovación” ha funcionado y en otros no; bueno, siempre hay espacio para mejorar.

Los medios de acceso son variados. Existen versiones de respuesta humana o incluso robótica. Las interfaces son cada vez más útiles y usables. Sistemas de información y flujos de trabajo unos más integrados –y útiles- que otros. Actividades unas mejor implementadas que otras, como emisión y renovación de la identificación del usuario, entrenamiento, disponibilidad de opciones tipo push-pull para instalaciones o actualizaciones, ejecución de políticas de retención, solicitudes variadas (provisión de recursos, programación de atenciones, consultas sobre funcionalidad u operación, requerimientos de reparación, de información), entre otras[1]. Todos gozan de una interesante y mayor agilidad, los que entregan (TI tradicionalmente), y los que reciben (siempre el usuario). La experiencia de usuario está garantizada –depende del usuario calificarla.

fig1

Empoderar a los consumidores (usuarios y clientes) de servicios especializados para que ellos mismos se auto atiendan cuando tienen necesidades relacionadas con la tecnología de la información está muy de moda hoy en día[2].

Los usuarios finales obtienen las herramientas que necesitan para maximizar la productividad, tienen acceso a una vasta base de conocimiento[3] –y hasta a información a la que antes no tenían acceso (y no hablo de seguridad sino de alcance, disponibilidad, re-utilización porque esta iniciativa depende de la calidad y cantidad de información disponible y las facilidades disponibles para accederla[4] y generarla, incluso por comunidades de usuarios[5], y las medidas adoptadas para retener su control), y los departamentos de TI reducen la tensión cotidiana de las llamadas que llegan al servicio de atención al cliente[6].

Interesante. Se reducen costos al pasar del “modo bombero” a un estado de eficiencia y efectividad, y se re-enfoca la mesa de servicio a incrementar la satisfacción del cliente o del usuario.

Sí, nada nuevo hasta aquí. Pero, Gartner[7] nos alerta de las generalidades en que hemos incurrido antes, lo cual nos fuerza a sincerar los resultados frente a las expectativas de esta innovación –y preparar un buen caso de negocio primero.

  • El autoservicio de TI reduce costos en el soporte nivel 1 principalmente con relación a las solicitudes varias que ya comentamos. Algunas cosas todavía requerirán una llamada al servicio de TI o la asistencia de un técnico de soporte. Es una mezcla cuyo balance debe ser cuidadosamente considerado con respecto al valor esperado, con el objetivo de no incurrir en gastos innecesarios –aunque suene trillado esto último.
  • El autoservicio de TI requiere cuidado y actualización constante; no es una inversión que se realiza una sola vez y nos olvidamos luego. Es un continuo asegurar que el servicio lo seguimos entregando ‑como área de TI- como fue comprometido, y nuestro “consumidor” lo sigue recibiendo –su apreciación del valor- de forma oportuna, consistente y constante. El conocimiento, hemos mencionado, juega un papel vital y como tal debe ser gestionado apropiadamente para mantener su vigencia y utilidad.
  • Los usuarios finales acudirán a los autoservicios sólo si no tienen alternativa, lo cual dependerá de la estrategia que implemente la organización para su “adopción”, ya que la inclinación a su aceptación potencialmente será variada –tanto como la cultura organizacional, la mentalidad de los usuarios, la brecha generacional, así como los plazos límite que se establezcan.
  • Para una implementación exitosa del autoservicio de TI se requiere de requisitos previos que lo complementen, como un conjunto correctamente seleccionado de herramientas y procesos, adecuados, probados, afinados, y mantenidos, por personas con roles y competencias técnicas apropiadas, que apoyen, por ejemplo: la automatización de las actividades antes enumeradas, entre otras; y a los usuarios en las decisiones que deben tomar y en las tareas que deben realizar. Si se implementa adecuadamente, el autoservicio puede mejorar la satisfacción del cliente, proporcionar análisis de tendencias de incidentes, identificar oportunidades de capacitación, permitir ejecutar escenarios del tipo “que pasa si” para determinar a dónde llegarán las finanzas de la compañía para el trimestre, y consolidar el conocimiento que existe actualmente en los silos en toda la organización de soporte. La retroalimentación obtenida de un piloto o varios] es atractiva –y útil, para identificar la diversidad de información que sea requerida y permitir flexibilidad y agilidad en satisfacerla.
  • Así es, no dejemos de lado la utilidad, usabilidad, garantía, no sólo de los servicios entregados, con base en procesos gestionados y sujetos a una mejora continua, sino también de los medios utilizados para su entrega, como la interface de usuario utilizada –portal bien diseñado, amigable e intuitivo por supuesto, con el que sea fácil pedir ayuda.

Como siempre, una buena venta del valor del servicio ayudará a que los usuarios lo adopten voluntariamente (menor rechazo inicial; servicios conscientes del contexto que conocen su rol, ubicación y equipo[8]; adopción más rápida; disponibilidad de diferentes medios de contacto; apoyo a las aplicaciones actualmente en uso –aunque no hayan sido provistas por el departamento de TI; naturalidad, facilidad y flexibilidad en el procesamiento de solicitudes; compromiso consciente; finalmente interiorización), buscar qué necesitan hacer, qué quisieran hacer y no pueden –aún, qué les ha funcionado, qué les molesta, y otros posibles aspectos a considerar[9] -una mejora continua de funcionalidad y alcances, promocionar lo realizado, buscando cada vez una mayor aceptación. Identificar los temas correctos que ayudarán a los usuarios a ayudarse a sí mismos, toma tiempo y esfuerzo, no olvidemos considerar el costo total de propiedad de la solución integral.

[1]        Fuente: http://www.techrepublic.com/blog/10-things/10-ways-it-can-use-self-service/; disponible en dic/2016

[2]        Fuente: http://www.computerworld.com/article/2500959/enterprise-applications/self-service-it.html; disponible en dic/2016

[3]        Fuente: http://www.servicenow.com/products/express/it-self-service-portal-for-smb.html; disponible en dic/2016

[4]        Fuente: http://whatis.techtarget.com/definition/customer-self-service-CSS; disponible en dic/2016

[5]       Fuente: https://www.atlassian.com/it-unplugged/best-practices-and-trends/technologies-for-self-service-success; disponible en dic/2016

[6]        Fuente: http://www.axiossystems.com/solutions/end-user-self-service; disponible en dic/2016

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

[8]        Fuente: http://www.bmc.com/it-solutions/it-self-service.html; disponible en dic/2016

[9]        Fuente: http://www.informationweek.com/strategic-cio/team-building-and-staffing/7-ways-to-avoid-self-service-it-pitfalls/a/d-id/1297292; disponible en dic/2016

Feb 28 2010

¿Monetizar la audiencia?

(Artículo preparado para difusión interna en la Red Científica Peruana -RCP)

“Para sobrevivir, los operadores tienen que comenzar a pensar como monetizar su audiencia, a diferencia de simplemente enfocar la venta en más minutos o kilobytes”. ( Patrick Parodi, Board Director, Shazam and Former Chairman, Mobile Entertainment Forum).

El comentario anterior resume en realidad el artículo. El autor dice que nos enfrascamos en tecnología pero no vemos realmente cómo sacar partido de ella.