De tin marin de do pingüé

La rima “de tin marin de do pingüe” era bastante útil para decidir qué sabor de helado quería uno comer cuando era niño. Pero no creo que este jueguito le sea de utilidad cuando está a punto de gastar miles de dólares en un software nuevo. Sin embargo, según lo que he visto, los procesos de toma de decisiones de muchas organizaciones no son mucho más sofisticados que el método que usábamos en la niñez. Nadie niega que las empresas identifican criterios y evalúan software, pero lo que no está muy claro es qué criterios seleccionan y cómo ponderan las evaluaciones. Todo parece indicar que, al final, lanzan todo en el aire y esperan que el resultado se revele por sí mismo.

¿Hay una forma mejor para seleccionar el software correcto para su empresa? Sí la hay. A continuación presento cuatro reglas básicas que pueden mejorar el proceso de toma de decisiones en una organización.

No confunda los criterios con las funciones

Los criterios son los factores de decisión, los elementos que lo llevarán a seleccionar un software y rechazar otros. Las funciones son lo que hace el software, las tareas específicas que puede llevar a cabo o automatizar. Hay muchos procesos de toma de decisiones que confunden estos dos conceptos.

Cuando tenga muchos “criterios”, fíjese muy bien si realmente está describiendo criterios o si simplemente está creando una lista de las funciones que le gustaría tener –es decir, si está repitiendo sus requisitos. Muchos encargados de la toma de decisiones caen en la trampa de agregar funciones como criterios porque creen que de esa forma pueden abarcarlo todo. Así, por ejemplo, un equipo puede incluir el criterio “El software permite asignar tasas de comisión a cada producto”, y aunque puede tratarse de un requisito real, puede no ser útil para el proceso de toma de decisiones.

En algunos casos, uno de los criterios es que ciertas funciones deben estar presentes o ser fáciles de usar. Para tratar estas “necesidades” se puede crear una lista de funciones requeridas y después definir un criterio que indique que el software debe cumplir con todas las funciones requeridas.

Si distingue entre las funciones y los criterios, su proceso de toma de decisiones se volverá mucho más simple.

Distinga entre los pilares y las fichas de póquer

En general, existen dos tipos generales de criterios: los pilares y las fichas de póquer.

Los pilares son aquellos criterios que no son negociables. No se puede considerar el software que no es capaz de satisfacerlos. Por ejemplo, en un proceso de selección que tuvo lugar recientemente, el presupuesto tenía que ser menor a 190,000 dólares canadienses. A la empresa no le importaba el costo, siempre y cuando estuviera por debajo de ese nivel. Ese era un pilar. Otros ejemplos de pilares son la capacidad para dar seguimiento a los lotes (que se usa en las industrias alimenticia y farmacéutica) y para calcular comisiones.

Los pilares son criterios binarios, es decir, son verdaderos o falsos. Pregúntese si eliminará un software de su proceso de selección si no es capaz de satisfacer el criterio que está considerando, sin importar el tamaño de la aplicación.

Por ejemplo, un cliente establece como requisito –un pilar- que la reasignación de almacenes para sus existencias debe ser fácil. El problema no es que haya que hacer estas reasignaciones, sino que tienen que poder hacerse con facilidad. El cliente sabe que casi todas las soluciones de planificación de los recursos empresariales (ERP) le permiten reasignar almacenes, pero también sabe que esta tarea es una práctica muy común en su negocio y que su personal del almacén no se siente cómodo con las computadoras. Si hacer las reasignaciones es una tarea difícil, su personal no lo hará. Como se trata de una firma de ingeniería bajo pedido (ETO), donde la disponibilidad y la ubicación de los componentes son de gran importancia, está dispuesta a no tomar en cuenta las soluciones en las que reasignar almacenes sea una tarea difícil, no importa qué funciones le ofrezca el resto de la aplicación.

En un proceso de selección, el número de pilares no debe ser muy elevado, y el número de criterios específicos debe ser mucho menor aún. En un análisis que realizó un cliente hace poco, había especificado sesenta y tres criterios pilares. Este número está cerca del límite superior recomendado. La mayoría de los criterios eran enunciados generales. Por ejemplo, uno de ellos era “El sistema debe soportar los requisitos de documentación ISO 9001”. Note que este criterio no dice nada sobre la facilidad con que el sistema debe hacerlo, únicamente que debe poder hacerlo. De estos sesenta y tres criterios, no más de doce eran muy específicos –y este es más o menos el número que hay que tener. Si reúne más de sesenta y cinco o setenta criterios pilares, probablemente tenga que reevaluar si son realmente necesarios.

Recuerde que la prueba para un criterio pilar es que si no es verdadero, entonces esa opción no sirve. Cuando los equipos de selección se enfrentan con esto, se dan cuenta de que gran parte de sus “necesidades” son en realidad preferencias y de que si una solución logra satisfacer una cantidad suficiente de los demás criterios, entonces pueden aceptarla, aunque no satisfaga esa “necesidad” particular.

El otro tipo de criterios puede describirse como ficha de póquer, porque se pueden intercambiar. Con estos criterios, puede estar dispuesto a sacrificar el desempeño en un aspecto del software, a cambio de un mejor desempeño en otro. El trabajo difícil es decidir qué será lo que sacrificará.

Las fichas de póquer se evalúan usando una escala continua o gradual y no de manera binaria como los pilares. Estas evaluaciones son lo que determinará qué está dispuesto a sacrificar. Si una solución es mucho más fácil de usar, ¿qué tanto quiere sacrificar en cuanto a confiabilidad del proveedor? Si una aplicación únicamente realiza la mitad de las funciones que desea (pero sí lleva a cabo todas las necesarias) pero cuesta la mitad, ¿es un buen sacrificio?

Para medir el desempeño de una opción es necesario adoptar un enfoque estructurado. Por ejemplo, en una evaluación reciente, uno de los criterios era la facilidad de uso. Se dio al equipo un plan de evaluación de software para que calificara qué tan intuitivo era éste. Durante una reunión que tuvo lugar al principio de la evaluación, el equipo tenía que decidir cuáles eran sus expectativas y qué consideraba como intuitivo. Decidieron tomar en cuenta cuántos errores cometían al llevar a cabo la evaluación, con qué frecuencia tenían que pedir ayuda y cuántas pantallas tenían que recorrer. La calificación promedio de todas las evaluaciones era la calificación para facilidad de uso. Las diferencias entre las calificaciones de las distintas alternativas proporcionaron información de peso para la decisión.

Si distingue entre los criterios pilares y las fichas de póquer, su vida será más fácil. Pero ¿cómo explica todos los requisitos que no son pilares? Una forma para hacerlo es evaluar qué porcentaje de los requisitos cubren las alternativas que se están considerando. En caso de que sea necesario, puede dividir sus requisitos en dos niveles de prioridad y evaluar cada uno de forma independiente.

No use más de diez criterios ficha de póquer

¿Cuántos criterios debe considerar? Entre ocho y diez. Si usa muy pocos es probable que no logre expresar la complejidad de la decisión. Si usa más de diez, pueden suceder dos cosas: uno, que mida el mismo aspecto de la solución más de una vez, y dos, que mida elementos que no tienen mucha importancia. Si tiene criterios sopesados de forma uniforme, entonces cada uno vale diez puntos. Sin embargo, rara vez se pueden sopesar de esa forma, así que agregar un criterio no necesariamente aumenta la probabilidad de que tome la decisión correcta.

De hecho, agregar más criterios sólo dificulta la decisión, y hay una razón estadística para explicar este fenómeno. De acuerdo a la ley de los grandes números, a medida que aumenta el número de variables independientes, la suma de éstas tiende a la suma de las medias. En esencia, cuando hay grandes cantidades de variables independientes, las variaciones normales de las mismas se anulan unas a otras. Así, con grandes números de variables, disminuye la capacidad para discriminar algunas de las distintas alternativas. Si las variables no son independientes, volvemos al problema de medir dos veces los atributos de la solución.

¿Cómo excluye criterios? Para ilustrar este razonamiento podemos usar un ejemplo simple. Si está pensando en comprar un automóvil nuevo, es posible que evalúe el estilo de las luces de cada opción. Sin embargo, al final, no creo que este sea el factor que lo haga tomar una decisión. El hecho de que tenga preferencias y pueda calificar las opciones no quiere decir que tiene que incluir el estilo de las luces como uno de los criterios. De la misma forma, puede tener preferencias con respecto a la fuente que usa la aplicación o el color de fondo de la pantalla, pero en muy raras ocasiones estas características determinarían qué tipo de software va a comprar. Una excepción sería si es difícil leer esa fuente específica o si el color de fondo de la pantalla no contrasta lo suficiente. Pero entonces el enfoque no es en la estética, sino en la facilidad de uso.

Reducir el número de criterios a ocho cuesta trabajo. El equipo tiene que trabajar mucho para encontrar los factores que realmente son importantes, y los criterios tienen que ser prácticos. La tabla 1 contiene cinco pruebas que sirven para determinar cuáles son los criterios eficaces.

Tabla 1. Las pruebas que determinan los criterios eficaces.

La evaluación de la facilidad de uso que describimos antes cumplió con todas estas pruebas.

Cómo limitar la ponderación de criterios

Excluir las alternativas que no cumplen con los criterios pilares y usar entre ocho y diez criterios fichas de póquer facilitan mucho la toma de una decisión en la selección de software. El trabajo necesario para identificar los criterios ayuda al equipo de selección a llegar a un acuerdo común sobre qué alternativa será la solución más adecuada. De esta forma, la decisión suele ser más obvia. El equipo únicamente está tomando en cuenta las cuestiones importantes, así que hay menos desorden con los datos que no afectan la decisión.

Hay un debate sobre la necesidad de ponderar las calificaciones de los distintos criterios al tomar la decisión. La ponderación no es tan crítica. En la década de los setenta se realizaron estudios que demuestran que la selección de criterios influye más en la decisión que la forma en que se ponderan dichos criterios. Uno de los descubrimientos clave de estos estudios fue que la independencia de los criterios es esencial. Es más importante encontrar los criterios correctos.

Según mi experiencia, si decide ponderar los criterios, basta con usar tres niveles distintos: 1, 1.5 y 2. Con ello tiene la libertad suficiente para poner énfasis en ciertos criterios que pueden apoyar estrategias empresariales más amplias sin dar un peso insuficiente o excesivo a los criterios.

Decisiones más fáciles y rápidas que resisten el escrutinio

Será más fácil y rápido tomar decisiones de selección de software cuando los equipos no confundan las funciones y los criterios, distingan entre los criterios pilares y las fichas de póquer y limiten la cantidad de fichas de póquer y la ponderación de los criterios.

Este enfoque tiene más de una ventaja importante para las decisiones de selección de software, además de su velocidad y su facilidad. El hecho de enfocarse en obtener los criterios correctos desde el principio facilita mucho la defensa de la solución. Por ejemplo, una empresa seleccionó el software de un tercero a pesar de que prefería una solución integrada. Pero como había descrito sus criterios claramente y sus métodos de evaluación eran claros, no surgió un debate cuando el equipo del proyecto presentó sus conclusiones ante la dirección. Lo que podía haber suscitado una controversia se convirtió en una cuestión no problemática, porque la dirección estaba de acuerdo con el proceso de toma de decisiones.

Si bien los métodos que describimos aquí no son difíciles, no se utilizan con mucha frecuencia. Las decisiones sobre software se han enfocado siempre en las funciones y los atributos de los sistemas, de manera que el proceso de toma de decisiones ha tendido a la comparación de listas. La falta de consideración sobre cómo evaluar los criterios de decisión ha provocado evaluaciones incompletas o no decisivas que parecen depender más de las preferencias personales que la evaluación de la evidencia. Y la confusión con respecto a las funciones y los atributos de las soluciones ha hecho que los equipos que toman las decisiones no sepan en qué deben enfocarse.

El enfoque estructurado a la selección de criterios es una ayuda inmediata en el proceso de selección de software. Distinguir entre las funciones y los criterios quiere decir que el equipo puede enfocarse en lo que es realmente importante para la organización. Distinguir entre criterios pilares y fichas de póquer simplifica los sacrificios que tendrá que hacer el equipo. Será fácil evaluar criterios ficha de póquer que estén bien seleccionados, y esto limitará la influencia de la ponderación. Además, el proceso entero aumentará la confianza de quienes eventualmente tienen que emitir el cheque para pagar la solución.

Acerca del autor

El Ing. Hugh R. Alley es profesional en gestión de proyectos y director de consultoría en Grant Thornton LLP, consultores en gestión y contadores certificados, en Vancouver, Canadá. Cuenta con veinte años de experiencia en trabajo de mejora de procesos y durante quince años ha actuado como consejero a nivel directivo sobre la definición de requisitos para sistemas de TI. Es ingeniero en sistemas de la Universidad de Waterloo, en Ontario y estudió economía de recursos en la Universidad Cornell, en Estados Unidos. Ha enseñado tanto en la Universidad Simon Fraser como en la Universidad de British Columbia (en Canadá). Escribe y hace presentaciones sobre temas de procesos de toma de decisiones, gestión de riesgo de proyectos, fabricación esbelta y procesos esbeltos. Se puede contactar con él en HAlley@GrantThornton.ca.