Ivanti Blog: Publicaciones de

Cómo evitar estos dos problemas habituales de la aplicación mensual de parches

Tue, 25 Jul 2023 14:02:27 Z

Ya ha llegado ese momento: toca aplicar parches a sus endpoints. Puede que sea algo que le guste, aunque probablemente no sea así. La aplicación de parches puede ser una tarea ardua y, con muchas organizaciones que aún la realizan manualmente, se invierten en ella más tiempo y recursos de los que cualquiera querría dedicarle.

Ahora bien, dado que va a dedicar todo ese tiempo y esos recursos a la aplicación de parches, querrá asegurarse de que todo vaya bien. Nadie quiere invertir tanta energía en la gestión de parches para acabar en una maraña de confusión y errores.

Así que asegurémonos de que no cae en estos dos problemas mensuales de parches más habituales:

¿Funcionan sus parches?
¿Ha probado los parches en su entorno?

Problema de parches n.º 1: ¿funcionan sus parches?

No es raro que los parches y las actualizaciones de seguridad fallen sin más. A veces se debe a un problema específico del entorno. Otras veces, el parche en sí simplemente es defectuoso.

Menos mal que decidió comprobar ese parche antes de implementarlo a ciegas, ¿verdad? Pero ahora que está fallando, ¿qué puede hacer al respecto? Depende.

Solución 1: póngase en contacto con su proveedor externo de gestión de parches

Si utiliza un proveedor externo de parches para gestionar las actualizaciones, debería ser el primer punto de contacto.

Aunque las empresas que gestionan parches de terceros prueban rigurosamente el contenido que distribuyen a sus clientes, no pueden probar todos los escenarios de uso. Es posible que tenga una configuración poco habitual o que su endpoint esté gestionando el parche de forma distinta a la que esperaba el proveedor externo de parches.

Sea cual sea el motivo, su proveedor siempre debería ser su primer recurso. No solo es importante notificar el fallo para que pueda corregirse, sino que también resulta útil para ese proveedor externo de parches.

Puede que haya encontrado un problema sistémico. Ahora usted es quien ha alertado a la empresa sobre un problema mayor en el que pueden centrarse y solucionar rápidamente.

Puede que no sea sistémico, pero sí un problema lo bastante común como para que haya ayudado a esa empresa a estar mejor preparada para futuras llamadas de otros clientes. Por no hablar de que también le ha proporcionado un posible nuevo escenario de uso que puede incorporarse a sus protocolos de prueba predeterminados.

Solución 2: consulte a una comunidad en línea más amplia para detectar posibles problemas con los parches

Pero ¿qué ocurre si no utiliza un proveedor externo de parches? Supongamos que su organización revisa manualmente estos parches.

Existen excelentes recursos en línea para comprobar si otras organizaciones también están teniendo los mismos problemas, entre ellos:

PatchManagement.org, «la primera lista de correo del sector dedicada al debate sobre la gestión de parches».
Varias comunidades de Reddit y Mastodon, como r/sysadmin, infosec.exchange o cualquier comunidad específica de un proveedor.
recursos de Patch Tuesday de Ivanti, diseñados para comentar qué parches se publican y qué puede esperarse de ellos.

Independientemente de la vía que decida seguir, hay muchas opciones entre las que elegir para identificar qué ha fallado en el parche defectuoso.

Problema de parches n.º 2: ¿ha probado los parches en su entorno?

De acuerdo, ha decidido probar todos los parches que llegan: ¡excelente! Ya está todo resuelto, ¿verdad?

No tan rápido.

Tampoco puede olvidarse de probar los parches que va a distribuir en dispositivos piloto de toda su organización.

¿Por qué? Al fin y al cabo, es solo una sencilla actualización de Chrome. Pero ¿lo es realmente?

Introducir un nuevo parche en sus sistemas no es muy distinto de introducir una nueva mascota en casa. Aunque ya haya tenido una mascota y confíe en saber cómo cuidarla, cada una tendrá sus propias reacciones ante habitaciones o personas que su mascota anterior no tenía.

