El nuevo significado de calidad en la era de la información

Sorprende lo groseros que siguen siendo muchos directivos con respecto al año 2000. Los problemas legales por sí solos asociados con el problema del cambio de fecha son tan grandes y complejos que algunas empresas podrían enfrentarse a daños que ascienden a miles de millones de dólares. La Comisión de Bolsa y Valores, reconociendo la posibilidad de litigios a largo plazo relacionados con el año 2000, exige ahora que las empresas revelen cualquier responsabilidad en sus declaraciones de 10 000 y puede hacer que los directores sean responsables personalmente por las quiebras del año 2000. Debido a los costes legales y de otro tipo, algunos observadores predicen que el problema del año 2000 provocará que el PIB de los Estados Unidos se contraiga hasta un 0,3%% en 2000. Y la dimensión global de los negocios no hace más que agravar la situación: a medida que las empresas estadounidenses dependen más de los proveedores internacionales, se exponen a un mayor riesgo milenario a corto plazo.

Sin embargo, lo más importante del año 2000 no es su coste directo, por muy grave que sea, sino la advertencia que envía sobre cómo las aplicaciones de software de una empresa se están convirtiendo rápidamente en su sistema nervioso central. Es una advertencia que los directivos solo pueden ignorar por su cuenta y riesgo. El software determina cada vez más la naturaleza de las experiencias que los clientes, empleados, socios e inversores tienen con una empresa, sus productos y servicios y sus operaciones. Por lo tanto, las experiencias positivas mediadas por el software son fundamentales para retener a los clientes, motivar a los empleados, colaborar eficazmente con los socios y comunicarse con los inversores. Las intranets y el comercio electrónico han subido la apuesta; estas aplicaciones basadas en Internet están teniendo un impacto considerable en todas las empresas, ya vendan ordenadores, flores o coches.

Sin embargo, en la mayoría de las organizaciones, los directores ejecutivos y los altos directivos llegan tarde a abordar los problemas de software. Como resultado, muchas empresas han acumulado una cantidad difícil de manejar de sistemas de software personalizados e incompatibles diseñados para gestionar las mismas aplicaciones. Por ejemplo, el CIO de General Motors estima que la organización ha instalado más de 7 800 sistemas de software distintos en todo el mundo, y más de 1 800 de esos sistemas están dedicados a aplicaciones financieras. El simple hecho de que tantos sistemas realicen las mismas tareas puede resultar problemático. Cuando los sistemas no son compatibles, transferir y compartir datos, y mucho menos intercambiar conocimientos, se hace casi imposible.

Pero GM y las empresas tradicionales como esta no están solas. Las empresas de TI pueden enfrentarse al mismo problema, especialmente si han crecido rápidamente mediante una serie de adquisiciones. Por ejemplo, la empresa de redes Cisco Systems adquirió 28 empresas entre 1993 y 1998 y tuvo que crear una unidad especial para garantizar que los grupos adquiridos cumplían con los estándares de configuración de Cisco para el software, las comunicaciones y el hardware.

Solucionar estos problemas implica costes directos muy reales, como descubrió Cisco después de gastar alrededor de$ 100 millones para estandarizar su infraestructura de información y luego gastar otro$ 100 millones para crear una interfaz de usuario basada en la web. Pero los costes directos palidecen al lado de los costes de oportunidad. Pensemos en un banco moderno típico. En cada transacción que realiza, el banco obtiene información sobre sus clientes. En principio, un banco debería poder hacer un seguimiento de sus clientes a lo largo de sus vidas y debería poder comercializar los productos adecuados: por ejemplo, una tarjeta de crédito a los 18 años, un préstamo para un coche a los 23 y una hipoteca a los 30. Pero la mayoría de los bancos ni siquiera pueden vender productos de forma cruzada (por ejemplo, vender una hipoteca a un cliente de una cuenta corriente) y mucho menos ofrecer servicios integrales. Las aplicaciones y bases de datos de sus infraestructuras de tecnología de la información se crearon para cada línea de negocio individual y, a menudo, son incompatibles. Del mismo modo, una gran empresa japonesa de electrónica de consumo descubrió que los datos de los consumidores que recopila nunca se utilizan porque la empresa no tiene el software instalado para entablar un diálogo continuo con sus clientes. Como comentó un directivo de la empresa: «Recopilamos todos estos datos y los guardamos en una caja de zapatos para no volver a verlos nunca más».

