Antecedentes Históricos

Contenidos:

  1. Introducción
  2. Un poco de Historia
  3. Aplicaciones Típicas
  4. Cobol e IBM
  5. Metodología
  6. Conclusión


Introducción

Como se indicó en la definición, los Sistemas de Información son requeridos para poder dar apoyo al proceso de toma de decisiones de las organizaciones. Desde esta perspectiva debe ser absolutamente claro que toda organización requiere de Sistemas de Información, y los requiere durante toda su existencia... Lo único que va a cambiar en el tiempo, es la forma en que se implementarán estos sistemas.

Por supuesto, estamos hablando de incorporación tecnológica, no se debe olvidar que muchos de los temas que se hablarán en esta sección, no son registrados en nuestro pais (de hecho, muchos de ellos no tienen sentido en otro lugar que no sea USA).

[Contenidos] [Índice General]


Un poco de Historia

Al analizar la llegada de la informática a las empresas, es bueno considerar dos ámbitos importantes, por una parte está la evolución de las teorías de la administración y en el otro frente de batalla, la llegada de la computación a las empresas.

Breve y simplificada historia de la administración

Sin pretender hacer un análisis exhaustivo de las teorías de administración (materia propia de otros ramos), es necesario observar algunos hitos importantes que han influído en el acercamiento al término: "informática" y su importante relación con las organizaciones.

Es fácil imaginar que en las primeras empresas, aquellas llevadas a cabo por nuestros ancestros prehistóricos, simplemente se lanzaban en pos de un objetivo (posiblemente una pieza de cacería que les diera de comer) de la misma manera que funcionan las manadas de animales salvajes: todos al ataque en forma instintiva. En esos muy primitivos tiempos, el éxito o fracaso de las empresas se medían directamente según la sobrevivencia o muerte de la tribu.

Con los primeros atisbos de inteligencia, ellos deben haber descubierto que era una muy buena idea seleccionar a los mejores cazadores y enviarlos a ellos a cazar, mientras que los miembros restantes de la tribu se dedicaban a otras labores. Se descubrió entonces que era necesario tomar algunas decisiones (¿cuánto cazar?; ¿dónde hacerlo?) y que para ello se necesitaba información (a cuántos debemos alimentar, dónde está la tribu); sin embargo, en una tribu de tamaño reducido, era relativamente fácil poder manejar esos datos. Al igual que con los ancestros menos iluminados, la medición del éxito o fracaso en la gestión tribal, se hacía en función de la sobrevivencia.

Un importante problema surgió cuando la tribu alcanzó un tamaño tal, que ya no era tan claro, para quienes tomaban las decisiones, cuántos eran los miembros, a quiénes se les dio de comer (y quiénes faltan). En ese momento, la necesidad, actuó como madre de la inventiva y generó los medios necesarios para poder mantener actualizada esta información. Desde los "nudos" incáicos hasta los papiros egipcios, cumplieron la misma función. La idea era contar y si se llevaba bien la cuenta, entonces se tenia cierta certeza respecto del éxito de la empresa que se emprendiera... Desde cuidar ovejas hasta construir pirámides o imperios. Dependiendo de la empresa, se necesitaría de más o menos "contadores" que asegurarán que todo estaba bien.

Esto debe haber funcionado bien por varios siglos, hasta que las empresas crecieron tanto que ya no bastaba con los medios antes indicados. La segunda guerra mundial marcó el inicio de la era de las empresas multinacionales (los "aliados" son la primera gran empresa multinacional), donde la distribución de los recursos -la mayoría de las veces escasos- a distintas partes del mundo, era la clave fundamental para presumir el éxito o fracaso de la misión. En este estado de las cosas, fue necesario sistematizar a fondo el proceso de control de recursos y con ello se definieron una serie de tareas repetitivas que eran necesarias para mantener este control.

Es en este momento en que queda claro que una empresa no sobrevive sólo en función de su producto o servicio, sino que tanto la supervivencia como el éxito de la empresa depende en buena parte del soporte administrativo de la organización. Surge entonces la sección "Administración y Finanzas", que en muchas organizaciones consume casi el 60% de los recursos que se han invertido en la empresa. Y no es raro que a la hora de aumentar la inversión, sea esta área la que obtiene los mayores recursos.

Computación y Empresa

No obstante lo anterior, no se debe perder de vista el objetivo principal de las organizaciones, que es "vender" su producto o servicio.