Del mismo modo, cada parche tiene sus propios matices de cambios y actualizaciones. A menudo pueden entrar en conflicto con aquello para lo que se han diseñado sus sistemas o programas, lo que puede afectar al entorno o a la eficacia del parche, incluso aunque haya superado las pruebas anteriores.

Al fin y al cabo, las empresas de software no parchean sus productos pensando en sus sistemas. Se centran en actualizar y aplicar parches a sus propias aplicaciones, y no pueden contemplar todos los escenarios de uso.

Resolver el efecto dominó de los problemas de parches

Contar con un grupo piloto dedicado de endpoints en el que probar estas actualizaciones puede garantizar que no se dañen sistemas, programas ni siquiera procesos de los que depende su empresa. El efecto dominó de una pequeña actualización de parche puede ser perjudicial para las operaciones de una empresa.

Por ejemplo, a principios de abril, Chrome lanzó un parche para corregir algunos errores. Pero también introdujo errores nuevos, uno de los cuales afectaba a la capacidad de impresión desde Chrome.

¿Y si su organización trabaja en un entorno con un uso intensivo de impresión, donde poder imprimir a través de Chrome es una opción imprescindible para sus operaciones?

De este modo, probar todos los parches, incluso los pequeños y aparentemente insignificantes, puede ayudarle a evitar una catástrofe.

Recuerde: cuando algo sale mal, los errores se propagan más allá del departamento o usuario inicialmente afectado. La mayoría de los usuarios y organizaciones no piensan en los impactos posteriores que puede provocar un pequeño parche si no se ha probado por completo. Al fin y al cabo, a menudo es TI quien se encarga de solucionar los efectos de un fallo o una interrupción.

Por eso, cuando llega el momento de aplicar parches, queremos prepararnos para que todo salga bien. Para ello, buscamos una variedad sólida de endpoints en los que probar nuestros parches, con el fin de asegurarnos de no generar un impacto posterior evitable, y también tenemos preparados nuestros recursos de la comunidad por si los parches acaban fallando.

También puede consultar:

La guía definitiva de la gestión de parches basada en riesgos para obtener más información sobre la creación de grupos piloto, la gestión priorizada de parches y otros aspectos básicos de la aplicación de parches.
El podcast Security Insights, que analiza la importancia de la visibilidad de los activos antes de limitarse a implementar un nuevo parche.
La serie Patch Tuesday, que ofrece todas nuestras recomendaciones y advertencias anteriores sobre parches. No se pierda la próxima sesión, que tendrá lugar el miércoles inmediatamente posterior al Patch Tuesday de cada mes.

A veces, la mejor estrategia de gestión de parches es simplemente una buena preparación. ¡Buena suerte!

Cómo crear una base de conocimiento: un enfoque sencillo y eficaz

Tue, 13 Jun 2023 18:36:14 Z

Al principio de mi carrera, pasé de trabajar como contratista de defensa a ser agente de soporte al cliente para un proveedor emergente de soluciones de gestión de servicios de TI. Como era nuevo en el equipo y en el sector, me sentía completamente fuera de lugar. Tras la formación inicial sobre el producto, me asignaron un ordenador de laboratorio y me dijeron que empezara a diagnosticar una serie de incidencias de clientes. Me sentía totalmente perdido.

Con el tiempo, tras muchas horas de estudio y con el apoyo de mis compañeros, fui entendiendo las cosas y acabé convirtiéndome en uno de los analistas de referencia. El problema de este método era que todo ese enorme conocimiento empírico quedaba encerrado en la mente de cada analista. Cuando perdíamos a un empleado, también perdíamos su amplia experiencia. Finalmente, se puso en marcha una iniciativa de base de conocimiento.

Por qué es buena idea invertir tiempo y esfuerzo en configurar una base de conocimiento

Aunque hay algunas razones evidentes para contar con una base de conocimiento, como:

Acelerar el tiempo de resolución de las incidencias de los clientes.
Mantener la productividad y la satisfacción de los empleados en el trabajo.
Reducir el tiempo hasta que los analistas alcanzan la efectividad.
Ofrecer soluciones coherentes.

