Romper el cuello de botella en el desarrollo de sistemas

Con el tiempo de espera para las nuevas aplicaciones que se extiende a varios años, los gerentes y los usuarios han estado buscando enfoques más eficientes para el desarrollo de sistemas. Entre los más prometedores, según estos autores, están el uso de paquetes de software, la creación de prototipos y los sistemas desarrollados por los usuarios. Evaluar los proyectos según los criterios de puntos en común, impacto y estructura puede ayudar a los gerentes a elegir la estrategia de desarrollo adecuada y a hacer llegar las aplicaciones a los usuarios más rápido. De esta manera, más empresas pueden cerrar la brecha entre la promesa y la realidad en cuanto a los beneficios de los sistemas basados en ordenadores.

Hace poco, la alta dirección de un gran fabricante de cartón pidió ayuda a su departamento de sistemas de información (SI) para evaluar las operaciones realizadas con otras empresas. Estas operaciones implican la producción y venta de una calidad de cartón a un competidor a cambio de una calidad diferente que la otra empresa pueda producir de manera más eficiente. La posibilidad de realizar una operación en el momento adecuado por el producto correcto tiene importantes implicaciones competitivas, ya que garantiza que las máquinas se puedan programar para obtener una devolución óptima y, al mismo tiempo, cumplir con los requisitos de los clientes en cuanto a una amplia gama de productos. Según el vicepresidente de marketing: «Cuando hablamos con Sistemas de Información sobre un proyecto que nos ayudaría a evaluar las operaciones a la luz de los mercados y los programas de producción actuales, nos sorprendió bastante. Nos dijeron que, a menos que pudiéramos convencer al grupo corporativo de planificación de sistemas de que cambiara sus prioridades, tendríamos que esperar un mínimo de tres años».

Los plazos de desarrollo de sistemas tan largos no son inusuales. En el caso del fabricante de cartón, el Departamento de Estado Islámico estaba trabajando en una larga lista de proyectos que sus proponentes consideraban todos importantes para el funcionamiento de la empresa. Las prioridades establecidas por un comité directivo de planificación de sistemas corporativos comprometieron al personal del Estado Islámico a emprender proyectos que requerirían varias docenas de años de trabajo para completarse.

En esta empresa, como en la mayoría de las demás, los cuellos de botella se deben principalmente al tiempo necesario para diseñar, programar, probar e implementar sistemas complejos basados en ordenadores y a los limitados recursos disponibles para satisfacer la demanda de desarrollo de sistemas. En el ejemplo de la cartulina, el intervalo de tres años desde la solicitud inicial hasta la implementación consistía quizás en dos años de espera en la cola y un año para desarrollar el sistema. Con recursos limitados, un departamento de TI típico solo puede desarrollar unos pocos sistemas cada año.

Este cuello de botella en la mayoría de las organizaciones deja la demanda insatisfecha durante tres años o más. Otros trabajos de desarrollo de sistemas que probablemente nunca lleguen a la fase de propuesta debido a los retrasos conocidos pueden incluir sistemas que los ejecutivos desean, necesitan y pueden justificar financieramente. De hecho, pueden ser sistemas que proporcionan la ventaja competitiva necesaria para la supervivencia de la empresa.

En respuesta a este problema, muchas organizaciones han recurrido a métodos innovadores para el desarrollo de sistemas. En este artículo evaluamos las tres innovaciones más prometedoras: el uso de paquetes de software de aplicaciones, el desarrollo de prototipos y los sistemas desarrollados por los usuarios. Proponemos un marco para evaluar las solicitudes de desarrollo de sistemas a fin de ayudar a los gerentes a seleccionar la estrategia de desarrollo adecuada.

El problema

Hasta hace poco, la mayoría del desarrollo de sistemas seguía un patrón que Robert Benjamin describió hace unos 20 años.1 El ciclo de desarrollo tiene fases y subfases para determinadas acciones, como se muestra en el gráfico I. En la mayoría de las empresas, para cada nuevo sistema que se desarrolla, el departamento de TI asigna miembros del personal a un equipo de proyecto para que realicen estas acciones en el orden especificado.

Anexo I Modelo de desarrollo de sistemas tradicionales