Para ello, las empresas buscan otorgar un soporte adecuado al proceso productivo, el cual se caracteriza (en la mayoría de los casos) por la repetición de tareas específicas y muy bien especificadas. Es decir, no sólo con pocos objetivos muy bien definidos, sino que con una definición muy precisa de la metodología a seguir para alcanzar el objetivo.

Desde esta perspectiva, fue claro que ciertas empresas de gran volúmen, consideraron la inclusión de mecanismos computarizados, para que tomaran el control de algunas de estas tareas altamente repetitivas y de mínimo nivel de necesidad de usar "intelecto". Otras, consideraron el uso de elementos computarizados para el control y registro de volúmenes de producción.

La aparición de estos elementos, que en su mayoría eran simples contadores mecanizados, trajo consigo un efecto que no se puede olvidar. Hasta antes que llegara la "máquina", había un ser humano haciendo ese trabajo (que por muy enbrutecedor que fuera, igual era una fuente de trabajo).

Esta situación generó el primer antecedente histórico que se debe tener en cuenta: El miedo a perder el empleo luego de la incorporación tecnológica (situación muchas veces utilizada por jefaturas mediocres, para justificar ciertos despidos que la empresa requiere por otras razones, pero que no se atreven a enfrentar). Lo anterior, se debe analizar con cuidado y, al momento de analizar la incorporación de tecnología en los Sistemas de Información (fundamentalmente computacional), se debe recordar que el efecto de pérdida de empleos, se produce principalmente entre los "blue collar" ("cuellos azules" que es la forma en la que se denomina al trabajador de producción, debido al uso de overoles de ese color), que debido a la naturaleza repetitva de su trabajo son "reemplazables" por la máquina; Muy diferente es la situación de los "white collar", ("cuellos blancos", que es la forma en que se denomina al personal de administración y finanzas, así como a los gerentes, pues usan camisas, habitualmente blancas), quienes tienen un trabajo dual, por una parte la repetitiva recopilación y actualización de información ("reemplazable" computacionalmente) y por otra de análisis e interpretación de la información para la toma de decisiones (que no es tan "reemplazable", al menos no sólo con Sistemas de Información, ni siquiera con Sistemas Expertos)

[Contenidos] [Índice General]


Aplicaciones Típicas

Logrado el primer acercamiento de la computación a las empresas, rápidamente se empezó a ganar terreno dentro de la organización. Y el primer interesado en utilizar nuevas tecnologías, fueron los responsables de la administración y las finanzas... Y los proyectos en los que mayor disponibilidad había para invertir eran los de estas unidades.

Administración y Finanzas es, como se dijo, la unidad "regalona" de la mayoría de las organizaciones (mal que mal, ahi también están los gerentes). Tanto así, que muchas de las organizaciones sólo empezaron a considerar el uso de la computación, como herramienta de apoyo a estas unidades.

De esta forma, surgieron las aplicaciones típicas, que hasta el día de hoy, siguen liderando, con mucha ventaja, el rating de los desarrollos más habituales:

Es interesante notar que en esta lista se dejó, conscientemente, al final el sistema de Ventas y/o Control de Clientes. Esto es, paradójicamente, lo que ocurre en gran cantidad de empresas que si bien han dado gran importancia a todo el proceso de inversión y gasto de recursos, no dan la misma importancia a los procesos de venta.

Lo anterior se debe a la creencia (muchas veces errónea) de que los procesos de salida (compras y sueldos) son perfectamente presupuestables, mientras que los de entrada, dependerán de una serie de factores más allá del control de la empresa. Por otra parte, influye mucho el que se haya llegado a un nivel de estandarización en los procesos de salida, principalmente por el interés del Estado (en todos los países) de establecer principios de control estándares para el cobro de los impuestos.

Se ha dicho antes y se repetirá después, pero al ser uno de los aspectos más importantes de los SI, nunca será excesivo: Cualquier Sistema puede ser realizado si se cuentan con recursos infinitos (Tiempo y $).

Otro punto muy reiterado es que los SI están directamente ligados a los procesos de toma de decisiones de las organizaciones. La decisión de implementar un SI de determinada forma (al presentimiento del ejecutivo, de forma manual, utilizando herramientas computacionales estandares, desarrollo de sistemas propios) dependerá, en definitiva, del nivel de importancia que la organización asigne a la información.

[Contenidos] [Índice General]


Cobol e IBM