También existen algunos motivos menos evidentes para mantenerla, como:

Eliminar el conocimiento tribal

Se trata de conocimiento que algunas personas conservan de forma privada con la intención de aumentar su valor, pero que deja a la organización en una situación vulnerable.

Mejorar la percepción de su organización y sus productos

Proporcionar resoluciones rápidas y precisas puede contribuir a la satisfacción con el producto y a la retención de clientes.

Reducir los costes de soporte de TI

Si la base de conocimiento se adapta correctamente y se pone a disposición de los usuarios de autoservicio, ya sea a través de un portal web o de un asistente virtual (chatbot), las incidencias pueden resolverse sin necesidad siquiera de llamar al service desk.

A esto se le denomina a veces soporte de nivel 0. Además, al cerrar las incidencias con mayor rapidez, los analistas aumentan su productividad, lo que a menudo elimina la necesidad de ampliar la plantilla.

Por dónde empezar al configurar una base de conocimiento

La mayoría de las soluciones modernas de gestión de servicios incluyen un repositorio de base de conocimiento integrado, aunque todavía sin contenido, listo para recibir sus valiosas aportaciones.

Aunque existen muchos proveedores excelentes de bases de conocimiento, es posible que no puedan integrarse con su entorno de gestión de servicios. Además, aunque no es una solución de base de conocimiento, SharePoint ofrece una plantilla de conocimiento que puede ayudarle a empezar.

Además de las soluciones de base de conocimiento independientes, puede considerar la posibilidad de incorporar conocimiento empaquetado a sus bases de datos de conocimiento. Estos paquetes de conocimiento, ofrecidos por distintas empresas, se centran en temas como Windows, Office 365, Adobe, macOS y otros. Estos paquetes de conocimiento concentrados y listos para usar son muy valiosos, ya que ayudan a las organizaciones de soporte de TI en fases iniciales a atender a los clientes y resolver incidencias con rapidez.

Aunque muchas organizaciones pueden utilizar conocimiento preempaquetado, la mayoría también ofrece soporte para soluciones únicas que requieren conocimiento especializado. En el caso de una organización consolidada que lleva tiempo prestando soporte, ya contará con información valiosa en forma de tickets de soporte anteriores que puede incorporarse rápidamente a una base de conocimiento.

Si la organización es nueva o se ha lanzado recientemente una nueva solución, se dependerá en gran medida de los equipos de ingeniería para obtener el conocimiento inicial de soporte.

Casi todas las soluciones modernas de gestión de servicios de TI disponen de funcionalidad para crear nuevos artículos de conocimiento directamente a partir de incidencias resueltas y cerradas. Por ejemplo, Ivanti Neurons for Service Management cuenta con un «botón» de enlace de acción que traslada sin fricciones los datos clave de la incidencia a una nueva plantilla de base de conocimiento.

También incluye flujos de trabajo para revisar, probar y perfeccionar los artículos antes de publicarlos. El reto es que los datos de resolución de tickets a menudo no están redactados en un formato repetible, paso a paso y fácil de entender.

El reto consiste en motivar a unos equipos de soporte muy ocupados para que conviertan y documenten incidencias anteriores en artículos de calidad, y para que almacenen los datos no documentados en un repositorio con capacidad de búsqueda.

Cómo motivar a sus equipos

La organización mencionada al principio de este blog tenía un método extraordinariamente eficaz para extraer información de la mente de los analistas. Utilizaba el enfoque del palo y la zanahoria.

Primero, el palo. Como parte de los objetivos anuales de todos, cada analista de soporte debía elaborar un número determinado de artículos de conocimiento originales al mes. El objetivo solía ser de 5 a 10 al mes, una cifra razonable teniendo en cuenta nuestro volumen de llamadas. No alcanzar el objetivo afectaba a la evaluación anual. Para garantizar que se enviaban artículos de alta calidad, primero se revisaban para detectar duplicados.

A continuación, se revisaba la exactitud de los artículos distribuyéndolos a otros miembros del equipo para su revisión técnica. Por último, recibían una revisión final antes de ponerse a disposición del público objetivo, ya fueran solo los analistas o tanto los analistas como los clientes.