Por supuesto, la ventaja competitiva depende de la naturaleza y la sofisticación no solo del software de aplicación, sino también del resto de la infraestructura de información de la empresa: sus fuentes de datos, bases de datos, sistemas operativos y hardware. Wal-Mart ofrece un ejemplo ideal de cómo una infraestructura de información integrada puede afectar con éxito a las decisiones empresariales. Por ejemplo, la integración del software de cadena de suministro del minorista con sus aplicaciones de minería y almacenamiento de datos garantiza la entrega puntual y eficiente de los productos a las tiendas. Las aplicaciones se basan en la información almacenada en las enormes bases de datos comerciales de Wal-Mart en el back-end (50 terabytes según el último recuento). Y Wal-Mart no es el único que cosecha los beneficios de una infraestructura de tecnología de la información altamente evolucionada. Dell, Eastman Chemicals, Amazon.com, y todos The Gap utilizan las tecnologías de la información para cambiar las reglas del juego. En nuestro trabajo, vemos una relación directa entre las infraestructuras de TI de las empresas (en particular, la calidad del software de sus aplicaciones) y la calidad y la rapidez de las decisiones de gestión.

Una de las principales razones por las que los directivos prestan muy poca atención al software es porque a menudo no tienen un marco que les ayude a tomar decisiones al respecto. Para empezar, los altos directivos no comparten una visión de lo que determina la calidad del software. Los conceptos generales de calidad han evolucionado y, poco a poco, se han vuelto más sofisticados. En la década de 1970, surgió una visión de la calidad centrada en el producto y en la conformidad; sugería que los productos y servicios cumplieran con especificaciones claras, como el tamaño, el peso, el color, el acabado, la duración de la batería o el tiempo medio entre fallos. La idea es que los consumidores puedan esperar que el producto funcione de forma fiable. Pero a medida que el sector de servicios crecía, muchas empresas tuvieron que desarrollar un modelo de calidad diferente, uno en el que la calidad se juzgaba en función de la capacidad de la empresa de cambiar para cumplir con las expectativas de una base de clientes diversa. Más recientemente, algunas empresas de alta tecnología han promovido un tercer enfoque en el que la calidad de un producto se juzga según su capacidad de apoyar la innovación mediante la experimentación. (La barra lateral «El concepto de calidad en evolución» describe con más detalle los diferentes enfoques de la calidad). Hoy en día, se necesita una nueva visión de la calidad, que sintetice los enfoques de conformidad, servicio e innovación, para evaluar la infraestructura de TI y el software de una organización.

El concepto de calidad en evolución

Nuestra comprensión de la calidad en los negocios hoy en día todavía se basa en gran medida en un enfoque que ha evolucionado a partir del sector de la fabricación durante las

…

La calidad del software en una infraestructura de información se puede evaluar centrándose en el usuario, las tecnologías de las que se extrae el software y para qué se diseñó el software, también conocido como dominio . El dominio de un producto se puede definir como el conjunto general de conocimientos sobre las necesidades y expectativas del usuario con respecto al producto. Tiene en cuenta el perfil del usuario y la funcionalidad del producto. Cada producto tiene un dominio; las aplicaciones de software son especiales porque las funciones y las expectativas de una pieza de software pueden variar considerablemente. Dada la importancia de los dominios en el software, empezaremos por identificar algunas características básicas de los dominios. Luego veremos cómo los usuarios del software y la tecnología dan forma a estas características. Por último, revisaremos los riesgos de calidad específicos del uso y el diseño del software. Nuestro objetivo es ayudar a los gerentes a determinar qué software de aplicaciones incluir en su cartera y los estándares de rendimiento que pueden esperar de él.

Entendiendo los dominios

Es bastante fácil entender los dominios de la mayoría de los productos fabricados. Tenga en cuenta su bicicleta de uso diario. En el mundo desarrollado, las bicicletas se utilizan principalmente para actividades de ocio o para hacer ejercicio. Sin embargo, en los países emergentes, como China e India, las bicicletas se utilizan principalmente como medio de transporte y como transporte de carga ligero. Si bien hay algunas variaciones en la forma en que se utiliza el producto en las diferentes partes del mundo, las características físicas y estructurales de la bicicleta limitan lo que se puede hacer con ella. Por lo tanto, tiene sentido aplicar el punto de vista de la conformidad al establecer los estándares de calidad para la fabricación de una bicicleta.

Por el contrario, los dominios del software pueden resultar complicados porque las necesidades y expectativas de los usuarios varían considerablemente. Por ejemplo, es bastante difícil saber con precisión cómo utilizarán las personas un paquete de software como Microsoft Excel o PowerPoint, en parte porque el uso del producto depende del nivel de habilidad del consumidor. Como esta información es menos precisa, el dominio del software es difícil de definir. Puede que cada vez dependa más de factores como la interacción entre el cliente y el productor, así como de otras tecnologías utilizadas.