Desde la misma perspectiva utilizada, al analizar la historia del ingreso de la computación a la empresa, debemos recordar que la administración de empresas, no estaba entre los objetivos de la ciencia computacional. Cuando se empezaron a desarrollar los lenguajes de programación, estos daban una mayor prioridad al cálculo y procesamiento matemático. Sin embargo, al abrirse los horizontes a los procesos de negocios, se desarrolló un lenguaje que, hasta el día de hoy, es el más utilizado en el desarrollo de SI: Cobol. Siendo un lenguaje extremadamente estructurado, probablemente es el lenguaje que define las instrucciones más largas de digitar, aún para tareas relativamente sencillas. ("ADD 1 TO IVAR.") Este aspecto de estructuración es, posiblemente, la causa de que el código COBOL sea uno de los más estables y soportados en el mundo. No sólo eso, también las estructuras de datos COBOL, han sido las más resistentes para el soporte de aplicaciones. No hay muchos lenguajes o soportes de almacenamiento de datos que puedan decir algo parecido. En resumen simple: COBOL funciona.

Sin embargo, la cantidad de código necesario para un programa COBOL (producto del nivel de estructuración) hacía que los proyectos fueran de largo aliento, sin que los niveles de estructuración del código forzarán un sistema bien estructurado, muy por el contrario, es común encontrar código críptico, aparentemente sin lógica, con miles de parches, cada vez que a un usuario se le ocurrió un requerimiento nuevo. Con consideraciones de ejecución que rayan en lo ridículo, como por ejemplo, que el reporte de salida de un programa, se ordena ("sort"ea) utilizando el sistema operativo y luego se usa como entrada de un segundo proceso.

Junto a COBOL, creció una de las plataformas más confiables de entre aquellas disponibles en su tiempo. La plataforma IBM, produjo la mayor cantidad de mainframes instalados en las empresas, aún cuando se tratase de una plataforma cerrada y que requería desde una instalación específica hasta contratar/capacitar a personal especializado para la operación de la plataforma (compuesta hasta no hace mucho tiempo atrás, por máquinas que parecían máquinas de lavaseco, refrigeradores de restaurante y roperos de tres cuerpos de tia ricachona).

Al igual que COBOL, IBM no está ahí porque sí, está porque funciona, y a la hora de tener una aplicación crítica, que debe prestar servicios en la norma 24x7 (veinticuatro horas al día, los siete días de la semana) IBM es de las plataformas confiables. Además se agrega el concepto de empresa transnacional que toma muy en serio su imagen de marca.

Un aspecto que se debe analizar con cuidado, pues a primera vista aparece como negativo, es aquél relacionado con los requisitos de instalación (salas especialmente equipadas) y de personal especialista para su operación normal. Si bien esto implica que la empresa debe incurrir en un gasto mayor, también ha sido una de las principales garantías de buen funcionamiento de los equipos y los sistemas por ellos soportados. Muchos de los problemas que hoy se tienen en ciertas instalaciones, se habrían solucionado con una preocupación mínima en los aspectos de instalación y operación.

En una informacion revelada a fines del año 2000, se indicó que unos piratas computacionales europeos, habían extorsionado por años a varias empresas norteamericanas. Las empresas debian pagar si no querian que estos piratas revelaran la información que habían obtenido de los servidores windows NT de esas empresas. Cuando se reclamo a Microsoft por esto, los expertos de Microsoft dijeron que ellos sabían del problema de seguridad y habían colocado en Internet, en forma gratuita para todo aquel que los deseara bajar, los "parches" necesarios para solucionar el problema. De hecho, se comprobó que los parches estaban disponibles desde mucho antes que esos piratas entraran en las bases de datos... ¿qué ocurrió?, muy simple, esas empresas tenían personal insuficientemente entrenado, que "no sabía" que en forma regular se publican, en internet, parches para NT (y otros sistemas operativos, no sólo de Microsoft) y por ello las instalaciones eran "vulnerables".

[Contenidos] [Índice General]


Metodología

No sólo productos y plataformas, deben ser analizadas en la mirada histórica. Más importante, es la definición de la forma en que se deben hacer las cosas, la metodología

La conclusión de la sección "Aplicaciones Típicas", debiera ser clara y conforma uno de los antecedentes históricos más importantes: Los sistemas se han desarrollado en diferentes tiempos, en distintos momentos tecnológicos.

Diferentes tecnologías, distintas herramientas, otras formas de pensar, diversos paradigmas en el desarrollo de los sistemas, confabulan para crear una situación bastante caótica en muchas organizaciones que ya llevan algunos años invirtiendo en herramientas computacionales. Así, integrar los diferentes sistemas (que a veces son soportados por elementos de hardware incompatibles entre sí) no sólo es complicado, puede llegar a ser imposible.