Después, la zanahoria. Se hacía un seguimiento del uso de los artículos y se recompensaba a los analistas en función del número de veces que un artículo se utilizaba para resolver correctamente una incidencia. Una buena solución de gestión de servicios de TI con una base de conocimiento integrada debería admitir este nivel de informes.

En función del uso mensual, los analistas cuyos artículos se habían utilizado más durante el mes para resolver incidencias recibían un premio importante al final del año; algunos regalos tenían un valor de varios miles de dólares.

A lo largo del año, se crearon campañas para motivar a los equipos y recordarles los requisitos y las recompensas. El resultado fue la creación, en un breve periodo, de un repositorio considerable, en crecimiento y de gran valor, compuesto por artículos específicos de producto.

Sea cual sea la forma en que motive a sus equipos para crear contenido de conocimiento, será necesario un esfuerzo coordinado y un refuerzo constante. Las recompensas por sus esfuerzos merecerán la pena.

Si desea experimentar todas las ventajas que puede ofrecer un proveedor moderno de gestión de servicios, vea la demostración completa.

Cómo equilibrar la seguridad con la DEX para lograr una ventaja decisiva

Mon, 31 Oct 2022 13:35:41 Z

Levante la mano si le gusta que le expulsen de la aplicación en la que estaba trabajando por un parche de seguridad inesperado.

¿Nadie? Podemos esperar…

¿De verdad, nadie?

De acuerdo, lo suponíamos. Y no nos sorprende. Jamie Whalen, presentador del Everywhere Workplace Podcast, se reunió recientemente con Steve Brasen, director de investigación de Enterprise Management Associates, para hablar sobre el conflicto percibido entre la experiencia digital del empleado (DEX) y la seguridad.

Con demasiada frecuencia, se sitúa la DEX y la seguridad en esquinas opuestas del proverbial cuadrilátero. Es comprensible, pero también es un enfoque obsoleto que deja pasar una oportunidad significativa. Combinar seguridad y DEX puede proporcionar una importante ventaja competitiva. Ambas son fundamentales y, juntas, aún mejores.

DEX

Los trabajadores remotos han dejado claras sus preferencias: quieren trabajar desde la ubicación que elijan. Adiós a los perímetros. Adiós a los cubículos. Muchos incluso renunciarían a un ascenso a cambio de poder trabajar desde cualquier lugar. Quieren un acceso fluido, una conectividad fiable y las herramientas adecuadas para hacer bien su trabajo.

Abordar estas necesidades es una parte importante para garantizar una DEX sólida, y sabemos que la DEX es clave para asegurar la fidelidad, la productividad, el compromiso y la satisfacción de los empleados.

Seguridad

¿Cree que la seguridad se plantea en oposición directa a esa lista de deseos de los trabajadores remotos? Piénselo de nuevo. La seguridad quiere lo mismo que los demás trabajadores remotos: que todo el mundo pueda hacer su trabajo de forma fácil y segura.

El problema: algunas de las medidas para lograr una seguridad de primer nivel pueden obstaculizar el acceso fluido si no se aplica el enfoque adecuado.

¿Por qué? Las medidas de seguridad más eficaces son cosas como la “gestión de contraseñas de alta fricción”, que, por su propia definición, resultan lo más difíciles de sortear posible. Eso es excelente para la seguridad. No tanto para los trabajadores remotos que intentan sacar adelante su trabajo.

Esta percepción de que la seguridad y la experiencia del empleado están reñidas se intensificó durante la pandemia, cuando muchas empresas dieron un giro abrupto (y a menudo no demasiado planificado) hacia el trabajo remoto. Los equipos de seguridad han tenido que ponerse al día.

Estos equipos carecen de personal suficiente y están desbordados: hacen todo lo posible por priorizar y gestionar vulnerabilidades, pero a veces esto ocurre a costa del acceso, lo que deja frustrados a los trabajadores remotos.

Control remoto

Esto es algo que no debería ser ningún secreto: la DEX y la seguridad no están reñidas. De hecho, una buena DEX mejora la seguridad.