Estos proyectos de desarrollo tienen un patrón de costes común. Por lo general, alrededor de una cuarta parte del coste se incurre durante la fase de definición, en la que se identifican las funciones básicas del sistema y sus costes y beneficios. Al menos la mitad pasa a la fase de diseño, en la que se escriben, prueban y documentan los programas y procedimientos. El resto del coste se incurre durante la implementación, la formación de los usuarios, el cambio al nuevo sistema y la realización de una auditoría posterior del proyecto. El proceso es a veces iterativo, por supuesto, y el trabajo de una fase anterior se amplía o revisa para obtener resultados posteriores. Estos costes representan principalmente el uso de empleados del Estado Islámico caros y cualificados que escasean.

Varias técnicas pueden aumentar la eficiencia y la productividad del personal de desarrollo de sistemas, especialmente durante el diseño. El diseño y la programación estructurados, varios sistemas de notación especiales, como los diagramas jerárquicos de entrada-proceso-salida (HIPO), los diagramas de flujo de datos y la «mesa de trabajo del programador», aumentan la eficiencia del personal. Aunque muchos departamentos de TI utilizan varios de estos procedimientos, el obstáculo en el desarrollo sigue existiendo.

La dificultad es que estas técnicas son enfoques tácticos dentro de la estrategia tradicional de desarrollo de sistemas. Cuando los profesionales expertos en TI desarrollan sistemas estudiando las necesidades de los usuarios, son adecuadas las maniobras tácticas para hacer que el proceso de redacción de programas y procedimientos que satisfagan esas necesidades de manera más eficiente son adecuadas. Sin embargo, son inadecuados hoy en día, cuando la brecha entre la oferta de profesionales de TI y la demanda de sus servicios sigue ampliándose, cuando la necesidad es de sistemas ahora, no dentro de tres años, y cuando la cartera de pedidos del Departamento de TI aumenta constantemente.

Las soluciones

Varias empresas han recurrido a estrategias alternativas para el desarrollo de sistemas que abandonan el modelo tradicional y que son mucho más productivas que las mejoras tácticas por sí solas. Sin embargo, dado que son radicalmente diferentes, implementarlas puede requerir más atención por parte de la dirección que las medidas tácticas.

Paquetes de software de aplicaciones

La idea detrás de la aplicación de sistemas de paquetes es permitir a las empresas aprovechar la mano de obra que se dedica al desarrollo de sistemas mediante el uso del mismo software en varias instalaciones. Las fases de definición y diseño del esfuerzo de desarrollo implican un coste fijo que suele superar los 75% del total, incurrido en el momento de escribir el paquete. El coste unitario de cada implementación varía según el número de instalaciones. Además, cuanto más a menudo se instale el sistema, mayor será la productividad de los programadores. Las economías de escala resultantes pueden reducir el coste unitario de desarrollo a una pequeña fracción de lo que habría sido si el sistema se hubiera creado a medida para un solo usuario.

El crecimiento explosivo de las empresas que suministran software de aplicaciones demuestra la eficacia de esta estrategia. Estas empresas desarrollan paquetes de programas que abordan cualquier área problemática y los comercializan a una fracción del coste total de desarrollo. La industria, que se espera que llegue$ 100 000 millones en ventas a mediados de esta década se basan en la explotación de las economías de escala inherentes al software de ordenador generalizado. Los observadores del sector predicen que esas empresas venderán más de un millón de paquetes de software de aplicaciones en los próximos diez años.

De las organizaciones que utilizan software estándar, el Servicio Forestal de los Estados Unidos ofrece un buen ejemplo de este enfoque. Estandarizó y mejoró un sistema de apoyo a la planificación desarrollado para un bosque nacional (para$ 150 000) y lo instaló en más de 100 bosques nacionales más. El coste unitario de cada una de estas instalaciones era inferior a$ 15 000. En tal caso, el efecto multiplicador de la instalación en varios sitios va más allá del desarrollo de los sistemas y pasa al mantenimiento, ya que se necesitan muchas menos horas de trabajo para hacer cambios en un sistema instalado en 100 sitios que para cambiar 100 sistemas diferentes en esos mismos lugares.

Decidir si instalar un paquete de software de aplicación es algo así como la tradicional decisión de «fabricar o comprar» en la fabricación. Sin embargo, en la mayoría de los casos, el paquete no cabe perfectamente. La dirección debe compensar el coste de modificar el software con los costes de cambiar los procedimientos o prácticas de la organización para adaptarlos al sistema. La implementación de un sistema «fijo» puede requerir la gestión del cambio organizacional, una función difícil para muchos directores de TI.