En lo que respecta al software, los dominios evolucionan rápidamente. Tomemos como ejemplo WinZip, un producto diseñado originalmente para proporcionar una compresión y transmisión de datos eficientes. Como la transmisión de datos requiere seguridad, hubo que añadir muchas otras funciones al software, como las funciones de cifrado y contraseña, y la posibilidad de gestionar archivos de gran tamaño en varios disquetes. Como resultado, el producto final que finalmente dominó el mercado se alejó mucho de las especificaciones y funciones originales.

El dominio de una aplicación de software tiene tres características básicas: especificidad, estabilidad y capacidad de evolución. Cuanto más específico sea el dominio, más fácil será para los gerentes desarrollar medidas de rendimiento. En este caso, es apropiado un enfoque de la calidad que haga hincapié en el cumplimiento de las especificaciones.

Los dominios de software más específicos se encuentran en el área de las aplicaciones de contabilidad, donde se pueden especificar con claridad las relaciones entre las transacciones contables. En principio, no hay ninguna razón por la que un programa básico de contabilidad general cometa un error. Eso no quiere decir que los dominios del software de contabilidad sean simples. Si se añaden al programa de contabilidad general las normas fiscales de todos los países, los tipos de cambio, las normas de amortización del fondo de comercio, etc., la solicitud puede resultar muy complicada. Pero por muy complejos que sean esos cálculos, nuestros conocimientos sobre la aplicación pueden estar bastante desarrollados y, por lo tanto, el dominio puede ser relativamente específico.

El segundo aspecto de un dominio de software, su estabilidad, permite a los gerentes aclarar el dominio de un producto. Supongamos que una empresa que está acostumbrada a vender productos y componentes independientes intenta desarrollar una aplicación de gestión de pedidos para vender paquetes personalizados. Como tiene poca experiencia en la agrupación de varios componentes, el precio de un producto de este tipo y el desarrollo de servicios de soporte, es posible que a la empresa le resulte difícil diseñar la nueva aplicación. Eso se complica más cuando, por ejemplo, los componentes se subcontratan a proveedores de todo el mundo. Pero con el tiempo, la experiencia en la venta del producto permitirá a la empresa tener una visión más precisa de las expectativas de los clientes. La estabilidad del dominio permite a los administradores aumentar la especificidad del dominio en función del conocimiento acumulado.

Pero el cambiante panorama competitivo a veces va en contra de eso. Tenga en cuenta las relaciones con los principales proveedores de una empresa y el software de aplicación que media en estas interfaces. Las relaciones con los proveedores solían ser bastante estables. Pero cada vez más, la base de la creación de valor en estas relaciones cambia drásticamente. Cada vez se intercambia más información y cada parte depende cada vez más de los sistemas de información de la otra. El volumen y la frecuencia de las interacciones con un proveedor pueden afectar a la naturaleza de las relaciones entre la empresa y el proveedor y a las características del software necesario para gestionar esas interfaces. Por eso, el software necesario para gestionar las relaciones con los proveedores de artículos de producción masiva, como televisores en color, es diferente del software necesario para gestionar las relaciones entre el proveedor y el contratista principal en una gran central eléctrica. En los dominios inestables, no tiene sentido adoptar una expectativa de calidad del 100%% conformidad para el software, porque nunca se puede cumplir. Más bien, los directivos deberían centrarse en la rapidez con la que el sistema puede solucionar los problemas y adaptarse a los cambios.

Lo que lleva a la tercera característica del dominio del software: su capacidad de evolución o la flexibilidad con la que los productos pueden cambiar para reflejar la acumulación de nuevos conocimientos sobre las necesidades y expectativas de los usuarios. Para muchos productos y servicios, los dominios evolucionan constantemente. Eso es sin duda cierto en el caso del comercio electrónico y las aplicaciones orientadas a las bases de datos, en las que se desarrollan nuevos dominios constantemente. En los mercados en los que cada cliente es su propio segmento, se requiere una cantidad significativa de experimentación antes de que los gerentes puedan especificar, aunque sea parcialmente, cómo deben hacer los negocios. En esas situaciones, el descubrimiento de un dominio y sus parámetros de rendimiento es un proceso continuo. ¿Cuál es, por ejemplo, una interfaz de aplicación ideal para una tienda electrónica en Internet? ¿Cuáles son las consultas correctas para configurar en una base de datos que recopila información de las transacciones electrónicas a través de la Web?

