Bases de datos de ordenadores: el futuro es ahora

Ha habido un debate considerable entre los especialistas sobre qué es una base de datos, si es que existe tal cosa; sobre los elementos de información que deben incluirse en ella; sobre las complejidades administrativas que crea el concepto; y sobre el valor real del concepto como principio organizador central de las operaciones de EDP de una empresa. En la medida en que la alta dirección haya escuchado este debate, probablemente se haya vuelto confusa y muy escéptica ante toda la idea. Este artículo demuestra que el concepto es real, viable y beneficioso. También demuestra que la evolución de EDP está llevando a las empresas con importantes operaciones de EDP a adoptar una forma de organización de la información basada en bases de datos. El propósito del autor aquí es aclarar a la alta dirección los datos esenciales sobre la naturaleza de una base de datos, su construcción y administración, de tal manera que los altos directivos puedan entender la idea y guiar a los niveles inferiores de los directivos, especialmente en el departamento de EDP, hacia un estándar de operaciones adecuado a las necesidades de la empresa de información de gestión. Como documentación, el autor utiliza los resultados de una encuesta diseñada para averiguar qué significa el concepto de base de datos en términos estratégicos y operativos en la actualidad.

El 1 de julio, dos series de previsiones del departamento de planificación llegaron al escritorio del vicepresidente de marketing. El primer conjunto preveía las ventas de la línea de productos industriales actual de la empresa para el año que comenzaba en enero siguiente. La segunda serie preveía las ventas durante el mismo período de una nueva línea de productos industriales, similar a la línea establecida de la empresa, que se lanzaría en enero.

La empresa esperaba que las dos líneas se complementaran entre sí, lo que permitiría cubrir en profundidad sus mercados, lo que colocaría a la empresa en una posición competitiva extremadamente sólida. Esto era particularmente importante en este momento; la competencia había hecho incursiones en el territorio tradicional de la empresa y el mayor nivel de ventas que cabía esperar le daría a la empresa los beneficios que tanto necesitaba.

Con mucho gusto, el vicepresidente de marketing observó que las previsiones eran más prometedoras de lo que se había atrevido a esperar. El personal de previsión tenía un historial excelente; no había razón para no tomarse en serio las altas proyecciones. Así que habría que pensar en aumentar la producción de ambas líneas en los próximos meses.

La producción en realidad no fue un gran problema. En las conversaciones preliminares con la industria, quedó bien establecido que la planta y el personal existentes podían esforzarse para producir cantidades mayores con poca antelación con relativamente poco esfuerzo. Las previsiones también daban indicaciones adecuadas sobre el nivel de producción que se necesitaría cada mes durante los nueve meses siguientes.

El inventario, por otro lado, sí que presentaba algún problema. Las ventas de la empresa tenían características regionales distintas; se realizaban en almacenes regionales que la empresa mantenía mediante acuerdos de arrendamiento posterior. Como preparación para la nueva línea de productos, ya se habían tomado algunas medidas para aumentar las instalaciones de almacenamiento regionales de la empresa, pero estas altas previsiones de ventas hicieron que el vicepresidente de marketing se preguntara si la expansión había sido lo suficientemente grande. Le pareció que muchos de los almacenes regionales podrían estar muy reducidos, tanto en espacio físico como en mano de obra. Con estos altos volúmenes proyectados, pensó, la empresa podría estar promocionándose a sí misma justo en un cuello de botella de almacenamiento.

Además, las variaciones regionales en los patrones de venta no se tuvieron plenamente en cuenta al hacer las previsiones, por motivos «técnicos»; esta era la única área «débil» que había accedido a tolerar en las previsiones. Por lo tanto, no tenía claro qué almacenes serían los más afectados y dónde podría haber algún exceso de capacidad en las regiones contiguas.

A continuación, pensó en las agresivas estrategias de marketing y promoción que acababa de aprobar, para ambas líneas de productos, que se llevarían a cabo en varias regiones durante los próximos trimestres. Si fueran tan eficaces como esperaba que fueran, ahí lo haría ser un problema en los almacenes. Quizás podría reducir sus estrategias de marketing y ventas preferidas, pero esta alternativa entraba en conflicto con la necesidad de la empresa de aumentar las ventas lo antes posible.

Definición de un problema

Hizo algunos cálculos sencillos y luego se dirigió a la oficina del director ejecutivo. Tras describir la situación a la luz de las previsiones finales de la planificación, la resumió así: «Si las cosas salen como esperamos, los almacenes de Chicago, como mínimo, tendrán que funcionar a cuatro veces su capacidad durante al menos tres meses. Ese es solo un grupo de almacenes. Y la verdad es que no tenemos el dinero disponible para contratar un espacio exterior adicional».

Discutieron sobre una serie de posibilidades, hicieron algunos cálculos y pensaron en voz alta las diversas consecuencias. Tras una hora de conversación, llegaron a la conclusión de que simplemente tenían que tener una idea mejor del impacto de la nueva estrategia de marketing en las ventas de ambas líneas y también tenían que tener una mejor idea del impacto de las ventas proyectadas en la rotación del inventario y el hacinamiento de los almacenes. Necesitaban, en resumen, unir los tres hilos.

En ese momento, el CEO señaló que las partes del rompecabezas ya estaban en el ordenador:

• La empresa tenía programas de simulación de inventario que se habían desarrollado recientemente para ayudar a ajustar las políticas de inventario. También estaban disponibles los datos reales de varios años sobre la rotación del inventario.

• El departamento de ventas tenía varios programas de previsión diseñados para proporcionar informes de ventas e información de previsiones por región y producto.

• Por motivos de marketing, el personal de previsión había desarrollado un modelo de penetración en el mercado de la nueva línea de productos, basado en las ventas de la línea de productos existente, que pretendía complementar.

Así que los dos hombres fueron a ver a la vicepresidenta de servicios informáticos y le expusieron el problema. Luego preguntaron: «¿Puede conseguirnos una copia impresa que nos diga el impacto que el marketing y las ventas van a tener en los almacenes?»

Su respuesta fue no. Señaló que la empresa no tenía ningún programa para ejecutar una simulación de este tipo. También señaló que, si bien la empresa disponía de la mayoría de los datos que necesitaría una simulación de este tipo, ninguno de los datos estaba fácilmente disponible. Los datos del inventario se habían preparado especialmente para las simulaciones de inventario y habría que recodificarlos por completo antes de poder utilizarlos para un propósito tan radicalmente diferente. Los programas de previsión de ventas sí proporcionaban proyecciones regionales, pero aún no se habían ajustado para adaptarlas a los nuevos sistemas de inventario; aún faltaban algunos meses para esa evolución. Además, los datos de ventas de varios años utilizados por los programas, una vez más, estaban codificados especialmente para los programas de ventas y no podían utilizarse en otros programas sin una reorganización masiva de los datos.