La implementación de un paquete no es apropiada, ni siquiera posible, en muchas situaciones. Esto es especialmente cierto cuando las necesidades de los usuarios no se han especificado o no se pueden especificar con precisión. La creación de prototipos es otra estrategia innovadora de desarrollo de sistemas que es útil en este tipo de situaciones.

Prototipado

El enfoque de prototipos para el desarrollo de sistemas aprovecha el avance de la propia tecnología informática, a través de potentes herramientas de software de alto nivel que se hacen prácticas con un hardware económico. Estas tecnologías permiten a los profesionales del Estado Islámico crear sistemas «rápidos y sucios» en respuesta a las necesidades de los usuarios. A continuación, los sistemas se refinan y modifican tal como se usan, en un proceso continuo, hasta que el ajuste entre el usuario y el sistema sea aceptable.

En un estudio sobre la práctica de la creación de prototipos, A. Milton Jenkins y J. David Naumann presentaron un modelo de desarrollo de sistemas de información con este enfoque (véase la prueba II).2

Modelo de prototipo para el desarrollo de sistemas de prueba II

Identificar las necesidades de los usuarios es diferente del paso de definición del modelo tradicional. Como los usuarios y el diseñador identificarán juntos los requisitos finales cuando los usuarios trabajen realmente con el sistema, solo será necesaria una visión rápida de los requisitos de los usuarios desde el principio.

Una innovación importante en el segundo paso de la creación de prototipos es el rápido desarrollo de un sistema de trabajo, normalmente en unos pocos días. Esto se logra mediante herramientas como sistemas informáticos de tiempo compartido, un sistema de gestión de bases de datos (DBMS) con lenguajes de consulta de alto nivel, paquetes generalizados de redacción de informes y bibliotecas de software de modelado. La idea es poner el sistema básico en manos del usuario rápidamente para que pueda empezar el proceso de perfeccionamiento.

Los pasos tercero y cuarto son revisiones repetidas de las etapas anteriores. A medida que los usuarios adquieren experiencia con el sistema, pueden determinar mejor lo que pueden y deben hacer para satisfacer sus necesidades. El diseñador, al trabajar con los usuarios, modifica el sistema en consecuencia. Una vez más, se hace hincapié en responder rápidamente a las solicitudes de cambios, utilizando las mismas herramientas de hardware y software de alto nivel.

Por ejemplo, la capacidad del lenguaje de consultas de muchos sistemas de gestión de bases de datos puede generar, en cuestión de horas, sistemas de recuperación de datos e informes que tardarían semanas en programarse con las técnicas tradicionales. La penalización por esta capacidad es doble. En primer lugar, el método es caro; por ejemplo, un DBMS puede costar más de$ 100 000 y requieren gastos de hardware aún mayores para su funcionamiento. En segundo lugar, el enfoque de prototipos ignora en gran medida los costes operativos, especialmente los del hardware, y se concentra en la productividad del personal. Es probable que el sistema que utiliza estas herramientas consuma muchos más recursos de hardware que el mismo sistema desarrollado de forma tradicional y programado según una serie de, por ejemplo, instrucciones de COBOL.

Sin embargo, cada vez es más evidente que se trata de una compensación rentable. Varias empresas afirman que los costes totales de desarrollo de sistemas mediante el enfoque de prototipos suelen ser inferiores al 25%% de los costes con el enfoque tradicional. Estas empresas descubren que los prototipos de sistemas suelen ofrecer resultados útiles más rápido que los que se desarrollan tradicionalmente. Y los sistemas que surgen de un ciclo de diseño iterativo en el que participan los usuarios suelen ser mejor recibidos que los que se derivan de procedimientos de diseño extensos, aunque únicos.

El enfoque de los prototipos va en contra de las normas tradicionales de desarrollo de sistemas. Su énfasis en la respuesta rápida a las necesidades vagamente especificadas de los usuarios va en contra de una larga lista de métodos de desarrollo de sistemas basados en una definición precisa de las necesidades. Sería muy caro diseñar y programar un sistema con los métodos tradicionales solo para descubrir que abordaba necesidades incorrectas. La naturaleza indulgente del enfoque de prototipos (es decir, crearlo rápida y fácilmente; arreglarlo rápida y fácilmente) permite a los usuarios identificar sus necesidades con un coste menor mediante la experimentación.