La conclusión es que los sistemas de información de una empresa pueden tener que cambiar con frecuencia a medida que los gerentes aprenden y se adaptan a los dominios de las aplicaciones en evolución. Obviamente, eso es cierto para las empresas emergentes de Internet. Pero también es cierto para las empresas establecidas; como han descubierto GM y Ford, vender coches en la Web puede revelar muchas oportunidades y problemas que no se identificaron del todo cuando iniciaron el proceso. Los fabricantes de automóviles han tenido que reconocer el impacto que Internet tiene en sus relaciones con los usuarios finales.

Determinar las características del dominio

La naturaleza de un dominio es crucial para determinar el enfoque de la calidad. En consecuencia, surge la pregunta: ¿Qué fuerzas influyen en el dominio? En general, dos controladores dan forma a las características de un dominio. En primer lugar, está el diálogo que tiene lugar entre el software de aplicación y sus usuarios finales, que cambia a medida que los clientes se hacen más heterogéneos y las empresas y los clientes aprenden unos de otros. En segundo lugar, hay cambios en las tecnologías básicas que determinan la naturaleza de la infraestructura de la información y las aplicaciones, el software y las bases de datos que necesita una empresa.

Diálogo con el cliente.

En todas las empresas, los directivos mantienen un diálogo implícito con sus clientes. Los clientes hacen comentarios sobre la calidad, los precios, el servicio, el diseño, los canales, etc. Al aceptar o rechazar los productos y servicios de una empresa, los clientes proporcionan información valiosa a los directivos. Pero en el sistema empresarial tradicional, los gerentes no tienen acceso directo a esta información porque los concesionarios y distribuidores actúan como intermediarios. Así que es Wal-Mart, no Procter & Gamble, quien gestiona la interfaz con los clientes y recopila la información. Sin embargo, estos patrones históricos están cambiando. Internet, por ejemplo, ahora permite a empresas como P&G establecer un acceso directo a los clientes. Y a medida que esas empresas lo hagan, tendrán que enfrentarse a una nueva realidad: el hecho de que, en cada vez más sectores, los clientes son muy diversos. No siempre fue así. En 1980, compañías como AT&T, en un entorno regulado, podían ofrecer un conjunto de servicios estándar a un precio predeterminado a todos los consumidores del país. Hoy en día, AT&T tiene que hacer frente a una variación significativa en la sofisticación de los clientes, así como al voraz deseo de los consumidores por nuevos servicios. En consecuencia, el número de servicios de AT&T cambia cada semana. Los precios de los nuevos servicios varían según la sofisticación y el poder de negociación del consumidor.

La diversidad de clientes aporta una dimensión completamente nueva al debate sobre la calidad en las aplicaciones de software. La mayoría de las personas que piensan en la calidad suponen implícitamente que todos los clientes son iguales. Si eso fuera cierto, el dominio podría ser específico y, por lo tanto, una perspectiva de calidad de conformidad sería adecuada para las aplicaciones de software que proporcionan una interfaz a los clientes. Pero en el mundo real, los clientes son diferentes. Es difícil precisar las especificaciones de las aplicaciones que se adapten a las necesidades de una base de clientes heterogénea. Pensemos en los motores de búsqueda de Internet. Se ajustan a las especificaciones de diseño necesarias para el proceso de búsqueda, pero los clientes suelen quedarse con información inadecuada o inapropiada. Del mismo modo, algunas aplicaciones de escaparate de Internet pueden ser fiables, pero la realidad es que alrededor de la mitad de los posibles clientes abortan el proceso de compra en Internet porque les resulta demasiado difícil entender y utilizar las funciones de la interfaz. Los estándares de calidad inadecuados se han traducido en pérdidas de ventas. El punto es que una aplicación de software de calidad debe hacer algo más que cumplir con las especificaciones técnicas de velocidad, por ejemplo: también debe ser fácil y emocionante de usar. Los desarrolladores de productos deben tener en cuenta los diferentes niveles de sofisticación de los clientes.

Una aplicación de software debe hacer algo más que cumplir con las especificaciones técnicas de velocidad, por ejemplo; también debe ser fácil y atractiva de usar.

