Llegamos a ustedes gracias a:



Columnas de opinión

12 formas de tomar decisiones tecnológicas realmente malas

Por: Isaac Sacolick, presidente de StarCIO

[11/08/2021] Cuando ve las nuevas tecnologías, ¿es usted como un niño en una tienda de caramelos, emocionado por probar cada una de las últimas innovaciones? ¿Quizás un líder de su organización es un jugador tecnológico, y está dispuesto a seleccionar proveedores sin el suficiente análisis y la debida diligencia? ¿O tal vez el director de compras, la oficina de gestión de proyectos o las partes interesadas del negocio someten las selecciones tecnológicas a una investigación tan exhaustiva que su organización se queda en la estela de la innovación y atascada en el barro con plataformas heredadas?

Estas personas que compran tecnología se encuentran en muchas organizaciones, y pueden socavar la capacidad de los líderes tecnológicos para realizar selecciones tecnológicas sabias y oportunas. La selección de tecnología al azar conduce a un esfuerzo desperdiciado y a una deuda técnica, mientras que los enfoques demasiado metódicos ralentizan el ritmo de la innovación y frustran la experimentación, la asunción de riesgos inteligente y las culturas ágiles.

Estas personas pueden hacer descarrilar su proceso de decisión tecnológica de muchas maneras, desde empantanar el proceso de evaluación tecnológica de su organización hasta perjudicar la toma de decisiones sobre cuándo invertir en tecnologías y qué productos o servicios considerar. He aquí 12 antipatrones a los que hay que prestar atención. Si quiere tomar decisiones tecnológicas acertadas, no haga lo siguiente:

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Aceptar la opinión de los ejecutivos como decisión final

Cuando el director general u otro ejecutivo influyente pide al equipo de tecnología que compre e implemente una solución tecnológica específica, es fundamental dar unos pasos hacia atrás para entender la razón de ser. ¿Qué problema está tratando de resolver este líder y en qué medida la solución satisface las expectativas? Con demasiada frecuencia, escucho a los líderes tecnológicos aceptar la voz del ejecutivo como un edicto, y no tomar medidas para racionalizar el enfoque o presentar alternativas.

Una solución es crear la disciplina de redactar y presentar declaraciones de visión de una página que se centren en un problema, una oportunidad o una propuesta de valor. Las declaraciones de visión bien elaboradas definen los objetivos, pero no son prescriptivas en cuanto a las soluciones o las implementaciones. Incluso si el equipo técnico rellena esto en nombre del ejecutivo, a menudo conduce a una discusión y debate sobre múltiples soluciones.

No solicitar ni tener en cuenta la opinión del cliente

Como tecnólogos, a veces cometemos los mismos errores que los ejecutivos cuando se lanzan a las implementaciones. Vemos el problema, conocemos una solución y un sentido de urgencia nos impulsa a implementar el arreglo. Por desgracia, al no incluir la voz del cliente en el proceso de toma de decisiones, o al no entender los beneficios (o no) para el cliente, podemos fácilmente ofrecer capacidades que no dan en el blanco. A menudo, las organizaciones ni siquiera definen formalmente quién es el cliente de determinados proyectos tecnológicos.

Definir un cliente es más fácil cuando se desarrollan aplicaciones para usuarios finales, definiendo roles y personas. Pero encontrar un rol de cliente puede ser más difícil cuando se consideran las capacidades de back-end, incluyendo la infraestructura, las capacidades de seguridad, el middleware, las bibliotecas o los servicios web. Pero los tecnólogos también forman parte del negocio. Los arquitectos, los analistas de negocio o los responsables de tecnología pueden servir como representantes del papel del cliente cuando se implementan tecnologías de back-end. Pídales que proporcionen los requisitos, identifiquen los criterios de aceptación, tomen decisiones sobre las compensaciones y evalúen su satisfacción con la solución implementada.

Ignorar las normas y tecnologías existentes

Históricamente, los departamentos técnicos han tenido dificultades para crear y mantener la documentación, y para comunicar y gestionar los estándares. Por eso, cuando surge una solicitud urgente o un requisito de primer orden, es más probable que busquemos nuevas soluciones en lugar de investigar y reutilizar las capacidades existentes.