Por último, señaló que su sistema informático no podía gestionar el enorme volumen de datos que necesitaba una simulación que intentaba combinar todos los datos de inventario, ventas y estrategia de mercado necesarios. Como mínimo, se necesitaría más memoria principal para el ordenador.

El CEO se mostró triste: «No me preocupa el tamaño del ordenador. Si necesitamos una memoria más grande, tendremos en nuestras manos una memoria más grande. ¿Cuánto tiempo tardará en limpiar los datos y escribir un programa de simulación que nos dé algunas respuestas?»

«Nueve meses, quizás un año», dijo el director de EDP.

«¿Porque todos nuestros datos están congelados en estos otros programas?» preguntó el CEO.

«Esa es la razón principal», respondió el director de EDP.

«Esa es una gran razón», dijo el CEO y se dirigió hacia la puerta.

«Por supuesto, podríamos haberlo hecho de otra manera», lo llamó el director de EDP. «Pero ahora lo que tenemos que hacer es…»

Pero los dos hombres se habían ido.

¿Cuál es la respuesta?

El problema de esta viñeta no tiene una solución fácil. La dirección pidió una simulación por ordenador que abarcara tres departamentos diferentes y se sintió frustrado sobre todo porque los datos de cada departamento estaban bloqueados en sus propias aplicaciones. Incluso si el tiempo lo hubiera permitido, el coste de recodificar todos los datos para una simulación interdepartamental probablemente habría sido demasiado alto para que la empresa lo asumiera. En otras palabras, los datos de la propia empresa eran un activo congelado, un recurso muy limitado, análogo al dinero que solo podía utilizarse para comprar un tipo de activo.

Las solicitudes de la gerencia para este tipo de procesamiento ad hoc están aumentando. Como consecuencia, las empresas están empezando a darse cuenta de que los datos son un recurso valioso que se debe gestionar como cualquier otro recurso básico.

Lo que el director de EDP quería explicarle al CEO, y lo que el CEO no esperó a oír, es que la empresa podría haber estado gestionando sus datos de tal manera que se hubiera podido cumplir con la solicitud del CEO.

Si la empresa hubiera mantenido todos sus datos legibles por ordenador en un solo grupo o banco (en la llamada «base de datos») y si la empresa hubiera estructurado esta base de datos de modo que se pudiera ejecutar un programa para prácticamente cualquier uso posible desde esta base de datos, habría sido cuestión de pura experiencia y talento para un programador bueno y experimentado inventar un programa que reuniera la información deseada. Además, si la empresa hubiera mantenido una base de datos, sus programadores ya habrían desarrollado la experiencia y la capacidad para escribir un programa de este tipo, con la ayuda de un «lenguaje de base de datos», con una antelación razonable.

La posibilidad de tramitar este tipo de solicitudes ad hoc es la ventaja especial del enfoque de base de datos. También tiene una ventaja más mundana: en una instalación de EDP de cualquier tamaño y complejidad, es factible y mucho más eficiente a largo plazo crear cualquier programa, ya sea grande, pequeño, complejo, rutinario o ad hoc, y para ejecutarlo desde una base de datos en lugar de desde un montón de archivos de datos independientes bloqueados en aplicaciones específicas.

La verdad de esta afirmación bastante contundente se debe al hecho de que el enfoque basado en datos libera al programador de la limitación de trabajar sobre, por debajo, alrededor y a través de las estructuras de archivos de datos separados, un hecho caro e implícito en el enfoque tradicional de las operaciones y la planificación del EDP. Con una base de datos, solo necesita trabajar con una sola estructura, la de la propia base.

Esta función de estructura principal única también facilita la decisión de cómo se pueden obtener e integrar los datos en la base de la manera más eficiente y económica, es decir, facilita el problema de mantenimiento de los datos una vez que se ha creado la base de datos. Teniendo en cuenta los extraordinarios porcentajes de los presupuestos de EDP que las empresas asignan al mantenimiento en la actualidad, normalmente más del 50%%—este beneficio es muy significativo.

Así ha surgido el concepto de base de datos para toda la empresa. Tiene dos aspectos clave:

1. Los datos que utilizan los programas de ordenador se consideran un recurso independiente en sí mismos, independiente de los programas de ordenador.

2. Existe un arte y un enfoque para gestionar y estructurar los datos legibles por ordenador de una empresa en su conjunto, de modo que constituyan un recurso disponible para la organización para una amplia gama de aplicaciones, especialmente de forma ad hoc.

Debido a sus posibles ventajas, el concepto de base de datos ha recibido mucha atención recientemente en la prensa profesional. Lo que espero hacer en este artículo es explicarlo en términos de gestión y presentar los resultados de una encuesta que indiquen cómo se recibe e implementa el concepto en una pequeña muestra de empresas.

Un patrón histórico

Tal como están las cosas, la mayoría de los directivos serían difíciles de gestionar, y uso—sus datos en todo su potencial, por razones que son en gran medida históricas. Debido al rápido crecimiento de la tecnología informática, la gestión de los datos se ha desarrollado de forma desordenada y rezagada a lo largo de los años. Hace muy poco que ha surgido un enfoque general de la gestión de datos y, en consecuencia, las aplicaciones se han desarrollado discretamente unas a partir de otras, de una manera desintegrada y derrochadora. Además, cada aumento de la complejidad y las capacidades de los ordenadores ha traído consigo nuevas generaciones de aplicaciones, pero estas aplicaciones siguen siendo de naturaleza especializada, diseñadas para un uso operativo específico o para una función de personal especializada.

Por lo tanto, la gestión de los datos ha seguido desarrollándose de manera fragmentada y en niveles organizativos bastante bajos, a nivel subdepartamental o de subpersonal.

Hoy en día, los niveles superiores de la dirección buscan información que solo se pueda generar a partir de grupos de toda la empresa debidamente estructurados que incluyan datos de las aplicaciones más restringidas ubicadas más abajo en la jerarquía organizacional. Es decir, la información de gestión actual requiere que una empresa tenga una base de datos que pueda utilizarse, junto con programas de amplia gama, para generar información a una escala más amplia y completa de lo que solían hacer las aplicaciones únicas y aisladas del pasado.