El acceso directo a los clientes y la heterogeneidad de los consumidores sugieren que tiene que haber un proceso de aprendizaje bidireccional. Para que los dominios sean más específicos, los gerentes deben conocer las expectativas y capacidades de sus clientes. Del mismo modo, los clientes deben conocer los productos y las funciones que ofrece una empresa. Adaptar este proceso bidireccional tiene implicaciones claras para lo que los gerentes necesitarán de las infraestructuras de información de sus empresas. Las bases de datos, por ejemplo, deben poder gestionar la nueva información sobre los consumidores y sus preferencias que se genera en cada transacción.

Por su parte, los clientes aprenden a través de una amplia variedad de mecanismos. En general, los usuarios finales tienden a experimentar en Internet. Puede que necesiten formación para utilizar aplicaciones como las herramientas automatizadas de análisis de ventas. La gente suele adquirir esta formación imitando a sus compañeros y aprendiendo de ellos, por eso es importante que una aplicación tenga una base instalada grande. Todas estas interacciones dan forma a las características de un dominio. Hay dos elementos que vale la pena destacar: en primer lugar, a medida que los gerentes y los clientes se conocen, el dominio del producto se hace más estable y específico. En segundo lugar, la solicitud debe evolucionar con el proceso de aprendizaje bidireccional.

Cambios en la tecnología.

La tecnología quizás haya desempeñado el papel más importante a la hora de obligar a los directivos a reevaluar la calidad. Esto se debe en gran parte a que los avances de la tecnología afectan profundamente a la forma en que se desarrolla y utiliza el software de aplicaciones. Es imposible hablar de todas las formas en que el cambio tecnológico ha afectado a la calidad, pero destacan cuatro dimensiones fundamentales:

• Longevidad de una plataforma tecnológica. Una plataforma es la tecnología principal sobre la que se crean varias aplicaciones. El sistema operativo Windows de Microsoft, por ejemplo, es una plataforma en la que se pueden crear una amplia variedad de aplicaciones. Java de Sun Microsystems se perfila como una plataforma de la competencia. La longevidad de las plataformas es fundamental para la calidad del software de una infraestructura de TI, ya que cuanto más tiempo exista una plataforma, más familiarizados estarán los clientes con ella y más aplicaciones se crearán en torno a ella. La base de poder de Microsoft, por ejemplo, es la aceptación generalizada de Windows por parte del público y la cantidad de aplicaciones que contiene. Hay algunas desventajas: la longevidad de una plataforma y su base instalada pueden reducir la capacidad de innovación del sector. Lo importante de las plataformas es que los estándares de calidad de las aplicaciones desarrolladas para una plataforma establecida son diferentes de los desarrollados para plataformas nuevas o en evolución. Las nuevas plataformas tienen que hacer hincapié en la educación de los clientes para aumentar la velocidad de aprendizaje. Pero a medida que los clientes se familiaricen con esas plataformas, surgirán estándares comúnmente aceptados. A largo plazo, eso significa utilizar la visión de conformidad de la calidad para juzgar el software.

• Es hora de lanzarlo. Una gran empresa tiene que presentar aplicaciones y plataformas a sus empleados todo el tiempo. Eso puede llevar mucho tiempo. Instalar un sistema de planificación de recursos empresariales puede tardar entre dos y tres años, por ejemplo, y el proceso puede requerir educación y formación en todos los niveles. Es más, no se instala un sistema complejo sin algunos problemas técnicos. Eso significa que la calidad del software debe juzgarse, al menos en parte, por la facilidad con la que se puede enseñar y ayudar a los usuarios cuando el sistema falla.

• Migración de sistemas antiguos. Para la mayoría de las empresas establecidas, el verdadero desafío es la migración de un sistema antiguo a uno nuevo. A pesar de que intenten reducir la cantidad de sistemas heredados en las aplicaciones de misión crítica, muchas grandes empresas seguirán teniendo que vivir con varios sistemas. Una importante empresa mundial estimó que se necesitarían tres años para reducir sus 1400 sistemas antiguos a solo 70 sistemas aprobados por la empresa. Mantener las interfaces de usuario mientras los sistemas antiguos y nuevos funcionan en varias partes de la organización es un desafío importante. El problema se agrava cuando una empresa intenta combinar un modelo de negocio tradicional con uno nuevo. Esa es una de las razones por las que Merrill Lynch, con su amplio sistema de distribución basado en corredores, ha tardado tanto en introducir las operaciones en línea. Pero empresas como E*Trade, que casi no tienen sistemas antiguos, pueden actuar con mucha más rapidez para satisfacer las necesidades y expectativas de los clientes en línea.