Tampoco se debe olvidar que la disponibilidad de hardware, hace tan sólo 10 años atrás, no era tan vasta, estandarizada ni barata (en términos de costo/beneficio) como lo es hoy. Al inicio de 1990, disponer de 100MB eran casi un lujo. 1GB estaba fuera de toda discusión, sólo disponibles para unos pocos.  (No está demás recordar aquella frase célebre, de un director de IBM en la década del 50: "creo que en el mundo, sólo hay mercado para unos cinco mainframes"). De esta forma, en la década de los 80, el proyecto de incorporación de computación a la toma de decisiones, pasaba por una fuerte evaluación económica de la necesidad de invertir en Hardware (que el que se tenía, estaba destinado 100% al sistema que lo adquirió) y de personal experto para mantener en funciones este equipo.

A lo anterior, se suma el irrefrenable interés del personal de informática por poseer los elementos de última tecnología. Aún cuando no haya ninguna justificación para incorporarlos a la empresa. Esto lleva a incrementar el plexo de tecnologías disponibles... y los costos involucrados en computación.

Así, los diversos proyectos de incorporación de la computación, se vieron enfrentados entre si (eran muy pocas las organizaciones en condiciones de enfrentar más de un proyecto a la vez), donde el proyecto perdedor, podía quedar en espera por varios años y donde no era extraño que todos los proyectos de este tipo quedaran relegados en el fondo del cajón, al punto de que ninguna empresa fue realmente capaz de presupuestar en el tiempo el desarrollo de sus sistemas, (los famosos planes de informática quedaban obsoletos, recién terminados). Las empresas intentaron opciones de desarrollo interno (la unidad informática) con proyectos hechos a medida de la disponibilidad de los recursos internos, o de compra de desarrollos externos, a pedido, a empresas distintas, sin conceptos metodológicos (se debe recordar que, sólo decir "análisis estructurado", es casi como decir "computación", maravillosamente ambiguo).

Se comprende entonces, que los usuarios de cada sistema, hayan adquirido un sentimiento parecido al de aquel matrimonio que, después de muchos intentos, logran concebir a su primer hijo... No sólo amor, también un sentimiento protector que obliga a defender el proyecto de cualquier intervención externa, aunque sea la opinión del vecino de oficina (que podría ser un agente encubierto intentando atacar a "nuestro niño", de manera de que se desmorone y puede demostrar que "el otro proyecto era mejor"). Esta paranoia (que no era tan exagerada, pues quienes la sentían, ya se habían comportado así respecto de los proyectos del vecino), define otro de los antecedentes históricos que se debe tener presente: las aplicaciones han sido desarrolladas dentro de la verticalidad organizacional, sin relación las unas con las otras...

Lo anterior, no sería tan malo, pero al relacionarse con otros antecedentes tiene un efecto muy negativo. Se debe recordar, por ejemplo, que por un simple problema de costos, las organizaciones donde siempre ha habido mayor disponibilidad para estos proyectos, son organizaciones grandes, la mayoría de ellas, muy jerarquizadas (con una larga cadena de mando entre la gerencia y los administrativos que manejan la información). Esta distancia jerárquica, más un cierto grado de indiferencia en la gerencia (muchas veces confundida con la necesaria distancia para prevenir los rumores de favoritismo), confabuló para dejar este proyecto en manos de un subjefe de la subseccion ... del departamento ..., del área ... etc. De esta forma, el "cliente" del proyecto, en realidad es un usuario operativo, sin autoridad en la toma de decisiones, que (de muy buena fe, sin duda, pero sin ninguna preparación) cree interpretar las necesidades de sus jefes. De esta forma, las aplicaciones se contruyeron sobre la base de requerimientos de usuarios operativos, sin consultas en los niveles de toma de decisiones, y sin capacidad de generar las políticas necesarias para aprovecharlas. Por ello, estas aplicaciones no se transformaron en las "herramientas estratégicas" prometidas, sino, desde la perspectiva gerencial, en simples y caros reemplazos del papel y los lápices.

Y lo anterior, sólo desde la perspectiva de las organizaciones que necesitan los SI... También se debe mirar que ocurría por el lado de los desarrolladores...