A pesar de las nuevas exigencias, la tradición sigue siendo fuerte; de hecho, apenas ha sido cuestionada. El gráfico I representa la forma tradicional de hacer las cosas: recopilar y codificar datos para programas específicos y, por lo tanto, pegarlos de forma más o menos permanente y exclusiva a esos programas. En retrospectiva, este enfoque tiene tres desventajas importantes.

Anexo I El enfoque tradicional de los programas y los datos

1. Los archivos y registros han tendido a ser redundantes.

Supongamos que la Compañía X originalmente tenía solo un sistema informático (por ejemplo, para cuentas por cobrar) que se presenta en el Anexo I como Programa I. (En este momento, preste atención únicamente al Anexo I. Le explicaré su acompañante, la prueba II, más adelante.)

Anexo II El enfoque basado en datos para los programas y los datos

El programa I tiene tres archivos de datos: A, B y C. El archivo A contiene los registros de los clientes, cada uno compuesto por elementos de datos un y b; un podría ser el nombre del cliente y b su saldo pendiente. Los archivos B y C contienen otros elementos de datos necesarios para el programa de cuentas por cobrar.

Supongamos que ahora la empresa quiere implementar un segundo programa, el Programa II, como se ilustra en el Anexo I, con los archivos D, E y F que contienen elementos a, b, c, d, f, y g. Tenga en cuenta que la empresa ya tiene todos estos elementos, excepto g, archivado para el Programa I. Sin embargo, con toda probabilidad, sus programadores codificaron los archivos A y B (incluidos todos los elementos) a, b, c, y d) expresamente para el Programa I y, por lo tanto, ahora no puede usar A y B intactos para el Programa II. Por lo tanto, los programadores tienen que tomar una decisión:

• Pueden recodificar A y B para que el Programa I o el Programa II puedan utilizar estos archivos. Pero esto significaría reescribir el Programa I para tener en cuenta la recodificación.

• Como alternativa, pueden crear dos «nuevos» archivos, compuestos por datos de A y B, pero codificados para la comodidad especial del Programa II.

En el pasado, cuando se enfrentaba a este tipo de decisiones, un departamento de EDP normalmente se limitaba a crear los dos «nuevos» archivos. Volver a repasar el Programa I normalmente parece demasiado difícil, así que inventar los nuevos archivos parece la salida más fácil. Es— a corto plazo.

Pero a la larga, como muestra la exposición, la empresa X podría encontrarse fácilmente creando más y más archivos cuasiduplicados a medida que añada nuevos programas. Por ejemplo:

• Necesitará dos nuevas versiones del archivo B para los programas II y IV, es decir, los archivos E y K.

• Necesitará tres versiones nuevas del archivo A para los programas II, III y IV, es decir, los archivos D, G y J.

• Necesitará una nueva versión del archivo I para el Programa IV, es decir, el archivo L.

Y así sucesivamente. La redundancia de los datos es obvia. Solo en este pequeño y muy simplificado ejemplo, 7 de cada 12 (58%) de los elementos de datos de los archivos son redundantes.

Al principio, la redundancia no causa muchos problemas. Tan pronto como los datos sean actualizado, sin embargo, es sí causar muchos problemas. En un departamento de EDP de cualquier tamaño, es prácticamente imposible actualizar todos los archivos e informes redundantes de forma sistemática y sincronizada. Tenga en cuenta lo que debe pasar si la empresa X añade un cliente: debe actualizar A, B, D, G y J, y eso solo sería el principio.

Una vez que los archivos, registros e informes comienzan a superponerse y la actualización se convierte en una tarea ardua, los procedimientos de actualización comienzan a perder peso y diferentes partes de la organización comienzan a recibir informes inconsistentes generados a partir de archivos que se encuentran en varios estados de deterioro. En una empresa grande, las inconsistencias entre los informes de ventas a nivel de división y los informes de ventas a nivel de sucursal eran tan extremas que los vendedores empezaron a ser muy elaboradas manual récords de ventas. De hecho, estos dos conjuntos de informes se generaron en gran parte a partir de archivos redundantes que se actualizaban en diferentes momentos.

Estas inconsistencias particulares se debieron a una mera diferencia de organización nivel—es decir, el nivel divisional contra el de sucursal. Los problemas graves de redundancia pueden surgir con mayor facilidad cuando los informes de una función deben combinarse con los informes de otra función. Por ejemplo, no hay absolutamente ningún motivo para esperar que el informe de control de inventario de una empresa coincida con su informe de contabilidad, a menos que las disciplinas de actualización de los archivos de ambas funciones estén sincronizadas entre sí.

Incluso pequeñas variaciones en los datos utilizados en los dos informes funcionales pueden provocar inconsistencias evidentes:

En una gran cadena minorista cuyas aplicaciones se habían desarrollado de la manera tradicional, las necesidades de la empresa obligaron a la dirección a solicitar la integración de varios programas y sistemas funcionales diferentes. Con un gran esfuerzo, el trabajo estaba hecho. Sin embargo, se hizo de tal manera que se crearon muchos archivos casi duplicados y se parchearon muchos programas independientes, pero esencialmente similares. De repente, la empresa se encontró gastando 90% de sus horas de trabajo de programación solo para mantener los programas ejecutándose en concierto y los archivos actualizados.

Como mínimo, la redundancia genera confusión y gastos para cualquier operación importante. Quizás su peor característica sea que cuanto más tiempo siga una empresa el patrón tradicional y siga añadiendo nuevos programas y archivos de datos redundantes, codificados específica y exclusivamente para esos programas, mayor será la tarea a la que se enfrentará cuando finalmente reúna todos sus datos en un solo grupo, tan estructurado y codificado que se puedan ejecutar nuevos programas sin necesidad de recopilar o recodificar datos exhaustivamente.

2. El enfoque tradicional socava o aborta los avances de la tecnología informática.

La memoria del ordenador alguna vez fue mucho más cara de lo que es hoy en día. Un importante fabricante de ordenadores prevé ahora que la tecnología de semiconductores reducirá el coste actual de la memoria principal en muchos órdenes de magnitud en un futuro no muy remoto. Incluso ahora, los costes del almacenamiento de acceso aleatorio se han reducido considerablemente gracias al desarrollo de dispositivos de disco extremadamente grandes. Además, el nuevo software ha introducido nuevas dimensiones en la informática, dimensiones que hacen posibles los tipos de sistemas de información más avanzados. Por ejemplo, las técnicas de memoria virtual permiten explorar, de forma económica, las relaciones entre los elementos de un conjunto de datos relativamente enorme, no todos los cuales tienen por qué estar presentes de forma literal.