• Tecnologías en evolución. Por definición, las tecnologías evolucionan. La demanda de funciones multimedia está aumentando para aplicaciones como las teleconferencias, las herramientas de colaboración a distancia y las páginas web fáciles de usar. Los activos de audio, imagen y vídeo se están convirtiendo en un componente importante de las bases de datos y la infraestructura de información de una empresa. Pero las tecnologías necesarias para crear, almacenar y recuperar audio y vídeo no hacen más que evolucionar. Incluyen tecnologías de compresión de datos, transmisión de vídeo, registro de vídeo y tecnologías de bases de datos de imágenes. La rápida evolución de las tecnologías sugiere que la experimentación temprana es una parte fundamental del desarrollo de nuevas aplicaciones. Es difícil, si no temerario, comprometerse prematuramente con una plataforma tecnológica. Esa incertidumbre y el ritmo de la evolución de la tecnología provocan una pérdida inevitable en la forma en que se desarrollan e implementan las aplicaciones. El cambio tecnológico, junto con los poderes disruptivos de la desregulación y la globalización, están facilitando la aparición de nuevas formas de competencia. Eso, a su vez, afecta a la forma en que juzgamos la calidad. La competencia basada en Internet, por ejemplo, cambia el significado de los precios. Las subastas se están convirtiendo en la base para fijar los precios de los productos en línea, ya estén a la venta libros, billetes de avión o habitaciones de hotel. Los requisitos de infraestructura de información y software de aplicación de un hotel o una aerolínea para hacer frente a una estrategia de precios orientada a las subastas son muy diferentes de los requisitos de un régimen de precios fijos.

Riesgos del software

A medida que las empresas siguen ampliando el papel de la tecnología de la información, se hace fundamental revisar el potencial de riesgo colectivo de la infraestructura de la información. Tradicionalmente, los riesgos del software se han equiparado a las incertidumbres en cuanto a los costes y las fechas de lanzamiento de los sistemas que se están desarrollando. En consecuencia, los enfoques de gestión de proyectos (y el proceso de desarrollo de software, la formación y las prácticas de recursos humanos asociados a ellos) se consideraron la mejor manera de controlar esas incertidumbres. Esos enfoques siguen siendo importantes, pero los gerentes deben reconocer los riesgos inherentes al dominio de una aplicación. En particular, los productos y sistemas diseñados para fomentar la innovación y el desarrollo de nuevos modelos de negocio conllevan un alto riesgo. El software se está convirtiendo en una misión fundamental para la mayoría de las empresas. Puede haber graves consecuencias comerciales si el sistema de gestión de la cadena de suministro de un minorista no funciona durante la temporada de rebajas navideñas o si una empresa de comercio electrónico tiene problemas con su software de aplicación durante las horas pico de negociación. El aumento de los riesgos asociados a las aplicaciones de misión crítica justifica un nuevo nivel de preocupación por el acceso a los varios sistemas; los procesos de incorporación de cambios y copias de seguridad de los sistemas; y la protección contra los piratas informáticos, los virus y otros peligros externos. El nivel de seguridad creado en torno a las bases de datos y el software de aplicaciones debe supervisarse cuidadosamente.

Sin embargo, el proceso de reducir el riesgo en la infraestructura de la información puede crear tensiones en la organización de TI. La comunidad de software tiene un fuerte deseo de escribir software que tenga tantos «detalles» como sea posible para contrarrestar la necesidad de ser específico del dominio. Experimentar con software de última generación ha sido una parte integral del progreso que hemos logrado en la infraestructura de la información, y los usuarios del software tienen una mayor tolerancia a los defectos que los consumidores comunes con la mayoría de los productos fabricados. Pero eso ya no es aceptable para las solicitudes que se han convertido en misiones críticas. A medida que los departamentos de TI buscan aplicaciones de software con niveles bajos de especificidad de dominio, también impulsan esas aplicaciones hacia niveles de calidad más bajos, según lo medido en función del cumplimiento de las especificaciones. La tendencia natural es acabar con una colección de aplicaciones experimentales. Sin embargo, una cartera de aplicaciones sesgada de esta manera puede aumentar el riesgo de la empresa.

La tendencia natural de un departamento de TI es acabar con una colección de aplicaciones experimentales. Sin embargo, una cartera de software sesgada de esta manera puede aumentar el riesgo de la empresa.

Otro riesgo más es que la mayoría de las organizaciones de TI se configuraron originalmente para gestionar una infraestructura de información diseñada en torno a un mainframe central. Pero ahora estas organizaciones de TI han sido testigos de una transición a infraestructuras de información descentralizadas, como las arquitecturas cliente-servidor, que tienen interfaces con las intranets e Internet. Estas infraestructuras también utilizan programas con más funciones que son independientes de los sistemas subyacentes, las plataformas de software y hardware. La gestión de estos sistemas exige un conjunto de capacidades organizativas muy diferentes a las de la mayoría de los departamentos de TI.