¿Por qué? Porque una DEX positiva genera cumplimiento, y el cumplimiento surge de forma natural cuando los protocolos de seguridad se integran de manera inteligente y fluida en la experiencia digital.

La clave, por tanto, está en hacer bien esa integración.

Cuando los protocolos de seguridad se desarrollan e implementan al margen de una DEX positiva, los trabajadores remotos acaban intentando sortear constantemente controles de seguridad que son esenciales para la empresa, pero que pueden resultarles extremadamente engorrosos como usuarios.

Cuando hay muchos obstáculos que superar, los empleados, en el mejor de los casos, son menos productivos y tienden a buscar formas alternativas de hacer su trabajo sin interrupciones constantes ni largos tiempos de espera para recibir respuesta a sus tickets.

“Cuando hemos realizado encuestas, hemos descubierto que el mayor reto para los usuarios es, en realidad, intentar trabajar con los controles de seguridad sin que afecten a sus herramientas de trabajo”, afirma Brasen.

Esta falta de cumplimiento interno no suele ser malintencionada; se percibe como algo práctico. Por desgracia, los riesgos son elevados.

La falta de cumplimiento es lo último que necesita la seguridad. Cuando los empleados están fuera de un perímetro, trabajando en distintos dispositivos y sistemas operativos por todo el mundo, los equipos de seguridad se enfrentan a una tarea de Sísifo.

“Imagine un escenario en el que un empleado que trabaja desde casa accede a recursos empresariales mediante una VPN (red privada virtual). También puede estar usando servicios alojados en la nube, independientes de la empresa”, explica Brasen.

“Y envía un ticket a soporte indicando que está sufriendo una ralentización en el rendimiento de la aplicación. ¿Por dónde empieza siquiera el administrador de TI? ¿El problema está en el dispositivo del empleado? ¿O se origina en la wifi doméstica del empleado? ¿O está relacionado con la VPN o con el entorno alojado en la nube?”

El coste de la falta de alineación

La falta de alineación entre seguridad y DEX causa muchos quebraderos de cabeza.

La falta de cumplimiento conduce claramente a vulnerabilidades masivas para la empresa. Aunque la frustración de los empleados es otro factor importante, hay aún más aspectos que tener en cuenta. Steve Brasen señala que existe una pérdida de productividad significativa asociada a las barreras de seguridad y los reinicios del sistema. La pérdida de trabajo es un problema importante, y la interrupción del ritmo también tiene un coste.

Estas interrupciones se acumulan: con equipos de seguridad al límite y tratando de responder a un aumento meteórico de las amenazas de seguridad (especialmente el ransomware), los parches, las ralentizaciones y los reinicios disruptivos pueden parecer constantes.

Cómo avanzar como un mismo equipo

La buena noticia: la falta de alineación entre seguridad y DEX no es inevitable. Así es como se puede avanzar como un mismo equipo:

Supervisar y gestionar la DEX: no se puede mejorar lo que no se ha medido. La tecnología puede desempeñar un papel enorme a la hora de reducir el impacto que los protocolos de seguridad tienen en los empleados.

Para empezar, es esencial supervisar y gestionar la DEX comprendiendo realmente cómo experimentan los usuarios los productos digitales y los protocolos de seguridad, así como qué impacto tienen esos elementos en el usuario.

Centrarse en la experiencia: probablemente haya oído hablar de los SLA (acuerdos de nivel de servicio), pero ¿qué hay de los XLA? Un XLA es un acuerdo de nivel de experiencia. El servicio se centra en un proceso, mientras que el XLA tiene en cuenta los resultados y las experiencias.

Por sólidos que sean sus SLA, si los resultados y el valor no están donde deberían, debería reconsiderarse el proceso.

Adoptar la automatización: automatizar, automatizar, automatizar. “La remediación automatizada debería implementarse siempre que sea posible para resolver rápidamente los problemas antes de que afecten a la productividad de los usuarios”, afirma Brasen.