Este enfoque a menudo conduce a capacidades redundantes, soluciones a medio desarrollar y una deuda técnica creciente. Añadir un paso de "investigación de soluciones internas" antes o como parte de la investigación de nuevas soluciones, es una disciplina sencilla que puede aumentar la reutilización. Cuando la gente recomiende nuevas tecnologías, cree un proceso para estimar las actualizaciones de las plataformas heredadas o para consolidar tecnologías con capacidades similares.

Fomentar una cultura tecnológica de un solo proveedor y un solo enfoque

¿Ha oído alguna vez a alguien afirmar con rotundidad: "Somos una tienda x", como forma de restringir cualquier investigación, revisión y consideración de otros proveedores o tecnologías? Una cosa es tener estándares y proveedores preferidos. Otra cosa es desconocer las capacidades de terceros y obstaculizar el debate sobre las alternativas.

Permitir que la voz de unos pocos y fuertes defensores de la plataforma ahogue cualquier exploración y experimentación puede conducir a costosos errores. Los responsables de tecnología deben abordar abiertamente este antipatrón cultural, especialmente si impide que la gente haga preguntas o desafíe el pensamiento del statu quo

Presumir que construir o comprar es la única opción

Existe una amplia zona gris entre la creación de soluciones con código personalizado y la compra de SaaS u otras tecnologías que proporcionan capacidades listas para usar. En medio se encuentran las plataformas de bajo código y sin código altamente configurables, las asociaciones comerciales y las oportunidades para aprovechar las tecnologías de código abierto.

Por tanto, construir o comprar es una simplificación excesiva. Un mejor conjunto de preguntas es si las capacidades requeridas ayudan a diferenciar el negocio, y qué tipos de soluciones ofrecen más innovación y flexibilidad a largo plazo.

Asumir que las APIs satisfacen las necesidades de integración

La mayoría de los sistemas modernos de SaaS e incluso muchos sistemas empresariales ofrecen API y otras opciones de integración. Pero la catalogación de los ganchos de integración debe ser solo el comienzo de la investigación para saber si satisfacen las necesidades del negocio. ¿Qué datos expone la API? ¿Son compatibles las vistas y transacciones deseadas? ¿Puede conectar fácilmente las herramientas de visualización de datos y de aprendizaje automático? ¿Tiene la API un rendimiento suficiente y existen costos de uso subyacentes que deban tenerse en cuenta?

Los enfoques para acelerar las revisiones de las capacidades de integración incluyen estas tres formas de validar las API y aprovechar las plataformas de integración de código bajo.

No realizar la debida diligencia social

Cuando nos enfrentamos a una larga lista de posibles soluciones, las fuentes de información de confianza pueden ayudarnos a reducir el campo de juego. La lectura de blogs, libros blancos, reseñas e informes de investigación, así como el visionado de seminarios web, conferencias magistrales y tutoriales en línea son pasos clave para el aprendizaje. Pero una herramienta que a menudo se deja de lado es el aprovechamiento de las redes sociales para consultar a los expertos.

No hay que pasar por la prueba de concepto

El arte, la artesanía y la ciencia de la selección de tecnologías implica el diseño y la ejecución de soluciones de prueba de concepto (PoC) que validan las suposiciones y prueban los requisitos estratégicos clave. Las PoC son especialmente importantes cuando se validan tecnologías emergentes o se evalúan plataformas SaaS, pero incluso el uso de picos ágiles para revisar componentes tecnológicos de terceros ayuda a acelerar la toma de decisiones y a evitar errores costosos.

El mayor error puede ser saltarse la PoC, ya sea porque se cree lo que se ha leído, se confía en el proveedor o se tiene demasiada presión de tiempo. Incluso cuando una PoC da luz verde a una tecnología, lo que se aprende de la PoC puede ayudar a dirigir las prioridades hacia implementaciones factibles.

Desarrollar matrices de decisión elaboradas

Cuando muchas personas participan en la revisión y evaluación de nuevas herramientas y tecnologías, un enfoque común para ayudar a impulsar una decisión basada en datos es crear una hoja de cálculo de matriz de decisión. Las características y capacidades se ponderan según su importancia y luego son calificadas por un comité de revisión. La hoja de cálculo calcula las puntuaciones agregadas.