La sociología de los gerentes funcionales también conlleva riesgos. Los directores de marketing y operaciones buscan constantemente formas de mejorar su competitividad. Como resultado, exigen al departamento de TI que desarrolle e implemente nuevas aplicaciones más rápido. Las organizaciones de TI están bajo una presión constante para sacar los sistemas más rápido y trabajar en dominios nuevos y emergentes. De hecho, la presión de los plazos en los proyectos de software es una de las principales causas de la mala calidad. Un estudio reciente del Instituto de Ingeniería de Software del Carnegie Mellon sobre la adopción de prácticas de ingeniería de software citó esta cita de un director de software: «Prefiero equivocarme que hacerlo tarde. Siempre podemos arreglarlo más tarde».

Establecer expectativas de calidad

Una vez que los gerentes hayan identificado las características de los dominios de aplicación de sus redes y los factores que influyen en ellos, pueden establecer las expectativas de calidad adecuadas. Deben empezar por dar forma y reducir las fuentes básicas de variación en las características del dominio. El primer paso es aumentar la sofisticación de los usuarios de la empresa mediante la formación. A medida que los empleados se familiaricen con la forma en que las aplicaciones de software procesan la información, se reducirán significativamente los problemas de calidad. En segundo lugar, los gerentes deben insistir en que sus principales proveedores utilicen sistemas de software compatibles para minimizar los problemas con las interfaces. En tercer lugar, los gerentes deben evaluar los paquetes y sistemas de software estandarizados, como los sistemas ERP, que intentan dividir los sistemas empresariales en módulos predefinidos en áreas como las operaciones, las finanzas, las ventas y los recursos humanos. Estos sistemas permiten la consolidación de varios formatos de datos y procedimientos utilizados en una empresa. Pero si bien los sistemas pueden aumentar la especificidad del dominio, también pueden reducir la capacidad de la empresa de diferenciarse. (Consulte la barra lateral «Las aplicaciones empaquetadas pueden no ser la respuesta») Por último, los gerentes pueden reducir la variación en el uso del software en el diseño de la interfaz de usuario; por ejemplo, basándose en menús e íconos predeterminados como forma de proporcionar un acceso fácil y común a las aplicaciones.

Las aplicaciones empaquetadas pueden no ser la respuesta

En muchas empresas plagadas de varios sistemas de software incompatibles, los directores de información y los altos directivos han recurrido, frustrados, a sistemas empaquetados

…

Por supuesto, a pesar de los esfuerzos de los directivos por controlarlo, la variación en las características de los dominios entre las aplicaciones de software persistirá. Sin embargo, los directivos pueden limitar los riesgos que conlleva la variación haciendo declaraciones explícitas para aclarar las expectativas en las dos áreas siguientes:

Nivel de conocimientos de usuario y desarrollador.

Para que las infraestructuras de información sean sólidas, los conocimientos sobre las aplicaciones y sus dominios deben estar claramente articulados en toda la empresa. Los desarrolladores y usuarios de software deben compartir sus conocimientos en la medida de lo posible.

Claridad en los parámetros de rendimiento.

Otra medida de la solidez de una aplicación es la forma en que gestiona las desviaciones de la norma. Un requisito previo para lograr un alto nivel de calidad es contar con métricas claramente articuladas sobre el rendimiento del software en diferentes condiciones. La claridad de los parámetros de rendimiento elimina las dudas sobre las expectativas de calidad.

La cartera de infraestructuras

Es importante que los directivos reconozcan que las decisiones de calidad que toman no forman parte de una decisión de lo uno o lo otro. Debido a la gran variación en las características de los dominios, así como en los factores que influyen en ellos, una empresa puede tener la oportunidad de desarrollar una cartera de aplicaciones que refleje las tres categorías tradicionales de calidad que hemos descrito. En primer lugar, están los sistemas y aplicaciones que deberían estar orientados principalmente a la conformidad, ya que sus dominios son estables y específicos. Luego vienen los sistemas y aplicaciones cuyos dominios son dinámicos y cuyos clientes tienen habilidades y expectativas diferentes. En este caso, se debe aplicar una visión de la calidad orientada al servicio y se hará hincapié en el apoyo y el aprendizaje. Por último, están los sistemas y aplicaciones cuyos dominios están evolucionando; en este último caso, la calidad debe consistir en facilitar la innovación y la experimentación. Al analizar sus carteras de solicitudes de esta manera, los altos directivos pueden obtener conocimientos significativos no solo sobre sus activos técnicos y los estándares de calidad necesarios para juzgarlos, sino también sobre la capacidad de la organización para respaldar diversas aplicaciones. Este enfoque de cartera de calidad no tiene por qué limitarse a la infraestructura de información de la empresa. De hecho, a menudo se puede extender a toda la gama de productos y servicios de la organización (consulte la barra lateral «Enfoques convergentes de la calidad»).