En un principio, el coste relativamente alto del almacenamiento en línea («memoria», en términos generales) era el factor principal que inducía a las empresas a delimitar el alcance de la programación y, por lo tanto, la cantidad de datos necesarios durante una ejecución determinada. En efecto, esto reforzó la práctica de crear y mantener archivos separados para cada aplicación de la cartera de la empresa; las empresas solían almacenar no más datos de los necesarios para la ejecución en cuestión.

Sin embargo, hoy en día, muchas empresas que han seguido la ruta tradicional, pero que han adquirido sistemas de almacenamiento en línea actualizados, descubren que tienen la capacidad de mantener vivas cantidades relativamente enormes de datos en el sistema. Pero sus datos siguen organizados y codificados según líneas informáticas de primera generación, es decir, mediante programas específicos. Desde un punto de vista racional, esto es tan incómodo, caro y absurdo como mantener los registros contables modernos totalmente en números romanos.

3. El enfoque tradicional obstruye la creciente demanda de la alta dirección de aplicaciones que requieren una base de datos.

El motivo de este lamentable estado está encerrado en la historia del ordenador. Una breve reseña de la evolución de las aplicaciones informáticas es la siguiente:

• El ordenador se utilizó por primera vez para sustituir las funciones manuales existentes, principalmente las de la función de contabilidad.

• Luego vino la integración de los sistemas basados en ordenadores dentro y entre las áreas funcionales; fue la etapa multifuncional.

• Ahora se están desarrollando sistemas interfuncionales e interniveles para la dirección media y media alta o, dicho de otra manera, la dirección exige ahora los beneficios de las innovaciones informáticas.

En esta tercera etapa, las redundancias e ineficiencias que se derivan del enfoque tradicional de la gestión de los datos se hacen tan evidentes y extensas que las aplicaciones solo pueden ser adecuadas si se desarrollan de tal manera que los programas específicos estén separados de los datos. Es decir, todos los datos de una empresa deben estar estructurados en una base de datos flexible.

Un concepto moderno

Como muestra el gráfico II, el concepto de base de datos estructura la actividad de EDP de tal manera que todos los datos legibles por ordenador de una empresa se fusionan en un solo grupo, que se utiliza para ejecutar programas de rutina y programas escritos en respuesta a solicitudes ad hoc. Tenga en cuenta que no aparece ningún archivo en esta exposición: la base de elementos de datos constituye el archivo general de la empresa y los archivos específicos son, en general, innecesarios. Tenga en cuenta también que aquí se presentan dos sistemas de software adicionales que no estaban en la prueba I:

El sistema de interfaz de bases de datos—esto permite a un programador de bases de datos especializado organizar y estructurar los elementos de datos de manera que se minimice o elimine la redundancia y se optimicen los costes económicos del almacenamiento y la accesibilidad de los datos.

El sistema de interfaz para una programación especial—esto incluye un lenguaje de programación de alto nivel diseñado especialmente para manipular los elementos de datos contenidos en la base de datos, resolver problemas y generar informes. Para escribir un programa ad hoc, el programador trabaja sucesivamente a través de la interfaz para aplicaciones especiales y el sistema de interfaz general hasta la propia base de datos.

Al comparar las exposiciones I y II, se puede ver un inmenso contraste entre el concepto tradicional y el concepto de base de datos, tanto teórico como práctico. Si la empresa descrita en la viñeta con la que abrí este artículo hubiera tenido una base de datos funcional, el CEO se habría limitado a pedirle a su director de EDP que pusiera a un programador a trabajar en un programa ad hoc. No habría surgido ninguna cuestión de disponibilidad de los datos; la única variable en el caso habría sido el tiempo necesario para escribir el programa, y puede que este tiempo solo haya sido cuestión de horas.

Se puede apreciar mejor el contraste si esperamos con ansias la cuarta etapa de desarrollo de las aplicaciones informáticas, aplicaciones que los altos ejecutivos utilizarán en la gestión corporativa. Lo más probable es que esta evolución surja de la unión del concepto de base de datos y el concepto de modelo corporativo; y aunque esta unión no es más que un destello en los ojos del especialista, la empresa que ahora ajuste sus políticas de EDP al concepto de base de datos disfrutará de una ventaja muy significativa sobre la empresa que sigue los patrones tradicionales hasta que llegue el día del juicio final. (Solo cómo una empresa debería realizar este ajuste es un problema que consideraré más adelante.)

Dado que gran parte de la tecnología informática necesaria para implementar el concepto de base de datos existe y el resto de la tecnología se está desarrollando rápidamente, ahora se pueden presentar argumentos sólidos a favor de adoptar el enfoque de base de datos. Sin embargo, en términos operativos, el concepto sigue siendo novedoso. ¿Hasta qué punto se utiliza? ¿Cuáles son las cuestiones y los problemas que implica su implementación? ¿Con qué estrategias puede trabajar una empresa para crear una base de datos? ¿Y qué beneficios podemos esperar, siendo realistas, de ello?

Un estudio de entrevistas

Para responder a estas preguntas, realicé una entrevista sistemática a los directores de procesamiento de datos de diez empresas de seis sectores diferentes. Las preguntas permitían responder sin restricciones y, por lo tanto, la información que proporcionaron estos gerentes (resumida en el anexo III) no es tan clara como cabría desear. Sin embargo, es informativo. Ofrece una perspectiva operativa de los directores de EDP sobre los siguientes temas:

Prueba III Etapas evolutivas de la base de datos

• Impresiones actuales sobre lo que debe ser y hacer una base de datos.

• Enfoques para estructurar y organizar una base de datos.

• Estrategias para crear un sistema de bases de datos.

• La asignación de la responsabilidad por el alcance y el contenido de la base, es decir, la administración de la base de datos.

• La función del administrador de la base de datos.

• Acceso y seguridad.

• Problemas organizativos y técnicos relacionados con el concepto de base de datos.

Las opiniones expresadas sobre estos temas variaban considerablemente entre los directores de EDP a los que entrevisté. En general, las opiniones de un directivo determinado reflejaban la fase particular a la que había llegado su empresa en la progresión evolutiva hacia el pleno uso del concepto de base de datos.