La falta de énfasis en la eficiencia operativa puede preocupar a algunos directores de TI. El enfoque del prototipo se basa en el supuesto de que, ante la posibilidad de desperdiciar recursos de hardware o mano de obra cualificada, hay que poner en riesgo el hardware. A un gerente inmerso en la cultura de gestionar instalaciones informáticas grandes y caras para garantizar la eficiencia operativa le puede resultar difícil adoptar esta actitud. Los costes de hardware siempre han sido los más fáciles de captar de los costes del Estado Islámico y, por lo tanto, los que se controlan más de cerca. La estrategia de desarrollo de prototipos de sistemas se basa en gastar dinero en hardware para sacar el máximo provecho a las personas que realizan el desarrollo.

Sin embargo, a pesar de que se ha restado importancia al desarrollo de un sistema completo y eficiente, con la creación de prototipos (y los paquetes, de hecho) se sigue dando la suposición oculta de que el departamento de TI «se encargará» del desarrollo. Si bien estos enfoques reducen drásticamente el tiempo dedicado al diseño y la implementación físicos, los usuarios seguirán dependiendo del personal de TI. En el caso de los paquetes de software de aplicaciones, los profesionales de TI suelen ayudar a especificar y seleccionar el paquete, y es posible que tengan que hacer modificaciones en el paquete una vez adquirido. Con la creación de prototipos, la mayor parte de la responsabilidad de diseño e implementación recae en los profesionales de TI, al menos a corto plazo. Para evitar las demoras inherentes al uso de los escasos recursos de un departamento de TI, hay que tener en cuenta estrategias que eliminen al personal profesional, es decir, los sistemas desarrollados por los usuarios.

Sistemas desarrollados por los usuarios

El término «usuario» en este contexto generalmente se refiere a cualquier persona que no sea un profesional de sistemas y cuya actividad principal sea el desarrollo o la gestión de sistemas basados en ordenadores. Un sistema desarrollado por el usuario se desarrolla con poca o ninguna ayuda de estos profesionales. Estos sistemas van desde programas sencillos escritos por los gerentes para que se ejecuten en sus ordenadores personales hasta el uso de un lenguaje de consultas DBMS para extraer información de la base de datos corporativa.

Para los gerentes, los sistemas desarrollados por los usuarios ofrecen varias ventajas atractivas: (1) la posibilidad de empezar a trabajar en un sistema cuando mejor se adapte al problema, en lugar de tener que esperar a que llegue el cronograma del departamento de TI; (2) reducción del tiempo de desarrollo, especialmente para la definición de los requisitos y los pasos lógicos de diseño; y (3) más satisfacción con el producto final. En este plan, quienes tengan más información y experiencia sobre el problema que se está abordando crearán el sistema. Se ahorra mucho tiempo porque no es necesario explicar el problema, su contexto y su impacto en los demás. Además, el sentido de propiedad que se produce cuando los usuarios son los creadores del sistema facilita en gran medida el proceso de implementación. No puede haber conflictos entre «nosotros» (los usuarios) y «ellos» (los desarrolladores) porque «nosotros» y «ellos» son las mismas personas.

Los usuarios pueden crear estos sistemas con varias herramientas y enfoques, entre los que se incluyen:

Programación de usuario.

Se pueden utilizar lenguajes de ordenador procedimentales como BASIC o FORTRAN para desarrollar el sistema. Este enfoque se hace más popular a medida que más jóvenes directivos se forman en programación en escuelas y universidades y a medida que aumenta la disponibilidad de ordenadores pequeños y baratos. El límite obvio de esta técnica es la capacidad de los programadores aficionados para hacer frente a requisitos complejos de procesamiento y manejo de datos.

Sistemas de análisis de información.

Los lenguajes de programación especializados diseñados para abordar una clase limitada de problemas (como el análisis financiero, los modelos económicos o la evaluación de proyectos) son fáciles de usar porque son específicos de un área, es decir, utilizan terminología y formatos que son «naturales» para el usuario. Esta especificidad también es el principal inconveniente de estos sistemas: normalmente solo se pueden aplicar fácilmente al área problemática para la que se diseñaron.

Idiomas de consulta de bases de datos.