Enfoques convergentes de la calidad

En este artículo hemos argumentado que se necesita una nueva visión de la calidad para evaluar la infraestructura de TI de una organización. Sin embargo, la perspectiva de calidad

…

Pero hay tensión en el centro de esta cartera, que se puede describir mejor en la exposición «Dinámica de la cartera de aplicaciones». La realidad competitiva y la transformación de las empresas están obligando a las empresas a experimentar más y a crear nuevos modelos de negocio. Eso lleva a aumentar los niveles requeridos de capacidad de evolución y experimentación en los dominios de los productos. Por lo tanto, la adaptación y la innovación se están convirtiendo en elementos clave para juzgar la calidad. Al mismo tiempo, la naturaleza fundamental de muchas de las aplicaciones hace que los administradores busquen la especificidad del dominio y, por lo tanto, eviten fallos en el sistema. Los gerentes se preocupan cada vez más por reducir el riesgo asegurándose de que los productos cumplen con las especificaciones. Por ambas consideraciones, la cartera de aplicaciones de la infraestructura de TI de las empresas en tiempos turbulentos se encuentra en un estado de pérdida constante. Los directivos deben aprender a controlar este ritmo de cambio y a responder a él. A medida que las características del dominio de una aplicación pasan de una varianza alta (experimental) a una varianza baja (conformidad), los gerentes deben asegurarse de reevaluar el enfoque de calidad aplicado a esa aplicación de software. En particular, deben ser sensibles a la hora de controlar el número de aplicaciones experimentales de su cartera en cualquier momento.

Dinámica de la cartera de aplicaciones

Además, antes de la adopción a gran escala de una aplicación, se deben realizar lanzamientos de prueba cuidadosamente diseñados para recopilar información sobre sus posibles efectos en el negocio. Una importante empresa multinacional del mundo impuso una nueva solicitud a su fuerza de ventas antes de que los empleados estuvieran preparados. La fuerza de ventas era un grupo heterogéneo y no compartía las mismas necesidades de información. Tampoco querían que todos los pasos del proceso de venta se automatizaran y estandarizaran. Una prueba habría alertado a la alta dirección sobre las diferentes necesidades de los miembros individuales de la fuerza de ventas, evitando así los problemas que se presentaban.

Es fundamental que las decisiones sobre los cambios en la cartera de aplicaciones no se dejen únicamente en manos del CIO y del departamento de tecnología de la información. Es posible que el personal de TI desconozca los gerentes de primera línea sobre los dominios reales y potenciales de las aplicaciones de software de una empresa. Por eso es crucial que los altos directivos de primera línea combinen su experiencia en el campo con los conocimientos técnicos que aporta el departamento de TI. Solo así podrá toda la empresa desarrollar una comprensión clara de las fuentes y la calidad del conocimiento de una empresa, así como comprender las tecnologías disponibles. Por supuesto, no hay nada nuevo en la necesidad de implicar a la alta dirección en las conversaciones sobre la calidad; los altos directivos han formado parte integral de las iniciativas de calidad de fabricación más exitosas. Pero la idea se olvida a menudo en el desarrollo de software.

En todos los negocios, desde un negocio que avanza relativamente lento, como la fabricación de cemento, hasta empresas que cambian rápidamente, como los servicios financieros, la infraestructura de la información se ha vuelto fundamental. De hecho, algunos negocios, como la negociación de acciones en línea, simplemente no pueden existir sin una infraestructura de información de alta calidad. A medida que nos adentramos en el nuevo milenio, podemos seguir el ejemplo de Charles Dickens y describir el entorno competitivo como una representación de los mejores y los peores momentos. Las turbulencias crean grandes oportunidades, pero también representan grandes riesgos para quienes no cambian. En un entorno así, las organizaciones deben aprender a reaccionar con rapidez y a tomar decisiones de forma descentralizada. Una infraestructura de información de alta calidad es la base de esta capacidad.