Para mayor comodidad del lector, he organizado el material de la Prueba III en secuencia evolutiva. Una empresa de fabricación, la empresa 1, en el extremo izquierdo, apenas ha empezado a entender y utilizar el concepto; en la empresa 10, en el extremo derecho, se encuentra un ejemplo bastante sofisticado de una base de datos en funcionamiento.

Permítame hablar ahora de los temas de la lista, uno por uno, prestando un poco de atención a la forma en que la base de datos se configura en las distintas etapas de su madurez.

Naturaleza de la base de datos

En primer lugar, he encontrado cierta confusión acerca de lo que significa «base de datos». Mi pregunta abierta: «¿Cuál es la base de datos de su empresa?» por lo general, primero ponía una expresión de perplejidad en los rostros de los directivos y, luego, solicitaba aclaraciones. Respondí que quería una declaración sobre cómo ven las bases de datos de sus empresas, si es que las ven.

Las respuestas variaron por todas partes. Algunos directivos incluyeron todos los datos legibles por ordenador de su empresa. Otros definieron la base de forma más restringida, por ejemplo, incluyendo solo los archivos de disco de acceso aleatorio que se utilizan para la elaboración de informes y análisis de rutina.

El hilo conductor de las respuestas era «legible por ordenador». Como todos los entrevistados eran directores de procesamiento de datos, este hilo conductor no es sorprendente. Pero, obviamente, la gran mayoría de los datos de una organización no se leen por ordenador; se guardan en los archivadores y en la mente de la dirección.

Aunque cada vez se ponen más datos en un formato legible por ordenador, a medida que la tecnología mejora y hace que las aplicaciones informáticas más sofisticadas sean factibles y económicas, gran parte de la literatura sobre bases de datos supone falsamente que las empresas ya han traducido todos los datos necesarios para estas aplicaciones a términos legibles por máquina. Esto simplemente no ha sucedido todavía; de hecho, la mayoría de las empresas ni siquiera han empezado a recopilar los datos necesarios para estas aplicaciones, en formato legible por máquina o de otro modo.