La mayoría de los sistemas de gestión de bases de datos disponibles en el mercado ofrecen idiomas fáciles de usar para acceder a los datos almacenados en el sistema. En muchos sentidos, estos sistemas de lenguaje de consultas del DBMS son similares a los sistemas de análisis de información que acabamos de mencionar, ya que permiten el almacenamiento y el mantenimiento de los datos, la extracción de los datos sin procesar y el análisis y la presentación de informes de los datos en respuesta a solicitudes ad hoc. Las diferencias entre los dos son en gran medida una cuestión de énfasis, ya que los sistemas de análisis de la información se centran más en las instalaciones de análisis y las funciones de presentación de informes y el DBMS se centra más en el almacenamiento y la recuperación de los datos. Con estos lenguajes de consulta, el usuario puede crear sistemas que se utilizarán periódicamente para resumir y generar informes de los datos, así como para responder a las solicitudes de datos.

Las posibles áreas problemáticas del enfoque de sistemas desarrollado por los usuarios incluyen:

• Uso excesivo e imprevisto de los recursos del ordenador. Los ordenadores son mucho más baratos que antes, pero su uso despilfarrador sigue siendo caro. Hacer que los sistemas desarrollados por los usuarios se ejecuten con recursos informáticos compartidos (por ejemplo, un centro de datos corporativo) puede dificultar la planificación de los requisitos de capacidad de ese recurso.

• Métodos de desarrollo inferiores. Los usuarios tienen muchas más probabilidades que los profesionales de TI de desarrollar sistemas que funcionen mal debido a errores de diseño, como la inclusión de datos inapropiados, las pruebas de sistemas inadecuadas y la falta de mecanismos de control y seguimiento de auditoría. El resultado pueden ser sistemas que producen información errónea como base para la toma de decisiones.

• Mala transferibilidad de los sistemas. Cuando los usuarios desarrollan sistemas, a menudo no generan la documentación necesaria para que otros puedan utilizar y mantener el sistema. Los sistemas desarrollados por los usuarios son a veces idiosincrásicos, lo que refleja los sesgos de sus diseñadores. A veces, los nuevos gerentes dejan de utilizar estos sistemas cuando se produce una rotación de personal.

Como ocurre con otras estrategias para superar el cuello de botella en el desarrollo de sistemas, el enfoque de desarrollo de usuarios tiene puntos fuertes y algunos puntos débiles importantes. La dirección debe asegurarse de que (1) la planificación tenga en cuenta la capacidad futura de los ordenadores y la necesaria compatibilidad entre sistemas; (2) el administrador de datos participe en la selección y el uso de los datos; y (3) se apliquen las normas esenciales de desarrollo y documentación para permitir la transferencia de los sistemas a otros usuarios. Con estos controles, una estrategia de sistemas desarrollada por los usuarios puede mejorar la capacidad de respuesta de las aplicaciones informáticas ante los problemas de gestión.

Selección de una estrategia de desarrollo

Todas las estrategias de desarrollo de sistemas, incluso las más tradicionales, tienen sus usos, por lo que una de las principales tareas de gestión consiste en seleccionar la estrategia adecuada.

Nuestros estudios realizados en varias organizaciones sugieren que los proyectos deben evaluarse en términos de tres propiedades básicas: puntos en común, impacto, y estructura—para determinar el método apropiado. Al definir estas propiedades para cada proyecto, se sugerirá la mejor manera de convertirlas en un sistema de información funcional.

Puntos en común

La medida en que otras organizaciones podrían utilizar la solución de sistemas para un problema determinado se conoce como puntos en común. Si se trata de un problema común, es probable que los paquetes de software ya estén disponibles en las empresas de software, las asociaciones industriales, las oficinas de servicios u otras fuentes para realizar las funciones. Para determinar hasta qué punto un proyecto tiene esta propiedad, los gerentes deberían preguntar:

1. ¿La mayoría de las demás empresas de nuestro sector o región tienen básicamente el mismo problema?

2. Si nuestra solución al problema es diferente a la de la mayoría de los demás, ¿por qué es así? ¿Hay motivos competitivos para proceder como lo hacemos?

3. ¿El coste de cambiar nuestros procedimientos para adaptarlos a la solución común es relativamente bajo?

Muchos directivos, al reconocer el valor de no reinventar la rueda, compran paquetes para la nómina, las cuentas por pagar, la contabilidad general y cosas por el estilo. De hecho, todas las aplicaciones de contabilidad pueden ser buenas candidatas para el enfoque de software empaquetado.