La remediación automatizada permite una gestión proactiva de las experiencias digitales, lo que resulta considerablemente menos disruptivo para los usuarios que la gestión reactiva tradicional.

Usar controles de seguridad inteligentes: en lugar de intentar controlar todas las amenazas en todo momento, utilice inteligencia basada en el riesgo para centrarse en las amenazas más relevantes y críticas. Esto no solo dirige sus recursos de seguridad al lugar adecuado, sino que también significa que la seguridad no provoca interrupciones innecesarias a los usuarios por amenazas no críticas.

Una vez más, los equipos de seguridad y los trabajadores remotos quieren lo mismo: que todo el mundo pueda hacer su trabajo de forma segura y sencilla. La automatización, la inteligencia basada en el riesgo y un enfoque centrado en la DEX pueden aliviar las cargas de seguridad, TI y el resto de su plantilla remota.

¿Quiere saber más sobre la importancia de invertir en DEX? Consulte el informe completo y escuche el episodio completo del podcast.

7 expertos explican qué significa shift left para los departamentos de TI

Fri, 18 Aug 2017 16:51:09 Z

Esta publicación apareció originalmente en el blog de Cherwell, antes de la adquisición por parte de Ivanti.

En nuestra reciente serie de artículos del blog, hemos explorado el concepto de shift left en relación con la gestión de servicios. Acercar la resolución de problemas y otras actividades lo máximo posible al usuario final permite a la gestión de servicios de TI (ITSM) ahorrar costes y es un buen ejemplo de cómo la gestión de servicios aplica shift left.

Dado que el concepto de shift left puede utilizarse para describir distintas actividades en diversos contextos, pedimos a expertos en TI que compartieran su opinión sobre qué significa shift left y si aporta valor a las organizaciones. Esto es lo que siete expertos en tecnología dijeron al respecto:

Ollie O'Donoghue, analista sénior de investigación en HfS Research

Como antiguo profesional del service desk, para mí shift left significa eliminar silos en TI para garantizar que el service desk cuente con los recursos, el acceso y las herramientas que necesita para resolver el mayor número posible de incidencias de los clientes en el punto de contacto. Y, cuando sea posible, poner estos recursos a disposición de los clientes para ofrecerles opciones de autoayuda y autoservicio.

El objetivo final, por supuesto, es mejorar la experiencia del cliente y crear relaciones más colaborativas entre TI y el negocio.

Para mí, el recurso más demandado en la cadena de valor de ITSM es el conocimiento. Los clientes acuden al service desk porque necesitan ayuda para solucionar algo que requiere conocimientos de TI valiosos. Y esa demanda se extiende por toda la estructura de soporte de TI a medida que se necesita más experiencia y habilidades para resolver los retos de TI. Por eso, es ahí donde he visto los mayores beneficios.

John Custy, formador y consultor de ITSM

Shift left significa acercar la persona, el proceso o la tecnología al cliente, lo que se traduce en una resolución más rápida, eficiente y eficaz.

Shift left debería significar algo más que autoservicio o envío web de solicitudes (automatización). Shift left consiste en ofrecer un mejor servicio y lograr mejores resultados de negocio.

Shift left no consiste únicamente en reducir los costes de TI (en realidad, a menudo transfiere costes al cliente), sino en realizar un esfuerzo consciente y coordinado para comprender qué trabajo es adecuado trasladar a otra área (personas o tecnología). A menudo, shift left se traduce en una mayor automatización cuando el valor de que las personas realicen el trabajo es bajo. Shift left también consiste en garantizar que se utilicen los canales de comunicación adecuados.

Steve Buchanan, director regional de soluciones en Concurrency y bloguero tecnológico

Shift left consiste, ante todo, en empoderar al cliente.

Un autoservicio real ayuda al cliente a obtener lo que necesita cuando lo necesita, sin demoras y sin afectar a la cuenta de resultados de la organización.

Los mayores beneficios logrados en ITSM mediante shift left se encuentran en el catálogo de servicios y la automatización. Determine qué servicios de TI pueden y deben estar en un portal de autoservicio y automatice todo lo posible de los servicios ofrecidos en el catálogo de servicios. El resultado son usuarios finales más satisfechos y más tiempo para que TI se centre en proyectos aún más estratégicos para el negocio.