En general, cuanto más avanzado sea el uso por parte de una empresa del enfoque de bases de datos, menos ingenua y realista será la definición del gerente de lo que debe contener la base (por ejemplo, «archivos de acceso aleatorio compartidos que se utilizan para programas de producción [periódicos] y solicitudes de gestión ad hoc». Esta definición refleja las dos características clave de la base de datos: (a) compartir datos entre programas y (b) estructurar los datos para poder atender las solicitudes de gestión ad hoc. Como muestra el gráfico III, las empresas más avanzadas conciben sus bases de datos desde esta perspectiva.

Un director de procesamiento de datos articuló especialmente bien el criterio de capacidad de respuesta a las solicitudes de gestión ad hoc. Dijo que su empresa adoptará plenamente el enfoque de las bases de datos cuando incorpore la tecnología que le permita responder a cualquier solicitud razonable de la dirección de informes o análisis en un día y sin degradar indebidamente su procesamiento continuo de datos. Describió además una solicitud razonable como aquella que se basa en datos legibles por ordenador existentes.

Estructura e integración

Las empresas 1, 2 y 5 del anexo III consideraron que su base de datos estaba estructurada según el criterio único de las solicitudes individuales, de la manera totalmente tradicional. Las empresas 1 y 2 tenían un grado mínimo de integración multifuncional, es decir, compartían datos entre aplicaciones funcionales como la fabricación y la contabilidad.

La empresa 5, en el centro del espectro, tenía un alto grado de integración multifuncional, como muestra el gráfico III. En mi entrevista con el director de EDP, me hicieron creer que la integración multifuncional era mínima. Sin embargo, las conversaciones posteriores con su analista principal de sistemas apuntaron a una alta integración. Con más investigación, descubrí que este hombre se había encargado de diseñar archivos para facilitar el uso compartido entre programas. Participó muy activamente en las sociedades profesionales de la EDP y expresó su firme opinión de que este era el enfoque «correcto».

Aun así, estas tres empresas compartían datos un mínimo entre los niveles de gestión. De hecho, se desarrollaron muy pocos programas de gestión en ninguna de las tres empresas.

Además de la empresa 5, otras cuatro empresas (4, 7, 9 y 10) indicaron un alto grado de integración multifuncional de sus bases de datos y también tenían aplicaciones informáticas muy bien desarrolladas en los aspectos operativos de sus negocios. Pero debo señalar una diferencia significativa entre las empresas 4 y 7 y las empresas 9 y 10:

• Las empresas de 4 y 7 años tenían aplicaciones bien desarrolladas para las actividades operativas generales: contabilidad, distribución y control de inventario. Sin embargo, estas dos empresas no habían integrado sus bases de datos con aplicaciones de gestión media y media alta, como la previsión de ventas y la planificación de la producción. Los directores de EDP de ambas compañías eran directivos bastante decididos, hombres que se apegaban a lo último a menos que se les indujera a hacer lo contrario; y al parecer sus altos directivos nunca habían insistido en el tema de la integración entre niveles.

• Encontré una situación muy diferente en las empresas 9 y 10. De hecho, las operaciones comerciales estaban bien respaldadas por aplicaciones informáticas; los aspectos operativos relacionados con los flujos de productos estaban respaldados por aplicaciones informáticas muy desarrolladas (por ejemplo, el pedido de materias primas, la distribución de las ventas, la contabilidad de las cuentas por pagar y por cobrar y el control del inventario).

Sin embargo, lo que es más importante, bajo una fuerte dirección de la alta dirección, los directores de EDP de las empresas 9 y 10 utilizaron criterios de tareas clave para integrar sus bases de datos. La empresa 9 consideraba que la distribución y la contabilidad eficiente de la facturación, el movimiento de los productos y los precios eran tareas clave, mientras que la empresa 10 consideraba que la fabricación y la planificación eran las claves de la rentabilidad general de la empresa. Además, ambas empresas habían integrado sus bases de datos para la elaboración de informes y análisis de la gestión con sus bases de datos operativas.

En ambas empresas se pueden ver los inicios de la integración entre niveles; ambas han sido clasificadas como «medianas» según este parámetro en el gráfico III. Al fin y al cabo, la integración entre niveles debe aparecer pronto, cuando la planificación se considere un enfoque clave para el desarrollo de la empresa y las bases de datos, como en la empresa 10, y donde las decisiones de precios se consideren un enfoque clave, como en la empresa 9.

Sin este ímpetu de la alta dirección para centrar la integración en las tareas clave, las empresas 9 y 10 nunca podrían haber alcanzado la fase avanzada del uso de los ordenadores y la gestión de los recursos de datos que han alcanzado. La elección de la dirección de esta estrategia en particular y su insistencia en ella fueron aún más afortunadas, teniendo en cuenta la popularidad de otras alternativas mucho menos viables.

Tres estrategias

Por lo tanto, una característica principal de la estrategia de tareas clave es la capacidad de responder a las solicitudes ad hoc de informes y análisis de la dirección. Una empresa puede seguir un par de estrategias más para satisfacer esas solicitudes sin recurrir al concepto de base de datos, pero no es probable que las alternativas tengan mucho éxito.

Estas son las estrategias que puedo identificar: la estrategia de fuerza bruta, la estrategia de aprovechar y la estrategia de bases de datos y tareas clave. La estrategia de cada empresa entrevistada se especifica en el anexo III y en el anexo IV he intentado definir las tres esquemáticamente.

Anexo IV Tres estrategias para responder a las solicitudes ad hoc

Supongamos que, de repente, a un director de EDP se le asigna una tarea como la que describí al principio de este artículo, es decir, una solicitud ad hoc de información de gestión que abarque todas las funciones y niveles de la empresa. Estas son las posibles formas en las que puede hacer el trabajo.

Por la fuerza bruta:

El director puede empezar de cero, recopilando todos los datos necesarios, codificándolos, escribiendo programas especiales y adquiriendo capacidad de hardware, si es necesario. Es probable que el esfuerzo que exige este enfoque sea enorme, el gasto prohibitivo y la demanda de tiempo totalmente imposible. En consecuencia, este enfoque se sigue muy raramente.

Bien, el anexo III indicaría que las empresas 1, 2 y 3 atienden las solicitudes ad hoc de la dirección únicamente mediante este enfoque. El director de una de esas empresas incluso declaró enfáticamente que este enfoque es más barato que cualquier otro y notablemente más barato que el enfoque de bases de datos, del que hablaré ahora.

Sin embargo, admitió que prácticamente nunca había recibido una solicitud de este tipo de informes ad hoc. No es de extrañar; una solicitud así generaría disrupción total en su departamento, y sospecho que la alta dirección de la empresa sabe este hecho.

Las otras dos empresas de este grupo, por igual, prácticamente no tienen experiencia ni éxito alguno en la atención de este tipo de solicitudes. Las afirmaciones sobre las virtudes de la fuerza bruta deben tomarse con cautela.

A cuestas:

Con esta estrategia, el director intenta «llevar a cabo el proyecto especial» con las capacidades más o menos existentes. Lo que hace es eliminar los datos de los archivos existentes, estructurarlos en un grupo de datos especial, aumentar este grupo con nuevos datos según sea necesario, ampliar los programas antiguos y escribir otros nuevos, y aumentar la capacidad del hardware, si es necesario. Este enfoque tiene dos desventajas importantes: requiere la construcción de un conjunto de datos totalmente redundante y, si bien consume menos dinero y tiempo que la técnica de la fuerza bruta, el dinero y el tiempo siguen siendo sustanciales.

La técnica a cuestas es algo más común que la técnica de fuerza bruta. Las empresas 4, 6, 7 y 8 lo han utilizado, como muestra el Anexo III. Pero como en todos los casos este enfoque representaba un esfuerzo especial para obtener un tipo especial de información, sus usos se caracterizaban por una cierta estrechez y superficialidad. Los posibles proyectos estaban limitados por la cantidad y la naturaleza de los datos existentes; y las habilidades de programación desarrolladas en estas empresas no eran realmente adecuadas para crear programas adaptados a las necesidades específicas de las empresas. De hecho, los sistemas de gestión de datos disponibles en el mercado se utilizaban generalmente para estructurar los nuevos grupos de datos y generar los programas que producían los informes para la gestión.

Mediante una estrategia de base de datos y tareas clave:

Ya he descrito cómo un director de EDP abordaría el problema de una solicitud de información de la gerencia; tal vez el lector quiera echar un vistazo a la organización que se muestra en el anexo II. El diagrama de respuesta de las bases de datos y las tareas clave del gráfico IV es muy similar a la organización general de las bases de datos, pero contiene algunos términos y opciones nuevos. Para explicar lo que significan, permítame volver a hablar sobre las empresas 9 y 10, que más han evolucionado hacia un modo de funcionamiento basado en bases de datos completas y lo han utilizado con más éxito.

Ambas empresas, 9 y 10, tenían bases de datos altamente integradas, como he comentado antes. Estas bases estaban estructuradas según las tareas clave de las empresas y estaban lo suficientemente desarrolladas como para que las empresas pudieran utilizar paquetes de software de bases de datos comerciales. Utilizaron un paquete de software para la organización de los datos, la definición de registros y archivos para admitir varias aplicaciones (el Sistema de Interfaz General del Anexo II) y un paquete de software diferente para producir informes y análisis de gestión ad hoc (el Sistema de Interfaz para Aplicaciones Especiales del Anexo II).

Ambos directores de procesamiento de datos estaban bastante satisfechos con el software comercial que utilizaban. Sin embargo, ambos comentaron que ni siquiera el software de base de datos más sofisticado disponible en el mercado incorporaba los métodos de estructura de datos más avanzados. Estos métodos coordinan las estructuras de datos teóricas (por ejemplo, cosas que se parecen a inmensos árboles de decisiones) con las restricciones de acceso de los dispositivos de almacenamiento físico, como los discos magnéticos giratorios. Baste decir que la organización de los datos es extremadamente compleja y técnica.

De hecho, es tan complejo que uno se ve prácticamente obligado a utilizar software comercial. Una de las directoras de procesamiento de datos declaró que la tecnología de estructuras es tan compleja hoy en día que no podría apoyar un esfuerzo interno para desarrollar el software. El otro director inicialmente tenía la intención de desarrollar su propio software de bases de datos, pero, tras una investigación preliminar de los costes y los problemas, decidió adquirir un paquete disponible en el mercado.

Sin embargo, esta complejidad se debe, en última instancia, a la naturaleza de las tareas clave para las que la alta dirección quiere que se utilice la base de datos. Si la alta dirección se centra en las tareas clave que abarcan todos los datos de la empresa y requieren una integración vertical y horizontal muy amplia de los informes y los análisis, la tarea de organizar la base de datos es más difícil que cuando las tareas clave abarcan solo una parte de los datos y requieren menos que la integración completa de todas las funciones.

Además, mis entrevistas me llevaron a una conclusión que puede ser directamente útil para los altos directivos y los altos directivos, ya que se centran en el tema de la organización de las bases de datos: cuanto más relacionados estén los usos funcionales de los datos, más fácil será diseñar una base de datos integrada y no redundante. Por ejemplo, la empresa 10, que estructuraba su base de datos en función de las tareas clave de planificación y fabricación, parecía tener menos problemas en el diseño de la base de datos que la empresa 9, que estructuraba su base de datos en función de las tareas clave de la contabilidad y la distribución.

La estructura de planificación y fabricación utilizada por la empresa 10 se centraba en la integración vertical de la base de datos. Sus datos de fabricación estaban organizados a nivel de operaciones o transacciones; muchos de los datos de planificación se obtenían resumiendo los datos de fabricación. La base de datos se diseñó para adaptarse explícitamente a las necesidades de información de los diferentes niveles de administración. Además, había una fuerte relación entre los objetivos de la organización y el uso del recurso de datos a través de un modelo de planificación basado en ordenador. El modelo proporcionaba directrices continuas para determinar los datos importantes que se recopilarían a nivel de fabricación.

Por otro lado, la estructura de contabilidad y distribución utilizada por la Empresa 9 requería la integración de los datos de dos áreas funcionales a nivel operativo. Aunque la estructura reflejaba el flujo de información, no reconocía explícitamente las necesidades de información de la gerencia media. Por lo tanto, no había una fuente continua de directrices y puntos de referencia para determinar qué datos y qué análisis eran importantes, como la había para la empresa 10.

Por lo tanto, en general, la estrategia de base de datos/tareas clave es más eficaz que la fuerza bruta y la combinación, ya que fuerza la integración interfuncional e interniveles de una manera que se adapta a las necesidades de la alta dirección. Por su parte, una vez que haya decidido que esta estrategia es la correcta, la alta dirección debe analizar detenidamente las que considera sus tareas clave y asegurarse de que ha decidido las que (a) tienen sentido para la empresa y (b) el personal de EDP responsable de estructurar y mantener la base de datos las entiende claramente.

Permítame volver un momento al diagrama de tareas clave de la prueba IV. Este diagrama tiene en cuenta el hecho de que alguna aplicación, ad hoc o no, puede estar alejada de las tareas clave de la empresa. Si esas solicitudes son realmente obligatorias y si son en serio alejada de los principios organizativos utilizados para estructurar la base de datos, una empresa siempre puede recurrir a archivos y programas especiales, de la manera tradicional. Sin embargo, parece bastante claro que una empresa que quiere seguir el concepto de base de datos/tareas clave y, al mismo tiempo, sucumbe a la tentación de crear una aplicación «especial» o tangencial cada vez que necesita un nuevo programa puede darse cuenta de que no hace ninguna de las dos cosas de forma eficaz.

Administración de bases de datos

Además de tomar buenas decisiones sobre la estructura y la organización de los datos, las buenas decisiones sobre la información que se incluirá en la base de datos de la empresa son fundamentales para el uso exitoso del concepto. La suma total de datos debe ser útil, pero no ingobernablemente grande, o el sistema se derrumbará por su propio peso.

En las diez empresas que estudié, los analistas de sistemas responsables de las distintas áreas de usuario iniciaron todas las solicitudes para desarrollar nuevos conjuntos de datos o cambiar los antiguos. Sin embargo, la tramitación de las solicitudes varió considerablemente:

• Las empresas 1 y 2, que aún se encuentran en las primeras etapas del desarrollo de las bases de datos, permitían a los analistas de sistemas individuales decidir qué archivos se desarrollarían y cómo se estructurarían para las diferentes aplicaciones. Estas empresas aún no habían empezado a considerar los datos de forma independiente de los programas para los que se recopilaban y codificaban.

• Las empresas de 4 y 5 años acababan de darse cuenta de la necesidad de separar los datos de las aplicaciones y de reconocer una «función de recursos de datos», pero el analista de sistemas seguía siendo el principal responsable de la toma de decisiones.

• Las empresas de 3, 6 y 7 años asignaron las decisiones sobre qué datos debían mantenerse a una autoridad superior y más centralizada que los analistas de sistemas, es decir, al director de procesamiento de datos o al comité directivo de EDP.

• Las empresas de 8, 9 y 10 años habían avanzado a una etapa en la que contaban con administradores formales de bases de datos que desempeñaban un papel central en la supervisión del contenido y los estándares de la base de datos. En estas empresas, se estudió la solicitud de datos para una aplicación concreta desde varios puntos de vista: necesidad, redundancia, coste/beneficio, métodos de aprovisionamiento, planificación del procesamiento electrónico de datos, etc. Estos análisis se habían vuelto lo suficientemente especializados como para dar lugar a otro puesto administrativo formal: analista de bases de datos.

La función del administrador

El anexo III muestra que los administradores de bases de datos existen realmente en tres empresas (8, 9 y 10) y que las empresas 3, 4 y 7 tienen previsto cubrir ese puesto en un futuro próximo (dentro de dos a cinco años).

Sin embargo, en ninguno de estos casos la empresa ha definido completamente las responsabilidades o la autoridad exactas del administrador. Las empresas parecen estar de acuerdo en que el administrador debe concentrar sus energías en las áreas de planificación y diseño de la base de datos; y parecen ver al administrador como un punto focal útil desde el que se puede ver todo el tema de los datos informáticos como un todo integrado. Con demasiada frecuencia, las empresas se han despertado para encontrar una plétora de repositorios de datos fracturados dispersos por toda la organización.

Debo señalar también que los directivos de EDP con formación puramente técnica suelen querer incluir todos los datos posibles (los archivos personales del presidente, las tasas de tráfico, etc.) en la base de datos, mientras que los directores con cierta experiencia ejecutiva en áreas más amplias tienden a adoptar una visión más realista de los elementos que deberían incluirse en la biblioteca de datos de trabajo de la empresa. He defendido en otros lugares la sensatez de inyectar un punto de vista gerencial más amplio en la toma de decisiones del departamento de EDP.1

Las conversaciones de la entrevista sobre las responsabilidades del administrador de la base de datos plantearon una interesante dicotomía. En los comentarios sobre cuáles son las responsabilidades debería be, se hablaba de los datos como un recurso corporativo. En los comentarios sobre cuáles son las responsabilidades reales son, los datos se veían simplemente como elementos legibles por ordenador.

Sin embargo, esta dicotomía no debería sorprender. La función de recursos de datos se está extrayendo de la función de gestión general. La especialización en los datos asociados a los ordenadores está justificada en este momento; existen las condiciones para la especialización.

Sin embargo, las actividades de gestión de los datos como recurso corporativo aún no se han desarrollado hasta el punto de que se justifique la especialización. La alta dirección del departamento de EDP todavía puede llevar a cabo estas actividades mejor que un especialista.2 Ya he señalado la responsabilidad de la alta dirección de dar orientación sobre las tareas clave. Además, dado que el administrador de la base de datos representa una fase de desarrollo avanzada y relativamente poco frecuente en la función de los recursos de datos, corresponde a la alta dirección supervisar de cerca esta área.

Una nota sobre el acceso:

El gráfico III muestra que los grupos que tuvieron acceso directo o indirecto a la base de datos son programadores y analistas. Ninguna de las empresas proporcionó ni a los gerentes ni a sus analistas directo acceso a la base de datos. Las empresas 8, 9 y 10 proporcionaron un indirecto acceso para los analistas a través de un sistema de gestión de datos. Aquí, el analista comunicó una solicitud a un programador que, a su vez, utilizó el sistema de gestión de datos para obtener una respuesta rápida.

En todas las demás empresas que estudié, el analista y el director se vieron obligados a realizar el proceso de satisfacer sus necesidades a través de un programador. Este proceso cambiará y se simplificará considerablemente a medida que mejore la calidad del software de interfaz.

Cuestiones organizativas y técnicas

Los directores de EDP expresaron su preocupación por los siguientes problemas organizativos importantes relacionados con la base de datos:

• Adquirir personal que pueda encargarse de sus aspectos técnicos.

• Financiar y desarrollar sistemas de cobro adecuados que lo respalden.

• Establecer y hacer cumplir los estándares de toda la empresa.

• Utilizar el recurso de datos para sacar el máximo provecho.

Los principales problemas técnicos asociados por los que expresaron su preocupación fueron los siguientes:

• Convertir datos en un formulario de base de datos.

• Proporcionar el software adecuado para las interfaces.

• Diseñar una base de datos que permita una capacidad de respuesta ad hoc sin degradar el procesamiento normal del ordenador.

• Aumentar la fiabilidad y la capacidad de reconstruir los datos perdidos.

En general, se consideró que tanto los problemas organizativos como los técnicos eran de tal magnitud que no se justificó tomar medidas enérgicas para implementar plenamente el concepto de base de datos en ese momento. El consenso fue que el concepto es sólido, pero hay que hacer mucho más desde el punto de vista administrativo antes de que pueda llevarse a la práctica de manera efectiva.

¿Qué debe hacer la dirección?

El uso del concepto de base de datos es el siguiente hito natural en la evolución de las aplicaciones de EDP. Adopta la especialización de las funciones de EDP; permite a la administración una flexibilidad real para satisfacer sus necesidades de información; y permite a las empresas ver y utilizar sus datos como un recurso real. Sin embargo, se recomienda cautela y paciencia a la hora de seguir con el concepto. ¿Qué deben hacer los directivos para hacer frente a esta situación de tira y afloja?

1. Tómese la idea en serio.

La alta dirección debe dar instrucciones al director de EDP identificando las tareas clave de la empresa y estableciendo prioridades para mejorar la capacidad de información. Quizás el factor más importante que permitió a las empresas 9 y 10 salir de un tratamiento parroquial de los datos fue la orientación de la alta dirección y su insistencia en explotar los datos en beneficio de la empresa.

2. Configure una función de administración de datos.

La cuestión es cuándo configurar una función de administración de datos, más que si se va a tener esa función. En última instancia, se necesitará un administrador para implementar el concepto de base de datos, de todos modos. Para las empresas que actualmente no tienen ese puesto, se necesita una estructura administrativa para formular un plan de implementación de la base de datos, regular el ritmo de implementación y establecer estándares, controles y procedimientos de acceso a las bases de datos. Como mínimo, ahora se debería contratar a un especialista en bases de datos que guíe en la toma de decisiones al director y al comité directivo del EDP. Esta persona también puede orientarlo a la hora de evaluar y seleccionar el software adecuado.

3. Incorpore la tecnología de bases de datos al sistema informático.

La tecnología de hardware y la tecnología de software para las bases de datos han madurado hasta el punto de que el concepto de base de datos puede ser factible y rentable para muchas organizaciones. Si bien la empresa no se verá perjudicada notablemente a corto plazo si ignora la tecnología de bases de datos, sí lo hará a largo plazo.

Además, el concepto de base de datos no se puede implementar de la noche a la mañana. Si una empresa empieza a planificar y actuar ahora, puede asimilar incluso las mejoras tecnológicas drásticas en sus sistemas actuales de forma lenta, cómoda y ordenada.

Para incorporar la tecnología que permita las operaciones de las bases de datos, la organización debe identificar sus principales sistemas informáticos y reestructurarlos (a) para eliminar la redundancia y (b) para facilitar su uso por parte de los niveles superiores de la dirección. Por el momento, es probable que las empresas deban adquirir software comercial para estructurar los datos y responder a las solicitudes de la dirección de análisis e informes ad hoc.

4. Piense en los datos como un recurso.

A largo plazo, la dirección debería empezar a pensar en los datos como un recurso básico. Debería aceptar esta idea como una consecuencia natural de la especialización funcional de la función de dirección general. Dado que el concepto de recurso de datos está estrechamente relacionado con una tecnología informática que avanza rápidamente, la gerencia debería esperar que el movimiento hacia actividades especializadas de gestión de datos avance a un ritmo más rápido que, por ejemplo, las especializaciones en la función de recursos humanos. Mi encuesta a las diez empresas indica que la aparición del administrador de bases de datos es un acontecimiento clave en la especialización.

5. Estime la posición de su propia empresa en la secuencia evolutiva.

Si descubre que su empresa aún se encuentra en una fase rudimentaria de desarrollo, planifique el desarrollo. Si su empresa está bastante avanzada, siga adelante con un poco más de fuerza. Lo único que puede perder es el despido.

1. Consulte mi artículo, «La difícil situación del director de EDP», HBR de mayo a junio de 1973, pág. 143.

2. John Dearden, «MIS es un espejismo», HBR de enero a febrero de 1972, pág. 90.