Desgraciadamente, estas herramientas pueden irse de las manos rápidamente cuando participan demasiadas personas, se eligen demasiadas características o se asignan ponderaciones arbitrarias. La hoja de cálculo acaba priorizando las preferencias de su autor, y la gente pierde de vista lo que hay que evaluar estratégicamente al revisar todas las campanas y silbatos.

Antes de embarcarse en una matriz de decisión, dé un paso atrás. Considere la posibilidad de destilar las características de las soluciones hasta llegar a la esencia del problema empresarial, en lugar de exigir largas listas de características que deben ser evaluadas por demasiados revisores.

Ignorar la arquitectura a largo plazo, el ciclo de vida y las consideraciones de soporte

Soy un gran partidario de evaluar las tecnologías basándose en la facilidad de uso y el tiempo de obtención de valor, pero eso no significa que las consideraciones de arquitectura, mantenimiento y soporte a largo plazo no sean importantes o no requieran una evaluación.

La clave es decidir cuándo evaluarlos, cuáles son las consideraciones clave, quién participará en la revisión y cuánto tiempo invertir en la evaluación. Una buena manera de hacerlo es separar las preocupaciones de entrada que los equipos tecnológicos deben considerar al comienzo de una evaluación de los factores a largo plazo que deben ser entradas en el proceso de toma de decisiones.

Omitir las revisiones de SLA, protección de datos y seguridad

La presión del tiempo o la fe (ciega) en la tecnología elegida son malas excusas para escatimar las revisiones de los acuerdos de nivel de servicio (SLA) y las evaluaciones de las prácticas de seguridad y protección de datos del proveedor. La clave para hacer bien estas revisiones es contar con la experiencia, las habilidades de negociación y las herramientas necesarias, así como con un proceso de evaluación eficiente, de modo que los tecnólogos y los patrocinadores de la empresa no perciban las revisiones como cuellos de botella.

Las organizaciones más grandes que realizan revisiones de SLA, protección de datos y seguridad internamente deben ser eficientes en cuanto al tiempo, y centrar sus esfuerzos en alinear la evaluación con los principales riesgos. Las empresas más pequeñas que no tienen suficiente experiencia deben buscar a personas externas con experiencia en el dominio de la solución.

Retrasar las revisiones financieras y legales

El último punto de mi lista, pero no por ello menos importante, son las revisiones financieras y legales. El anti-patrón aquí es esperar demasiado tiempo para traer a los expertos necesarios para llevarlas a cabo.

Considere que muchas ofertas de SaaS, servicios de API y tecnologías nativas de la nube tienen modelos de precios basados en el consumo, y los costos operativos pueden no ajustarse a las limitaciones presupuestarias o financieras. Las revisiones legales son especialmente importantes para las empresas de sectores regulados o las que operan a nivel mundial, y la revisión de los factores de cumplimiento en ambos casos puede ser especialmente lenta. Tanto para las revisiones financieras como para las legales, los retrasos pueden ser costosos.

No espere hasta el final del proceso de revisión de la tecnología para incorporar a los expertos financieros y jurídicos. Mi consejo es que los incorpore desde el principio y les pida que opinen sobre lo que hay que revisar desde el principio, antes de que se tome cualquier decisión de selección de tecnología. Además, no sobrecargue sus recursos financieros y legales con demasiadas evaluaciones en curso a la vez.

Intentar hacer malabares con múltiples evaluaciones tecnológicas es poco realista para muchas empresas, y los líderes deberían priorizar sus esfuerzos de compra. Si lo hacen, les prometo que es posible realizar revisiones tecnológicas inteligentes, exhaustivas y eficientes.

Isaac Sacolick es el autor de Driving Digital: The Leader's Guide to Business Transformation through Technology, que cubre muchas prácticas como la metodología ágil, devops y ciencia de datos que son fundamentales para los programas exitosos de transformación digital. Sacolick es un reconocido CIO social, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com, también es presidente de StarCIO.

También en este informe: