Cómo clasificar los proyectos de ordenador

¿Cómo decide una organización qué proyecto de procesamiento de la información tiene la máxima prioridad? Si se trata de elegir entre una nueva red de comunicaciones de datos, una nueva aplicación de procesamiento de textos o un nuevo sistema de control de inventario, ¿qué proyecto es probable que gane? Una cosa es segura: los gerentes de los sistemas de información (SI), los ejecutivos corporativos y los usuarios tendrán puntos de vista muy diferentes, y eso es lo más importante. Los intentos de resolver sus puntos de vista contradictorios pueden aumentar la presión arterial de todos.

Las diferencias de opinión pueden ser particularmente agudas en períodos de cambio organizacional, cuando, por ejemplo, un nuevo vicepresidente de finanzas y administración asume la responsabilidad de los sistemas de información, o cuando un comité directivo informático recién creado celebra sus reuniones iniciales. Del mismo modo, un nuevo director de sistemas de información que asuma la responsabilidad de una función existente puede sentirse presionado por el jefe «para que se le ocurra algo» sobre la irritante cuestión de las prioridades. Incluso las instalaciones del Estado Islámico maduras y relativamente tranquilas no son inmunes cuando, por ejemplo, el nuevo motor de la fabricación, recién llegado a escena, pregunta al CEO: «¿Cómo se determinan nuestras prioridades? ¿Existe un enfoque formal o volamos por el asiento de los pantalones?»

Este artículo analiza primero las cuestiones políticas que afectan a las decisiones sobre las prioridades y algunos conceptos erróneos comunes sobre cómo deben determinarse las prioridades. A continuación, describe un enfoque que tiene en cuenta las cuestiones políticas y, por último, identifica los factores clave para la implementación de dicho enfoque.

Factores que afectan a las prioridades

Varios factores influyen en la asignación de las prioridades de los proyectos de procesamiento de la información, cada uno de una manera diferente. Se trata de las ventajas financieras, los objetivos empresariales, las ventajas intangibles y la importancia técnica. Aunque estas consideraciones puedan parecer obvias, implican tanto dificultades como ideas erróneas en muchas empresas, que se analizarán en los párrafos siguientes.

Prestaciones económicas

Las empresas corren el riesgo de adoptar un punto de vista simplista a la hora de fijar las prioridades de los proyectos informáticos. A menudo se da una importancia indebida a los beneficios financieros tangibles a la hora de determinar el orden en que se financian los proyectos. Por lo tanto, un proyecto que se amortice solo (ya sea en función de la amortización o del flujo de caja descontado) en un año ocupará un lugar más alto en la lista que uno que tarde dos años.

Objetivos empresariales

Los proyectos de procesamiento de la información deben promover los objetivos de la organización. Sin embargo, llevar esta idea a la práctica suele ser un quebradero de cabeza a los directores de sistemas de información, ya que en algunas empresas la planificación empresarial en sí misma no está bien desarrollada y puede que no haya una declaración formal de objetivos. En otros, la calidad de la planificación del Estado Islámico es inferior a la de la planificación empresarial. Es posible que las empresas que tienen planes de negocios y de TI formales carezcan de los mecanismos adecuados para vincular los dos. Además, no todas las empresas necesitan planificar sus actividades de IS en la misma medida.1 Las características del plan IS dependen de la naturaleza de la organización. Para algunas organizaciones, como los bancos, en las que el Estado Islámico es un arma estratégica, los planes del Estado Islámico totalmente integrados son vitales. En otros, donde estos proyectos tienen menos impacto en el desempeño corporativo, la necesidad de una planificación cuidadosa no es tan grande.

Prestaciones intangibles

Algunos beneficios importantes de un proyecto de SI no se pueden medir fácilmente (por ejemplo, una mejor presentación de la información, un mejor apoyo a las decisiones o la satisfacción de una necesidad operativa). En lugar de forzar los cálculos para demostrar los beneficios, me parece más sensato y práctico aceptar la premisa de que el procesamiento de la información a veces puede beneficiar a la empresa de formas importantes pero inconmensurables. De hecho, a veces los beneficios intangibles pueden ser más importantes que los tangibles. Esto es particularmente cierto, por ejemplo, en el caso de proyectos de software de procesamiento de información, como la conversión de sistemas operativos, el diseño de redes de datos y la creación de bases de datos para varias aplicaciones.

Importancia técnica

A veces es esencial o muy conveniente emprender un proyecto antes que otro, aunque no sea por otra razón que las limitaciones que imponen las capacidades del personal técnico. Además, pueden intervenir consideraciones de la arquitectura del sistema. Por lo tanto, el diseño de una nueva red puede preceder con sensatez a un sistema que utilice comunicaciones de datos y, para un banco, un nuevo archivo maestro de clientes puede preceder a la introducción de un sistema de depósito a la vista revisado.

En las organizaciones con un enfoque pronunciado en los beneficios financieros y en los resultados finales (el tipo de «apoyo» descrito por Warren McFarlan, por ejemplo), es posible que los altos ejecutivos no se den cuenta de la importancia que pueden tener las cuestiones técnicas a la hora de establecer las prioridades.2 Como resultado, los gerentes de sistemas de información astutos deben ocultar el tema combinando los proyectos de forma creativa en un solo paquete vendible o asignando recursos a los proyectos técnicamente importantes sin el conocimiento de los directivos superiores.

Aunque los cuatro factores que se acaban de describir afectan al proceso de establecimiento de prioridades, es muy posible que presenten imágenes contradictorias. Por ejemplo, un proyecto puede no tener beneficios financieros, aunque claramente apoya los objetivos empresariales (por ejemplo, una campaña de correo para apoyar un programa de creación de imagen corporativa) o un proyecto con beneficios financieros considerables, como un nuevo sistema de inventario para la línea de productos X, puede no respaldar los objetivos empresariales de aumentar la cuota de mercado en la línea de productos Y. Un proyecto importante desde el punto de vista técnico, como el desarrollo de un software especializado para mejorar la seguridad informática, puede tener pocos beneficios financieros y una adaptación cuestionable a ciertos negocios objetivos. Sin embargo, puede que merezca una mayor prioridad porque, por ejemplo, el comité de auditoría del consejo ha expresado su grave preocupación por la seguridad.

Los responsables de la toma de decisiones

Para complicar aún más el establecimiento de prioridades, está la cuestión de quién debe definir las prioridades de procesamiento de la información. Tenga en cuenta estos tres conceptos erróneos comunes.

Los usuarios deben decidir las prioridades. No deberían; al menos no solos y no cuando tienen un nivel operativo bajo. Aunque está claro que son importantes para el proceso de establecimiento de prioridades, los directores de operaciones de nivel inferior generalmente no tienen un conocimiento suficiente de los objetivos empresariales generales y de las cuestiones técnicas como para tomar las decisiones correctas por sí mismos. Los altos directivos están, por supuesto, en mejores condiciones para decidir las prioridades, aunque es posible que no siempre estén informados de todos los factores. La importancia técnica de cualquier proyecto puede pasarse por alto, por ejemplo.

Los directores de operaciones y de TI deben definir las prioridades conjuntamente. Este punto de vista pasa por alto el hecho de que los altos ejecutivos deben desempeñar un papel integral en el proceso. Esto es especialmente cierto cuando los sistemas de información tienen una importancia estratégica y en situaciones de «cambio». En esos casos, es esencial relacionar estrechamente los proyectos de SI con los objetivos empresariales. Además, en cualquier organización, solo los altos ejecutivos pueden tomar la decisión final sobre la asignación de los escasos recursos entre dos proyectos igual de atractivos. Pueden optar por ambas y añadir los recursos en consecuencia, pero dejarlos fuera del proceso se antepone a esa decisión.

Un comité directivo informático puede decidir las prioridades. A veces esto es cierto. Sin embargo, un comité así puede participar en la política y acabar centrándose únicamente en los beneficios financieros. Además, un comité directivo no será un foro útil de debate a menos que incluya a representantes de los usuarios, el Estado Islámico y la alta dirección y cuente con un buen apoyo de personal.

Sin duda, la mejor manera de fijar las prioridades es convertirlas en un subproducto de algún proceso de planificación formal a nivel corporativo o de unidad de negocio. Lamentablemente, pocas organizaciones tienen procesos de planificación tan explícitos y ordenados que puedan confiar únicamente en ellos para determinar las prioridades de los sistemas de información. Además, incluso cuando se formaliza la planificación de las unidades de negocio y de la SI, las cuestiones prioritarias pueden seguir planteando problemas graves.

Hace poco, una empresa de alimentos multimillonaria realizó un ejercicio de planificación detallada para su división de alimentos de consumo. Los planificadores y los controladores de las divisiones se esforzaron seriamente por traducir las implicaciones para los sistemas de los diez planes de unidades de negocio en proyectos de TI con dólares y centavos, y sugirieron prioridades. Sin embargo, la consolidación de los planes a nivel divisional ha provocado fricciones y malentendidos. El personal del Estado Islámico y el jefe de grupo del$ La división de 2000 millones no estuvo de acuerdo en cuanto a la necesidad de los 30% el aumento presupuestario de los gastos de TI y los nuevos sistemas propuestos.

Siendo realistas, en la mayoría de las organizaciones el director de sistemas de información debe desempeñar el papel más activo a la hora de establecer las prioridades. Debe tratar de conciliar los conflictos relacionados con los criterios clave. Está claro que el proceso no solo requiere tener en cuenta algo más que los beneficios financieros, sino también la participación de personas que tengan una perspectiva amplia. ¿Cómo puede el director de TI medir la importancia relativa de los beneficios financieros e intangibles, evaluar su adecuación a los objetivos y expresar la importancia técnica de una serie de proyectos de una manera fácilmente comprensible?

Implementación del enfoque

En el gráfico I se muestra cómo implementar el proceso de establecimiento de prioridades. La interacción continua con los altos directivos es muy conveniente tanto para obtener orientación (sobre los objetivos, por ejemplo) como para que conozcan los factores que afectan a las decisiones finales sobre las prioridades del proyecto.

Prueba I Establecer prioridades

Los ocho pasos detallados de la prueba I probablemente se apliquen solo a las empresas cuyos sistemas de información están casi sumidos en el caos. Las empresas que ya tienen actividades de procesamiento de la información bien documentadas y declaraciones claras de sus objetivos empresariales deberían poder centrarse inmediatamente en los pasos 4 a 7, que describen el proceso de clasificación en sí. Estos cuatro pasos no son secuenciales y superponerlos acelerará el proceso de establecimiento de prioridades. Además, empezar pronto con el paso 7 (evaluar el ajuste entre los proyectos y los objetivos empresariales) podría acortar la lista que se está considerando, ya que debería ser posible eliminar los proyectos marginales. Además, si los objetivos tienen un enfoque llamativo en los resultados finales, el análisis de los beneficios intangibles también podría restringirse.

Por último, aunque el método que describo tiene ocho pasos discretos, en la práctica debe ser, hasta cierto punto, iterativo. Esto es especialmente cierto para el examen de los costes y beneficios financieros del desarrollo de cada proyecto (paso 4).

Establecer prioridades

Paso 1: tomar el control del procesamiento de datos.

Cuando no se adopte un proceso formal de establecimiento de prioridades, es probable que ya existan varios problemas. Es muy posible que algunos miembros del personal fijen sus prioridades, el síndrome de «ellos contra nosotros», una mala comunicación con los usuarios y acciones unilaterales por parte de los directores de procesamiento de datos.

Está claro que, en una situación así, ningún enfoque puede ser eficaz. El recién nombrado director de procesamiento de la información primero debe tomar el control tomando una o más de las siguientes medidas: establecer mecanismos mejorados para interactuar con los usuarios, reorganizar el procesamiento de datos y contratar nuevo personal, crear algún tipo de comité directivo informático y mejorar la base de información de los proyectos pendientes.

Paso 2: documentar sistemáticamente.

Parte del problema a la hora de ordenar las prioridades se debe a la documentación inadecuada de las solicitudes de proyectos. Puede haber varias deficiencias: un enfoque anticuado, aleatoriedad en la forma en que se documentan los proyectos, procedimientos de autorización deficientes o mala comunicación sobre los proyectos dentro del departamento de sistemas de información y/o entre los usuarios y la dirección. Como resultado, es posible que el director del Estado Islámico no tenga los datos necesarios para evaluar y clasificar los proyectos.

Como se ha escrito mucho sobre la documentación de los proyectos, no voy a hablar de este importante tema en detalle. Sin embargo, en general, la documentación adecuada exige establecer, en términos generales, los datos necesarios para las distintas clases de proyectos, por ejemplo, el procesamiento de datos y la automatización de oficinas. Es probable que sea imposible lograr una uniformidad total en todos los proyectos de SI, ya que las organizaciones se encuentran en diferentes etapas del uso de las distintas tecnologías. Es posible que los gerentes se vean obligados a estimar los datos de algunos proyectos (prototipos, por ejemplo) y, al mismo tiempo, tener una base más sólida para calcular los costes de otros con precisión. Por lo tanto, siempre será esencial un poco de flexibilidad.

Además, las empresas deberían desarrollar procedimientos estándar mediante los cuales los proyectos se identifiquen y presenten para su aprobación (que permitan diferentes clases de proyectos) y convertir las solicitudes informales de proyectos pendientes a los nuevos procedimientos y formatos estandarizados. Los planificadores deben describir no solo los beneficios tangibles sino también los intangibles, la adecuación a los objetivos y la importancia técnica de cada proyecto. La dirección debe insistir en el cumplimiento de los nuevos procedimientos para todos los proyectos.

Paso 3: aclarar los objetivos empresariales.

Como se ha mencionado anteriormente, puede resultar difícil aclarar los objetivos empresariales, ya que la importancia que se asigna a la planificación varía de una organización a otra. Algunas tienen declaraciones formales de objetivos, otras no. Sin embargo, las empresas que ignoran los objetivos pueden dedicar los escasos recursos a proyectos con un impacto marginal. Y esto puede suponer una doble pérdida, ya que también renunciarán a las ventajas que podrían derivarse de la utilización de recursos en proyectos que sirvan mejor a sus objetivos empresariales.

En un entorno en el que la planificación formal no esté bien desarrollada, el director de TI debería tomar la iniciativa e intentar exponer los objetivos empresariales personalmente para que los revise la alta dirección. Un enfoque amplio y pragmático es esencial, ya que ningún departamento de TI puede transformarse repentinamente en un departamento de planificación corporativa completo, ni debería hacerlo. El objetivo de este ejercicio único es situar los proyectos del Estado Islámico en su contexto empresarial.

El director de TI busca orientación principalmente sobre dos temas, a saber, lo que la organización trata de lograr y la naturaleza de las principales limitaciones. Al analizar la primera, querrá la opinión de la dirección sobre objetivos como aumentar la penetración en el mercado, reducir los costes operativos, expandirse internacionalmente y acelerar el desarrollo de productos. Al analizar las limitaciones, serán importantes cuestiones como los horizontes temporales, los recursos y las posibles respuestas competitivas.

La mejor manera de proceder es combinar las entrevistas juiciosas a los directores de empresas, jefes de división, administradores de territorios y otros con una lectura detenida de los documentos internos y una revisión rápida del procesamiento de la información de los principales competidores. El elemento más importante en este caso es entrevistar a los responsables de la toma de decisiones.

Aunque las opiniones difieren entre los responsables de la toma de decisiones, es casi seguro que estarán de acuerdo en los tres o cuatro objetivos principales. El director de TI puede basarse en ellas mediante reuniones de debate y revisión con un grupo directivo de alto nivel adecuado, como un comité de operaciones, un comité de políticas o un comité directivo de ordenadores. El resultado será un consenso en la lista de objetivos que, aunque no es perfecto, puede servir más adelante de guía para evaluar y clasificar los proyectos de procesamiento de la información en función de su adecuación a los objetivos de la empresa en el paso 7.

Paso 4: Clasificar en función de los costes y beneficios financieros.

El requisito previo para este paso es el análisis clásico de los costes y beneficios proyecto por proyecto. Como los resultados de cada proyecto son diferentes, el director debe calcular las cifras basándose en una serie de suposiciones relacionadas con el desarrollo interno, la programación de subcontratos, el paquete comprado, etc. El objetivo debe ser lograr el equilibrio óptimo entre los distintos medios de poner en funcionamiento las aplicaciones, no solo el coste de llevar a cabo los proyectos internamente.

El nivel de detalle necesario dependerá, por supuesto, de factores como la política corporativa, el tiempo y la disponibilidad de la información. A veces, también, el único curso práctico puede ser hacer estimaciones brutas. Una vez conocidos los costes y beneficios, el director puede mostrar su estado de prioridad relativa en una cuadrícula de nueve cuadrados. La prueba II ilustra la clasificación de una serie de aplicaciones informáticas para un banco europeo según cada uno de los criterios analizados. El mismo método se aplica, por supuesto, a cualquier conjunto de proyectos de procesamiento de información (como el procesamiento de textos, las comunicaciones de datos y la ingeniería de software), no solo a los que utilizan el ordenador.

Anexo II Cuadrículas prioritarias

En la prueba II, las calificaciones bajas, medias y altas dependerán de la organización. ¡Lo que sea alto para Exxon será bajo para el Pentágono! Aparecen quince proyectos, identificados por número. En la cuadrícula A, el proyecto 1, «Cuentas corrientes», se sitúa en la parte inferior derecha de la cuadrícula porque tiene grandes beneficios financieros y requiere un alto nivel de inversión. Por otro lado, el proyecto 4, «impuestos», aparece en la parte superior izquierda porque ofrece pocos beneficios financieros y requiere una inversión baja.

Con tal variedad de proyectos, los altos directivos pueden determinar, de un vistazo, los costes y beneficios relativos de toda la cartera de proyectos. Por supuesto, se sentirán atraídos por los que caigan en la plaza de arriba a la derecha: grandes beneficios financieros y bajas necesidades de inversión. Por desgracia, es probable que sean poco frecuentes. Muchas empresas, por ejemplo, que han empezado a abordar el problema de las aplicaciones clave obsoletas debido a la falta de inversión en el procesamiento de datos se han dado cuenta de que es probable que estos proyectos se posicionen en la parte inferior izquierda; es decir, requieren una inversión significativa y producen pocos beneficios financieros.3 Una empresa minera, que tiene que cuantificar los beneficios de rediseñar su sistema de nóminas de 1956, se da cuenta de que la tarea requiere una combinación de brujería y análisis financiero. La mayoría de estos análisis son muy cuestionables.

Sin embargo, esta misma empresa ha obtenido un beneficio inesperado al analizar detenidamente sus sistemas de información y los costes, los beneficios y las cuestiones prioritarias. La alta dirección se convenció de que tenía un grave problema con la dotación de personal de la función; simplemente no tenía suficientes personas para hacer otra cosa que no fuera lo mínimo. Dado el entorno económico hostil, en lugar de añadir personal, la empresa tomó la decisión informada de retrasar los proyectos. Como resultado, el director del Estado Islámico podría hacer su trabajo sin presiones injustificadas para que realizara los milagros que antes se esperaba que produjera.

Paso 5: clasificar las prestaciones intangibles.

Se trata de un proceso de cuatro partes. La primera parte identifica los beneficios intangibles que tanto el procesamiento de datos como los administradores de usuarios consideran alcanzables. La segunda parte determina el método de puntuación de la evaluación. La tercera parte asigna valores numéricos a cada proyecto para que los beneficios se puedan clasificar por orden de importancia. Por último, la parte 4 coloca los proyectos en una cuadrícula de nueve cuadrados.

Un equipo compuesto por usuarios, como los directores de operaciones departamentales, y por profesionales de los sistemas de información con conocimientos sobre las áreas afectadas por los proyectos debería llevar a cabo este proceso. Para añadir imparcialidad al ejercicio, incluya al jefe de auditoría interna.

Al trabajar en sesiones grupales y de forma independiente, los miembros del equipo pueden identificar los beneficios intangibles y cada miembro del equipo pone sobre la mesa su percepción de cuáles son: recuperación más rápida de la información, mejora de la imagen, mejor toma de decisiones, etc. Probablemente se pongan de acuerdo rápidamente en algunos objetivos, pero tendrán que golear otros.

El enfoque grupal también tendrá más éxito en la segunda parte del proceso: la elección del método de puntuación. Son posibles varios sistemas. Sin embargo, los directivos deben tener cuidado de no complicar demasiado el proceso al adoptar un método que sea muy complejo o falsamente científico. En la ilustración del Anexo III, por ejemplo, el equipo adoptó un sistema sencillo que asignaba a cada prestación intangible un máximo de diez puntos y, tras un breve debate, decidió no ponderar ni puntuar algunas prestaciones por encima de otras. Ponderar las prestaciones puede dar lugar a discusiones interminables que no sirven de mucho. No se trata de una ciencia exacta; el objetivo es llegar a una medida amplia de la importancia relativa de cada proyecto.

Anexo III Calificación de los beneficios intangibles

Para la tercera parte, la valoración de los proyectos en función de los beneficios, los miembros del equipo deberían trabajar de forma independiente y, después, reunirse en grupo para resolver las diferencias. En estas reuniones, cada persona debe estar preparada para explicar, por ejemplo, si un proyecto obtiene cinco sobre diez y otro obtiene la máxima puntuación, qué hace que uno sea dos veces mejor que el otro.

Las reuniones concluirán con una hoja resumida similar a la del Anexo III, en la que se muestran las puntuaciones de cada proyecto para cada beneficio intangible, la puntuación total y la clasificación general.

Con los proyectos clasificados de esta manera, la parte 4, posicionar cada uno en una cuadrícula de nueve cuadrados, es un último paso fácil. Lo único que queda es que el equipo determine el rango a lo largo del eje horizontal para obtener beneficios intangibles altos, medios y bajos. No es sorprendente que el valor de un proyecto sea muy diferente según se defina por sus beneficios intangibles o financieros. Por ejemplo, en la cuadrícula A del anexo II, el proyecto 1, «Cuentas corrientes», las tasas son altas en términos de beneficios financieros. Sin embargo, en la red B tiene una calificación baja en cuanto a beneficios intangibles. Lo contrario ocurre con el proyecto 13, «Comunicaciones y hardware». Es poco probable que genere ahorros en efectivo, pero promete muchos beneficios intangibles.

Paso 6: clasificar según la importancia técnica.

Algunos proyectos deben completarse antes que otros. Los directores de procesamiento de datos pueden mostrar la importancia técnica de cada uno de los proyectos en el formato que se muestra en la cuadrícula C del anexo II. Una vez más, el eje vertical representa la inversión, mientras que el eje horizontal muestra los niveles de importancia técnica bajos, medios y altos. Aunque esto representa una evaluación subjetiva por parte de los directores de procesamiento de datos, los ejecutivos de alto nivel pueden ver más fácilmente la clasificación en este esquema sistemático.

Paso 7: evaluar la adecuación a los objetivos.

Una vez aclarados los objetivos empresariales (consulte el paso 3), los usuarios y los directores de procesamiento de datos pueden evaluar juntos la calidad del ajuste entre ellos y los proyectos, mediante una hoja de trabajo en la que se comparan los proyectos con varios objetivos. También es posible desarrollar un enfoque cuantitativo en el que la contribución de un proyecto a un objetivo se indique numéricamente, con una puntuación máxima de 10, por ejemplo, para un ajuste perfecto.

Una vez establecido el grado de adecuación a los objetivos empresariales, el director de TI puede clasificar los proyectos en un formato de cuadrícula similar de nueve cuadrados.

Paso 8: resumir las prioridades.

Las exposiciones darán a la alta dirección una buena imagen de las distintas formas de medir el valor de un proyecto y, en consecuencia, de las complejas cuestiones que implica el establecimiento de las prioridades generales. Para conciliar la información, a veces contradictoria, se pueden resumir las prioridades en una sola cuadrícula de nueve cuadrados, como hizo una empresa en el Anexo II.

El número de veces que un proyecto aparece en un cuadrado concreto de las matrices de nueve cuadrados ayuda a determinar la evaluación final. Por ejemplo, el proyecto 5, «contabilidad», aparece en la esquina inferior derecha en todos los casos, y el proyecto 15, «archivo maestro de condiciones», aparece tres de cada cuatro veces. Evidentemente, estos dos proyectos deberían tener una alta prioridad.

Pero la evaluación final depende de las prioridades de la empresa. Si las prioridades se hubieran asignado y medido en función de los beneficios financieros en este caso, los resultados habrían sido muy diferentes. Otros tres proyectos se habrían colocado por encima del proyecto 15: el proyecto 1, «cuentas corrientes», el proyecto 2, «letras de cambio», y el proyecto 3, «bonos». Sin embargo, los tres proyectos «de máxima prioridad» solo se ajustaban moderadamente bien a los objetivos empresariales, y dos de los tres tenían poca importancia técnica y solo algunos beneficios intangibles.

La cuadrícula compuesta pone de relieve esas inconsistencias y proporciona a los ejecutivos los datos necesarios para seleccionar las prioridades. Por lo tanto, en el ejemplo, los altos directivos podrían decidir ignorarlo todo excepto los beneficios financieros, pero lo harían entendiendo que la mayoría de los proyectos no cumplían los objetivos empresariales de manera eficaz.

Además, con el conocimiento de cómo los diferentes factores afectan a las prioridades, los ejecutivos pueden cambiar el grado de énfasis que se da a cada uno de ellos en función de las circunstancias corporativas. En tiempos difíciles, por ejemplo, podrían decidir que solo se deben tener en cuenta los beneficios tangibles.

Factores clave del éxito

En este proceso de establecer las prioridades de los ordenadores, el éxito depende de la interacción de tres grupos de personas, a saber, los ejecutivos de alto nivel, los usuarios y los directores de sistemas de información. Cada uno tiene un papel importante que desempeñar.

Los ejecutivos de más alto nivel deben demostrar su voluntad de destinar recursos a proyectos aprobados de alta prioridad. Deberían participar en el establecimiento de las prioridades y, en particular, en la determinación de qué aspecto del establecimiento de prioridades debe ser más importante en un período de tiempo determinado. También deberían ayudar a aclarar los objetivos empresariales de modo que todo el proceso pueda estar relacionado con las necesidades subyacentes de la empresa. Por último, deben estar dispuestos a ejercer su juicio y a tomar decisiones en áreas en las que tradicionalmente no ha participado la alta dirección.

La función de los usuarios es comprometerse con los beneficios indicados en el análisis de costes y beneficios de cada proyecto e implicarse en el proceso para que las decisiones finales reflejen un consenso. En este caso, por ejemplo, es particularmente importante entender los beneficios intangibles y comprometerse con ellos.

Los directores del Estado Islámico deben dirigir el proyecto y ser responsables de su progreso. Deben analizar las cuestiones y desarrollar los cuatro planes de establecimiento de prioridades para la toma de decisiones ejecutivas.

Por último, una advertencia: es importante basarse en el marco existente para fijar las prioridades; rara vez debería ser necesario o incluso deseable empezar de cero.

Los recursos analíticos y de programación cada vez son más escasos y costosos. Tenemos que utilizarlos de forma eficaz asignándolos a proyectos de alta prioridad. Identificarlos mediante un enfoque estructurado ayudará al director y a los altos ejecutivos del Estado Islámico acosados a analizar los problemas.

1. Véase F. Warren McFarlan, James L. McKenney y Philip Pyburn, «The Information Archipelago—Plotting a Course», HBR de enero a febrero de 1983, pág. 145.

2. Ibíd.

3. Consulte mi artículo, «Penny-Wise Approach to Data Processing», HBR, julio-agosto de 1981, pág. 111.