Ya se indicó al inicio de esta sección, lo más importante es la definición de la forma de hacer las cosas. Y se puede entender que el cliente o el usuario, carezcan de metodología, a ellos les interesa una solución a su problema de manejo de información para la toma de decisiones (aún cuando un cliente realmente interesado en una solución, tiene mucho que decir en cuanto a estándares, como se verá más adelante en el capítulo de Análisis de Requerimientos). Son los desarrolladores los responsables de dar una respuesta integral en este punto.

Cuando se estudia con ojo crítico la historia del desarrollo de sistemas, se observa que uno de los aspectos que más destaca, tiene relación con el sentimiento paternal que los usuarios desarrollaban (desarrollan ¿?) respecto de los SI, ya que en forma paralela, los programadores desarrollaban (desarrollan ¿?) un sentimiento maternal, que no deja de lado el "dolor" del parto (que ocurriría al momento de entregar la versión medianamente definitiva). Se debe entender que teniendo "padre" y "madre", los sistemas no sólo son defendidos a brazo partido de los ataques externos, ambos padres toman para sí, el "compromiso" de apoyar el proceso de crecimiento de su "hijo", al punto de ser sobreprotectores, por una parte y asumir/crear el sentimiento de ser indispensables para el correcto funcionamiento del sistema. Esto último, lleva a programadores y usuarios a conspirar (a veces, inconcientemente), al punto de idear/aceptar ciertos procesos e interfaces complicadas, que les garanticen una gran dificultad al momento de reemplazarlos. E incluso a seguir aceptando nuevos requerimientos ("a no, el sistema es totalmente inutil, a menos que saque en forma automática el reporte A25, que se debe emitir una vez al año") y alargando así el desarrollo del proyecto, ojalá hasta el fin de la eternidad.

Hay que considerar que el problema anterior, no es un error de usuarios y/o programadores, aun cuando es una situación indeseable, está plenamente documentada desde hace bastante tiempo. El error es de los respectivos jefes de proyecto, que no toman las providencias necesarias para minimizar este problema (en términos generales, basta con no abandonarlos a su suerte, asegurando que los requerimientos se toman cuando y como corresponde; generando un diseño que cubra todos los requerimientos y proveyendo de mecanismos de respuesta que involucren a los jefes de proyecto ante los nuevos requerimientos).

Lo anterior se debe complementar con un hecho cierto, la mayor parte de los Ingenieros de Proyecto (normalmente, los jefes de proyecto) o desprecian la labor de programación o simplemente les es indiferente (esto no debe interpretarse como si se despreciara a los programadores, que no es así; es sólo la constatación de haber superado una etapa que, por lo demás, muchos de ellos nunca vivieron). Así cuando se acaba el proceso de diseño inicial (y se inicia la etapa de construcción), tienden a dejar que el programador resuelva aspectos "menores" como son, sacar un listado o ajustar un formato de pantalla o reporte. (Aún cuando ello implique variaciones del diseño tanto en estructuras de datos como de programas).

Peor aún, cuando muchos desarrollos se hicieron sin que nunca se involucrará un "jefe de proyecto", sin menoscabar la labor del rol programador, su misión es construir, no la de diseñar. Y aunque hay buenos diseños hechos por personas que nunca recibieran mayor capacitación que la de programador, estos son casos aislados, realizados bajo la inspiración de "artista" y no de la rigurosidad metodológica, que a la larga es lo más necesario.

Así se presenta el último de los antecedentes históricos a tener presentes: No se ha utilizado metodología, o peor aún se ha hecho un análisis desestructurado, que pintaba para metodología, pero que no es.

[Contenidos] [Índice General]


Conclusión

Es importante resumir algunos de los aspectos más importantes de estos antecedentes históricos:

Esto pinta un cuadro bastante complicado, que hasta el día de hoy sigue causando dificultades.

Se debe luchar contra sentimientos muy fuertes de los usuarios ("a noooo, el sistema anterior, era infinitamente superior") sentimiento que van a traspasar al nuevo sistema, en cuanto se inicie un nuevo proyecto de desarrollo.

Se debe hacer frente a un importante grado de rechazo a la planificación, pues los usuarios "saben" que el nuevo sistema no va estar listo en las fechas acordadas (sobre todo, porque muchas veces, las fechas son acordadas por gente sin mayor preparación en el área informática y sin consultar a los expertos "total, después arreglamos las fechas, sobre la marcha se estiba la carga")

Pero, por sobre todo, se debe luchar a brazo partido contra la fuerte costumbre de desarrollar sin hacer caso (o haciendo caso omiso) a la metodología. Si se avanzara en esta única área, se lograría un importante avance.

[Contenidos] [Índice General]