Doug Tedder, consultor principal, Tedder Consulting

Demasiadas organizaciones utilizan procedimientos de gestión de cambios innecesariamente complejos y muy burocráticos. Para estas organizaciones, aplicar shift left a la gestión de cambios supone una ruptura radical con las prácticas centralizadas de “mando y control” actualmente implantadas. Aunque en última instancia puede dar lugar a una reducción de los costes de soporte, la “reducción de costes” no puede ser el principal motor de una iniciativa de shift left.

Más bien, shift left debe centrarse en objetivos como una mejor experiencia del cliente, una mayor capacidad de respuesta a las necesidades del negocio o el empoderamiento del usuario final.

Pero lograr estos beneficios requiere una inversión inicial en cambio cultural, gestión del conocimiento y diseño de procesos, además de mantenimiento continuo y mejora continua para conservar y optimizar las capacidades recién implementadas.

Troy DuMoulin, vicepresidente de Investigación y Desarrollo, Pink Elephant

Fundamentalmente, shift left consiste en desarrollar una cultura de propiedad y responsabilidad sobre los resultados, no solo sobre tareas o actividades personales. De lo contrario, cada individuo actuará bajo el principio de: mi tarea está hecha y el resultado final es problema de otra persona.

Siguiendo el dicho “si lo creas, eres responsable de ello”, creo que el lugar más importante en el que centrar los principios de shift left es en las actividades de desarrollo/creación tanto de los grupos de software como de infraestructura.

Hoy medimos a nuestro personal en función de tareas individuales relacionadas con su puesto o función específicos. Inspirándonos en las métricas Lean y Agile, debemos cambiar el foco hacia métricas centradas en la materialización del valor para el cliente en relación con la calidad, el tiempo y el coste. Métricas como el plazo de entrega, el tiempo de ciclo y el porcentaje de defectos escapados son mucho más significativas y elevan nuestra perspectiva desde las tareas individuales o departamentales hasta la experiencia del cliente de extremo a extremo.

Claire Agutter, directora, Scopism

Para mí, shift left forma parte de la transformación continua del pensamiento en gestión de servicios de TI.

Shift left reduce los tiempos de espera y el desperdicio, por lo que encaja muy bien con Lean. Hace que las cosas sucedan con mayor rapidez, de modo que puede mejorar la experiencia del empleado y la del consumidor. Se basa en el análisis y la observación de nuestro entorno para ofrecer mejoras continuas.

He visto los mayores beneficios en el área del soporte de TI. Los consumidores actuales quieren poder buscar ayuda a través de nuevos canales, por ejemplo mediante redes sociales, o realizar sus propias investigaciones en línea. Las empresas que ponen información a disposición de los usuarios a través de estos canales reducen la necesidad de llamadas al helpdesk. Esto ofrece al consumidor una mejor experiencia y también libera tiempo del personal de TI para que pueda concentrarse en otras actividades que aporten más valor.

Jonah Kowall, vicepresidente de Desarrollo de Mercado e Insights, AppDynamics

En realidad, no me convence demasiado este término aplicado a las pruebas de software, ya que no equivale a lo que vemos en los cambios de gran alcance actuales. Yo veo menos un desplazamiento y más nuevos proyectos impulsados por nuevas metodologías y tecnologías.

La tendencia más importante para TI es ser ágil y formar equipos multidisciplinares de ingeniería de producto.

Ambas tendencias permiten producir software con mayor rapidez, mejorar de forma incremental y capacitar a los miembros del equipo para tomar decisiones y asumir riesgos. Todos estos elementos favorecen mejores resultados de negocio y alinean TI y el negocio de forma más eficaz.

Como destacan estos expertos en TI, la reducción de costes es solo uno de los muchos beneficios de una iniciativa de shift left. Desde empoderar a los clientes hasta fomentar la responsabilidad y mejorar la experiencia de los usuarios y del personal de TI, shift left representa una gran oportunidad para los departamentos de TI.