Sin embargo, es importante darse cuenta de que la base para evaluar los puntos en común no es la aplicación sino la solución de sistemas. Por ejemplo, una empresa que estudiamos compró un sistema de nómina que, finalmente, necesitó casi$ Modificaciones por valor de 150 000 para adaptarlas a las necesidades de la empresa. Al revisar el proyecto, el controlador explicó: «Tenemos un plan de compensación e incentivos muy complejo para prácticamente todos nuestros empleados. Pensamos que trabajar desde la base de un sistema establecido facilitaría el desarrollo, pero ahora vemos que el paquete acaba de estorbar. Como resultado, estamos cerca de$ 25 000 más que nuestra estimación para un sistema personalizado».

Si el problema es único o los requisitos de la empresa dictan un enfoque único para resolverlo, se recomienda algún tipo de desarrollo interno.

Impacto

El grado en que un sistema afectará a la empresa determina en gran medida el papel que debe desempeñar el profesional de TI en el desarrollo de sistemas. En general, cuanto más generalizado sea el impacto y cuanto más importante sea un sistema para la empresa, mayor será la participación de los profesionales de TI para garantizar el control de calidad en el proceso de desarrollo.

Gordon Davis informa de varios casos que ilustran este principio.3 En una, el propio vicepresidente financiero diseñó y programó un sistema para ayudar a evaluar las oportunidades de inversión a corto plazo. Este sistema funcionó tan bien que pasó a formar parte del proceso de toma de decisiones de la empresa sobre la gestión del efectivo. Sin embargo, cuando el vicepresidente dejó la empresa, se descubrió que el sistema era tan idiosincrásico y estaba tan mal documentado que su sucesor no podía usarlo. En otro caso, un ejecutivo creó un programa para recuperar información de los archivos de personal de la empresa a fin de ayudar a determinar el coste de una propuesta de mejora de las prestaciones a los empleados. Sobre la base de la información proporcionada, se adoptó la prestación. Cuando se descubrió que, debido a un error lógico, el programa había subestimado los costes varios cientos por ciento, hubo que retirar la prestación, una medida que tuvo importantes repercusiones.

En estos casos, como en otros, el hecho de que los desarrolladores aficionados no realizaran un trabajo profesional al probar, controlar y documentar un sistema causó graves problemas. Cuando el impacto del sistema es limitado, es posible que el coste adicional de la participación del personal profesional no esté justificado. Sin embargo, si un sistema tiene un impacto importante, es muy importante hacer bien su trabajo. Esta necesidad implica que los profesionales del sistema de información participen en la creación de prototipos, la selección de paquetes o el enfoque de desarrollo tradicional.

El gerente debe determinar en cada caso: (1) si el sistema tiene un impacto en toda la empresa o si su utilidad se limita a una o dos personas, (2) si el sistema aborda problemas de importancia estratégica y (3) cuál sería el impacto en la empresa de un fallo del sistema.

Estructura

La tercera propiedad es la estructura del sistema propuesto. F. Warren McFarlan define la estructura en este contexto como lo bien que entendemos el problema y su probable solución.4 La estructura es particularmente importante para determinar la idoneidad del enfoque del prototipo. Cuanta menos certeza sobre lo que debe hacer el sistema propuesto, más atractivo será el prototipado debido a su proceso de desarrollo iterativo y participativo.

La literatura del Estado Islámico abunda en casos en los que una estructura baja conduce a un fracaso en el desarrollo. Un ejemplo típico es el caso relatado por John Schmitt y Kenneth Kozar, en el que una agencia de planificación estatal dedicó muchos años de esfuerzo a desarrollar un inútil sistema de apoyo a la planificación.5 Como nadie sabía lo que debía hacer o cómo debía funcionar un sistema de apoyo a la planificación, cualquier cosa que propusieran los consultores del proyecto parecía atractiva. Sin embargo, tras varios años de esfuerzos, se hizo evidente que la falta de un proceso de decisión claro en la agencia hacía que cualquier tipo de apoyo al sistema no tuviera ningún valor. La falta de estructura en este caso provocó un gasto de recursos sin fin.

Para determinar la estructura de un proyecto, los directores deberían preguntarse: ¿Qué tan bien definido está el proceso que debe respaldar este sistema y con qué confianza se pueden especificar de antemano las entradas y salidas implicadas?

Un proyecto con una estructura elevada (por ejemplo, la automatización de una función bien definida, como el procesamiento de pedidos) probablemente se adapte a un software empaquetado o a un enfoque de desarrollo tradicional. Con una estructura baja, la creación de prototipos es más atractiva, ya que puede ayudar a identificar el problema y a resolverlo.

La prueba III resume las relaciones entre las características del proyecto y los métodos de desarrollo de los sistemas. Podemos hacer varias observaciones sobre estas relaciones:

Prueba III Selección de un método de desarrollo

1. Cuando el problema y la solución son comunes a un gran número de empresas, se debe considerar un paquete de solicitud. Especialmente cuando el problema está muy estructurado, a menudo es posible encontrar sistemas redactados de forma profesional y bien documentados listos para usar.

2. Cuando el problema y la solución no son comunes, normalmente se necesita algún tipo de desarrollo personalizado. Si el impacto del sistema se extiende a toda la empresa, los profesionales de TI deberían controlar su desarrollo, ya sea mediante los métodos tradicionales o mediante la creación de prototipos. De esta manera, se pueden hacer cumplir las normas que garantizan el desarrollo de sistemas sólidos, transferibles y eficaces. Si, por otro lado, el impacto es bastante limitado, el desarrollo de usuarios puede liberar a los profesionales del Estado Islámico para otras tareas.

3. Las ventajas de la creación de prototipos son mayores cuando una estructura baja dificulta la definición de las soluciones en una sola pasada del ciclo de desarrollo tradicional. El profesional de TI sigue siendo responsable de la creación del sistema, pero el usuario realiza el verdadero trabajo de diseño, ya que entiende el problema mejor que el profesional de TI.

Romper el molde

Como dijimos al principio de este artículo, ahora es bien conocida la brecha entre los beneficios potenciales y reales del Estado Islámico para una empresa. En algunos casos, este vacío provoca un inconveniente: la necesidad de realizar funciones de forma manual o trabajar de manera menos eficiente. En otros casos, puede afectar al éxito general de la empresa. Aunque existen otras razones para estas deficiencias, el culpable es cada vez más el cuello de botella en el desarrollo de sistemas.

La principal ventaja de los métodos de desarrollo que describimos aquí (implementaciones de software empaquetadas, creación de prototipos y sistemas desarrollados por los usuarios) es que ponen los sistemas en manos de los usuarios más rápidamente al cortocircuitar aspectos del proceso de desarrollo tradicional. Sin embargo, estos métodos no están exentos de riesgos ni garantizan el éxito. Hay situaciones en las que un método es apropiado y otras en las que no. Sugerimos un marco que los directivos puedan utilizar para evaluar la adaptación a su situación particular.

Por último, sugerimos que los altos directivos puedan desempeñar un papel importante a la hora de cerrar la brecha de la TI fomentando el establecimiento y la implementación de nuevas estrategias para el desarrollo de sistemas de aplicaciones basados en ordenadores. Estas decisiones políticas tienen el potencial de reducir drásticamente el tiempo necesario para que los sistemas de información lleguen a manos de los usuarios. A pesar de los beneficios evidentes de los enfoques de desarrollo alternativo en determinadas circunstancias, hemos descubierto que esa orientación por parte de los altos directivos a veces es necesaria para romper moldes cuando el grupo de TI se ve atrapado en el modelo tradicional de desarrollo de sistemas.

1. Robert I. Benjamín, Control del ciclo de desarrollo de los sistemas de información (Nueva York: John Wiley & Sons, 1971).

2. A. Milton Jenkins y J. David Naumann, «La creación de prototipos: el nuevo paradigma para el desarrollo de sistemas», MIS trimestral, Septiembre de 1982, pág. 29.

3. Gordon B. Davis, «Precaución: los sistemas de desarrollo de usuarios pueden ser peligrosos para su organización», Actas de la 17ª conferencia anual de Hawái sobre Ciencia de Sistemas, Enero de 1982.

4. F. Warren McFarlan, «Portfolio Approach to Information Systems», HBR, septiembre-octubre de 1981, pág. 142.

5. John W. Schmitt y Kenneth A. Kozar, «El papel de la dirección en los fracasos del desarrollo de los sistemas de información: un estudio de caso», MIS trimestral, Junio de 1978, pág. 7.