administracion de la funcion informatica

I ACTOR AFI

Administración de la Función Informática

Ricardo Hemánda Jimhez

Egresado del Instituto Politécnico Nacional (IPN) en 1968,el ingeniero Ricardo Hernán- dez Jiménez forma parte de la primera generación de Ciencias computacionales, reconocida oficialmente como la primera carrera en este campo en América Latina.

En 1972 fue subdirector de Informática en el centro de cómputo del Registro Federal de Causantes de la Secretarfa de Hacienda y Crédito Piiblico (SHCP). Posteriormente, en 1976, después de su especialización informática en Estados Unidos y Canadá, ocupó el cargo de Gerente de Informática en la institución Bancomer.

En 1980 fundó el Centro de Estudios Tkc- nicos de Computación Electrónica, el cual sirvió de plataforma para varios institutos que ahora imparten carreras tecnicas de computación.

Durante más de cuatro años participó como invitado permanente del Centro Edu- cacional de la IBM de México, impartiendo cursos de especialización.

4

" Todos decimos conocer la informática, entenderla y saber desprender de ella sus bondades; la realidad es que no es así.

Lo maravilloso de este asunto es creerlo a pesar de todo". Como se puede apreciar, esto que afirmo guarda entre líneas una buena dosis de ironía. Y así es. Con ello intento llamar

afanosamente la atención de mis colegas (profesores, alumnos y profesionales) para que sepan que en un país como México somos libres de usar la informática como queramos, pero que

somos responsables si no lo hacemos como se debe en beneficio

4 1 !ea1 del desarrollo y modernización de nuest7o país, ,

También quiero informar a mis colegas que AFI fue diseñado pensando en sentar las bases para redireccioriar la actuación del informático tradicional y hacer emerger al informático actual: profesionales comunes capaces de hacer cosas extraordinarias

a partir de la tecnología.

Querido lector, me pongo a tus órdenes en el siguiente correo: [email protected]

ADMINISTTRACION DE LA FUNCION

INFORMÁTICA FACTOR AFI

nez

Catalogación en la fuente

/~ernández Jiménez, Ricardo -

Administración de la función informática : factor AF1.-- 7a ed. -- México : Trillas, 2003 (reimp. 2006). 400 p. ; 23 cm. Incluye índices 158 N 968-24-6 706-3

1. Información - Sistemas de almacenamiento y recuperación - Administración. l . t.

D- 004.068'H 769a LC- T58.64'H4.3 1685

ia presentación y disposición en conjunto de

ADMINI~TRACIÓN DE LA FuNCIÓN INFORMATICA. Factor AFI son propiedad del editor.

Ninguna parte de esta obra puede ser

reproducida o trasmitida, mediante ningún sistema o método, electrónico o mecánico

(incluyendo el fotocopiado, la grabación o cualquier sistema de recuperación y

almacenamiento de información), sin consentimiento por escrito del editor

Derechos reservados 0 1988, Editorial Trillas, 5. A. de C. V.

División Administrativa Av. Río Churubusco 385

Col. Pedro María Anaya, C. t? 03340 México, D. E

Tel. 56884233, FAX 56041364

División Comercial Calzada de la Viga 11 32 C. 12 09439, México, D. I?

Tel. 56330995 FA)( 56330870

Miembro de la Cámara Nacional de la Industria Editorial Reg. núm. 158

Séptima edición (158N 968-24-6706-3)

Impreso en México Printed in Mexico

5e imprimió en Rodefi impresores, 5 . A. de C. U BM2 80 RW

Este libro tardó en concluirse más de 18 años, aunque sólo me llevó algunos meses escribirlo. Al iniciar mi carrera en el ámbito del procesamiento de datos mediante equipos de cómputo -tuve la oportunidad de ejercerla a mediados de 1968- comencé a ser partícipe de un fenómeno que prevalece hasta la fecha y que, aun cuando todos los que hemos trabajado en el medio lo conocemos bien, pocos hemos hecho algo para contrarrestarlo, permitiendo que cada vez sus efectos sean más devasta- dores. Este fenómeno se da por el mal uso que hacemos del real potencial de la informática.

Durante muchos años, de manera ininterrumpida, he detectado el gran desperdicio que sufre esta tecnología, tan importante para cualquier país. Si bien es cierto que la heredamos, eso no nos autoriza a abandonar nuestra responsabilidad y hacer lo posible para aprovecharla en su justa dimensión. Lejos de aceptar el reto con el afán de lograr un uso eficiente de lo que se nos ha dado, nos hemos acostumbrado a menospreciar sus beneficios; a obtener de ello lo que buenamente resulte, sin importar su costo; nos hemos conformado con una explotación deficiente. Dicho Fenómeno lo he definido como "despilfarro computacional", y mejor diría hoy "despilfarro informático".

Detectar las causas de este fenómeno es lo que ha tomado tanto tiempo. Para esto fue necesario observar día con día los problemas de productividad a los que se enfrentan la mayoría de las áreas de informá- tica. Ha sido fundamental apreciar sus causas y efectos, así como comprobar que tales problemas se repiten una y otra vez en una misma empresa, y que a su vez éstos son idénticos en la gran mayoría. Fue definitivo haber vivido esos problemas uno a uno y ser participe de los fracasos a que conducen para tener la seguridad de que no son imagina- rios, sino reales. Fue necesaria una profunda investigación para apreciar

que los efectos de este deterioro son exponencialmente costosos. En suma, la veracidad de lo que aquí se expone está sustentada por cientos de colegas que han tenido el valor de aceptar tan dramática situación y atacar la problemática con profesionalismo, aunque ha faltado coordi- nación para hacer extensivos los procedimientos de solución que han tenido éxito. Por ello se puede decir que este libro ha sido escrito por más de un centenar de personas altamente calificadas y con amplia experiencia, digna de tomarse en consideración para los objetivos de esta obra: redireccionar nuestra visión informática y, en consecuencia, nuestra actitud como profesionales de esta disciplina; esto último, por supuesto, es lo más difícil.

No podría adjudicarme el mérito completo del presente trabajo porque es de esos libros que no deben ser escritos por una sola persona. Su real valor es adquirido por cientos, si no es que por miles, de entrevistas, comentarios, opiniones, sugerencias, aportaciones, experiencias, análisis, trabajos, éxitos, fracasos, conclusiones y todo lo que es necesario para demostrar una realidad que se quiere reconocer con la profundidad necesaria y, finalmente, exponerla en forma abierta para que otros logren identificarla en su real magnitud. Sin embargo, asumo la responsabilidad de lo que aquí se expone porque es muy mía la tenacidad y constancia de haber desarrollado años de investigación, los cuales me han dado la madurez para discernir entre lo que se debe criticar con valor, ya que tengo bases sólidas y evidentes, y la capacidad y experiencia profesional para proponer soluciones realistas que amor- tigüen las consecuencias del despilfarro informático.

Si el lector llega a sentirse aludido al darse cuenta de que es partícipe de la raíz de algún problema aquí expuesto, le ruego reflexione y comprenda que un libro cuyo fin es atacar problemas en su máxima con- cepción, no tendría sentido si no fuera honesto y encubriera las causas reales, por incómodas que éstas resultaran. Al contrario, le pido que analice con detenimiento cada problema y acepte la oportunidad de participar en su solución. Esta es la clave, usted no será un pasajero que cómodamente aborda la lectura de este libro y espera con placer que lo lleve a su destino sin ningún esfuerzo. Usted será el conductor, yo sólo le proporcionaré un mapa perfectamente comprensible para que con su esfuerzo y su capacidad profesional llegue al destino marcado por el objetivo de este libro: redireccionar nuestra estrategia informática. Esto no será sencillo, y dado que sé lo que digo, permítaseme usar la siguiente analogía, en afán de lograr su participación decidida.

Sí, en efecto, usted será su propio conductor; pero le advierto que el viaje no será sencillo: pasará por caminos casi inaccesibles; cruzará desiertos extensos, terrenos pantanosos, espesuras selváticas; habrá momentos en que no querrá continuar y quizá hasta sienta el deseo de regresar, pero cuando consulte su mapa guía se llevará una sorpresa,

pues el trecho avanzado será muy grande y no le quedará más remedio que seguir adelante, a pesar de encontrarse solo. Cuando finalmente, casi exhausto, compruebe en su mapa guía que llegó a su destino, sólo encontrará una gran puerta que se abrirá en forma automática para cederle el paso. Cuando se encuentre del otro lado, ésta se cerrará por un mecanismo imposible de franquear si quisiera regresar. Para entonces usted se dará cuenta de que realmente ha sido un viaje sin regreso. Ya no será el mismo; habrá aprendido que existen muchas posibilidades de erradicar el despilfarro informático; que los medios existen y están a su disposición. Cuando vuelva la vista hacia adelante, podrá ver un mundo informático deteriorado y decadente, próximo a sucumbir, bajo la carga de una historia viciada, producto de muchos años de improvisación. Podrá apreciar miles de empresas que lo esperan deseosas de contar con información clara, oportuna y veraz, que permita a sus directivos con- ducirlas hacia los millones de clientes que esperan un mejor servicio. Si mira hacia otro lado, distinguirá cientos de dependencias gubernamentales que le ofrecen la oportunidad de apoyarlas para que la información de la que hasta ahora carecen les permita incrementar la recaudación fiscal, controlar en forma eficiente la prestación de servicios, abreviar los trámites burocráticos, reducir la corrupción mediante controles exactos, así como encauzar sus planes a corto, mediano y largo plazos. Por otro lado, encontrará muchos funcionarios públicos, incluido el primer mandatario de la nación, deseosos de contar con información no falseada para dirigir el país con más seguridad y con planes más precisos. Más allá distinguirá millones de personas, ese es el pueblo, que le reclama a usted honestidad profesional, para que aporte sus conocimientos y que ellos no sigan dedicando su valioso tiempo a soportar la insuficiencia de trámites de toda índole. Por un momento se sentirá muy confundido, incrédulo por tan triste panorama, pero casi de inmediato recobrará su confianza, su mente estará muy lúcida, y en ese momento aceptará el reto, seguro de que lo puede lograr, pues habrá adquirido una nueva visión del ámbito informático. Para entonces usted habrá reflexionado sobre la importancia de la información, que es en sí la que orienta las acciones en todo el mundo y mantiene la integración de la humanidad. Los acuerdos más importantes entre naciones dependen del grado en que cada una esté informada y, obviamente, de la calidad, veracidad y oportunidad de la información.

Dentro de un mundo cada vez más pequeño gracias al avance de las comunicaciones -prácticamente ya sin fronteras-, $quiénes y sobre qué bases definirán las políticas internacionales que regirán el comercio, la

legislación, economía, tecnología, ecología, energía, ciencia, educación, sociedad, distribución de la riqueza, política y muchas cosas más<

Actualmente hay quienes afirman que los países pobres, antes de I pensar en la globalización, primero deberían atender sus grandes y peligrosos rezagos internos, que tienen que ver fundamentalmente con vivienda, empleo, alimentación, seguridad social, atención médica y mucho más. Sin embargo, sobre la manera de "navegar" en un mundo globalizado, ya se está decidiendo: iquiénes lo están haciendo y con qué bases6

Por lo anterior, en esta séptima edición agregué un capítulo para llamar la atención, ya que (no obstante que AFI se ha convertido ya en una asignatura de nivel profesional) tal parece que no se ha llegado a captar que ello bien pudiera estar representándole al país la manera de entrar al terreno del juego informático mundial y participar como firme protagonista en el diseño de la informática sin tener que generar tecnología, sino, más bien, planeando y poniendo en práctica nuevas formas de utilizarla, principalmente en función de los objetivos comerciales de las empresas. Asimismo podemos hacerlo realidad en muchas otras cosas dentro de las cuales todavía no somos participantes activos. Para todo eso podemos aprovechar que ya existe una historia andada y una experiencia disponible. Pero, caray, cuánto trabajo nos cuesta pensar.

Resulta insultante que hoy, a la luz de los grandes negocios mundiales, se estima que un tercio de la producción mundial es controlado por alrededor de 500 grandes empresas, que esas mismas dominan la mitad de todo el comercio internacional y que sólo 12 de estas compañías sostienen la producción mundial de alimentos. Los estudiosos de la globalización aseguran que éstos son apenas los efectos iniciales de la misma.

Los registros históricos nos dicen que poco antes de la Segunda Guerra Mundial, Estados Unidos cayó víctima de la Gran Depresión, situación terrible que llevó a los estadounidenses a un profundo colapso económico. En tales circunstancias, les invadió un sentimiento generalizado de ineficiencia: su imagen nacional súbitamente cayó en una marcada devaluación, su economía se tornaba de mal en peor. Tal actitud derrotista propició una sensible baja en la producción del país. El desempleo hizo que el gigante americano se hundiera en la crisis más terrible de su historia. El caos moral y económico reinaba a plenitud en casi toda la sociedad. De repente, a partir de 1939, cuando se empezó a gestar la Segunda Guerra Mundial, con los sucesos del 7 de diciembre de 1941, cuando Japón atacó y devastó a Pearl Harbor dentro del propio territorio estadounidense, se despertó al coloso de su prolongado letar- go, reaccionando mediante un formidable esfuerzo industrial para equi- par a sus propias fuerzas y a las de los países aliados. La intensa actividad industrial, aunada a los efectos de la movilización bélica, aseguró

una ocupación de trabajo plena y la productividad se incrementó a niveles sin precedentes. La desesperación y las vacilaciones de que habían sido presa los estadounidenses durante la Gran Depresión, de pronto desaparecieron. Millones de estadounidenses, unidos en un sentimiento común de orgullo nacional, decidieron que era el momento de la renovación, la sensación de poder lograr grandes cosas los transfor- mó. En unos cuantos años, toda la nación emergió de las cenizas del desempleo y de la frustración, para convertirse en el innegable líder del mundo.

Me pregunto con seriedad y, al mismo tiempo, dejo plasmada aquí una reflexión para el lector: $Sería posible que los tremendos efectos de la globalización pudieran causar en los mexicanos algo similar a lo que les ocurrió a los estadounidenses durante la Segunda Guerra Mundial¿ Por eso, también pregunto: $Hasta cuándo seremos capaces de manifestar poderosamente a AFI dentro de las escuelas y en las empresas¿ ¡Caray!

COMENTARIO A LA SEXTA EDICIÓN

Hace poco, al hacer una reflexión sobre el tiempo que he dedicado al factor AFI, me di cuenta de que eran ya 18 años. Durante esta recapitulación también caí en la cuenta de la cantidad de problemas personales y profesionales que esta tarea me ha acarreado. Recoi-dé la cantidad de argumentos que he tenido que sustentar, con base en estudio y práctica, para "defender" mis puntos de vista y convencer a empresarios, directivos y asistentes a mis conferencias y seminarios sobre N I . Puedo decir, con conocimiento de causa, lo que significa el celo profesional, y he constatado que es muy incómodo y difícil de vencer. Confieso que ha sido una enorme carga esta responsabilidad gratuita que me eché a cuestas, pero reconozco también la valiosa experiencia que me ha dejado la superación de todas esas dificultades, y me han resultado "bien pagadas", gracias a lo apasionante que ha resultado esa historia mía, la cual he querido escribir y actuar. En dicho contexto, puedo decir que soy actor de mi propia historia.

El fenómeno del "despilfarro computacional" y la necesidad imperiosa del factor MI, más la consecuencia implícita de la modernización informática a que hago referencia en esta obra, aunque a paso de carga, han sido aceptados. Se habla ya de ellos con frecuencia. Mi objetivo principal está logrado; ahora sé que tengo que apresurar el paso hacia la consecución de la consolidación de AFI.

Durante 1996, y principalmente en 1997, ha llegado a mis manos una buena cantidad de revistas, periódicos y algunos libros, en donde se refieren abiertamente a mi planteamiento sobre la Administración de la Función Informática (el factor MI), y en muchos casos se menciona

insistentemente mi propuesta de considerar a la informática ya no como una simple actividad de apoyo, sino como una función vital. Lo anterior me estimula en verdad.

En esta sexta edición quiero dejar establecido que he tenido un acercamiento muy importante con varias universidades de México y del extranjero para que acepten mi propuesta de diseñar el programa de estudios para la carrera de Administradores de la Función Informática (los AFI). Sin lugar a dudas, sé de la urgencia de cubrir esta necesidad, punto de vista que espero sea compartido por los lectores de esta obra.

En el capítulo 1 dejo entrever, según mi planteamiento, algunas de las actividades, hasta ahora no cubiertas como se debería, que esos nuevos profesionistas tendrán que atender. También menciono lo alarmante de los resultados de mis más recientes investigaciones sobre la magnitud de las repercusiones que, por nuestro descuido y desatención a la Administración de la Función Informática, se dejan ya sentir en el sector educativo y en la gran mayoría de las empresas. Invito muy atentamente a los estudiantes y profesores, principalmente de las carreras de administración e informática, a que presten una especial atención a este llamado. Espero que les descubra un importantísimo y amplio campo de acción, que incluso podría explotarse de inmediato como temas de tesis.

Convoco a mis colegas informáticos -profesionales, profesores y estudiantes- a unirse a mí para atender más ampliamente el panorama de AFI. Hay mucho camino por recorrer. Por mi parte estoy inmerso en el desarrollo de un modelo que permita implantar AFI dentro de las organizaciones, lo cual será motivo de mi ya próximo libro.

Decía anteriormente que he visto con agrado que mis conceptos ya tienen aceptación, pero aún percibo cierto recelo en varios colegas e instituciones por incorporarlos de manera franca. Por alguna razón no han querido ser participes abiertos de AFI, y mi propuesta de función uzformática se ha manejado como actividad informática o auditoría in- formática. Y no debería ser así, ya que si se denomina actividad a lo que yo llamo función, se le está restringiendo, y con ello se dificulta captar su amplitud e importancia; y si se le llama auditorzá, se le limita a una pequeñísima parte de lo que estimo que es AFI.

Para referencia de lo anterior véase, entre otros casos, el Programa de Actualización Informática para Directivos (PADI), establecido por la Fundación Arturo Rosenblueth en el folleto de Otoño 97, del periodo del 27 de agosto al 19 de noviembre. Véase también el libro titulado Auditoría en Informática, de mi colega Enrique Hernández H. (CECSA). Asimismo, refiérase a los cursos denominados Administración Eficaz de la Infraestructura Informática, y otros ofrecidos por Infogama, a través del periódico Computer World de México. Yo los invito a que, sin ambages, adoptemos todos el Factor AFI.

En esta edición quiero agradecer a las universidades, tecnológicos y, en general, a todas las escuelas e institutos que utilizan mi libro como complemento de sus materias de informática. Estoy seguro de que ellos ya captaron la importancia de la temática de esta obra.

El panorama que expongo ofrece a los recién egresados un amplio horizonte de aplicación; a partir de mi experiencia personal puedo afirmar que ya muchos egresados han puesto en práctica los conceptos que se vierten en este libro, y con ello han podido impartir una nueva dirección al aprovechamiento de la informática en las empresas, con lo cual han obtenido un uso considerablemente más eficiente de esta tecnología.

Ahora, en esta quinta edición hablo de los tres grandes rezagos que ha suhido la informática en nuestro país, como preámbulo, antes de ofrecer al lector por primera vez mi enfoque sobre lo que denomino el factor NI (Administración de la Función Informática).

El concepto de reingeniería en México muestra ya un acusado desgaste, debido al abuso comercial que se ha hecho de él. Se habla de reingeniería de software, reingeniería de programación, reingeniería de sistemas, reingeniería de datos, reingeniería de aplicaciones, reinge- niería de procesos ... juf!

La única reingeniería que yo veo es la reingeniería de los sistemas de información. Ahí es en donde veo realmente el problema y no en los demás procesos de una empresa, los cuales en gran medida son entorpe- cidos por la acusada improvisación de los sistemas de información; aunque, ciertamente, al reestructurar los sistemas, necesariamente se recompondrán los procesos. De otra manera, yo me pregunto: si las empresas no cuentan con procedimientos administrativos perfectamente maduros, entonces $qué es lo que automatizan¿

Me atrevo a afirmar que más de 50 % de los procedimientos administrativos de la mayoría de las empresas son improvisados, esto es, no son estables ni maduros. Es por ello que una gran mayoría de los sistemas automatizados son deficientes; no porque sean incongruentes desde el punto de vista de la informática, sino porque se tienen automatizados sistemas de información incongruentes.

He llegado a la conclusión de que la reingeniería debe entenderse como la reorientación de los sistemas de información en función de los mecanismos administrativos modernos de las empresas actuales. Sólo entonces los sistemas de información que se automaticen serán verdaderamente efectivos para las empresas, y en consecuencia los demás procesos anteriores, colaterales y finales, serán desburocratizados, con una tendencia a la productividad y no al despilfarro, producto de la improvisación, consecuencia del control y la incertidumbre administrativa de la organi- zación. Es aquí en donde radica la aportación efectiva del factor AFI.

La realidad es que la estructura centralizada del área de informática resulta insuficiente para responder con eficiencia a las necesidades de automatización de las organizaciones modernas. Por lo anterior, he detectado que el área de informática ya no es funcional para apoyar firmemente la reingeniería de los sistemas de información. Será necesario conseguir no sólo la modernización de las empresas, sino también la modernización del área de informática, mediante el factor AFI.

Desde mi punto de vista, y. ,dadas las pruebas que hay de las enormes deficiencias en la aplicacion de la reingeniería. como se auiere entender, el factor NI es unbrequisito para dar Astentó a la reingehería de los sistemas de información.

Es perceptible entonces la gran cantidad de trabajo por hacer: por un lado, urge afianzar los mecanismos administrativos; y por el otro, diseñar la estrategia informática que soporte cabalmente la estructura administrativa mencionada. AFI sustenta esa estrategia mediante el desplazamiento de un área de informática considerada de apoyo, para establecer una estructura informática dispersada en toda la organiza- ción, que soporta la £unción informática propia de toda la empresa.

Esto es en esencia lo que ahora quiero compartir con mis colegas inforrnáticos (profesores, técnicos y estudiantes): las nuevas posibilidades de aplicación que da AFI a los informáticos actuales, que comprenden un amplísimo campo de acción.

COMENTARIO A LA CUARTA EDICIÓN

Muchos de mis lectores y asistentes a mis conferencias y seminarios frecuentemente me habían invitado a que incluyera un tema que tratara sobre el uso que se les ha dado a las PC directamente en las áreas operativas de las empresas. Por algún tiempo no pude hacerlo, porque precisamente me encontraba inmerso en una investigación a este respecto. Ahora, finalmente al haber culminado dicha investigación, en esta cuarta edición, pongo a disposición de los lectores el análisis de la problemática ahí encontrada y, por supuesto, la propuesta de solución que permita a mediano plazo fomentar una "cultura informática" en esos sectores operativos de las empresas; lo cual en otras palabras significa iniciar la descentralización del área de informática de las empresas; opción que ya es reclamada por la dinámica acelerada con la que se mueven los modernos mecanismos administrativos y los requerimientos crecientes de información de los esquemas organizacionales tremendamente móviles, los cuales día con día tratan de adaptarse a las proyecciones, de negocio y de servicio de las empresas, quienes ya vislumbran la complicada competencia que se avecina y las complicaciones de participar y permanecer en ella,

Quisiera terminar este comentario agradeciendo a las múltiples empresas y universidades de todo el país que me han solicitado el seminario denominado "Administración de la Función Informática de las Empre- sas", basado en este libro, en el cual trato de alertar a mis colegas informáticos para prepararnos a desempeñar la tarea tan importante que nos toca en la modernización de las empresas, para lo cual será necesario incrementar la productividad del área de informática, para apoyarlas con los recursos de información requeridos de modo que las áreas operativas aghcen sus mecanismos administrativos, con el fin de que los clientes sean atendidos con un alto grado de calidad en ei servicio que se les ofrece y casi no se les cumple, logrando con lo anterior un nivel de competitividad capaz de ser congruente con los requerimientos a que, aun sin desearlo, nos obliga el actual Tratado de Libre Comercio.

Finalmente, quiero responder a repetidas peticiones sobre la manera de establecer contacto conmigo para que me escriban sus sugerencias o para que participe en exposiciones sobre los temas de mi libro. Favor de dirigirse a:

El gran interés que ADMINISTRACI~N DE LA F U N C I ~ N INPORMATICA (MI) ha despertado entre colegas y estudiantes, me estimuló para continuar mis investigaciones.

En esta tercera edición expongo nuevas conclusiones, tales como el concepto de "excelencia informática"; la importancia del "seguimiento como función"; la afirmación de que las áreas de informática no están administradas; mi propuesta sobre el "modelo de aprendizaje por seguimiento como función"; un estudio completo sobre los argumentos de mis aseveraciones, etcétera.

Me es grato decir que dichas investigaciones han sido recibidas con interés, y se les da ya importancia tanto en el nivel nacional como internacional. Deseo hacerlas extensivas a usted, estimado lector.

A quienes me atendieron cuando les planteé mi proyecto sobre la presente obra, les quedo profundamente agradecido, y estoy seguro de que cuando lo vean realizado, aprobarán el hecho de que sus comentarios lleguen a todos los informáticos interesados en lo que he dado por llamar el factor AFI, el cual sin duda propone un nuevo y vasto campo de acción para mis colegas (profesionales, profesores y estudiantes).

Después de 18 años de lucha, AFI ha empezado a surgir de una realidad informática inoperante y caduca, urgida de una nueva dirección.

He esperado con paciencia desde entonces, y ahora que AFI se ha ma- nifestado, no tengo la menor duda de que es el inicio de una nueva forma de ver, entender y aplicar la informática dentro de las organizaciones modernas y, en consecuencia, de la necesidad de una nueva actuación de los informáticos,

El camino que he tenido que andar no ha sido Eácil ní cómodo; por el contrario, ha sido largo y áspero, y a través de él he recibido burlas, agresiones y bloqueos para no prose uir con mis investigaciones, lo que además ha traído consi o la pér ida de infinidad de oportunida- f d des de trabajo. Por suerte, a o largo de mi trayectoria profesional tuve el apoyo incondicional de mis cuatro jefes, quienes me brindaron su confianza, y de quienes aprendí gran parte de lo que ahora es MI.

Lo que ellos hicieron por mí no se los puedo pagar; no tengo con qué, porque eso vale muchísimo. Pero les digo que lo que AFI haga por los inforrnáticos de este país es aportación también de ellos, mis cuatro amigos, mis cuatro etapas profesionales:

- Ing. Francisco Castañeda Marín: el impulso. - Act. Pablo E. Márquez López:t (en dondequiera que esté usted) la

seguridad. - Ing. Iker Vilat (en dondequiera que estés querido amigo): la reali-

zación. - Ing. AlPedo Capote: la consolidación.

Prólogo 5 Agradecimientos 14

Siete de los cientos de orificios que AFI descubrió, 20. Introducción 21

Cap. 1. El factor AFI 25 El desenlace informático en México (cómo nos Fuimos viciando), 30. Los tres grandes rezagos de la informáti- ca en México, 42. Sugerencias de solución, 51. Resu- men, 72.

Cap. 2. El despüfarro informático: una realidad ignorada Sugerencias de solución, 88. Resumen, 89.

Cap. 3. Y la administración de la función informática.. . ghasta cuándo$ 91 Cómo y por qué surgió el problema informático del año 2000, 93. Sugerencias de solución, 104. Resumen, 110.

Cap. 4. La administración de la función informática: una actividad urgente 112 Sugerencias de solución, 120. Resumen, 127.

Cap. 5. La función informática y su relación con el ciclo de crecimiento competitivo de una empresa 129 Descripción del esquema, 130. Resumen, 132.

~NDICE DE CONTENIDO

Cap. 6. La importancia de evaluar los compromisos de trabajo 134 Sugerencias de solución, 135. Resumen, 136.

Cap. 7. Estandarizar la comunicación entre directivos y técnicos 139 Sugerencias de solución, 140. Resumen, 141.

Cap. 8. Beneficios de la asignación equilibrada de las órdenes de trabajo 143 Sugerencias de solución, 143. Resumen, 147.

Cap. 9. Estrategias de capacitación Sugerencias de solución, 149. Resumen, 149.

Cap. 10. Formación y contratación de personal técnico Sugerencias de solución, 152. Resumen, 153.

Cap. 11. Ventajas y desventajas de la consultoría externa 154 Sugerencias de solución, 157. Resumen, 162.

Cap. 12. Importancia de la participación de los usuarios Sugerencias de solución, 165. Resumen, 166.

Cap. 13. Acercamiento entre técnicos y usuarios 167 Sugerencias de solución, 170. Resumen, 172.

Cap. 14. Auditoría técnica: +por qué3, +para qué3 Sugerencias de solución, 174. Resumen, 177.

Cap. 15. Evaluación de software Sugerencias de solución, 180. Resumen, 184.

a79

Cap. 16. El enigma de las bases de datos 185 Sugerencias de solución, 187. Resumen, 188.

Cap. 17. Los métodos de trabajo y sus beneficios Sugerencias de solución, 19 1. Resumen, 193.

Cap. 18. Elaboración de programas en la computadora 194 Sugerencias de solución, 195. Resumen, 208.

1 " ~NDICE DE CONTENIDO

I Cap. 19. Control de cambios - Sugerencias de solución, 210. Resumen, 2 12.

Cap. 20. Administración de archivos 213 Sugerencias de solución, 214. Resumen, 236.

Cap. 21. Ingeniería de sistemas: Análisis, diseño y mantenimiento Sugerencias de solución, 238. Resumen, 292.

Cap. 22. La productividad en la informática Sugerencias de solución, 295. Resumen, 296.

Cap. 23. Operación de sistemas Sugerencias de solución, 299. Resumen, 303.

Cap. 24. Usemos las microcomputadoras, pero +en qué$ 305 Sugerencias de solución, 308. Resumen, 3 15.

Cap. 25. Funciones y responsabilidades del área de informática 317 Sugerencias de solución, 318. Resumen, 318.

Cap. 26. En busca de la excelencia en la función informática 319 Resultados más recientes de mi investigación sobre administración de la función informática, 321. Suge- rencias de solución, 337. Conclusiones, 345.

Apéndices. Descripción de responsabilidad y funciones por puesto, de acuerdo con el organigrama de una dirección de informática 346

Apéndice A. Gerencia de desarrollo de sistemas 348 Puesto: Gerencia de desarrollo de sistemas, 348. Pues- to: Coordinador de sistemas, 350. Puesto: Líder de proyectos, 351. Puesto: Analista-programador, 352. Puesto: Mesa de control y resguardo de documenta- ción, 353.

Apéndice B. Gerencia de consultoría técnica a usuarios 355 Puesto: Gerencia de consultoría técnica a usuarios, 355.

Puesto: Consultor de métodos y procedimientos, 357. Puesto: Consultor técnico, 358.

Apéndice C. Gerencia de servicios de cómputo 360 Puesto: Gerencia de servicios de cómputo, 360. Puesto: Je- fe del centro de procesamiento de datos, 362. Puesto: Supervisor de turno de operación, 363. Puesto: Opera- dor de la red de teleproceso, 364. Puesto: Operador de computadora, 365. Puesto: Ingeniería y seguridad de instalaciones de equipo, 365. Puesto: Auxiliar de instalaciones, 367. Puesto: Jefe de operación de sistemas, 367. Puesto: Supervisor de captura de datos, 368. Puesto: Capturista de datos, 369. Puesto: Supervisor de control de procesos, 370. Puesto: Operador de sistemas, 371. Puesto: Supervisor de la mesa de control, 371. Puesto: Control de calidad de resultados, 372. Puesto: Prepara- ción y distribución de resultados, 373. Puesto: Jefe de soporte técnico, 374. Puesto: Programador de sistemas para el soporte técnico e instalación de software en línea, 375. Puesto: Programador de sistemas para el soporte técnico e instalación de software local, 376. Puesto: Programador de sistemas para el soporte e instalación de software de bases de datos, 377.

Apéndice D. Gerencia de desarrollo técnico 380 Puesto: Gerencia de desarrollo técnico, 380. Puesto: Administración y seguridad de archivos y bases de datos, 381. Puesto: Desarrollo de métodos de trabajo, auditoría técnica y seguimiento de fallas y problemas, 383. Puesto: Evaluación de hardware y software, y medición de niveles de servicio, 384. Puesto: Planeación y control de capacitación técnica, 385.

Índice analítico

SIETE DE LOS CIENTOS DE ORIFICIOS QUE AFI DESCUBRIÓ

1. AFI demuestra que dentro de nuestro deterioro informático, a lo que nos hemos dedicado es a administrar la crisis de la informática en vez de administrar la función informática. A distancia se ve que esto fue lo que obligó a hacer un seguimiento por excepción en vez de un seguimiento como función, y en consecuencia a no aplicar el modelo de aprendizaje, ya que no es posible establecer este modelo dentro de un contexto de seguimiento por excepción.

2. En nuestra prisa por implantar la tecnología de la informática, y con nuestro profundo desconocimiento de 10 que ello implicaba, creí- mos que sería fácil y rápido hacerlo, pero. . . uEl ambicioso sube por las escaleras altas y peligrosas y nunca se preocupa de cómo va a bajar" (Thomas Adams) .

3. Los informáticos hemos sido dueños de una razón equivocada. 4. Actualmente se advierte ya que los informáticos han considerado

a AFI de distintas maneras: unos la ven como aIgo vago y quizá trivial; pero otros la aceptan ya como nuestra realidad. Esto hasta cierto punto es Iógico, pues el factor AFI hace un descubrimiento atrevido e hiriente que lastima las Fibras sensibles de nuestra vanidad sobre algo que aún nos resistimos a aceptar: nuestra impotencia para aprovechar la tecno- logía de la informática sin el atroz despilfarro, pero AFI está logrando despojar de esta máscara a aquellos vanidosos que han terminado por reconocer que nunca fueron dueños de la magia que por muchos años dijeron poseer, y por eso nunca fueron actores de su propia historia, sino más bien resignados espectadores de algo que no comprendían a ciencia cierta: la informática; y en tan deteriorado ambiente, han terminado por captar una triste realidad de la que sí fueron protagonistas, porque al no haber actuado a tiempo, terminaron escribiendo el libreto de una arquitectura suya: el desastre.

5. La informática en México ha sido invadida por la improvisación desmesurada, por eso jamás ha mostrado su verdadera identidad.

6. AFI se propone rescatar la personalidad extraviada del mformático, de entre los escombros del "despilfarro informático".

7. Dentro del terreno de AFI me propuse hablar de la excelencia, sin darme cuenta de que ésta no puede existir. Al respecto terminé por descubrir un enfoque que hice mío, y ahora lo ofrezco así:

El siguiente es un mensaje oculto, a disposición sólo de aquel que logre arrancarle su particular significado: jamás he deseado alcanzar la excelencia, pero s í sus consecuencias.

En 1980, como resultado de sencillas charlas de café, en las que nos reuníamos varios compañeros del ambiente informático, analizamos en un breve resumen en tomo a qué habían girado nuestras múltiples pláticas; y algo que de momento nos causó impacto h e que, sin excepción, siempre habíamos comentado sobre problemas que suce- dían en nuestros distintos centros de trabajo. La conclusión inmediata h e : todas las áreas de informática tienen problemas de operación.

Esto nos inquietó y casi al mismo tiempo nos preguntamos: jcuáles son las razones¿; jqué es lo que pasa¿; $hay manera de eliminarlos o por lo menos abreviarlosl. Coincidimos en que teníamos que hacer algo al respecto, que la mayoría de nosotros podríamos aportar nuestra experiencia y, con un poco de suerte y mucha dedicación quizá encontraría- mos la luz que permitiera detectar las razones de este mal y en la medida de nuestra investigación podríamos detectar soluciones realistas y dignas de ponerse en práctica. Sin embargo, volvimos a coincidir en una pregunta: jpor dónde empezar¿ En esta ocasión nos retiramos llevando como tarea que en la siguiente reunión haríamos sugerencias de cómo comenzar con una investigación que nos llevara a lo que en ese momento denominamos "detectar los verdaderos problemas de nuestro ámbito informático y exponer posibilidades de solución".

En la siguiente reunión, tal como lo acordamos, pusimos en tela de juicio nuestras sugerencias personales y, una vez analizadas, decidimos empezar por hacer encuestas en diversas instalaciones, grandes y pe- queñas, que previamente seleccionaríamos. Así lo hicimos y como primer resultado tangible, reuniendo las conclusiones de las encuestas, escribí un artículo que apareció en la revista Infomática bajo el título de "Los verdaderos problemas de nuestro ámbito computacional", el cual expongo textualmente a continuación:

En la mayoría de las instalaciones de procesamiento de datos existen grupos de técnicos altamente calificados a quienes por lo general se denomina "soporte a la producción". La función básica de estos grupos es fungir como "bomberos" para los casos en que fallan los procesos en producción. De una manera casi heroica y contra el tiempo, ellos tienen la responsabilidad de corregir esas fallas, ya sea reprocesando según entienden el proceso o, peor aún, haciendo reparaciones improvisadas y sin control, que poco a poco deforman la estructura original de los sistemas; y si agregamos que dichas reparaciones, por la premura con que se hacen, generalmente no se documentan, entonces la documentación original, en caso de que exista, va perdiendo su relación con el sistema correspondiente. Así, reparación tras reparación, empeora la situación hasta el grado de hacer casi imposible la comprensión de cualquier sistema en su concepto integral; por tanto, los sistemas afectados de tal manera se convierten en "bombas de tiempo", poniendo en peligro la estabilidad de la operación de la empresa.

Como es de suponer, las personas que participaron en la afectación de tales sistemas empiezan a ser indispensables, porque sólo ellos saben en dónde hicieron ajustes. Entonces, el famoso grupo de "soporte a la produc- ción" adquiere sentido, pues existe un pretexto real que justifica su existencia, a pesar de que esto desquicia el buen funcionamiento de la organiza- ción, porque a partir de ahí el procesamiento de datos continuo depende en gran medida de unas cuantas personas y, peor aún, nadie puede garantizar si la siguiente falla podrá ser resuelta. La consecuencia será que el servicio de la empresa en todo momento resultará "inestableJ7.

?Por qué "fallan" los procesos en producción< ?NO se supone que se tuvo el tiempo suficiente para analizar y diseñar de manera minuciosa los sistemas< ?NO se probaron en forma exhaustiva programa tras programa hasta determinar que cubrían todas las condiciones establecidas en el diseño< ?NO se revisaron y analizaron meticulosamente los resultados de las pruebas de cada programa, así como su funcionalidad dentro del sistema integral, y se demostró con un plan de ejecución que era un sistema confiable para liberarse a producción< Entonces, ?qué pasa< Las experiencias han demostrado durante mucho tiempo, aquí y en otros países, que los sistemas que se desarrollan en rigurosa forma, regidos por metodologías que eslabonan con firmeza fase tras fase, difícilmente fallan, y que cuando esto sucede es por excepciones que de ninguna manera justifican la asignación permanente de un grupo de técnicos altamente calificados, y menos aún cuando su trabajo consiste en deformar los sistemas originales. Los cambios necesarios a los sistemas y las excepciones de falla deben tratarse bajo estricto control por personas que conocen los detalles del sistema.

Jamás se debe olvidar que tales correcciones afectan necesariamente a la documentación, lo cual hace que los sistemas sean operados y manteni- dos en lo futuro por personas ajenas a su diseño y funcionalidad. Pues lo importante no es corregir las fallas, sino determinar de rigurosa manera la causa y prever que esto no vuelva a suceder. Sin embargo, ello implica por fuerza actividades serias y profesionales.

Lo anterior demuestra que todavía no hemos madurado lo suficiente dentro de esta disciplina y que no seguimos linearnientos de trabajo seguros, aunque éstos existan. Olvidamos con frecuencia que la computadora no tolera errores humanos y que éstos son muy costosos tanto en tiempo como en dinero; además, desprestigian Ia labor del área de informá- tica ante sus propios usuarios, fomentando constantes fricciones entre ambos. No hay que olvidar que un usuario puede ser un cliente que acude a un banco a cobrar tm cheque o a pagar la prestacidn de algún servicio.

Lo anterior es sólo uno de los males que, como enfermedades mortales, van minando la única y verdadera razón de las áreas de informática: producir información veraz y oportuna, sin lo cual no se justifican su costo ni su existencia.

Sería inútil insistir en que la tecnología nos lleva la delantera y que no estamos preparados para obtener el máximo provecho de sus virtudes. Es común leer y escuchar que no hay gente en el mercado lo suficientemente experimentada y capacitada como para ocupar puestos técnico-adrninistra- tivos importantes en este campo; y día con día podemos comprobarlo mediante los múltiples anuncios que solicitan técnicos de alto nivel, que ofrecen sueldos altísimos y, aunque sabemos que esto propicia el pirateo, la rotación de personal, la inflación de sueldos, el descontento de los técnicos internos, etc., lo seguimos haciendo sin reconocer que eso no solucionará nuestros problemas, pues la deficiencia en el servicio sigue existiendo, aun cuando hay gente altamente experimentada.

Para tener bases firmes acudimos a varias instalaciones, tanto grandes como medianas y pequefías, e hicimos encuestas sobre cuáles, a juicio de los informáticos, eran las razones básicas que entorpecían la función efectiva de su actividad. Hay que destacar que en todas las instalaciones que visitamos, de una o de otra manera, había serios problemas, así como situaciones de presión que, según los entrevistados, con frecuencia los ponían al borde de la crisis. Como resultado de tales entrevistas, encontramos las siguientes apreciaciones:

1. La mayoría de los jefes se comprometen a entregar resultados en tiempos récord, sin tomar en cuenta a quienes realmente hacen el trabajo.

2. Si no son 10s jefes quienes se comprometen, por lo general tienen que aceptar los tiempos marcados por los directivos, pues aquéllos son impuestos, sin considerar el grado de dificultad de los trabajos, ni los recursos con que se cuenta.

3. En gran cantidad de instalaciones los informáticos aprenden sobre la marcha, de una manera por completo empírica y sin planes de capacitación previamente definidos.

4. Todo el tiempo se encuentran saturados de trabajo por falta de planeación efectiva, razón por la cual dificilmente realizan labor de in- vestigación, necesaria para la mejor explotación de los recursos de . cómputo.

5. Con frecuencia, los usuarios se sienten insatisfechos por la falta de un nivel de servicio acorde con sus verdaderas necesidades de infor-

mación, y en ocasiones están en completa discordia con el área de informática.

6. No hay metodologías de trabajo, y donde llegan a existir, difícil- mente son respetadas.

7. Los sueldos son muy desiguales, tanto en la propia instalación como de una a otra, lo que provoca bastantes insatisfacciones personales y, obviamente, el pirateo.

Como se puede apreciar, la problemática real está a la vista de todos y no en los recursos de cómputo como se pretende hacer creer. Más bien creemos que la raíz de todos estos desajustes es la falta de coordinación, motivación y disciplina, factores indispensables en el ámbito informático.

El resultado de nuestras encuestas queda sintetizado así. Sin embargo, no quisimos conformarnos con exponerlo y criticarlo, porque ésta es tarea sencilla, sino que conjuntamos más idomiación e hicimos un análisis más severo, cuyo producto final ponemos a consideración del lector a través de este libro.

Cabe aclarar que el contenido de la presente obra no sólo se limita a mencionar la problemática del medio, sino que en cada tema sugiere estrategias de solución plenamente probadas en la práctica. Sin embargo, no se piense que tales sugerencias son mágicas ni predican cambios automáticos e instantáneos para aquellos que previa evaluación decidan adoptarlas. Más bien, lo que se visualiza es un conjunto de actividades que pueden ser implantadas de manera paulatina y ordenada. De la misma forma, son factibles de acoplarse a las necesidades individuales de cada instalación.

El falctor AFI

Problema

El área de informática, con su estructura tradicional centralizada, ya no responde a las necesidades de las organizaciones tremendamente cambiantes de la actualidad.

A partir de 1992, cuando elegí el calificativo de factor AFI para identificar el factor administrativo de la función informática, muchos colegas me preguntaban insistentemente su significado, lo cual siempre me ponía en aprietos, porque si bien yo sabía perfectamente a qué me refería, no podía expresarlo mediante una simple definición. Esto hacía que me tomaran como arrogante, porque imaginaban que no quería decírselo, y yo, para salir de la emboscada, les formulaba la siguiente pregunta: "jSabes tú lo que representa el tiempo para tic", a lo cual sin la menor duda siempre me respondían que sí. Ahora, jme podrías definir concretamente lo que es el tiempo<, e invariablemente me daban largas explicaciones sin siquiera lograr definirlo. En aquel momento, les respondía que así me encontraba para definir en concreto 10 que era AFI. En este libro me propongo describir lo mejor posible este factor y, probablemente, a encontrarle una definición certera.

En 1988, en la ciudad de Monterrey, tuve la oportunidad de impartir un seminario, en el cual por primera vez, ante reconocidos especialistas en informática y directivos de los centros de cómputo más importantes del país, hablé sobre los resultados más recientes que arrojaban ya mis

CAP. 1. EL FACTOR AFI

investigaciones sobre lo que denominaba "el gran deterioro informático". El propósito de esa plática era demostrar que el control del área de informática se nos estaba escapando de las manos; quise alertar a mis colegas de que los problemas a los que nos enhentábamos a diario ya estaban desbordando nuestra capacidad técnica, y que las consecuencias estaban tomando niveles de deterioro informático peligrosos, espec- tacularmente costosos para las empresas en donde trabajábamos.

Y elegí ese tema porque, por experiencia, sabía lo que estaba sucediendo en ese ámbito y quería exponerlo para que mis colegas estuvieran alertas y prestos a actuar oportunamente. Aun así, esperaba que lo que les iba a exponer, ellos lo tomaran como algo ya conocido y trivial, pero digno de analizarse con seriedad.

Mientras proyectaba una a una las láminas de mi exposición, me di cuenta de que a cada momento la expectación iba en aumento. Otro detalle que no esperaba era que el salón resultaba insuficiente porque seguían llegando más personas, reflejando en su rostro una especie de angustia por lo que quizá ya se habían perdido. Terminada la exposi- ción, una gran mayoría de los asistentes se me acercó para solicitarme una copia de las láminas, porque querían mostrarlas a sus compañeros dentro de su propia empresa. Otros más me invitaron a que los visitara en sus instalaciones con el fin de organizar una exposición particular. También hubo quien me pidió que aceptara una invitación a comer en privado, de modo que pudiera contestarles muchas preguntas que les empezaban a inquietar y sentían que las respuestas se vislumbraban en mi temática.

No habían pasado dos semanas de aquel evento, cuando me llegaron invitaciones de varias universidades del país para exponer el mismo tema.

Confieso que de momento no esperaba aquella embestida ni podía pensar con claridad en lo que estaba pasando. Muy pronto lo compren- dería: mi libro Administración de centros de cómputo (primera edición de este libro), ya se había difundido sin que yo me enterara oportunamente, y en él se exponía mi teoría de que "el área de informática no está administrada ni lo ha estado jamás".

Pero. . . ?Cómo podía atreverme a decir semejante cosat ?NO se suponía que ése era precisamente el trabajo de los gerentes y directores de tal áreat Hasta entonces comprendí por qué varios colegas me habían invitado a comer en privado: jeran los directores y gerentes responsables del área de informática de algunas instituciones! En algunas pláticas posteriores que tuve con varios de ellos, por cierto muy interesantes para fines de mis investigaciones, supe de primera mano lo que principalmente les había inquietado de mi exposición: lo que yo decía reflejaba una verdad absoluta, y ellos como responsables del entorno informático de sus instalaciones, no querían verse sorprendidos

EL FACTOR AFI 27

por sus superiores sin antes haber tomado cartas en el asunto, pues en ese momento mi libro ya estaba en circulación.

Para el caso de las universidades que se interesaron en invitarme, la razón era que en mi libro yo invitaba a los idormáticos y administradores recién egresados a que visualizaran un horizonte de aplicación mucho más amplio que el de ser simplemente analistas, programadores o asistentes técnicos. Les decía que las cosas no estaban bien, que se estaba deteriorando dramáticamente el ambiente informático. En el libro les demostraba que el fenómeno que denominé "despilfarro computacional" era un absurdo, de costo tan elevado que ellos (los recién egresados) no debían permitir. Además, por primera vez, se escuchó el nombre de una nueva carrera: "Administradores de centros de cómpu- to" (con ese titulo yo no me quería referir al centro de cómputo como tal, sino al área de informática), y la urgencia de su creación era evidente, según yo lo proponía y lo demostraba.

Ha pasado ya más de una década desde aquellos sucesos, y el panorama ha cambiado. Sí que ha cambiado: jestamos empeorando! Mi teoría de que "el área de informática no está administrada ni lo ha estado jamás" ha quedado demostrada. Pero eso que no logramos identificar durante más de tres décadas, probablemente con esherzo perseverante y con la formación de los profesionales especializados en ello hubiéramos logrado subsanarlo; pero. . . jvolvimos a dormirnos en nuestros laureles! No hicimos nada al respecto. Seguimos ocultando y disfrazando una realidad. De pronto surge el TLC y se aprueba. Se inicia la apertura comercial y las empresas del país forman alianzas para competir, y se preparan los planes de modernización. Por todos lados se anuncia que la automatización de los procesos será indispensable; es más, se ve a la informática como una estrategia de competencia. Se habla con insistencia sobre la puesta en marcha de la reingeniería de los sistemas de información. Se invierten fabulosas cantidades de dinero en la instalación de complejas redes de teleproceso para llevar el servicio directamente hasta el usuario final (los clientes). Se lanzan costosas campañas de publicidad en donde se ofrecen servicios rápidos y precisos apoyados por modernas computadoras. Pero ... jse podrá apoyar firmemente la modernización de las empresas con la estructura y funcionamiento tradicional del área de informática¿ Yo afirmo que no. Pero no se piense nuevamente, como hace 10 años se dijo, que estoy aventurando tal afirmación. No; esto lo sabe la gran mayoría de los informáticos. El resultado de estas últimas investigaciones está sustentado por cientos de colegas preocupados, al igual que yo, por los enormes proyectos que vamos a enfrentar prácticamente sin armas. Diría yo: "No es posible que sabiendo de las atrocidades que cometimos en el pasado, volvamos a empezar un nuevo ciclo caminando por el mismo sendero." Pero lo que más me aterra, en forma particular, es que

CAF! 1. EL FACTOR AFI

si no logramos tener control sobre la administración del área de infor- mática, ahora jcómo vamos a enfrentar mi nueva teoría sobre la "administración de la función informática" (el factor AFI), la cual tiene como requisito indispensable la descentralización del área de infor- mática t

Pero casi estoy seguro de que aun a sabiendas de la importancia del factor AFI, muchos de mis colegas serán reacios a aceptar no digamos su validez, sino su puesta en marcha, y por desgracia para el medio informática, no veo otra forma de que las cosas sucedan sino haciéndo- las; por eso quiero aprovechar este capítulo inicial para invitar al lector, principalmente si es estudiante de administración, que, a contracorrien- te, se una a la lucha de aquellos que lo queremos hacer.

Para tratar de familiarizamos con AFI, y probablemente para tratar de encontrar una definición, quisiera que analicemos el siguiente camino de preguntas, y seguro estoy de que algo importante sucederá desde ahora.

1. jSe encuentra administrada el área de informática< 2. Si la respuesta es no, ir al punto 5; en caso contrario, ir al punto 3. 3. ?Quién administra el área de informática¿ Ir al punto 4. 4. Si el área de informática está en verdad administrada, entonces jpor

qué existe y ha existido tanto "despilfarro computacional" y se siguen cometiendo a diario errores tan graves y costosos< Ir al punto 5.

5. jEl despilfarro y los errores mencionados son "males necesariosn< Ir al punto 6.

6. Si la respuesta es S& ir al punto 12; en caso contrario, ir al punto 7. 7. jEl personal técnico, de supervisión y directivo del área de informá-

tica está consciente del despilfarro y el elevado costo de los errores que se siguen cometiendo< Ir al punto 8.

8. Si la respuesta es sí, ir al punto 9; en caso contrario, ir al punto 10. 9. Si dicho despilfarro y la magnitud de los errores son de todos

conocidos, entonces jpor qué no se le ha dado solución a algo tan dañino y costoso para las propias empresas, y por qué se ha convivido con ellos por siempre y se sigue haciendo< Ir al punto 10.

10. jSe podría decir que esa situaciónla hemos adoptado los informáticos como nuestro método de trabajo y que al mismo tiempo lo hemos inculcado en las nuevas generaciones< Ir al punto 11.

11. Si la respuesta es no, ir al punto 13; en caso contrario, ir al punto 12. 12. Se sabe que en la actualidad la informática es usada ya por muchas

empresas como una estrategia de competencia; entonces, con los

EL FACTOR AFI 29

antecedentes anteriores, jel área de informática tendrá la madurez necesaria para apoyar sólidamente y de manera oportuna los planes de modernización de las empresas¿ Ir al punto 14.

13. Si el área de informática realmente está administrada, jcómo explí- car semejante deterioro en ella< Ir a1 punto 14.

14. ?Será que la dinámica organizacional y la complejidad que han alcanzado los mecanismos administrativos y de control de las empresas rebasaron ya la capacidad de respuesta del área de informática¿ Ir al punto 15.

15. Si la respuesta es si; ir al punto 18; en caso contrario, ir al punto 16. 16. jSe cree que la estructura actual del área de informática es todavía

funcional< 17. Si la respuesta es si; ir al punto 19; en caso contrario, ir al punto 18. 18. jLa reingeniería de los sistemas y la nueva tecnología de software,

hardware y telecomunicaciones están marcando una nueva era de la informática y ello será la solución para erradicar los vicios y las fallas mencionados¿ Ir al punto 19.

19. jSe cuenta con la capacidad técnica y los estrategas informáticos para implantar una solución definitiva y sostenida¿ Ir al punto 20.

20. ?Quién sabe a ciencia cierta dentro del área de idormática cómo se debe realizar lo que se podría calificar como la modernización informática de las empresas6 Ir al punto 21.

21. ?Quién asegura que no repetiremos los mismos errores del pasado< La historia informática nos obliga seriamente a cuestionarnos lo anterior.

Como puede apreciarse, existen muchas incógnitas y, según he investigado, cuanto más busco, más encuentro en el deteriorado ámbito informática; en otras palabras, esto significa que es imperante la necesidad de implantar el factor AFI.

Antes de entrar de lleno en mi propuesta, quisiera intercalar una pizca de ironía para lograr algo de relajamiento y hacer más llevadero el tema. Iniciemos por el comienzo. Pero jqué no se empiezan así las cosasC Esta pregunta es la misma que les hago a los asistentes a mis seminarios; por supuesto que es intencional, y de verdad, ya no me sorprenden algunas respuestas. Una muy significativa que recuerdo fue: "No, no siempre se empieza por el comienzo, pues si así fuera, jcómo explicar que un programador inicie la elaboración de un programa sin haber comprendido siquiera lo que pretende hacer<" Entonces pregun- té: "?Así inician en tu instalación la elaboración de los programas¿" El estruendo de carcajadas se desencadenó en el resto del grupo, y todos coincidieron en que lo mismo sucedía en sus instalaciones. Lo más gracioso y a la vez dramático es que casi es un hecho que en cada uno de mis seminarios, llega un momento en que empieza una competencia para decir en dónde se hacen las peores cosas. Aunque hace algunos

30 CAP. 1. EL FACTOR AFI

años no podía menos que asombrarme por lo que escuchaba, ahora ya no me causa efecto, jsé que es una realidad! Pero ... jtambién lo saben mis colegas! Esto está sucediendo como algo rutinario en nuestro ámbito informático en los albores del siglo m.

Para iniciar por el principio, creo pertinente dar algunos datos históricos para irnos ubicando en el tiempo, y de esta manera informar al lector, sobre todo si es recién egresado, de la forma tan "ciega" como adoptamos esta tecnología; así podremos comprender la magnitud de lo que hemos hecho con ella, o mejor sea dicho, de cómo la hemos despilfarrado.

EL DESENLACE INFOIW~TICO EN MÉXICO (CÓMO NOS FUIMOS VICIANDO)

Quisiera demostrar que el desenlace informático en México fue sin la debida atención, es decir, está definido por la tremenda ligereza con que se construyó, la absoluta improvisación a que nos sujetamos, el camino a ciegas que recorrimos, el poco interés de las autoridades académicas, la ambición de aquellos que algo conocían sobre computadoras y su temor de que fueran bajados de su pedestal si se descubría lo poquísimo que sabían al respecto, el abandono en que se dejó esta tecnología y el poco caso que se le hizo a los técnicos que deseaban establecer bases firmes para crecer y, en suma, el desconocimiento general sobre las bondades de esta tecnología que propició el poco interés que en ella se tuvo.

Ahora se puede ver con claridad que en esa época la tecnología nos superaba; o mejor dicho; por nuestro profundo desconocimiento no fuimos capaces de recibir esta tecnología y explotar metódicamente sus beneficios. Por eso es que no crecimos tecnológicamente en este sentido. Aún más, con el paso de los años nos quedamos tan estancados que actualmente persisten vicios y formas de trabajar de aquella época.

Yo viví este desarrollo en México, y por eso puedo explicar con detalle lo que sucedió, pues permítaseme decir que sufrí las consecuencias de la poca importancia que se daba a los informáticos de los años sesenta. Yo pertenezco a la primera generación de profesionales en compu- tación que egresó del IPN en 1967, única carrera en computación en aquel entonces reconocida oficialmente en toda Latinoamérica. Puedo decir que cuando egresé sólo había visto dos veces una computadora, en la cual los que estábamos a punto de egresar, tratamos de correr un sencillísimo programa de COBOL, que por supuesto nunca funcionó porque ni siquiera habíamos comprendido lo que intentábamos hacer. Nos recibimos como buenamente pudimos, pero 2de qué<, no lo sabía- mos la gran mayoría. Por supuesto que cuando salimos a buscar trabajo, prácticamente se reían de nosotros, pues nos ponían cada examen que

incluso resultaría difícil para los profesionales de la actualidad. Además nos exigían experiencia. Pero jcómo tenerla, si como dije antes, sólo vi dos veces una computadora, y eso a través de un grueso cristal! Fi- nalmente, después de año y medio de andar buscando trabajo (para entonces de lo poco que yo intuía que sabía sobre computadoras, ya no quedaba ni el recuerdo), ingresé junto con otros cuatro compañeros de la escuela a una entidad del gobierno, donde después de seis largos meses de capacitación (sin goce de sueldo) fui contratado como auxiliar de operador. Pasado el tiempo, ya con experiencia suficiente, fui invitado a colaborar dentro de una institución bancaria, en uno de los proyectos más grandes que se hayan emprendido en materia de cómpu- to en el país.

Era el año de 1976 cuando llegó a mis manos un documento que de inmediato me interesó porque reflejaba perfectamente el panorama en el cual fue estructurándose nuestro ámbito informático, Dicho documento me fue entregado por unos técnicos del banco para el cual yo trabajaba, quienes ya tenían varios años en esa instalación, por lo que estimo que tal documento fue escrito alrededor de 1975. A pesar de que han transcurrido más de 25 años, ahora podemos darnos cuenta de las bases a partir de las cuales nos Fuimos formando en este medio. Pero lo más frustrante es que actualmente seguimos conservando muchas de las prácticas y vicios que menciona dicho documento. A continuación lo resumo y lo comento en forma simultánea, con el fin de que se conozca lo que acontecía en aquellos años, para entender mejor el porqué de nuestro estancamiento, y para que valoremos con honestidad cuánta similitud existe entre los problemas de aquella época y los problemas actuales, y así nos demos cuenta de lo arraigado que quedaron los vicios que ahí se mencionan. Por tanto, el contenido de este documento debe- ría considerarse como una evidencia histórica del dramático surgimien- to de nuestra "cultura informática".

Para ubicamos en el tiempo, en el relato debe tomarse como base el inicio de los años sesenta, excepto en caso de que se mencionen otras fechas. El contenido es el siguiente:

El desarrollo de la informática en México ha sido y es anárquico. No se considera esta actividad como una profesión. No existe ninguna carrera universitaria en informática. '

México entró en la época de la computación electrónica en el momento en que Estados Unidos y otros países desarrollados encontraron la forma fácil de hacer negocio dentro del entorno del procesamiento electrónico de datos en los países tecnológicamente atrasados.

Una vez más se repitió el proceso de transferencia atrabancada de una nueva tecnología, cosa típica en los países latinoamericanos.

Se obtuvo la tecnología de "fiícil" adquisicidn, sin haber sufrido el doloroso proceso del desarrollo de ésta, sin personas que estuvieran preparadas

32 I 1 CAF! 1. EL FACTOR AFI l !

palla recibirla, entenderla y explotarla con conocimie hetedamos con plena falta de experiencia; o mejor dicho,

zo ni parto; sencillamente Io adopta una verdad, única y absoluta, en el pr portadores de esta tecnología segufan ptos y técnicas más avanzados, tales c

multiprogramaci6n, bases de datos, tiempo real, etcétera. Fue evidente en México (posiblemente por la cercanía con Estados

Unidos) que los vendedores de computadoras no tenían necesidad de presionar demasiado a sus clientes para venderles estas máquinas, ya que, como estaban de moda, se compraban más que por el convencimiento de la necesidad de su utilización, por la novedad, como si fueran automóviles último modelo. Se adquirían por cuestiones de prestigio y vanidad, aunque en la mayoría de los casos no se tuviera idea de cómo aprovecharlas.

Antes de las computadoras, los primeros artefactos que llegaron a1 país (inicios de los años cincuenta) fueron las máquinas de registro directo con tarjetas perforadas (llamadas así porque se programaban conectando cables directamente en un tablero) para programar, las cuales no requerían personal con preparación universitaria. Tampoco hubo tiempo de prepararlos en estas labores. Fue así como se lanzaron cursos improvisados de cuatro a seis semanas, por medio de los proveedores que tenían la obligación de ofrecer el personal ya capacitado a sus clientes y de algunos particulares sin ninguna obligación, pero con ganas de hacer algo con el fin de formar técnicos calificados, en vez de aquellos charlatanes que ya se empezaban a colocar en las compañías,. para pasar meses enteros sin ofrecer ningún resultado práctico ni de utilidad definida.

Estos cursos improvisados fueron el alma rnater de los supuestos especialistas en procesamiento de datos de aquella época. ¡Vaya!, pero 2c6mo íbamos a crecer partiendo de estas basesC Y lo peor es que ellos fueron los maestros de los maestros que capacitaron a una generación tras otra.

A pesar de estos antecedentes y gracias principalmente a las noches sin dormir, esfuerzo, tenacidad, canas y muchos otros sacrificios, se líegó a manipular medianamente las máquinas de registro directo. Pero la ambi- ción les ganó, ya que unos 200 poseedores de este rudimentario conocimiento crearon un misterio alrededor del procesamiento de datos, y súbitamente el crecimiento técnico en materia de cómputo de1 país quedo detenido, como si el no comunicar sus raquíticos conocimientos les sirviera de defensa contra los intrusos de otras áreas y de los graduados de las carreras pro£esionales (aun cuando no eran informáticos). Lo anterior sirvió para que los "especialistas" hicieran lo que les vino en gana, creando un tremendo obstáculo para que se capacitara nuevo personal. Y así pasó mucho tiempo.

Por fortuna, algunos profesores se dieron cuenta de este peligroso bloqueo, y comenzaron a ingeniárselas para estructurar cursos relámpago que permitieran que de las aulas universitarias comenzara a emerger una

nueva generación de técnicos más correctamente preparados, con lo cual poco a poco se empezó a remodelar el sistema de trabajo que habían introducido los primeros "especialistas". Pero el proceso fue lento, y requirió varios años más.

Dentro de este contexto, el desarrollo de la informática siguió su ritmo y siguieron vendiéndose más equipos (note el lector la tremenda improvi- sación con que fueron preparados nuestros primeros maestros e imagine la calidad que podían tener los resultados obtenidos en aquellos equipos).

Por regla general, los nuevos usuarios entraban en la etapa de la automatización por los siguientes motivos: por la presión de la competencia; por la insistencia, mentiras e hipnotismo de los vendedores o por la recomendación directa de las casas matrices. Por supuesto que dichos usuarios fueron integrados casi siempre sin ninguna preparación previa a este importante paso.

Para vender las primeras computadoras, el vendedor conseguía con el anzuelo de un atractivo sueldo a algún individuo medianamente experimentado en el asunto de estructurar y echar a andar un nuevo centro de cómputo, y lo colocaba como gerente al mando de dicho centro.

De inmediato éste se "pirateaba" a sus antiguos colaboradores, o en su defecto lanzaba un anuncio en el periódico, con lo cual empezaba a funcionar el mecanismo de la rotación de personal que tanto perjudica, y que con base en las leyes del mercado libre del siglo pasado, trae como consecuencia la inflación de sueldos, el "bloferismo", las barreras para la formación adecuada de nuevos técnicos, los fracasos, los resentimientos e inconformidad de los técnicos propios de la instalación, los graves retrasos en la realización de muchos proyectos, y en general el desprestigio de la profesión.

A los informáticos de las décadas de los años cincuenta y sesenta se les tenía en un concepto de "genios". Para inicios de los años setenta, su popularidad había decrecido tanto que simplemente se les llamaba "elec- trónicos", y no pocas personas 10s comparaban con los radiotécnicos.

En ese entonces se percibía que el principal deterioro durante el desarrollo informático de México se debía a la ausencia completa de los parámetros y criterios adecuados para la calificación del personal de informática. Ni siquiera se podía saber con acierto qué personal era bueno o malo.

Las bases en las que se fundaba la llamada evaluación de técnicos eran la promoción propia de los técnicos, el "bloferismo", el "amiguismo", el solo hecho de haber trabajado en un centro de cómputo con equipos de gran tamaño. Por otro lado, como contrapeso de esta promoción activa y dinámica, funcionaba el "sistema de devaluación": rumores, chismes, comentarios hirientes, envidias. Ni una sola persona del medio podía escapar del popular calificativo de "tonto".

Como se puede observar, ya que e1 sistema de evaluación de técnicos se basó en tales parámetros ("amiguismo", "padrinos", "bloferismo", etc.) y se vivió con él durante décadas, lo que nos dejó, entre otras malas cosas, fue un fuerte atraso en el proceso de preparación del personal informático. A

34 CAF! 1. EL FACTOR AFI

inicios de los años setenta, en Estados Unidos se duplicó el personal de informática. En Japón se quintuplicó. En México sólo existió un aumento de 60 %, el cual no fue suficiente para alcanzar el ritmo de crecimiento del número de instalaciones. Esto significó que el número de técnicos por instalación decreció. Además, como en ese entonces la tendencia era aumentar el tamaño y la capacidad de las computadoras, pero no se aumentó el número de técnicos por instalación, no se tuvo la capacidad para absorber nuevos conceptos, aplicaciones, sistemas avanzados ni nuevos lenguajes de programación, y por tanto nos volvimos a estancar por más años.

La situación se tomó muy grave, al grado de que muchas empresas no pudieron conseguir programadores a ningún precio por un lapso de varios años.

De pronto se comenzó a hablar mucho sobre los temas de teleproceso y trasmisión de datos (1973), y sin embargo no se contaba con ningún profesional especializado en esta rama, por lo que se tuvo que improvisar a algunos aficionados y técnicos de otras especialidades de las comunicaciones: Lo mismo sucedió en las especialidades de diseño de bases de datos, administración de datos, sistemas operativos, programación modular, etcétera.

Durante aquellos años era común que a un magnífico programador que sabía COBOL de memoria, lo pusieran a diseñar un sistema de consulta por medio de bases de datos, tan sólo porque se le daba el nombramiento de analista de sistemas y se le duplicaba el sueldo; también se solía asignar a un individuo sin más conocimiento que Ias instrucciones de RPG, para rediseñar los procedimientos administrativos en el nivel de empresa o de institución, con el fin de automatizarlos.

Es obvio que para efectuar con soltura cualquier actividad humana, se requiere educación, preparación, especialización y experiencia, además de vocación y devoción. En el medio informático, por mucho tiempo se ha violado esta regla, no obstante que las actividades de operación, programa- ción y análisis y diseño de sistemas requieren una preparación y especiali- zación laboriosas, que no se adquieren fácil ni rápidamente, además de que no cualquiera puede ser candidato aspirante a esos puestos.

Para ser operador o programador se debe ser una persona metódica, cuidadosa, detallista y con inclinación hacia las matemáticas. Se requiere no sólo dominar el lenguaje de programación que se utilice, sino también ser prohndo conocedor de las características técnicas de la computadora con que se cuente. Por otro lado, para ser analista de sistemas se debe tener una visión muy amplia del entomo administrativo de la empresa y dominar con gran amplitud los conceptos sobre sistemas de información automatizados.

Pese a los requisitos de especialización anteriores, si el informático de aquella época quería progresar, tenía que cambiar constantemente de actividad, aunque alguna la tuviera que dejar a medias: de operador a programador; de programador a analista; de analista a jefe de un centro de cómputo. Y como se puede apreciar, muchas veces un buen operador se convertía en un pésimo programador, y un magnífico analista se convertía en un jefe mediocre.

Por lo anterior, el límite de crecimiento del informático dentro de la organización se daba dentro del marco del área de informática. O mejor dicho, prácticamente no había crecimiento, ya que eran áreas que no pasaban de 15 o 20 personas y sólo un jefe. En otras palabras, ahí terminaba la carrera del informático. Para aspirar a otros niveles administrativos de más jerarquía tenía que plantearse como objetivo salir del área de informática.

¡Qué desperdicio!: cuando finalmente se lograban años de especia- lización, cuando se contaba con las raras características académicas que se requerían y además se tenía la capacidad y paciencia para esperar oportunidades de ascenso, terminaba uno fuera del área que ya dominaba. Después de esto, no resulta difícil entender la tremenda escasez de personal técnico calificado y diestro en labores de computación que se padecía en aquella época. Para contar con técnicos, éstos tenían que formarse sacando empleados operativos y capacitándolos de manera improvisada con maestros que resultaban ser los novatos técnicos que aún no se habían ido, ya que los más experimentados, o ya habían emigrado a otra instalación por razones de "pirateo", o ya habían salido del área de informática para ocupar puestos de mayor jerarquía que no existían dentro de su entorno informático. Ahora resulta fácil saber por qué nos estancamos por años. Por eso formamos vicios, ya que sin contar con buenas directrices, lo que se improvisaba se tomaba como procedimiento único y verdadero. Esa fue la razón de nuestro temor a cambiar las tarjetas perforadas por sistemas de consulta mediante pantallas de video. Resultaba curioso (por no decir gracioso) cómo en plena década de los años ochenta muchos de los centros de cómputo más grandes del - país, aun contando con poderosas computadoras, seguían manteniendo sistemas de tarjetas perforadas de los cuales dependían resultados importantes para la institución. Y dichos centros eran considerados nacionalmente como instituciones con tecnología de punta.

Por supuesto que tales sistemas de tarjetas perforadas ya habían sido diseñados hacía décadas, cuando aún casi todos los resultados se ob- tenían en reportes impresos; la consecuencia era que a los usuarios se les seguían enviando a diario toneladas de papel (reportes impresos) que jamás tenían tiempo de leer. Había ocasiones en que a un jefe de mediano nivel se le sacaba de su oficina para que ésta pudiera ser utilizada como bodega de reportes impresos obsoletos o que a nadie importaban. La razón era que estos usuarios tenían pena de que se encontraran cerros de papel por todas partes y a diario se acumularan más. Preferían ocultarlo para que no lo vieran personas de otras áreas o visitantes que muchas veces eran clientes de la compañía (hasta hace muy poco esto se seguía viendo).

Al inicio de la década de los setenta empezaron a surgir algunos profesionales en informática egresados de algunas universidades y tecnoló-

CAE 1. EL FACTOR AFI

gicos, y aunque eran sumamente novatos, ahora contaban con un potencial importante, producto de su buena formación académica, por lo que en poco tiempo empezaron a ser pilares de algunas instalaciones. Para entonces empezaba a percibirse, al principio dihsamente, pero luego con mucha mayor claridad, la diferencia entre un aficionado y un profesional. Se decía que la diferencia radicaba en que el profesional sabía que contaba con elementos para cumplir compromisos y los cumplía, pues sabía qué recursos iba a utilizar, sabía identificar si contaba con ellos, programaba sus actividades y era capaz de calendarizarlas, estaba preparado para establecer métodos de trabajo y seguirlos, seguía un orden desde el principio y documentaba su trabajo. No así el aficionado, que todo lo hacía de manera suelta y con desorden.

Se empezaba a entender que cuando se contrataba a un profesional, no se tenía que estar preocupado por la entrega de resultados, sino que se pagaba por la garantía de su obtención.

Era evidente que se estaba en el momento de dejar de ser aficionado para convertirse en profesional. Pero todavía no había madurez y, como quienes sustentaban los puestos más altos en las instalaciones de cómputo eran precisamente los aficionados de la antigüedad, ahora su labor fue bloquear por más años la aceptación formal de los profesionales. ¡Qué desgracia y qué desperdicio de talento! ¡Qué oportunidad de crecer se nos congeló en las manos por más años!

Como señal del abatimiento informático, se comenzó a dar un fenó- meno: se empezó a pagar más a los profesionales que a los técnicos improvisados, y no tardaron las envidias y e1 recelo entre unos y otros. Y por supuesto, ante los ojos de los jefes del propio centro de cómputo y de las áreas administrativas, se decía que "los profesionales costaban demasiado". Pues claro, porque se les estaba desperdiciando, ya que un jefe que había sido uno de los aficionados, con nivel académico medio o bajo, no tenía ni la más remota idea de cómo liderear y administrar las actividades de los profesionales. Por esta razón, y para no sentirse menos, les imponía por fuerza los métodos de trabajo que él conocía; métodos de trabajo viciados y empíricos. Peor aún, ya fuera que existieran esos métodos o no, lo más común eran los "maratones de trabajo" (noches y días enteros sin dormir), con lo que absorbieron a los profesionales y les inculcaron o im- pusieron tales formas de trabajo. Con el tiempo, del profesional metódico y ordenado sólo quedó un "caballito de batalla" incorporado al batallón de los aficionados.

En poco tiempo (1970-1975), a los profesionales se les degradó y éstos tuvieron que soportar la discriminación que les hacían los aficionados, quienes de cualquier manera seguían teniendo el conocimiento de los detalles de los ridículos sistemas que estaban en operación. Pero eran los únicos, así que no había alternativa.

Pese a lo anterior, la década de los setenta marcó una nueva etapa en la era de la informática en México. Hubo una explosión en la adquisición de nuevos equipos de cómputo. Las posibilidades de técnicas modernas de comunicación vía telefónica, microondas y satélite hicieron que se inventa- ran nuevas técnicas en el manejo de datos (bases de datos, teleproceso, sistemas operativos, sistemas completos ofrecidos como paquetes de soft-

EL DESARROLLO INFORMATICO EN MÉXICO 37

ware, etc.). Estas técnicas hicieron que las posibilidades de servicios en línea (tiempo real) fueran requeridas por grandes instituciones (bancos, dependencias gubernamentales, empresas privadas) como estrategia de competencia para ofrecer un mejor servicio a sus millones de clientes. En consecuencia, surgieron nuevas especialidades de técnicos que obviamente no existían en el mercado (programadores de sistemas, administradores de bases de datos, especialistas en teleproceso, especialistas en seguridad de datos, administradores de la capacitación técnica, auditores de informática, etc.). La demanda de personal técnico y profesional estalló y los sueldos se fueron a las nubes, la "piratería" se desencadenó como nunca. Fue un caos total.

Por razones de la escasez de carreras profesionales en uiformática plenamente estructuradas y confiables (con excepción de las del Tecnológico de Monterrey y el IPN) en la década de los setenta, de una o de otra manera surgían técnicos como por arte de magia. Algunos entraban en el campo después de una carrera técnica, administrativa o de cualquier otro tipo; otros, después de un par de años de carrera profesional; muchos, al salir de preparatoria, y hasta de secundaria; otros, después de algún curso de pro- gramación se lanzaban en busca de las miles de vacantes con sueldos jamás vistos.

Considerando que la mayoría de las empresas no admitían programadores sin experiencia, muchos de los estudiantes improvisados pasaban seis o siete meses saltando de empresa en empresa hasta que tarde o temprano, por la gran demanda, lograban colocarse como aprendices de operador o algo por el estilo. Así empezó la carrera del técnico en informá- tica. Aígunos, a base de tesón y autodidactos, lograron destacar y llegaron con el tiempo a ocupar puestos de jefes, gerentes y hasta de directores. Muchos, sin embargo, siendo malos técnicos, con el tiempo conocieron los secretos del oficio sólo de palabra, o sea, aprendían la jerga de la compu- tación, y no tardaron mucho en colocarse. En toda aquella revolución, algunos jamás fueron descubiertos como pésimos técnicos. Para aquellos que descubrieron que sus técnicos estaban mal preparados, por lo regular ya era demasiado tarde: éstos estaban ya en la nómina.

En estas condiciones, los que elegían el camino del cambio constante de instalación, en poco tiempo ganaban mucho más que aquellos que tomaban el camino del estudio y la especialización dentro de una sola instalación (jen la actualidad, esto le suena familiar al lectort). Sucedía que cuando la misma persona salía de una empresa por un tiempo y después regresaba, duplicaba su sueldo, mientras que gente fiel a su trabajo y responsable de sus obligaciones, recibía después de mucho tiempo sólo 10 5% de aumento.

Esta situación levantó un gran revuelo; muchos técnicos se quejaron con los directivos, diciendo que no era sano lo que estaban provocando las empresas con sus anticuadas políticas, y que esto era nefasto en un campo tan dinámico que requería un personal tan especializado. Se pedía a grito abierto que, dadas las condiciones de trabajo (frecuentes "maratones", urgencias continuas, desvelos constantes), debían ser bien remunerados aquellos que verdaderamente sabían y producían buenos resultados.


Por supuesto que no les hicieron caso, pues siguieron apareciendo en el periódico anuncios solicitando persona1 con dos años de experiencia en máquinas de cuarta generación. Una persona de mediana inteligencia, después de unos cursos de programación y un año de haber estado llenando solicitudes y haciendo inEinidad de exámenes, lograba dominarlos de tal manera que un gerente, al ver los resultados y sostener una breve entrevista, de inmediato lo contrataba. Así, un individuo listo podía muy bien pasar cinco o seis meses "programando", sin que nadie se diera cuenta de que era incapaz. Para entonces, aunque no hubiera dado ningún buen resultado, ya había cobrado varias quincenas. Para el caso de los analistas de este tipo, se prefería mejor no hablar.

Así queda sintetizado un documento que apareció hace más de 25 años. En lo particular, me propuse comentar este contenido con varios colegas altamente experimentados con el fin de comparar aquella época con los acontecimientos actuales. La conclusión general he : "En la actualidad contamos con equipo tremendamente más poderoso que antes; se han establecido eficientes métodos de trabajo, existen modernos lenguajes de programación, los paquetes de software se han diversificado enormemente, las redes de teleproceso actuales son impresionantes, la información procesada fluye a millones de usuarios en segundos, las microcomputadoras han introducido, aunque superficialmente, una cultura informática en el nivel general. Pero jatención !, en esencia, los problemas que actualmente aquejan al área de informática son los mismos que se mencionan en el documento, sólo que ahora mucho más amplificados ."

Tome nota, que esta opinión generalizada concuerda mucho con las bases que en el siguiente capítulo establezco como plataforma para asegurar que la función informática de las empresas nunca ha estado administrada ni lo está en la actualidad.

Mis investigaciones me permiten afirmar que la década de los setenta representó para México el punto de partida definitivo para integrarse de lleno al ámbito computacional. Antes de esta década, el desarrollo informático en nuestro país era prácticamente nulo. Muchas empresas, aun teniendo la capacidad económica para adquirir equipo de cómputo, no encontraban la justificación para hacer el gasto (salvo por vanidad o prestigio, como se menciona en el documento expuesto), pese a que sus operaciones administrativas hacían urgente su adquisi- ción. He encontrado que la explicación de esta contradicción ahora resulta hasta cierto punto lógica y natural, pues vea usted: por situaciones que no viene al caso comentar, durante años nuestras escuelas, institutos y universidades no prepararon técnicos y profesionales en computación, en otras palabras, no se creó una cultura informática en nuestro país. Por lo mismo, eran pocos los empresarios, directivos y funcionarios que entendían los enormes beneficios que representaba la

EL DESARROLLO INFORMÁTICO EN MÉXICO 39

utilización de las computadoras. Pero aun cuando algunos deseaban adquirirlas, el problema verdadero consistía en encontrar los analistas, programadores y operadores que las hicieran Funcionar. Su capacitación sería mucho muy tardada debido a que no existian centros educativos específicos de ti o abierto, pues los pocos que existian eran los propios de los distribui 'f ores de computadoras de esa época, y la gran mayoría no contaba con la infraestructura adecuada para garantizar capacitación de calidad. Lo que se hacía era organizar cursos breves de algunas semanas y se lanzaba al personal a foguearse directamente a la máqui- na. En verdad era poco lo que se aprendía en tales cursos teóricos (al igual que ahora), pues donde realmente se aprendía era en la práctica, donde con frecuencia no se llegaba a aplicar gran cosa de lo que se había recibido durante los cursos. Me tocó ver casos en que algunas personas que habían obtenido calificaciones bajas, en pocos días de práctica superaban fácilmente en conocimientos a algunos con calificaciones sobresalientes.

Todos los que de alguna manera participamos en el desarrollo de la informática en México, sabemos que el nacimiento de nuestra cultura in- formática, si es que así se puede llamar, fue tremendamente superficial y desordenada. Fue la manera como empezamos a engendrar infinidad de vicios, los cuales quedaron arraigados de tal manera que la gran mayoría aún persisten. Muchos de los que participaron como instructores en la preparación de los técnicos de Finales de la década de los sesenta e inicios de la de los setenta aprendieron de una manera también superficial, quizá más precaria que nosotros (recuerdo que mi maestro de programación nos enseñó el lenguaje COBOL aprendiendo sobre la marcha. Por cierto, nunca estuve seguro de si él aprendió). Aun con la mejor intención de enseñar, lo mejor que podían generar entre sus alumnos era técnicos improvisados que aprendieron los vicios que ellos habían adquirido, acarreando así infinidad de deficiencias. Véase con detenimiento que desde principios de los años setenta hasta inicios de los años noventa, estamos hablando de un periodo de 20 años, lo cual quiere decir que muchos de los técnicos que participaron como maestros de aquella época aún siguen activos en el medio; es muy probable que durante varios años tanto ellos como los que Fueron sus alumnos hayan ocupado los puestos de mayor jerarquía en el área de informática de las instalaciones más importantes del país, y es muy prob ble ue aún los ocupen. ?Pero qué importancia puede tener esto< kjb - # -

Analicemos lo anterior. Dado que ellos Fueron precisamente 6 s aue de alguna manera (por cierto muy meritoria, pero no por eso menos equivocada) Fueron armando la infraestructura informática con que cuenta ahora el país, a ellos se les debe reconocer el gran esherzo que tuvieron que hacer para lograr lo mucho que se avanzó durante esos 20 años. Fueron ellos quienes permitieron el gran salto que México dio en

40 CAP 1. EL FACTOR AFI

el ámbito informático, llevándolo de un nivel prácticamente nulo en la utilización de equipos de cómputo, hasta hacer que en la actualidad sea una tecnología utilizada hasta en los últimos rincones del país.

Pero no todo es halagador. Cierto es que México está actualmente al corriente en el conocimiento de esta tecnología; cierto es que se avanzó tremendamente en sólo dos décadas; pero precisamente por esa marcha forzada que adoptamos, muchas cosas se fueron improvisando en el camino. Muchos vicios y deficiencias se le fueron inculcando a las nuevas generaciones de informáticos. Pero no pudo ser de otra manera, pues aprendimos a usar las computadoras más con tesón, constancia, desvelos, estudio autodidacto, a marchas forzadas, sin estrategias a la altura de esta tecnología, planes improvisados, etc., que con capacita- ción estratégica, tiempo suficiente para hacer bien las cosas, organiza- ción, planeación, administración. Estuvimos solos, trabajando como pudimos, con verdaderos deseos de producir resultados satisfactorios, con muchísimos sacrificios que llegaron al límite de la capacidad física de los participantes. Fue evidente que las urgencias y prisas fueron cotidianas. Este fue nuestro ambiente de trabajo durante semanas, meses, años ... muchos años.

Con el desarrollo tremendamente acelerado de esta tecnología que se dio básicamente a partir de la década de los setenta, nuestra consigna se convirtió en: "Hágase como sea, pero hágase." Jamás se analizaron los costos, los riesgos, y sobre todo el bajo nivel de calidad que se iba consiguiendo en los trabajos terminados. Por ejemplo, al salir al mercado los equipos de la tercera generación, de pronto apareció la facilidad del acceso remoto a los datos, o sea los sistemas en Iínea, y como se pudo, tuvimos que convertir los sistemas batch en sistemas on h e , iy vaya que lo hicimos! En corto tiempo ya contábamos con servicio en Iínea, aunque de momento fuera sumamente deficiente, raquítico en su alcance de servicio, y por supuesto tremendamente improvisado desde el punto de vista aplicativo. No había pasado mucho tiempo cuando de pronto se nos presentó el concepto de bases de datos, y hubo que asimilarlo. Había que rediseñar sistemas completos para ahora aprovechar los beneficios de las bases de datos. $Cómo lo íbamos a lograr$, no lo sabíamos, pero había que hacerlo a como diera lugar. jEl resultadoc: sistemas altamente defectuosos, bases de datos inseguras y mal diseña- das, etc. Pero lo que más nos importaba es que habíamos incorporado estos adelantos.

Como se puede observar, "heroicamente" fuimos haciendo cosas muy mal hechas. Ese fue el camino sobre el cual se h e creando la idraestructura informática del país. En otras palabras, teníamos que entrar a como diera lugar a la alta tecnología computacionaI. Ya adentro, muy probablemente podríamos componer las cosas. Pero la realidad es que en vez de eso, nos engañamos y creímos que habíamos

construido un camino correcto. Aunque prefiero decir que nos dio pereza tan sólo pensar en todo lo que había que "reparar", y preferimos esperar a que alguien llegara a hacerlo. Pero no sucedió así: la verdad es que arraigamos un modo de trabajar en todo el personal que estaba a nuestro cargo, y se entendió como método. Ellos a su vez lo trasmitie- ron a otros, y así se hizo una cadena a la cual actualmente se le siguen agregando eslabones, etiquetados como "nuestra forma de trabajar", sin entender que con cada nuevo eslabón nos estamos ahorcando más y más.

Pero hay razones de fondo que influyeron aún más para que en México quedáramos esclavizados a sistemas dormáticos tan deficientes e inseguros, que incluso visto desde la perspectiva actual, pudieran justificar tal proceder, por la sencilla razón de que en aquel momento convenía a las empresas hacerlo así. Aunque no se crea, estas circunstancias desembocaron en lo que muchos años después se llegaría a conocer como el fenómeno de Y2K. Consúltese el cap. 3, en donde explico esto detalladamente.

Poco se ha hecho para corregir las deficiencias, como se demostrará en los siguientes capítulos. Las cosas, por inercia, nos han seguido manteniendo en un nivel tecnológico pobre, que dista mucho de ser congruente con los requerimientos de las empresas modernas.

Es probable que el lector se sienta ya aturdido de tanto "negativismo". Pero deje que le diga que con todo y eso me he quedado corto. Y para que no quede duda, espere un poco más y verá hasta dónde hemos llegado, y peor aún, que seguimos aferrados a caminar en esa dirección.

Pues bien, si aún existiera duda de todo lo que se ha dicho hasta aquí, y si en verdad hubiéramos ya madurado con suficiente Eirmeza para emprender un camino más productivo y provechoso en el ámbito informático, jcómo explicar el segundo gran tropiezo que cometimos con la aparición de las microcomputadoras o PC (véase cap. 24) con el que volvimos a tropezar con la misma piedra¿ Es indudable que volvimos a perdernos debido a las prisas y a la improvisación. Por desgracia, se vuelve a comprobar que lo que nos orilló a este nuevo fracaso, o mejor dicho "despilfarro" (ahora se puede ver con mayor claridad el nivel de despilfarro de que somos capaces en este ambiente), fueron los vicios que seguimos arrastrando. Se demuestra con claridad que cometimos muchos de los viejos errores: fueron idénticos.

$Qué informático en su sano juicio puede rebatir mi teoría sobre: la función informática de las empresas jamás ha estado administrada ni lo está en la actualidad¿ Después de esta segunda enorme prueba, de la cual hay evidencia por todos lados, estamos hechos un desastre. Lo sabemos todos pero preferimos ignorarlo. Siento que estamos en un estado de "caída dependiente", es decir, estamos en lo profundo del hoyo, nos estamos ahogando, pero seguimos esperando a que alguien o algo actúe y nos sacuda fuertemente para organizamos y movemos a


emprender medidas correctivas, pero guiados por ese alguien o algo que sepa lo que se debe hacer. Nosotros no lo haremos mientras no exista esa guía y ese tutor que adquiera la responsabilidad.

Permítaseme decir que eso no sucederá, que cada uno de nosotros tiene que pagar parte del precio que no hemos querido pagar (aun a sabiendas de que ya nos resultó más caro). Sepa cada informático (colega, estudiante o profesor) que si queremos participar en la erradica- ción de tan tremendo despilfarro informático, se tendrá que dar mucho más a cambio de lo que se nos paga. Seamos conscientes de que es el único camino para prosperar y superar cualquier obstáculo expuesto aquí. Por lo anterior, y como nadie distinto de nosotros va a tomar la responsabilidad que nos corresponde, ahora que el lector ya tiene el panorama resumido del desenlace informático como se dio en nuestro país, entremos al entorno de AFI.

LOS TRES GRANDES REZAGOS DE LA LNFORMÁTICA EN MÉXICO

Para explicar AFI, me voy a referir a lo que he identificado como los tres grandes rezagos de la informática, que a lo largo de la historia informática en México nos han afectado enormemente, y tengo evidencias de que esto que voy a explicar también lo ha sufrido en forma similar la gran mayoría de los países en vías de desarrollo.

Seguro estoy de que el lector sabe lo que significa un rezago. Sin embargo, para darle un orden a mi explicación, quisiera mencionar su significado.

Rezago: atraso; suspender la ejecución de una cosa; quedarse atrás. Ahora bien, antes, cuando hablé del desenlace informático en

México (de cómo nos fuimos viciando), quedó demostrado que nuestra falta de entendimiento para aprovechar significativamente los recursos de cómputo que prácticamente se nos dieron en la mano, se debió fundamentalmente a que no estábamos preparados académica ni culturalmente para su correcta utilización. Vimos inclusive que muchos años después de que en México se introdujeron los equipos de procesamiento electrónico de datos, primero los de registro directo (hacia 1950) y después las computadoras (hacia 1960), apenas en 1970 se inició la impartición profesional ya formal de las carreras de computación, aunque bien es cierto que en 1964 el IPN tímidamente lanzó una carrera profesional de este tipo, y el Tecnológico de Monterrey hizo algo similar. O sea que prácticamente tardamos 20 años en reconocer que dicha tecno- logía valía la pena de tomarse en serio. Se puede ver con claridad nuestro tremendo atraso tecnológico. Pero también ahora habrá que reconocer que si bien académicamente (en el nivel técnico y profesional) logra-

LOS TRES GRANDES REZAGOS 43

mos, aunque muy tarde, adentramos en dicha tecnología, después tardamos otros 20 años más para que en el nivel de masas culturalmente lográramos adoptarla (en 1990, con la introducción de las PC) y, para colmo, aun ahora no tenemos en el nivel de secundaria una materia oficial sobre computación. O sea que continuamos quedándonos rezagados. Véase el impacto de lo anterior:

Debido a que el avance tecnológico del hardware, del software y de las comunicaciones sigue siendo vertiginoso, resulta que, cuando apenas nos encontramos asimilando una etapa, ésta se vuelve obsoleta, y por eso no terminamos de empezar a utilizar una cosa cuando ya tenemos que iniciar el aprendizaje y el intento de utilizar una nueva. Esto demuestra que nuestra frágil preparación hace que tardemos demasiado para implantar un tipo de tecnología, desperdiciando gran parte del esfuerzo invertido y no aprovechando debidamente sus beneficios. Equivalencia: despilfarro.

Analizando lo anterior, podemos apreciar que el enfoque de rezago al que me he referido es real. Pero estimo que lo más costoso como consecuencia de nuestro atraso académico y cultural sobre esta tecnolo- gía se da en ese tremendo despilfarro computacional en el que nos hemos hundido y del cual no queremos salir.

Veamos con atención los tres grandes rezagos que he logrado identificar en nuestro ámbito informático, y encontremos e1 sentido que le doy a MI.

PRWR REZAGO: ADMIMSTRACI~N DE CENTROS DE C~MPUTO (ACC)

A mediados de la década de los sesenta, en México eran muy pocas las empresas que tenían una computadora para el proceso de sus datos. A esas alturas la ignorancia sobre los beneficios de esos equipos era casi total. Sólo en algunas dependencias del gobierno, como el Registro Federal de Causantes, el Seguro Social y otras, en algunas aseguradoras como Seguros Monterrey y otras, así como bancos, por ejemplo el de Comercio, Banco de México y otros, por la gran cantidad de datos con los que operaban, se hizo necesario que adquirieran computadoras; pero la gran mayoría de las empresas aún utilizaba equipo de registro directo. En aquellos años estaban de moda las computadoras IBM de la serie 1401 con tarjetas perforadas y memoria de anillos de ferrita, cuyas capacidades de memoria son difíciles de creer para los jóvenes de ahora.

En 1968 trabajé como operador de una 1401 con capacidad de memoria de 8 kB (1 kB = 1024 bytes), y dado que tenía una expansión de 3 U, el total era 11 kB. Había conectadas a ella una impresora de martillos de 300 líneas de 132 posiciones por minuto, una lectora de tar-


jetas perforadas de 1100 tarjetas por minuto y cuatro unidades de cinta magnética de 556 caracteres por pulgada de grabación. Esta computadora se programaba en lenguaje AUTOCODER. Con este "potente" equipo se llevaba el registro y control de los contribuyentes del país (algo así como tres millones de causantes) y todavía se daba apoyo a dependencias como el Registro Federal de Automóviles y otras. Por ese entonces también existían otras marcas de computadoras como Digital, Control Data, etc., con características más o menos similares. Pero aun yo, que ya me encontraba en el medio, así como una gran mayoría de mis colegas, creíamos que las verdaderas computadoras eran las de IBM (International Business Machines), debido a que en aquella época hablar de computadoras era sinónimo de IBM.

Recuerdo que en una ocasión acudí con varios compañeros a visitar una instalación en donde estaban por adquirir una computadora IBM 360-40, y debido a que en el Registro Federal de Causantes se estaba considerando la misma posibilidad, estábamos interesados en conocer de cerca los argumentos de selección de aquella instalación. Ya que los principales interesados de aquella reunión éramos nosotros, debimos llegar con casi 30 minutos de anticipación para no correr el riesgo de algún retraso, y queriendo aprovechar el tiempo, pedimos a uno de los colegas que trabajaba ahí que nos mostrara la sala de máquinas, quien con mucho gusto de inmediato nos condujo hacia ahí. Atravesamos un largo corredor y, debido a que todas las puertas de acceso eran iguales, cada una tenía un letrero discreto que indicaba la función del área correspondiente, pero sólo había una que tenía un vistoso letrero mucho mayor que el de las otras. A la que llegamos decía "Departamen- to IBM". Con cierto orgullo reflejado en su cara, aquel que nos guiaba nos mostró una enorme sala de máquinas de registro directo y de perforadoras de tarjetas, en donde además se aglutinaba probablemente un centenar de personas que las operaban. Hacia el fondo, en un cuarto acondicionado ex profeso, se encontraba una computadora. Se nos dijo que el cambio por el nuevo equipo de cómputo obedecía principalmente a que se requería desplazar el equipo de registro directo. Durante los casi 20 minutos que duró el recorrido, ninguno de los visitantes nos habíamos percatado de que tanto el equipo de registro directo como las perforadoras de tarjetas y la computadora no eran de la marca IBM, hasta que quien nos guiaba nos alertó diciéndonos que aquel departamento se consideraba el departamento de mayor importancia de la empresa, y que aunque el equipo no era IBM, el nombre del departamento se había definido así para que reflejara la importancia que merecía, ya que habían encontrado que era la forma en que el personal de otros departamentos lo identificaría jerárquicamente.

De este tamaño era la ignorancia que sobre los equipos de cómputo se tenía en aquellos años (1964-1970), y nótese que esto ocurría en las


propias empresas donde existia el centro de cómputo. Imagínese el lector lo que podían entender sobre este ambiente las personas comunes y corrientes. Recuerdo que algunos afortunados de la propia empresa que en algún momento habían tenido la oportunidad de estar dentro de la sala de máquinas y habían presenciado el funcionamiento y manejo de la computadora, provocaban hasta la envidia de otros compañeros que no habían tenido tal privilegio. Cuando yo era operador de la computadora en el Registro Federal de Causantes, fui testigo de interminables desfiles de funcionarios de todos los niveles que acu- dían a aquel lugar con ojos de asombro a ver lo que ahí sucedía: carretes de cinta girando en su unidad de un lado a otro sin que nadie los tocara, cientos de luces parpadeando, miles de tarjetas perforadas que eran "tragadas" por la lectora a velocidad impresionante (1100 tarjetas por minuto), y todo aquello sucedía en una fría temperatura de 14-18 OC en medio de un infernal ruido producido por los motores de enfria- miento y el descomunal golpeteo de los martillos de impresión, con la impresora jalando metros y metros de papel que de un lado entra- ba en blanco y por el otro salía lleno de letras y números estampados (300 ííneas de 132 posiciones por minuto). Esto era como estar (y no exagero) en el mismísimo año 2000: era como entrar en la máquina del tiempo y viajar en aquellos instantes al futuro. Sencillamente era un lugar mágico.

Pero no se piense que me he apartado del tema; por el contrario, quiero que el lector se entere de cómo sucedieron aquellas cosas y que fije su atención en las repercusiones que con el tiempo aquel profundo desconocimiento ocasionó. Esto que he comentado, aunque probablemente chusco, lo he querido mencionar porque si a mí, que lo viví (1968), en estas fechas me resulta difícil de concebir (han pasado más de 30 años), imagino qué pensará el estudiante de ahora, quien con lujo de comodidad en una notebook del tamaño de un libro transporta el poder de cómputo de varias veces lo que podían hacer computadoras de aquella época ubicadas en áreas de 60 m2.

Por lo anterior, el centro de cómputo resultaba impresionante, lo cual hizo que jerárquicamente, dentro de la organización, se le colocara en Fpa iqportante posición. Puedo decir que los más altos niveles de la organizaci8n utilizaban dicho centro como un reflejo de poder y de prestigio. Me tocó ver casos en los que funcionarios de otras organizaciones llegaban sumisos a pedir demostraciones de lo que ahí se hacía, yéndose después a tal grado impresionados que literalmente tenían que mirar de abajo hacia arriba a quienes tenían aquello en su poder.

Si bien había analistas de sistemas y programadores de la computadora, los que éramos operadores de la computadora teníamos la batuta, ya que con frecuencia aquellos nos tenían que rogar para que les permi- tiéramos probar sus programas. Resultaba curioso que a menudo nos


invitaban refrescos, dulces y cigarros, para congraciarse con nosotros y de esa manera mantener las mejores relaciones posibles, porque era seguro que en algún momento cercano esos obsequios serían correspon- didos con "tiempo-máquina". Lo que quiero decir es que tanto dentro del propio Registro Federal de Causantes como ante otras dependencias externas, el centro de cómputo era la imagen misma del poder, en cuanto que ahí se concentraba el proceso de datos de los modernos sistemas de información de aquella época.

Ahora no puedo menos que sonreír cuando recuerdo la frecuencia con la que se "caía el sistema" (se interrumpía el servicio de la computadora por una falla de la máquina o de los procesos); aquellos usuarios que se quedaban sin servicio materialmente se tenían que arrodillar para que les dijéramos en qué momento se iba a reanudar el servicio, motivo por e1 cual los operadores nos sentíamos sumamente importantes; y hasta con cierto desdén, si estábamos de humor, les dábamos alguna informa- ción, o de plano nos aprovechábamos, y de manera descortés les de- cíamos que no sabíamos para cuando, o para crearles mayor incomodi- dad, les comunicábamos que iba a tardar varios días, cuando a veces sólo le estaban dando a la computadora un mantenimiento de 30 minutos. En este tipo de situaciones, era frecuente que los operadores recibiéramos directamente llamadas de altos funcionarios para preguntarnos calmadamente si ya íbamos a "levantar el sistema".

Puede verse que la imagen del centro de cómputo tenía un significado sumamente especial. Pero se podrá ver también que el10 era consecuencia de la nula cultura computaciona1 que en aquellos tiempos se daba en todos los niveles. Esto hizo que el centro de cómputo se con- virtiera rápidamente en el termómetro (aparente) del nivel de auto- matización de una organización, y en no pocos casos en un argumento de orgullo para la institución propietaria.

A mediados de la década de los setenta, el centro de cómputo seguía atrayendo la atención de propios y extraños, y con la aparición en esa década de las modernas y potentes computadoras de la tercera genera- ción (capacidades de memoria de l a 4 megabytes), se habló de la necesidad de una novedosa actividad: la administración de los centros de cómputo. Se diseñaron cursos que enseñaban a llevar el control de la producción, la administración de los archivos de datos, las técnicas de seguridad de instalaciones físicas, el resguardo y recuperación de archivos, la recuperación en casos de desastre, etcétera.

Lo novedoso del tema hizo que muchas dependencias gubernamentales y privadas invirtieran fabulosas cantidades para capacitarse en estas actividades. Con el paso de los años, la novedad de aquel concep- to se desvaneció rápidamente hasta perderse casi en el olvido. Pero en septiembre de 1985, en México, el desastre que causó el terrible terremoto, muchas instalaciones fueron severamente dañadas y no


pocas quedaron bajo los escombros, llevándose consigo valiosísimos datos históricos ya no recuperables. Entonces nuevamente tuvieron un auge las estrategias para la protección y administración de los centros de cómputo. Pasados los años, podemos ver cómo existen centros de cómputo tan frágiles en aspectos de seguridad y operación como los de las décadas de los setenta y ochenta.

Es cierto que los modernos equipos de cómputo de la actualidad son altamente seguros y confiables, ya que su propio diseño considera esos aspectos, lo que minimiza considerablemente un caso de accidente, y la ubicación misma de las modernas instalaciones también disminuye los efectos que pudiera tener un desastre natural; pero aun así, son muy pocas las instalaciones que pueden decir que cuentan con alto nivel en la administración de su centro de cómputo. Las más, siguen al filo de la improvisación, y esto lo sabemos la mayoría de los informáticos.

Así pues, se verá que la administración de los centros de cómputo, no obstante su enorme importancia, nunca se logró consolidar, por lo que si nos atenemos a la definición de lo que significa rezago (atraso; suspender la ejecución de una cosa; quedarse atrás), es evidente que ahí quedamos rezagados sin la menor duda. Tan cierto es que quedamos rezagados, que todavía a estas alturas, muchas empresas (entre ellas la mía) siguen promoviendo seminarios y cursos enfocados a la administración de centros de cómputo, y soy testigo de que en la práctica, los conocimientos impartidos en dichos cursos casi nunca se consolidan.

SEGUNDO REZAGO: ADMLNISTRACI~N DEL ÁREA DE INFORMATICA (AAI)

Pese a que para la administración de los centros de cómputo en la mayoría de las instalaciones no se logró consolidar ninguna estrategia completa ni efectiva, actualmente se acepta que a ese respecto se sigue actuando de manera descuidada e improvisada.

Con el paso del tiempo (finales de los años setenta), con la puesta en marcha de las bases de datos, teleproceso, lenguajes de programación de cuarta generación y las supercomputadoras, de improviso surgieron los llamados sistemas integrales, cuyas posibilidades de acceso y proceso de datos superaron por mucho lo imaginable de aquella época. Para entonces, los centros de cómputo que en un momento se exhibían hacia la calle a través de gruesos y costosos cristales, ahora se les escondía en oscuros sótanos o elevados pisos fuera de la vista de la gente de la calle, argumentando esto como una medida de seguridad, aun cuando esto representaba también un enorme riesgo en caso de una inundación o temblor. Incluso algunos centros de cómputo han sido instalados fuera de la ciudad.

CAE 1. EL FACTOR AFI

Para entonces ya no se tuvo en el concepto de antes a los operadores de computadoras (como personas sumamente importantes por su especialidad); éstos quedaron relegados a segundo término. Dentro del esquema informático, entonces se les consideró de bajo nivel, con sueldos también bajos. Resultó que con las modernas técnicas de programación, bases de datos, sistemas operativos, diseño de sistemas, teleproceso, tecnología de las comunicaciones y otros, surgieron como por arte de magia nuevas especialidades: programadores de sistemas, administradores de bases de datos, administradores de espacios en discos, directores de proyectos, etc. Súbitamente el área de informática se expandió de manera vertiginosa. En las organizaciones ya no se habló como antes del centro de cómputo: ahora se referían al área de informática, y para destacarla, a ésta se le ubicó generalmente en el nivel de dirección dentro de la organización.

El área de informática creció desmesuradamente; los sueldos de los especialistas se fueron a las nubes, y hubo casos en que un gerente, por ejemplo de soporte técnico, ganaba lo mismo que un director de otra área, y que un programador de bases de datos ganaba lo que un gerente de una sucursal bancaria; también en que el área de informática en el nivel nacional se conformaba por 500, 600 o 1000 personas.

A finales de los años setenta, la fiebre en el desarrollo de sistemas de teleproceso y por lotes no tuvo precedentes. Las inversiones en hardware, software y capacitación especializada fueron de vértigo. La entrada de numerosas PC en los distintos departamentos de los usuarios y los planes de capacitación para éstos provocaron gastos superlativos, de tal suerte que el área de informática se estructuró apresuradamente y sin control. Su crecimiento resultó avasallador y, por consiguiente, el despilfarro fue atroz. Se gastaron fortunas en proyectos infructuosos o que resultaron de poca efectividad, por lo que muchos de ellos pronto fueron abandonados. En los proyectos que medianamente resultaron útiles, el costo fue desmesurado.

En 1980 inicié mis investigaciones sobre lo que denominé "los verdaderos problemas del ámbito computacional", queriendo decir con ello que vislumbraba un peligroso descontrol en el área de informática, aunque reconozco que en ese momento no sabía a ciencia cierta a qué se debía aquello. Pero intuía que algo grave estaba pasando.

Con el tiempo, me di cuenta de que la problemática detectada era producto de una total carencia administrativa dentro de esta área. Esto lo empecé a externar en varias conferencias, y ya sin la menor duda, basado en mis trabajos de asesoría, deduje que el área de informática no esta ba administra da.

Así es como fui madurando la idea de escribir un libro que contuvie- ra las bases en las cuales fundamentaba mi razonamiento, y en 1988 salió al mercado mi libro, que por un error se tituló Administración de

LOS TRES GRANDES RUAGOS 49

centros de cómputo, queriendo referirme no al centro de cómputo sino al área de informática. De inmediato atrajo la atención de colegas y estudiantes. De esta manera inicié mi lucha, y en mi calidad de asesor puedo demostrar una y otra vez la veracidad de mi afirmación, y cada vez se me unen más adeptos.

Para 1991 había decidido cambiar el titulo de mi libro por el de Administración del área de informática, sin embargo, me detuve porque empezaba a palpar que este segundo gran rezago ya comenzaba a quedarse aún más atrás, y me daba cuenta de que se avecinaba un tercero.

Aquí cabe preguntarse: ?cómo poder cubrir con tiempo el tercer rezago, si aún no hemos superado los dos prirnerost

Esto es verdaderamente para preocuparse, pues hay pruebas de que existe una gran distancia hacia la solución completa de este triste panorama. Basta ver cómo en la actualidad, en el nivel de universidades y tecnológicos, e incluso en carreras técnicas, existe la materia denominada administración de centros de cómputo, y cuando a los alumnos que la cursan les explico lo que es el centro de cómputo y lo que es el área de informática, y después les pregunto que a cuál de estas áreas se refieren en su materia, invariablemente me contestan que, visto así, es sin duda al área de informática. Entonces les pregunto que por qué se lIama así la materia, y me contestan que no lo saben, lo cual sé que es ab- solutamente cierto, porque si existiera una materia particular para la administración de centros de cómputo, con mayor razón debería haber otra para la administración del área de informática, y por supuesto que una más para la administración de la función informatica (AFI). ¡Qué complicado se está volviendo esto! Mejor analicemos mi propuesta sobre N I .

TERCER REZAGO: ~ M I N E T R A c I ~ N DE LA FUNCI~N INFoIUdTICA (MI)

Me resulta claro que el área de informática, en su estructura centralizada, ya no es funcional. Es evidente la impotencia de ese esquema ante los tremendos cambios organizacionales y de estrategias de negocio de las empresas actuales. La globalización mundial nos reclama mayores opciones de estrategias informáticas. Los conceptos tradicionales de negocio empiezan a desaparecer para dar lugar a modernos mecanismos comerciales y de senricio en cualquier rama. Obsérvese lo que se está logrando con las llamadas "supercarreteras de información". Internet ya no se utiliza sólo para el intercambio de información, sino también como un mecanismo para transacciones comerciales y de servicio. Por otro lado, el dinero como tal tiende a desaparecer para dar

50 CAP. 1. EL FACTOR AFI I

paso a la "tarjeta inteligente", y en lugar de las monedas y billetes lo que fluirá será sólo información. A distancia se ve que la informática resulta un arma poderosa para competir, y pienso que mejor sería decir para participar, ya que quien no esté integrado eficientemente en esta tecnología no sólo no podrá estar a la altura de la competencia, sino ni siquiera podrá participar en dicha competencia.

Hace algunos años, cuando el software o hardware fallaban, y esto originaba la suspensión del servicio inforrnático por un lapso de tiempo importante hacia las distintas unidades usuarias, repercutiendo incluso en los clientes, se tenían contemplados procedimientos de emergencia manuales, y de alguna manera se salía del apuro. Ahora, dados los enormes volúmenes de información que se deben manejar y la diversidad de tipos de transacciones, no es posible aplicar procedimientos de emergencia manuales, ya no digamos en empresas grandes y medianas, sino incluso en las pequeñas. Ésta es la razón de que muchas empresas cuenten con suficientes equipos de cómputo en distintas ubicaciones, conectados éstos a imagen de espejo y con sistemas de interruptores automáticos, para prever desastres que pudie an interrumpir permanentemente el servicio. Se puede ver cómo equeñas oficinas y hasta negocios, en caso de descompostura de su P k , en cuestión de minutos se pueden cambiar a otra computadora para continuar su trabajo.

Lo anterior demuestra que lo que antes se consideraba como un simple servicio de apoyo inforrnático para la operación fluida de las unidades usuarias, ahora resulta ser una función para la operación integral de las empresas. Si se suspende la función informática se paralizan automáticamente las demás funciones de la empresa. En la actualidad, una empresa en suspensión de funciones incluso puede paralizar algunas funciones de otras empresas que dependen de algún intercambio permanente de información.

El factor AFI lo mencioné por vez primera en 1993 en un seminario denominado "Administración de la Función Informática", como complemento de mi recomendación de que cuando menos lográramos la administración del área de informática. Más recientemente daría a conocer mi propuesta de descentralizar el área de informática y crear una división que planeara la estrategia informática viendo de arriba hacia abajo las necesidades reales de automatización de toda la organi- zación, analizando la hncionalidad dependiente de cada unidad usuaria (o negocio, como algunos la suelen llamar) en relación con sus requerimientos de información, con estricto apego al logro de los objetivos de negocio y servicio marcados por los más altos directivos de la empresa.

Si bien en este capítulo sólo me propuse explicar al lector lo que quiero decir con MI, me siento animado a llevarlo más allá, dándole incluso las premisas sobre un plan general d acción para implantar AFI dentro de una organización. i

SUGERENCIAS DE SOLUCIÓN

Antes de mencionar el plan de acción, es importante entender completamente el significado del término plan. El diccionario nos dice lo siguiente:

Plan: Conjunto de actividades propuestas con la finalidad de alcanzar objetivos o resultados previstos.

No se me tome a mal haber escrito la definición anterior, pues es muy probable que el lector ya la conociera. Pero deliberadamente quise llamar su atención con el fin de recalcar que un plan, aunque de una manera muy meditada, sólo propone actividades por desarrollar, lo cual implica que existe flexibilidad en todo momento para reorientar e incluso cambiar totalmente el rumbo propuesto si así lo dictan las circunstancias. Por ello, el plan que expondré es una propuesta con base en experiencias reales que han tenido éxito, pero queda a discreción del lector agregar, quitar o modificar actividades si lo juzga conveniente o necesario según su particular punto de vista, experiencia o medio en el que se desenvuelve. Lo que quiero subrayar es que un plan nunca debe ser estrictamente rígido, pues las condiciones en las cuales se planeó pudieran variar con el tiempo y obligar a la realización de cambios y ajustes. De hecho, el buen planificador se mantiene constantemente alerta a las variantes del medio y corrobora con frecuencia el impacto sobre el plan con e1 fin de establecer oportunamente las medidas correctivas.

He sido testigo infinidad de veces de casos en los que un plan, sobre todo a mediano y largo plazos, se ha "forzado" queriendo seguirlo estrictamente cuando éste ya no era del todo funcional en las condiciones vigentes; deseo que el mensaje se haya captado y se tome muy en cuenta.

En el plan general que expongo a continuación, desgloso los tres objetivos básicos en que está sustentado AFI.

Primer objetivo: Descentralizar el área de informática

La descentralización del área de informática no es algo que pueda entenderse como una simple reorganización del área de informática; es algo mucho más profundo que sólo modificar el organigrama (sin querer decir con eso que sea algo sumamente complejo). Además no es una decisión que pueda tomarse dentro del área de informática, aunque ahí es en donde deberá gestarse el impulso inicial.

CAF? 1. EL FACTOR AFI

En este momento quizá lo anterior parezca incómodo y probablemente le suene fuera de sentido al lector (sobre todo si ya es un informático activo), pues podría pensar lo siguiente: pero jcómo voy a participar como verdugo de mi propia áreat Descentralizar el área de informática no significa desaparecer esta área de la organización. Véase bien que lo que digo es que hay que descentralizarla, lo cual significa que todas las actividades vigentes del área de informática tendrán que seguir desarrollándose y evolucionando como hasta ahora, pero en el lugar donde éstas resulten de mayor provecho para la empresa y ubicadas de tal modo que el fenómeno del despilfarro computacional se abata.

Además, dada la importancia que actualmente tiene la informática para todas las organizaciones, afirmo que la modernización de las empresas estará dada en gran medida por la modernización del área mencionada. Pero, al mismo tiempo, es un salto obligado, necesario, que tarde o temprano tiene que darse, y que no debe posponerse hasta cuando el efecto de la competencia ya haya causado estragos difíciles de superar y mucho más costosos, como efecto de no haber tomado la decisión oportunamente.

No resultará fácil dar ese salto, y mucho menos cuando a primera vista lo que se vislumbra es el desmembramiento del área de informá- tica. No resultará sencillo para los informáticos prepararse mentalmente para comprender que ellos no serán desplazados, y que no se alterarán las jerarquías de los gerentes y directivos de esta área. Por el contrario, descentralizar esta área representará ubicarla en un contexto más amplio dentro de la empresa, e influirá con mayor vigor en los lugares estratégicos de la organización donde los beneficios de su aplicación podrán apreciarse como nunca en la historia de esta área, al fortalecer enormemente las actividades operativas, de control y de servicio. Abar- cará mayor campo de acción. Adquirirá mayor poder jerárquico en el nivel de la empresa; .no autoasignándoselo como se ha practicado hasta la fecha, sino porque éste le será reconocido como resultado de haberse diseminado los beneficios de las actividades informáticas en todas las áreas de la organización, y la importancia de ello se apreciará tangiblemente.

Entonces no será vista como un área riesgosa y peligrosa que vive aislada, fuera del control de la organización, sino como un mecanismo indispensable, firmemente administrado, que da servicio a toda la organización.

La empresa moderna necesita este nuevo enfoque informático de aplicación general, que no puede cubrirse con la actual estructura del área de informática, y mucho menos si permanece como una entidad aislada, independiente y autónoma. La función informática ahora se requiere en todas las partes de la organización.

Es conveniente que el lector tome en cuenta que los informáticos del país seremos requeridos con urgencia para emprender un supremo esfuerzo, y aquí es donde esto comienza a manifestarse.

Este primer salto reclama un esfuerzo tan grande, que obliga al informático a despojarse de esa mentalidad cerrada y viciada con la cual ha trabajado por años, y cambiarla por una mentalidad abierta capaz de emprender nuevas ideas, con la confianza que le dan su experiencia, conocimientos, sentido profesional y capacidad técnica, en vez del temor de perder una jerarquía que ya nadie le reconoce.

Pasos para efectuar la descentralización

Paso 1. Formación de un comité de política informática. Este comité debe estar estructurado por los directivos de las áreas que actualmente usan la información, producto del proceso electrónico de datos (usuarios) y por los directivos de los distintos departamentos del área de informática. Es requisito que los integrantes del comité estén preparados mentalmente para abordar un solo objetivo: descentralizar el área de informática de la empresa. Por esto, es necesario que cada integrante se vea a sí mismo como parte de un solo equipo de trabajo, es decir, en ese momento su mira estará dirigida hacia el logro del objetivo establecido y los conocimientos de cada uno se fusionarán (no competirán) para contribuir a la realización de dicho objetivo.

En este comité no hay jefe. Sólo existe un representante elegido por el mismo comité, cuya tarea final es presentar el estudio de descentra- lización del área de informática al mando mayor de la empresa.

Paso 2. Análisis de la situación actual del área de informática. El comité procederá a realizar un estudio detallado de la situación particular del área de informática, mediante la evaluación sincera y realista de lo que la empresa requiere de dicha área y lo que ésta está dando verdaderamente. Una manera práctica de conocer lo anterior es evaluar los resultados que emite el área de informática y ver si cubren los requerimientos de información de los distintos departamentos usuarios. Es de vital importancia profundizar en lo que esta área le cuesta a la empresa para así tener una idea más clara de la efectividad del área en com- paración con su costo.

Al participar en esta autocrítica, es importante que los directivos del área de informática no se sientan como "verdugos" de su propia área; esto sólo demostraría falta de confianza y poca honestidad. Por el contrario, cuanto más severa sea dicha autocrítica, mayor será el beneficio al establecer el remedio. Ellos deberán estar conscientes de que Ia situación tan desastrosa que se vive dentro del área de informática es consecuencia y resultado del arraigo de vicios y desorden no desde hace


algunos años o lustros, sino desde los mismos albores de la informática en México. ¡Qué gran oportunidad se les presenta!: Ellos serán partícipes del rompimiento urgente y necesario de tanto tiempo de hábitos dañinos y costosos; ellos serán los arquitectos de una nueva etapa histórica para la informática del país; ellos pondrán los cimientos para emprender la renovación informática reclamada con urgencia por el proceso de mo- dernización de las empresas actuales; ellos estarán en vías de preparar el terreno para iniciar el cambio que hasta la fecha nadie se ha atrevido a emprender, no porque no se sepa que es vital hacerlo, sino porque existe miedo y falta de confianza, avalado esto por el deterioro del medio informático, y porque muchos no se han dado cuenta de que este proceder sólo conduce al hundimiento progresivo del área de informática; en consecuencia, se vuelve peligrosamente vulnerable la propia empresa. Llegará el momento en que las evidencias sean tan claras que los empresarios reclamarán con toda justicia a los informáticos el no haber actuado a tiempo, y se lamentarán por haber puesto su confianza en ellos.

Cuando se vaya a hacer la autocrítica del área de informática, sus directivos deberán pensar seriamente en lo anterior, y se verá que una participación honesta y decidida no quiere decir una "desvalorización" del informático; por el contrario, esto demostrará una actitud de madurez y crecimiento, la cual estará reflejando que se ha adquirido conciencia de que el área de informática está padeciendo una grave crisis, la cual ellos están dispuestos a enfrentar con decisión y confianza de superarla.

Paso 3. Análisis de las ventajas que traerá la descentralización del área de infomática. Ya en este paso deberá tener la idea clara de1 deterioro del área de informática, así como del elevado costo generado por el despilfarro computacional, y en consecuencia la medida, aunque teórica, de la distancia que habrá que recorrer para contar con la infraestructura informática para satisfacer los requerimientos de infor- mación de una empresa en proceso de modernización. De este modo resultará factible conocer con mayor rapidez los beneficios que se espera obtener al descentralizar dicha área, partiendo de la suposición de que ella ampliará el campo de aprovechamiento de los sistemas de información dentro de la organización, así como la tendencia hacia el abatimiento del despilfarro computacional (véase cuadro 1.1).

Paso 4. Visualización de la organización total de la empresa porme- dio del enfoque de unidades usuarias. Este aspecto es vital para conocer bajo qué esquema se procederá a descentralizar el área de informática.

Una unidad usuaria se define como una entidad, dentro de la organización, que cubre una función completa y que actúa con autono- mía operativa para lograr sus propios objetivos.

Lo anterior no implica necesariamente reorganizar la empresa, aunque presumo que la gran mayoría de las empresas, durante su proceso de modernización, afectarán de algún modo su esquema orga-

Cuadro 1.1. Cuadro comparativo de las ventajas que representa el área de informática descentralizada con respecto a la centralizada

Area áe informática áescentraüzada

Ven tajas

Racionalización del uso de los recursos de cómputo

Análisis detallado del costo-beneficio de las inversiones en los proyectos de informática

Satisfacción de las verdaderas necesidades de información de las unidades usuarias

Efectivo direccionamiento de la reingeniería de los sistemas de información

Posibilidades reales y costeables para establecer una cultura informática en el nivel de la empresa

Capacidad informática para adaptarse rápidamente a las variantes de los negocios y objetivos de la empresa

Verdadero apoyo informático al plan de modernización de la empresa y su crecimiento futuro

Verdadero enfoque de la informática como un arma estratégica de competencia de la empresa

Area de informática centr*

Desventajas

Despilfarro computacional

No existen

Muchos sistemas improvisados que no cubren plenamente las necesidades de información de los usuarios

Confusión y descontrol

Pocas posibilidades para el logro de la cultura informática de la empresa y demasiado desperdicio de esfuerzo y dinero

Imposibilidad absoluta de adaptación

Insuficiencia de apoyo para el plan de modernización de la empresa

Tendencia al rezago como una estrategia de competencia para la empresa

CAP 1. EL FACTOR AFI

nizacional, por io que sería benéfico que esto se hiciera por medio del enfoque de unidades usuarias. Esto significaría un enorme avance al hacer que las actividades de la organización se vayan agrupando mediante sistemas completos, lo que en otras palabras quiere decir "pensar en términos de sistemas de información".

Paso 5. Esquematización de la hnción informática a través de las distintas unidades usuarias. Al visualizar a la organización con la estructura de unidades usuarias, se facilita la determinación de los verdaderos requerimientos de información para la efectiva operatividad de cada unidad usuaria, y en consecuencia se podrán determinar tam- bién los requerimientos de cómputo (humanos y materiales) convenientes para cubrir completamente dichas necesidades de información. De esta manera cada unidad usuaria tendrá el servicio directo de una gerencia de informática, la cual a su vez estará administrada y controIa- da por el área administrativa de la función informática de la empresa. La idea es que cada unidad usuaria cuente con un potencial informático inmediato capaz de satisfacer sus más rigurosos requerimientos de información sin necesidad de tener que pasar por laboriosos y tardados procesos burocráticos para llegar a un área de informática centralizada, como ocurre hoy día. Otra ventaja que se observa es que este esquema será capaz de adaptarse rápidamente a las condiciones variantes de cada unidad, porque cada informático asignado será un especialista en los sistemas propios de dicha unidad. Finalmente, los usuarios podrán ser los propios responsables del diseño, automatización y eficiencia de sus sistemas de información, lo que en otros términos significa ser los dueños absolutos de sistemas creados con la exactitud y flexibilidad que ellos determinen, partiendo de la base de que ellos son quienes conocen con acierto los datos de que disponen y los requerimientos precisos de información necesarios para hacer de sus actividades procesos operativos, administrativos y de servicio altamente productivos. Por otro lado, los informáticos serán los especialistas que harán realidad la automatización de los sistemas concebidos por los propios usuarios, bajo la norma de que dicha automatización será orientada para mantener siempre un alto grado de servicio (véase fig. 1.1).

Paso 6. Exposición ante los directivos de la empresa de los argumentos ventajosos que implica la descentralización del área de rnformática con el fin de obtener su aprobación. El comité de política informática ya cuenta en este momento con todos los argumentos necesarios para lograr que los niveles superiores de la empresa tomen la decisión en favor de la descentralización del área en cuestión. Las pruebas que demuestran las enormes ventajas que traerá dicha descentralización son más que suficientes para obtener la aprobación de tal planteamiento. De todos modos, resultará necesario interesar y advertir a los empresa-

Ubica~Yón ~rodicional del ¿reo de imformtíllPCo de la oganizacibn

Ubicoeibn aaual del (Zrea de infa~mtítica bajo el concwo de AFI dentro de la onganización

Figura 1.11. !!&me que la estrUdUra del enhque de dienteaservidor bajo el cancepto de ~ e d prádcamente se qju- a este esquema.

CAP. 1. EL FACTOR AFI

rios del grave perjuicio que se está gestando dentro del entorno de la modernización de la empresa, al no emprender al mismo tiempo la mo- dernización del área de informática.

Paso 7. Inicio de la Administración de la Función Informática (AFI) de la empresa. Se sugiere que este proceso sea paulatino, primero con una unidad usuaria, luego con otra, y así sucesivamente.

Por supuesto que todo cambio propicia infinidad de rumores entre el personal. Claro que en este caso habrá rumores y hasta la posibilidad de algunas renuncias o despidos; pero, no hay que preocuparse demasiado por este efecto, pues de cualquier manera esta situación se generará durante el proceso de modernización de la empresa, y la implantación de AFI es parte de tal proceso; incluso será mejor que tal situación se efectúe dentro del marco de la modernización misma. Pero, es recomendable que los directivos del área de informática minimicen el impacto de tales rumores, sobre todo cuando éstos desvirtúan los hechos con el solo fin de causar algún daño. Esto pueden lograrlo mediante una campaña de promoción, dentro de la empresa, con base en las ventajas personales y empresariales que traerá dicha implanta- ción, y aún más para los propios informáticos.

p. 1, *egundo objetivo: Formar un mecanismo

para la administración global del entorno inforrnático de la empresa

Ya hablé sobre cómo se fue formando el área de informática a través del tiempo. Es evidente que esta área se fue estructurando por etapas de una manera por demás improvisada, y que, con los años, de un modesto departamento insignificante se convirtió en una de las áreas más grandes y de mayor jerarquía dentro de las organizaciones. Encontré que los cambios de estructura en dicha área fueron tan frecuentes, que poco a poco dentro de una organización (la de la empresa) nació otra organiza- ción (la del área de informática).

Dichos cambios sucedieron con tal rapidez que, sin que nadie se lo propusiera, se perdió de vista la enorme dependencia que de esta área comenzaron a tener prácticamente todas las demás áreas de la empresa. Cuando los informáticos de pronto se dieron cuenta de tal situación, y confiados en lo vulnerable que era la empresa sin el apoyo de1 proceso electrónico de datos, cerraron filas como quien quiere apoderarse del control de la organización, y convirtieron sus actividades en un tabú intocable que sólo ellos entendían y podían manejar a su libre antojo. Ello propició el aislamiento de dicha área, en cuyos dominios nadie más podía entrar. Dentro de esa área, los informáticos hicieron lo que les

vino en gana sin tomar en cuenta cómo repercutiría esto en los múltiples usuarios; se organizaron internamente como quisieron, sin importar que se perdiera el aspecto administrativo informático, y si no tenían idea de cómo organizarse, resultó fácil copiar los esquemas de otras empresas, sin darse cuenta de que ahí también carecían de ese aspecto administrativo; utilizaron la centralización y el proceso electrónico de datos que ellos operaban como un arma para hacerse de poder, sosteni- do éste por la ignorancia que de esta tecnología tenían los usuarios; hicieron de sus actividades un "feudo" que sólo ellos podían entender y manejar.

Tal situación se sostuvo por décadas. Sencillamente, el contexto informático de la empresa siempre funcionó como una "maraña" de actividades desordenadas en donde reinó ampliamente la baja productividad. Pero, iquién podía poner freno a este atroz despilfarro{ Nadie, porque nadie ajeno a esta área conocía a ciencia cierta lo que acontecía dentro de esa "fortaleza".

Ya mencioné el tremendo desorden que siempre ha privado y que hasta la Fecha prevalece dentro del área de informática. También demostré el severo despilfarro que ahí se sigue cometiendo. Además comprobé con lujo de detalles, que la función informática de las empresas jamás ha estado administrada ni lo está en la actualidad. Asimismo, también afirmé que esta situación ya resultaba insostenible, y entreveo que si los directivos del área de informática no emprenden cambios significativos y congruentes con las necesidades administrativas de las empresas actuales, y si no modernizan esta área en correspondencia con el nivel de modernización que persiguen en el mediano plazo tales empresas, se enfrentarán a problemas cada vez más complejos que no podrán afrontar si no se preparan con tiempo, y tarde o temprano comenzarán a caer cabezas. Por el contrario, si emprenden cambios de rigor ahora, como los que promuevo en la presente obra, habrá tiempo suficiente para coincidir en el momento en que surjan los requerimientos de sistemas de información modernos, obligados por el proceso de modernización de las empresas.

Es importante que los directivos del área de informática reconozcan que en la actualidad el "analfabetismo computacional" ya no es tan grande como hace cinco o 10 años, pues ahora la gran mayoría de empresarios, por iniciativa propia o a través de sus asesores, saben de la importancia de esta tecnología y de la dependencia casi obligada que de ella tiene toda empresa sin importar su tamaño. Asimismo, los directores y gerentes de las distintas unidades usuarias día con día se preparan mejor para explotar con mayor eficacia la informática, en provecho de sus actividades operativas, administrativas y de control.

Lo anterior empezará a ejercer una tremenda presión (y actualmente ya hay indicios) sobre el área de informática, que de acuerdo con las


expectativas a corto plazo, ni remotamente podrá enfrentar y, repito, comenzarán a caer cabezas.

Pues bien, los pasos que sugiero para formar un mecanismo de administración para el entorno informático global de la empresa son los que expongo a continuación:

Pasos para formar un mecanismo de administración

Paso 1. Contar con la estructura descentralizada del área de informática. En este momento el comité de política informática ha diseñado, presentado y conseguido la autorización para lo que será el área de informática descentralizada. Por tanto, ya se tiene bien clara la ubicación de cada unidad usuaria dentro del esquema organizacional de la empresa, así como el alcance y el tipo de apoyo técnico-informática que tendrá cada una de ellas.

De lo anterior se debe comprender que el soporte técnico (que en este momento se esquematiza dentro de la estructura descentralizada del área de informática) se refiere únicamente al personal informático que quedará asignado a cada unidad usuaria. Por elío, no pretenda ahora determinar el equipo de cómputo con el cual quedará sustentada la participación de cada unidad dentro del entorno de modernización de la empresa, ya que este aspecto deberá ser uno de los primeros trabajos que realizará dicho personal informático asignado, y deberá hacerse rigurosamente en función de los requerimientos estrictos de quienes ahora dictarán lo que necesitan, cómo lo necesitan y la estrategia de cómo se hará; es decir, en adelante todo será desarrollado bajo responsabilidad y dirección de los gerentes que comandan las distintas unidades usuarias.

Pues bien, por el momento se destaca que para estar en posibilidades de formar el mecanismo administrador de la función domát ica de la empresa, es requisito contar con el esquema de la estructura descentralizada del área de informática. Este es el primer paso según el plan.

Paso 2. Constituir el área administradora de la función informática de la empresa. Ningún área que no se encuentre lo suficientemente administrada como para su correcta operación, podrá funcionar según fue concebida dentro de la organización.

Aunque durante mucho tiempo se creyó que la Revolución Indus- trial tuvo su éxito con el invento de las máquinas que eran capaces de producir enormes cantidades de artículos en serie, con muy poco o nulo esfuerzo humano, al paso del tiempo se descubrió que tal éxito no sólo se encontraba en el uso de dichas máquinas, sino que sin los métodos administrativos y de control, semejante producción de artículos sp

hubiera convertido en un caos: control de la producción, cantidades requeridas de materia prima, rutas, tiempos de envío y entrega de artículos, estándares de calidad, manuales de operación de la maquinaria, programación de servicio de mantenimiento del equipo, control de inventarios, etc. Sin este contexto administrativo, ya podemos imaginar el tremendo desquiciamiento que hubiera acontecido.

Con el paso de los años se fueron estructurando grandes empresas. Así h e como los mecanismos administrativos que en un principio se establecieron, fueron rebasados por las expectativas iniciales de crecimiento, por lo que fue necesario ajustarlos frecuentemente, hasta que con el tiempo su evolución los hizo tan complejos que resultó urgente la formación de profesionales en administración de empresas, capaces de tomar control sobre ellos y hacerlos eficientes y útiles.

En el ámbito inforrnático aconteció algo parecido a los sucesos de la época de la Revolución Industrial: se diseñaron equipos electrónicos capaces de producir información a velocidad vertiginosa y en cantidades colosales, pero, a diferencia de las estrategias administrativas implantadas para controlar la producción en masa que surgía de las máquinas de aquel tiempo, en la época informática no se hizo lo mismo, y prueba de ello es que aun hoy día no existe ninguna carrera profesional específica para administrar, de manera global, el contexto in- formático de las empresas. Desafortunadamente, ese hecho no quiere decir que la necesidad administrativa informática no exista; por el contrario, el fenómeno del despilfarro computacional, del que aquí tanto he hecho mención, es sin duda producto de semejante carencia administrativa. Pero el agravamiento paulatino que se ha dado con el tiempo en el sentido del bajo nivel de calidad en el servicio informático es mayor evidencia de ello.

Por lo anterior, junto con la descentralización del área de informáti- ca resulta indispensable la estructuración del área administradora de la función informática.

Sin duda, este mecanismo administrador es el elemento fundamental que hará posible la modernización informática a que he hecho mención en repetidas ocasiones. En él estará sustentada también la estrategia de modernización de las empresas. Por el momento, sólo recalcaré la enorme importancia que representará contar con esta área administradora.

Paso 3. Adoptar un modelo de aprendizaje por seguimiento como función. Las actividades del área de informática son quizá las actividades administrativas más artesanales que existen dentro de las empresas. Cuando digo "artesanales" me refiero a que el cuidado y precisión con que deben llevarse a cabo dichas actividades deben ser sumamente finos.

La inmensa cantidad de errores que se cometen dentro del área de informática se debe a que un pequeñísimo detalle se pasó por alto, o

62 CAP 1. EL FACTOR AFI

más bien no se respetó. Nos resulta gracioso cuando escuchamos definiciones hechas a lo largo de nuestra historia informática sobre lo que es una computadora. Una que ilustra perfectamente lo que mencio- né acerca de la labor "artesanal" dice lo siguiente: "Una computadora es una máquina que convierte los pequeños errores en grandes desastres." Y icuánta verdad hay en esto!, si consideramos lo que nuestra improvi- sación informática nos ha costado en descuidos por la falta de adminis- tración. Por ello es necesaria una observación continua, además de constantes ajustes en los métodos de trabajo de dicha área, con el fin de capitalizar experiencias que permitan aprender de los errores, además de poder conocer con acierto por qué se están cometiendo tales errores. Pero se vuelve más importante ser capaces de establecer controles para evitar incurrir una y otra vez en los mismos errores, como ocurre y ha ocurrido por años, lo que en otras palabras significa aprender a controlar los errores partiendo de la capitalización de las experiencias y tender a erradicar su aparición repetida.

Al paso de los años he comprobado que en el área de informática, pese a lo ya dicho respecto de la labor artesanal que ahí se realiza, se trabaja con un enome descuido, lo que obviamente se manifiesta en la cantidad incontrolable de problemas que se viven a diario. Aun así, casi por norma dichos problemas se atacan con una visión de "urgencia" que hace que no se analicen las verdaderas razones que los originaron y, por 10 mismo, jamás se hace énfasis en dejar establecida una estrategia de control que evite la nueva aparición de los mismos problemas. Con esa actitud no es posible aprender de las experiencias, y se podría decir que se hace un seguimiento para la solución de los problemas solamente por excepción, es decir, sólo mientras duran las consecuencias de los problemas, pero una vez pasada la presión, todo queda en el olvido, sin querer darse cuenta, quienes actúan así, de que con ello se van perdiendo oportunidades de aprender a controlar los errores que condujeron a tales problemas.

La solución a lo anterior, comprobada por mí y por muchos de mis colegas, está dada en algo que descubrí y que he denominado Modelo de aprendizaje por seguimiento como £unción, cuyo antídoto básico contra los errores reiterados está dado por un seguimiento permanente. Así, para fortalecer el mecanismo de administración global dormático de la empresa, se vuelve necesario adoptar dicho modelo (véase fi

Tercer objetivo: Crear una cultura informática en el nivel de empresa

En la actualidad, prácticamente no existe una publicación (revista, periódico, libro, etc.) que de algún modo no contenga artículos que se ocupen en forma particular de la aplicación de las computadoras, sistemas de información, teleproceso, toma de decisiones con base en computadora, bancos de datos y muchos otros temas del ámbito informático. Por otro lado, casi a diario aparecen anuncios promoviendo seminarios y cursos sobre informática orientados a los gerentes y directivos de las empresas. Asimismo, se ofrecen un sinnúmero de paquetes de software destinados a la alta gerencia, cuya operación reclama un mínimo de conocimientos sobre computación por parte del usuario. Y en lo que respecta a cursos relámpago dirigidos a personal operativo y secretarial, éstos son ofrecidos prácticamente por cualquier instituto o escuela.

Lo anterior indica que estamos viviendo algo que, sin exagerar, se podría llamar la "Revolución Informática" (por analogía con la Revolu- ción Industrial). Dicha revolución informática está transformando radi- calmente la actual manera de trabajar de la gente. La tecnología de la informática ha llegado a adquirir tal importancia que materialmente nos ha hecho prisioneros, dada la dependencia a que hemos llegado respec- to de estos equipos y hemos llegado a depender tanto que ya empieza a ser familiar el uso del término analfabetismo computacional para distinguir una persona que sabe usar la computadora de otra que no lo sabe. Así, hoy día la incapacidad de leer y escribir determina el analfabetismo, y una persona letrada es aquella que puede realizar ambas Funciones. En sólo unos años más, una persona letrada deberá poder leer, escribir y utilizar con soltura las computadoras.

1 ' A Sin embargo, en las empresas no se ha logrado dar ese gran cambio; ' Si bien se han hecho intentos por capacitar al personal gerencia1 y administrativo en el uso de las computadoras personales, puede afirmarse que no se ha sabido orientar dicho esFuerzo, y el resultado es que a quienes así se ha capacitado, normalmente llegan a hacer de la computadora un uso poco provechoso. La experiencia ha demostrado que no basta con darles cursos aislados e improvisados, dicha capacitación deberá ser formal y planeada de acuerdo con las actividades de cada área, dirigién- dola firmemente hacia la resolución de los problemas cotidianos que enhenta cada una. Para planear esta capacitación, debe considerar no sólo el uso de paquetes de software bajo control de computadoras personales, sino que habrá que conjugar los siguientes aspectos: adminis- tración, información, toma de decisiones, equipo de cómputo y paquete- ría de software. Sólo de esta manera se podrá decir que se está en di- rección a la creación de una cultura informática en el nivel de empresa.

He comprobado que se habla intensamente sobre la modernización de las empresas, además se afirma que dicha modernización no se podrá dar sin el enfoque de la productividad. Ha sido mencionado por todo tipo de políticos y empresarios, y a través de todos los medios de comunicación posibles, que es impostergable elevar el nivel productivo de los empleados y trabajadores con el fin de sanear la deteriorada eco- nomía de las empresas y volverlas más competitivas. Sin embargo, muy a mi pesar, poco o casi nada se ha dicho de la importancia de la in- formática para lograr tales propósitos. Me atrevo a afirmar que este hecho no es producto de la casualidad; la verdad sea dicha, es que en nuestro país todavía no existe algo que pueda calificarse como cultura informática, y más bien lo que existe es un amplio analfabetismo computacional. Por ello, no se ha tomado conciencia de la enorme importancia que representa el aspecto informática dentro de las estrategias de modernización de las empresas, sencillamente, una gran mayo- ría de los empresarios, políticos y funcionarios desconocen su verdadero potencial. Pero esto no cambia en nada la realidad, o sea: se quiera o no, la creación de una cultura informática en el nivel de las empresas es el arma más poderosa con que pueden contar éstas para sustentar firmemente su modernización y, en consecuencia, para afianzar su nivel competitivo. Es imprescindible que desde los niveles de menor jerarquía hasta los directivos, a las personas se les enseñe a pensar en términos de sistemas, con el fin de que se comprenda con toda claridad lo siguiente: toda actividad operativa, administrativa y de control que se realice en cualquier parte de la empresa, no se encuentra aislada, sino que forma parte de un mecanismo completo mucho más amplio que el solo entorno de una oficina o departamento; o sea, que cada sistema dentro de la empresa entrelaza las actividades de varios departamentos que en conjunto satisfacen un proceso completo vital en el cuerpo de la organización.

En la actualidad ya no basta con que el personal de una empresa esté capacitado en una sola especialidad administrativa, funcional u operativa, como pudiera ser en mercadotecnia, ingeniería, mecánica, publicidad, control de calidad, etc.; tampoco es suficiente con que la gente entienda superficiahente el concepto de planeación, la importancia del trabajo en equipo y la necesidad del control. Por sobre todas estas cosas, para su funcionamiento armónico y oportuno, una empresa se vale en todo momento y lugar de los beneficios de la información actualizada; o sea, una empresa necesariamente debe estar informada.

Ante sus clientes, una empresa está representada por la calidad de su servicio, y precisamente este aspecto estará dado en la medida en que la empresa se encuentre informada; informada de qué es lo que sus clientes esperan de los productos, qué es lo que en realidad se les está dando, en qué medida se están satisfaciendo sus necesidades, qué más necesitan los clientes, etc. En la medida en que la empresa pueda


contestar verazmente este tipo de planteamientos, valiéndose del proceso de la información con la que cuente, será posible activar oportunamente sus mecanismos operativos para satisfacer los requerimientos exigidos por los clientes.

Con el fin de crear una cultura informática en el nivel de empresa, propongo dar los siguientes pasos:

Pasos para crear una cultura informática

Paso 1. Realizar un análisis de requerimientos de información dentro de cada unidad usuaria. Primero debe comenzar por darse cuenta y tener la fume idea de que esto no será fácil ni rápido, ya que im lica I implantar una formación cultural informática que nunca ha existi o ni existe actualmente. Es vital comprender para este propósito que esto obliga a fomentar un cambio de mentalidad en todo el personal de la organización, sin importar su nivel jerárquico, con el objetivo de lograr en ellos un cambio radical hacia perfiles nuevos en sus hábitos de trabajo, empezando por cambiar la imagen misma de la manera de hacer las cosas y del concepto en que tienen las herramientas que han usado, y buscando una filosofia moderna en el entorno de los sistemas de información y los nuevos equipos que tienen a su disposición, para volverse más productivos partiendo de la aportación de su ingenio y de su creatividad y no del trabajo rutinario y agotador de costumbre. Dicho aspecto equivale a despojar mentalmente a los empleados de sus métodos tradicionales de trabajo y convertirlos en una nueva genera- ción de individuos, cuyo sentido del deber ante la empresa los ubique claramente en una época orientada a la calidad en el servicio, basada Fuertemente en los sistemas de información como principal vehículo para una eficiente atención a los clientes. Reitero que no será sencillo, pues es bien sabido que si hay algo difícil de hacer, es precisamente cambiar los hábitos de la gente; pero también es cierto que modernizar una empresa exige cambiar la manera de hacer las cosas, desde las más complejas hasta las más insignificantes, o también sea dicho en otras palabras más de moda: hacer reingenieni. $NO se ha puesto a pensar lo que estarán tratando de hacer aquellas empresas en las que una elegante edecán con toda su capacitación especializada simplemente lo espera con paciencia, y con mucha cortesía le pregunta a qué piso desea subirt Esto, en palabras llanas, está expresando competencia. Pues si lo anterior, así de sencillo, resulta importante para dichas empresas, ahora piense: $Qué habría que hacer que valga la pena en una organización para crear una cultura informática como punta de lanza para volver competitiva a una empresat No hay alternativa: habrá que cambiar la manera de hacer Ias cosas. Pero demos eracias a aue tenemos a nuestra

entera disposición los instrumentos para hacerlo: los sistemas de d o r - mación y las computadoras.

Pero no nos desanimemos, pues para hacer ágil y certero (no sencilIo) este proceso, precisamente está planeado este paso; hacer un riguroso análisis de requerimientos de información en cada unidad usuaria, por parte de los propios gerentes de cada área, permitirá a éstos detectar por sí mismos la imperiosa necesidad que tienen sus respectivas áreas en relación con el proceso de datos, y captarán perfectamente lo dependiente que son sus labores de la información producto de dicho proceso. En este momento lo importante es que sean precisamente ellos los que participen en este análisis. De esta manera, podrán ver con toda claridad que la solución a la mayoría de sus problemas operativos depende del abastecimiento oportuno de toda esa información. Serán los más convencidos de que si quieren alcanzar cabalmente sus objetivos en las distintas unidades usuarias, esto depende de la precisión con que determinen sus necesidades de información, pero ellos y no terceras personas. Ésta es la clave; al quedar ellos inmersos dentro del contexto inforrnático de la empresa, no podrán menos que comprender que la formación cultural informática no es sólo un producto de trabajo más; tampoco es una "cultura de relleno" como se ha considerado cotidianamente. Es una estrategia moderna de trabajo tan necesaria y poderosa que no se puede prescindir de ella sin poner en riesgo el control de la empresa entera. Con este panorama, seguramente no podrán pasar por alto que ellos son los pilares para la estructuración de los sistemas de información, por lo cual dicha cultura informática se vuelve obligada y refleja una necesidad de primer orden.

Paso 2. Efectuar una campaña de creación de conciencia infomá- tica. Cuando se habla de crear conciencia en las personas, por lo general se relaciona con la manipulación de la gente, y efectivamente hay mucho de cierto en ello; esto dificulta mucho la creación de dicha conciencia, ya que conciliar los intereses de los humanos quizá sea una de las actividades más difíciles de lograr, y peor aún cuando se intenta generar cambios en las actitudes. La naturaleza misma de las personas ofrece resistencia al cambio.

Es imperativo destacar que en nuestro caso el enfoque para lograr la creación de conciencia es distinto, pues se parte de una base sólida que hace que dicha creación de conciencia surja por sí sola cuando los usuarios se convenzan de que, para el trabajo que ellos realizan, es necesario contar con un método moderno de trabajo que dé vigor a la vida operativa de las unidades usuarias. Pero lo que verdaderamente resulta de valor en este enfoque es que toda esta estrategia de cambio forma parte de un mecanismo necesario para modernizar a las empresas, o mejor dicho, que esta nueva manera de pensar respecto del trabajo es un requisito para emprender dicha modernización. Recuérde-


se que toda la actividad de cualquier organización gira en tomo a la eficiencia con que las personas realizan sus operaciones de trabajo, o sea, que el activo de mayor valor para cualquier empresa es su propio personal.

Para lograr una cultura informática en el nivel de empresa, uno de los pasos que hay que dar consiste en realizar un análisis certero de los requerimientos de información dentro de cada unidad usuaria. Esto por sí solo provocará un inicio de creación de conciencia en el nivel de los gerentes de cada área, quienes podrán ver con toda claridad que para contar oportunamente con tan importante información para el mejor

I funcionamiento de las distintas entidades operativas que ellos comandan, tendrán que valerse necesariamente de los servicios que les proporciona la informática y, por consiguiente, ellos son los primeros en estar conscientes de que el personal a su cargo y ellos mismos deben entender y participar en e1 manejo de dicha tecnología.

Lo anterior demuestra que la creación de conciencia propuesta se puede hacer mediante una estrategia de "reacción en cadena": primero se atrae el interés de la alta gerencia convenciéndola de que está a su alcance la información que ellos deseen, siempre y cuando participen activamente en su consecución haciéndose verdaderamente responsables de los sistemas de información que se implanten; después, como resultado de lo anterior, saltará a la vista que la capacitación de ellos y de su personal para operar sus mecanismos administrativos apoyados en la tecnología de la informática es inminente y prioritaria. Ellos sabrán que su participación en este entorno, a partir de ahora, es parte de su estrategia de trabajo; en consecuencia, y partiendo de la base de que cada unidad usuaria tendrá a su disposición expertos en informá- tica y equipo de cómputo propio (computadoras personales y redes) para sus requerimientos de información locales, y un centro de cómputo dotado de computadoras de alto poder para los sistemas de información medulares e institucionales, sabrán que forman parte importante del equipo de trabajo de la estrategia informática de la empresa, y no como antes, cuando eran simples espectadores de lo que buenamente les diera el área de informática. Ellos ahora sabrán que adquieren responsabilidad vital para el logro de los objetivos informáticos de su área de acción y, en consecuencia, de la empresa, a cambio de contar con sistemas de información de mucho mayor calidad que los logrados con las viejas estructuras. Serán conscientes que los informáticos y el equipo de cómputo son sus aliados para la consecución de los objetivos de au- tomatización determinados por el análisis de sus propias estructuras operativas y los intereses mismos de servicio y de negocio de la empresa, es decir, la informática será comprendida como una estrategia más de servicio y de competitividad para beneficio de la empresa y sus clientes, en la cual el usuario y el informático conjugan sus especialidades. Por lo anterior, el proceso de cultura informática en el nivel de empresa

será una consecuencia misma del proceso de descentralización del área de informática.

Entonces, lo anterior no será trivial y poco prioritario como ha sucedido hasta ahora con el concepto mal entendido de capacitación a los usuarios. Tampoco se podrá elegir si se emprende la cultura informá- tica de la empresa o no: jserá necesario! Esto hará que tal propósito se cumpla cabalmente.

La campaña de creación de conciencia informática será una necesidad obligada cuando la alta gerencia tome el control del destino informático de la empresa, y los informáticos asuman su verdadera responsabilidad dentro de este objetivo.

Pero salta a la vista que, dadas las condiciones actuales del esquema informático caduco de la mayoría de las empresas, el proceso de creación de conciencia informática al que hemos hecho referencia será mucho más potente, rápido y efectivo si los informáticos colaboran en vez de obstaculizarlo, y comprenden que su postura en este proceso resultará importante. Por eso, el hecho de que en este momento el área de informática ya se encuentre descentralizada facilitará enormemente tal objetivo de creación de conciencia informática en las distintas unidades usuarias, pues los informáticos se verán vinculados activamente en tal propósito.

En mis investigaciones he comprobado que la implantación de una cultura informática en el nivel de empresa que quisieron alcanzar algunas organizaciones fracasó o no tuvo el alcance pretendido y se despilfarra- ron tiempo y dinero en grandes cantidades, porque la quisieron hacer desde el área de informática hacia las distintas unidades usuarias, vistas éstas como un todo, y no como entidades independientes y distintas en sus requerimientos y métodos de operación. Peor aún, sin una visión clara de para qué se les estaba capacitando, si se sobreentendía que el área de informática iba a seguir apoyando al entorno informático de toda la organización. Permítaseme decir que fui testigo de la incomodi- dad incluso con la que esta capacitación fue recibida por la gran mayoría de los usuarios al obligárseles a ir a los cursos sin un propósito claro. El resultado ya todos lo sabemos: un despilfarro descomunal en todos los sentidos, demostrado ahora por cientos o miles de usuarios que nunca llegaron a manejar alguna computadora o la manejan deplorablemente. Salta a la vista que sencillamente las unidades usuarias no apoyaron tal proyecto, pues en verdad no tenían responsabilidad ni control sobre él. Ahora ellas serán las directamente responsables y, por tanto, las más interesadas en que se cubra tal proyecto con la efectividad que reclama su enorme importancia.

Para efectos de consolidar permanentemente una cultura informáti- ca dentro de toda la empresa, es necesario considerar los siguientes requisitos:


a) Diseñar módulos de capacitación de informática en función de las distintas responsabilidades de la organización con reconocimiento de diplomado, lo cual redituará en muchos beneficios para la empresa y sus integrantes (véase cap. 24).

b) Implantar un mecanismo de seguimiento para garantizar y evaluar la aplicación práctica del conocimiento de idormática adquirido.

En este libro me propongo dar una guía de cómo lograr lo anterior, pero no dejará de ser sólo eso: una guía, si bien ya probada y comprobada su efectividad durante muchos años. Esto sólo está escrito, y los problemas ahí están; no desaparecerán con sólo leer lo aquí expuesto. Habrá que trabajar mucho sobre el objetivo de implantar AFI.

Para terminar este capítulo se muestran unos esquemas que ilustran lo que para mí representa AFI: algo así como ir en busca de la excelencia informática, en donde cada uno de 10s elementos necesarios dentro del esquema idormático queda ubicado en función de su verdadero aprovechamiento.

Modernización inf9rmbitica

Area de capacitación

Figura 1.3. Esquema de modernización informática.

Objetivo

Unidades usuarias

-Fijar los objetivos informáticos de la empresa

-Estrwcturar los mecanismos administrativos en términos de sistemas de información. -Evaluar la eficiencia de los resultados del procesamiento electrónico de datos.

Á rea de capacitación

Objetivo

-Crear una cultura informitica propia de la empresa.

Q Funciones

-Integrar a los tres sectores mediante un plan maestro global de capacitación sobre sistemas de información.

-Coordinar la capacitación en función del plan maestro. -Evaluar el avance hacia los objetivos del plan maestro mediante una estrategia de

seguimiento como función.

Área de procesamiento electrónico de datos

@ Objetivo -Satisfacer los requerimientos de información de las unidades usuarias mediante equipo

electrónico de procesamiento de datos.

8 Funciones

-Dotar a la empresa con el equipo de cómputo adecuado para satistácer los requerimientos de información a corto, mediano y largo plazos.

-Mantener un nivel eficiente de destreza en el uso y aprovechamiento de los recursos de cómputo.

-Proporcionar un nivel de servicio computacional congruente con la dinimica operativa de la empresa.

RESUMEN

En realidad, AFI nació en 1980, aunque en ese entonces no tenía una idea clara de hacia dónde me encaminarían mis investigaciones. En aquellos años me empezó a inquietar el desperdicio y el desaprovechamiento tan marcados que estábamos haciendo de los recursos de cómpu- to (humanos, técnicos y materiales), lo cual con el tiempo llamaría despilfarro computacional. Estaba convencido de que era posible evitar la aparición redundante de los errores que a diario ocurrían. Me di cuenta de que la gran mayoría de esos errores sucedían por negligencia o improvisación al querer aplicar un conocimiento que con frecuencia no teníamos; pero también de que lo anterior ocurría porque carecía- mos de un esquema de control en las actividades de detalle que ejecutaban los técnicos. El reto que me propuse fue encontrar las causas de raíz que originaban todos esos desajustes. De alguna manera ya había identificado que cuando un problema se atendía, éste invariablemente era solucionado, lo cual me ayudó a comprender que, en la gran mayoría de los casos, una vez resuelto e1 problema ya nadie hacía un análisis de las causas que lo originaron, y mucho menos dejaba establecida una estrategia permanente de control para evitar que éste aparecie- ra nuevamente. Era evidente que se entendía que el éxito de haberlo solucionado en esa ocasión consistía en haber encontrado una "solución al momento", y no se tomaba en cuenta que el éxito debería ser su erradicación definitiva. En otras palabras, no había ningún efecto de aprendizaje que hubiera dejado dicha experiencia.

Lo más inquietante para mí era que todo mundo estaba consciente de esta situación, y me preguntaba por qué nadie ponía remedio a ese desastre, si sabíamos perfectamente de los riesgos y del elevado costo que todo eso representaba. Analizando detalladamente, una y otra vez la pregunta anterior, fue como inicié mis investigaciones las cuales con el tiempo fui documentando y dando a conocer a través de breves artículos en la revista Informática y en el periódico Computer World de México.

Lo anterior poco a poco me llevó a entender que la problemática tal, no era sólo de ese momento ni de pocos años atrás, sino que era parte de la propia historia informática de nuestro país. Encontré que con el tiempo dicha problemática no sólo no había mejorado, sino que con el crecimiento improvisado que se dio en el área de informática, la situación había llegado prácticamente a volverse, ahora sí, incontrolable; pero lo que mayormente me impresionó, y creo que fue lo que me impulsó hacia lo que ahora es AFI, fue que tan deteriorado ambiente formaba ya parte de la forma de trabajar del área de informática. Es decir, era ya parte de la estrategia de trabajo de los informáticos. Hasta entonces comprendí la verdadera razón que justificaba la existencia de1 grupo de "soporte a la producción".

Ya con el interés puesto en meterme de lleno a encontrar explica- ción a mis inquietudes, después de varios años pude reconocer lo que finalmente me impulsó hacia M I . Descubrí lo que llamé "los tres grandes rezagos de la informática en México", los cuales me explicaron perfectamente las causas de raíz de tan deteriorado ambiente, con el cual en la actualidad seguimos viviendo. No tenía duda, había encontrado lo que con tanto afán estuve buscando. De los tres rezagos mencionados, el primero se refiere a la, hasta ahora todavía descuidada, ac- t?vidad de la Administración de los Centros de Cómputo; el segundo, a1 Area de Informática, que no está ni ha estado jamás administrada; y el tercero, a mi propuesta, apenas hasta hace poco aceptada, después de casi 15 años, sobre la Administración de la Función Informática (el factor AFI).

Así, AFI surgió como la identificación de una gran necesidad que, a sabiendas de todos, nadie ha cubierto. Para haber identificado esa necesidad, tuve que escudriñar la historia informática de México, y aprovechando que en gran medida yo mismo la viví, no tardé mucho en interpretar las razones que nos guiaron al despilfarro computacional. Pude leer dicha historia, tal como si se tratara de un mapa cuyos símbolos me explicaran detalladamente, paso a paso, el porqué de nuestra incapacidad para recibir, manejar y aprovechar ventajosamente la tecnología de la informática, y la misma historia nos dice, casi a gritos, que no hemos madurado, que seguimos improvisando nuestro trabajo al igual que antes, al igual que siempre. Pero también me dijo, y lo interpreté, que había que redireccionar la actuación del informático, que ese cambio era urgente. Acepté esta invitación y aquí está AFI. Ahora invito a mis colegas a participar decididamente con rumbo a este enfoque.

He llegado a pensar, y lamentablemente a comprobar, que el in- formático tradicional, y siguiendo la cadena, también en gran parte el actual, permanentemente ha dado en prenda el futuro a cambio de conseguir el presente. Es decir, al resolver ya como una práctica arraiga- da, de manera improvisada y desordenada, los problemas que se le presentan, generados éstos principalmente por la mala calidad de su trabajo, sin obtener de esas estrategias de solución ningún aprendizaje de la experiencia, no le importa lo que esa situación acarree en el futuro.

Mi propuesta, desde 1992, ha consistido en primera instancia en aceptar que el área de informática con su estructura tradicional centralizada ya no es funcional, dados los requerimientos actuales de las organizaciones. En segundo término, reconocer que la dependencia informática que guardan las organizaciones es casi total; es decir, que el aspecto informático pasa de ser un elemento de apoyo importante, a convertirse en una función vital para la organización, no sólo en departamentos específicos, sino diseminado en toda la estructura. Por lo


anterior, la imagen que se tenía del área de informática de que desde ahí emergía todo el apoyo para la automatización de las actividades operativas, se ha desvanecido; ahora dicho apoyo pasa a formar parte de la propia estrategia de trabajo de cada departamento, y es la esencia misma de las actividades diarias. Véase simplemente una evidencia de lo anterior, al observar en cualquier empresa, decenas y cientos de PC independientes o conectadas en red, accesando incluso a potentes computadora~, formando parte de todo un mismo mecanismo de trabajo.

No nos engañemos, desde hace muchos años la informática ha dejado de ser un simple apoyo importante, es una función vital para las empresas.

El despilfarro Informático: 3 una realldad ignorada I

Problema

El fenómeno del despilfarro informático nos sigue superando; lo seguimos encubriendo y hemos preferido ignorarlo.

Hace ya muchos años (1976-1980) me inquietó un fenómeno, del cual tanto mis compañeros de trabajo como yo ya teníamos conocimientos. Lo curioso del caso es que, aunque convivíamos con él a diario, parecía como si éste no existiera, ya que nos habíamos acostumbrado tanto a él, que lo identificábamos como parte misma de nuestro ámbito de trabajo cotidiano. Yo me hacía constantemente esta pregunta: jha- brá alguna manera de reducir tanto desperdicio humano, técnico y materialc Comencé por darle nombre a este "algo" que de alguna manera yo había descubierto: despilfarro computacional (hoy, despilfarro informático).

A principios de la década de los ochenta, en mi calidad de gerente del área de asesoría técnica en la institución donde trabajaba, constantemente debía visitar muchas instalaciones de cómputo, donde intercambiaba un sinnúmero de experiencias con colegas de dichas instalaciones. Me percaté de que en la gran mayoría de las áreas de informática se utilizaban demasiados recursos (tiempo, dinero, personal, esfuerzo, tecnología, suministros, etc.) para obtener pocos resultados. Comprobé que ya casi como costumbre se emprendían agotadores "maratones" de trabajo, para producir "resultados urgentes" mediante

seudosistemas improvisados y que a pesar del enorme esfuerzo y costo que ello implicaba, se llegaba a resultados poco satisfactorios, lo cual originaba un nuevo círculo de actividades necesarias para subsanar las deficiencias del primer intento. Cuando por fin se lograba algo que se aceptaba como "moderadamente buenoJ', ya se había cometido un enorme despilfarro de recursos. Como no queriendo darnos cuenta de este fenómeno, disfrazábamos el asunto como "todo un éxito", queriendo dar mérito al esfuerzo invertido, y después incluso de un fes- tejo, nos disponíamos a ocuparnos del siguiente trabajo en cartera. Lo peor de todo este ajetreo es que con el paso del tiempo se entendió que ésta debía ser nuestra estrategia de trabajo; es decir, tratando-errando. Es más, tan convencidos quedamos de que así debía ser, que lo adoptamos como esencia misma de nuestro ámbito informático, y ya no lo soltamos; nos aferramos tanto a él, que lo mantenemos vigente hasta la fecha.

Recuerdo que cuando comencé a manifestar inquietud sobre este despilfarro computacional se me tiIdó de "optimista fantasioso". En una junta de gerentes, realizada en la empresa para la cual trabajaba, me atreví a decir lo siguiente: "Siento que se trabaja demasiado y obtene- mos muy poco, es decir, despilfarramos demasiados recursos." Visible- mente molestos varios de los gerentes, uno de ellos me contestó: "Yo no lo creo así, pues si te das cuenta, todos los proyectos de alguna manera los hemos sacado adelante." Contesté: "Sí, eso es cierto, pero lo que digo es que mucho tiempo lo pasamos corrigiendo errores y más errores. He calculado, con base en los registros de la propia computadora, que aproximadamente 40 % de las actividades del área de informá- tica se dedica a la reparación de lo mucho que hacemos de manera improvisada y apresurada. He comprobado que aun teniendo procedimientos de control perfectamente establecidos, a los cuales se les dedicó muchos meses de trabajo agotador, los pasamos por alto. En nuestras constantes prisas, tendemos exageradamente a la improvisación, es más, muchos de los errores, como 10 demuestran estos comunicados que tengo aquí, ni siquiera los detectamos nosotros, sino que son descubiertos por los departamentos usuarios cuando ya ocasionaron severos conflictos administrativos; lo que en otras palabras significa que aún no estamos conscientes de que los errores del área de informática generalmente desencadenan trastornos en serie, y afectan casi de inmediato a muchas áreas dentro del esquema organizacional." Como de- seando poner fin a la polémica que se había iniciado, otro gerente me dijo: "Mira, mira, de cuando acá te preocupas por esto; yo tengo 10 años en esta empresa, y desde que llegué aquí, así hemos trabajado sin que nadie haya dicho algo; hasta que ahora tú te quieres dar tu importancia. Es más, hasta siento que nos ha ido bien, pues dentro de la organización somos reconocidos como un área importante. Tene-

mos una forma de trabajar y eso es todo, y aunque no fuera la correcta, no veo que podamos hacerlo de otra manera; te aconsejo que no hagas más ruido y dejes las cosas como están, y te pido que no nos involucres en tus ideas fantasiosas." Temiendo que la plática pudiera desbordarse, por el momento fingí que me habían convencido y cam- biamos de tema.

Durante algunos días estuve tratando de explicarme a mí mismo el porqué de esa resistencia a tratar de mejorar y la empecinada intención de dejar las cosas tal como estaban, aun cuando se reconocía en forma unánime que los problemas se manifestaban a diario, y peor aún, sabiendo claramente de los conflictos administrativos que esto ocasionaba dentro de la empresa. Nunca imaginé que me estaba adentrando en un tema que llegaría a costarme el rechazo de muchos de mis colegas, e incluso de personas que fueron buenos amigos; y menos aún que ello llegaría a ser la razón de severos bloqueos para perder importantes trabajos de asesoría.

Me impresionó profundamente el hecho de que quienes se resistían a emprender cambios definitivos y a actuar de una manera decidida para superar los problemas mencionados eran precisamente los gerentes de las áreas identificadas como las causantes de la mayoría de los problemas. Me pregunté una y otra vez lo siguiente: jcómo sería posible dar solución a un problema cuando quienes lo generan no lo quieren resolver< Esto verdaderamente me desanimó.

Confieso que estuve tentado a tirar todo por la borda y a recurrir al camino fácil del olvido, abandonando así el asunto para no crearme más problemas. Sin embargo, cada día que pasaba y veía cómo se iban acumulando los problemas, me convencía con mayor fuerza de que estaba ante el descubrimiento de algo importante y no pude conformarme con permanecer pasivo.

Con esa inquietud en mente, inicié la preparación de un documento que poco a poco se convirtió en el inicio del material de lo que meses después utilizaría en una conferencia en la cual exponía mis conceptos. De igual manera, este novedoso enfoque lo convertí en una serie de artículos que fueron publicados por el periódico Computer World de México y algunas otras revistas del medio.

Mis expectativas y las de algunos colegas que se habían interesado en el tema fueron superadas de manera inesperada, pues dichos artícu- los de inmediato generaron tremenda polémica a favor y en contra. De una u otra manera me llegaban comentarios y recibí frecuentes llamadas telefónicas animándome a que fuera hacia el fondo del asunto. De varias partes del país fui requerido para dar conferencias al respecto. Así fue como, contagiado por el interés de colegas, profesores y estudiantes decidí separarme de la compañía para la cual trabajaba e inicié una serie de investigaciones en mi nueva modalidad de asesor en informática. La

ventaja de haber sido asesor de los directores de las áreas de informática más grandes del país es que m e permitió conocer la base e n la cual sustentaría los argumentos de mi descubrimiento, los cuales ahora estaban probados e n los hechos reales no de una instalación, sino de un amplio sector inforrnático del país entero; ya n o tenía duda, sabía que estaba e n lo cierto. Este solo elemento cambiaría definitivamente mi trayectoria como profesional del campo infomático. Apoyé mi lucha e n la siguiente plataforma:

Vivimos en un país que heredó la tecnología de la computación hace ya más de 40 años. Nosotros no sufrimos el laborioso y costoso proceso de la investigación que tuvieron que enfrentar sus descubridores. La recibimos en las manos ya madurada, depurada, lista para explotarse. Sin embargo, en nuestra prisa por utilizar dicha tecnología, caminamos a ciegas, sin prepa- ración, sin conocimiento pleno de los requerimientos que ello implicaba, sin conciencia real de sus riesgos, ni del elevadísimo costo que representa- ría tiempo después nuestra improvisación. En ese camino equivocado, fuimos creando vicios, entendiéndola a nuestro modo, improvisamos nuestros propios métodos de aprendizaje y los difundimos a las siguientes generaciones. En la actualidad, seguimos trabajando en gran medida como lo hicimos hace años, y es por eso que en pleno siglo m, en México, todavía en la gran mayoría de las instalaciones se contratan técnicos y profesionales altamente capacitados y con enorme potencial creativo; se elaboran costosos métodos de trabajo probados científicamente, tendientes a elevar la productividad y a lograr una sensible estandarización en las distintas actividades; se establecen medidas de seguridad de datos y de instalaciones físicas complejas y costosas; se pagan sueldos superiores al estándar general; se emprenden planes de capacitación sumamente agresi- vos; se cuenta con computadoras de alto poder, muchas veces las más modernas de la época; el presupuesto asignado al área de informática casi siempre resulta de los más elevados dentro de la empresa. Sin embargo, los errores dentro del área de informática están a la orden del día; los usuarios siguen insatisfechos igual que hace años; los servicios en línea se interrum- pen frecuentemente, con repercusiones severas para usuarios internos y usuarios finales; persiste un enorme despilfarro computacional en todos los niveles, obligando a una productividad muy baja. En suma, las cosas no marchan bien; no hemos logrado tomar el control.

Lo anterior fue producto de largas y profundas investigaciones. Ana- licé muchos casos e n diversas instalaciones y, a veces, era tal el descontrol, que m e resistía a creer lo que estaba ante mis ojos. Con el tiempo fui concretando dichas investigaciones y, convencido de que el asunto era de suma gravedad, m e comprometí conmigo mismo a sacar a la luz tan tremenda situación. Así, inmerso e n la descripción de los múltiples problemas y de las estrategias de solución que apliqué e n la práctica con resultados dignos de divulgarse, comencé la escritura del presente libro.

Pero, no me detuve ahí, pues cuanto más buscaba, más encontraba; me refiero a la triste situación de deterioro en nuestro ambiente infor- mático. Con los días, semanas y meses, seguí madurando, afinando y complementando mis estrategias de solución, probándolas una y otra vez. Para mi asombro, comprobé que era relativamente fácil poner solución a cada problema que iba enfrentando. Así, con mucha mayor claridad, conocí que ciertamente había encontrado las verdaderas razones de lo que estaba sucediendo, tal como lo describo en el párrafo anterior en el cual baso el presente estudio. Sin embargo, a pesar del éxito de las estrategias de solución que fui encontrando, algo me decía que lo que había descubierto era apenas la punta del iceberg. Este "algo" que de momento no sabía describir concretamente, me dejó profundamente preocupado, hasta que después de varios meses de analizarlo y comen- tarlo con verdaderas autoridades del ámbito informático del país, por fin encontré la razón de mi preocupación. Ese "algoJ1 era, sin la menor duda, el tremendo efecto que la informática va a producir en el plan de modernización de las empresas del país. Desde mi punto de vista, la informática se encuentra entre los primeros tres elementos vitales para la aceleración y el éxito de dicho plan. Veámoslo de la siguiente manera.

Es bien sabido que los gobiernos establecen los lineamientos para alcanzar el desarrollo deseado de un país; sin embargo, el éxito de todas estas estrategias y planeación va en función del nivel de prosperidad que alcancen las empresas de cada país. Una empresa fuerte y próspera genera fuentes de trabajo; produce artículos y servicios de alta calidad competitivos dentro y fuera del país; se ve requerida a mantener empleados capacitados con la suficiente destreza para sostener e incrementar la calidad de sus productos y servicios, y así tender hacia el incremento de sus mercados; es consciente de la importancia que representa contar con tecnología de punta en maquinaria y equipo; genera divisas y recursos económicos para su país, etc. Por otro lado, una empresa débil y pobre, o decadente, no podrá contribuir con dichos beneficios. Y precisamente es aquí donde toma fuerza la importancia de que las empresas cuenten con sistemas de información eficientes. ?Por qué< Porque los mecanismos administrativos y de control por medio de los cuales las empresas logran conocer oportuna y verazmente sus avances, retrocesos y estancamientos se derivan del proceso de la información con la que cuentan. Se sabe de incontables casos en que empresas prósperas decayeron súbitamente debido a que la toma de decisiones importantes fue equivocada por no contar con los indicadores de información oportunos o éstos no fueron confiables. Por tanto, se reconoce que las empresas modernas caminan con más seguridad cuando sus sistemas de información alcanzan niveles de madurez que las guían confiadamente, para tomar buenas decisiones, incluso en épocas de crisis.

Lo anterior obliga a pensar que un país prospera cuando sus empresas prosperan. Para prosperar, una empresa tiene que competir y ganar; para ganar tiene que ofrecer bienes y servicios capaces de atraer clientes; para atraer clientes, habrá que proveer a éstos con bienes y servicios de calidad, en el momento en que ellos los necesiten y al alcance de su economía; para que una empresa pueda ofrecer esto, debe estar bien informada; para que una empresa pueda estar bien informada, requiere haber alcanzado profunda madurez en sus mecanismos administrativos y de control; para que dichos mecanismos funcionen dinámica y eficientemente, deben concebirse como sistemas de información; para que la in- formación fluya con oportunidad, deberán automatizarse dichos sistemas.

Como puede apreciarse, la información adquiere profunda relevancia dentro del marco operativo y de servicio de toda empresa.

Me doy cuenta perfectamente de que los informáticos del país (colegas, profesores y estudiantes) seremos requeridos para emprender un supremo esfuerzo con el fin de convertimos en un verdadero apoyo dentro de los planes de modernización de México, para colaborar eficaz- mente en el surgimiento de empresas prósperas capaces de alcanzar niveles de competitividad congruentes con la competencia que se avecina.

A propósito he dicho que los informáticos seremos requeridos para emprender un supremo esiuerzo. Se verá, según lo demuestran mis investigaciones de más de 15 años, que hace mucho tiempo que estamos empantanados en la manera como hemos aprovechado los recursos de cómputo (humanos y materiales), o mejor dicho, de cómo los estamos despilfarrando. En este libro demostraré que aún mantenemos formas de trabajo profundamente improvisadas y obsoletas, y peor aún, que las seguimos enseñando a estudiantes de nuevas generaciones. Comprobaré que aun a sabiendas de los desastres que ocasiona dicho proceder, lo adoptamos ya como nuestra cultura informática y que nos resistimos una y otra vez a emprender el cambio. Se verá que no queremos cambiar porque no hemos madurado lo suficiente en esta tecnología, tenemos temor a aventurarnos en algo desconocido, y preferimos la comodidad de no querer pagar el precio que implica todo cambio, sin darnos cuenta de que nuestro despilfarro ha resultado y resultará mucho más caro.

A lo largo de los capítulos mostraré claramente cómo nuestro ambiente inforrnático se ha colapsado, y por eso mismo lo que he llamado supremo esfuerzo, en verdad lo será, porque tendremos que derribar varias barreras que con el tiempo nosotros mismos hemos construido, antes de siquiera estar preparados para vislumbrar algo de lo que llamo excelencia informática. Pero no podemos quedamos en donde estamos, es obligado el cambio. Como informáticos conocedores de nuestro estancamiento, es obligación nuestra desatar el nudo que nosotros mismos hemos tejido; es obligación nuestra reparar lo que

hemos descompuesto. Y más aún, empezar a abrir e1 camino a las nuevas generaciones de irdormáticos.

Los mecanismos administrativos y de control de las empresas modernas han madurado, han crecido y se mueven constantemente en diversos sentidos en lapsos de tiempo muy cortos. Lo que resultaba efectivo hace algunos años, ahora ya no lo es. Los esquemas organizacionales de las empresas de hace seis u ocho años ya no existen, y los de ahora cada vez son más dinámicos. Antes, donde había departamentos con 50 o 60 personas, ahora sólo queda una docena operando microcomputadoras, haciendo mucho más trabajo del que se hacía. Antes se consultaban enormes archivos de documentos haciendo esperar por horas a las personas; ahora dichos archivos han desaparecido y en su lugar hay pantallas de video conectadas a potentes computadoras, las cuales hacen posible dichas consultas en segundos.

Como puede apreciarse, los notables cambios en los esquemas organizacionales fueron obligados por la implantación de nuevos y modernos mecanismos administrativos y de control, los que a su vez Fueron originados por la creciente demanda de información. Anterior- mente dichos mecanismos administrativos y de control prácticamente se tenían que adaptar a los recursos de cómputo disponibles; ahora es a la inversa: los recursos de cómputo se desarrollan pensando en las estrategias administrativas que se requieren para el control de las empresas de la actualidad. Por tanto, en aquellos países cuyas empresas han logrado desarrollar una cultura informática elevada, se ha alcanzado la dinámica necesaria para responder congruentemente a los requerimientos administrativos de una organización tremendamente volátil. Por el contrario, en los países en vías de desarrollo, la mayoría de las empresas tienen que esperar la lenta respuesta de adaptación del área de informática, dejando por enormes periodos prácticamente inmóviles los mecanismos administrativos, los cuales se vuelven cada vez más obsoletos e ineficientes, y quedan así empantanados en espera de que en algún momento incierto el área de informática arroje algún resultado que produzca algún movimiento de provecho; sin embargo, para entonces con frecuencia las necesidades administrativas ya son otras. Este solo hecho, así de sutil, coloca a las empresas en una posición vulnerable ante sus competidores nacionales, y no se diga ante aquellas de otros países más desarrollados. La razón es que actualmente las empresas modernas han descubierto en la informática una importante arma estratégica de competencia.

Creo que bien vale la pena a este respecto mencionar, aunque sea brevemente, las conclusiones a las que llegamos recientemente un grupo de investigadores como resultado de un detallado estudio que se nos pidió.

Es bien sabido que a raíz de la firma del TLC, la competitividad de las empresas deberá necesariamente alcanzar niveles suficientes, capaces de permitirles permanecer con éxito en el mercado.

Durante el estudio que desarrollamos, detectamos que el nivel de competitividad de las empresas se eleva rigurosamente en función de la capacidad y calidad de sus recursos humanos. Ahora, sabemos que la calidad en el servicio que continuamente se ofrece va íntimamente li- gada a la efectividad de las estrategias de trabajo de los distintos departamentos que constituyen una organización. Pero, también conocemos que la efectividad de dichas estrategias no es producto de la fortuna, sino el resultado de un proceso permanente de mejora continua en la preparación de los integrantes de la organización, en sus distintas jerarquías.

Lo anterior nos permitió identificar lo que con el tiempo llegamos a denominar los tres elementos básicos para la modernización de las empresas, los cuales nos ayudaron a determinar hacia dónde debe- ría enfocarse prioritariamente la capacitación del personal. Tales elementos son:

1. Elemento creativo. Todo producto o servicio nace y se manifiesta mediante el ingenio humano. Las estrategias administrativas y operativas que logran que dicho producto o servicio adquiera la calidad, precio y difusión deseados, con el fin de obtener la aceptación de los clientes, son básicamente estructuradas por la capacidad creativa del personal de mando y supervisión de la organización. Asimismo, la creatividad es el arma más poderosa con que contamos las personas para mantener en el proceso de mejora continua el funcionamiento señalado por las estrategias administrativas y operativas de una empresa. Lo anterior, dicho en otras palabras, significa que cualquier proceso, del tipo que sea, dentro del funcionamiento integral de toda organización, en algún momento fue concebido y puesto a funcionar por obra del potencial creativo de alguna o algunas personas.

2. Elemento administrativo. Los modernos mecanismos administrativos y de control que han adoptado las organizaciones de la actualidad, no podrían ser operados sin el uso de la informática. Las estrategias administrativas amalgamadas con el potencial infomático han dado a las organizaciones la capacidad de transformaciones rápidas según lo reclama la dinámica de la creciente lucha competitiva, sin menoscabo de la operación continua y servicio a sus clientes ni la pérdida del control. Este solo hecho ha permitido ver el potencial que posee la informática como un arma estratégica para la competencia.

3. Elemento operativo. Por muchos años ha sido bien aceptado el dicho de que "lo importante no es llegar, sino sostenerse". Sin embargo, en la actualidad el aspecto de sostenerse no implica haber llegado

y permanecer estático con lo logrado hasta ahí. Se vuelve indispensable mantener activo un proceso de mejora continua que nutra permanentemente los mecanismos administrativos y de control establecidos en un principio. Por decirlo de algún modo, es necesario "aceitar" constantemente la maquinaria y cambiarle "piezas desgastadas" con el fin de irla adaptando oportunamente al medio competitivo, el cual se mantiene en constante evolución, en alerta permanente para expulsar a empresas perezosas. Los conceptos bien dirigidos de servicio, calidad, liderazgo, trabajo en equipo, atención al cliente, actitud positiva, cero defectos, seguimiento como función y otros, resultan relevantes aplicados a las actividades diarias del personal de todas las jerarquías. Ciertamente, aquí radica el secreto de gran parte del éxito de muchas empresas.

Como puede apreciarse, ninguna empresa podrá emprender su modernización si no hace propio del personal de su organización el conocimiento y dominio de cuando menos los tres elementos anteriores.

Aquí es donde la situación empieza a complicarse para los informáticos del país (profesionales, profesores y estudiantes). La situa- ción del ámbito informático de nuestro país no es precisamente halaga- dora y, por consiguiente, primero habrá que construir bases firmes antes de siquiera pretender decir que estamos listos para apoyar el plan de modernización. Será necesario hacer un profundo análisis de nuestras carencias, vicios, recursos, etc., y desarrollar un plan estratégico que, aparte de colocarnos dentro de una cultura informática sólida, nos im- pulse con la suficiente fuerza hacia la excelencia informática, dejándonos en posibilidades de avanzar al ritmo de las necesidades de automatización de las miles de empresas que emprenderán su modernización.

Seguramente que no será fácil, ni tenemos todo el tiempo que quisiéramos; pero, por eso mismo, en nuestra prisa no debemos caer en los errores del pasado. Tenemos que poner en marcha nuestra creatividad, y lograr hacer más con menos y en menos tiempo. Sé que esto es posible, pero es necesario primero reconocer nuestras deficiencias para que, ya identificadas, podamos enfrentarlas con inteligencia, para encontrar atajos seguros que nos permitan acelerar el paso, sin el peligro de caer en improvisaciones que más adelante nos resulten mucho más ostosas, como nos ha sucedido en el pasado, y que por desgracia nos han C; ejado sumidos en prácticas obsoletas, empiricas y costosas.

Pues bien, comencemos por reconocer una realidad ignorada, no por desconocimiento, sino por temor al cambio; y nótese que no dije resistencia al cambio. Es temor, porque sabemos que nuestra prepara- ción es deficiente y nuestra experiencia en el campo está llena de vicios, por eso tenemos desconfianza. Desconfianza por no saber cómo hacer las cosas de acuerdo con la complejidad que reclama la tecnología

84 CAE 2. EL DESPILFARRO INFORMÁTICO

moderna de la informática; por eso preferimos hacer las cosas tal como las hemos hecho por años, despilfarrando sin valorar el costo de lo que nosotros conocemos como "proyectos exitosos". Repitiendo una y otra vez los mismos errores (al fin y al cabo ésa es la manera como enten- demos que se maneja esta tecnología).

Quiero mostrarle al lector algo de lo mucho que veremos en el presente trabajo, y le aseguro que desde este momento su visión profesional empezará a sufrir cambios radicales. Lo aseguro.

Por más de dos décadas he tenido la oportunidad de asesorar, en distintos ramos, a los directivos y gerentes de las áreas de informática más grandes del país. Dada la magnitud de dichas instalaciones, he colaborado en gran variedad de proyectos tanto técnicos como administrativos propios del ámbito computacional. Al mismo tiempo, mientras profundizaba en cada proyecto, tuve la invaluable posibilidad de conocer con detalle una gran cantidad de distintos problemas a los que se enfrentaba cada instalación, y la valiosísima experizncia de contribuir en la solución de algunos casos, y en otros la de determinar completamente las estrategias de solución.

Lo anterior me permitió descubrir y comprobar una realidad que frecuentemente (por no decir siempre) escapa a técnicos y gerentes, quienes están inrnersos en lo cotidiano de sus labores, y además, no conocen más allá de las fronteras de su propia instalación. ¡Qué dije!: $escapa< ¡Pero si a diario la están palpando con sus propias manos! Es más válido decir "la ignoran", es decir, hacen como que no está ahí. Sin embargo, tarde o temprano, con el peso de los problemas que se acumulan, día con día, de pronto la vislumbran (hablo de la realidad ignorada), tímidamente al principio, y en pocos momentos más, comienza el temor (temor a perder el puesto), de tal manera que quienes la descubren, hacen todo lo que está a su alcance para aparentar que no está pasando nada, y tratan de ignorarla, o mejor dicho, para curarse en salud, pretenden disfrazarla como un mal necesario al que hay que aceptar, pues de todas maneras siempre se ha vivido con él. Se tratan de convencer a sí mismos de que ello forma parte de la esencia misma del entorno informático en el cual ellos se han formado. En otras palabras, es una realidad conocida por todos: es un secreto a voces. Pero, lo irónico es que se reconocen sus efectos y se sabe de los desastres que ocasiona.

En el párrafo anterior, parecería como si quisiera confundir al lector, pues primero digo que hay una realidad escondida, la cual con el peso de los problemas se manifiesta de pronto y se hace visible ante los ojos de todos; después afirmo que dicha realidad todo mundo siempre la ha conocido, incluso que se ha aceptado como parte misma de la esencia informática. Parece como si fuera un juego de palabras que no conduce a nada. iExactamente!, así es como nosotros los informáticos queremos

hacer que se visualice tal realidad: como si fuera sólo un juego de palabras que no conduce a nada. >Por qué darle importancia<, olvidemoslo y mejor ataquemos los problemas.

Voy a explicarme. Véase de esta manera: la mayoría de los integrantes del área de informática conviven a diario con un sinnúmero de problemas, los cuales, a pesar de sus efectos dañinos, pasan inadvertidos porque se resuelven y controlan temporalmente en la propia área donde sucedieron, y no llegan a ser del conocimiento general. Sí, son docenas de problemas que, acumulados durante días, semanas y meses, se convierten en cientos, si no es que en miles. $El costo<, tremendamente alto, pero nadie lo puede precisar. Es decir, se vive entre errores constantes, que generan una enorme cantidad de problemas, pero como estamos acostumbrados a verlos como parte misma de lo cotidiano de nuestras actividades, lo aceptamos como algo tan natural, que puede asegurarse que dicha realidad no existe. ?LO ve el lector< Todo el mundo conoce esa realidad, pero se acepta como si no existiera, es decir, no representa problema alguno -de todas maneras los problemas que acontecen habrá que resolverlos, no hay razón para inquietarse-. Es más, en un gran número de instalaciones se cuenta con un área ex profeso para "atender" esos problemas cotidianos. Por tanto, es una realidad que está bajo control, lo cual quiere decir que simplemente no está ahí, cuando menos ante los ojos de la gran mayoría. O mejor dicho, hagamos como si no existiera: es más cómodo vivir fuera de las inquietudes. Es preferible pensar que no vale la pena preocuparse por algo que ya es así.

De pronto, casi como si estallara una bomba en pleno centro de cómputo, de un momento a otro surge una interrupción en el servicio, o por error se genera un mal resultado que tomó horas, quizá días en producirse, lo cual hace que en pocos minutos se destroce la tranquilidad de miles de clientes, cientos de departamentos en donde miles de empleados se quedan inactivos y otros cientos inician procedimientos de emergencia. Entonces, en unos segundos, se convoca a una junta precipitada, a 13 cual acuden en estampida aquellos que algo tienen que ver con el problema, incluso algunos que por su capacidad técnica, aun no teniendo incumbencia, participan como elementos de apoyo. En este momento se acepta que la realidad sí existe, que tiene forma, que es peligrosa, que sus estragos son de alcances incalculables. $LO vuelve a ver el lector< La realidad sí existe, es decir, cuando el problema es grave y sale de las fronteras del área de informática, entonces la realidad se descubre poderosa ante los asustados ojos de los informáticos y el profundo enojo de clientes y departamentos usuarios de los servicios de cómputo. Entonces merece una atención especial y es prioridad ante todo lo demás, por tanto sí se justifica dedicar todos los recursos necesarios para restablecer el control. Así, después de muchas horas de presión, sin

comer siquiera, y tal vez hasta sin dormir, por fin se corrige el asunto y regresa la calma. En pocas horas, pasada la crisis, la inercia ambiental de costumbre supera la gran sacudida y vuelve a ocupar su lugar como antes, es decir, ¡no existe talrealidad!Así, todo el mundo queda anestesiado después de la tragedia, quizá por un día, dos o tal vez por sólo algunas horas, y prefiere no pensar en la siguiente catástrofe, que se sabe va a ocurrir porque así siempre ha sucedido, pero más vale ignorar la realidad.

Seguramente ya identificó a qué realidad nos hemos estado refirien- do. Pero, aun así, me atrevo a pensar que usted también ya se vio envuelto en el juego de palabras; es decir, sabe de qué le estoy hablando, incluso muy probablemente usted ha sido partícipe de los "maratones" para resolver problemas, pero aún no logra reconocer las raíces del fenómeno. Pues bien, pongámosle nombre a esta realidad:

La Eunción informática de las empresas nunca ha estado administrada ni lo está en la actualidad.

Es casi seguro que el lector se sorprenda de la afirmación anterior, pues se preguntará: jentonces qué es lo que hacen los gerentes, subdirectores, directores, del área de informática<, jno se supone que ésta es su labor< Para lo anterior no tengo la respuesta, ni mucho menos el derecho de calificar la actitud de ellos. Sin embargo, sí soy quien afirma que la función informática de las empresas nunca ha estado administrada ni lo está en la actualidad. Pero, no se piense que tal afir- mación no está sustentada. Por el contrario, existen tantas evidencias, que cuando las he expuesto en mis seminarios y conferencias, todavía no he encontrado alguien que me diga que eso no es verdad. La seguridad con que afirmo esto está sustentada, como ya dije, por más de dos déca- das de investigaciones serias en el mismo campo de acción e incluyen valiosas aportaciones de cientos de colegas, quienes también han vivido por años las experiencias y frustraciones de tal falta de administración.

Es preciso dar peso a la afirmación anterior; por ello, en este momento le pido muy seriamente. al lector que conteste de nuevo el cuestionario del capítulo 1, respecto de si el área de informática está administrada o no. En este punto del desarrollo resulta importante que el lector saque sus propias conclusiones sobre lo que afirmo, porque éste será el argumento básico que justifique la lectura (entiéndase estudio) de este libro. En tal sentido, pues, analice y responda, por segunda vez, con amplia honestidad, el cuestionario que aparece en la página 28.

Para sacar verdadero provecho del contenido de esta obra, sugiero al lector que no lo vea como un libro técnico. Lo expuesto aquí deberá ser

EL DESPILFARRO INFORMÁTICO

considerado como un extenso informe del trabajo de un asesor que para cobrar sus honorarios tenía que resolver los problemas y comprobar a sus clientes la efectividad de tales soluciones. Las soluciones tenían que ser objetivas, claras y convincentes a toda prueba. Confieso que llegué a adquirir tal destreza en la identificación de las causas de raíz de los problemas, que me resultaba fácil establecer la estrategia de solución. No, no es altanería de mi parte, pues permítame decirle que muchos de los problemas a los cuales ya había encontrado solución resultaban ser idénticos en otras instalaciones, y legué al grado de ser contratado en la misma instalación para resolver problemas que ya había resuelto ahí años atrás, no porque las soluciones establecidas no hubieran sido efectivas, sino porque habían sido abandonadas o no se habían respetado; es decir, mientras había existido la presión del problema, se habían aplicado los correctivos que les había sugerido y había desaparecido el problema, pero cuando ya no se tenía dicha presión, se volvía a los vicios de antes, surgiendo así nuevamente el problema. Como podrá apreciar el lector, ésta era la razón de que en tales casos fácilmente encontrara las estrategias de solución, ya que además yo no tenía duda de su efectividad.

Éste es el informe que doy aquí: el planteamiento de problemas y soluciones sustentadas por casos reales; pero además confirmadas y enriquecidas por valiosísimas aportaciones de centenares de colegas, las cuales en conjunto son las que verdaderamente le dan sustento a este trabajo. Ahora bien, no se imagine el lector que aquí encontrará complicados modelos matemáticos o difíciles teorías científicas. . . ni siquiera algo novedoso de lo que hasta ahora no haya oído hablar (salvo que todavía sea estudiante, y seguramente el conocerlo le resultará valiosí- simo para cuando ejerza). Por el contrario, le sorprenderá que casi todo cuanto le describiré, de algún modo ya lo conoce. Es más, probablemente lo ha vivido. Pero, jatención!, que esto no le haga restarle importancia al contenido, pues lo verdaderamente nuevo, lo más valioso de lo que expongo, es que lo ya conocido por usted, ahora se ve desde otra perspectiva: con la voluntad de querer hacer lo que muy pocos hemos hecho, con valor al aceptar lo que otros prefieren ignorar y con sencillez mediante la aplicación de soluciones sumamente simples apoyadas en el sentido común; pero al mismo tiempo, debido a esta simplicidad, se vuelven muy vulnerables. Es muy fácil dejarlas de lado y no aceptarlas, no caiga en esta trampa.

Las estrategias de solución planteadas aquí van mucho más allá de todo ese escándalo disfrazado de planeauón estratégica, y no se piense que estoy en contra de la planeación como tal. En lo que no coincido es en esa planeación que burocratiza la puesta en marcha de soluciones prácticas; en esa planeación que está hecha para dificultar la participa- ción de aquellos que sugieren mecanismos ingeniosos que ponen en

entredicho la existencia de algunos "departamentos de control"; tampoco acepto la planeación que dicta caminos infinitos de procedimientos que por lo general nadie termina por recorrer. Baso mi exposición, y en eso consistió mi investigación, en comprobar que para lograr las soluciones planteadas aquí, no hay que caminar demasiado; incluso promuevo lo contrario: caminar mucho menos que lo andado hasta ahora, sólo que en distinta dirección.


El presente libro está dirigido a los estudiantes, en quienes en muy pocos años estará sustentado el destino inforrnático de las empresas de nuestro país. En especial a los estudiantes de las carreras de administra- ción y de informática.

Confío plenamente en ellos. Por esa razón he dedicado al asunto muchos años de trabajo y he extraído valiosa información de mis propias experiencias; he escudriñado cada detalle de las múltiples deficiencias que se me ha encomendado subsanar; he implantado un sinnúmero de estrategias de solución. Esto es lo que quiero compartir con los jóvenes estudiantes. Cierto estoy de que ellos no podrán ignorar la realidad. Los informáticos de mi generación ya hicimos lo que teníamos que hacer, y quiero aclarar que por fortuna muchos de mis colegas se han comportado como verdaderos héroes, sosteniendo el barco durante muchos años y cargando el lastre de los informáticos corrompidos, pero ya es necesario emprender el cambio.

Las estructuras informáticas que construimos por tanto tiempo ya no responden a las demandas de las empresas modernas de la actualidad. Necesitamos ser relevados. No resistiremos mucho tiempo, por más que sigamos ignorando la realidad. No creo que el resultado de mis investigaciones pueda ser capitalizado por los informáticos tradicionales. No confío siquiera en que se tomen la molestia de leer el libro que a muchos de ellos les he obsequiado. Tampoco creo que muchos de ellos tengan la capacidad ni el coraje para emprender el cambio que sugiero, porque esto representaría para ellos volver a empezar. Por lo anterior, reitero, este libro ADMINISTRACI~N DE LA FUNCIÓN INFORMÁTICA está dirigido a los recién egresados y estudiantes.

Ahora quiero compartir una frase motivacional que en algún momen- to se me ocurrió y que me ha resultado valiosa en el logro de mis proyectos:

La esencia de todo propósito no está en el ímpetu con el que se inicie, sino en la persistencia para su realización.

RESUMEN

El despilfarro computacional fue mi primer descubrimiento; pero ... ?qué dije<, jdescubrirnientoC Pero si todos lo conocemos. A diario hemos vivido con él, seguimos viviendo con él y su costo es enorme.

Sí, dije descubrimiento, porque yo no lo quise ignorar. Acepté su realidad, y ahí empezó mi lucha con un rumbo bien definido: hacia AFI. Este fenómeno es real. Por eso AFI ha demostrado que dentro de nuestro deterioro informático, a lo que nos hemos dedicado es a administrar la crisis de la informática, en vez de administrar la función informática. Pero algo todavía peor es que, si estamos conscientes de que se ha vivido con tan deteriorado ambiente informático, corrigiendo problema tras problema (despilfarrando), por qué no hemos aprendido de tan gran experiencia. En vez de eso, seguimos repitiendo los mismos errores y, en consecuencia, corrigiendo una y otra vez los mismos problemas. AFI vuelve a demostrar que no es posible aplicar el modelo de aprendizaje, porque no es posible aplicar este modelo dentro de un contexto de seguimiento por excepción, pues para aplicar favorablemente dicho modelo, se requiere un ambiente de seguimiento por función, dentro del cual el modelo inexorablemente funciona.

Me atrevo a pensar que el despilfarro computacionaI, del cual aseguro hemos y seguimos siendo presa, ha repercutido severamente en las finanzas de muchísimas empresas y, por supuesto, en los bolsillos de millones de clientes. Veámoslo de la siguiente manera.

Imaginemos por ejemplo una institución bancaria, en donde su función informática le resulte dramáticamente cara, propiciado esto obviamente por un atroz despilfarro computacional. jDe dónde cree usted que sale ese gasto< Pues sí, del bolsillo de sus clientes. O qué no se ha dado cuenta de que actualmente empieza a haber cargo por una simple solicitud de saldo, entre otros.

Por lo anterior, afirmo que los inforrnáticos seremos muy pronto requeridos para emprender un supremo esfuerzo para lograr aprovechar de la mejor manera posible los recursos de cómputo (humanos, técnicos y materiales). Tenemos que ofrecer y dar a las empresas mejores resultados en esas labores. Nuestra obligación consiste en reparar en forma definitiva lo que por tanto tiempo hemos descompuesto. Y más aún, empezar a abrir con una nueva dirección el camino para las nuevas generaciones de informáticos. AFI ofrece estas posibilidades, empezando por redireccionar el obsoleto e ineficaz concepto de apoyo informático hacia un contexto mucho más amplio, perceptible éste como función informática, vital para las organizaciones modernas. Los requerimientos de información de estas organizaciones han cambiado mucho, lo cual reclama por la naturaleza misma de la dinámica de los mercados actuales, dentro de los cuales se mueven esas organizaciones, cambiar el

esquema infomático tradicional por uno más amplio, dinámico y sobre todo flexible, capaz de moverse a la misma velocidad que la volatilidad organizacional. En la actualidad, un esquema organizacional rígido es inoperante, y los de hace cinco años ya no existen o están cerca de sucumbir ante la realidad competitiva actual. Desde cualquier perspectiva, tras una reflexión profunda, el cambio en el esquema inforrnático obliga necesariamente a un cambio radical de actuación del informático, quien ha de transformarse en un Administrador de la Función Informá- tica (un MI).

Y la administración de la función informática.. . ihasta cuándo?

Problema

A poco más de una década de haber surgido AFI, hoy existe una materia profesional para tal fin, sin embargo, aún a sabiendas de su gran necesidad, existe todavía cíerta confusión y escepticismo al respecto.

Para iniciar este análisis, y sólo como una de tantas muestras, pero sin embargo de las más significativas sufrida en todo el mundo, voy a referirme al evento mformático que causó la llegada del año 2000.

Al iniciar la década de los noventa fue evidente, a escala mundial, una real preocupación sobre lo que se avecinaba al iniciar el año 2000. Resultaba indispensable modificar la enorme cantidad de programas de cómputo que manejaban el año (1971, 1972 ...) con sólo dos dígitos, los de la extrema derecha, y se sobreentendían los dos de la extrema izquierda siempre como " 19" (mil novecientos.. .).

Durante la primera mitad de esa década de los noventa, aunque la preocupación era verdadera, prácticamente ninguna empresa h z o nada al respecto; parecía existir la esperanza de que alguien corrigiera el problema, por arte de magia o, cuando menos, lo simplificara de forma importante y así alargando esa espera estéril se acortó el tiempo peligrosamente. No Fue sino hasta 1995 que el pánico hizo presa en las empresas e instituciones de todo el mundo, pensando en lo que podría

. I

92 CAF! 3. iHASTA CUÁNDO?

sucederles cuando sus computadoras Fallaran al hacer operaciones arit- méticas con el campo de la Fecha, entrado el primer minuto del año 2000. Entonces se gastaron enormes Fortunas (se habla de 800 mil millones de dólares a escala mundial, de los cuales México gastó 30 mil millones) para modificar todos los programas que fuera necesario. No quedaba otra opción.

Ahora, pasado el trago amargo, me doy cuenta de que muy pocos realmente supieron las verdaderas razones por las que hace 40 o 50 años atrás fue necesario y ventajoso reducir el campo del año a dos dígitos en vez de cuatro. Esto, en vísperas del año 2000, la gran mayoría de personas lo calificaron de "torpeza". Pero, hoy veo la situación todavía más caótica, cuando me doy cuenta de que muy, pero muy pocos, se percataron de las verdaderas razones por las que ese cambio tan insignificante costó tal esfuerzo y tan descomunal gasto económico, y peor aún, que no hayamos capitalizado tan significativa experiencia para convertirla en un nuevo modo de hacer las cosas dentro de las empresas de nuestro país, respecto de los sistemas de información y la automatización de los mismos, dejando abierta la posibilidad para volver a tropezar con la misma piedra. Así, encuentro hoy la razón para retomar el problema llamado Y2I< (del inglés: Year 2K año 2000), pero no para decir en especial por qué hubo que hacer tal cambio, sino para recordar a mis colegas informáticos que la dificultad y el elevado costo de esa hazaña no se debió tanto a la cantidad de programas que Fue necesario modificar, sino al increíble y terriblemente deteriorado ambiente dentro del cual se tuvo que hacer ese cambio.

De cualquier manera, toco de paso que durante la segunda mitad de la década de los noventa existieron infinidad de comentarios desvirtuados por haberse decidido manejar dentro de los programas y archivos de datos (incluso, internamente en los circuitos electrónicos de las computadoras, desde hace casi medio siglo), sólo los dos últimos dígitos del año. Es decir, en vez de haberse decidido, por ejemplo, identificar el año 1968 con sus cuatro dígitos, se decidió escribir nada más los dos últimos, "68", asumiendo los dos primeros siempre como "19 ...". Esta decisión, que ante la inminente llegada del año 2000 terminó por ocasionar múltiples problemas y gastos colosales, en su momento también ahorró sumas impresionantes de dinero y Fue la solución para poder operar con mayor eficiencia los sistemas informáticos de aquella época.

Desde el punto de vista de AFI, esta historia refleja una evidencia clara de la falta administrativa que siempre ha prevalecido dentro del terreno de la informática. Si bien es cierto que no hubo torpeza (más adelante explico por qué) en haber tomado esa decisión, no puede ocultarse de ningún modo la falta de experiencia que a escala mundial se ha tenido por siempre en el manejo y explotación de esta tecnología, sobre todo, considerando lo joven que es (en 1948, apenas se construyó

el prototipo de lo que hoy son las modernas computadoras). En ese sentido, parece ser que cabe cierta justificación de la indiferencia administrativa dentro de la informática, pues primero hubo que aprender a manejarla y a aplicarla.

A mi juicio, el hecho de no saber administrar los recursos informáticos para aprovecharlos y aplicar todo su potencial tecnológico, a lo largo del tiempo ha ocasionado pérdidas incluso mayores a lo que se tuvo que pagar para lograr superar el problema Y2IZ. Yo lo entiendo porque antes no había una historia en la cual sujetarse en el terreno de la informática que se pudiera tomar como modelo para saber qué hacer (cómo administrar la función informática). Pero hoy existe suficiente camino andado como para darnos cuenta de que la función informática debe administrarse y por eso existe AFI. El siguiente análisis descubre perfectamente por qué.

CÓMO Y POR QUÉ SURGIÓ EL PROBLEMA INFORMÁTICO DEL A Ñ 0 2000

Pregunta 1. Cuando se decidió quitar los dos dígitos de la extrema izquierda (19) al campo del año en la fecha para representar el año con sólo dos dígitos en vez de cuatro, en los diseños de registros de datos, y dejar que los programas de computadora los manejaran asumiendo permanentemente el número "19 ...", jse sabía el gran problema que se podría generar cuando llegara el año 20005.

Respuesta. Quienes de algún modo participamos en el diseño y pro- gramación de los sistemas de información basados en computadora en la década de los sesenta y que también establecimos en nuestros respecti- vos centros de cómputo esa decisión, sí sabíamos perfectamente que al llegar el año 2000, todos aquellos programas que utilizaran la fecha para la realización de cálculos de cualquier tipo fallarían en su proceso. ¡Sí que lo sabíamos!

Pregunta 2. Entonces, si se sabía perfectamente el grave desastre que podría acarrear lo anterior, jpor qué se hizo aun a sabiendas5.

Respuesta. Precisamente porque se pensaba que podría suceder, mas no que iba a suceder, pues en aquella época (1965) teníamos la. certeza firme de que los sistemas diseñados de tal manera, seguramente en pocos años más (digamos cinco o a más tardar 10) ya habrían sido remplazados; ya que en ese tiempo faltaban 35 años para llegar al año 2000, había "toda una vida" por adelante para hacerlo.

Pregunta 3. Pero, jno resultaba estúpido que por ahorrar dos insignificantes dígitos se corriera tan descabellado riesgo que llegó a


costar a escala mundial 800 000 millones de dólares, de los cuales a México le tocó pagar poco más de 30 000C

Respuesta. Esta pregunta prefiero que la conteste el lector con base en la información que a continuación se presenta. Que sea él quien valore lo que se hubiera perdido de no haberse tomado tal decisión, en el sentido de haber eliminado esos insignilcantes dos dígitos. Que sea él quien juzgue si el costo de 800 000 d o n e s de dólares que tuvo a escala mundial es más o menos equivalente a lo que se obtuvo a cambio, gracias a la supresión de sólo dos dígitos.

PWRA ETAPA. POR QUÉ SE T O M ~ LA DECISI~N DE QUITAR DOS D~GITOS DEL AÑO

La falta de información veraz sobre el problema informático del año 2000 ha sido manipulado ventajosamente para convertirlo en argumentos comerciales, sociales, políticos y hasta religiosos. Sin embargo, este fenómeno fue real. El riesgo del desastre, de magnitud casi apocalíptica, existió y también fue verdadero. Por eso, precisamente por eso, fue necesario pagar tan colosal costo a escala mundial. La incertidumbre sobre lo que verdaderamente iba a suceder en las computadoras, una vez que los relojes marcaran el primer segundo del año 2000, existió, pero nada parecido a lo que se quiso hacer creer a la gente, y que incluso algunas sectas religiosas relacionaron con pasajes bíblicos en el sentido de que se avecinaba el fin del mundo.

La incertidumbre de lo que pudo haber sucedido en los procesos de las computadoras la sufrieron especialmente los especialistas de la in- formática, y qué bueno que fue así, porque nos obligó a una revisión meticulosa para verificar hasta en sus más mínimos detaíles los cambios que se hicieron en los programas, archivos y computadoras; así es como se pudo ofrecer la suficiente garantía de su correcto funcionamiento entrado el primer segundo del año 2000.

+TUVO sentido haber generado tal desorden4

Sucedió que en la década de los sesenta, las cantidades de datos que se colectaban en bancos, empresas gubernamentales y privadas, empezaban a ser inmanejables de manera secuencial. En aquellos tiempos, en el Gobierno de México, ya existía la necesidad de controlar algo así como 3.5 millones de contribuyentes, y en los bancos cerca de 4 millones de cuentahabientes. Por ello, surgió la necesidad de utilizar tanto los dispositivos de hardware como los programas de software

necesarios para lograr el acceso directo a los datos, por ejemplo, en un gran archivo del gobierno en donde se llevaba el control de los contribuyentes para el pago de sus impuestos o en los bancos donde se tenían que actualizar los saldos de las cuentas de cheques de sus clientes, se quería que en vez de tener que leer registro tras registro hasta llegar al que se deseaba consultar o actualizar, se pudiera leer y actualizar directamente el registro deseado con sólo proporcionar su identificador individual. Se encontró que para un banco el número de cuenta del cliente y para el gobierno la clave de contribuyente, bien podían significar ese identificador individual necesario para accesar directamente los datos particulares. Ahora bien, la única posibilidad para lograr el acceso directo requerido era almacenar esos grandes volúmenes de datos en dispositivos de acceso directo, corno lo fueron los discos mag- néticos, que recientemente habían salido al mercado.

E1 avance tecnológico, en aquellos años, sólo permitía diseñar discos magnéticos (de tamaño gigantesco) con capacidades de almacenamien- to Iimitadas (a lo sumo 5 megabytes). Además, los precios de esos modernos dispositivos, por la misma razón de que la tecnología no estaba tan desarrollada, resultaban elevados (varias decenas de miles de dóla- res, dependiendo de su modelo y de su capacidad de almacenamiento), que considerando el precio de la computadora, resultaba un gasto muy importante (hablo de computadoras gigantescas).

Los caros dispositivos de acceso directo y sus limitadas capacidades de almacenamiento más los reducidos tamaños de memoria de las computadoras, nos obligó a racionar hasta sus últimas consecuencias la representación de datos. De tal manera que fue indispensable manejar casi todo por nomenclaturas. Por ejemplo, para las entidades federativas, en vez de codificar "Aguascalientes" con todas sus letras, en los registros de datos se utilizaban sólo dos posiciones, 01 que significaba Aguasca- lientes, 02 Durango, etc. Así, sólo cuando se requería emitir algún reporte impreso, el programa al consultar un directorio con los nombres de las entidades federativas, reconocía que 01 se refería a Aguascalientes y así lo imprimía. Lo mismo se utilizaba para el Registro Federal de Automóvi- les, en donde por ejemplo, General Motors era 01, Ford era 02, etcétera.

Pero necesitábamos más posiciones disponibles para poder almacenar los archivos en los reducidos discos magnéticos, y éstas las encontramos en el campo de la fecha, el cual era común que se utilizara varias veces en un solo registro de datos. Esto se consiguió al omitir dos dígitos ("19", correspondientes al año) en todos los campos de fecha que estuvieran definidos en cada registro de datos.

Para darnos una idea de la magnitud de esta modesta simplificación tenemos que en el caso del Registro Federal de Causantes (dependencia del Gobierno perteneciente a la SHCP, que en la década de los sesenta estaba encargada de llevar el control de impuestos de todo el país), se

96 CAF! 3. iHASTA CUANDO?

llevaba el control de algo así como 3.5 millones de contribuyentes. Dentro de cada registro de datos (3.5 millones, uno por cada contribuyente) existían cuatro campos de fecha: fecha de alta, fecha de nacimiento, fecha de baja, fecha de inscripción, y a veces más. Así que, nos dimos cuenta que si ahorrábamos dos caracteres (19) por cada campo de fecha (cuatro campos), entonces en cada registro estábamos ahorrando ocho caracteres en total, o más si había más campos de fecha. Al multiplicar ocho caracteres ahorrados en cada re istro por 3.5 millones de registros, el ahorro resulta colosal: 28 millones d e caracteres ahorrados. Ahora, si consideramos que en la década de los sesenta, los discos de mayor capacidad de almacenamiento estaban en el orden de los 5 megabytes (5 millones de caracteres), estamos hablando de que con la simple reducción de los dos caracteres (19) de los campos de la fecha, se estaba ahorrando la necesidad de disponer de seis unidades de discos más para mantener en línea (completo) el acceso directo a 3.5 millones de registros, lo cual significaba ahorrar decenas de miles de dólares en equipo de cómputo. Si estos miles de dólares los multiplicamos por todos los centros de cómputo del mundo que hicieron lo mismo, podemos imaginar a grandes rasgos el ahorro económico.

Este enorme ahorro en dispositivos de acceso directo, por sí solo, en aquella época ya justificaba la decisión de hacer el recorte referido. Pero, ahorrar en dispositivos de disco no fue el único logro al simplificar los dos dígitos del año (19), pues existía un ahorro aún más importante. Resulta que cuando dichos registros (ya disminuidos en dos dígitos en cada campo de fecha) se procesaban en la memoria de la computadora, significaba menor ocupación de posiciones de memoria, dejando mayor disponibilidad para utilizarla con instrucciones de programa; para captar la importancia de lo anterior, hay que tomar en cuenta que en ese momento, las capacidades de memoria de las computadoras (no PC, sino potentes macrocomputadoras), estaban en el orden de los 8 K bytes (ocho mil posiciones de memoria), lo cual nos obligaba a los programadores a racionar terriblemente las instrucciones con las que construía- mos los programas, dándose el caso que, cuando un programa tenía una cierta cantidad de instrucciones no posible de ser almacenadas todas ellas en la reducida memoria de la computadora (ocurriendo esto en muchos casos por 20, 10, ocho o menos caracteres), se hacía necesario fragmentar un pro rama en dos o más pro ramas de menor tamaño, situación que muc f as veces se pudo evitar a P contar con algunas pocas más posiciones de memoria por medio de la simplificación de los dos caracteres del año (19) en cada campo de datos que representaba la fecha.

Si imagináramos que se hubiera preferido manejar los cuatro dígitos del año, en vez de dos, y por esa ocupación Fragmentar los programas, las consecuencias en muchos casos, es que en vez de un solo proceso de datos, se hubieran tenido que hacer varios pro

CÓMO Y POR QUÉ. . . 97

secuenciales para llegar al mismo resultado, por lo que, si el tiempo estimado para procesar archivos de tres millones de datos era de una semana o más (aquellas computadoras eran miles de veces más lentas que las de ahora), resultaba que entonces sería de dos o más semanas. Además que en aquella época las computadoras no se vendían, sino que se rentaban por tiempo de uso, el presupuesto se pudo haber incrementado sustancialmente por muchas semanas más de'procesos adicionales, al fragmentar los programas, ocasionada ésta, a su vez, por la limitación del tamaño de memoria de la computadora.

Como puede apreciarse, al reducir los tiempos de proceso, la consecuencia inmediata era menor pago de renta por concepto de tiempo de uso de la computadora, de esta manera, los ahorros Fueron considerables, lo cual, si lo calculamos por todas las computadoras del mundo, en donde se hizo lo mismo, podemos darnos una idea de lo mucho que se ganó.

Pero, además de los dos argumentos anteriores (ahorro en dispositivos de acceso directo y ahorro en tiempos de proceso), había algo que verdaderamente significó la más importante ganancia. Gracias a la estrategia del uso de nomenclaturas (posibilidad de utilizar claves en vez de nombres completos) y a la simplificación de los dos dígitos del año, permitió hacer alcanzables, desde el punto de vista económico, los dispositivos de acceso directo para la gran mayoría de las empresas privadas y de gobierno. Esto, así de sutil, a finales de la década de los sesenta, permitió hacer costeable y factible el uso del teleproceso (posibilidad de accesar y actualizar desde distancias remotas los datos de la computadora) para la gran mayoría de las empresas que ya utilizaban equipo de cómputo, y para aquellas que aún no lo hacían, les ofreció un exquisito argumento para hacerse de uno.

Pero, jqué significó el uso del teleproceso< Por un lado permitió el acceso directo a los datos, lo cual ofreció la posibilidad de actualizarlos de manera directa en el momento mismo en que sufrían algún cambio en su contenido (por ejemplo, los saldos bancarios). Este hecho revolu- cionó totalmente el concepto del procesamiento electrónico de datos que hasta aquella fecha se tenía, permitiendo el diseño de sistemas de información capaces de ofrecer a los gerentes, empresarios, directivos y funcionarios, información estratégica casi inmediata, vital para sus negocios y funciones, lográndose así darles la posibilidad de tomar decisiones oportunas y certeras, ya que contaban con información al día, y no tener que esperarse semanas y hasta meses para poder tomar alguna decisión importante (en muchos casos la información, en esas condiciones, ya no les era de utilidad por estar fuera de tiempo).

Para valorar lo que significó ofrecer a los directivos y empresarios, por primera vez en la historia, información actualizada y oportuna en la toma de decisiones, basta con imaginar cuánto les valió a las empresas adelantarse semanas y meses para decidir si era conveniente importar o exportar en un

98 CAP 3. iHASTA CUÁNDO?

momento dado algún producto; o decidir solicitar oportunamente un crédito para una importante transacción comercial, o decidir bajar o incrementar el precio de algún producto. Cuánto pudo valer decidir, en un momento dado, subir o bajar las tasas de interés bancarias; cuánto pudo valer tomar ahora, y no después, una importante decisión política que afectaba a millones de personas. Y así, infinidad de sucesos políti- cos, sociales y económicos, en donde se tomaron nuevas y mejores decisiones gracias al acceso directo a la información actualizada en tiempo real (en el momento en que sucedían las cosas).

Cuál fue, pues, el avance económico y tecnológico mundial por el hecho de haberse adelantado varios años para poner al alcance de todo tipo de empresas las enormes posibilidades del teleproceso. De lo contrario, al no simplificar los campos de datos y así hacer incosteable el uso de los dispositivos de acceso directo y proliferar la fragmentación de programas, que a su vez repercutían en el alargamiento de tiempos de procesos haciéndolos más caros, seguramente se hubiera postergado por varios años más el desarrollo de los modernos sistemas de información que se requería en aquella época bajo la utilización del teleproceso. Seguramente se hubiera continuado así por muchos años más, con los laboriosos y tardados procesos secuenciales para actualizar los datos de archivos vitales para la toma oportuna de decisiones. ?Cuánto valió eso a escala mundial¿, y en su caso, ?cuál fuela influencia que aportó ese adelanto a la humanidad para acelerar el desarrollo tecnológico en materia de informática para Llegar rápidamente hasta donde estamos hoy<

SEGUNDA ETAPA $POR QUÉ SE DEJÓ EL CAMBIO HASTA EL ÚLTIMO MOMENTO^

A este respecto, actualmente se cree que todo obedeció a una negligencia desmedida de los informáticos de aquella época y, aunque efectivamente hubo cierto grado de negligencia, el haberse dejado todo para último momento tiene que ver fundamentalmente con otras razones de gran peso, con lo cual no quiero decir que se estuvo en lo correcto, sino poner al descubierto las verdaderas razones (justificadas o no) de por qué sucedieron así las cosas y no de otra manera.

Si acudimos a la historia, los años sesenta significaron una etapa sumamente acelerada en el desarrollo humano. Fue una época espléndi- da para vivir y ser joven, que estaba marcando un nuevo despertar a solo dos décadas del fin de la Segunda Guerra Mundial y de las tremendas privaciones que como consecuencia le siguieron. Por eso, pasado un tiempo suficiente de aquel cataclismo mundial, del que para entonces ya pocos recuerdos quedaban, dicha década representó el inicio de muchas nuevas cosas y de un optimismo renovado en todas las esferas de la vida: nueva música, nuevo arte, nueva literatura, nueva tecnología,


nuevas modas, en fin, nuevos descubrimientos. La ciencia se estaba moviendo como nunca, sin temores, sin límites: en 1969, el avión supersónico Concorde británico-francés daba una clara muestra de los avances; en ese mismo año, "el pequeño gran paso" estadounidense dado en la Luna, mostraba al mundo su supremacía espacial; las posibilidades de la electrónica abrían enormes puertas de desarrollo en todos los campos; las comunicaciones hacían posible acortar distancias como nunca, al grado de prácticamente eliminarlas mediante los satéli- tes en el espacio, que eran absoluta realidad y no ciencia ficción como parecían hasta pocos años antes. En esos años todo se creía posible, por insólito que se antojara.

Posteriormente, en la década de los setenta, cuando supuestamente deberían haber desaparecido los sistemas que manejaban los dos dígitos en vez de cuatro para el año, sucedió que aquel hervidero de avances a escala mundial propició un auge económico que obligó a las empresas a una lucha competitiva sin precedentes. Para entonces, y como consecuencia del crecimiento acelerado de los mercados y la tenaz lucha de las empresas por tener la mayor participación en ellos, la informática representó la herramienta más importante para ofrecer servicios de calidad y cautivar a los clientes.

La informática hizo posible cambiar eslogans tales como: "una vez salida la mercancía, no se admiten reclamaciones", pasó a ser: "la completa satisfacción del cliente o la devolución de su dinero"; la in- formática permitía conocer con acierto las necesidades de los clientes y eficientar los procesos para ofrecerles los productos que ellos reclama- ban. En consecuencia, produjo una explosión en la adquisición de equipos de cómputo y en el desarrollo urgidísimo de nuevos sistemas de información, lo cual propició una dramática demanda de programadores y analistas de sistemas, los cuales eran insuficientes en el mercado.

Por tanto fue necesario formar un nuevo ejército de programadores y analistas aunque de manera precipitada e improvisada por quienes ya estaban en las empresas (la mayoría de ellos, programadores y analistas tradicionales formados improvisadamente dentro de las propias empresas) y que eran quienes habían desarrollado y programado los anteriores sistemas, cuyo modelo que tuvieron para tomarse como base para el desarrollo de los nuevos sistemas era precisamente la forma de como estaban desarrollados los primeros. Incluso, dado que ellos eran (analistas y programadores tradicionales) los que sabían los detalles más íntimos de los sistemas iniciales, en gran medida aprovecharon partes importantes de los viejos programas para desarrollar los nuevos sistemas, es decir, con formatos de registros y programas que consideraban sólo dos dígitos para el año, pues esa era la manera más rápida y económica de poder satisfacer los urgentes requerimientos de información que recla-

maban los departamentos usuarios para el logro de los objetivos de negocio de las empresas.

De cualquier manera, en ese momento pensamos que "si aguantamos, en estas condiciones, los sistemas durante toda la década de los setenta al iniciar los ochenta aún tendremos 20 años por delante para renovar- los". Es decir mucho tiempo, incluso para hacerlo de manera ordenada.

Pero, no fue así, pues dichos sistemas desaparecieron y fueron remplazados por otros nuevos más modernos (pero manteniendo sólo los dos dígitos para manejar el año), mismos que fueron creciendo y hacién- dose más complicados y confusos. Con el tiempo, quienes diseñaron y programaron tales sistemas salieron de las empresas, otros cambiaron de actividad, unos más se retiraron por la edad, y algunos incluso murieron. Llegaron nuevas generaciones de programadores en marejadas, metieron mano a los programas, cambiaron los sistemas, los hicieron más confusos, y se Fueron; llegaron otros e hicieron lo mismo (durante más de 30 años el mismo deterioro). Este tránsito de personas quizá no hubiera tenido mayor efecto si se hubiera tenido el cuidado de administrar y documentar los cambios efectuados, pudiendo dejar así historia y una realidad con- trolada de la situación de esos sistemas. Pero, precisamente por el ir y venir de aquellos especialistas improvisados, jamás existió un único responsable que pusiera orden, entonces la complicación y confusión de esos sistemas sin documentar alcanzó niveles incomprensibles e inmanejables, al grado que, si se hubiera intentado siquiera investigar en dónde había que corregir para manejar las fechas en cuatro dígitos en vez de dos, se corría el riesgo de hacer fallar los procesos que en ese momento daban servicio a millones de personas en un solo día, lo cual significaba que los servicios de las empresas, para entonces, estaban ya cautivos de la función informática

En tales condiciones de deterioro de los sistemas y de servicio ya comprometido hacia millones de clientes, la pregunta era, ?quién se iba a atrever por emprender el cambio del campo del año de dos a cuatro posiciones¿ Era entendible que nadie ¡y lo repito!, nadie quiso verse comprometido, y menos aún aparecer como culpable, con la posibilidad de afectar a millones de personas, lo cual pudo originar la quiebra de muchas empresas. Por eso, siempre existió la esperanza de que algo o alguien, por arte de magia, iba a llegar y solucionar el problema. Ningún empresario o directivo en su sano juicio podía siquiera pensar en autorizar un gran desembolso para correr una aventura que incluso pudiera poner en riesgo a una empresa o institución. Además, dentro de cualquier empresa, jquién sabía con exactitud lo que debía hacerse con sistemas tan antiguos o totalmente deformados por el manipule0 desmedido, que asegurara e1 cambio correcto¿ Pues sencillamente jnadie! Caray, qué reflejo tan real tenemos aquí sobre una total falta administrativa dentro de la función informática.

Fue mejor dejar pasar el tiempo y, con toda seguridad, el director responsable del área de informática de ese momento, para cuando tronara el cuete, ya no estaría en esa empresa, por lo que el problema sería de quién sabe quién. Además, se pensaba, el director de informática no había sido responsable de haber tomado la decisión en esa empresa para tratar el año con dos dígitos, por tanto él no tenía culpa alguna del fenómeno originado, por el contrario, hacía lo que podía para mantener el servicio informático, luchaba a brazo partido, operando sistemas mal hechos, que seguramente él podría haber desarrollado mucho mejor. Se les estaba haciendo un favor a esas empresas al operar y mantener el barco a flote, con sistemas de tan baja calidad. Así se pensaba y así se actuaba.

Pero llegó 1995, cerca del año 2000, y las empresas seguían operando bajo el control de muchos sistemas constituidos por cientos de programas, que en conjunto sumaban varios miles, sin documentación, sin un entendimiento certero de su interrelación, y mucho menos de cuáles y en qué partes habría que modificarse para manejar los cuatro dígitos del año en campos de la fecha, en vez de dos. Cuando parecían muchos años para la llegada del año 2000, ahora ya era inminente actuar y los papeles se invertían: necesariamente había que emprender la aventura para modificar los sistemas viejos y no documentados, sin importar el costo ni los riesgos que se tuvieran que correr, por grandes que éstos Fueran para las empresas. Hacer el cambio representaba la única posibilidad de evitar la hecatombe mundial anunciada. Dicha aventura, bien manejada, era la única opción de salvación para la mayoría de las empresas.

+Cuáles pudieron haber sido las consecuencias en el año 2000, de no haberse resuelto el problema$

jPor qué era necesario el cambio si resultaba tan costosoC Las razones eran serias. El panorama resultaba tan alarmante, que incluso la ONU tomó cartas en el asunto y convocó una Reunión Mundial de Coordinadores de Comisiones Nacionales para la Conversión Informá- tica Año 2000, cuyo propósito fue estar al tanto del comportamiento y situación que guardaba cada país con respecto al problema llamado YZK. Se identificó a escala mundial que las áreas que corrían mayor riesgo de conflicto con el nuevo milenio, eran las de telecomunicaciones, electricidad, energía nuclear, petróleo, gas, finanzas, tráfico aéreo, puertos y transportación marítima. En consecuencia, si en cualquiera de estas áreas hubieran ocurrido problemas, en cascada, los problemas se habrían generalizado prácticamente a todas las demás.

102 CAP. 3. im .- - -

De entre muchos efectos que se hu6ier:n tenizo, si no se hubiera hecho el cambio, un ejemplo es el manejo de dinero. Veamos imaginariamente el siguiente caso. Dentro de los programas de cornpu- tadora, para calcular cuánto debe pagar una persona o empresa a la que se le otorgó un crédito (un préstamo), se toma como base: la fecha de origen del crédito, la fecha del pago más reciente y la fecha actual. Esto mismo, de manera muy simplificada, en un sistema bancado se hace de la siguiente forma:

Vamos a suponer que a una persona o empresa se le prestó, a principios de 1989, una cantidad de $300 000, a un interés anual de 20 %, a un plazo de 15 años. Entonces, dicho préstamo terminaría de ser cubierto hasta el año 2003, o sea que, a principios del año 2004, el préstamo ya no existiría, ya que el último día de 2003 (de no existir retrasos en el pago) el préstamo habrá sido cubierto totalmente.

No existiría ningún problema en calcularle sus pagos hasta 1999, ya que hasta ese año (1999), y hacia atrás, los dos primeros dígitos del año siempre fueron "19". Por lo ue si, en el caso de este ejemplo, la fecha 9 del préstamo fue en 1989, e programa hubiera tomado de la computadora o de los datos el 89 y colocaba siempre antes de estos dos dígitos el 19, para llegar a 1989, y así en todos los años hasta 1999.

Entonces, para saber cuántos años del préstamo había pagado la persona o la empresa, y en consecuencia, cuántos años le faltaban por pagar, se calculaba tomando como base la fecha del préstamo (en nuestro ejemplo 1989) y la fecha actual. Estando en el año de 1999, el cálculo implicaba la siguiente resta:

Año actual (1 999) - año de origen del réstamo (1 989) + 1 = número d de años paga os (1 1)

Por tanto:

Plazo del crédito en años (15) - cantidad de años pagados (11) = número de años por pagar (4)

Si dividimos el monto del préstamo de $ 300 000 entre 15 años de plazo, la cantidad por pagar sin considerar los intereses sería de $20 000 anuales. Por lo que, en nuestro ejemplo, en 11 años pagados ya se habrían cubierto $220 000, faltando por pagar la cantidad de $80 000 en los cuatro años restantes.

Lo anterior era lo correcto. Pero qué sucedería a partir del año 2000, si no se hubieran corregido los programas para considerar los cuatro dígitos del año y se dejaran considerando sólo los dos últimos dígitos.


En el momento en que los calendarios marcaran el año 2000, habría sucedido que los dos últimos dígitos iban a ser 00, y si los programas consideraban automáticamente el 19 (mil novecientos...), la fecha de entonces se iba a convertir en 1900. Por tanto, las operaciones anteriores para calcular el número de años pagados y por pagar, se hubieran comportado como sigue:

Año actual 2000 (convertido por los programas en 1900) - año de origen del préstamo (1989) + 1 = número de años pagados (- 88)

como valor negativo o también (90) como valor absoluto, dependiendo del tratamiento que el programador le había dado.

Por tanto:

El resultado de restar 1900 - 1989 + 1 = 88 o 90, o sea una cantidad negativa o positiva, bien se iba a convertir a favor del deudor o en su contra, por lo que, si el tratamiento de la operación anterior, por parte del programador, fue considerar una cantidad negativa (- 88), entonces al aplicar la siguiente resta algebraica, se obtendría:

Plazo del crédito en años (15) - cantidad de años pagados (- 88) = número de años por pagar (1 03), en contra del deudor.

Resultante de 15 - (- 88) = 103

Ahora, 1 03 años x $20 000 = $ 2 060 000 que falta por pagar el deudor.

Por otro lado, si el resultado de la operación mencionada había sido tratado como cantidad absoluta positiva (90 años), se habría obtenido lo siguiente:

Plazo del crédito en años (15) - cantidad de años pagados (90) = número de años por pagar (- 75), a favor del deudor.

Resultado de 15 - 90 = 75 (como si los hubiera pagado de más) Ahora, 75 años a favor del deudor, que supuestamente pagó de más,

por $20 000 por año = $1 500 000 (que pagó el deudor supuestamente de más y que habría que reembolsar).

Como puede apreciarse, la cantidad de errores de cálculo que se hubieran originado al no corregirse el tratamiento de la fecha en una gran cantidad de programas, hubieran producido una catástrofe fi- nanciera.

104 CAP 3. iHASTA CUÁNDO?

El lector podrá apreciar que, visto así el problema, el panorama resulta ser distinto a lo que se dijo en el nivel popular. La falta administrativa de la función informática desempeñó también una función preponderante en esta historia.

A partir de mis observaciones actuales concluyo que pese a esta gran experiencia, ya familiar para todos nosotros, pareciera ser que no nos dejó un gran aprendizaje. Le invito, amigo lector, a comprobar que en la gran mayoría de las empresas (sobre todo medianas y pequeñas, pero también en muchas de las grandes), el aspecto informático se sigue manejando de manera improvisada, muy lejos de lo que pudiera considerarse como administración de la función informática. Le propongo que acuda a cualquier empresa, de preferencia mediana o chica, y observe la realidad de lo siguiente: descontrol y conhsión en archivos; programas inseguros probados sólo superficialmente; fallas de procesos constantes; falta de documentación; capacitación sin objetivos claros; diseño de sistemas al vapor; operación de paquetes hechos un caos; incongruencia de los procesos informáticos con respecto a los reales objetivos de negocio de la empresa; despilfarro computacional a mares; incongruencia entre la operación de los procesos de trabajo y los sistemas de información; procesos de trabajo burocráticos faltos del real aprovechamiento informático; etc. Esto sólo por mencionar algunas de las muchas deficiencias informáticas.

Ya no es extraño que cuando platico con empresarios acerca del tema de la administración de la función informática muchos de ellos inmediatamente se quejan de que les cuesta demasiado la informática, que invierten demasiado en tecnología y que no ven beneficios importantes congruentes con dicha inversión o reflejados directamente en el crecimiento de sus negocios.

Mi apreciación directamente en las universidades y tecnológicos es que pareciera ser que quienes determinan los contenidos de las materias ya no creen en la efectividad a que supuestamente debería conducir el ejercicio del término administración.

Lo menciono porque me sucedió que a partir de 1998, por vez primera fui enterado que este libro se tomó como base para el diseño de una nueva materia en el nivel profesional llamada "Administración de la Función Informática". Me enteré por primera vez en el Tecnológico de Villahermosa, Tabasco (y después en muchos más en el resto de la República), donde he impartido varias conferencias sobre el tema. Recuerdo perfectamente el entusiasmo que causaron mis conferencias entre los miles de alumnos que asistieron a ellas, que en esencia es para


ellos para quienes escribí a AFI y no para los informáticos tradicionales quienes ya dieron lo que tenían que dar y ni por asomo tendrían el deseo de volver a empezar un nuevo ciclo de desarrollo inforrnático dentro de nuestro país bajo las propuestas de AFI. Por eso, sé perfectamente que mis mejores aliados para consolidar los beneficios de AFI dentro de las empresas (que ya los reclaman a gritos) son precisamente los ahora estudiantes. Cuando platico con ellos les digo que me gustaría que vieran a AFI no necesariamente como un nuevo concepto (que en sí hoy ya lo es), sino mejor aún, como un movimiento, porque desde mi punto de vista, un movimiento no se actúa sino que se contagia. Y precisamente esto es lo que se necesita para proyectar los beneficios que ofrece MI.

Me he referido anteriormente a la aversión que sobre el térrnino administrar se ha venido desencadenando de un tiempo para acá. Quizá esto lo he detectado claramente, porque precisamente lo he utilizado como una palabra que forma parte de mi concepto administración de la función inhormática, lo cual me ha llevado a entablar algunos debates con colegas de la carrera y académicos que le dan un sentido distinto. Por eso, quiero aclarar que lo que para ellos representa el término administrar, dentro de AFI, para mí no significa lo mismo. Si no Fuera así, entonces cuál sería mi contribución dentro de MI , al no sustentarlo con una proyección distinta. A aquellos que se resisten a creer en la administración como función, les pido que aprecien la diferencia de mi enfoque y probablemente los convenceré de una nueva realidad. Pero, también les digo que, desde el punto de vista de su aversión, de alguna manera razón no les falta, porque comprendo perfectamente que lo que en algún tiempo Fue la panacea para crear control dentro de las organizaciones, las personas y las necesidades cambiantes de las condiciones bajo las que tenemos que vivir al paso del tiempo, nosotros mismos nos hemos encargado de ir desfigurando, y es por eso que hoy, a la luz de un mundo globalizado (mejor diría yo convulsionado), administrar bajo la visión tradicional en el sentido de gobernar o regir o cuidar, como se define en el diccionario, resulta insuficiente para satisfacer las realidades de hoy. Entonces, dentro de AFI, administrar no significa lo mismo que de la manera tradicional. Pero, hay toda una historia atrás de este nuevo enfoque, misma que a continuación voy a resumir.

Cuando estuve en la ciudad de Villahermosa, Tabasco, aprovechando mi estancia en aquel lugar, fui invitado a una importante universidad de aquella región donde se organizó un congreso de informática. Se acordó que yo impartiera la segunda conferencia, la cual versaría sobre la definición que le doy al aspecto administrativo de la Función informá- tica (AFI).

Esto que relato sucedió a inicio del segundo semestre de 1999, cuando el tema de las consecuencias del problema llamado Y2IZ estaba

en efervescencia, y precisamente la conferencia previa a la mía trataría sobre dicho asunto. Para no correr el riesgo de sufrir algún retraso, asistí a esa primera conferencia, así estaría listo al finalizar aquella para impartir la mía. Después de una breve inauguración, nos propusimos escuchar al primer conferencista, quien resultó ser profesor de uno de los tecnológicos de mayor prestigio en el país, quien al ser presentado, pese a que parecía ser demasiado joven, me di cuenta que poseía un currículum impresionante. En su currículum se mencionó que, a parte de ser catedrático e investigador, había participado en el nivel internacional en distintos comités en representación de la institución educativa donde laboraba, y por si fuera poco, tenía un cúmulo de diplomados, aparte de maestría y doctorado. Me sentí honrado de participar junto a un personaje de semejante nivel. Echando mano de su habilidad como expositor, inició con mucha fluidez su exposición. Todo marchaba normal, hasta que (no supe si porque no sabía que yo me encontraba ahí o precisamente porque lo sabía), en un momento de su exposición, sin que viniera al caso, de manera completamente brusca, dijo: "Por cierto, tengo entendido que después de mí, les van a hablar sobre la Adminis- tración de la Función Informática, y yo quiero ver si, en una empresa, donde todo urge para hoy, les va a dar tiempo de estar administrando, ija!" Terminó su exposición aquel joven y desapareció apresuradamente, y no lo volví a ver, pero me hubiera gustado explicarle con detenimiento mis conceptos y puntos de vista sobre la dirección que doy al enfoque administrar dentro del factor AFI. Seguro le hubiera cambiado su percepción, además de serle útil la aclaración para sus clases. Por eso, ahora quiero dárselo a usted amigo lector y verá qué distinto suena visto desde mi lado, comparado con el de aquel joven doctor.

Aunque es incómodo escuchar una aseveración equivocada respec- to de lo que uno realmente quiere decir, no me alteró el comentario de mi colega por lo que dijo, a pesar de la, pudiera decirse, forma "grosera" como lo expresó. Pero, sí me incomodó que lo mencionara un joven supuestamente tan preparado que, a pesar de tantos títulos, se quedó estacionado en el pasado. Esto sí me afecta, sobre todo, porque lo que escribo a través de M I intenta hacer reaccionar a los jóvenes en contra de prácticas atrasadas que ya no resultan útiles dentro del contexto actual. Si el comentario hubiera salido de un catedrático de edad avanzada, hubiera creído simplemente que no estaba actualizado, y ya, pero lo expresó un joven cuyo trabajo consiste en enseñar a otros más jóvenes que él, y entonces digo: "qué visión de las cosas tiene, qué intentará dejar ver a aquellos a los que enseña", y eso sí que es grave.

Seguramente cuando leyó en el programa de conferencias lo referente a la "Administración de la Función Informática", asoció el término administrar con: burocratizar, retardar, bloquear, estorbar, tramitar,

mucha gente, confusión, y todo lo que hace que las cosas nunca terminen de realizarse, y por eso dijo: "...quiero ver si en una empresa donde todo urge para hoy, les va a estar dando tiempo de administrar, ija!" No creo que administrar sea algo malo como lo quiso hacer notar aquel joven al referirse al término tradicional (que para mí es tradicional, pero no despectivo como lo verá dentro de AFI), y además no es el que yo quiero decir dentro de AFI, luego entonces, seguramente en la mente de aquel joven estaban los pensamientos tradicionales de "há- ganse las cosas rápido, como sea, ipero ya!, no importa cómo queden, después, ya veremos". ¡Sí!, evidentemente que así piensa él, administrar como algo dañino. ¡Caray!, no me dejó explicarle que, administrar, dentro de AFI, no significa lo que piensa él, y el problema es que, mientras nadie le quite de la cabeza su mala percepción, la seguirá arrastrando, y peor aún, difundiéndola a otros jóvenes que van a creer en él. ¡NO, por favor! Ojalá y no lo siga haciendo.

Como puede ver, amigo lector, esto sí que es un problema y por eso deseo que usted quede correctamente enterado acerca de mi enfoque actual sobre administrar dentro de AFI.

Para empezar, diré que si vemos la historia del hombre, encontrare- mos que cuando éste era nómada y lo único que le preocupaba era su supervivencia, su máxima prioridad consistía en alimentarse, incluso cuando aprendió a cultivar sus alimentos. Después, en pleno auge de la época de la agricultura, cuando se estableció y aprendió las bondades del comercio, también aprendió la necesidad de contabilizar y registrar sus transacciones. Conforme el comercio se extendió, poco a poco aquellos que producían y luego vendían a otros que a su vez distribuían, surgió la necesidad de establecer mecanismos primitivos de planeación para saber qué y cómo hacer con las diversas mercancías para hacerlas

'

llegar a los consumidores y resultar en negocio. Así, para dichos planes, también hubo necesidad de establecer a su vez otro tipo de mecanismos de control ("administrativos"), para asegurar que lo que se planeaba hacer, en la práctica efectivamente sucediera.

Posterior a la agricultura, en la época industrial en donde las máqui- nas para producir en serie inundaron el mundo, por tanto los mecanismos rudimentarios de administración fueron perfeccionándose cada vez más para obedecer a un dinamismo vertiginosamente acelerado de hacer negocio. Así, al paso de las décadas, surgieron también aceleradamente infinidad de nuevas formas de trabajar y de organizarse dentro de las industrias, lo cual dio lugar a nuevas teorías administrativas y, por supuesto, a nuevas especialidades profesionales que las convirtieran en realidad.

No obstante, del aumento desmedido de la población mundial y la necesidad de satisfacer las nuevas demandas de la humanidad, con mayor celeridad que antes, los mecanismos administrativos tradiciona-

108 CAP 3. ;HASTA CUÁNDO?

les fueron sofisticándose aún más, sobre todo urgidos por el colosal aumento de información que había que manejar, registrar y procesar. Así, surgió la necesidad de inventar máquinas de apoyo para el proceso de datos, desde las mecánicas, después las electromecánicas, hasta las puramente electrónicas (las computadoras). Efectivamente, máquinas exclusivamente de apoyo, para ayudar a procesar rápidamente tal cual como estaban hechos los procedimientos administrativos establecidos. Y así, hasta la fecha, donde los mecanismos administrativos forman parte esencial de la forma de trabajar de la humanidad, mecanismos eficientes y deficientes, muchos de ellos incluso aberrantes desde el punto de vista de quienes reciben los servicios, pero necesarios según la óptica de los individuos que los establecen.

Ahora bien, desde la perspectiva de AFI, la administración tradicional así fue y así tenía que ser, y en mucho así sigue siendo, mientras no se entienda y se afronte el hecho de que ya hay suficiente tecnología capaz de permitirnos mirar hacia otras direcciones. Partiendo de esta realidad, así es como establezco un nuevo enfoque para la administración adicional al tradicional y congruente con la modernidad que hoy nos acoge mediante el fabuloso potencial de la tecnología disponible, que no existía antes cuando se instrumentaron los mecanismos administrativos de otros años.

Acepto que aquel joven, en un momento dado, haya percibido los vicios que, a lo largo del tiempo, se vincularon a los procesos administrativos, bajo el influjo de la burocracia; y entiendo también que, durante su experiencia laboral y académica fue lo que quedó arraigado dentro de él, por lo que, incluso pudiera darle un grado de justificación a su idea desvirtuada, porque efectivamente, a través del tiempo, las organizaciones, queriendo administrar sus procesos de trabajo, desen- cadenaron en un abuso desmedido de controles que poco a poco fueron revirtiéndose en burocracia. Pero, en lo que no estoy de acuerdo con él, es en que crea que, porque él lo ve así todos los demás tengamos que seguir viendo lo que él no ha sido capaz de desprenderse.

Por eso ahora le explico que este problema de burocracia se gestó hace ya más de un siglo, allá en la época de la Revolución Industrial, cuando no había empresarios, ni líderes, ni organizaciones, ni administradores, ni informática, y mucho menos, una historia en dónde apoyarse para razonar sobre lo que la administración debía ser. Es más, en aquel momento tampoco existían carreras profesionales diseñadas para enseñar todo eso. La historia nos narra que nuestros antecesores tuvieron que ir haciendo todo eso, construyéndolo paso a paso, cargando además dos grandes dificultades; sin un modelo previo en el cual apoyarse y sin una dirección certera hacia dónde dirigirse. Pero, como dije, ahora existe tecnología y recursos tan poderosos que en aquel entonces ni soñando se podían imaginar, los cuales paradójicamente

surgieron del aprendizaje que dejaron todas aquellas carencias, y que hoy nosotros, además de toda una moderna infraestructura tecnológica, también contamos con una historia rica en enseñanzas con las cuales podemos apoyarnos para identificar por qué sucedieron así las cosas y no de otra manera. Hoy ya no existe justificación para seguir viéndolo como antes, porque ya se pagó el precio de todas esas novatadas, necesarias para aprender. Hoy tenemos un conocimiento certero, antes no lo sabíamos. Ya no tenemos por qué seguir cautivos de la burocracia, tal cual como fue construida (por haber sido un mal necesario, por vicios, por no haber tenido a la mano otros recursos, o por lo que sea), y mucho menos, pemitir seguir despilfarrando dentro de ella el potencial tecnológico con el que ahora se cuenta.

Es decir, si por falta de, lo que haya sido, con el tiempo se diseñaron procesos administrativos deficientes, por qué seguirlos automatizando tal cual, por qué seguir aferrados a una visión administrativa ya desgas- tada e inoperante. Qué lástima, que un joven con tanto potencial se haya conformado y estacionado en aquel pasado, como si ya hubiera bajado la cabeza, resignado a aceptar la continuidad de lo tradicional. Me aterra sólo de pensar en cuántos jóvenes estarán pensando igual que él, y lo peor, a cuántos más en sus clases los estará contaminando con esa imagen agachista. ¡NO, por favor!, que no lo haga. Por eso insisto en que, si hubiera podido aclararle un poco mi concepto sobre administrar dentro del contexto de MI, seguramente hubiera podido evitarle continuar arrastrando junto a él ese desastroso panorama.

Por eso quiero dar un nuevo horizonte y sólo pido que no se eche en saco roto. Esto que trasmito puede ser de mucha utilidad dentro de la carrera profesional del inforrnático actual.

En México ha llegado el momento de ampliar el espectro de posibilidades sobre la manera como podemos aprovechar a la informática. Es tiempo de ir más allá de lo que hasta ahora hemos hecho con ella, desde el punto de vista aplicativo. Esta percepción, también de paso, debe servirnos para concientizarnos respecto de que en un país como Méxi- co, efectivamente somos libres para usar como queramos a la informá- tica, pero somos responsables de si no 10 hacemos como se debe, con cargo a nuestra conciencia profesional.

Este tipo de responsabilidad es precisamente la que he querido adoptar, la cual en esencia, fue la que dio origen a AFI. Por eso, AFI no debe entenderse como una metodología de trabajo monolítica y rígida, como si fuera una receta de cocina tradicional, cuyo propósito pudiera ser administrar los recursos de informática (que con toda seguridad es lo que instantáneamente construyó en su mente aquel joven doctor). ¡NO hombre!, hubiera sido una estupidez de mi parte continuar arraigado a los esquemas del pasado, y así, con esos fantasmas en mi mente, haber querido concebir a AFI. Por qué tendría que haber partido de un


esquema desgastado e inoperante como se ha visto a la administración desde el pasado. Entonces, si hubiera actuado así, cuál habría sido mi contribución al concebir a AFI, que hiciera posible que ahora se encuentre ya aceptada como una materia profesional, y también, cuál podría haber sido la aportación de AFI hacia los informáticos y administradores de hoy. Por supuesto que ¡no!, dentro de AFI, no se ve a la adminis- tración como algo para "controlar" a la informática; administrar para AFI, es administrar a la informática para aprovechar su potencial y no despilfarrado como hasta ahora ha sido. Por favor, cáptese la cobertura actual que AFI le da al concepto de administrar:

Concepción tradicional Concepción propia de AFI

Administrar para: Administrar para:

Controlar Obtener Burocratizar Aprovechar Estorbar Integrar Retardar Inventar Aplazar Descubrir nuevas posibilidades Etcétera Etcétera

RESUMEN

En tanto que los infomáticos actuales no se desprendan de la influencia de los informáticos tradicionales, y mientras estos últimos no apoyen, como se debe, en el crecimiento correcto de los primeros, sé que proyectar en su justa dimensión mi enfoque sobre Administración de la Punción Informática va a seguir avanzando pero, a paso de carga. El problema es que la dinámica de un mundo ya globalizado nos está comiendo el escaso tiempo que pudiéramos tener para reaccionar y metemos de lleno a la lucha por ocupar un lugar ahí mismo, en los eventos del siglo m.

Una pequeña, pero significativa, aportación que quisiera hacer a los jóvenes informáticos de hoy, la encuentro, y así se las entrego, en una nueva forma de ver y entender al aspecto administrativo que toco dentro de AFI.

Si bien dentro de AFI hablo sobre adminstración, no lo hago en el sentido tradicional, sino más bien dentro de un enfoque que obtuve como consecuencia de haberme dado cuenta de que mucho del enorme potencial informático lo estamos despilfarrando (por ejemplo, encuentro que una gran cantidad de empresas siguen utilizando a la informá- tica simplemente como un instrumento de apoyo administrativo y de control, y es la hora que no han logrado vincular ese exquisito potencial

RESUMEN 1 1 1

directamente como aporte de sus procesos de trabajo, como una estrategia operativa para hacer negocio), y por eso, cuando acuñé a MI, y dije que era vital administrar la función informática, en esencia lo que quise decir es que, aparte de controlar de mejor manera la infraestructura informática, lo realmente importante dentro de este enfoque sobre administrar, era administrar a la informática no tanto para controlar, sino mejor aún, para aprender a obtener de ella (de la informática). Por eso dentro de AFI, más allá de administrar para: controlar, burocratizar, estorbar, retardar, aplazar, y todo aquello que, por abuso de la adminis- tración tradicional, hace que las cosas nunca salgan o se dificulten más allá de lo tolerable, está el administrar para: aprovechar, integrar, inventar, promover, descubrir, resolver, proyectar, reinventar, y todo aquello que haga evolucionar las cosas para hacerlas convivir dentro de las realidades de hoy. Ni más ni menos.

La administraclón de la fu~nción informática: una actlvldad urgente

Problema

La administración de la función informática de las empresas reclama una carrera profesional específica, necesaria, vital y urgente, para el desarrollo del país.

Las tecnologías de la informática y las comunicaciones han modificado de manera importante la forma de trabajar de toda la humanidad. La dependencia que tenemos en la actualidad de la telemática es evidente; sin embargo, los sucesos han ocurrido con tal rapidez que se requiere un análisis Formal para comprobar la magnitud de esta dependencia. Una manera drástica, pero objetiva de ilustrarla, sería imaginar lo que sucedería si desde este momento permanecieran desconec- tadas todas las computadoras en el mundo. Los efectos serían más graves que los causados por una guerra. De inmediato, quedaríamos sin transportes ni comunicaciones, los bancos cerrarían y no habría dinero disponible, las transacciones comerciales quedarían práctica- mente anuladas, la mayoría de las empresas dejarían de prestar sus servicios y muchas otras detendrían su producción, grandes redes de suministros de energía eléctrica quedaríqn desactivadas, los suministros de agua dejarían de operar, millones de personas quedarían inactivas, etcétera.

Lo anterior seguramente no sucederá, pero nos permite evaluar la importancia de las computadoras. Y si bien no llegará a suceder en tan

UNA ACTIVIDAD URGENTE

gran escala, es innegable la frecuencia con que somos víctimas de los errores que se cometen en los centros de cómputo. $Quién no ha perdido horas esperando a que se restablezcan los servicios de algún banco para cobrar un cheque¿ $Cuántas veces no hemos acudido a aclarar un recibo de cobro emitido erróneamente4 Miles de trámites han quedado pendientes por falta de información oportuna.

Si cuantificáramos en dinero el costo de esos errores, nos daríamos cuenta de que son quizá los errores más costosos actualmente. Un error de este tipo, aunque parezca insignificante, afecta a mucha gente en sóIo un momento, en razón del servicio masivo que se da.

Lo anterior obliga a pensar que algo está sucediendo en el ámbito inforrnático. Mejor dicho, siempre ha sucedido, pero ha sido tan sutil que pocos nos hemos percatado de semejante riesgo. No es admisible que si la Función del área de informática es simplificar las labores administrativas, éstas en muchos casos terminen por ser más com- plicadas.

Mis actividades como asesor en informática de las instalaciones más grandes del país me han demostrado que la causa real de estos problemas está en un bajo nivel administrativo de las áreas de informática. Confieso que no Fue fácil llegar a esta conclusión; tomó muchos años de investigación. Sin embargo, antes de adentramos en este punto, fijemos nuestra atención en lo que es el área de informática, ya que esto permitirá una valoración más amplia del problema administrativo que allí ocurre.

El área de informática representa una entidad dentro de la organiza- ción, la cual tiene como objetivo satisfacer las necesidades de información de la empresa, de manera veraz y oportuna. Su función primordial es complementar la labor administrativa para hacerla más segura, fluida y así simplificarla. E1 área de informática es responsable, entre muchas cosas más, de centralizar, custodiar y procesar la mayoría de los datos con los que opera la empresa. Prácticamente todas las actividades de los demás departamentos se basan en la información que les proporciona dicha área. La toma de decisiones depende en gran medida de la capacidad de respuesta del proceso de datos. Por lo anterior, casi no se escatima la inversión para proveerla al área de informática del equipo técnico (material y humano) necesario. De hecho, en la mayoría de las organizaciones el área de informática absorbe la mayor parte del presupuesto. La importancia que tiene el área de informática dentro de la organización la coloca en una posición que influye incluso en una gran parte de las decisiones administrativas y de proyección de las empresas.

Como puede apreciarse, el área de informática es uno de los engranes vitales dentro de la maquinaria organizacional; permite que muchos otros engranes se detengan o funcionen sistemáticamente. De hecho, la efectividad del área de informática significa la culminación de la siste-

CAP. 4. UNA ACTIVIDAD URGENTE

matización de la empresa. El análisis y el diseño de sistemas de in- formación implican un alto grado de eficiencia administrativa dentro de la organización. Se puede afirmar que la sistematización reclama que los mecanismos administrativos de la organización estén claramente establecidos.

Hasta aquí todo va bien. Es conveniente, o más bien, indispensable para el área de informática hacer lo necesario antes de iniciar el análisis y diseño de los sistemas, para que la empresa adquiera conciencia sobre lo que significa un nivel administrativo eficiente. Pero aquí surge una pregunta: $Está preparada a su vez administrativamente el área de informática para asumir su gran responsabilidad<

La experiencia que he adquirido durante más de 20 años en el ámbito informático me ha demostrado que pocas áreas de informática están eficientemente administradas. En la mayoría existen serios problemas al respecto. La falta de administración conlleva a un despilfarro de los recursos de cómputo, tanto humanos como materiales. He observado que la causa más frecuente de los errores que se cometen en el área de informática es precisamente su falta de administración.

He realizado auditorías técnicas en muchas empresas para detectar innumerables deficiencias en el área de informática. Al principio era relativamente rápido encontrar las causas individuales de los errores e implantar los correctivos. Si bien mejoraba en gran medida la operación y se resolvían temporalmente los problemas y, durante un tiempo todo parecía estar bajo control, después, errores que no se habían presentado surgían como por arte de magia. Esto me inquietó, porque parecía que nunca podríamos adelantarnos, o por lo menos, amortiguar las consecuencias de tales errores.

Dediqué mucho tiempo para encontrar un método realmente efectivo que cubriera la mayoría de las posibilidades de solución de errores previamente identificados; pero a medida que avanzaba en el análisis, concluí que era imposible encontrar un método único realmente satisfactorio, porque mientras se ajustaba a la solución de cierto tipo de errores, por otro lado resultaba incongruente como solución de otra clase de errores; es decir, la solución integral no podía enmarcarse en una sola estrategia momentánea.

Decidí cambiar mi método de análisis del problema. Mientras no conociera las causas originales que habían propiciado esta situación, sería muy complicado encontrar una solución efectiva y, sobre todo, permanente. Me imaginé que esas causas deberían estar en el historial mismo del área de informática. Dado que en ese tiempo asesoraba a una de las instalaciones más grandes del país, pensé que ésta era un excelente prototipo con el cual podía iniciar la investigación. Con la ayuda de los directivos obtuve toda la información posible y encontré lo siguiente:

UNA ACTIVIDAD URGENTE 115

1. La organización del área de informática 10 años antes, contaba con los siguientes departamentos.

Análisis y diseño de sistemas. Unidad de programación. Unidad de operación. Soporte técnico.

El departamento de análisis y diseño de sistemas se encargaba de definir los programas de cada sistema. Elaboraba un documento bien estructurado en donde se encontraba lo concerniente a cada programa y lo enviaba al departamento de programación.

En el departamento de programación se estudiaba la definición de cada programa y se aclaraban dudas con el analista correspondiente; se procedía a elaborar el programa y se regresaba al analista una carpeta con los resultados de la última prueba y la lista fuente del programa. Como los datos prueba habían sido definidos por el analista, las cifras de control eran verificadas con facilidad por éste, quien había considerado todas las posibilidades de combinación de datos a las cuales se apegaría el programa en producción. La carpeta enviada al analista formaba parte de la documentación del sistema; otra carpeta propia para la operación del programa se entregaba al departamento de operación.

El departamento de operación mantenía estrecha comunicación con los analistas de sistemas y con los usuarios para determinar los calendarios de producción.

Finalmente, el departamento de soporte técnico se encargaba de mantener en operación el sistema operativo y de asesorar técnicamente a los demás departamentos.

2. Cuatro años después de haber iniciado la etapa anterior, la organización del área de informática tenía los mismos cuatro departamentos; pero se incrementaron sus funciones y el personal había aumentado de 17 personas a casi 25. Los departamentos eran como sigue:

Departamento de análisis y diseño de sistemas:

- Sistemas locales. - Sistemas on line (en línea).

Departamento de programación:

- Programadores de sistemas locales. - Programadores de sistemas on line.

CAP 4. UNA ACTIVIDAD URGENTE

Departamento de operación:

- Operadores de computador. - Operadores de la red on line.

Departamento de soporte técnico:

- Sistemas operativos. - Software on line.

Por supuesto, los sistemas on line vinieron a establecer especialidades y variaron los procedimientos de control; se definieron nuevos estándares de trabajo; hubo necesidad de implantar planes de capacitación; el número de usuarios se incrementó; los calendarios de trabajo variaron notablemente porque algunos sistemas batch (en lote) se convirtieron en on line; se incrementó el equipo de cómputo, y aumentaron las cargas de trabajo en todos los departamentos por la inclusión de nuevos sistemas y servicios.

3. Dos años después de haber iniciado la etapa anterior, la organiza- ción volvió a cambiar de la siguiente manera:


- Sistemas locales. - Sistemas on line. - Sistemas especiales (data base: base de datos). - Mesa de control.

Gepartamento de programación:

- Programadores de sistemas locales. - Programadores de sistemas on line. - Programadores de base de datos. - Mesa de control.


- Operadores de computadora. - Operadores de periféricos. - Operadores de la red on line. - Control de la producción.

Departamento de soporte técnico:


- Sistemas operativos. - Software on line. - Software base de datos.

Departamento de capacitación.

Esta nueva organización cambió prácticamente todos los procedimientos de control, métodos de trabajo, funciones, responsabilidades, cuotas de producción, horarios de servicio; hubo más usuarios, planes de capacitación, etc. Para entonces, el personal del área de informática rebasó los 40 empleados.

En el momento de Uevar a cabo mi estudio, acerca del porqué de la enorme cantidad de errores, la organización era la siguiente:


- 5 grupos de analistas especializados por tipo de sistema aplicativo; cada uno atendía sistemas locales, on line y micros.

Departamento de programación:

- Programadores batch. - Programadores on line. - Programadores de micros. - Programadores de sistemas operativos. - Programadores de base de datos. - Mesa de control.


- Operadores especializados en periféricos, computadora y red on line.

- Operadores de sistemas. - Control de la producción. - Operadores del centro de captura. - Ingeniería de instalaciones.

Departamento de asesoría técnica:

- Auditoría de sistemas. - Asesoría a usuarios.

Departamento de seguridad de datos. Departamento de capacitación. ; De artamento de método! y procedimientos.

w*~~li:wr


Para entonces, la cantidad de controles era muy complicada y confusa, las funciones y responsabilidades no eran muy claras y había desacuerdos, eran 90 empleados.

Después de la investigación, detecté que dentro de una organiza- ción (la de la empresa) había nacido otra organización (la del área de informática). Era evidente que el área de informática se estructuró por etapas muy aceleradas; que su organización se creó de manera improvisada. Pude distinguir que cada departamento se autoadministraba con una independencia casi total. Por más acuerdos que se establecían entre ellos, era muy difícil regular la función integral del área de informática. Y cuando algún departamento trabajaba correctamente, otro u otros fallaban debido a que se daban por hechas algunas actividades que ni siquiera se habían considerado, puesto que se presuponía que algún otro departamento era el responsable de ellas. De esta manera, los errores aumentaban y surgían fricciones entre departamentos. Compro- bé que el área de informática no estaba administrada.

Comparé este estudio con la situación que se presentaba en algunas otras áreas de informática y fue sencillo detectar los mismos problemas en ellas. En algunos lugares que aparentemente trabajaban bien, lo estaban logrando gracias a un tremendo esfuerzo de coordinación entre los distintos departamentos. En estos casos, diariamente se celebraba un sinnúmero de juntas de trabajo para lograr acuerdos. Esto provocaba gran consumo de tiempo en la toma de decisiones y la consecuencia era que el avance de muchos proyectos se interrumpía constantemente.

De inmediato establecí que se estructurara un departamento exclusivo para la administración del área de informática, cuyo objetivo fuera implantar un proceso administrativo completo, en el cual se considerara a la organización del área de informática en su entorno global, así como los múltiples canales de comunicación con las distintas unidades usuarias de la compañía; que estableciera puntos de control mediante los cuales se detectaran en forma oportuna desviaciones para estar a tiempo de operar correctivos plenamente predefinidos antes de que algún error incrementara los daños con el tiempo.

Demostré que por la autonomía con que trabajaba cada departamento dentro de la organización del área de informática, no sólo se entorpecía la puesta en práctica de soluciones que aisladamente se proponían para corregir ciertos errores, sino que se provocaban confrontaciones continuas entre ellos. Comprobé que innumerables acuerdos entre los distintos departamentos quedaban en el olvido por la falta de seguimiento efectivo; porque, por lo general, aun acordados los com-


promisos cada departamento establecía sus propias prioridades de trabajo, y mientras que unos estaban en posibilidades de cumplir con su parte del acuerdo, otros no, por diversas razones, justificables e injustificables.

Encontré que en actividades vitales del área de informática no había procedimientos de trabajo, lo cual originaba una alta tendencia a la improvisación y a la falta de estandarización. En algunos casos los procedimientos existían, pero no se respetaban, ya sea por negligencia o falta de actualización. La documentación en algunos departamentos era completa y práctica, mientras que en otros se carecía de ella, lo que permitía que los conocimientos y la experiencia fueran aprovechados por empleados que después renunciaban, ocasionando altos riesgos y, por supuesto, errores y pérdida considerable de tiempo hasta que los nuevos integrantes dominaban su trabajo.

Comprobé que todos estos descontroles eran cabos sueltos que siempre habían existido en el área de informática. También detecté que cada departamento tenía funciones y responsabilidades concretas en las

! cuales no estaban consideradas actividades administrativas claras y congruentes con los demás departamentos. Más bien, éstas se habían implantado con una visión personalizada de cada departamento y por iniciativa de sus gerentes, pero no con una guía general que realmente se adaptara al esquema organizacional total del área de informática.

Con todos los argumentos anteriores, irrefutables, elaboré un documento que contenía la "Estructuración del departamento administrativo del área de informática". Ese documento consideraba las funciones y responsabilidades prioritarias, de tal manera que dicho departamento hera susceptible de una rápida formación y de obtener los beneficios a corto plazo. Propuse que éste debería quedar ubicado como staff (personas) del director del área de idormática, con el fin de darle la autoridad suficiente para implantar sus estrategias y hacerlas respetar mediante un seguimiento por función y no por excepción.

Mi propuesta, a pesar de no tener argumentos de peso en contra, se tomó con mucha cautela, y por un tiempo se archivó. El área de informática siguió inmersa en graves problemas, y aunque se han realizado constantes cambios en su organización, no ha sido suficiente. Después de muchos contratiempos, actualmente mi estrategia se considera como una decisión irnpostergable.

Este libro ofrece un amplio panorama para distinguir hacia qué actividades importantes se debe encauzar la administración del área de informática. Estoy convencido de que estudiantes y profesores podrán imaginar ideas complementarias que les permitan pensar en aspectos de aplicación adicionales, que a su vez los impulsen en distintas direcciones dentro del entorno administrativo informático. Esto será de incalculable valor.

120 CAP 4. UNA ACTIVIDAD URGENTE

Es urgente reconocer que las actividades del área de informática son muy distintas (y, por supuesto, no digo que más importantes) del resto de las áreas de una empresa. Quiérase o no, esta tecnología aún es nueva en nuestro medio, y esto nos enfrenta al hecho de que tomará tiempo comprender sus beneficios, sus exigencias y, sobre todo, sus riesgos. No es admisible que algo tan delicado se deje a la deriva.

Dado el auge de la informática y su sorprendente avance, las actividades dentro del área de informática se han diversificado tanto, que obligan a que su esquema organizacional sea muy dinámico, porque aquélla origina cambios notables en lapsos muy breves. Reitero que si no se afianza administrativamente la función informática, la empresa será inestable en todo momento, y tendremos que seguir haciendo frente a innumerables errores, además de soportar sus graves consecuencias y altos costos, en perjuicio de los clientes.

¡Atención: la administración de la función informática es una actividad urgente!

Mencioné en el primer capítulo, sobre lo que años después se supo que verdaderamente impulsó a la Revolución Industrial: sin la existencia de los métodos administrativos y de control, aquello habría sido un caos y seguramente habría ocurrido un despilfarro de recursos técnicos, humanos y materiales, de magnitud tal que habría significado sin duda el derrumbamiento de dicha Revolución Industrial, por su incosteabilidad o porque los productos habrían quedado completamente fuera del alcance económico de los consumidores.

Así h e como, con el tiempo, se hizo necesaria la formación profesional de administradores de empresas (los LAE). Ahora, en lo que yo he denominado la Revolución Informática, por el gran potencial y dependencia que de esta tecnología tenemos, se requiere la formación profesional de administradores de la función informática (los MI). Sé que esto es necesario. Lo aseguro.

No se piense que lo anterior lo estoy lanzando como una propuesta vaga, por el contrario, lo digo con toda la seguridad que me autorizan mis investigaciones, y asumiendo cabalmente la responsabilidad que me confiere el ser el autor de AFI. Existen tantas evidencias claras al respecto, sobre las repercusiones que ha generado la falta administrativa de la función informática, que si pensaba haber perdido mi capacidad de asombro, cuando a lo largo de tantos años he vivido y analizado tan tremendo deterioro inforrnático, ahora me siento aterrado por lo que voy encontrando en el camino.

En afán de que el lector pueda captar la magnitud del despilfarro computacional al que nos ha llevado nuestro descuido y desatención en la administración de la función informática, quiero compartirle la siguiente experiencia, y lo invito a evaluar profundamente el alcance de los estragos que sigue generando dicho descuido y nuestra pasividad al no aceptar tan importante necesidad.

A principios de 1996 fue publicado mi Curso Integral de Compu- tación para nivel de secundaria. Por esa razón, tuve que viajar a distintas localidades del país con el fin de capacitar y dialogar con cientos de profesores de secundaria y al mismo tiempo darles a conocer el curso. Como entonces no existía en México un programa oficial para la materia de computación dictado por la SEP, tuve la oportunidad de participar en varias sesiones de trabajo junto con muchos profesores y funcionarios de escuelas e institutos, con el propósito de evaluar algunas muestras de lo que pudiera llegar a ser más tarde dicho programa oficial. En esas reuniones, ya como un método que me propuse seguir, antes de iniciar la evaluación, les formulaba la siguiente pregunta: $NO sería mejor que antes de empezar el análisis de cualquier programa, primero hiciéramos un planteamiento preciso de qué pretendemos lograr en los alumnos con un programa de enseñanza sobre compu- taciónc, y dado que por lo general no se acostumbraba empezar así las reuniones, normalmente aceptaban mi propuesta, y puesto que quien hacía tal cuestionamiento era precisamente yo, enseguida me tenía que hacer cargo de la situación y tomaba la iniciativa.

Para empezar, tomaba como punto de partida los principios en los cuales se basa la enseñanza moderna (que ya eran del conocimiento de la gran mayoría de los profesores), con la finalidad de que todos al inicio estuviéramos en la misma "frecuencia".

Todos coincidimos en que las bases principales de la enseñanza moderna eran:

a) Educar al mayor número de personas posible con la mejor calidad. 6) Desarrollar en los alumnos fundamentalmente habilidades que

les permitan controlar y manejar los cambios de la vida en una manera crítica y reflexiva.

C) Desarrollar en los alumnos habilidades para que en cualquier circunstancia de su vida sean capaces de seleccionar, recopilar, controlar, analizar y explotar la información.

También coincidimos en que, con el fin de abordar los tres aspectos anteriores, sabíamos que se tenía que seguir el siguiente orden de pasos:

a) En función del tipo de hombre que se quiere formar, es de vital importancia precisar qué es lo que se le va a enseñar.


b) En función de las tres bases principales para la enseñanza moderna ya planteadas, deben seleccionarse las estrategias didácticas para lograr los objetivos señalados en dichas bases.

c) Por último, hay que determinar con qué medios y recursos didácticos se podrán lograr los dos puntos anteriores. Aquí cabe señalar que es en donde finalmente se debe incluir la tecnología de la informática.

Al hacer algunos análisis sobre escuelas modernas de nuestro país que ya cuentan con el taller de computación en sus aulas, nos dimos cuenta que no habían seguido el orden anterior, que en vez de ello la gran mayoría se habían precipitado sin antes haber tomado en cuenta que la educación es el fin y que la tecnología es el medio. Por esto, muchas escuelas incorporaron tecnología de computación sin tener claro cómo usar esa tecnología para conseguir sus metas educativas, y una gran mayoría cayeron en la trampa al querer descifrar en qué utilizar la tecnología, convirtiendo a la educación en el medio y no en el fin por lograr. Es decir, en vez de primero proponerse encontrar la estrategia que les llevara a cubrir sus objetivos educativos e incluir en esa estrategia los recursos informáticos para conseguirlos, pensaron primero en qué utilizar la tecnología de tal manera que los llevara al logro de los objetivos, adentrándose de esta manera prioritariamente en descubrir lo que podían hacer con esa tecnología, pasando a segundo término el fin de la educación. Esta situación la he detectado en diversas escuelas, desde secundarias hasta universidades. Esto demuestra que no hemos definido políticas que permitan conocer con acierto cómo abordar, en los distintos ramos de la sociedad, el aprovechamiento de esta tecnología para el logro de los objetivos deseados. Se ve claro que los nuevos sectores (como la educación) también están iniciando una etapa de improvisación, semejante a la que vivimos los primeros informáticos, para incluir en las escuelas la tecnología de la informática. Es decir, al no contar con guías que los orienten (porque los informáticos no las hemos desarrollado), están emprendiendo ese recorrido a ciegas, tal como lo hicimos nosotros. Lo cual a su vez demuestra que seguimos sin contar con bases firmes de estudio para saber a ciencia cierta cómo administrar y dirigir correctamente los beneficios que proporciona la informática.

En este momento le pido al lector que trate de imaginar lo que costarán esos intentos improvisados y el tiempo que tomará, en este caso al sector educativo, el establecer los métodos apropiados para tomar el control y saber a ciencia cierta cuál es la mejor forma de aprovechar esta tecnología para los fines educativos en las escuelas. Muy a mi pesar, vislumbro que en vez de seguir un modelo único que contenga políticas de aplicación general y éste pueda ser tomado como guía para saber cómo hacerlo, cada escuela, así como ha ocurrido con

SUGERENCIAS DE SOLUCI~N 123

cada empresa, lo hará libremente y sin consentimiento pleno. Invito al lector a que observe este panorama, y me dará mucho gusto que me dijera que estoy equivocado. Se me ocurre que un estudio serio de este aspecto muy bien podría ser tema de una tesis importante. La invitación está hecha.

Lo anterior le ha sucedido a muchísimas empresas en donde el negocio pasa a segundo término por atender primero la tecnología, lo cual ha llevado a automatizar la gran mayoría de las actividades de la organización tal cual son, sin haberse preguntado si al contar con el potencial que da la tecnología de la informática, antes de automatizar dichas actividades, cuántas de ellas deberían cambiar en esencia (por lo cual considero que el factor AFI es un prerrequisito para la reingeniería). Aquí surge nuevamente como evidencia clara el descuido y riesgo a los que cotidianamente nos enfrentamos por la falta administrativa de la función informática, y recuerdo de inmediato aquello que mencioné en el primer capítulo de que si los procedimientos administrativos y de control en una empresa no están maduros, entonces jqué es lo que automatizan tales empresasc Ya para cerrar este comentario, quiero dejar establecida la siguiente pregunta: En vez de lo que están haciendo muchas empresas en el sentido de prohibirles a sus gerentes y empleados el acceso a internet, porque se ha detectado que dedican mucho de su tiempo a navegar en información poco provechosa, jno sería mejor que los AFI determinaran los lineamientos de control para hacer verdaderamente efectiva tal navegación en beneficio de la empresa, y encontrar nuevas estrategias de servicio, comercialización y publicidad para aprovechar el potencial que sobre esto ofrece internetG Esto nuevamente confirma que se sigue confundiendo a la informática con el fin en lugar de el medio.

Por mencionar sólo algunos aspectos del panorama de acción que deberán abordar los AFI, tenemos los siguientes:

Estoy convencido de que el desorden y descontrol con el que ha emergido el panorama informático en nuestro país ha dado lugar a que cada empresa se haya "rascado con sus propias uñas" para ir formando su esquema informático. Por esta razón, si uno observa la manera como se utiliza y aprovecha esta tecnología de una empresa a otra, habrá constancia absoluta de que se parecen en muy poco o nada, lo cual indica que desde el punto de vista informático, cada empresa es única. Incluso, he observado que dentro de una misma empresa que cuenta con varias localidades en donde hay equipo de cómputo, cada una de ellas trabaja de manera distinta a las demás. Entonces, esto obliga a un tratamiento particular también, partiendo de la base de que la informá- tica representa enfoques distintos de una empresa a otra. O sea, que debe entenderse que la informática tiene una misión específica para

124 LMK r . UNA ACTIVIDAD URGENTE

cada empresa. Por tanto, parte del trabajo de un AFI considera el planteamiento siguiente: $Cuál debe ser el alcance de la misión de la Función informática (estatutos) para cada empresa (traje a la medida), considerando a cada empresa como un ente singular en Función de sus objetivos de negocio y de servicio particulares< Ya inmersos en la singularidad informática de una empresa, lo anterior a su vez nos encamina a lo siguiente: ?Cómo se deberá vigilar el aprovechamiento de los recursos de informática (humanos, técnicos y materiales), para evitar hasta sus últimas consecuencias el "despilfarro informáticoJJ¿ $Cuál será el mecanismo de evaluación para medir el acercamiento de la misión de la función informática hacia los objetivos de negocio y de servicio marcados por los altos directivos de la empresa< ?Cómo será medido el costo-beneficio del aprovechamiento de la misión de la Función informática, para efecto de regular la inversión sobre el potencial informático requerido realmente en la empresa, según los siguientes parámetros relacionados: proyección de la empresa, dinámica organizacional, dinámica del negocio, dinámica de la competencia, tecnolo- gía disponible y dinámica del mercado<

Partiendo de lo anterior, en principio, el trabajo de un AFI consistirá en coordinar el establecimiento de los estatutos que determinen el alcance de la misión de la función informática dentro de una empresa, así como la clarificación de éstos hacia todas las unidades usuarias. Estos administradores tendrán un amplísimo campo de acción: su trabajo tendrá como base el establecimiento, la implantación y la coordinación de los mecanismos de seguimiento para que los recursos de informática (humanos, técnicos y materiales) sean verdaderamente aprovechados por la empresa en estricto apego a sus objetivos de negocio y de servicio. Serán ellos también quienes de manera sistemá- tica y sostenida evalúen el acercamiento de la misión de la función informática, diseñada para cada empresa en particular, en Función de los logros alcanzados en el marco de los objetivos de negocio y de servicio actuales, con el fin de permitir con mayor acierto la definición de la proyección de esos objetivos hacia un Futuro.

Me atrevo a asegurar que sólo el ahorro que se consiga por concepto de disminución del despilfarro informático al que tanto me he referido estará muy por encima del costo que a las empresas les implique la contratación de los MI. Además, dicho ahorro no será por única vez, éste será continuo, tal y como lo ha sido el despilfarro referido. Pero consideremos un poco las áreas específicas que estos profesionales tendrán que administrar dentro del entorno informático:

Determinación periódica de la misión de la función informática (MFI), específicamente en el tipo de negocio en donde trabaje el administrador.

Evaluación periódica del acoplamiento entre MFI-negocio. Evaluación sistemática del costo-beneficio, producto del acoplamiento entre MFI-negocio. Determinación de las acciones por emprender, según el nivel de desviación encontrado en la evaluación sistemática del costo- beneficio, producto del acoplamiento entre MFI-negocio. Implantación del método de seguimiento para cada caso de desviación encontrado, mediante el modelo de aprendizaje por seguimiento como función (MASF). Etcétera.

Y eso que no he mencionado lo muchísimo que hay que administrar en sectores todavía desprotegidos, como:

Capacitación informática en todas las áreas y niveles de la orga- nización (unidades usuarias y técnicas). Seguridad de datos (resguardo); confiabilidad de datos (integridad); acceso a los datos (confidencialidad). Negociaciones para la adquisición de software en función de nivel de aprovechamiento según el tipo de giro de la empresa. Lo anterior significa que si de 100 % de potencial de algún software, la empresa únicamente utiliza 60 % porque el tipo de negocio así lo reclama, ésta sólo pague 60 % del costo total. Preveo que si esta mecánica se establece por algunos proveedores del software, incluso bloqueándole al cliente el uso del software declarado como superfluo, éstos favorecerían a sus clientes con ahorros económicos considerables y su clientela aumentaría. Esta modalidad de adquisición de software es justa, pero a la fecha dentro del área de informática no se hace esta evaluación, y con frecuencia las empresas pagan fortunas por software poco aprovechado por no requerirse en su entorno total. Control, seguimiento y aprendizaje de las fallas técnicas que afectan el servicio de informática en cualquier parte de la organi- zación, considerando también la atención a clientes.

Y ya no es necesario seguir, pues la falta administrativa de la función informática en cualquier parte donde se enfoque la atención es evidente. Y esto no solamente lo sé yo, jtambién mis colegas!

Como es obvio, el cúmulo de acciones que estos profesionales deberán emprender es amplísimo, y si pensáramos en otras que no se han atendido o se han hecho a medias o mal, más encontraríamos. En mi percepción, es urgente a todas luces la formación de los AFI.

En este momento quisiera hacer un paréntesis, aprovechando el derecho que me otorga ser autor de AFI. Me quiero atrever a comentar

126 CAF! 4. UNA ACTIVIDAD URGENTE

una especulación que me ha inquietado recientemente, pero no por eso :

dejo de asumir totalmente la responsabilidad de lo que digo. Tiene que ver con lo siguiente.

Partiendo de mi experiencia en haber identificado que un gran porcentaje de los procesos administrativos de las empresas no son maduros, por haberse concebido de una manera informal, originando así múltiples incongruencias en la operatividad de muchos departamentos dentro de la organización (como procesos administrativos redundantes, incompletos, insuficientes, inseguros, aislados, caducos, excesivos, confusos, incosteables, etc.), he reflexionado acerca de la automatización: jqué es lo que verdaderamente han automatizado tales empresas¿ La única reingeniería que considero necesario hacer es la reingeniería de los sistemas de información. También sabemos perfectamente que, cuando los problemas no se presentan por causa de malos procedimientos administrativos, el origen se encuentra en una mala y deficiente utilización de las herramientas de informática. Así, mi espe- culación consiste exactamente en que los administradores de empresas (los LAE), que están ya trabajando o que egresan de las universidades, no cuentan con los conocimientos de informática suficientes para diseñar los procedimientos administrativos en términos de sistemas de información; y que los informáticos, que están ya trabajando o que egresan de las universidades, no tienen los conocimientos suficientes como para comprender las necesidades administrativas de la organiza- ción de modo que se aproveche eficientemente el potencial informático; o no será tal vez que lo que falta sea un AFI para llenar el hueco entre los dos primeros; y por qué no pensar que un AFI, aprovechando dicho potencial de la tecnología informática, pueda ser quien desplace definitivamente a los dos especialistas (administradores e idormáticos) tradicionales; y finalmente quizá lo que se requiere es reorientar las carreras tradicionales de administradores e informáticos, para adaptarlas a la realidad actual, en el entorno de la administración de la función infor- mática, además de egresar a los AFI. En particular, y aquí radica mi especulación, creo que aprovechando la experiencia adquirida durante décadas en el desarrollo de software integral aplicativo, disponible para cualquier tipo de negocio, aunado al potencial de hardware y las comunicaciones, el AFI sería suficiente, desplazando a las dos carreras tradicionales anteriores. Este es mi punto de vista, $cuál es el de usted colega< Sin duda este podría ser otro tema interesante de tesis. Así, pues, queda expuesta mi especulación, que no quise callar.

Aseguro que el primer tecnológico, universidad o insti w5 u o que imparta la carrera de administrador de la función informática en el nivel profesional se anotará un acierto sin precedentes, dada la urgente necesidad de estas labores (incluso de aplicación inmediata para el sector académico, como ya vimos). Afirmo que deberá darse un giro

RESUMEN

total en la formación del informático actual y del futuro, pues para el informático tradicional (programadores, analistas y otros) ya cambiaron sus funciones, incluso ahora se les califica como "aprieta teclas". Por eso, en espera de que el sector académico genere a los AFI, invito a los catedráticos de las distintas carreras de administración a que dialoguen con sus alumnos al respecto, analicen la situación y lleguen a conclusiones serias; pero también aconsejo a los estudiantes que por cuenta propia investiguen en este sentido.

Pero, voy más allá, si Fuera necesario, me apunto desinteresadamente para apoyar al colegio que decida emprender e1 proyecto de la forma- ción de los MI, con el fin de proveerlos de mis experiencias. Estimo incluso que, debido a que la función informática ya se da prácticamente en toda empresa, ya sea micro, mediana o macro, se pueden establecer dos niveles de AFI: el nivel técnico, para microempresas y algunas empresas medianas, y el nivel profesional, para parte de las empresas medianas y las macroempresas. Sé que a los AFI se les podría llamar de otra manera; pero su necesidad actual es tan real, que su formación es urgente. Sé que más temprano que tarde, estos profesionistas especializados surgirán de las aulas académicas y la única pregunta que por ahora queda en el aire es: ?qué colegio será el iniciadorz Ese seguramente pasará a la historia académica informática de nuestro país. Estoy seguro.

Es oportuno intentar describir ahora, y no definir, porque no existe una definición, lo que quiero decir con el factor AFI, ya que frecuentemente se me ha reclamado en múltiples institutos y universidades; pero permítaseme decir primero que no existe una definición porque todavía no lo considero un concepto, sino apenas un planteamiento en camino de convertirse en un concepto. Pues bien, este es mi planteamiento:

El factor AFI puede ser descrito como el mecanismo particular con que debe dotarse a cada empresa para poder establecer con toda claridad y en todo momento, el alcance y acercamiento de la misión de la función informática, a través del ciclo de crecimiento competitivo.

RESUMEN

Las tecnologías de la informática y las comunicaciones han modificado en muy pocos años (aproximadamente 50 años) de manera importante la forma de trabajar de toda la humanidad. Actualmente existe una dependencia abrumadora en el uso de computadoras, y no hay prácticamente actividad alguna que no dependa del uso de estos equipos. Sin embargo, aun conscientes de dicha dependencia, pareciera ser que no estamos aptos para hacer un uso eficiente de sus bondades, pues los errores que hemos cometido y seguimos cometiendo han

128 CAP 4. UNA ACTIVIDAD URGENTE

hecho que la poca utilización provechosa que se obtiene resulte altamente costosa.

Las investigaciones que he realizado por años para tratar de descubrir las causas de raíz que han generado el problema anterior me han encaminado a reconocer que éste existe debido a un bajo nivel administrativo de las áreas de informática, por la'manera improvisada como fueron estructuradas dichas áreas. Al no haber existido un modelo previo que indicara cómo hacerlo, lo hicimos como pudimos, sin tiempo ni bases certeras de estudio. El resuitado: un impresionante despilfarro informático.

Si a la improvisación anterior le agregamos el sorprendente avance tecnológico que ha existido, entonces podemos deducir que la brecha entre la administración que se requiere y la realidad informática que vivimos es considerablemente grande; pero esta brecha se ha hecho mayor, porque tampoco se ha querido atender la formación de administradores de la función informática. Entonces estamos en un círculo vicioso: no hay administración de la función informática porque no sabíamos que tenía que haber, y no hay administradores de la función informática porque no sabíamos que teníamos que administrar la función informática, y hay un enorme despilfarro informático porque no estamos administrando la función informática.

AFI propone, primero, convencer que necesitamos administrar la función informática y, segundo, generar profesionistas especializados en la administración de la función informática.

Según mi punto de vista, la actividad profesional enfocada a la administración de la'función informática es urgente y necesaria, el deteriorado ambiente infomático nos lo está pidiendo a gritos; pero empiezo a detectar que los efectos de no atender lo anterior se están desplazando hacia nuevos sectores, tales como la educación, en donde se ha hecho aun menos en materia de computación, y ahora que se pretende introducir estudios de computación en el nivel de secundaria, los tropiezos y la improvisación en la estrategia para hacerlo es por demás evidente, gracias a que no existe un método que lo indique con claridad, y no existe un método porque la historia nos señala que nunca ha existido, ya que no se le ha dado importancia a la administración de la función informática. Lo cual quiere decir que estamos repitiendo los mismos errores del pasado, pero ahora sabemos que el costo es altísi- mo. AFI surgió como consecuencia de que detecté esa enorme necesidad. Por eso existe este libro.

La administración de la función informática (el factor AFI) es urgente, tal como la formación de los administradores de la función informá- tica (los AFI) lo es también.

La función informática y slu relación con el ciclo de crecimiento competitivo de una empresa

Problema

Son muy pocas las empresas que distinguen con claridad la relaci6n que existe entre el esquema inforrnático y sus mecanismos operativos a través de las distintas etapas de su desarrollo y, por eso, no han podido reconocer que la informática ya no es un simple apoyo, sino una función vital.

Con base en el planteamiento anterior, me propuse escudriñar las distintas etapas por las que en algún momento deberá atravesar toda empresa. Encontré básicamente ocho fases, las cuales al relacionarlas entre sí, logré definir un ciclo, el cual denominé ciclo de crecimiento competitivo. Durante este ciclo las empresas necesariamente, si quieren crecer, competir y permanecer, deberán estar informadas. Sin embargo, encontré también que la calidad de la información con que cuentan está directamente relacionada con la madurez de sus procedimientos administrativos; mientras más maduros se tengan dichos procedimientos, mayor es la posibilidad de desarrollar buenos sistemas de informa- ción; y mientras se cuente con mejores sistemas de información, mayor será el éxito al automatizarlos e implantarlos operativamente en la organización, lo cual reditúa necesariamente en la generación constante de información de calidad. AqueUas empresas que han logrado esta situación confiable, por lo general se dan cuenta rápidamente de

CAE 5. CICLO DE CRECIMIENTO COMPETITIVO

que la informática no es un asunto de apoyo, sino de función vital. Por el contrario, las empresas (las cuales son la gran mayoría) que no cuentan con sus mecanismos operativos bien definidos, generalmente tienen que acudir a la improvisación constante, y en esas condiciones, por la naturaleza misma de su descontrol, no cuentan con un esquema informático estable y mucho menos pueden apreciar su importancia.

¡Atención! Para lograr el objetivo de este libro es de vital importancia que el lector en este momento entienda perfectamente el significado que le doy al ciclo de crecimiento competitivo. Para tal fin, lo primero que debe hacer el lector es identificar y comprender con mucha claridad el sentido que adquiere cada fase, y de esta manera poder enmarcar integralmente el funcionamiento de dicho ciclo dentro del entorno general de una empresa, para que así se preste toda la atención a cada fase operativa y su correspondencia con el esquema informático, de modo que el ciclo se cumpla cabalmente. Esta será la manera como deberá entenderse el siguiente esquema:

DESCRIPCIÓN DEL ESQUEMA

Fase 1. En esta fase, la empresa no está preparada para competir. Los directivos de la empresa saben que ésta está fuera del mercado, ya sea porque acaba de iniciar operaciones o porque está en colapso. Aquí nos atañe el colapso, y así lo manejaremos para la siguiente explicación. Saben que la razón de estar fuera es que tienen tantas deficiencias y se han viciado a tal grado, que es lo que les impide tener crecimiento dentro del entorno de competitividad, y por tal razón no cuentan en ese momento con los requisitos suficientes para mantenerse dentro de la lucha. Por tal motivo, ya no se siguen resistiendo a aceptar que se tienen vicios que impiden su crecimiento; es decir, se reconoce que están en esa situación y con ello se da el primer paso para proceder a analizar las deficiencias reconocidas y aceptadas, con el fin de conocer las razones de raíz que han puesto a la empresa en tan difícil situación. En este momento la empresa está en colapso, y se asume que sus sistemas de información no estuvieron a la altura de la calidad necesaria para haberlo detectado con oportunidad antes de sucumbir.

Fase 2. En esta fase, ya habiendo analizado la situación anterior y las razones que la originaron, se requiere y se asume que logran desarrollar un esquema claro de objetivos por alcanzar, con el fin de llegar a niveles de crecimiento que los coloque a la altura de los requerimientos de competitividad de la época que se está viviendo. En otras palabras, existe entre los directivos un ferviente deseo de entrar en la competencia. Es evidente que los sistemas de información necesariamente, por no

DESCRIPCIÓN DEL ESQUEMA

decir indispensablemente, tendrán una función estratégica vital para el logro de los objetivos establecidos.

Fase 3. En esta fase ya se han establecido los objetivos por alcanzar y es evidente el deseo de competir. Ahora, ya habiendo madurado los objetivos planteados para entrar en la lucha, se procede ala elaboración de planes de detalle que enmarquen las actividades que los lleven a superar los vicios que hicieron sucumbir a la empresa y a emprender el crecimiento hacia el logro de los objetivos ahora replanteados. En este momento ya no es un solo deseo de competir, esto se ha convertido en una firme decisión. Al establecer el plan de acción, los sistemas de información se convertirán en la herramienta básica para administrar el mismo plan de acción y los procesos operativos que se determinen para alcanzar los objetivos deseados.

Fase 4. En esta fase ya se entra de lleno en la competencia. Se determina y se pone en práctica la estrategia de competencia. El uso de indicadores de información forma parte de la estrategia.

Fase 5. En esta fase, la empresa está tratando de ubicarse dentro del entorno de la competencia. Es decir, ya dentro de la lucha, empieza a tener información de cómo se está comportando en comparación con sus competidores. Estos indicadores de información la mantienen al tanto del lugar que está alcanzando respecto de los objetivos por alcanzar. Además, la experiencia que va logrando lo colocan en posición de crecimiento competitivo; es decir, está en posibilidad de determinar los parámetros realistas de inforrnación que requiere para, ya que está dentro de la competencia, permanecer en ella.

Fase 6. En esta fase ya no es suficiente con permanecer dentro de la competencia, ahora es obligatorio sobresalir. Es el momento de ir en busca de la excelencia; es decir, ser mejor que los demás competidores. Este impulso es necesario para no decaer, pues en este momento la fuerza competitiva genera una presión constante. Todos los competidores están buscando alternativas de crecimiento que les permitan incrementar su mercado; por ello es casi seguro que los objetivos de una empresa empiecen a requerir ajustes de permanencia. ¡Es un proceso tremendamente dinámico! Por ello la búsqueda de la excelencia es algo continuo; nunca una meta. En este momento, la excelencia informática que se logre significa una valiosa arma de estrategia competitiva de vital importancia.

Fase 7. En esta fase habrá empresas que no resistan la presión constante de los competidores y empiecen a perder mercado, al grado que salen expulsadas de la competencia. Es decir, hay un decaimiento de competitividad porque sus objetivos alcanzados, cualesquiera que éstos sean, ya no son congruentes con el crecimiento alcanzado por sus competidores. Es evidente que no contaron con indicadores efectivos de información que les permitiera crear mecanismos correctivos oportunos, y no detectaron a tiempo sus deficiencias.

CAF! 5. CICLO DE CRECIMIENTO COMPETITIVO

Fase 8. En esta fase, ya fuera de la competencia, es necesario analizar y evaluar detalladamente su situación, abservando con detenimiento el cuadro competitivo que deberán enfrentar. Es obvio que el análisis y la evaluación de su situación, así como la observación del esquema competitivo, tendrán que hacerse con apoyo en sus sistemas de información. Así, después de esta revisión, habrá empresas que determinen no continuar, o sea, que acepten su colapso total y cierren sus puertas. Por el contrario, otras empresas, en vez de sucumbir, revitalizarán sus capacidades organizacionales y financieras, o sea su esquema de lucha, e iniciarán con fuerza renovada el ciclo de crecimien- to competitivo.

Como puede apreciarse, el ciclo de crecimiento competitivo es recorrido con total apego en los sistemas de información. En otras palabras, la directriz que guía e indica el crecimiento de competencia de las empresas, o en su defecto que le señala los "focos rojos", está dada por los indicadores de información con que cuenta la empresa.

RESUMEN

Cuando me ocupé de investigar la vinculación de la función infor- mática con las distintas etapas de desarrollo que necesariamente tiene que transitar una empresa, descubrí que son muy pocas las empresas que identifican a la informática como una función vital dentro de su organi- zación; por tal motivo, todavía se ¡e ve como un simple apoyo, restán- dole importancia, pero no por eso dejan de pagar un altísimo precio por el poco provecho que de ésta se obtiene.

Durante mis investigaciones fue necesario identificar cada etapa de crecimiento empresarial para llegar a estar en la competencia. Pude definir con claridad ocho fases, mismas que al relacionarlas entre sí, me permitieron configurar lo que Ilamé ciclo de crecimiento competitivo, a1 cual también Ilamé "las tres ces" de una empresa.

Pude comprobar que el ciclo de crecimiento competitivo es recorrido con total apego en los sistemas de información, lo cual significa que los indicadores de información participan de manera determinante en el crecimiento y en la permanencia, o en su defecto decadencia, de una empresa, lo cual a su vez consolida e1 éxito o fracaso, que en el juego de la competencia se tenga.

- ; Ciclo de cr+miento competitivo de una empresa

v r # ' l......

La Importancia de evaluar

Problema

La mayoria de los jefes del área de informática se comprometen a entregar resultados en tiempo rbcord, sin tomar en cuenta a los que realmente hacen el trabajo.

Este problema es muy común, puesto que el nombramiento de jefe automáticamente representa "don de mando". Esto no sólo es válido en el ambiente inforrnático, sino en cualquier área operativa. Cuando se trata de dirigir obreros, empleados o peones que realizan tareas manuales, la estrategia resulta efectiva porque, por lo general, desempeñan actividades repetitivas y constantes que no representan mucho razonamiento y que, dependiendo de una supervisión muy estrecha, se ejecu- tan más rápidamente, con lo que se obtiene una mayor producción. Pero, esto no sucede en el área de informática, en donde el verdadero trabajo es resultado del factor creatividad.

Entonces, se aprecia que el "don de mando" no garantiza resultados correctos ni oportunos; sin embargo, no son pocos los jefes que creen que así obtendrán mejores logros. En ocasiones se piensa que por el solo hecho de tener un titulo académico, aun sin ser a£ín al área de informá- tica, se está en posibilidades de dirigirla, lo cual tampoco resulta cierto. Así pues, no es difícil reconocer que cuando algunos jefes aceptan compromisos para ser cumplidos en tiempos récord, lo hacen con desconocimiento del esfuerzo que eso requiere. Los resultados de esta

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

estrategia los conocemos todos: noches sin dormir, trabajo frecuente en fines de semana, sistemas improvisados e incompletos, deserción de personal, prórrogas en los tiempos de terminación o cancelación definitiva del proyecto. Los que conocemos este ambiente, de una o de otra manera hemos participado en tales maratones y sabemos muy bien que son pocos los trabajos de este tipo que han culminado con éxito. La mayoría sólo han representado pérdidas cuantiosas, tanto en tiempo como en dinero, además del descontento y la falta de motivación general de quienes participaron. Aunque también es cierto que, cuando se logra salir del apuro, el costo y el despilfarro causados no resultan tan importantes. Pero pregunto: $por qué si los informáticos podemos evitar este gasto tan desmedido, nos aferramos al desperdicio<


1. Un jefe deberá ser una persona con suficientes conocimientos de in- formática para que éstos le permitan evaluar la magnitud y complejidad de un proyecto, antes de adquirir un compromiso ante superiores o usuarios.

2. Deberá tener la capacidad técnica suficiente para desglosar en macroactividades el esquema total de cada proyecto.

3. En función de las macroactividades, él mismo deberá evaluar los recursos técnicos y humanos que se requerirán para realizar dicho proyecto.

4. Una vez evaluado lo anterior, tendrá los elementos suficientes para determinar si cuenta con dichos recursos. En caso de contar con éstos, pasar al siguiente punto; de lo contrario, deberá tomar una posición sincera y comunicar a sus superiores la situación.

5. Si cuenta con los recursos necesarios, la situación es más cómoda; sin embargo, antes de comprometerse a dar fechas de terminación, deberá asignar las macroactividades al personal que designe, y dejar que ellos sean quienes, al descomponer cada macroactividad en actividades de detalle, determinen las fechas de terminación; y así, al conjugar todas éstas, tendrá una visión más realista del periodo total requerido para la terminación completa del proyecto.

6. Es conveniente destacar que cada actividad resultante del desglose de las macroactividades deberá apegarse a la política de "productos terminados"; es decir, la terminación real de cada una deberá estar representada por algo tangible que permita visualizar su verdadera terminación. Normalmente un producto confiable es la documentación fiel que comprueba resultados obtenidos al finalizar cada actividad.

Es frecuente la creencia de que algunas actividades no pueden medirse con la política de "productos terminados"; sin embargo, la experiencia demuestra que toda tarea productiva arroja un resultado objetivo. Para comprobarlo se expone el siguiente ejemplo:

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

CAE 6. LA IMPORTANCIA DE EVALUAR LOS COMPROMISOS

Supongamos que a un programador se le designe para realizar un estudio sobre la instalación de un paquete de software. La pregunta que surge es: ?cómo saber que el programador ya lo estudió¿ Hay varias formas de averiguarlo: se le podría solicitar que dé una plática sobre la estrategia de instalación; o bien que entregue una lista de verificación (check list) de las Fases que seguirá para instalarlo.

7. Un jefe deberá ser capaz de detectar que, desde el punto de vista técnico, las fechas de terminación programadas por sus subordinados no estén demasiado holgadas, ya que si esto sucediera podría resultar que la persona a quien se le hayan asignado tales actividades no sea la idónea; quizá su falta de experiencia la lleve a establecer plazos más largos de lo necesario.

Esta no es una tarea fácil, pero es en estos casos donde el jefe demuestra su habilidad de mando, con razones a la altura de cuaIquier técnico, y que ha sido designado para ese puesto por su experiencia y no por otras razones. Sin duda, esto lo hará más respetable.

8. Por último, es Función del jefe establecer controles de avance y seguimiento de proyectos, ya que esto le ayudará a visualizar las desviaciones imprevistas que pudieran surgir, y así establecer correctivos oportunos.

En este punto hay que destacar que para el logro completo de todo proyecto, el jefe debe abstenerse de asignar actividades extras que desvíen de su objetivo al personal ya asignado, ya que esto ocurre con Frecuencia y entorpece las actividades normales, propiciando que el trabajo planeado se haga a medias y que el personal se sienta Frustrado. Algo que debe tenerse siempre en mente es el respeto al trabajo de cada miembro del equipo, pero sobre todo, que vean la realización final del mismo. El hecho de sentirse productivos los motivará.

Durante una investigación detecté que los jefes de los distintos departamentos del área de informática que de alguna manera observaban las sugerencias anteriores invariablemente conseguían buenos resultados. Esto no quiere decir que en sus instalaciones no hubiera problemas; sin embargo, los beneficios de estas estrategias se podían palpar al comprobar que la mayoría de los técnicos casi no tenían necesidad de trabajar a deshoras ni los Fines de semana, pese a que las cuotas de pro- ducción eran elevadas, y claramente se distinguía un aire de tranquilidad y conf anza, en contraste con otros departamentos en donde el desorden era evidente.

RESUMEN

El "don de mando" no garantiza buenos resultados en el área de informática. Cuando algún jefe se compromete a entregar resultados en

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

El don de mando no hará que las cosas salgan mejor en el área de informática.

tiempo récord y no toma en cuenta a los que realmente harán el trabajo, se debe a su falta de conocimiento del esfuerzo que ello implica, ge- nerándose así maratones que obligan a trabajar a marchas forzadas y en forma improvisada. La mayoría de estos trabajos tienden al fracaso, por lo que representan pérdidas cuantiosas tanto en tiempo como en dinero. Un jefe debe estar preparado para discernir la complejidad real de un trabajo antes de comprometer a otros. Deberá tener la capacidad técnica para comprender la magnitud de cualquier solicitud y no deberá aceptar compromisos sin antes dialogar con sus subordinados. Deberá estar seguro de contar con los recursos técnicos y humanos disponibles para cumplir el trabajo bajo rigurosa planeación, sin que los técnicos descui- den actividades a las cuales ya estén asignados.

Con lo anterior me refiero a aquellos jefes que no saben lo que están diciendo, sencillamente porque no son informáticos, y que ingenuamente se comprometen ante los usuarios, y para enmendar su error debido a la ignorancia, sacrifican a su personal, presionándolos con amenazas y gritos sin tomar en cuenta que este tipo de trabajos improvisados y superficiales causarán a la larga desastres altamente

138 CAP 6. LA IMPORTANCIA DE EVALUAR LOS COMPROMISOS

costosos en todos los sentidos. Por esto, también cuando digo que un jefe no deberá aceptar de sus superiores encomiendas imposibles, no me refiero a una negativa que lo colocará como incompetente; por el contrario, lo que debe hacer es sensibilizar a los directivos de los ,riesgos de hacerlo así. Hasta ahora no conozco a un solo directivo al cual se le quiera proteger y que se haga de oídos sordos. Pero lo anterior requiere jefes informáticos competentes.

Estandarizar la comunicación entre directivos y técnicos

Problema

Si no son los jefes los que se comprometen, con frecuencia tienen que aceptar los tiempos marcados por los directivos de la empresa, pues aquéllos casi son impuestos sin considerar el grado de complejidad técnica y, a veces, ni los recursos con que se cuenta.

Se trata básicamente de un problema de comunicación entre técni- cos y directivos, pues sencillamente no hablan el mismo lenguaje; es decir, los directivos en su mayoría son administradores que tienden a visualizar la proyección de su empresa. A ellos compete, en esencia, el ámbito del negocio y las relaciones con los distribuidores, clientes, etc. No está dentro de sus actividades visualizar el aspecto técnico de un proyecto, ni la complejidad técnica que esto implica, sin embargo, es fundamental que cuenten en forma oportuna con la información que les provee el área de informática, para tomar decisiones con más seguridad. Las imposiciones que se mencionan en la problemática de este planteamiento son generadas, en forma fundamental, porque los directivos no comprenden el ámbito computacional o tienen una idea desvirtuada. Con frecuencia creen que las computadoras son equipos automáticos que generan fácilmente lo que se les solicita. Este problema se agudiza más, aun cuando los directivos no tienen contacto con las labores del área de informática.

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Debemos estar conscientes de que los directivos no son responsables de que este problema se presente, sino que también intervienen los jefes que preparan presentaciones en el centro de cómputo sólo para mejorar su imagen ante los directivos. Ellos jamás comentan lo complejo que resulta preparar dicha presentación; por el contrario, disfrazan el proceso, haciéndolo parecer muy simple. Quienes conocemos el ambiente, hemos sido testigos y participes de frecuentes desvelos, conver- tidos en días y semanas agotadoras, con el fin de preparar una presen- tación que no dura más de 15 minutos y que muchas veces es cancelada. Por supuesto, con este tipo de trabajo se minimiza la capacidad profesional que se requiere en el área de informática. Existe un concepto desvirtuado de los directivos que exigen el cumplimiento de algún trabajo en tiempo récord, lo cual es producto de lo que en ellos han fomentado algunos jefes del área de informática con poca responsabilidad y con conocimientos pobres de este ambiente.

SUGERENCIAS DE SOLUCIÓN 1. Es labor de todo jefe preparar seminarios técnicos básicos con el fin

de sensibilizar a los directivos. Tales seminarios deben realizarse para difundir, por medio de conceptos básicos, las ventajas de sus propios equipos de cómputo, así como las funciones técnicas que desarrolla el personal del área de inforrnática, con objeto de que los directivos puedan, por un lado, conocer realmente las posibilidades de los equipos de cómputo y, por otro, los requisitos de especialización que debe cubrir el persona1 informática para lograr la funcionalidad y estabilidad de la empresa. En este punto, hay que destacar que hoy día ya no es posible que ninguna persona, trátese de un directivo, profesional, funcionario, empleado o estudiante, ignore la verdadera función de las computadoras, sus alcances y sus requisitos. Es un conocimiento obligado para las generaciones actuales y Futuras.

Mediante esta estrategia, los directivos podrán visualizar, aunque en un esquema muy general, tanto el potencial real con que cuenta su centro de cómputo, como las deficiencias que existan. De esta manera, antes de exigir, podrán evaluar, dialogar y entender en qué medida harán sus solicitudes de información.

2. Otro factor importante es que en ciertos periodos los jefes deben informar a los directivos sobre los proyectos en los que se está trabajando; la importancia y beneficios que representan para la compañía; los recursos que tienen asignados, tanto de personal como de equipo; y cualquier información útil que perrnita saber a los directivos hasta qué grado se tienen comprometidos tales recursos, y si hay o no disponibilidad para absorber nuevos proyectos. Con esto, los directivos podrán asignar con más precisión las prioridades de cada proyecto.

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

RESUMEN

Es importante recalcar que en estos informes nunca se debe pretender ocultar la situación real de la instalación, pues es mejor que los directivos conozcan la verdad, por grave que ésta sea, y tomen medidas correctivas a tiempo, que hacerlos pensar que todo marcha a la perfec- ción y que el área de informática es una fuente inagotable que atenderá cualquier nivel y cantidad de solicitudes.

3. En caso de que las solicitudes de trabajo sobrepasen la capacidad de los recursos del área de informática y que, por su importancia, se requiera variar la prioridad de trabajos ya asignados, es vital que esto sea en forma excepcional, ya que si ocurre con frecuencia sólo se logrará dejartrabajos a medias, desanimando en forma constante a los técnicos. Lo más sano sería no adquirir nuevos compromisos, a menos que sean de vital importancia y en estos casos deberán ser compromisos a corto plazo que permitan continuar rápidamente con los proyectos suspendidos.

4. Para el caso anterior, una opción prudente es solicitar apoyo de asesores externos, preparados para cubrir las características de un proyecto urgente, que aunque se considere costoso, no es así; lo siguiente lo confirma:

a) La garantía de que los productos serán entregados es muy elevada, puesto que normalmente el pago de servicios se efectúa a la entrega de los resultados.

b) Los técnicos de la instalación no se verán afectados. c) No requiere contratar más personal, pues esto, a la larga, resulta

más caro por las implicaciones que representa una contratación formal.

5. Otro factor importante y que con frecuencia pasa inadvertido es que habrá que considerar las cargas de trabajo que generan con nuevos trabajos en producción. Antes de aceptar un nuevo compromiso será necesario medir los recursos de cómputo que absorberá, porque podría aumentar la configuración del equipo. Si esto no se visualiza claramente puede crear atrasos y trastornos en la producción actual.

6. Por último debe evitar, hasta donde sea posible, presentaciones con el fin de impresionar. Al contrario, debe señalarse la carga de trabajo real que representó, y las presentaciones deben ser productivas con una tendencia de servicio, pero no por única vez.

RESUMEN

Los directivos que imponen la requisición de trabajos son aquellos a los que se les ha trasmitido una idea desvirtuada sobre la capacidad real de los equipos de cómputo, así como sus limitaciones; y por lo general

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

no entienden la complejidad técnica que requiere este tipo de solicitudes. Con Frecuencia creen que las computadoras son equipos automáti- cos que generan fácilmente lo que se les solicita. Esto no es culpa de ellos, sino de lo que les han fomentado jefes irresponsables, quienes cuando tienen oportunidad ofrecen presentadones con el único fin de cuidar su imagen. Jamás comentan lo complejo que resultó preparar dicha presentación, al contrario, aparentan que se realizó en formd ' 'I simple y rápida. Es labor de todo jefe sensibilizar a los directivos, y orientarlos para que comprendan la labor y las irnplicaciones del área de informática. Deben informar a los directivos sobre los proyectos en los que se trabaja y la disponibilidad real en cuanto a recursos técnicos y humanos para evaluar la posibilidad de absorber más compromisos. En caso de que las solicitudes de trabajo sobrepasen la capacidad de los recursos disponibles, es obligación del jefe demostrárselo a los directivos y posiblemente, si la situación lo requiere, auxiliarse con asesores externos. Jamás debe ocultarse la situación real del área de informática, ni hacer presentaciones para impresionar; al contrario, debe indicarse lo complejo que resultó, con el fin de que si existen presentaciones que impliquen cualquier tipo de esfuerzo, éste resulte provechoso.

Beneficios de la asignación equilibrada de las órdenes de trabajo

Problema

Casi siempre hay saturación de trabajo por falta de control efectivo, razón por la cual difícilmente se desarrollan trabajos de investigación, necesarios para un mejor aprovechamiento de los recursos de cómputo.

El problema tiene básicamente tres razones de fondo: en unos casos se debe al tipo de organización del área de informática, pues se ha detectado que cuando existen grupos de especialización por proyecto, algunos están saturados de trabajo, mientras que en otros hay poca actividad; hay casos en los que el problema existe por la adquisición frecuente de compromisos urgentes; y por último, debido a la falta de control efectivo en la asignación de trabajos.


1. Dentro del esquema inforrnático, las organizaciones están dadas en función del tipo de trabajo en el cual se encuentra enmarcado el servicio que presta la compañía o institución. Las organizaciones establecidas por áreas de especialización son más productivas en el campo científico y de investigación, en donde cada proyecto lleva, por lo

general, años o décadas para su realización; sin embargo, en el terreno comercial, los proyectos no duran más allá de meses o pocos años. Por tanto, no es conveniente designar un área completa para su desarrollo y posterior mantenimiento, porque es así como se produce la falta de equilibrio en las cargas de trabajo. Por esto, la estrategia idónea es tener los llamados grupos de servicio, en los cuales tanto programadores como analistas desarrollan de manera indistinta cualquier tipo de sistema comercial, para convertirse así en mecanismos generadores de sistemas completos y bien documentados; puestos en operación, se desligan para atender otros compromisos.

Es conveniente destacar que una buena documentación es la herramienta básica que hace operable cualquier sistema, aun por personas ajenas a su desarrollo. Debe notarse que cuando no existe documenta- ción, o ésta es deficiente, se origina una tendencia muy alta de especia- lización del personal, propiciando sistemas demasiado peligrosos en su operación y mantenimiento, además de convertir a la instalación en un centro de emergencias y sobresaltos constantes, lo que obliga a mantener al personal en un innecesario estado de alerta permanente.

Cualquier problema en la operación, o cambio en el sistema, produce una carga de trabajo severa cuando el personal que la atiende ya está asignado a otro proyecto. Es de esperar que esta carga de trabajo llevará mucho más tiempo, por la falta de documentación. En cambio, cuando los sistemas se desarrollan con base en una metodología eficiente, difícilmente fallan en su operación; y si por excepción sucede esto, por lo general son detalles que requieren poco tiempo para su solución. Ahora bien, en casos específicos en los que se requieren cambios necesarios, donde se cuente con todos los antecedentes documentados, es factible que cualquier analista o programador experimentado logre el cambio sin mayores complicaciones. No aceptar esto, es como desear que no exista rotación de personal y que los especialistas del proyecto permanezcan siempre en la instalación. Por el contrario, en instalaciones sin orden es donde más rotación de personal existe.

2. En los casos en que los compromisos urgentes son tan frecuentes que rebasan la capacidad de producción del personal de informática, la sugerencia más recomendable es hacer un llamado de atención al jefe que origina esto, pues lo más seguro es que no tenga idea del tipo de trabajo que ahí se realiza, o que no sepa crear conciencia en los directivos de lo que está sucediendo. No se pretende que exista una rebelión mal intencionada en contra de él sino, por el contrario, que el área de informática sea estable y que beneficie a sus integrantes y principalmente a la empresa, al prestarle un serVicio eficiente de infor- mación; no debe incurrirse en el error de hacer trabajos al vapor, no documentados, con riesgos y mucho menos en un ambiente de descontento general del personal que origine renuncias frecuentes o en masa.

SUGERENCIAS DE SOLUCI~N

3. La falta de control efectivo en la asignación de trabajos se da Fundamentalmente por falta de metodologías que hagan posible la ejecución de trabajos eficientes y que, de acuerdo con cada una de las fases de la metodología, permitan medir el grado de avance de cada proyecto, así como la capacidad real de producción. Como ejemplo podemos citar el siguiente caso:

Todo programa, para su elaboración, requiere pasar por las siguientes fases estándar:

Asignación al nivel de programador idóneo para desarrollar el programa en función de su complejidad. Estudio de la definición del programa. Elaboración del diagrama de bloque. Prueba de escritorio sobre el diagrama de bloque. Codificación en el lenguaje de programación. Prueba de escritorio sobre la codificación. Transcripción a medios procesables del computador. Elaboración de datos prueba en el medio por probar. Compilación y depuración de errores. Catalogación. Prueba del programa. Verificación de resultados. Ajustes de programa si son necesarios. Documentación y entrega.

Para esto, si el je£e de programación tiene registrado en un pizarrón magnético el nombre de cada programador, así como las fases para la elaboración de cada programa asignado; y en pequeños cartoncillos la clave de cada programa, éstos podrán colocarse en la fase correspondiente. De un solo vistazo es posible distinguir la asignación individual y el avance de cada programa. Esto, aparte de evitarle al jefe de programación pedir información de avance y asignación cada vez que lo requiera, le permite visualizar la carga de trabajo real en su área de acción, y así considerar si aceptará más compromisos, si se los solicita- ran. Para esto, deberá asignar a alguien para que pase diariamente con cada programador con el fin de conocer la fase en que se encuentran los programas y actualice la posición de los cartoncillos.

Un método similar deberá establecerse para los departamentos de análisis, diseño, operación o cualquier otro que exista.

4. Al lograrse una asignación nivelada de cargas de trabajo, es labor de todo jefe evitar que exista personal ocioso, el cual no tenga asignado algo de provecho. Si esto llegara a suceder, es responsabilidad del jefe del área asignar trabajos de investigación que sirvan para el desarrollo técnico de cada persona y de beneficio para la compañía.

CAP. 8. BENEFICIOS DE LA ASIGNACIÓN EQUILIBRADA

Estos trabajos pueden ser los siguientes:

a) Elaboración de rutinas de utilidad que sean de uso común. 6) Investigación de facilidades poco comunes o desconocidas del sis-

tema operativo que sean de provecho, para una mejor explota- ción de los recursos del computador.

c) Investigación del funcionamiento de instrucciones de programa- ción poco comunes o desconocidas y que resulten de gran poder.

d ) Análisis de problemas que afecten a otras áreas; en otras palabras, llevar a cabo auditorías técnicas.

e) Estudio de algunos procedimientos de control mal definidos que ocasionen retrasos.

f ) Estudio de los estándares de documentación que permita simpli- plificar o mejorar la existente, etcétera.

Con el £in de aprovechar cualquier experiencia obtenida en las investigaciones, se sugiere implantar un sistema de comunicación con boletines en los cuales se divulguen dichas experiencias y se haga partícipe a todo

La falta de planeación produce incertidumbre en las fechas de terminación.

RESUMEN

el personal técnico para escribir artículos de interés y beneficio comúq para toda la instalación. Podrá informarse sobre nuevos nombramien- 'A tos, funciones, cambios de organización, innovaciones técnicas y, en general, cualquier tópico de interés que permita una mejor comunica- ción entre todas las áreas. Mediante esta estrategia, se atacará uno de los problemas más graves de toda instalación: la falta de comunicación.

RESUMEN

La saturación de trabajo en el área de informática se da básicamente por tres razones, a saber: cuando existen grupos de especialización, mientras unos están saturados, otros están inactivos; cuando se adquieren con frecuencia trabajos urgentes; y por último, cuando no hay control efectivo en la planeación y asignación de trabajos. Las áreas de especialización son más productivas en un ambiente científico o de investigación en donde un proyecto generalmente lleva lustros o déca- das para su realización. En el terreno comercial, los trabajos no duran más allá de algunos meses, o pocos años, por lo que no hay razón para asignar áreas completas para su desarrollo. La estrategia más recomendable es formar los llamados grupos de servicio. En caso de que los trabajos urgentes se den con frecuencia, será necesario analizar seriamente la situación. El desorden en la asignación de trabajos que origina desequilibrio en las cargas de trabajo puede subsanarse mediante metodologías de control que permitan en todo momento conocer la capacidad real de producción de cada departamento.

Estrategias de capacitación

Problema

Con frecuencia los técnicos aprenden sobre la marcha, de manera empírica y sin planes de capacitación previamente definidos.

Este Fenómeno se presenta en bastantes instalaciones, aunque en muchas otras sí se siguen planes de capacitación; sin embargo, en algunas de éstas, tales planes no son congruentes con las necesidades técnicas que existen. En otras palabras, existe la capacitación por el solo hecho de capacitar. Son ocos los jefes que comprenden que en el área de informática las activi l ades no deben ser empíricas, sino que dado el tipo de trabajo, se requieren especialistas bien capacitados y experimentados que garanticen un nivel de servicio elevado. Es necesario que los directivos adviertan que la inversión en un centro de cómputo no radica únicamente en la adquisición del equipo, sino que aún habrá de invertir cantidades,. quizá mayores en capacitación, y que ésta deber2 ser permanente. f ampoco basta con la contratación de personal preparado, pues si éste no es capacitado en forma permanente, con el paso del tiempo se volverá obsoleto. Algunos problemas que origina la falta de capacitación se mencionan a continuación.

En primer lugar, los técnicos quedan estancados en cuanto a sus conocimientos. Al existir este estancamiento la explotación de los recursos de cómputo es totalmente deficiente, pues en la mayoría de los casos las labores de análisis y diseño, programación, operación y man-

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

RESUMEN 1 49

tenimiento de software son tan obsoletas que impiden realizar trabajos de buena calidad, dando como resultado un mal servicio para los usuarios; pero la consecuencia más grave es la distorsión de las funciones del área de informática.

Así, al no haber capacitación permanente, el personal técnico decide abandonar la compañía en busca de nuevos horizontes y mayor oportunidad [de desarrollo, para originar entonces una mayor rotación de personal, inflación de sueldos, escasez de personal calificado y, peor aun, el desquiciamiento de la estructura organizacional y de servicio del área de informática.


1. AI establecer los planes de capacitación, ésto$ deben tener un objetivo concreto y costeable; es decir, los cursos que se bmgramen deb,en eqtqr orientados a fortalecer proyectos en desarr~llo g futuro, pues la capacitación no sólo debe capacitar, sino estar p enamente justificada.

Y 2. Es recomendable que existan dos tipos de planes de capacitación:

externos e internos; es decir, cuando se origina la necesidad de tomar cursos fuera de la compañía, incluso en el extranjero, se debe enviar a una o dos personas, como máximo, plenamente facultadas para aprovechar los conocimientos, y ellos serán quienes capaciten al personal restante. Con esto se consigue lo siguiente:

Inversión moderada. Difusión de conocimientos y desarrollo general. Creación de instructores propios de la compañía. Capacitación permanente y motivación general del personal. El personal que se envíe a los cursos y que después los imparta, se sentirá motivado, reconocido y comprometido moralmente con la compañía. Al existir los cursos internos se crea un ambiente de trabajo sano y por consecuencia atractivo para el personal de nuevo ingreso. Con esto se eliminan envidias y competencias internas malintencionadas, lo cual permite que se trabaje en confianza dentro de un ambiente de compañerismo y colaboración mutua.

RESUMEN

La capacitación técnica para el personal del área de informática debe ser obligatoria. Los planes de capacitación serán congruentes con la

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

Hcano

Highlight

filosofia de los pcoyectos de la instalación; es decir, la capacitación deberá ser por objetivos. Es necesario convencer a los directivos de que la inversión de un centro de cómputo no está únicamente en el equipo de cómputo. No basta con contratar personal capacitado al cdal no se siga desarroUandoj pues esto con el tiempo los volverá obsoletos. Es recomendable implantar dos tipos de planes de capacitación: el p.rim.ero será la capacitación externa, a cuyos cursos sólo irán una o dos personaq como malxihno; el segundo es la capacitación interna que impartirán dentro de la empresa quienes hayan asistido a cursos externos. La capacitaciijn deberá ser permanente y no necesariamente cosaosa. j

<. 1

Formación y contratación de personal técnico

Problema

Existe una gran escasez de personal verdaderamente preparado y la mayoría de las empresas no logra contratar al personal idóneo para sus verdaderas necesidades, lo cual con el tiempo ha originado un pirateo desmedido.

El fondo de este problema es bien conocido, simplemente no existen carreras de informática diseñadas de acuerdo con la realidad y las necesidades crecientes de las empresas. En años recientes, nuestras escuelas, institutos y universidades no han preparado verdaderos especialistas en la materia, pues no se tomó en cuenta que esta tecnología se expandería con tal rapidez; hace unos años se crearon carreras en materia de informática, debido a la gran demanda de este tipo de personal, pero ahora éstas ya resultan incongruentes con la realidad informática de las organizaciones.

Aun así, el personal egresado dista mucho de tener una preparación acorde con las demandas del mercado; los maestros que imparten las diferentes materias de este ramo no cuentan, en su mayoría, con los recursos materiales necesarios para preparar verdaderos profesionales; hacen falta laboratorios diseñados ex profeso para la capacitación eficiente de los alumnos.

1. Para estos casos resulta más seguro y económico capacitar profesionales recién egresados de carreras de orientación técnica, científica, actuarial, física, matemática o electrónica, incluyendo a los de las áreas de informática; y prepararlos exhaustivamente en forma interna y con instructores propios de la compañíd en cuestión, con lo cual se logra ambientarlos desde un principio en la problemática individual de la instalación. Esto sin duda es un procedimiento lento, por lo cual, si por la naturaleza de los proyectos debiera ser más rápido, resulta conveniente la contratación de grupos de asesores dedicados a estas labores.

2. Si se decide contratar gente con experiencia, hay que considerar que las entrevistas superficiales resultan inconvenientes; y como es sabido, en este medio existen muchas personas que se dicen "especialistas" y van saltando de una instalación a otra con el único fin de ganar más; como dominan el lenguaje del ambiente de informática, impresio- nan a los entrevistadores, consiguiendo una contratación rápida. Pero cuando se dan cuenta del fraude es demasiado tarde, por ello es necesario examinarlos exhaustivamente en varios sentidos:

a) Su nivel académico es bueno y sus conocimientos generales aceptables; sin embargo, este tipo de exámenes no deben seguir un formato predefimdo, ya que podría resultar una persona que ha presentado muchos de estos exámenes y los conoce muy bien. Lo ideal sería que fuera examinado por un comité y en forma oral, con preguntas recién elaboradas.

b) Habrá que examinarlo exhaustivamente sobre la especialidad que dice tener, pero esto deberá hacerlo otro grupo de especialistas con conocimientos actualizados y comprobados en la prácti- ca. Si la compañía carece de dichos especialistas, debe pedir apoyo a otras instalaciones que sí los tengan.

c) Debe distinguir claramente que el candidato tenga varios años de experiencia y no unos cuantos meses, que repetidos en hacer lo mismo resultan años. La experiencia se mide por la diversidad de proyectos en los que ha aportado sus conocimientos.

d ) Habrá que considerar que el puesto que vaya a ocupar no sea distinto a los ue ha desempeñado, pues suele suceder que un buen analista d e sistemas resulta malo como líder de proyecto o jefe de un área no acorde con su verdadera capacidad.

3. Por último, no debe creer en las recomendaciones verbales de los amigos del candidato, pues es bien sabido que la imagen que se tiene de una persona no es la misma para otras, y que los favoritismos no son convenientes en estos casos.

RESUMEN

Debido al incremento de equipos de cómputo en el país, y a la poca previsión de las autoridades académicas, no existe suficiente personal técnico en el mercado capaz de satisfacer las verdaderas necesidades de las empresas. Con urgencia, en años recientes se han creado carreras profesionales en informática. Aun así, el personal egresado dista mucho de estar preparado de acuerdo con las verdaderas necesidades del medio, por ello es necesario que a los recién egresados se les someta a un buen periodo de capacitación, después del cual la mayoría resultan buenos elementos. La escasez de este tipo de personal ha favorecido a cientos de charlatanes, los cuales saltan de una empresa a otra buscando sólo ganar más. Si una empresa requiere más personal técnico en infor- mática, y el tiempo se lo permite, debe contratar recién egresados y capacitarlos. Si la urgencia es verdadera, debe apoyarse en asesores externos; y si se requieren especialistas propios de la empresa, debe hacerse un plan de contratación riguroso para no contratar a un charlatán.

'\

La escase de personal técnico altamente calificado pr 5 picia trabajos de pésima calidad.

Ventajas y desventajas 3 de la consultoría externa 2

Problema

El apoyo de consultores externos para resolver proyectos específicos de informática que la empresa no puede enfrentar por falta de recursos técnicos o falta de experiencia no siempre resulta bepbfico.

En años recientes se ha extendido la contratación de servicios de apoyo para ser realizados por consuItores externos; es decir, se contrata por un tiempo límite, o por un trabajo específico, a un grupo de especialistas ajenos a la empresa con el fin de subsanar rápidamente los problemas de trabajo de alguna unidad usuaria, ya sea porque no se cuenta con los especialistas propios de la instalación o porque la capacidad de trabajo del área de informática ha sido rebasada.

Si nos referimos en forma concreta a la asesoría externa en materia de informática, sabemos que ha proliferado el establecimiento de despachos de consultores, llegando en algunos casos a estar forrnados por una sola persona que, apoyada en una supuesta experiencia, aprovecha nuestro deteriorado ambiente de informática, el cual ya resiente la impotencia de afrontar proyectos cada vez más necesarios y ambicio- sos en esta materia.

La falta de especialistas integrados y preparados sistemáticamente, acordes con las necesidades crecientes que los reclaman, hace que cada vez con mayor frecuencia los responsables asignados para la solución de

VENTAJAS Y DESVENTAJAS 155

tales proyectos requieran apoyo de recursos humanos adicionales y, como es de esperar, en Ia mayoría de los casos dichos recursos no están disponibles en la propia compañía, razón por la cual optan por contratar los servicios de asesores externos; pero jrealmente resuelven así el problema< Las experiencias han demostrado que no siempre resulta exitosa la estrategia; es más, en muchos casos resulta tan errado este plan, que no sólo no se llega a una solución favorable, sino que a veces el ambiente anterior, ya deteriorado, empeora aún más, llegando en algunos casos a suspender esos servicios de consultoría, con la consiguiente pérdida de tiempo invertido y, obviamente, con el obligado gasto involucrado para luego regresar a establecer un plan de restauración del ambiente anterior.

Tal vez e1 Iector piense que se exagera un poco, pero no es así, en lo personal he sido protagonista de múltiples revisiones de contratos de servicios de consultoría, y me he percatado de situaciones que, de no haberlas vivido, ni yo mismo las creería. Me referiré en particular a dos casos que llamaron fuertemente mi atención por el gran despilfarro de tiempo y dinero que ocasionaron, aunque, por supuesto, no mencionaré el lugar ni a los responsables, porque no es el objetivo ni está dentro de mi ética profesional.

El primero de ellos ocurrió a mediados de la década de 1980; entonces se tenía contratados a unos 60 técnicos propios de la compañía y el proyecto consistía en diseñar e implantar un sistema apoyado en un banco de datos que diera como resultado una cuenta única para los clientes de dicha compañía. Pues bien, por razones que siempre ignoré, para tal proyecto se contrató a un grupo externo de 30 especialistas que "trabajaron" durante año y medio para lograr sólo un raquítico sistema de consulta trivial que nunca llegó a ser la esperada cuenta única; pero no sólo ocurrió eso, sino que los controles administrativos anteriores sufrieron un deterioro que se tardó más de un año en restablecer.

Los procedimientos rudimentarios anteriores, si bien no lograron la cuenta única, sí estaban bajo control y eran conocidos, pero fueron abandonados para que finalmente no se tuviera ni uno ni otro. Cabe mencionar que los 60 técnicos propios de la compañía participaron cuando mucho en un 5 % a lo largo del proyecto, pero eso sí, cobraron como si hubieran trabajado el 100 %. Olvidaba decir que el equipo de cómputo con una configuración bastante considerable fue adquirido exclusivamente para este proyecto, es decir, orientado sólo para dar servicio a un solo sistema. Si a esto agregamos los costos del local, dispositivos magnéticos para la computadora, mobiliario, líneas de tras- misión de datos, etc., es posible imaginar el costo total de1 fallido proyecto. Sin embargo, falta añadir el costo por servicios de los consultores externos, por cierto extranjeros, del cual desconozco el monto total. Por el conocimiento que adquirí durante mis análisis, estimo que

156 CAP 11. VENTAJAS Y DESVENTAJAS

este proyecto se hubiera logrado, en su totalidad, en un plazo no mayor de año y medio y con un costo menor a la mitad de lo que representó, si se hubiera dirigido en forma correcta.

El segundo caso al que me referiré no llegó más allá de la conceptua- lización equivocada (porque a nadie convenció) de un sistema de control financiero, en el cual participaron unos 20 especialistas durante ocho meses, aproximadamente, para concluir en la cancelación del proyecto. No conozco la cantidad que costó este intento de proyecto, pero lo que sí puedo afirmar es que el gasto que se hizo alcanzó miles de dólares.

Los anteriores constituyen sólo dos casos conocidos por mí, aunque, obviamente, como éstos existen muchos. Si al margen de estas situaciones pusiéramos una línea divisoria imaginaria, del otro lado encontraría- mos excelentes trabajos, desarrollados por grupos de consultores o asesores externos que no sólo han resuelto múltiples problemas, sino que:

Han abatido costos en beneficio de las compañías, en donde han diseñado e implantado sistemas en tiempos récord y definido estándares de trabajo y técnicas de control que hacen a los infor- máticos de la instalación verdaderamente productivos. Han implantado disciplinas creadas y acopladas a las necesidades particulares de la compañía, y logrado la normalización continua de los servicios de cómputo hacia los distintos usuarios. Han provocado cambios en la mentalidad de los técnicos propios de la instalación, eliminando vicios dañinos ya arraigados. Han apoyado fuertemente a altos directivos y conseguido que éstos tomen mejores decisiones. Han publicado libros tendientes a difundir su vasta experiencia en las variadas ramas del ámbito informático. Han enriquecido poco a poco nuestra forma de explotar la tec- nología, tanto en materia de hardware como en software.

Aunque se piense que me he apartado del tema, lo anterior fortale- cerá aún más el contenido que aquí expongo, pues de otra manera sería difícil que se pudiera ilustrar en forma real el encabezado de este problema.

A lo largo de los párrafos anteriores he hablado de lo bueno y lo malo con respecto al trabajo de asesores externos (o consultores); como en todo, existen trabajos buenos y malos, pero como buen comprador, en la decisión de adquirir algo bueno, interviene el grado de conocimiento de lo que se desea comprar. Habrá más posibilidades de una buena compra si existe conocimiento previo del artículo, o en su defecto un cuestionamiento más profundo de la calidad o ventajas que se


tendrán al adquirirlo. Pues bien, precisamente éste es el análisis que haremos a continuación, sólo que en este caso el articulo hará referencia a los servicios de asesoría externa en materia de informática y lo que haremos será dar una serie de orientaciones y argumentos para que el comprador de servicios adquiera lo mejor para su provecho.


1 :Estudio preliminar para llevar a cabo el proyecto. Una vez que se ha convencido a la alta dirección de que dé su aprobación, generalmente se procede a establecer la estrategia según la cual se atacará el proyecto. Es aquí donde empiezan los problemas, pues al hacer un análisis más detallado, que a veces toma varias semanas, o quizá meses, se percatan de que para ese momento no cuentan ni con la infraestructura de recursos humanos ni con los conocimientos necesarios para el buen logro del compromiso que han adquirido; y como para entonces ya es un trabajo en cartera con límite de tiempo para su ter- minación, las urgencias principian y al no haber forma de asignar a los informáticos de la instalación, lo más viable es la contratación de asesores externos.

2. Solicitud de servicios de asesores externos. Es importante no tomar a la ligera este punto, pues en muchas ocasiones se contrata a un grupo de asesores teniendo en cuenta únicamente la recomendación superficial de algún amigo; considérese que esta etapa puede resultar la más crítica para el éxito del proyecto.

No permita que su proyecto fracase. Atienda las siguientes recomendaciones, las cuales no son empíricas, sino que están sustentadas en experiencias muy valiosas.

a) Una vez que ha elegido la contratación de asesores externos, convénzase de que la selección del grupo que va a contratar le llevará cierto tiempo, es decir, no deberá apresurar por ningún motivo esta fase.

b) Lance una convocatoria a través del medio más idoneo de publicidad, donde señale en forma concreta los objetivos del proyecto así como los recursos generales de hardware y software con que se cuenta, con el fin de que acudan al llamado sólo aquellos asesores que se sientan competentes para realizar dicho proyecto. Con esto se ahorrará tiempo y tendrá la certeza de que sólo acudirán asesores interesados en el proyecto.

C) Haga que cada representante de grupo de asesores sea entrevistado por una persona que conozca de integración de personal, para que analice la seriedad de la formación del grupo de asesores que ofrecen sus servicios. Una buena estrategia en este momento es formular un peque ño cuestionario que el entrevistado firmará al término de la entrevista

CAF! 1 1. VENTAJAS Y DESVENTAJAS

en el cual se establezcan preguntas que formalicen la veracidad de la integración legal y de la estructura del grupo, bajo protesta de decir verdad. La persona que lo firme deberá tener reconocimiento legal de su grupo. Usted verificará que dicho cuestionario sólo sea firmado por grupos completamente estructurados. En este momento la selección del grupo será más depurada y segura.

d ) Una vez que se cuente con los representantes de los grupos de asesores más idóneos para el proyecto, el siguiente paso será cuestionar si en verdad su estructura organizacional y su experiencia, aunada a sus conocimientos, reúnen los requisitos potenciales para garantizar el éxito del proyecto. Para este caso reúna a los representantes y formalice una plática con la duración necesaria para explicarles con detalle los alcances del proyecto, recalcando cada uno de los resultados requeridos; adviértales que la terminación del proyecto se dará con conclusión de cada uno de los resultados expuestos. No permita que se limiten a entregar sólo algunos resultados. Debe quedar bien claro que el proyec- to se dará a aquel grupo que se apegue a las estrictas demandas de la compañía, por lo cual el compromiso será adquirido sólo por grupos de asesores plenamente seguros de que lograrán el proyecto en su totalidad. Esta plática deberá darla el personal de la compañía que elaboró el estudio preliminar para realizar el proyecto; dicha plática deberá terminar sólo cuando haya aclarado todas las dudas de los asesores. Si es necesario propicie una segunda plática para que los asesores tengan tiempo de estudiar las notas o apuntes que la misma compañía les haya proporcionado y no se dé lugar a malos entendidos. Es conveniente formular un cuestionario breve, el cual será firmado por cada representante para saber si la plática cumplió con su objetivo y se despejaron las dudas. Si existen, aclárelas.

e) Solicíteles propuestas de estrategias para llevar a cabo el proyec- to, así como de sus respectivas cotizaciones; y seleccione como máximo tres de estas propuestas. Para efectos de este tipo de selección tome en cuenta los siguientes aspectos:

Es candidato a selección el grupo que disponga de una diversidad de especialistas y que asigne por lo menos a un experto en cada módulo que reclame el proyecto. En otras palabras, será candida- to aquel que cuente con un mejor grupo de especialistas congruente con la filosofía del proyecto. Es candidato a selección el grupo que haya participado anteriormente en proyectos similares y de igual o mayor magnitud. Es candidato a selección el grupo que tenga como mínimo cinco años de establecido y un índice bajo de rotación de personal. Es candidato a selección el grupo que tenga mayor cartera de clientes importantes (no de clientes en general).


Es candidato a selección el grupo que tenga oficinas complet - mente establecidas, lo cual demostrará la formalidad de su int - gración. Es candidato a selección el grupo que tenga establecido en S

contrato menos cláusuIas de protección tendientes a abolir S

responsabilidad en el proyecto. Es candidato a selección el grupo que precise en forma concret los resultados a los que se compromete, y que cumpla con lo requerimientos del proyecto.

requerido en las pláticas.

1 Por último, es candidato a selección el grupo que se compromet& por escrito al cumplimiento total del proyecto, según les fur:

l Como se habrá notado, no hemos hablado de costos ni de tiempoi;

el objetivo principal de esta selección es garantizar, hasta donde sea posible, el éxito del proyecto; es decir, el cumphiento integral del mismo; no se recomienda que se busque lo más barato y se desperdicie sin beneficio alguno, o que se ahorren algunas semanas, descuidando actividades de importancia que a la postre lleve a tareas frecuentes de emergencia, lo cual provoca un estado constante de sobresaltos por fa1 de previsión, obligado por un poco más de tiempo. Como quiera qu 't sea, tanto el costo como el periodo son negociables y sujetos a acuerdo. Lo que no resulta es partir de bases infundadas que pongan en peligro $1 éxito del proyecto en su totalidad o parcialmente. No hay razón para permitir esto cuando es posible un control estricto y culminar con éxito.

f ) Una vez seleccionadas tres propuestas, como ináximo, no S

apresure a tomar una decisión, y mucho menos a firmar un contrat , pues todavía falta un aspecto de suma importancia: pedir a los grupo seleccionados que muestren ejemplos de la documentación de trabajo 1 similares al que pretenden hacer. Este detalle será la culminación con 18 cual se garantizará, en gran medida, el buen logro del proyecto, pues 19 que mostrarán, aparte de confirmar su participación en trabajos similat- res, será la calidad, orden y magnitud de lo que saben hacer. Finalmentq, usted se convencerá de qué grupo representa su mejor adquisición di: compra de servicios. Pues en este momento aprendió a conocerlos, sup+ de su trayectoria, estimó la garantía que representaban para el buen figi del trabajo que desarrollarán y que tuvo una muestra de sus habilidadeg.

g) Prepárese a firmar un contrato. En este momento usted ya debib haber colocado las propuestas y determinado primera, segunda y tercei ra opciones. Es el momento de negociar las cotizaciones y los es decir, no debe aceptar estos dos aspectos a la primera propuestas. Pida a cada representante que le sea justificado tanto costo como el tiempo, y una vez que se ha llegado a un acuerd

CAP 11. VENTAJAS Y DESVENTAJAS

comunique su decisión a los grupos candidatos haciéndoles ver que . basó su decisión en los elementos que ellos mismos dieron. Este pequeño detalle comprometerá moralmente al grupo seleccionado; y a los no seleccionados les hará sentir la importancia que se les dio a sus propuestas, colocándolo a usted como un hombre honesto, metódico y sobre todo, imparcial. Pues bien, lo que la mayoría de la gente haría en este momento sería pedir al grupo seleccionado que redacte su contrato y lo presente para revisión y autorización. ¡Pues no!, el contrato deberá ser redactado en conjunto para evitar correcciones futuras; y lo más importante, recalcar por último los compromisos adquiridos, sin dejar ningún cabo suelto, ya que podría existir la posibilidad de un posterior malentendido mutuo.

3. Firma del contrato. Si usted siguió en forma sistemática los puntos anteriores, e incluso otros propuestos por su misma compañía, firme con toda confianza, libre de temores, convencido de que ha puesto bases sólidas para el buen éxito del proyecto. Además, siéntase satisfecho de cuidar los intereses de la com añía que le facilita el sustento personal a cambio de su excelente tra E ajo. Si descuidó estos factores, prepárese a enfrentar uno de los más fuertes fracasos personales, y posiblemente hasta la pérdida de su trabajo. Todo esto por falta de cuidado, o peor aún, por falta de conocimientos.

4. Inicio del proyecto. Si bien ya se han establecido bases sólidas al contratar al grupo idóneo para lograr resultados exitosos, no dejan de ser sólo eso. Hay que entender que faltará el verdadero trabajo, el de hacer realidad los planteamientos teóricos. En ocasiones se piensa que al haber contratado a un buen grupo de asesores, de ahí en adelante sólo es problema de ellos lograr el proyecto. ¡Pues no! Aunque si bien ellos harán el trabajo, deberá existir un líder del proyecto propio de la compañía, y él es quien deberá establecer los estándares y políticas de trabajo a que se deberán sujetar cada uno de los asesores que trabajen en el proyecto. En otras palabras, el control del proyecto estará siempre en manos del personal de la compañía y nunca deberán permitirse abusos por parte de los asesores. No hay que olvidar que el control del negocio siempre deberá estar en manos del dueño y no de los empleados, de otra manera se va a la quiebra.

5. Desarrollo del proyecto. Es conveniente, casi indispensable, que se administre el avance del proyecto bajo la filosofía de productos terminados; es decir, a la terminación de cada actividad, ésta deberá arrojar un producto completo que demuestre en forma tangible que dicha actividad ha sido cubierta formalmente. De lo contrario, se dan por terminadas actividades que aún no lo están, sólo porque alguien lo afirma así, y son registradas como terminadas cuando ni siquiera hay indicios de ello. Recuerde que las riendas de control las lleva el eropio

t-

1 .

SUGERENCIAS DE SOLUCI~N 161 1 personal de la compañía; por tanto, ellos deberán dictar los procedimientos más convenientes para, incluso, dirigir el avance de las propias actividades de los asesores, y no perder en ningún momento la dirección correcta hacia la terminación exitosa de cada actividad.

6 Tenninación del proyecto. Es de vital importancia detectar cuán- do en realidad el proyecto ha sido concluido en su parte técnica; para esto, aparte de la administración por medio de productos terminados, se cuenta con el contrato en el cual están especificados los resultados concretos comprometidos, y obviamente esto estará amparado por demostraciones prácticas de cada resultado, donde se requiera de los asesores un plan de prueba integral que contemple hasta los másl múiunos detalles respecto del alcance del proyecto. Si fuera necesario^ tómese varios días, pero no se arriesgue a aceptarlo sobre pruebas1 superficiales. 1

7. Implantación y liberación del proyecto. A este respecto, algunas compañías concluyen su contrato con los asesores al término de las pruebas y presentaciones de cada producto; pero olvidan que la actividad que determina el éxito verdadero de un proyecto es cuando los usuarios propios de la empresa operan iluidamente los resultados del sistema computarizado, del cual a veces resulta igual o más compleja su implantación que su desarrollo. Por tanto, pensar así es un grave error, que puede obstaculizar y opacar en gran medida todo el esfuerzo. Por tal razón, el contrato debe contener este servicio de vital importancia, y no se dará por terminado el compromiso hasta ver completamente en ope- ración formal el sistema logrado.

8. Recepción del proyecto. A propósito no he mencionado la participa- ción que debe tener el personal técnico propio de la compañía. He querido^ dejarlo hasta el final por considerar este momento el más oportuno para^ analizar su impacto. Pensemos que todo el trabajo de detalle lo han hecho1 los asesores, por tanto, la experiencia integral y el conocimiento profundo será de ellos; pero, $qué va a suceder cuando los asesores se retiren de la compañía¿, $quién va a dar mantenimiento al sistema¿, $quién podrá dar un dictamen correcto y rápido cuando se presente algún problema ope-1 rativoe, $quién podrá hacer modificaciones para nuevos resultados so-1 licitados¿; podríamos seguir cuestionando hasta comprender que éste es el peor procedimiento cuando se solicita servicio de asesores externos. Es importante que participen activamente algunos técnicos propios de la1 compañía, cuyo trabajo consista en empaparse de los más mínimos detalles y pormenores del sistema que luego heredarán. Una buena1 estrategia para lograr esto es asignarles la tarea de documentar, con lo cual se verán obligados a enterarse de todo cuanto tenga que ver con dicho sistema; de esta manera, el proceso de recepción del proyecto será a conciencia y menos lento, garantizando así la operatividad y el mantenimientd del sistema en el futuro.

CAP 11. VENTAJAS Y DESVENTAJAS

Creo que ahora sí tenemos más elementos de juicio para aventurar un dictamen más certero; y digo aventurar porque quien decida de qué lado debe inclinarse la balanza será el responsable de contratar asesoría externa. La manera como intuya que debe dirigirla es la que, con el tiempo, le dirá si su decisión fue buena o mala, porque hasta para contratar asesoría externa se debe estar preparado; si no, los resultados son desastrosos.

Para terminar, desde mi punto de vista la asesoría externa es una opción excelente cuando se sabe dirigir; note usted algunos de sus beneficios inmediatos:

Se resuelve un problema a corto plazo, ya que se compran conocimientos y experiencia en forma inmediata. La garantía de que los productos se entregarán es elevada, si se negocia que el pago sea a la terminación de los productos, con seguridad éstos se terminarán por completo. Los técnicos de la instalación, en su mayoría, no se verán afectados en sus proyectos vigentes. No se requerirá contratar más personal, pues esto a la larga resulta más caro por las implicaciones que se adquieren al hacer una contratación formal. El pago de la asesoría externa es por única vez y no de por vida, como en el caso de los empleados propios.

La asesoría externa es la peor opción si no se está preparado o no se sabe cómo dirigirla. Por tanto:

La asesoría externa: jventaja o desventaja<

¡Usted dirá!

RESUMEN

Cuando algún proyecto resulte de tal magnitud que no pueda ser cubierto por personal técnico de la propia compañía, quizá piense en contratar los servicios de asesores externos. Si es así, no lo haga a la ligera, prepárese a conciencia y siga un método que le garantice que la opción será exitosa. Haga una selección metódica con el fin de elegir al grupo más preparado para resolver el problema. Usted será el director del proyecto, nunca permita que los asesores hagan lo que más les convenga. Dirija el proyecto hacia el éxito y marque a los asesores el camino que deben seguir; haga que trabajen, pero bajo el método que a usted convenga. Nunca deje el negocio en manos de los empleados

RESUMEN

porque irá al fracaso. A usted es a quien interesan los buenos resultados, no suelte las riendas ni permita que se pierda tiempo inútilmente. Dé la dimensión perfecta a la terminación de cada actividad y no lo dé p o ~ hecho cuando no exista un producto tangible. Compruebe que los resultados del trabajo son cabalmente cubiertos mediante pruebas y demostraciones exhaustivas y no con revisiones superficiales. Apruebe el proyecto cuando esté en operación y no cuando le hayan mostrad sólo algunas pruebas. Integre personal propio de la empresa desde e '1 principio del proyecto, para así no depender indefinidamente de lo. asesores. La asesoría externa es una opción excelente cuando realmente se sabe dirigir; y es la peor opción si no se está preparado o no se sabe cómo dirigirla. La asesoría externa jventaja o desventaja¿, eso lo contes- tará usted según su punto de vista y experiencia.

Importancia de la participación de los usuariols

Problema

Los usuarios de la información están frecuentemente insatisfechos por la Falta de un nivel de servicio acorde con sus necesidades reales; y en algunos casos tienen un total distanciamiento del área de informática.

Esta situación se genera básicamente por una falta de comunicación muy grande, pues con frecuencia se olvida que los usuarios realizan quizá la tarea más importante dentro de los objetivos específicos de los sistemas de información de una empresa, ya que son ellos en esencia quienes hacen uso efectivo de la información producto de los procesos de la computadora, y quienes realmente pueden evaluar la verdadera utilidad de dicha información; sin embargo, casi siempre se les aísla y se les obliga a depender de lo que a juicio de los técnicos debe considerarse dentro de los diseños de sistemas, razón por la cual, en muchas situaciones, los usuarios manifiestan su inconformidad, puesto que los resultados de los sistemas no alcanzan a cubrir sus necesidades de información, que a su vez les permitan hacer fluido su trabajo operativo


1. Para todo diseño de sistemas es de vital importancia hacer partícipes a los usuarios, de manera que se sientan parte integrante de un mismo equipo de trabajo, y que estén conscientes que el éxito de los sistemas de informa- ción depende en gran medida de su participación activa, pues son ellos quienes realmente viven la problemática de la falta de información; por tanto, son ellos la fuente Fundamental que dará la pauta a los sistemas por diseñar. No basta con solicitarles datos acerca de los problemas por resolver sino pedirles sus puntos de vista, sobre cómo, a juicio de ellos, podrán resolverse; hacerles sentir además que participan desde el análi- sis y el diseño. De la misma forma debe revisarse junto con ellos cada uno de los resultados por obtener, así como la utilización provechosa que se hará de los mismos; por ningún motivo se les hará sentir que se les están imponiendo.

Mediante esta estrategia ellos sentirán que en parte también son responsables de lo que se logre con el sistema y en consecuencia, siempre estarán dispuestos a colaborar de común acuerdo y difí- cilmente habrá Fricciones. Lejos de eso, la relación será más estrecha en un ambiente profesional y de participación conjunta. Con esto se fomentará una realidad sana, pero poco aceptada: el centro de cómputo y los informáticos son elementos de servicio, mas no "dictadores de órdenes".

2. Con el fin de que exista un entendimiento más efectivo y una co- municación más estrecha, es necesario que el personal técnico organice seminarios sobre procesamiento de datos para todos los niveles de usuarios de la información, en los cuales se den a conocer los conceptos más elementales, pero necesarios, para que comprendan con facilidad los tecnicismos mas usuales del ambiente y no se sientan cohibidos cuando éstos son mencionados. Pues cuando un informática entrevista a un usuario y comienza a mencionar tecnicismos que éste no entiende, automáticamente se crea una barrera que vuelve tediosa la entrevista; a consecuencia de esto, el usuario ya no quiere participar y entonces nace el recelo de uno hacia otro.

3. Como una Filosofía que todos los informáticos deben establecer para toda entrevista con usuarios, se sugieren los siguientes puntos:

Documentarse sobre las características y funciones del entrevistado, siendo esto útil para entrar en confianza, hablando en los términos del usuario. Destacar la importancia de la intervención del entrevistado en el desarrollo del proyecto por implantar, para lograr su apoyo. Dirigir la entrevista para que el entrevistado plantee las soluciones al sistema, con objeto de que lo sienta como creación suya.

Hablar con tacto, sin herir susceptibilidades ni criticar. Saber escuchar, pero sin dejar de tener iniciativa. Contagiar entusiasmo por el proyecto. Dejar que el entrevistado se explaye sobre sus funciones, para captar ideas que beneficien al sistema. No permitir que el entrevistado lo desvíe del objetivo básico de la entrevista, pero con discreción. Hablar con seguridad y evitar ser el entrevistado en lugar del entrevistador, sin ser demasiado brusco. Toda entrevista provoca situaciones tensas, por ello hay que tener seguridad en sí mismo, buena presentación, hablar con claridad, no ser irónico, no intimar con el entrevistado y ser cordial y agradable.

4. Por último, es importante elaborar un cuestionario antes de la entrevista. Esto dará una imagen de orden y evitará que las preguntas sean improvisadas.

RESUMEN

Los sistemas que no ofrecen una solución real y completa a 10s requerimientos de los usuarios son aquéllos en los cuales no se conside- ró a éstos y casi les fueron impuestos. Es importante hacer partícipes a los usuarios desde el análisis de todo sistema, pues son ellos los que realmente conocen sus requerimientos de información. Los usuarios son la fuente principal que dará la pauta para los sistemas por diseñar. El éxito de un sistema está dado en gran medida por la participación de los usuarios. El centro de cómputo y los informáticos son elementos de servicio, mas no "dictadores de órdenes". Es necesario impartir seminarios técnicos sobre procesamiento de datos, de acuerdo con el nivel requerido por los usuarios, para que éstos conozcan los conceptos fundamentales y puedan participar con más confianza. Durante las entrevistas de técnicos y usuarios es fundamental seguir un método y elaborar cuestionarios previos.

Acercamiento entre técnicos y usluarios

Problema

Las computadoras electrónicas siguen siendo "cajas negras" para los usuarios de los sistemas de información.

Si nos remontamos un poco a la historia de la computación en México, recordaremos que en este país, por vez primera en Latinoamérica, fue creada una carrera oficial en ciencias computacionales, gracias al entusiasmo de unas cuantas personas que por fortuna comprendieron la trascendencia futura de esta tecnología. Esto ocurrió en 1964. Aún se recuerda en el ambiente computacional de México que los primeros planes de estudio en materia de informática fueron asignados al IPN, a través de la escuela tecnológica núm. 3, "Juan de Dios Bátiz". También se debe un reconocimiento muy especial a los principales promotores de dicha carrera, los cuales participaron como jefes del proyecto y de quienes se puede decir que abrieron la brecha inicial para que México no siguiera a la zaga de esta tecnología. Ellos fueron el C. P. Luis Senderos, el C. P. Roberto Bermúdez Limón y el ing. Emiliano Hernández Martínez.

Fuera de este gran esfuerzo, cuyo incalculable valor reconocemos, no recordamos ningún otro intento serio en la década de 1960 que promoviera en el nivel académico oficial esta carrera; y si lo hubo fue tan irrelevante que se perdió en el anonimato.

Lo anterior refleja por sí solo el grado de atraso tecnológico que hemos padecido y seguimos tolerando casi con la misma fuerza o quizá

más que en años anteriores. Esto ocurre y seguirá sucediendo mientras no nos interese lo suficiente esta tecnología, o peor aún, tal vez sea porque

' todavía seguimos sin comprenderla. ?Será posible que aún no reconozcamos la enorme importancia que

representa dicha tecnología para los países desarrollados¿ Y qué decir de aquellos en vías de desarrollo como el nuestro. Decimos esto porque se antoja incómodo y denigrante que si las computadoras en Estados Unidos y otros países ya eran utilizadas de manera productiva desde finales de los cuarenta, apenas 20 años después, tímidamente y más influidos que convencidos, se comenzaron a usar en México.

Esto sólo demuestra nuestro nivel de pasividad y nuestro grado de conformismo, aparte de nuestra triste realidad. Habrá que reconocer que no ha sido por falta de científicos y estudiosos mexicanos capaces de lograr incluso una tecnología propia, aunque fuera limitada. Más bien, y lo tenemos que aceptar, lo que sucede es que existe poco interés por parte de las autoridades para asignarle apoyo y prioridad a esta tecnología. Por desgracia seguimos aceptando la de "fácil aplicaciónJ1, sin el doloroso proceso que implica el desarrollo de ésta. Por ello tenemos que aceptar lo importado como verdad única y absoluta.

Antes de 1964, en México no había ninguna carrera Formal universitaria en informática; para programar equipos de cómputo no se requería personal con preparación universitaria. Tampoco hubo tiempo de pre- pararlo. Así pues, se lanzaron los cursos de cuatro a seis semanas, tanto de los proveedores de equipo, que tenían obligación de ofrecer personal capacitado a sus clientes, como de los particulares, sin ninguna obliga- ción, pero con ganas de hacer algo.

De esta manera poco a poco se fue "moldeando" el "Fantasma de la computación electrónica", es decir, comenzaba a fabricarse algo intan- gible, raro, y que sólo al mencionarlo era preferible ignorarse, porque desde un principio se consideró algo "intocable".

Sólo pocos elegidos que tuvieron la fortuna de asistir a algunos cursos improvisados y que lograron comprender a medias los conceptos básicos, o simplemente aprendieron el lenguaje de la computación, eran los que estaban "autorizados" para trazar el destino informático del país.

Por eso se crearon los "expertos" de la informática, quienes celosa- mente atesoraban sus raquíticos conocimientos de cómputo. De no haber sido así, hubiera peligrado su estatus; además se corría el riesgo de que se descubriera que la informática no era más compleja que cualquier otra materia académica, y mucho menos que fuera infranqueable como los "expertos" la hacían parecer. En esos tiempos ellos lo hacían todo: diseñaban, programaban e incluso operaban los ficticios sistemas de la época. Sencillamente impresionaban.

Con lograr que la computadora aparentara trabajar, girando cintas, leyendo tarjetas o enviando mensajes, inclusive con error, era suficiente

ACERCAMIENTO ENTRE T~CNICOS Y USUARIOS 1 69

para demostrar a los "iletrados" en la materia que ellos eran los únicos capaces de entender esos equipos.

Y qué decir cuando, mediante un pequeño programa obtenían algún reporte impreso, que por cierto muchas veces contenía resultados in- ventados o inexactos; era lo máximo. Era inconcebible para los espectadores la velocidad con que se imprimían dichos reportes (300 o 600 líneas por minuto). Por todo lo que eran capaces de hacer los "expertos", se les consideraba "sabiosn.

De lo anterior se deduce que sencillamente no había "usuariosn de la información; pero cómo iban a existir si no entendían lo que estaba ocurriendo o hacia dónde se pretendía llegar.

La información que los "usuariosn debían manejar, e incluso los procedimientos administrativos propios de ésta, siempre les fueron impuestos. Esto no es un secreto. En la actualidad, en muchas empresas sigue sucediendo, y todos los que trabajamos en el medio lo sabemos.

Cuando a principios de los setenta por fin se logra desenmascarar a muchos "expertosJ', el Tantasma de la computación" se empieza a desvanecer. Toman impulso las especialidades de análisis y diseño de sistemas, programación y operación; es decir, las cosas se empiezan a tomar más en serio y los "expertos" pierden poco a poco su fuerza, pues ya no les es posible continuar engañando y menospreciando a la nueva generación de especialistas, los cuales se encuentran más preparados.

Al haber más conciencia, no de las bondades de las computadoras sino de la necesidad del manejo y control de la información, empieza a tener sentido desarrollar análisis de necesidades de información, así como del diseño de sistemas computarizados. Por fin se piensa en que deben existir "usuarios" que puedan aprovechar los resultados de dichos sistemas.

Sin embargo, los "usuarios", al continuar desconociendo, ya no el potencial verdadero de los equipos de cómputo, sino los conceptos más elementales que les permitan "comunicarse" con los analistas de sistemas, siguen siendo ignorados, y ahora a expensas de lo que ordene y diga el famoso analista de sistemas.

Cuando por desesperación o iniciativa personal, algún "usuario", con todo e1 conocimiento de causa proponía soluciones ingeniosas durante el análisis, bastaba con que el analista le lanzará un "conejo" para convencerlo de que "eso es imposible de hacer en la computadora", y ahí quedaba todo.

De esta manera, el "usuario" seguía reprimido y aislado. Sólo se le tomaba en cuenta para entrevistarlo y obtener sus conocimientos sobre las necesidades de la información, para posteriormente imponerle los procedimientos por seguir, incluso se le entregaban los instructivos para el uso y manejo de la información, bajo consigna de que debía respetarlos porque de otra manera podría entorpecer las labores del centro de cómputo.

Así, aunque frecuentemente no le solucionaban los problemas de falta de información al "usuario", sí le ocasionaban trabajo extra para

1 70 CAF! 13. ACERCAMIENTO ENTRE TÉCNICOS Y USUARIOS

'lograr los múltiples ajustes que medianamente subsanaran las graves deficiencias de los sistemas diseñados.

Sólo reflexionando en lo anterior se puede comprender el recelo que se ha fomentado entre los "usuarios" y el área de informática. Esto tampoco es un secreto.

Al llegar a los ochenta, se ponen de moda los "paquetes de software", y se dice que ya no son necesarios ni analistas de sistemas ni programadores. Que los paquetes son del tipo "universal"; es decir, que satisfacen casi todas las necesidades de información de los "usuariosn.

La realidad de esto es que ni son "paquetes universales" ni desapa- recerán analistas ni programadores. La mayoría de los paquetes son tan rígidos que cuando existe la necesidad de algún cambio de tipo legal, o algún nuevo requerimiento de información, la respuesta es simple: "no se puede" o "implica una modificación de alto nivel".

Esto lo sabemos todos porque no es un secreto. Sin embargo, el objetivo no es criticar los paquetes, sino señalar que si antes por lo menos existían entrevistas a los "usuarios" de la información, ahora se dice que ya no es necesario. Por tanto, al "usuario" se le reprime aún más ignorando por completo su opinión y casi se le desaparece del mapa inforrnático.

Todos los que de alguna manera hemos vivido el desenlace de la in- formática en México sabemos lo anterior y lo aceptamos como un mal del ambiente. Nos hemos acostumbrado a admitirlo como una situación normal.

Nos resistimos a reconocer, o no queremos aceptar, que en la opera- ción de cualquier sistema manejado por computadora el "usuario" es realmente el "cerebro" del análisis de la información, él es quien logra que los resultados que se obtengan, producto del diseño, sean los más adecuados y congruentes con la verdadera necesidad. Sencillamente los "usuarios" son quienes conocen con precisión sus requerimientos de información.

Por otro lado, son ellos la verdadera fuente de información para con- cretar sistemas eficientes, que emitan resultados veraces y de calidad.

Los recursos de informática (computadora, paquetes, especialistas, etc.) sólo son recursos de apoyo al servicio de quienes conocen con exactitud los problemas por resolver, las necesidades de información, la justificación y los riesgos. En sí, la esencia de la verdadera razón de la existencia de los centros de cómputo son los "usuarios".

En 1984 tomó auge el hecho de poner a disposición de los "usuarios" grupos de terminales y paquetes para que ellos mismos operen directamente su información en la computadora. Esto parece ser la solución

ideal, al eliminar el cúmulo de intermediarios e imposiciones a que hemos hecho referencia.

Permitirá sin duda acortar la línea de comunicación entre el "usuario" y la computadora, y quizá al aunar los recursos de cómputo, creatividad y la experiencia del propio "usuario" en la problemática y manejo de la información, se logren verdaderos sistemas de informa- ción, acordes con las necesidades existentes.

Pero no nos engañemos otra vez al idealizar una solución que requiere preparar el terreno, que no puede suceder sólo porque así lo deseamos. Seamos realistas, esto demanda una estrategia lógica de pasos naturales, como cualquier programa de computadora. Recordemos que la computadora siempre se le ha presentado al "usuario" como una "caja negra".

Imaginemos que nosotros, "los informáticos", sabemos que la "caja negra" contiene un león en su interior. Ahora se le dice al "usuario" que se acerque sin temor a la "caja negra" (al león), pero sólo se lo pedimos, es decir, no lo preparamos. El "usuario" confía en nosotros y se acerca; entonces el león se lo come, pero no es eso lo que queremos.

Por lógica, el primer paso que debe darse es hacer que el "usuario" y el león se conozcan y se conviertan en amigos. De lo contrario, el león sentirá que el "usuario" lo quiere agredir; aunque éste simplemente desea acercarse, el león lo atacará.

Para evitar esto existen dos opciones inmediatas: la menos prudente consiste en amaestrar al león para que no ataque, sin embargo, nunca se puede saber cuándo el león va a enloquecer y atacar; la segunda es más sensata, capacitar al "usuario" para que sepa con certeza cuándo el león tiene intenciones de atacar y se le den armas y recursos para que, aunque el león (amaestrado o no) ataque, el "usuario" siempre resulte ileso.

De esta manera, por instinto natural, el león se rendirá y preferirá ser amigo del "usuario". Lo importante es que éste estará preparado.

Esta segunda opción se puede lograr paulatinamente a través de seminarios graduales de "sensibilización" hacia los "usuarios". El objetivo es que conozcan la "caja negra", sepan de sus bondades, distingan entre los riesgos y olviden el "fantasma del cómputo". Cuando dominen la herramienta, el producto será de alta calidad.

Dominar la herramienta no implica convertirlos en especialistas de cómputo, lo que se persigue es enseñarles la filosofía de la computación, así como proporcionarles los conceptos necesarios para que comprendan e1 funcionamiento y la operación de estos equipos.

El resto llegará como consecuencia del interés, inquietud e ingenio natos del "usuario". Más ahora que el software moderno y las poderosas computadoras ponen a disposición del usuario imágenes, sonido y diálogo conversacional. Pero los informáticos de una empresa son los responsables de lograr que la tecnología sea aprovechada en función de los objetivos de negocio ahí establecidos.

En Estados Unidos y otros países, las computadoras ya eran utilizadas de manera productiva desde finales de los cuarenta; 20 años depués, comenzaron a utilizarse en México. Nuestro nivel técnico respecto de este campo se ha visto estancado durante mucho tiempo. Es evidente que si los profesionales del medio aún no logramos aprovechar debidamente esta tecnología es porque no la hemos asimilado en su plena magnitud; cómo podemos pedir que los usuarios, a los que nosotros mismos hemos relegado, se integren rápidamente y se responsabilicen del manejo de la información con el solo hecho de ponerles terminales de video y PC enfrente. Tenemos que comprender que la computadora siempre se le ha presentado al usuario como una "caja negra". Cierto es que se va haciendo más estrecho el tramo que separa al usuario de la computadora, a través de nuevos métodos y tecnología más avanzada, pero también es cierto que la integración del usuario no puede ser automática. Para lograr eso es Fundamental que quienes conocemos el ramo guiemos al usuario y lo capacitemos en Forma paulatina hasta lograr que la "caja negra" le sea descubierta sin complicaciones, sin temores, sin elucubración; más bien con sencillez, con objetividad y con los conceptos necesarios para que los usuarios comprendan conceptual- mente el Funcionamiento de estos equipos y sean ellos mismos quienes se integren cuando sientan que están preparados, y no presionados por nuestra prisa. Nosotros los técnicos estamos obligados a facilitarles la transición. (véase cap. 21). Hoy en México ya es tiempo de saber que la tecnología de la informática se nos ha puesto a disposición no sólo para usarse sino, mejor aún, para aplicarse en la consecución de los objetivos de negocio y de servicio de las empresas e instituciones. Caray. Como si esto fuera un secreto.

AudPtoría técnica: Lpor qué? ¿para qué?

Problema

Casi ningún área de informática realiza auditorías técnicas periódicas para obtener diagnósticos de su situación y así poder superar sus deficiencias en gran medida.

En toda área de informática existen desacuerdos en cuanto a cuál es la mejor manera para lograr una coordinación efectiva entre los distintos departamentos que la conforman. Es común que cada departamento tenga autonomía en su modo de trabajar, sin embargo, el trabajo que desarrolla un departamento y la manera como lo hace, indefectiblemen- te afectan, de un modo o de otro, el trabajo de los demás.

Por lo general se olvida que ningún departamento por sí solo puede lograr los objetivos globales de procesamiento de datos. Para alcanzarlos, es indispensable que existan acuerdos claros y específicos sobre los procedimientos que deberán seguirse, desde la captura de datos hasta la obtención de resultados; desde la definición de programas hasta la obtención de resultados de las pruebas integrales de cada sistema por liberar; desde la distribución de resultados hasta la correcta utilización de elIos por parte de los usuarios de la información. En todas las etapas intermedias deberá existir un completo conjunto de acuerdos y comunicados que permitan producir siempre información veraz y oportuna.

Esto quiere decir que deberán existir métodos de trabajo individuales por cada departamento, que comuniquen e interrelacionen el trabajo

como un todo, porque de no ser así, cada departamento trabajará a su manera sin importar lo que los demás hagan ni la manera como realicen su trabajo. Esto sólo ocasiona errores frecuentes y costosos que al final todos tratan de eludir.

El objetivo de las auditorías técnicas es cómo involucrar un árbitro entre todas las áreas, de manera que sea posible comprobar con un alto grado de acierto si todos los procedimientos establecidos logran fluidez, consistencia y oportunidad en el desarrollo del procesamiento de datos; encontrar los puntos críticos que lo entorpecen y promover soluciones rápidas; además de hacer críticas estrictas de tales procedimientos y confirmar si esa es la mejor forrna de hacerlo o es factible optimizarlos.

1. Es recomendable que toda empresa realice auditorías técnicas, ya sea por especialistas propios, por asesores externos dedicados a estas labores o por técnicos de otra instalación modelo.

2. Las auditorías deberán ser periódicas (cuando menos una por año) porque casi siempre se encuentran fallas tan sutiles que difícilmente son detectadas en revisiones superficiales; sin embargo, con frecuencia resultan ser la causa principal de los fracasos de la instalación.

3. Cada auditoría deberá hacerse a profundidad y atendiendo cada área por separado para que al final sea más fácil comprobar si éstas se encuentran interrelacionadas en forma congruente.

A continuación se muestran cuestionarios base con los cuales es posible iniciar una auditoría por área de acción.

a) Auditoría en el área de análisis y diseño de sistemas:

$Qué metodología de desarrollo se sigue en los diseños< $Trabajan todos los analistas con base en la misma metodología de desarrollo t $Cómo documentan el diseño de un sistemat $Qué método de control siguen para actualizar la documenta- ción cuando hay cambios en los sistemas ya en operación< $Cómo definen los programas para su elaboración< $Cómo critican y se aseguran que los programas son confiables para ponerlos en producción< $Qué tipo de controles establecen para hacer cambios en los sistemas ya en producción< $Los sistemas están diseñados por módulos que facilitan su mantenimiento en el futuro<

$Qué tipo de controles utilizan para sostener la integridad de los sistemas en cuanto a posibles intrornisiones por personas no autorizadas< $Desarrollan labor de optimización de sistemas< $Qué etapas deben cubrirse para liberar un sistema a producción< 3Prevén respaldos automáticos de información en los sistemas< ?Cómo determinan los niveles de analistas dentro de la insta- lación y cuáles son sus perfiles técnicos< $Normalmente cuántos analistas y de qué nivel intervienen en el desarrollo de un sistema completo6 $Planean su capacitación por objetivos<

b) Auditoría en el área de programación:

$Qué metodología se sigue en la elaboración de los programas< $Programan bajo la misma metodología todos los programadores¿ $Cuántas compilaciones promedio se requieren para depurar un programa con errores de sintaxis< $Cuántas corridas promedio de prueba se requieren para obtener resultados correctos de un programa< $Cómo y quién define los datos prueba para los programas< ?Cómo se aseguran de que los datos prueba cubren todas las condiciones posibles< $Cómo y quién determina el tiempo que se requiere para la elaboración de cada programa< jCómo estructuran la documentación de cada programa< $Programan bajo la filosofía estructurada< $Cómo controlan las modificaciones a que son sujetos los programas< $Mantienen actualizada la documentación de cada programa< $Cómo se difunden las experiencias de los programadores< ?La capacitación se plantea bajo objetivos¿ $Hacen los programadores labor de investigación técnica< $Todos los programas arrojan cifras de control< ?Cómo y quién determina que un programa sea confiable para liberarse a producción¿ $Cómo y quién determina la complejidad y asignación de cada programa¿ $Existen estándares de programación< ?Cómo se determina el nivel y perfil técnico de un programador<

c) Auditoría en el área de sistemas operativos:

$Qué metodología siguen en la generación de los sistemas operativos< $Cada cuando suben el nivel de los sistemas operativos y en qué basan esa decisión< $Cuál es el método de prueba para las nuevas versiones de los sistemas operativos< ?Cómo evalúan los paquetes de software susceptibles de adquirirse e instalarse¿ Una vez instalado un nuevo paquete de software o sistemas operativos, ?qué procedimiento siguen para que los usuarios conozcan y usen las nuevas facilidades soportadas< ?Cómo corrigen las fallas de los paquetes y del sistema operativo, y cómo prueban tales correcciones< $Cómo van controlando el mantenimiento y cambios a paquetes y al sistema operativo< $Existen políticas de uso para paquetes y sistema operativo< $Cuáles son los procedimientos de respaldo y recuperación del sistema operativo< $Cómo mantienen y depuran la asignación de espacio en discos< $Hacen labor de afinación del sistema operativo< $Cuáles son los estándares de documentación de esa área< jMonitorean permanentemente el comportamiento del equipo de cómputo< $Qué estadísticas obtienen sobre el uso de la computadora< ?Cómo determinan el nivel y perFil técnico de un programador de sistemas operativos< ?Establecen estándares de nomenclatura para los archivos<

d ) Auditoría en el área del teleproceso:

$Quién determina la estructura de la red de teleproceso< $Son los tiempos de respuesta los deseados¿ $Existen procesos rápidos para restablecer el servicio de teleproceso en caso de caída< $Cómo están documentados los procedimientos de recupera- ción< ?Llevan estadísticas sobre las transacciones del servicio de teleproceso¿ ?Bajo qué condiciones y cómo prueban nuevas aplicaciones de teleproceso< $Planean la capacitación de los usuarios del teleproceso<

RESUMEN

?Tienen establecidos sus niveles de servicio¿ ?Qué niveles de seguridad tienen establecidos para el acceso a los datos, vía teleproceso¿

* ?Existen estándares de documentación dentro de esta áreat ?Cómo determinan el nivel y perfil técnico de los integrantes de esta área¿ $Existe capacitación por objetivost

e) Auditoría en el área de operación:

?Cuántas cargas del sistema operativo se dan a diario¿ ,?Cuáles son las razones más frecuentes¿ ?Registran las razones de éstost $Siguen procedimientos plenamente documentados que los guíen al tratar de recuperar fallas de hardware y software en los componentes críticos¿ ?Tienen calendarios establecidos para el mantenimiento de la computadora¿ ?Cómo reconstruyen archivos dañados o perdidos6 ?Existen calendarios para el control de la producción¿ ?sÜé procedimientos siguen en la distribución de resuitabosc ?Cómo verifican que los resultados sean correctos¿ ?Cuál es el nivel normal de multiprogramaciónt ?Qué procedimiento siguen cuando existe alguna falla en los programas en ejecuciónt $Cómo identifican los archvos en cinta magnéticat $Cuáles son las causas más frecuentes por las que se interrum- pe el servicio¿ -

$Existen procedimientos de resguardo de la informaciónt 2 Los planes de capacitación son por objetivos¿ ?Cómo determinan el nivel y perfil técnico de los operadores?

RESUMEN

Es común que dentro de la organización del área de informática cada departamento trabaje a su modo, sin tomar en cuenta que la manera de hacerlo necesariamente afecta el desempeño de los demás. Por lo general se olvida el hecho de que ningún departamento, por sí solo, puede lograr los objetivos globales del procesamiento de datos. En todas las etapas intermedias deberá existir un completo acuerdo y eficiente comunicación para coordinar esfuerzos. Los métodos de trabajo que se implanten deberán considerar este aspecto, de manera continua, no deben ser producto de eventualidades, sino que deben estar

perfectamente reglamentados los canales de comunicación y límites de acción y responsabilidad entre departamentos. El objetivo de la auditoría técnica es semejante a involucrar un árbitro que regule las actividades entre los distintos departamentos del área de informática. A la par, el proceso de auditoría consistirá en detectar deficiencias en el desarrollo del trabajo; desde la captura de información hasta la obtención de resultados en la computadora, y hacer el seguimiento oportuno para corregir cabalmente las fallas detectadas. Toda empresa deberá realizar auditorías técnicas periódicas, ya sea por personal interno dedicado a estas labores, o por consultores externos expertos del ramo. Se deberá auditar cada departamento por separado con el fin de conocer si sus actividades se complementan ordenadamente con los restantes. La audi- toría técnica es una buena práctica, sobre todo en instalaciones grandes propensas al desorden y a la falta de comunicación. Una metodología de trabajo se puede entender como la descripción de un conjunto de actividades que definen la forma ordenada de realizar un proceso completo a fin de garantizar productos o servicios de calidad estándar.

Evaluación del software

Problema

Muchas empresas acostumbran adquirir paquetes de software que a la postre resultan de escasa o nula utilizaci6n.

Con el avance de la tecnología en materia de hardware, se ha hecho posible que los equipos de cómputo se vuelvan cada vez más económi- cos. Por el contrario, el software se ha encarecido y con frecuencia se vuelve difícil de encontrar en el mercado, de manera que sea ajustable a las verdaderas necesidades de cada empresa. Es conocido que algunas compañías distribuidoras y fabricantes de equipo de cómputo han lan- zado convocatorias para fusionarse con otras compañías o grupos que se dedican al desarrollo de software, elevándose así por esta demanda los costos de dicho software.

Sin importar que este fenómeno sea cada vez más grave, muchas instalaciones han adquirido el vicio de comprar prácticamente cualquier paquete de software que se les ofrece, aun cuando saben que sólo harán poca utilización del mismo. Si a lo anterior agregamos que sólo en contadas ocasiones se toma en cuenta al usuario, que se supone recibirá el servicio, encontramos que finalmente se compra sin objetivos claros y, por tanto, con muy pocas posibilidades de un uso efectivo de tales paquetes.

Existen instalaciones que por no hacer una evaluación seria, compran paquetes que en poco tiempo resultan obsoletos o son incompati-

CAF! 15. EVALUACIÓN DE SOFTWARE

bles con otros equipos de la misma instalación. Al paso del tiempo se encuentra que la instalación sigue pagando mantenimiento para varios paquetes que no han sido utilizados.

Esto se traduce en un gasto infructuoso y elevado en la mayoría de los casos. No hay necesidad de que esto suceda si hacemos un estudio preliminar, aunque resulte tedioso, para demostrar la conveniencia de la adquisición de tal o cual producto de software. Seguir comprando a ciegas y sin un fin específico y costeable sólo representará incrementar el presupuesto del área de informática, lo cual a nadie beneficia. Es preferible aprovecharlo para requerimientos más necesarios.

Es inaudito que algunas instalaciones argumenten que debe gastarse lo presupuestado para este año por concepto de compra de software, porque si no el siguiente ya no les será autorizado un presupuesto similar o mayor, y más vale que sobre y no que falte. Por eso habrá que gastarlo en lo que sea. Tales argumentos sólo reflejan una falta de sentido profesional y de responsabilidad.


En primer lugar, ninguna sugerencia surtirá efecto si partimos del argumento anterior. Aun así, una opción más sensata es establecer que el alcance del presupuesto por compra de software será dado no en forma anual ni con un estimado teórico, que más bien es ilógico. Es preferible que cuando existe la necesidad de la evaluación de algún paquete de software y se demuestre su verdadera justificación, sean los directivos usuarios, quienes vayan a recibir el servicio, los que lo absorban dentro de su presupuesto particular. En otras palabras, que este tipo de presupuestos los administre el propio usuario. A fin de cuentas, los usuarios son los que verdaderamente hacen uso de los servicios de cómputo. Los técnicos del área de informática sólo deberían ser los responsables de llevar a cabo la evaluación preliminar y las sugerencias de adquisición, con la garantía de que será un s o b a r e de alto beneficio para dicho usuario; y éste será quien dictamine la necesidad final de adquirirlo. Algunas instalaciones ya llevan a la práctica este procedimiento y los resultados han sido evidentemente mejores que los gastos infructuosos ya mencionados.

Las fases que deberá cubrir una evaluación de software, en el sentido serio y profesional, se enmarcan a continuación:

Fase 1. Cuando se identifica la necesidad concreta de algún usuario para la adquisición de algún paquete de software, lo primero que habrá que hacer es formar un comité entre el grupo de especialistas técnicos del área de informática y los responsables del proyecto por

parte del usuario, quienes conocen sus verdaderas necesidades de infor- mación.

Fase 2. Dentro del comité, el usuario dará una plática detallada acerca de los objetivos de información que se persiguen, para que el personal técnico capte las verdaderas necesidades.

Fase 3. Una vez comprendidos los objetivos concretos por parte de los integrantes del comité, el grupo técnico hará un análisis del mercado para conocer cuáles productos cubren las necesidades específicas del proyecto. Para identificar el producto más idóneo, deben considerarse los siguientes parámetros de evaluación:

1. Alcance práctico del producto. En este punto habrá que tomar en cuenta si las facilidades que ofrece el producto cubren en su totalidad 10s requerimientos del usuario. Para esto será indispensable que si el producto cubre, además de 100 % de las necesidades detectadas, algunas otras, habrá que encontrarle una utilidad práctica para explotarlo en toda su magnitud,

2. Compatibilidad con el software existente. Es determinante que el producto sea completamente compatible con el software de la instalación, pues no es conveniente realizar cambios ni de un lado ni de otro, a menos que dichos cambios sean superficiales y no modifiquen la filosofía original del producto (entiéndase como cambios superficiales la adecuación de algunos parámetros solamente).

3. Sencillez para la explotación del producto. Algo muy importante es que el uso del producto sea lo más sencillo para el usuario, de manera que le simplifique el trabajo en vez de someterlo a una especialización profunda y lenta. Si esto no se cumple, el uso del

'

producto tiende a dejarse de lado. 4. Mantenimiento para actualizaciones futuras. El producto debe ser

sujeto de cambios rápidos y sencillos para cubrir posibles modificaciones, requeridas por el usuario, en atención principalmente a las que se generan por cambios legales. Es decir, debe ser un producto flexible, factible de ser modificado a partir de parámetros y no por efecto de modificaciones en el cuerpo de los programas.

5. Sencillez para la instalación del producto. Algo importante de evaluar también es la sencillez de su integración al software actual, ya que hay productos que hacen muy fluida a ésta y no se requiere personal especializado para tal fin. Existen productos cuya integración requiere especialistas difíciles de conseguir o capacitar. Si éste es el caso habrá que considerarlo, si no existe otra opción.

6. Soporte por parte del proveedor. Es importante, durante la eva- luación, que exista personal del proveedor, capacitado para pre-

CAP. 15. EVALUACIÓN DE SOFTWARE

ver, por si se presentara, algún problema difícil de resolver en forma local, y atenderlo inmediatamente.

7. Mateial didáctico que proporciona el proveedor. Habrá que considerar si el material didáctico para la explotación del produc- to es completo y de calidad, sobre todo que se apegue al nivel del usuario, para lograr una explotación inmediata y completa de las facilidades que proporciona.

8. Cantidad de usuarios del producto en el mercado. Un buen unto de comparación, que incluso dará más confianza en la a dP quisi- ción del producto idóneo, es investigar en el mercado alguna instalación que lo tenga en operación, con el fin de intercambiar opiniones que sean de beneficio para el dictamen.

9. Costo del producto. En términos económicos, hay que tomar en cuenta el costo del producto para hacer un análisis de costo- beneficio y poder determinar la conveniencia de la adquisición.

Fase 4. Con el fin de lograr una selección más ventajosa, es recomendable que, partiendo de la evaluación anterior, se considere un máximo de tres proveedores y a cada uno por separado se le pida una demostración en la cual sea posible hacer una prueba completa en el ambiente del usuario que recibirá el servicio.

Fase 5. Se procederá a efectuar una junta de trabajo entre los miembros del comité, cuyo objetivo sea determinar la decisión con respecto al producto por adquirir; se elaborará también un documento oficial que contenga los siguientes aspectos:

a) Índice. 6) Descripción de los objetivos por alcanzar con el producto. c) Lista de compañías proveedoras a las que se trató.

d ) Procedimiento de selección que se cubrió para la selección del producto.

e) Análisis de costo-beneficio, donde se enmarque el nivel de utili- zación del producto con respecto a sus facilidades.

f ) Aplicaciones en que se explotará el producto. g) Observaciones y recomendaciones finales. h) Firmas de los integrantes del comité.

Fase 6. Iniciar trámites de adquisición.

Una vez adquirido el producto, se procederá a realizar el procedimiento de integración y puesta en marcha, a través de los siguientes pasos de control:

Paso 1. La recepción de cualquier producto de software estará centrada en la mesa de control de1 área de informática, cuyo responsa-

ble comprobará que el material está completo, auxiliándose de la rela- ción que acompaña a dicho producto. Si detecta que viene incompleto, lo rechazará de inmediato. En caso contrario, firmará de recibido.

Paso 2. Una vez recibido el producto, deberá darlo de alta en la re- lación de software que existe para tal fin; al mismo tiempo, pasará la comunicación formal al departamento de soporte técnico. Dicha comu- nicación contendrá lo siguiente:

a) Nombre del producto. b) Fecha de recepción. c) Nivel de actualización o versión de release.

d) Clave del producto.

Los elementos de que consta el producto, como son: manuales, cintas, instructivos, etc., serán centralizados en la mesa de control, cuyo encargado lleva registro y control estricto.

Paso 3. Es recomendable sacar copias de manuales, cintas, instructivos, etc., para tener siempre un respaldo en caso necesario.

Paso 4. Los elementos del producto original deberán quedar centralizados en lugar previamente definido, de manera tal que a partir de ese momento sólo se trabaje con las copias.

Paso 5. Al momento de decidir la integración de cualquier producto, la persona asignada para ello deberá solicitar los elementos necesarios a la mesa de control, quien a su vez llenará una forma que contenga los siguientes datos:

a) Nombre de la persona que requirió el producto. b) Fecha y hora. c) Nombre de cada elemento requerido, así como su identificación

individual. d ) Fecha y hora de devolución de los elementos requeridos cuando

el producto haya quedado instalado. e) Firmas de entrega y devolución de ambas personas.

Paso 6. El responsable de la integración hará un estudio a conciencia sobre el procedimiento de integración; además, deberá elaborar una lista de verificación detallada sobre los pasos de dicha integración.

Paso 7. Con base en la lista de verificación previamente elaborada, se procederá a integrar el producto. Como resultado de la integración, se deberá estructurar una carpeta documental que contenga, aparte de la lista de verificación, todos los listados producto de la integración, así como notas explicativas de las experiencias encontradas durante el proceso. Eso será muy valioso para consultas futuras.

Paso 8. Después de la integración se realizarán pruebas exhaustivas, las cuales deberán ser avaladas por el usuario que recibirá el servicio.

Paso 9. Se capacitará a1 usuario para hacer10 autosuficiente en el uso del producto, si ese Fuera el caso.

Paso 10. Finalmente, después de liberar a producción el producto, se entregarán a la mesa de control los elementos solicitados en un principio, así como la carpeta documental que contenga los antecedentes de la integración.

RESUMEN

Pese a que en años recientes se ha incrementado en forma desmesurada el costo del software, muchas empresas han adquirido el vicio de comprar lo que les ofrezcan sin haber evaluado a conciencia la verdadera utilización que tendrá éste. Con frecuencia no se toman en cuenta las opiniones de los usuarios para adquirir productos que en verdad se ajusten a sus necesidades de servicio. Existen instalaciones que, por no hacer una evaluación seria, compran paquetes que en poco tiempo se vuelven obsoletos o son incompatibles con otros equipos de la misma instalación, donde también se deberían utilizar. Lo peor es que algunas instalaciones argumentan que habrá que gastar el presupuesto para ese año porque de lo contrario, al año siguiente ya no se les autorizará. Es recomendable para hacer compras de software más provechosas que se forme un comité entre técnicos y usuarios; que el presupuesto asignado a este rubro sea manejado por los propios usuarios. Deberán existir re- glamentos oficiales que permitan evaluaciones exhaustivas y confiables; y se deberán aplicar métodos de trabajo para la integración de todo producto de software.

El enigma de las bases de datos I

Problema

Las instalaciones que han decidido cambiar sus archivos de datos tradicionales a la estructuracibn de bases de datos, diflcilmente han conseguido resultados a corto plazo debido a inmadurez técnica y falta de profesionales especializados.

La tecnología en el campo de la electrónica alcanzó avances significativos en pocos años. En un corto periodo se diseñaron computadoras bastante rápidas en sus tiempos de proceso, cuya velocidad, que en algún tiempo se cuantificaba en términos de microsegundos, pasó a ser mucho menor. Esto representó un verdadero logro en el diseño del hardware, porque también se diseñaron periféricos capaces de ser congruentes con la velocidad alcanzada por la unidad central de proceso. Sin embargo, surgió un problema serio: el software no había logrado el mismo desarrollo, y por tanto, seguía siendo tradicional, principalmente en la organización de datos y sus métodos de acceso; es decir, en comparación con el hardware, éstos seguían siendo casi primitivos, haciendo que la velocidad de la computadora fuera frenada en gran medida. De esta manera, los ingenieros en diseño de software se vieron precisados a desarrollar un nuevo concepto, llamado bases de datos. Este propósito, entre otras cosas, perseguía aprovechar la velocidad de la computadora, surgiendo así una variedad de nuevos arreglos de datos, acordes con el avance del hardware.

186 CAP. 16. EL ENIGMA DE LAS BASES DE DATOS

En la actualidad existen en el mercado distintos tipos de bases de datos; desde las de estructuras jerárquicas hasta las llamadas relacionales; existen también las estructuradas por redes llamadas asociativas, así como otras que sustentan calificativos pomposos como argumento comercial.

Es verdad que dichos tipos de organización de datos son mejores que los anteriores y superan con mucho las facilidades tradicionales, pero también es cierto que los requerimientos técnicos necesarios para un aprovechamiento eficiente, tanto en hardware como en s o b a r e , superan a los anteriores. Es más, los conocimientos técnicos de los encargados de generar, diseñar y mantener las bases de datos no se alcanzan de un día para otro; por el contrario, es necesaria la formación de especialistas del ramo. Esto por supuesto no puede ser un argumen- to de venta y por ello se tiende a disfrazar, originando que quienes por entusiasmo o por una auténtica necesidad, deciden adquirir algún paquete de bases de datos, por lo general tarden mucho tiempo para lograr un buen aprovechamiento de sus bases de datos.

Con lo anterior no se pretende afirmar que las bases de datos sean malas o que representen un gasto elevado e infructuoso. Al contrario, estoy convencido de que la gran mayoría de las instalaciones, grandes o medianas, requieren por necesidad cambiar al concepto de bases de datos. Para demostrarlo, veamos algunos beneficios que de ello resultan:

Se adquiere una gran flexibilidad para estructurar registros de datos con longitud variable dentro de una misma base de datos. Se permite una amplia posibilidad en la eliminación de datos redundantes. Se fortalece la capacidad para limitar a los usuarios de manera que sólo puedan acceder a datos a los que están autorizados, lo cual se traduce en un amplio rango de confidencialidad. Se logra un buen ahorro de espacio en dispositivos de discos, ya sea por la eliminación de redundancia de datos o por los nuevos métodos de cálculo de espacio requerido. Existen mejores métodos de acceso optimizados, con lo cual se logra aprovechar en forma eficiente la velocidad de la computadora. Se amplía la versatilidad en la programación para el manejo de datos. Se permite que una misma base de datos sea la fuente para varios sistemas relacionados. Se puede estructurar una misma base de datos por fases, lo que permite desarrollar también sistemas por fases, pudiendo obtener así resultados en forma casi inmediata, sin necesidad de haber concluido la implantación de sistemas completos.

Existe una amplia posibilidad y flexibilidad para hacer preguntas no planeadas sobre el contenido de los datos, así como la obten- ción de reportes y estadísticas sólo con la codificación de algunos comandos de control. Para los sistemas de teleproceso y accesos en tiempo real, es evidente que, dadas las facilidades anteriores, son la organización de datos ideal.

Es fácil comprender las enormes ventajas que representa el uso de bases de datos en el ámbito informático, pero lo que no resulta tan cierto es la supuesta facilidad para estructurarlas, explotarlas, adminis- trarlas y mantenerlas. No se piense que este es un comentario suelto o mera especulación mía, basta acudir a las instalaciones que lo han intentado para conocer la gran cantidad de tiempo y dolores de cabeza que les ha representado. Habrá que decir que muchas instalaciones no han logrado, por lo menos, estructurar correctamente sus bases de datos, ya que no han pasado de crear un gran archivo que dista mucho de ser una base de datos. Otras instalaciones, no pocas, no cuentan ni siquiera con un grupo de técnicos capacitados, no sólo para estructurar sus bases de datos, sino también para conocer qué especialidades tiene que cubrir. La prueba está en aquellas instalaciones que han adquirido este tipo de paquetes y después de varios meses siguen esperando a alguien que les ayude en la generación de los mismos.


La problemática expuesta tiene su raíz en que la mayoría de las instalaciones se han aventurado hacia un terreno desconocido, sin haberse tomado la molestia de investigar a conciencia los requerimientos técnicos y humanos necesarios para participar con éxito en este nuevo entorno. Han permitido que lo novedoso del concepto y lo ventajoso de sus facilidades los arrollen como una gran ola y ahora se ahogan en un mar de problemas. Es inconcebible que se emprenda una aventura donde el argumento de juego sea lo más valioso de un centro de cómputo, es decir, sus archivos de datos. Los que ya emprendieron la aventura, en la mayoría de los casos, están más ocupados en atender su propio rompecabezas que en escuchar sugerencias; sin embargo, confío en que hayan aprendido lo suficiente de sus errores como para ocuparse de encontrar las mejores opciones correctivas. Para aquellos que prefieren ir sobre pasos firmes al emprender cualquier tarea, y sobre todo una de tal envergadura, seguramente les resultarán de gran interés las siguientes recomendaciones al respecto:

188 CAP 16. EL ENIGMA DE LAS BASES DE DATOS

Entender perfectamente los requerimientos técnicos de hardware, software y de especialización de personal, antes de adentrarse en el ámbito de las bases de datos. Visualizar con detenimiento los objetivos de servicio, resultados específicos y niveles de información que se pretenden. Determinar con precisión los volúmenes de datos con los que operan en la actualidad y las estrategias más viables de conver- sión de archivos tradicionales a concepto de bases de datos. Hacer un inventario de los sistemas por implantar y determinar la relación que existe entre ellos. Hacer una estructuración específica del departamento especializado en el diseño, la administración y el mantenimiento de las bases de datos. Considerar que se tendrá que hacer una reevaluación en las labores de análisis y diseño de sistemas, para el mejor aprovechamiento de este nuevo concepto. Estructurar un plan estratégic8 para la integración del concepto de bases de datos, con el fin de ir cubriendo con rigor todos los prerrequisitos por considerar, antes de intentar la definición conceptual de sus nuevos diseños. Buscar la asesoría de un especialista de bases de datos, no representante del producto que se va a adquirir. No improvisar técnicos queriendo ganar tiempo, sino adquirir conciencia de que llevará un buen periodo la capacitación siste- mática de los mismos. Visitar instalaciones modelo en donde se han implantado bases de datos y averiguar la realidad de 10 que esto les ha representado en tiempo y esfuerzo. Evaluar distintos paquetes que ofrecen en el mercado para seleccionar aquel que reúna las características más ventajosas para su ambiente particular. Jamás, y lo digo muy en serio, entrar en negociación con algún proveedor a primera vista.

RESUMEN

Así como la tecnología avanzó en gran medida en el desarrollo de hardware, fue necesario inventar nuevas técnicas en el arreglo de datos y en los métodos de acceso. De esta manera se abordó el concepto de las bases de datos. Sin embargo, todo sucedió tan rápidamente que confia- mos en que se simplificaría el panorama para las instalaciones que decidieron adoptarlas. Este error lo hemos pagado muy caro, ya que existen instalaciones que han emprendido la aventura más por entusias-

RESUMEN

mo que por un razonamiento pleno de lo que ello implica. Cierto es que este nuevo tipo de organizaciones de datos superan con mucho a Ias tradicionales, pero también es cierto que los requerimientos técnicos para una explotación eficiente superan demasiado a los anteriores. Las bases de datos son necesarias actualmente dado el crecimiento exponencial que ha tenido la información, sin embargo habrá que tomar muy en serio el cambio a este nuevo enfoque, y sobre todo prepararse en forma sistemática para abordarlo. No resulta fácil ni rápido, como argumentan los proveedores de los productos que ofrecen en el mercado. Para integrarse al ámbito de las bases de datos será necesaria la creación de un área de especialistas que las exploten, administren y mantengan. Por imprudencia se ha permitido que lo novedoso del tema y lo ventajoso de sus facilidades nos haya arrollado como una gran ola y ahora nos ahoguemos en un mar de problemas. Los que ya emprendieron la aventura se preocupan más en salir del atolladero que en escuchar sugerencias. Los que aún no la han intentado no se detengan, prepárense primero y busquen el momento preciso cuando hayan reunido todos los prerrequisitos necesarios para ingresar a este campo.

Los métodos de trabajo y sus beneficios

Problema

N o existen metodologias de trabajo, y donde las hay difícilmente son respetadas.

Una metodología de trabajo puede definirse como el conjunto de operaciones específicas que permiten conocer con acierto la manera y la secuencia con las que deberá efectuarse una labor, así como estandarizar los eventos rigurosos a los que deberán sujetarse dichas operaciones. Esto, entre otras cosas, permite visualizar la calidad de la actividad desarrollada por cada integrante y, en consecuencia, las deficiencias de los mismos.

Es un hecho que todo tipo de trabajo requiere un orden en el desarrollo de cada actividad; no importa si el trabajo es senciilo o laborioso, de cualquier manera será necesario establecer un esquema lógico de pasos por cada operación que interviene. Será necesario dictar lineamientos de control para obtener productos modelo en acabados y calidad.

A pesar de que en el ámbito informático esto es un factor vital para el desarrollo de los sistemas y su operación, además del mantenimiento de los mismos, frecuentemente se viola esta regla. Los resultados son evidentes en muchas instalaciones que la pasan por alto, las consecuencias son costosas, tanto en tiempo como en dinero, pero mucho más en resultados incompletos, desfasados y de pésima calidad, que no reúnen

los mínimos de confiabilidad para garantizar resultados veraces y oportunos a los usuarios de información.

?Por qué no existen metodologías o por qué no se respetan cuando las hay< La respuesta es sencilla: ¡NO hay tiempo! ¡Los resultados los requieren ya, cuanto antes, sin importar mucho su calidad!

Sin duda, volvemos a entrar al mismo círculo vicioso: falta de orien- tación a los directivos; jefes inmaduros o con pésimos conocimientos técnicos y administrativos en materia de informática. En general, falta de profesionalismo de quienes aceptan el desorden y de aquellos que lo propician.

1. A lo largo de infinidad de entrevistas he encontrado situaciones de terrible desorden por no haber lineamientos de trabajo, no digamos eficientes, sino básicos para el buen funcionamiento de cada departamento que integra al área de informática. Por esta razón, cada inforrnático trabaja de acuerdo con sus posibilidades, resultando un descontrol tal que nadie sabe a ciencia cierta cuál es la situación real de los proyectos en desarrollo; en los casos de aquéllos ya en producción, los problemas son tan frecuentes que casi siempre hay necesidad de hacer trabajos de mantenimiento, no por obtener nuevos resultados sino por la mala calidad de éstos, lo cual es inconcebible en sistemas en producción. Esto provoca costos elevados y de toda índole, sólo porque no hubo previsión y orden para tales situaciones. Los jefes de cada departamento son los únicos responsables de que esto suceda, y la recomendación urgente es que se invierta el tiempo necesario para establecer sus propias metodologías; que se percaten de que esta inversión será tan provechosa y menos larga que todo el tiempo que se pierde en los ajustes Futuros.

El jefe de cada departamento deberá estar preparado para hacerlo, si por razones obvias no lo está, será necesario que se documente y tome cursos al respecto en forma inmediata. Si no quiere hacer esto, entonces pida que se haga con recursos externos a la compañía, por consuItores experimentados. Piense que será un trabajo de una sola vez y los frutos del mismo se obtendrán durante mucho tiempo.

2. En ciertos casos asistí a instalaciones donde quedé asombrado con los procedimientos de trabajo establecidos, los cuales estaban perfectamente documentados. En algunos casos habían sido desarrollados por personal propio de la instalación, incluso por áreas establecidas ex profeso; y en otros por consuItores externos, sin embargo, mi asombro fue mayor cuando comprobé que casi nadie los respetaba. Esto es responsabilidad absoluta de los jefes que lo han permitido, no basta con definir las me- todología~ y guardarlas. Son necesario una supervisión y una continuidad

CAP 17. LOS MÉTODOS DE TRABAJO

para asegurar que éstas se lleven a la práctica; es indispensable establecer puntos de control en los cuaIes un trabajo no pueda continuar si éste no se ha apegado a dichos lineamientos; hay que investigar las causas, y si es necesario, presionar al personal que no quiera sujetarse a dichas normas. He hablado bastante sobre la responsabilidad que concierne a los jefes, y continuaré haciendo énfasis sobre las funciones del mismo cuando se vea que ahí radica el mal. Sin embargo, los técnicos deberán apoyar con profesionalismo las estrategias prudentes y sanas impuestas por los jefes. Es necesario reconocer que el jefe es la directriz de una determinada área de acción y que sus actividades no consisten en atender a los técnicos todo el tiempo, éstos deben ser profesionales en sus actividades y hacer la parte que les corresponde; de lo contrario, abandónese el puesto y permítase que lo ocupe alguien que verdaderamente quiera colaborar y formar parte activa de un mismo equipo, digno de aportar conocimientos y seriedad en su trabajo.

N o existen rnetodologCas de trabajo, donde las hay, no se respetan.

RESUMEN

Una metodología puede definirse como el conjunto de operaciones específicas que permiten conocer con acierto la manera y la secuencia con la que debe efectuarse un determinado trabajo. Es un hecho que todo tipo de trabajo requiere de una estrategia de pasos lógicos que conduzcan a productos de alta calidad. A pesar de que en el ámbito informático esto es un requisito inevitable, con frecuencia se viola esta regla. Muchas instalaciones no conocen los beneficios de una metodo- logía, otras, no pocas, lo entienden perfectamente bien, es más, cuentan con documentos excelentes en su contenido, pero están guardados y perfectamente resguardados, es decir, nadie los usa. Para todas ellas es conveniente que visiten instalaciones modelo donde existan me- todología~ en operación, porque así podrán comprobar sus múltiples beneficios.

Elaboración de programas en la computadora

Se consume mucho tiempo maquina para la elaboración de los programas en la computadora y con frecuencia tienen que hacerse correcciones posteriores por no haberse probado las condiciones de proceso predefinidas.

Esto tiene que ver sin duda con la falta o deficiencia de procedimientos de norma para que un programa sea elaborado bajo estricto control de calidad y seguridad. Es frecuente que un programador inicie la elaboración de un programa partiendo de una definición verbal del analista o sólo de notas improvisadas derivadas de una plática informal entre ambos.

Por ello, es natural que el programador invierta gran parte de su tiempo haciendo ajustes de última hora, que sumados a cada una de las etapas para la elaboración del programa, arrojan un lapso inconcebible; además, nunca se tiene la certeza de que en el programa fueron consideradas todas las posibles condiciones de proceso a que estará sujeto una vez terminado. Por tanto, no es difícil suponer que cada programa hecho así, al ser sometido a una prueba integral del sistema, arroje resultados tan deficientes que obligan de nuevo a múltiples correcciones, incrementando aún más los tiempos. Finalmente, cuando por fin se dictamina que el sistema es factible de liberarse a producción,

SUGERENCIAS DE SOLUCI~PY 195

resulta un hecho que habrá fallas por inconsistencias, al operar ahora bajo las rigurosas condiciones reales de los datos, las cuales superan con mucho a las condiciones triviales consideradas en la definición de los programas.

Estos vicios son comunes en bastantes instalaciones; por tanto, la única posibilidad real de erradicarlos consiste en establecer etapas reglamentarias de trabajo que permitan ir midiendo la seguridad del trabajo y la correcta utilización de los recursos de cómputo, así como la verdadera productividad de cada programador. Estas etapas deben considerarse en conjunto como una metodología que no sólo permita alcanzar un alto grado de confiabilidad en los resultados de cada programa, así como en la reducción de los tiempos para su elaboración, sino con el objetivo básico de implantar una disciplina en las labores de cada programador. Se verá que por sí sola cada etapa obliga a no pasar a la siguiente si no se ha cumplido rigurosamente con los objetivos establecidos para cada una de ellas.


Un programa, para su elaboración, deberá pasar necesariamente por las siguientes etapas reglamentarias:

1. Elaboración de la deíinición del programa. El analista del sistema al que corresponde el programa tendrá que elaborar una defini- ción escrita y estructurada, de tal manera que el programador asignado para la elaboración de dicho programa cuente en forma completa con la documentación necesaria, la cual le indicará qué es lo que se quiere que haga el programa; cuáles son las entradas; qué se desea como salidas; en qué condiciones se desea procesar los datos; con qué criterios de datos prueba se verificará la correcta función del programa; qué cifras de control se requieren y, en suma, cualquier descripción necesaria para la correcta comprensión por parte del programador.

La documentación estructurada de la definición del programa debe- rá comprender lo siguiente:

a) Hoja de orden de trabajo. Formaliza una solicitud de trabajo del departamento de análisis y diseño hacia el departamento de programa- ción.

b) Hoja del diagrama general de proceso. Esquematiza las entradas y salidas del programa, aludiendo directamente a los nombres de los archivos por procesar. Si el programa maneja varias opciones de proceso, entonces habrá una hoja de este tipo por cada opción por considerar. También se hace mención de las longitudes de registro y Factores de bloque, además del tipo de organización y del método de acceso para cada archivo.

196 CAP 18. ELABORACI~N DE PROGRAMAS

c) Hoja de identificación y objetivos del programa. Esta hoja hará mención de la clave o nombre que se le dará a partir de este momento al programa. La clave o nombre deberá ser único para cada programa dentro del esquema total de los sistemas que se lleguen a operar. La documentación, mensajes del programa y cualquier referencia al mismo deberán manejarse por esta clave o nombre. Además, en la misma hoja se hará una descripción resumida pero clara de los objetivos del proceso que tiene el programa dentro del contexto integral del sistema.

d ) Hoja de descripción de campos de registro de entrada. Esta hoja contiene el desglose detallado de los campos que contiene cada registro y las características individuales de cada uno. Si un archivo contiene diferentes tipos de registro, con un arreglo diferente de campos, habrá un desglose particular para cada tipo de registro. Se hará referencia al archivo correspondiente dentro de cada desglose de cada registro. Aquí se hará mención de las longitudes de registro y factores de bloque correspondientes a cada archivo. Es conveniente que exista una nomenclatura estándar sobre los nombres de campos que componen cada registro, lo cual permitirá el uso de estos mismos desgloses para otros programas que usen alguno o varios de los archivos aquí definidos, abreviando codificación y desgloses varias veces.

e) Hoja de descripción de campos de registro de salida. Esta hoja se debe sujetar a lo establecido en el punto anterior, sólo que en este caso es para archivos de salida.

f ) Formatos de reportes impresos. Aquí se incluyen los formatos de impresión, donde se detallan las posiciones en las que se deberán imprimir encabezados, numeración de hoja, cantidades, etc. Asimismo, si existen diferentes tipos de impresión, habrá un formato por cada tipo que se desee obtener. En caso de que las salidas de impresión sean formas preirnpresas, se deberán anexar, de preferencia, muestras ejemplo llenas, con el fin de que se considere dentro de la programación una rutina de centrado de forma.

g) Hoja de deftnrción de tablas internas. Esta hoja hará mención de la longitud y cantidad de elementos de que consta la tabla, así como el contenido específico de cada uno de ellos. Por supuesto, la hoja sólo será requerida cuando se vayan a manejar este tipo de tablas.

h) Hoja de criterios de datos prueba. El analista que desarrolle la definición del programa es la persona más idónea para establecer los criterios de datos bajo los cuales se asegura que el programa cubrirá las condiciones que se deben tratar cuando éste se encuentre en proceso real. Este aspecto nunca deberá dejarse al arbitrio del programador.

i ) Hoja de cifras de control. Aquí se deberá describir el formato de impresión, así como los conceptos y fórmulas matemáticas bajo las cuales deberán cuadrarse las cifras de control que certificarán, en parte, la correcta función del programa.

j) Hoja de descripción del proceso. Esta hoja es vital para lograr la correcta elaboración del programa. Aquí se deberá especificar qué se quiere que haga el programa y no cómo. Deberá precisarse con claridad esta descripción logrando que se ajuste estrictamente al objetivo de tal programa. El analista deberá asistir al programador en cualquier duda o mala interpretación. De hecho deberá ser un requisito establecer una plática en la cual se precisen los objetivos del programa y se unifiquen conceptos entre ambos.

2. Recepción de la definición en el departamento de pro- gramación. El departamento de análisis deberá enviar por escrito y perfectamente estructurada la definición del programa hacia el departamento de programación, en donde la mesa de control verificará que dicha definición contemple los requisitos establecidos. Si éstos no son cubiertos, se deberá rechazar y regresar al departamento de análisis, puntualizando las razones que se argumentaron para la no aceptación.

Si la definición está completa, la mesa de control la pasará al jefe o supervisor de programación para efectos de asignación de programador.

3. Estudio para la asignación del programa. Con base en las características del programa, en el departamento de programación se determinará el nivel de programador al cual se deberá asignar. Para este caso se deberán considerar los siguientes niveles:

a) Programador A (o supervisor). Debe realizar programas con las siguientes características:

Número de archivos de entrada, uno o más. Combinación de condiciones por considerar, cuatro o más. Número de archivos de salida, uno o más. Manejo de tablas internas de una, dos y tres dimensiones. Reportes con una o más acumulaciones y cortes, una o más. Elaboración de gráficas impresas o por terminal. Cualquier tipo de acceso de archivos. Cualquier tipo de organización de datos. Manejo de opciones de programa, uno o más. Manejo de rutinas externas (de usuario y de sistema operativo). Manejo de rutinas de cálculo. Cruce de archivos con o sin actualización de datos.

b) Programador B. Debe realizar programas con las siguientes ca- racterísticas:

Número de archivos de entrada, uno o más. Combinación de condiciones por considerar, de uno a cuatro.

198 CAR 18. ELABORACIÓN DE PROGRAMAS

Número de archivos de salida, uno o más. Manejo de tablas internas, de una y dos dimensiones. Reportes con una a cuatro acumulaciones y cortes, de uno a cinco. Acceso secuencial y aleatorio por llave, parcial o completa. Organización secuencial e indexada. Manejo de opciones de programa, de una a tres. Manejo de rutinas externas (de usuario). Manejo de rutinas de cálculo con operaciones simples. Cruce de archivos sin actualización de datos.

c) Programador C (o en desarrollo). Deberá realizar programas con las siguientes características:

Número de archivos de entrada, uno o dos. Combinación de condiciones por considerar, una o dos. Número de archivos de salida, uno o dos. Manejo de tablas internas de una dimensión. Reportes sencillos (sin cortes). Acceso secuencial y aleatorio simple. Organización secuencial e indexada.

Si no se quiere tener fechas desfasadas en la terminación de los programas, es necesario que la asignación de programa al nivel de programador idóneo se tome muy en cuenta. Sin embargo, en ocasiones las cargas de trabajo originan que se asigne un programa complejo a un programador cuyo nivel está por debajo del requerido. Si así sucediera, será necesario considerarlo en los calendarios de compromisos; también se requerirá que a tal programador lo asesore y supervise un programador de mayor nivel, porque de lo contrario se corre el riesgo de que el programador novato se empantane y se tenga que rehacer dicho programa.

Por otro lado, si se le asesora correctamente y el programa sale en tiempo por el énfasis que ponga el programador, se podrá considerar que éste se empieza a foguear para pasar a un nivel superior.

4. Asignación de tiempo para la elaboración del programa. Esta fase es una de las más difíciles de establecer debido a la gran variedad de factores que habrá de considerar. Sin embargo, es necesario marcar una fecha de compromiso, donde se tomen en cuenta factores de medición para determinarla con cierto grado de precisión.

Para este caso, es bien sabido que las etapas que mayor tiempo consumen de un programador son las de elaboración de diagramas de bloque, bajo el cual se esquematiza la solución lógica, incluyendo las pruebas de escritorio necesarias y la codificación en el lenguaje de programación.


Por ello, si consideramos los factores por los que se dedica mayor o menor tiempo a estas dos etapas, podremos acercamos con precisión al tiempo que tomará la elaboración de un programa determinado.

El método consiste en descomponer en conceptos de detalle los elementos considerados en la definición del programa, y asignar tiempos apegados a la experiencia cotidiana. A modo de orientación se dan a consideración los siguientes parámetros, los cuales han arrojado fechas que se estiman cercanas a la realidad:

a) Número de archivos de entrada. En realidad, el número de archivos de entrada que intervienen en un programa da por sí mismo una idea de la complejidad inicial de un programa, ya que de alguna manera este número aumenta lo laborioso de la solución lógica que se dé y la codificación del programa. Esto consume tiempo, el cual se ha determinado como sigue:

Número de archivos Horas

1 r nera, la cantidad de

archivos que intervienen como salivda representa un consumo de tiempo, sin embargo, éste tiende a ser menor que en el caso de los archivos de entrada. La razón es que la solución lógica del programa atenderá con más rigor a las entradas que a las salidas, puesto que éstas normalmente son producto del proceso considerado en las entradas. Los tiempos que se han encontrado son los siguientes:

Número de archivos Minutos

CAP. 18. ELABORACIÓN DE PROGRAMAS

c) Número de campos que serán procesados en los registros de entrada y salida. Este aspecto determina uno de los elementos más laboriosos tanto para el aspecto de la solución lógica como para el momento de codificar. Los tiempos analizados son los siguientes:

Campos normales

Campos empacados

Hora Minutos

Horas Minutos

d ) Parámetros que recibe el programa para especificarle acuna íün- ción. Cuando un programa está sujeto a recibir parámetros, de- berá considerarse que habrá que validarlos y, en su caso, enviar mensajes de error. Los tiempos encontrados son los siguientes:

Número de campos Horas Minutos


e) Definición de tablas internas. Es evidente que la definición de tablas internas en programas requiere tiempo, ya que se deberá tener mucho cuidado para llenarlas de datos, cuyo contenido deberá ser bien verificado. Los tiempos encontrados son como sigue:

kn donde:

E = Número de elementos que componen la tabla. L = Longitud en caracteres de elementos.

M = Tiempo requerido en minutos.

f ) Cantidad de operaciones aritméticas. Aquí se tomarán en cuenta las operaciones aritméticas que estén consideradas en el programa, incluyendo contadores de cualquier tipo. Para esto será necesario desglosar cualquier fórmula matemática en operaciones de detalle. Se consideran los siguientes tiempos:

Dperaciones Horas Minutos

g) Manejo de rutinas de centrado de formas preimpresas. En irnpre- sión de formas preimpresas será conveniente elaborar rutinas que permitan hacer un centrado correcto de impresión para evitar reinicios y desperdicio de formas mal impresas. Los tiem-

- p- son: m

" Número Horas l . ,I

1 o c ' Iutos 2 o 2 o 4 0 3 1 O0 4 1 2 o

h) Manejo de rutinas de cortes. Si durante la impresión de reportes se tienen que efectuar cortes, esto también le tomará tiempo al programador. Los tiempos encontrados son:

Número Horas Minutos

i ) Depuración de contenido de campos. Cuando haya que verificar el contenido de campos, según con ciertos criterios, los tiempos son:

(5 minutos) x C = T

En donde:

C = Número de campos por depurar. T = Tiempo en minutos para la depuración.

j ) Rutinas para el manejo de tablas. Al respecto, además de tener que definir las tablas internas, el programador se verá obligado a desarrollar rutinas para el acceso a dichas tablas; por tanto, los tiempos establecidos para cada tabla considerada serán:


k) Número de condiciones por considerar. Esto se refiere básica- mente a la diversidad de tipos de registro que pueden venir en los archivos de entrada, por ejemplo: considerar que en un mismo archivo vendrán registros tipo 1, 2, 3 y 4 o 1, 3 y 4 o 3 y 4, etc. Es decir, todas las combinaciones posibles. Los tiempos por asignar son:


1) Constante de nivel de programador. Esta constante se aplica con el fin de asignar un tiempo en el cual el programador analizará las distintas posibilidades bajo las cuales elaborará la solución lógica más apropiada para realizar un diagrama de bloque que produzca a su vez un programa ágil y de calidad.

Nivel Horas

Esta constante podrá ser establecida con más precisión en cada instalación, de acuerdo con las características de los programas más comunes en dicha instalación. Asimismo, es posible que los tiempos señalados en los puntos mencionados anteriormente puedan variar de acuerdo con el criterio particular de cada instalación.

m) Prueba de escritorio sobre el diagrama de bloque. Para este fin, el tiempo por asignar irá en función del tiempo total resultante de sumar los tiempos de los incisos a al 1, en cuyo caso se aumenta- rán 10 minutos por cada hora resultante de la suma de los tiempos de los incisos a al l. Este aumento de 10 minutos por cada hora sumada nos dará el tiempo requerido para la prueba de escritorio sobre el diagrama de bloque.

n) Codificación del programa. Se considera que para codificar el programa, el tiempo requerido ya fue incluido en los tiempos resultantes de los incisos a al J.

o) Prueba de escritorio sobre la codificación. El procedimiento para obtener este tiempo es idéntico al inciso m, es decir, se aumen- tarán 10 minutos por cada hora resultante en los incisos a al l.

p) Captación del programa ya codificado. Este tiempo será establecido por cada instalación, ya que depende básicamente de sus propios procedimientos establecidos para la captación de la codificación.

q) Compilación y catalogación del programa. Al igual que el punto anterior, este tiempo será establecido en cada instalación.

r ) Prueba y depuración del programa. Este tiempo también está sujeto a cada instalación por la razón establecida en el inciso p.

S) Vaíidación de resultados de las pruebas. Para obtener este tiempo será necesario ape arse al criterio establecido en el inciso m.

t) Documentación de 7 programa. Para realizar las carpetas de pro- gramación y operación no se establece tiempo, ya que los lapsos de espera de los puntos de captación, compilación, catalogación y prueba del programa son suficientes para elaborar tales carpetas.

Al aplicar la técnica anterior para la asignación de tiempos se tiene la certeza de que se obtendrá una idea más apegada a la realidad, que si sólo se asignara en forma em írica con apreciaciones intuitivas.

En algunas instalaciones se A an elaborado programas que al ser alimen- tados con los datos de detalle ya mencionados, automáticamente se obtiene el total de tiempo requerido para la elaboración de cualquier programa.

5. Estudio para la elaboración del programa. Una vez seleccionado el programador cuyo nivel es el más apropiado para la ela- boración del programa, así como la determinación del tiempo requerido para su desarrollo, dicho programador tendrá que realizar un estudio profundo sobre los criterios de la deFinición, hasta lograr una compren- sión total. Requerirá auxiliarse por el analista que definió el programa para aclarar cualquier duda, por trivial que ésta sea. Esta fase es el fundamento principal para el desarrollo del programa, porque si se capta la idea clara de lo que se desea que haga el programa hasta en sus más mínimos detalles, por lo general, no existen problemas en la obtención de los resultados, y tal vez hasta se logre una solución óptima. Sin embargo, cuando se tienen dudas por parte del programador y éstas no son aclaradas con tiempo, invariablemente llegará a resultados erróneos, lo cual trae como consecuencia un uso indebido de la computadora, así como el despilfarro de horas hombre; además, lo más importante, tendrán que alterar los planes para la integración de los programas que intervienen en el sistema y quizá no pueda realizarse una prueba completa de dicho sistema en los tiempos ya establecidos.

6. Elaboración del diagrama de bloque. Si el programador ha captado completamente el planteamiento de la definición del programa y ya no existen dudas, puede estar seguro que está preparado para desarrollar el diagrama de bloque que dé como resultado la solución lógica a tal planteamiento. De lo contrario, no debe pasar a esta fase, ya que asumirá una gran cantidad de criterios no entendidos y obviamente no dará una correcta solución.

Debe establecerse que todo programa, por sencillo que parezca, debe- rá primero ser resuelto mediante un diagrama de bloque, con lo cual se

asegure que en la solución lógica están incluidos todos los criterios que le darán los resultados esperados.

Este diagrama deberá contener todos los detalles necesarios para diagnosticar que no existen cabos sueltos, pues no debe darse por hecho nada porque es frecuente encontrar diagramas de bloque con una apreciación muy general del problema por resolver.

7. Prueba de escritorio sobre el diagrama. Una vez que se tiene el diagrama de bloque, éste debe ser sometido a una prueba de escritorio, la cual deberá ser lo más exhaustiva posible. Por supuesto, esta prueba debe realizarse de acuerdo con los criterios de datos prueba que previó el analista, y de cuyo resultado se obtendrán rigurosamente los resultados ya predefinidos. No se podrá pasar a la siguiente fase si no se ha cumplido con lo anterior.

8. Codificación del programa. Esta etapa es la que requiere más atención, porque absorbe el cuidado del programador, ya que al transcribir el diagrama en hojas de codificación, se tendrá que cumplir con las variadas reglas de sintaxis requeridas por el lenguaje que se utilice, así como con las normas establecidas por la propia instalación.

La transcripción se debe hacer con mucho cuidado para que la codificación contemple todo el planteamiento plasmado en el diagrama, ya que debe entenderse que lo que se está haciendo es la transcrip- ción de una solución encontrada, y no deberá omitirse ninguna conside- ración hecha en el diagrama; o a la inversa, codificar rutinas que no están en el diagrama. Si esto ocurriera, se corre el riesgo de transcribir una solución incompleta.

9. Prueba de escritorio sobre la codificación. Es frecuente que al transcribir el diagrama en instrucciones, en forma involuntaria se omitan algunas consideraciones y se afecten los resultados finales. También, es común cometer errores de sintaxis que por lo general se encontrarán cuando el programa sea compilado, perdiéndose tiempo inútilmente. Es por eso que de nuevo se requiere una prueba de escritorio, pero ahora sobre la codificación, lo cual aumenta la garantía de obtener resultados correctos en la computadora; pues aun mediante esta segunda prueba es factible encontrar errores de lógica por algún descuido.

10. Captación de la codificación. Cuando esté completamente seguro de que tanto en el diagrama de bloque como en la codificación hay un alto grado de certeza para la obtención de resultados, es posible tomar las hojas de codificación para la captación a medios procesables por la computadora. Cada hoja codificada deberá apegarse cuando menos al siguiente esquema:

Nombre o clave del programa. Nombre del programador.

Fecha y hora. Número de hoja (1 de 10, 2 de 10, etc.). Número de líneas codificadas por hoja. Número consecutivo de líneas (de 10 en 10 por posibles intercalaciones).

11. Verificación de la captación. Es probable que durante la captación se hayan cometido errores de dedo involuntarios, por lo que si dicha captación se envía directamente a compilar habrá errores de sintaxis, lo cual representa un desperdicio de tiempo máquina. Para evitar esto es necesario verificar lo captado línea por línea contra las hojas de codificación. Aunque es difícil, es posible que aún se encuentren errores de sintaxis u omisión de instrucciones que el propio programador haya cometido.

12. Compilación y catalogación. Esta fase es la traducción del lenguaje fuente al lenguaje máquina; pero si existen errores de sintaxis, no se realizará la traducción y habra tantas compilaciones como sea necesario para lograr la depuración total. Esto obliga a que la computadora sea utilizada con frecuencia como depuradora de errores, lo cual no es correcto bajo ningún pretexto. Por ello, si se ha seguido estrictamente la aplicación de las fases anteriores, se deberá entender que en un número no mayor a tres entradas a la máquina, el programa estará depurado por completo y listo para catalogarse.

13. Transcripción de datos prueba. Una vez que se cuenta con los datos prueba codificados, los cuales han sido utilizados en las pruebas de escritorio, será necesario transcribirlos al medio en el cual serán probados en la computadora. Es conveniente sacar listados de tales datos antes de iniciar las pruebas, y corroborar que éstos hayan sido captados en forma correcta; de no ser así, las pruebas arrojarán resultados incorrectos y tal vez hasta el programa falle por datos erróneos.

14. Prueba de depuración del programa en la computadora. Esta fase es la que determina si hubo éxito o no en la elaboración del programa, porque los resultados de todas las fases anteriores se pueden apreciar hasta este momento, y deberán ser estrictamente los que se predefinieron, en función de los criterios de datos prueba.

Cuando se prueben varias opciones del mismo programa, es conveniente armar un solo paquete que las incluya; de esta manera se obtienen rápidamente resultados con menos entradas a la máquina, lo que abrevia el tiempo requerido para esta fase. En este caso se considera normal hasta tres entradas a la computadora para hnes de una depura- ción total.

15. Validación de resultados. Una vez hechas las pruebas del programa, es indispensable validar los resultados hasta en sus más mínimos detalles, para poder afirmar que es un programa confiable;

porque si bien en muchas ocasiones se cree que un programa trabajó correctamente con sólo verificar las cifras de control, se incurre en un grave error, ya que la verdadera verificación que garantiza resultados correctos se encuentra en la revisión detallada de los registros de salida, al comprobar que cada campo contiene información veraz; más aún, se deberá verificar el contenido de los campos que estuvieron sujetos a alguna operación y fueron actualizados. Asimismo, habrá que revisar acumulaciones, cortes, fechas, etc. Esta fase deberá ser estrictamente minuciosa, ya que de no ser así, puede originar que programas subsecuentes fallen en su proceso, a causa de malas salidas del anterior.

16. Documentación del programa. La documentación completa y adecuada de un sistema programado que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier centro de cómputo; sin embargo, este requisito se descuida con frecuencia. La documentación es la herramienta que hace posible la operabilidad de los sistemas, aun sin la presencia de las personas que efectuaron los detalles. Es pues un fundamento histórico indispensable para lograr la continuidad de los procesos, aunque exista rotación de personal.

Para documentar un programa elaborado basta con dos carpetas, cuyo contenido se debe apegar cuando menos a lo siguiente:

a) Carpeta de programación. Esta carpeta debe existir por cada programa que interviene en el sistema, y su contenido debe aparecer en el siguiente orden:

fndice. Definición del proceso (descripción). Diagrama general de proceso (uno por cada opción). Diseños de formatos de registros de entrada y salida. Diseños de impresión de reportes. Explicaciones especiales. Lista de cláusulas de control para inicio y reinicio. Lista del programa obtenido en la última compilación. Resultados de la última prueba del programa (listas de los archivos de entrada y salida obtenidos). Cifras de control de la última prueba.

b) Carpeta de operación. Ésta debe ser un instructivo para la corrida del programa, cuyo contenido debe ser:

Índice. Descripción del proceso. Diagrama general de proceso (uno por cada opción). Explicaciones especiales para operación.

208 CAP l a . ELABORACI~N DE PROGRAMAS

Mensajes y acciones de operación. Descripción de formatos de parámetros. Lista de cláusulas de control para inicio y reinicio. Formatos de registros de entrada y salida. Formatos de impresión. Muestrario de cifras de control y fórmulas de verificación.

17. Entrega de la documentación, programa y cláusulas de control para Mcio y reinicio. Una vez cubiertas todas las fases para la elaboración de cualquier programa, y los resultados de la última prueba hayan sido aprobados por el analista que lo definió, la carpeta de programación será entregada al analista correspondiente para que pase a formar parte de la documentación completa del sistema. La carpeta de operación, el programa fuente y las cláusulas de control para inicio y reinicio serán entregados al centro de cómputo.

Esta metodología ha sido adoptada por varias instalaciones y los resultados efectivos no se han hecho esperar, ya que se va guiando al programador de manera que la mayor parte de su tiempo lo emplee en elaborar su plan de trabajo en el escritorio y de manera sistemática y ordenada, desarrollando actividades que garantizan casi siempre la obtención rápida de resultados correctos y confiables. En otras palabras, se obtiene del programador una mayor productividad y se elimina al máximo el uso excesivo de la computadora.

RESUMEN

Es frecuente que un programador inicie la elaboración de un programa partiendo sólo de una de£inición verbal de1 analista. Debido a esto, es natural que el programador invierta gran parte de su tiempo, además de1 desperdicio de tiempo máquina, haciendo ajustes de últirna hora. El problema principal es que nunca se tiene la seguridad de que será un programa confiable en producción. Estos vicios son comunes en muchas instalaciones; por tanto, la única posibilidad real de erradicarlos consiste en establecer etapas reglamentarias que permitan ir midiendo la seguridad del trabajo, así como la correcta utilización de la computadora. Se observará que por sí sola cada etapa obliga a no pasar a la siguiente si no se ha cumplido con el objetivo establecido para cada una.

Control de cambios 3

a+ "lema L; En la mayoría de los centros de

cbmputo, cuando falla algún programa o se requiere un cambio necesario, se hacen reparaciones improvisadas y sin control.

En todo sistema de información existe la posibilidad de realizar cambios, ya sea que éstos se originen por solicitud del usuario para obtener un nuevo resultado requerido por alguna necesidad de informa- ción, detectada hasta ese momento; por un cambio obligado por cuestiones legales; o simplemente para modificar o complementar el diseño de algún reporte de salida. Es decir, los sistemas por naturaleza deben ser dinámicos y congruentes con la necesidad de proyección de las instituciones.

Asimismo, un cambio podría ser originado por programas deficientes que no fueron probados exhaustivamente y, puestos en producción, se llega a presentar alguna condición no prevista en el programa, originando una falla.

Sin importar la manera como se ha originado un cambio, será necesario que éste se sujete a un procedimiento estricto y no a reparaciones improvisadas y sin control, que lejos de ayudar, distorsionan la filosofía original del sistema, causando cada vez peores estragos en la producción; y lo que es peor, se empieza a tener una dependencia casi absoluta de las personas que hacen reparaciones de este tipo.

21 0 CAP 19. CONTROL DE CAMBIOS

Actualmente esto se ha convertido en un vicio tan dañino que, pese al peligro que ocasiona, lo queremos ver como un mal necesario. Nos hemos acostumbrado a disfrazarlo como un problema obligado, sin entender que es una de las principales razones de los fracasos de un centro de cómputo.

El pretexto frecuente es: "corríjase el problema y después veremos qué hacer", aunque todos sabemos que una vez resuelto el problema, ya nada se hará.

1. Es necesario establecer que existen dos tipos de cambios: temporales y permanentes.

2. Los cambios temporales se identifican porque sólo afectan a la corrida circunstancial de un proceso; es decir, que después de haber cumplido con el proceso, dicho cambio desaparece, como si nunca hubiera existido. Por eso no es necesario establecer un control tan estricto; sin embargo, tales cambios deben sujetarse a lo siguiente:

a) Si el cambio afecta únicamente a cláusulas de control o a parámetros, aun así dicho cambio nunca se deberá hacer directamente en los archivos oficiales de producción, sino que tales elementos deberán ser copiados en archivos alternos y ahí es donde se hará el cambio y la corrida del proceso, después de lo cual estos archivos deberán borrarse para no caer en confusiones futuras.

b) Si el cambio es hacia programas, del mismo modo deberá efectuarse el cambio en bibliotecas alternas, y de ahí se tomarán para efectuar la corrida; después de realizada ésta, los programas correspondientes tendrán que ser respaldados con fecha de caducidad y borrados de las bibliotecas alternas.

3. Los cambios permanentes se identifican porque permanecerán para un futuro o durante un lapso considerable. Por esto, tales cambios tendrán que sujetarse a un procedimiento estricto. Los pasos por seguir serán los siguientes:

Antes de hacer el cambio en forma permanente, éste debera realizarse en primer orden como si fuera un cambio temporal; es decir, llevarlo a cabo en archivos y bibliotecas alternos a los oficiales de producción.

b) Realizar el cambio según la definición, debiendo estar ésta por escrito.

c) Una vez hecho el cambio en archivos y bibliotecas alternos, se procede a efectuar las pruebas necesarias y se obtienen los resultados con el cambio reflejado.

d ) Teniendo todos los elementos para comprobar que dicho cambio se ha realizado satisfactoriamente, se procede a pasar a la fase de autorización, en donde la persona facultada para autorizar deberá ser el analista que definió dicho cambio y también el usuario. A él se le entregarán todos los elementos de la última prueba para que se per- cate de que el cambio ha sido cubierto en todos sus detalles. Es necesario amparar este control con una forma similar a la que se anexa más adelante.

e) Una vez autorizado el cambio, se procede a la afectación de los archivos y bibliotecas oficiales de producción, con el fin de reflejar el cambio en forma permanente.

E) Hecho lo anterior, se efectuará una última prueba en este medio, presentando las carpetas de documentación actualizadas con el cambio, se volverá a pasar con el analista que autorizó éste para confirmar que el mismo es permanente y seguro para procesos reales.

g) Valiéndose de la forma de control, el ciclo de cambio quedará cerrado al estampar la segunda firma de aceptación y autoriza- ción. Esta forma será la evidencia oficial de que el cambio se efectuó bajo riguroso control.

Las características de la forma son las siguientes:

CONTROL DE CAMBIOS

Se efectúa cambio a:

Programa fuente O

Parámetros 0

El cambio será:

Temporal:

Cláusulas de control 0

Otros (especificar):

Permanente

Nombre del sistema o aplicación:

Nombre de elemento(s) por afectar:

Descripción del cambio:

Nombre de quien efectuó el cambio:

Hora: Fecha:

Nombre de quien autorizó el cambio:

Hora: Fecha:

Firma de autorización:

Carpeta en donde quedó documentado el cambio:

Hora: Fecha:

Firma de autorización definitiva:

Comentarios

RESUMEN

En todo sistema de información existe la posibilidad de realizar cambios, ya sea que éstos se originen por el usuario al requerir un nuevo resultado, motivados por efectos legales o por otras razones; es decir, los sistemas por naturaleza no pueden ser estáticos. Sin importar la manera como se origine un cambio será necesario que éstos se sujeten a un procesamiento estricto. Jamás deben permitirse reparaciones improvisadas, ya que éstas modifican la filosofía original del sistema y normalmente no queda registro. El pretexto hecuente es: "Corríjase el problema y después veremos qué hacer." Sabemos que una vez resuelto el problema, nada se hará. Deben identificarse dos tipos de cambios: temporales y permanentes. Cualquiera que sea éste, deberá controlarse estrictamente.

Administración de archivos 2

Problema

Gran parte de los centros de cómputo tienen problemas con el control de los archivos de datos que se resguardan.

Existen vanos factores por los que una instalación pierde el control en cuanto a cantidad, contenido, tipo e importancia de los archivos de datos que mantiene en resguardo. Esto se antoja inconcebible en un centro de cómputo, cuya función es precisamente dar seguridad a la integridad de los datos. Así, los desajustes más severos que enfrentan tales instalaciones son:

1. Procesos erróneos al encontrar que se manejaron archivos equi- vocados.

2. Pérdidas elevadas en tiempo máquina y de operación. 3. Resultados incorrectos encontrados hasta que el usuario los

detecta. 4. Pérdidas cuantiosas en impresión con datos erróneos tanto en

formas preirnpresas como papel stock. 5. Saturación de paquetes de discos y cintas con archivos obsoletos. 6. Consulta errónea y actualización de archivos maestros afecta-

dos con archivos inválidos. 7. Severas dificultades al tratar de restaurar archivos maestros mal

actualizados.

8. Extravíos frecuentes de datos valiosos e históricos. 9. Destrucción de archivos útiles.

10. Necesidad de trabajos urgentes a deshoras y fines de semana con objeto de reestructurar archivos mal actualizados o perdidos.

11. Demoras frecuentes en la entrega de resultados. 12. Confusión para identificar a qué áreas o sistemas corresponden

los archivos resguardados. 13. Sistemas descontinuados al perder archivos medulares de difícil

recuperación. 14. Alto grado de posibilidad de alteraciones fraudulentas en los

archivos. 15. Poca confidencialidad en los archivos de datos.

Estos puntos no abarcan las consecuencias que originan el descontrol ya mencionado, pues es imposible saber a ciencia cierta cuántos problemas se presentan a diario en instalaciones con tal situación. Es increíble que esto suceda en no pocas instalaciones del país. Da la impresión de que ahí no trabajan profesionales del ramo.

Este problema atañe directamente a los jefes que permiten que el centro de cómputo se les desintegre en las manos. Son jefes que no saben poner orden debido al desconocimiento, no de lo que deberían hacer sino del riesgo tan alto que esto ocasiona.

No se pretende que sean especialistas de todas las actividades necesarias de la instalación, sino que tengan la suficiente experiencia para detectar anomalías y establecer correctivos oportunos; que sepan dónde están ubicados, cuáles son sus responsabilidades y funciones y valoren los riesgos de los malos controles detectados y no se atemoricen ante las adversidades. Deben entender que los técnicos están a expensas de lo que ellos vislumbren y determinen para un correcto desempeño en la administración y resguardo de los datos.

1. El primer factor que debe establecerse para abordar el problema de la falta de control de los archivos de datos, es clasificar el tipo de datos con los que opera la instalación y establecer un esquema por orden de importancia. Esto podría ser como sigue:

Archivos de producción. Archivos para prueba de sistemas integrales. Archivos del sistema operativo en operación. Archivos del sistema operativo en prueba. Archivos para desarrollo de nuevos sistemas.

2. Una vez clarificado el tipo de archivos y su importancia, se establecerá una identificación muy precisa para determinar los niveles de respaldo para aquellos archivos vitales, históricos o de difícil recupe- ración.

Téngase en cuenta lo siguiente:

Resguardo local. Resguardo fuera de sitio.

Los archivos con resguardo local son los que por la naturaleza de los procesos de la instalación deben estar disponibles en el momento oportuno para la producción diaria. Debe tenerse el .cuidado de que estos archivos siempre tengan respaldos, ya sea ubicados localmente o fuera de sitio, sobre todo los que son actualizados con Frecuencia. No hay que olvidar obtener respaldo también de los archivos de movimiento con los cuales fueron afectados los primeros.

Los archivos con resguardo fuera de sitio serán aquellos que por su importancia en la historia de la instalación sean vitales en caso de pérdidas o daños de los archivos locales para restablecer cualquier accidente y que puedan reponerse rápidamente. Estos archivos deberán estar en una bóveda contra accidentes, fuera y distante del centro de cómputo donde se mantengan los respaldos necesarios como protec- ción contra cualquier desastre. En esta bóveda deberán resguardarse básicamente: archivos maestros, históricos y aquellos de difícil recupe- ración.

Este aspecto deberá ser respetado por todo centro de cómputo, no importa si es grande o pequeño, pues ninguna instalación está exenta de actos de terrorismo, accidentes o robos. Son posibilidades latentes que tienen que ser cubiertas. Véase como seguro de vida, donde no se sabe cuándo puede ocurrir un accidente, ni cómo, pero llegará; es entonces cuando habrá que estar preparado. Además, el costo de prevenir los daños a los archivos es raquítico si lo comparamos con los beneficios que esto significa.

El manejo de fechas de caducidad también es importante; esto ayudará a resguardar y mantener sólo archivos útiles y activos, para eliminar así confusiones peligrosas que indujeran a dar de baja archivos necesarios o saturar los medios de almacenamiento con archivos obsoletos.

Con un esquema de fechas de caducidad, los procesos automáticos o manuales para depurar son muy seguros y rápidos.

La identificación individual de cada archivo es el punto débil si no se planea en forma eficiente; es decir, la consistencia, seguridad y asigna- ción de una nomenclatura moderada pero segura, por sí sola, debe contestar las siguientes preguntas:

jQué archivo est jA quién corresponde< ?Qué tipo de archivo est jEn dónde se encuentra dicho archivo<

Como una orientación, a continuación se dan modelos de nomenclatura que permiten operar con un alto grado de seguridad en cualquier centro de cómputo. Sígala, imítela, adáptela, analícela, implántela o compleméntela; pero haga algo para corregir el problema mencionado.

Descripción:

Dentro del esquema de seguridad para protección de los datos contenidos en los archivos concentrados en un centro de cómputo, se ha determinado el concepto de grupos de acceso por unidad usuaria.

Una unidad usuaria se define como el área dentro de la organización que cubre una función completa y casi autónoma. En algunas empresas a esto se le llama unidad de negocio.

Lo anterior quiere decir que los archivos que pertenecen a una determinada unidad usuaria no podrán ser accesados por otra, es decir, los procesos de consulta y afectación de esos datos serán por efecto de los sistemas de cada unidad.

Para este caso, los grupos de acceso abarcarán los siguientes tipos de archivos:

Bibliotecas (archivos de programas). Archivos secuenciales. Archivos secuenciales-indexados. Archivos directos. Archivos VSAM 'ESDS'. Archivos VSAM 'KSDS'. Rutas (paths) alternas VSAM 'KSDS'. Bases de datos. Archivos del sistema operativo (SYS1, SYS2).

Los grupos de acceso significarán a su vez el primer calificador de los nombres de archivo como sigue:

I - - - - iuomores de grupos de acceso. - - - - 7

I

L ---, ,---- L 1 - 1 C - - - - - - 1

I RRRRennn 1 *rchivos - - - - - - - - - - - - - - - - - - - :--------- 1 - - - - - - - J I - - - - - - - - - Bibliotecas J '

I 1

~ o A b r e s de archivos N h b r e s de bibliotecas I

t I I l v v

gggggggg - >ooooooo< - xxxxmxx gggggggg - >ooooooo< - xxxxmxx (1 er. Calif.) (1 er. Calif.)

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA BIBLIOTECAS

Para bibliotecas de uso general dentro de una unidad usuaria.

l 1 I I uu 1 'U' 'B' ; 'GRAL' / 1

I I I I I I I I I I I I I I '- - -,'GRAL' = Constante (uso general) I I I - - +'E = Constante (biblioteca) I I - - +'U' = Constante (unidad) - - ., uu = Clave de unidad usuaria

usuaria. 7

1 I I I - - , 'B' = Constante (biblioteca) I l- - -, a = Clave de área dentro de la unidad usuaria I - - + uu = Clave de unidad

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA ARCHWOS SECUENCIALES

Para archivos secuenciales de uso general dentro de una unidad usuaria.

l I I

i uu ; 'U' ; 'S 1 'GRAL' i 1 1

I I I I l I I 1 I I I 1- - - ,'GRAL' = Constante (uso general) I I I I I 1 - - +'S' = Constante (archivo no VSAM-secuencial) I I 1 - - +'U' = Constante (unidad) ! - - ., uu = Clave de unidad usuaria

Para archivos secuenciales de uso exclusivo de un área dentro de la unidad usuaria.

I l I I I I I I I I L - - , 'S' = Constante (archivo no VSAM-secuencial) I 1- - -, a = Clave de área dentro de la unidad ; - - + uu = Clave de unidad

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA ARCHNOS SECUENCIALES-INDEXADOS

Para archivos secuenciales-indexados de uso general dentro de una unidad usuaria.

I 1 I

! uu ; 'U' ; '1' 'GRAL' i 1

I I l l I I 1 I I I l- - -,'GRAL' = Constante (uso general) I I 1 - - $1' = Constante (archivo secuencial-indexado) I I : - - +'U' = Constante (unidad) L - - ., uu = Clave de unidad usuaria

Para archivos secuenciales-indexados de uso exclusivo de un área dentro de la unidad usuaria.

- - t '1' = Constante (archivo secuencial-indexado) g ~ & ' ~ 9 i- - -, a = C k e de firea dentro de la unidad usuaria I - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA ARCHIVOS DIRECTOS

Para archivos directos de uso general dentro de una unidad usuaria.

1 1 1

uu 'U' ; 'D' ; 'GRAL' 1

1- - - - -' - - - - - -'- - - - - 1- - - - - - - _i

1 1 1 1 1 1 1 1 1 1 1 1 1 1

l- - - ,'GRAL' = Constante (uso general) I I 1 - - -, 'D' = Constante (archivo directo) 1 I 1 - -+'U' = Constante (unidad) : - - ., uu = Clave de unidad usuaria

Para archivos directos de uso exclusivo de un área dentro de la unidad usuaria.

1 1 1 1 1 1 1 1 1 I I b 'D' = Constante (archivo directo) - - - I 1- - -, a = Clave de área dentro de la unidad usuaria ; - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA ARCHIVOS TIPO V S M 'ESDS'

Para archivos VSAM 'ESDS' de uso general dentro de una unidad usuaria.

1 1 1

I uu 1 'U' 1 'E' ; 'GRAL' I

1- - - - -'- - - - - -'- - - - - -'- - - - - - - 1 1 1 1 I 1 1 1 1 1 1 1 I I I l- - -,'GRAL' = Constante (uso general) I I 1 - - + 'E' = Constante (archivo VSAM-secuencial)

: - - +'U' = Constante (unidad) : - - + uu = Clave de unidad usuaria

Para archivos VSAM 'ESDS' de uso excIusivo de un área dentro de la unidad usuaria.

1 1 1 1 1 1 1 l I 1 - - - 'E' = Constante (archivo VSAM 'ESDS') I l- - -, a = Clave de área dentro de la unidad usuaria 1 - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACIÓN DE GRUPOS DE ACCESO PARA ARCHIVOS TIPO VSAM 'KSDS7

Para archivos VSAM 'IZSDS' de uso general dentro de una unidad usuaria.

1 1 1

1 uu 1 'U' ; 'K' 1 'GRAL' 1

1 1 I 1 1 1 1 1 1 1

l- _ -,'GRAL' = Constante (uso general) I I 1 - - -, 'K' = Constante ( archivo VSAM 'KSDS') 1 I : - - +'U' = Constante (unidad) : - - + uu = Clave de unidad usuaria

Para archivos VSAM 'KSDS' de uso exclusivo de un área dentro de la unidad usuaria.

1 - - 1 1 1 ,-----,-----,--- 1 I 1 1 1 1 1 1 1 I - - - 'K' = Constante (archivo VSAM 'KSDS') I l- - -, a = Clave de área dentro de la unidad usuaria 1 - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACIÓN DE GRUPOS DE ACCESO PARA ARCHNOS ALTERNOS 'KSDS'

Para rutas (paths) alternas VSAM 'KSDS' de uso general dentro de una unidad usuaria.

1 I I

1 uu ; 'U' ; 'P ; 'GRAL' 1 I I

1 I I I I I I 1- - -,'GRAL' = Constante (uso general) I I 1 I 1 - - + 'P = Constante (ruta alterna VSAM 'KSDS') I I - - +'U' = Constante (unidad) L - - ., uu = Clave de unidad usuaria

Para rutas alternas VSAM 'KSDS' de uso exclusivo de un área dentro de la unidad usuaria.

I 1 I

I u u ; a ; ' ~ ' : I 1 - - 1 1 I

I I I I 1 1 1 I I 1- - -. a = Clave de área dentro de la unidad usuaria 1 - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA BASES DE DATOS

Para bases de datos de uso general dentro de una unidad usuaria.

I I 1 ! uu ; 'U' ; 'X' 1 'GRAL' I I I

1 l I I I I I I

I I I 1- - - ,'GRAL' = Constante (uso general) I 1 I I I 1 - - + 'X' = Constante (bases de datos) I I - - +'U' = Constante (unidad) - - ., uu = Clave de unidad usuaria

Para bases de datos de uso exclusivo de un área dentro de la unidad usuaria.

- - - - - - I r - ---- I ------1

I 1 I

I u u ; a ; ' ~ ' ; 1 - - I I I ,-----,-----,---

I I I I I I I I I I I b 'X' = Constante (base de datos) - - - I 1- - -, a = Clave de área dentro de la unidad usuaria 1 - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA BASES

DE DATOS CON INFORMACIÓN DE NIVEL DE DIRECCI~N

I r-----1------1 1 1 1

I uu ; 'D' ' 'X' 1 - - - - - 1-- I 1

1-----7--- l I 1 1 I 1 1 1 1 I I b 'X' = Constante (base de datos) - - - l 1- - - b 'D' = Constante (dirección) ! - - + uu = Clave de unidad usuaria

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE GRUPOS DE ACCESO PARA ARCHWOS DE USO UNIVERSAL

Para bibliotecas de uso universal.

1 1 1 1 'UU' ; 'B' 1 1 1

1 1 I 1- - - - - - - - - - - - - - - - - - - -, 'B' = Constante (biblioteca) I I - _ - - - - - - - - - - - - - - _ ,'UU' = Constante (uso universal)

Para archivos secuenciales de uso universal.

1 1 I 1- - - - - - - - - - - - - - - - - - - -, 'S' = Constante (archivo secuencial) 1 I - - - - - - _ _ - - _ - _ - - - - , 'UU' = Constante (uso universal)

Para archivos indexados de uso universal.

1 : 'UU' ; '1' i l 1

l - - - - - - - J - - - - - - i I I

'l' = Constante (archivo I l - - - - - _ _ _ - - - - - - - - - - _ _ , secuencia1 indexado)

;- - - - - - - - - - - - - - - - -,'UU1 = Constante (uso universal)

Para archivos directos de uso universal.

1 1 I 'UU' 'D' 1 1 1

1 1 I 1- - - - - - - - - - - - - - - - - - - -, 'D' = Constante (archivo directo) 1

1 - - - - - - - - - , - - - - - - -, 'UU' = Constante (uso universal)

Para archivos VSAM 'ESDS' de uso universal.

1 1 I 'UU' 'E' 1 1 1

l - - - - - - - J - - - - - - ' I I 'E' = Constante (archivo I I - - - _ - - - - - - - - - - _ - _ _ - - VSAM 'ESDS') I - - - - - - - - - - - - - _ - - - ,'UU' = Constante (uso universal)

Para archivos VSAM 'IZSDS' de uso universal.

I 1 1 1 'UU' ; 'K' 1 1 1

l - - - - - - - n - - - - - - J I I 'K' = Constante (archivo I I _ _ _ _ _ - - _ - - - - - - - - _ - - - VSAM 'KSDS') I

1- - - - - - - - - - - - - - - - -,'UU' = Constante (uso universal)

Para bases de datos de uso universal

- - - - - - - - - - - - - - - 1 I 1 1 I 1

1 'UU' ; 'X' 1 1 1

l - - - - - - - n - - - - - - ' 1 1 I 1- - - - - - - - - - - - - - - - - - - -, 'X' = Constante (bases de datos) 1 1- - - - - - - - - - - - - - - - -,'UU' = Constante (uso universal)

FORMATO DE NOMENCLATURA PARA LA FORMACI~N DE LOS NOMBRES DE ARCHNOS DE DATOS A PARTIR DEL SEGUNDO CALIFICADOR (PRIMER CALIFICADOR:

NOMBRE DE GRUPO DE ACCESO)

Descripción

Normalmente existen dos tipos de archivos y bibliotecas, los comunes y los del sistema operativo.

Todo archivo ubicado dentro del centro de cómputo deberá estar identificado con un nombre único. Esta regla es de carácter obligatorio

224 CAF! 20. ADMINISTRACI~N DE ARCHIVOS

en dicho ambiente, para lograr una identificación rápida que permita, por medio de su nombre (DSNAME), conocer a quién pertenece y cuál es su contenido, y así evitar la duplicidad de nombres: a continuación se describen las reglas de codificación:

Para archivos comunes de sistemas aplicativos en la fase de prueba y en servicio. , - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - m - - - - - -

e . Caif 2do. Calif. ! 3er. Calif. / 4to. Calif. !

I I 1 I I I I I I I ! *OPCIONALw I 1 l I 1 1 I 1 l I I

- - - - , GnnnnVnn = Para ver- I I I I I siones de archivos históricos I I I I I I I I : - - - + ffffffff = Identificación de la función I I 1 l I I I l

básica del archivo I I I 1- - - -, Sss = Identificación del sistema y subsistema I I I I 1 - - - +'SV = Constante (archivo en servicio) I I ! - - - +'PRU = Constante (archivo para pruebas) - - - - +m Nombre de grupo de acceso

En donde:

ffffffff = En formato libre codificar la identificación de la función básica de este archivo (por ejemplo, MOVIM será para determinar que es un archivo de movimientos) para actualizar a un archivo maestro.

Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, teniendo cuidado de asignar la misma para el mismo sistema y subsistema.

gggggggg = Para efectos de poder codificar el nombre de grupo de acceso.

Para archivos comunes de sistemas aplicativos en la fase de prueba en estado de respaldo.

1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

e . C i f 2do. Calif. 3er. Calif. 4to. Calif. i , - - - - - - - - l - - - - - - - - - - - - - l - - - - - - - - - J - - - - - - - - - l ) gggggggg I 'PRU' I 'BK' Sss m GmnnVnn 1

1 1 1 1 1 1 I I I I I I WOPCIONALW 1 1 1 1 1 1 1 1 1 1 1

- - - - , GnnnnVnn = Para ver- I I I I I siones de archivos históricos 1 1 1 1 I I I I : - - - , mmff = Identificación de la función 1 1 1 1 I I I I básica del archivo I I I 1 - - - -, Sss = Identificación del sistema y subsistema 1 1 I I i - - - ,'BK' = Constante (archivo en respaldo) 1 I I - - - ,'PRU' = Constante (archivo para pruebas) - - - - +gggggggg Nombre de grupo de acceso

En donde:

ffffffff = La identificación de la función básica de este archivo (por ejemplo, MOVIM será para determinar que es un archivo de movimientos) para actualizar un archivo maestro.



Para archivos comunes de sistemas aplicativos en la fase de produc- ción y en servicio. , - - - - - - - - _ - - - - - _ _ _ _ - - - - - - - - - - - - - - - - - - - - - - - -

1

l er. Calif. j 2do. Calif. : 3er. Calif. I 4to. Calf. I 1 I l - - - - - - - _ I - - - - - _ _ _ _ _ - - - - - - - - - - - - - - - - - - - - - - -

1 gggggggg I 'OFC' 'SV' I Sss mmfF I Gt~nnnvnn i I I I 1 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 1 1 1 1 1 1 1 1 1 I I I I 1 I MOPCIONALW 1 1 1 1 1 1 1 1 1 1 1

- - - - , GnnnnVnn = Para ver- I I I I I siones de archivos históricos 1 1 1 1 I I I I : - - - , mmff = Identificación de la función I I I I básica del archivo I I I 1- - - -, Sss = Identificación del sistema y subsistema 1 I I I i - - - ,'SV' = Constante (archivo en servicio) 1 I 1 - - - , 'OFC' = Constante (archivo oficial de producción) - - - - l +gggggggg Nombre de grupo de acceso

En donde:




Para archivos comunes de sistemas aplicativos en la fase de produc- ción en estado de respaldo.

, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I l er. Calif j 2do. Calif. : 3er. Calif. 1 4 0 . Calif. 1 , - - - - - - - - - - - - - - - - - - - - - J - - - - - - - - - J - - - - - - - - - 1 gggggggg / 'OFC f 'BK' I sss I m I GnnnnVnn I

1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 I I I I I I I wOPCIONALH 1 1 1 1 I 1 - - - - , GnnnnVnn = Para ver- 1 1 1 I 1 I I I I I siones de archivos históricos 1 1 1 1 I I I I : - - - + fffíffR = Identificación de la función I I 1 1 1 1 1 1

básica del archivo I I I 1- - - -, Sss = Identificación del sistema y subsistema 1 1 I I I - - - ,'BK' = Constante (archivo en respaldo) 1 I ! - - - +'OFC' = Constante (archivo oficial de producción) L - - - +gggggggg Nombre de grupo de acceso

En donde:


Sss = En formato Iibre codificar la clave de1 sistema y subsistema de que se trate, teniendo cuidado de asignar la misma para el mismo sistema y subsistema.

gggggggg = Para efectos de poder codificar el nombre de gmpo de acceso.

FORMATO DE NOMENCLATURA PARA LA FORMACIÓN DE NOMBRES DE BIBLIOTECAS

Descripción

Toda biblioteca ubicada dentro de los dispositivos de almacenamiento deberá estar identificada con un nombre único. Esta regla es de carácter obligatorio, requerida por el propio sistema operativo.

Con este fin, y para lograr una identificación rápida que permita, por medio de su nombre (DSNAME), conocer a quién pertenece y cuál

es su contenido así como evitar la duplicidad de nombres, a continua- ción se describen las reglas de codificación.

Para bibliotecas privadas personales para programadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 : l er. Calif. 2do. Calif. 1 3er. Calif. i l - - - - - - - - - ' - - - - - - - - - - - 1

1 - - - - - - - - - - 1 ! uuuuuuu ! 'SPRIVLIB' I tttttttt i----------l-----------l-----,J

1 1 1 1 1 I I \ - - - -, mmtt = Tipo de biblioteca. 1 I ! - - - -, 'SPRIVLIB' = Constante (biblioteca de 1 I uso personal en servicio). L - - - + uuuuuuu = Identificación personal (USERID).

En donde:

tttttttt = El tipo de biblioteca, para este caso podrá ser únicamente de los dos tipos siguientes:

- Fuente. - Carga.

- uuuuuuu = Identificación personal del programador.

Para bibliotecas privadas personales en estado de respaldo (backup) para programadores.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I l er. Calif. i 2do. Calif. j 3 e r Calif. : i - - - - - - - - - ' - - - - - - - - - - - 1

1---------- 'BPRIVLIB' ; mtttr \

- - - - - - - - - - l - - - - - - - - - - - - - - - - - - - - - A

1 1 1 1 1 I I 1 - - - -, tttttttt = Tipo de biblioteca. 1 I ! - - - -, 'BPRIVLIB' = Constante (biblioteca de 1 I uso personal en backup). l- - - -, uuuuuuu = Identificación personal (USERID).

En donde:

ttttttt = El tipo de biblioteca, para este caso podrá ser únicamente de los dos tipos siguientes:

- Fuente. - Carga.

uuuuuuu = Identificación personal del programador.

Para bibíiotecas comunes de sistemas aplicativos en la fase de prueba y en servicio.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7

I ler. Calif. I 2do. Cala 3er. Calif. 1 1- - - - - - - - - - : ; - - r - - - T - - - - - - - - - . I

1 m j - ;PR~. SV. 1 sss 1 tttttttt ; - - - - - - - - - - - - - - - - - - - L - - - n - - - - - - - - - _ I

1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 I I I I ' - -b mmtr = Tipo de biblioteca. I I 1 - -b Sss = Identificación del sistema y subsistema. 1 1 I I - +'SI" = Constante (biblioteca en servicio). 1 I - + 'PRU' = Constante (biblioteca para pruebas). - + gggggggg = Nombre de grupo de acceso.

En donde:

tttttttt = El tipo de biblioteca para este caso podrá ser de los siguientes tipos:

- Fuente. - JCLdisp. - Proced. - Carga. - Macros. - Params. - Objeto. - Gráficas. - Clists. - Menús. - Estand. - JCLstruc.



Para bibliotecas comunes de sistemas aplicativos en la Fase de prueba en estado de respaldo (backup).

j 1 er. Calif. j 2d0. Calif. i ser. Calif. : 1- - - - - - - - - - r ; - ; r - - - T - - - - - - - - - . l

l gggggggg :- TiR"; BK SSS mrntt I 1

- - - - - - - - - - - - - - - ' - - - I _ _ _ - - - : - - - - - - - - - i I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I I I I I ' - -b mrntt = Tipo de biblioteca. I I ! l - -bSss = Identificación del sistema y subsistema.

I

I I - + 'BK' = Constante (biblioteca en respaldo). I

I L - + 'PRU' = Constante (biblioteca para pruebas). ! - + gggggggg = Nombre de grupo de acceso.

En donde:

tttttttt = El tipo de biblioteca, para este caso podrá ser de los siguientes tipos:

- Fuente. - JCLdisp. - Proced. - Carga. - Macros. - Params. - Objeto. - Gráficas. - Clists. - Menús. - Estand. - JCLsmc.



Para bibliotecas comunes de sistemas aplicativos en la fase de producción y en servicio.

i e . C i f 2do. Calif. j 3er. Calif. ! l----------l-----T---T---7---,--.1

; gggggggg ; 'OFC' ; 'SV ; sss 1 tttttttt - - - - - - - - - - - - - - - - - - - - - - - 1 - - - - - - - - - 2

I 1 1 1 1 1 1 I 1 I 1 1 1 1 1 1 1 I l I I I I ' - -b mmtt = Tipo de biblioteca. I I 1 ' - -bSss = Identificación del sistema y subsistema. 1 1 I I - +'SV = Constante (biblioteca en servicio). 1 1 - + 'OFC' = Constante (biblioteca oficial de producción). ! - + gggggggg = Nombre de grupo de acceso.

En donde:

tttttttt = El tipo de biblioteca para este caso podrá ser de los siguientes tipos.

- Fuente. - JCLdisp. - Proced. - Carga. - Macros. - Params. - Objeto. - Gráficas. - Clists. - Menús. - Estand. - JCLsmc.

Sss = En Formato libre codificar la clave del sistema y subsistema de que se trate, teniendo cuidado de asignar la misma para el mismo sistema y subsistema.


Para bibliotecas comunes de sistemas aplicativos en la fase de pro- ducción en estado de respaldo (backup).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 l er. Calif. 2do. Calif. j 3er Calif. 1- - - - - - - - - - I - - - - - r - - - T - - - T - - - - - - - - - . I

1 gggggggg ; 'OFC'; 'BK' j SSS I t t t t t t t t ; l-----------------------l---------J

1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 I I I I ' - -b tttttttt = Tipo de biblioteca. I I ! - -b Sss = Identificación del sistema y subsistema.

1 I I - + 'BK' = Constante (biblioteca en respaldo). 1

I '- - + 'OFC' = Constante (biblioteca oficial de producción). '- - + gggggggg = Nombre de grupo de acceso.

En donde:





Para bibliotecas comunes de programas producto (software de apoyo al sistema operativo) en la fase de pruebas.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . j l er. C a l l 2do. Calif. 3er C a l l ; 1 - - - - - - - - - - 1 - - - - - r ; - - T - - - T - - - - - - - - - . l ; gggggggg ; 'PPS' pR' 1 xxx 1 tttttttt ; - - - - - - - - - - - - - - - - - - - L - - - J - - - - - - - - - J

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ' - -b tttttttt = Tipo de biblioteca. I I 1 l - -b xxx = Identificación del programa producto. 1 1 I I - + 'PR' = Constante (biblioteca en pruebas). I

I - +'PPS' = Constante (biblioteca de programa producto). k - + gggggggg = Nombre de grupo de acceso.

En donde:


- Fuente. - JCLdisp. - Proced. - Carga. - Macros. - Params. - Objeto. - Gráficas. - Clists. - Menús. - Estand. - JCLstnic.

xxx = En formato libre codificar la clave del programa producto de que se trate.


Para bibliotecas comunes de programas producto (software de apoyo al sistema operativo) en la fase de servicio.

1 l er. Calif. 2do. Calif. / 3er Calif. 1 1 - - - - - - - - - - I - - - - - r - - - r - - - T - - - - - - - - - . I ; gggggggg ) 'ppy 'SV' 1 xxx 1 tttttttt ; - - - - - - - - - - - - - - - - - - - I - - - i - - - - - - - - - A

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I I I I ' - -b ttmm = Tipo de biblioteca. I I ! l - -, xxx = Identificación del programa producto.

I

I I - + 'SV' = Constante (biblioteca en servicio). I - + 'PPS' = Constante (biblioteca de programa producto). I - + ggggggg = Nombre de grupo de acceso.

En donde:


- Fuente. - JCLdisp. - Proced. - Carga. - Macros. - Params. - Objeto. - Gráficas. - Clists. - Menús. - Estand. - JCLstnic.



Para bibliotecas comunes de programas producto (software de apoyo al sistema operativo) en estado de respaldo (backup).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7 1 1

1 l er. Calif. ; 2do. Calif. I 3er. Calif. ; ; - - , - - - '---'--- 1 - - - - - - - - - -

- - - - _I

I gggggggg PPS (BK' XXX: - - -2Gtttt 1 1 - - - - - - - - - - - - - - - 1 - - - I - - - n - - - - - - - - - A

1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1

1 l- -, ttmm = Tipo de biblioteca.

1 1 I I ; I - -, xxx = Identificación del programa producto. 1 1 I I - + 'BK' = Constante (biblioteca en respaldo). 1 I - - +'PPS' = Constante (biblioteca de programa producto). I - + ggggggg = Nombre de grupo de acceso.

En donde:





Tabla 20.1. Descripción de tipos de bibliotecas en cuanto a su contenido.

Tipo de biblioteca Contenido único

Fuente Programas fuente correspondientes a un mismo sistema o subsistema.

Macros Macroinstrucciones requeridas dentro de los programas de un mismo sistema o subsistema.

JCLdisp Disparadores de JCL que invoquen a su vez grupos de cláusulas de JCL en modo de procedimientos catalogados.

Params Parámetros de control requeridos por los procesos.

Proced Grupos de cláusulas de JCL formando procedimientos catalo~ados.

Objeto Programas en forma de módulos objeto correspondientes a un mismo sistema o subsistema.

Carga Programas en forma de módulo de carga correspondientes a un mismo sistema o subsistema.

Gráficas Gráficas correspondientes a un mismo sistema o subsistema.

Clists Grupos de comandos de TSO (CLISTS).

Menús Formatos de pantallas (MENUS) para sistemas interactivos vía TSO.

Estand Definiciones de estándares de uso generalizado.

Docum Documentación de las experiencias de la instalación de programas producto.

JCLstruc Estructuras de JCL utilizables por medio de menús de TSO.


Para bibliotecas primarias del sistema operativo.

- - - - - - - - - - - - - - - - - 1

1 l er. Calif. ! 2do. Calif. I

1 1 L - - - - - - , xxxxxxxx = Identificación I individual asignada por el 1 I proveedor del sistema operativo. [ - - - - - - - - - - - - - - - - - + 'SYSI' = Constante (biblioteca primaria).

En donde:

=Este nombre está ya predefinido por el proveedor del software del sistema operativo, identifica en sí la función de dicha biblioteca de acuerdo con la estructura funcional del propio software.

'SYS1' = Este es el prefijo estándar de las bibliotecas primarias (1) que contienen el sistema operativo.

Para bibliotecas secundarias del sistema operativo.

- - - - - - - - - - - - - - - - - I l er. CalK j 2do. Calif.

; 'SYSZ' I xxxxxxxx j

1 1 1 - - - - - - - , xxxxxxxx = Identificación I individual asignada por el 1 I proveedor del sistema operativo. [ - - - - - - - - - - - - - - - - - + 'SYSZ' = Constante (biblioteca secundaria).

NOTA: Como estándar general, todo nombre de archivo o biblioteca deberá ser catalogado al momento de su creación. El catálogo señala todos estos nombres a su volumen correspondiente; por tanto, esta será la manera como dicho volumen indicará si el archivo se encuentra en un paquete de discos o en un volumen de cinta magnética.

En donde:

xxxxxxxx = Este nombre está ya predefinido por el proveedor del software del sistema operativo, identifica en sí la función de dicha biblioteca de acuerdo con la estructura funcional del propio software.

'SYS?' = Éste es el prefijo que se deberá asignar a toda biblioteca que por cuestiones de seguridad contenga módulos modificados del propio sistema operativo.

FORMATO DE NOMENCLATURA PARA LA FORMACIÓN DE LA IDENTIFICACI~N PERSONAL

Descripción

Toda persona que requiera usar los recursos de cómputo deberá estar reconocida por una clave individual de usuario denominada USERID.

Sin esta clave, no será posible la autorización para acceso al uso del equipo de cómputo para ninguna persona, ya que de manera completamente automática, cuando se intente su uso, la persona será requerida para que proporcione su clave individual (USERID), y sólo cuando la clave proporcionada sea válida se autorizará el acceso.

Para que una persona sea autorizada, será necesario que quede registrada por medio de su identificación individual (USERID) dentro de los archivos de seguridad controlados por el sistema operativo. Por tanto, es requisito solicitar su alta al personal del grupo de soporte técnico.

En el caso del esquema de nomenclatura, esta clave representará el primer calificador para los nombres de bibliotecas privadas asignadas a cada programador.

Las reglas para la formación del USERID para cada persona se enrnarcan a continuación:

FORMATO DE NOMENCLATURA PARA LA FORMACIÓN DE LA CLAVE DE IDENTIFIcAcIÓN

PERSONAL (USERID) I _ _ _ _ _ _ _ _ _ _ _ _ _ - - _ - - - - - - - - 7

1 1 1 1 1 1 I

I U U I a i n i xxx I 1 1 1 1

1 I I 1 1 I 1 1

I I I 1- - -, xxx = Iniciales del nombre de la persona. 1 I I I i - - -, n = Nivel de autorización. I I I - - .+a = Clave de área dentro de la unidad usuaria. : - - + uu = Clave de unidad usuaria.

A continuación, se presentan los distintos niveles de autorización, con el fin de estructurar cada USERID.

Tabla 20.2. Para la asignación de niveles de autorización para el personal de las unidades usuarias externas al centro de cómputo.

Nivel de a utorización Descripción

Deberá ser asignado a personas cuyo trabajo consista en operar la información de sistemas ya desarrollados con posibilidades de accesar sólo archvos, y pueden incluso alterar su contenido.

Deberá ser asignado a personas cuyo trabajo consista en

3 operar la información de sistemas ya desarrollados con posibilidades de accesar sólo archivos, para efectos úni- camente de consulta de datos.

NOTA: Para este caso, el nivel de autorización lo único que tipifica es el trabajo que se realiza, mas no la jerarquía ni el nivel de conocimientos de la persoe. '

Tabla 20.3. Para la asignación de niveles de autorización para el personal del centro de cómputo.

Nivel de autorización Descripción

. -. -

Deberá ser asignado al personal propio de soporte técnico, I) el cual tiene la responsabilidad de dar mantenimiento a -

los programas, pa;ámetros y archivos del sistema operativo. (Nivel superior sin restriccionesl) - -- - -- - -

Deberá ser asignado al personal de desarrollo de siste- 1 mas, el cual tiene la responsabilidad de dar manteni-

miento y soporte aplicativo.

2 Deberá ser asignado al personal que realiza básicamente &funciones de programación y operación de procesos.

.Deberá ser asignado al personal en entrenamiento, incluso a operadores de la computadora que lo justifiquen por '

- sus funciones. -

RESUMEN

Es frecuente que una instalación pierda el control en cuanto a cantidad, contenido, tipo e importancia de los archivos de datos que mantiene en custodia e integridad el centro de cómputo. Esto resulta inconcebible si consideramos que es la materia prima principal para el funcionamiento de los sistemas. El primer factor que debe establecerse para abordar este problema es clasificar el tipo de datos y archivos por orden de importancia. Como siguiente paso, es necesario establecer una identificación precisa para determinar los esquemas de resguardo y de respaldo de cada uno de ellos. Deben considerar~e dos tipos de resguardo: el primero será para resguardo local, en donde se ubican aquellos archivos que por su naturaleza deben estar disponibles en el momento oportuno para la producción diaria; el segundo será para resguardo fuera de sitio y para archivos históricos o de difícil recuperación, de preferencia estarán ubicados en una bóveda contra incendio. El manejo preciso de fechas de caducidad dará la pauta para mantener archivos útiles. La identificación individual de cada archivo, por sí sola, deberá contestar: iqué archivo es¿, i a quién corresponde<, iqué tipo de archivo es¿, y ien dónde se encuentra ubicado<

Como ha sucedido, en las PC el tamaño máximo para dar nombre a los archivos es de ocho más tres caracteres. Sin embargo, ya se anun- ció que se va a manejar una longitud mucho mayor, lo cual permitirá utilizar cabalmente la nomenclatura aquí descrita.

Ingeniería de sistemas: análisis, \ diseño y mantenimiento 2

Problema

La prueba de que muchas instalaciones desarrollan sistemas improvisados se da por el hecho de que frecuentemente "arreglan" programas con el fin de emitir nuevos resultados, no por cambios obligados, sino porque no fueron previstos durante el análisis inicial.

Este fenómeno se ha generalizado, pues son pocas las instalaciones en nuestro país que hacen cambios a los sistemas ya en producción, obligados por una verdadera necesidad. Son más las que permanecen en un eterno mantenimiento por falta de sistemas consistentes que no heron diseñados meticulosamente apegados a estándares sólidos. Es común escuchar que el usuario necesita resultados nuevos, o cambios a los ya existentes, porque sus requerimientos de información están incompletos o simplemente porque no cubren sus necesidades concretas. Es más, muchos de los resultados que emanan de tales sistemas ni siquiera le son de utilidad; y a veces hasta los recibe duplicados sólo que en distintas fases del sistema.

Desarrollar un análisis y elaborar el diseño no es tarea sencilla, requiere mucho tiempo de estudio y dedicación. Representa una gran dosis de investigación y otro tanto de planeación. Implica bastante creatividad por ambos lados, el usuario y el analista. Obliga a una fuerte labor de análisis de necesidades de información y, por tanto, a un alto grado de conocimiento del medio para el cual se hará el diseño; es decir,

238 CAP 21. ANÁLISIS, DISEÑO Y MANTENIMIENTO

si se va a diseñar un sistema para una aseguradora, se requiere conocer bastante del área de seguros; por otro lado, si lo que se va a desarrollar es un sistema de control de impuestos, es vital dominar los conceptos fiscales; y así, según el medio de que se trate. Esto no puede adquirirse de un día para otro. Asimismo, debe tenerse un dominio absoluto de las técnicas de computación para lograr la traducción de las necesidades del usuario, en términos técnicos de procesamiento de datos.

Es obvio que esto no puede hacerse empíricamente, o mejor dicho, no se debe, ya que en verdad son muchas las instalaciones que se atreven a improvisar sistemas, y las repercusiones, tanto en tiempo como en costo, son altísimas. Basta saber que muchos sistemas (si es que se les puede llamar así), desde su nacimiento y hasta la fecha, son de un alto costo y de muy poca utilidad para los usuarios, pues su aprovechamiento es casi nulo, y se dan casos en que para obtener un raquítico resultado se pasan semanas de proceso, arrojando infinidad de resultados que a nadie sirven, o a los cuales el usuario todavía tiene que adecuar con información surgida de sus propios procedimientos manuales o por sistemas colaterales elaborados específicamente para tal fin.

En auditorías efectuadas en diversas instalaciones se han encontrado casos en que hasta 30 % de los resultados de un sistema, que consume semanas de proceso, son desperdiciados por no interesar a nadie. En ocasiones para obtener un resultado útil se tienen que hacer cinco o más cruces de archivos voluminosos de difícil creación. No es un secreto que en incontables ocasiones se hacen programas satélite bastante laboriosos, para generar algún resultado que no se tiene del sistema original. Esto y un sinnúmero de problemas bien conocidos por todos son los que producen lo que a menudo se denomina "mazacotes" de programas, disfrazados de sistemas.

La palabra análisis conlleva un proceso de investigación minuciosa, imposible de desarrollar rápidamente o con pláticas improvisadas con el usuario. El concepto diseño representa un alto grado de inventiva y creatividad. Los pasos del análisis y diseño obligan a un proceso perfectamente definido. Significan secuencia, estructura, orden, previ- sión y cualquier ingrediente lógico que oFrezca seguridad y confianza de que se cubren las necesidades completas de información para lo que el sistema está concebido.

La solución más viable para atacar este problema no puede ser simple, deberá surgir metódicamente de una gran cantidad de experiencias y la recopilación de muchas prácticas probadas en el terreno de los hechos, obtenidas después de muchos fracasos y de la persistencia para lograr los

correctivos de más beneficio. Por ello, la siguiente metodología ha prevalecido con un amplio reconocimiento por quienes la han puesto a prueba. Cierto es que no es la panacea, pues quizá usted encuentre puntos que no se ajusten a sus propios procedimientos, pero si es así, mejórela y obtenga mejores resultados. Lo que sí aseguro es que se acerca mucho a lo que hoy se conoce con el nombre de Reingeniería de Sistemas. Pero yo a esta metodolo- gía que aquí presento la ofrezco mejor como una reahgeniería de Sistemas.

Surge la solicitud

El disparador normal que origina el desarrollo de un sistema surge como una solicitud que hace el usuario al área de informática. En dicha solicitud se destaca lo siguiente:

Los objetivos. El usuario debe definirlos. La comprensión de estos objetivos es vital para el diseño integral. Las políticas. Los usuarios de1 sistema deberán establecerlas, ya que éstas normarán los criterios más importantes dentro de la filosofía del sistema.

Es probable que el personal de sistemas ayude al usuario a fijar los objetivos y políticas. Tanto los objetivos como las políticas del diseño deberán quedar establecidos por escrito, procurando que sean claros y concretos, y sobre todo reales, apegados a 10s verdaderos requerimientos detectados.

Investigación del sistema actual o necesidad (análisis)

Es importante investigar si existe un sistema actual mediante el cual se obtengan los resultados o parte de éstos, para así determinar más adelante si es conveniente diseñar uno nuevo, considerando el perfeccionamiento de las operaciones y la reducción de los costos, así como nuevos resultados no estimados en el actual. Nótese que el sistema actual podría ser incluso del tipo manual.

Plan de investigación

Para todo tipo de investigación debe elaborarse un plan o programa de trabajo, previo al inicio de ella; el plan de investigación deberá

240 CAF! 21. ANALISIS, DISENO Y MANTENIMIENTO mi contener las actividades por realizar Y el tiempo estimado de duracion de cada una de ellas. ~ s t 6 dará una vkión ,general de las actividades por realizar, el tiempo que se requiere y los usuarios que se van a investigar o que van a intervenir en la investigación. Antes de elaborar el plan o programa de trabajo, el analista tendrá que documentarse y ubicarse en el medio para el cual se hará el sistema.

Ubicación en el medio. Antes de iniciar la investigación, es fundamental ubicarse en el medio por investigar con documentación existente y pláticas con personas que tengan amplio conocimiento del mismo; los elementos básicos son 10s siguientes:

Estructura y organización de la unidad usuaria. Mostrará un panorama genera1 de cómo iniciar la investigación y a quién dirigirse. Relación de la unidad usuaria con otras unidades. Dará un panorama más amplio de la función e importancia de esa unidad usuaria. Objetivos, políticas y funciones. Se obtendrá un conocimiento general de la unidad usuaria en cuanto a funciones y resultados básicos que se logran, así como las normas que regulan los procesos administrativos vigentes. Si se trata del rediseño de un sistema ya automatizado, la ubica- ción se efectuará con la documentación correspondiente. De no existir ésta totalmente integrada, se efectuarán pláticas con el analista que diseñó o que mantiene el sistema actual, ya que es él quien está más enterado de ello e incluso conoce la operación actual y deficiencias más notables que originaron la solicitud al área de sistemas.

Relación de actividades y estrategia de investigación. Para todo tipo de investigación debe elaborarse un programa o plan de trabajo, previo al inicio de ella. Este programa de investigación deberá contener las actividades por realizar y el tiempo estimado de duración de cada una de ellas, para obtener una panorámica completa de actividades, su secuencia, las áreas por investigar, así como el tiempo total que tomará la investigación.

Este plan puede variar, dependiendo del desarrollo de la investiga- ción, ya que puede haber aspectos que, por su importancia, justifiquen tal variación. Sin embargo, el plan inicial será la guía principal. Fundamen- talmente debe considerarse lo siguiente en el programa de investigación:

Actividades. Secuencia. Duración de las actividades.


Áreas y personas involucradas, Observaciones.

Desarrollo de la investigación

Una vez que se tiene conocimiento completo del medio por investigar (ubicación), se procede a realizar la investigación; primordialmente tienen que hacerse entrevistas, tanto en el nivel ejecutivo como en el operativo.

Para realizar una entrevista en cualquier nivel, es indispensable : documentarse sobre las £unciones y caracteristicas del personal por entrevistar, así como preparar cuestionarios para obtener la información deseada; es posible utilizar las siguientes técnicas de entrevistas, dependiendo del caso.

Abierta. Cuando no existe un cuestionario predefinido. Cerrada. Existe un cuestionario específico de la entrevista. Mixta. Cuando existe un cuestionario, pero también incluye consideraciones abiertas.

Entrevistas en el nivel directivo. Por lo general, los primeros contactos en la investigación son las personas de mayor nivel jerárquico de la unidad usuaria afectada; por tanto, al efectuar la entrevista deberá dirigirse básicamente a obtener la siguiente información:

Objetivos específicos (sistema actual). Deberá obtenerse informa- ción al respecto para afirmar o variar lo estudiado cuando se hizo la ubicación. Sobre el sistema por diseñar, es recomendable obtener:

- Resultados principales. - Operaciones básicas. - Entradas al sistema. - Usuarios de los resultados. - Tiempos de respuesta de cada operación básica. - Recursos utilizados. - Deficiencias detectadas y situaciones deseables.

Relaciones externas de la unidad usuaria. Deberá obtenerse mfor- mación acerca de las relaciones externas, para determinar si los objetivos del sistema por diseñar son reales o ubicados en el medio. La información por obtener será:

242 CAF! 21. ANÁLISIS, DISENO Y MANTENIMIENTO

- Servicios aparentes y reales de la unidad usuaria. - Relaciones directas con otras unidades usuarias. - Relaciones indirectas con otras unidades usuarias. - Tiempo de respuesta de resultados hacia otras unidades usua-

rias. - Canales de comunicación y de flujo de información. - Principales incongruencias entre unidades usuarias.

Objetivos propios de la unidad usuaria. Deberá considerarse que algunas veces los objetivos no son entendidos correctamente, por lo que deben captarse los verdaderos objetivos en el resumen de la entrevista, y después verificar dichos objetivos durante el desarrollo de la investigación. De lo anterior deberán quedar precisadas:

- Políticas de la unidad usuaria. Considerar cuáles políticas están reglamentadas y cuáles no lo están; igualmente, los objetivos deberán verificarse en el desarrollo de la investigación.

- Estructura de la unidad usuaria. Es importante conocerla para tener un conocimiento más veraz acerca de ella y del personal a quién dirigirse; es conveniente que se derive de este estudio la presentación del investigador con personal de jerarquía más baja para lograr su apoyo también, lo cual será útil y eliminará malos entendidos sobre el porqué se realiza la investigación.

Las consideraciones que se deben tomar en cuenta en una entrevista en el nivel dirección son las siguientes:

v Documentarse sobre las características y funciones del entrevistado; esto es útil para crear un ambiente de confianza. Utilizar la terminología adecuada al entrevistado, para un mejor entendimiento (evitar tecnicismos). Destacar la importancia de la participación del entrevistado en el desarrollo del sistema por hplantar, para lograr su apoyo. Dirigir la entrevista para que el entrevistado plantee las soluciones al sistema; para que lo sienta como creación suya. Hablar con tacto, sin herir susceptibilidades ni criticar. Saber escuchar, pero sin dejar de tener iniciativa. Contagiar entusiasmo por el proyecto. Considerar que una entrevista en el nivel de dirección no es para recopilar información detallada, sino más bien, de alcances de negocio. Si es necesario, dejar abierta la posibilidad de una siguiente entrevista con una razón específica. Al término de cada entrevista, es necesario documentarla en el menor tiempo posible trans-

currido desde el término de ella, considerando los siguientes puntos:

- Número secuencia1 de entrevista dentro de la investigación. - Puesto del entrevistado. - Funciones del entrevistado. - Objetivo de la entrevista. - Cuestionario de la entrevista. - Observaciones. - Conclusión de la entrevista. - Persona y puesto siguiente por entrevistar.

Si no se efectúa esta documentación al término de la entrevista, se pierden muchos aspectos correspondientes al objetivo de la investiga- ción. Por tanto, debe documentarse cada una de ellas dentro del desarrollo de la investigación.

Entredstas en el nivel operativo. Normalmente, este tipo de entrevistas se relaciona con el recorrido de la información. Esta forma de recopilación de información tiene por objetivo vislumbrar la opera- ción real del sistema actual; y con el fin de automatizarlo, deben considerarse los siguientes elementos:

Flujo de documentos. Ya que los procedimientos actuales seguramente son del tipo manual, se deberá recopilar información documental existente, en la cual se basen dichos procedimientos. Durante la recopi- lación de información deben verificarse los objetivos y políticas marca- das en las entrevistas en el nivel dirección, porque en algunos casos están desvirtuadas en los niveles operativos, y un malentendido por el analista podría traer graves repercusiones posteriores.

Entradas a l sistema. Usualmente, las entradas de un sistema son señaladas como generales, por lo que si no se investigan a fondo, se puede omitir alguna que repercuta en el sistema y no esté declarada como tal. Deben considerarse los siguientes tipos de entradas:

Definidas o lógicas. Las que por naturaleza del sistema y su operación son necesarias para lograr el objetivo de determinado sistema u operación. Impuestas. Las que por determinada política o norma entran en el sistema; este tipo es generalmente de carácter legal. Por excepción. Las entradas que no están comprendidas en el objetivo básico del sistema u operación, pero que están dentro de los límites de los mismos, y que por ser de este tipo, son excep- cionales. Se deberán considerar todas las entradas por excepción u operación del sistema, para determinar el volumen de entradas por excepción en relación con las entradas lógicas e impuestas.

244 CAP 21. ANÁLISIS, DISENO Y MANTENIMIENTO

No definidas. Son de difícil detección en una entrevista. Lo más factible es detectarlas en el recorrido de la información, pero en algunas ocasiones en esta fase de la investigación serán detectadas al permitir que el entrevistado se explaye con un tipo de entrevista mixta. Es de suma importancia detectarlas, ya que pueden desvirtuar la política real del sistema.

Resultados del sistema actual. Considerando los objetivos detectados en las entrevistas en el nivel dirección, se debe recopilar informa- ción sobre los resultados que cubran dichos objetivos o, en caso contrario, detectar cuáles son los resultados reales. Estos resultados se clasifi- can de la siguiente manera:

Lógicos. Son los resultados que por naturaleza del sistema y su operación deben estar comprendidos en él; se debe considerar la utilización de cada uno de ellos para evaluar si verdaderamente son aprovechados, según el enfoque que se predeterminó. Impuestos. Además de los resultados lógicos, existe este tipo de resultados, los cuales también deberán estar comprendidos en el sistema y su operación; pero se debe buscar la causa por la que están impuestos para tener una visión más clara de los alcances y repercusión de los resultados del sistema y su operación, si éstos fueran variados posteriormente. Adicionales. Este tipo de resultados son los que se obtienen por iniciativa del personal que interviene en el sistema y su opera- ción; se debe conocer la utilización de dichos resultados para detectar su funcionalidad, validez y legalidad. No comprendidos. Este tipo de resultados se determinarán al entrevistar en este nivel; también se pueden lograr como aporta- ción de las juntas operacionales, con esto se obtendrán más recursos de información al diseñar el sistema, y por tanto, mayor alcance operativo.

Funciones operativas y toma de decisiones. En el transcurso de la investigación, y en particular al entrevistar personal operativo, se encuentran diversos tipos de operaciones que se realizan con la informa- ción en proceso, las cuales son las siguientes: manuales, mecánicas y electromecánicas. Por el momento sólo se definen las manuales, ya que son la base del análisis. Existen diferentes operaciones manuales realizadas con la información, las más comunes son:

Recepción de información Fuente. Es una operación de carácter manual; para ello existen controles como: foIios, catálogos y facturas. Es importante que se conozca e1 origen de la informa- ción recibida y sus datos de cuantificación.

Selección y distribución de la información. Esta operación se realiza de acuerdo con sus características y objetivos de proceso. Es conveniente detectar en esta fase el número de copias utilizadas en el documento fuente, la distribución de cada una de ellas y las operaciones realizadas, para detectar funciones duplicadas u operaciones innecesarias. Proceso del documento fuente. En esta fase deben investigarse todas las operaciones que se realizan con el documento fuente, así como los resultados que se obtienen; las operaciones más comunes son:

- Cálculos con la información. Depende del objetivo de la operación y de la necesidad de cuantificación de datos.

- Adecuación de la información para una operación posterior, como son: codificación, señalamiento sobre conceptos especiales, complementación de información en casos específicos, correc- ción y modificación de información con base en tratamientos nuevos, así como depuración de alguna otra información por cuestiones de caducidad, redundancia o de cualquier otro tipo.

- Cifras de control. Deben estar ligadas con los puntos de control del sistema u operación; asimismo, deberá considerarse su validez y utilización efectiva.

- Destino del documento fuente. Es importante para determinar la antigüedad de información y volúmenes, así como el medio donde se archiven los documentos y la periodicidad de consulta y caducidad y, por supuesto, que para esto deberán existir y hacerse caso de las reglamentaciones para ese fin.

Es importante determinar la frecuencia de toma de decisiones en los niveles operativos (que aunque son necesarias para agilizar los procesos de trabajo no pueden dejarse al arbitrio de las personas, sino que deben ser bien asignadas y definidas), ya que puede ser la razón de las variaciones del sistema actual. Por lo anterior, es importante determinar los tipos de decisiones y quiénes están facultados para tomarlas, así como los límites de las mismas, para identificar si no está centralizada la toma de decisiones; ya que de ser así, repercutirá en el funcionamiento normal del sistema. En general, existen los siguientes tipos de decisiones en el nivel operativo:

De supervisión o coordinación. Es el tipo de personal que conoce el sistema con mayor detalle y la gente más apropiada en la toma de decisiones en este nivel. Es muy importante analizar la autoridad de estas personas dentro del sistema, para ubicar los límites de decisiones correspondientes. Además, es importante identificar el tiempo de respuesta de la toma de decisiones al tener una variación el sistema, para considerarlo dentro de la automatización del nuevo sistema.

246 CAP. 21. ANALISIS, DISENO Y MANTENIMIENTO

De operación. Este tipo de decisiones debe ser muy limitado y vigilado; y en la investigación debe observarse la preparación del personal para la toma de decisiones. El ámbito de la toma de decisiones en este nivel está acorde con el conocimiento del sistema, y es función del jefe inmediato fijar los límites para ejercerlas.

Hay consideraciones que el analista de sistemas debe tomar en cuenta cuando entreviste a personal de nivel operativo. Es conveniente que él se asegure que antes de empezar una entrevista de este tipo exista una presentación general de él al personal por entrevistar, y después a cada uno de ellos según la secuencia de las entrevistas. Esto es lo primero que debe hacer el jefe inmediato superior por parte de los usuarios. El objetivo de esta presentación es que todos conozcan al analista de sistemas y sepan el motivo de sus entrevistas, para evitar falsos rumores y situaciones difíciles en torno a éste. El analista debe considerar los siguientes puntos:

Realizar con anterioridad un plan o cuestionario para cada entrevista. Utilizar el lenguaje adecuado con el entrevistado para tener un mej or entendimiento (evitar mencionar tecnicismos). Dejar hablar libremente al entrevistado sobre su función, para captar ideas que beneficien la operatividad del sistema. No permitir que el entrevistado lo desvíe del objetivo primordial de la entrevista. Seguir el orden planeado de entrevistas hasta donde sea posible. Hablar con tacto y evitar ser el entrevistado, procurando ser discreto. Toda entrevista provoca situaciones comprometedoras, por lo que es recomendable lo siguiente:

- Seguridad en sí mismo. - Aplomo. - Presentación. - Hablar claro. - No ser irónico. - No intimar con los entrevistados.

Objetivos y políticas internas. Durante las entrevistas en el nivel operativo es importante comprobar que el personal conozca los objetivos y políticas que han determinado los directivos de la unidad usuaria, y que aquéllos sean aplicados en cada uno de los pasos de la operación del sistema; si llegan a detectar que están desvirtuados, habrá que considerarlo dentro del funcionamiento del sistema actual, ya que esto podría estar afectando, y por tanto se debe plantear en los niveles correspondientes. Aquí se deberá ser muy precavido, porque se podría considerar que el analista es un espía, y jamás volverá a contar con una participación veraz por parte del personal operativo.

Recorrido de la información. Esta fase de la investigación es la observación y seguimiento del proceso de la información, desde su origen hasta la última actividad realizada para ello. Además, en esta fase hay que poner especial cuidado, ya que podría existir alguna actividad duplicada o innecesaria, así como alguna falla de importancia que repercuta en el sistema por automatizar.

Durante el recorrido de la información se tienen que investigar los siguientes aspectos:

Origenes del documento fuente o información. Durante el recorrido de la información deberán determinarse los orígenes del documento fuente o información básica del sistema, donde se consideren los departamentos y funciones que intervienen en la estructuración del documento fuente o información de origen.

Normas y reglamentaciones. Aquí deberán estimarse las normas y reglamentaciones que rigen durante el recorrido de la información, y comprobar si se cumplen y si son adecuadas, como pudieran ser las consideraciones de confidencialidad, integridad, seguridad y otros establecidos.

Volúmenes. Se deberán considerar los volúmenes de información manejados en un periodo determinado, los cuales deberán tomarse en cuenta en el sistema investigado y en el posible sistema por diseñar.

Periodicidad. Se deberá investigar la frecuencia con que fluye esa información y cada una de las operaciones involucradas en función de esa periodicidad.

Variaciones. Aquí se investigarán las variaciones que sufre la infor- mación en caso de que las haya, así como las repercusiones ocasionadas por ello y las causas que las motivan.

Confiabilidad. Tomar en cuenta la eficacia del servicio del sistema actual, para determinar la confiabilidad y la calidad de información que se maneja en ese momento y prever un perfeccionamiento en este sentido.

Antigüedad y caducidad de información. Investigar la antigüedad de los archivos básicos del sistema, así como la frecuencia de su consulta. También se tomará en cuenta el respaldo de los archivos para la recu- peración de información en caso necesario, y considerarlo todo ello en el sistema por automatizar.

Recopilación de formas preimpresas. Durante el recorrido de la in- formación es conveniente tomar ejemplares de todas las formas preimpresas utilizadas en el sistema actual, y observar su contenido y apa- riencia con fines de perfeccionamiento.

Complejidad del proceso. Deberá determinarse el grado de dificultad de operación del sistema en función de los recursos necesarios. Esto permite, entre otras cosas, determinar el tipo y nivel de personal que realmente se requerirá en cuanto a su nivel académico y experiencia.

Tiempo de proceso. Se deberá obtener el tiempo de proceso de cada una de las operaciones del sistema, así como el tiempo global del mismo, en


función de los volúmenes de información y la complejidad del proceso, con el fin de determinar el tiempo estimado para la obtención de resultados en el nuevo sistema y encontrar medidas de mejoramiento.

Distribución de resultados o documentos. Se deberán investigar los departamentos o personas usuarias de los resultados o documentos obtenidos en el sistema, así como la utilización de los mismos para prever mayor efectividad en las consecuencias de su uso.

Tiempo de respuesta. Debe obtenerse el tiempo de respuesta del sistema para cada uno de sus usuarios, con el fin de mejorarlo en el nuevo sistema.

Muestreos. Debe estimarse el volumen de datos que intervienen, la complejidad del proceso y las variaciones que tenga, para tomarlo como un argumento de importancia en el mejoramiento del sistema por diseñar.

Recursos. Deben tomarse en cuenta los recursos tanto humanos como materiales con que cuenta el sistema actual, para proyectarlos en las necesidades del nuevo sistema, por supuesto, bajo un esquema de simplificación, para que tenga sentido la automatización.

Costos. Este aspecto deberá ser lo más real posible, lo cual está en función de los recursos considerados tanto para el sistema actual como para el nuevo, y será la guía principal en el estudio de costo-beneficio del sistema por diseñar.

Evaluación de la investigación

Análisis de la información recopilada

Esta etapa del análisis es primordial, pues es donde se va a evaluar el sistema que se investigó; por ello deberá integrarse toda la información recopilada durante la investigación. Una vez integrada, deberá estudiarse cada uno de los aspectos que componen la investigación, para determinar la operatividad de dicho sistema, y en Función de esto, proponer mejoras al mismo y determinar la factibilidad de su automatización y; en su caso, la conveniencia.

Por lo anterior, puede observar que lo realizado en la investigación es fundamental para la evaluación; por lo que, si durante la investigación realizada no se consideró algún aspecto detectado en esta evaluación, deberá volver a investigarse cada caso.

Documentación de la investigación

Para poder evaluar adecuadamente un sistema investigado, deben considerarse los siguientes puntos:

Diagrama de flujo de la información analizada. Consiste en diagramar el flujo de la información del sistema actual, indicando todas


las operaciones que se realizan dentro del mismo, así como las áreas responsables de cada actividad. Para este tipo de diagrama es recomendable utilizar el denominado interdepartamental, en el cual se distinguen las distintas operaciones que sobre los documentos o información se van desarrollando de un departamento a otro.

Descripción del diagrama. Debe contener el detalle de todas y cada una de las actividades que se efectúan en el sistema, las cuales se investigaron durante el recorrido de la información. También deberá cubrir las variaciones detectadas en dicho recorrido. La descripción de las actividades debe tener el orden con el cual se efectúan en el sistema, para que tenga secuencia lógica.

Estructura organizacional analizada. Este punto de la docu- mentación deberá contener la estructura observada durante la investi- '

gación, y habrá que destacar si existe una diferencia con lo visualizado durante las entrevistas o documentación existentes. Los puntos que deben considerarse en esta estructura son:

Organigrama de la unidad usuaria:

- Estructura jerárquica. - Funciones.

Recursos existentes:

- Humanos. - Materiales.

Estos recursos deben estar relacionados con el organigrama de la unidad usuaria y así evaluados por si hubiera un exceso.

Objetivos determinados. Estos deberán ser documentados y serán los señalados por los directivos de la unidad usuaria. En muchas ocasiones, los objetivos no son logrados realmente; en ese caso, deberán señalarse por escrito las diferencias detectadas durante el trabajo de investigación.

Es posible que los objetivos que persiguen los directivos no sean bien trasmitidos en otros niveles y que por eso estén desvirtuados y afectando o compliquen algunas operaciones.

Normas y políticas determinadas. Al igual que en el punto anterior, éstas deberán quedar señaladas en la documentación según fueron interpretadas por los directivos.

Las normas y políticas pueden ser aún más desconocidas o mal entendidas que los objetivos, por ello deberá documentarse toda discre- pancia encontrada al respecto durante la investigación. Bien pudiera ser la causa de la inefectividad del sistema actual y el origen de su alto costo.

CAF! 21. ANÁLISIS, DISENO Y MANTENIMIENTO

Anexos (documentos recopilados, catálogos, etc.). Durante la investigación deberá recopilarse toda forma preimpresa o reporte utilizados en el sistema, los cuales deberán documentarse en relación con el diagrama de flujo de información. Si es posible, señalar en dichos ejemplares la información con que se llenan, la razón y su consecuencia.

Propuesta para mejorar el sistema. Durante la investigación y recorrido de la información recopilada, el analista de sistemas debe percatarse de las fallas del sistema vigente, para proponer mejorarlo en los siguientes aspectos:

Información fuente. Pasos innecesarios o duplicados. Funciones clave. Procedimientos críticos. Utilización correcta de resultados. Objetivos, políticas y necesidades de la empresa o institución actuales. Recursos humanos y materiales necesarios para emprender un esquema de modernización. Costos y beneficios que justifiquen la inversión.

Propuesta de factibilidad de automatización. Después de haber efectuado la investigación y el recorrido de la información, el analista deberá evaluar el sistema tradicional tomando como partida su transformación para ahora encauzar su potencial hacia las nuevas estrategias de servicios o negocio dadas las nuevas realidades de competencia de hoy.

Diseño del sistema

Durante el diseño del sistema, el trabajo del analista consiste en elaborar una o más opciones de automatización del sistema que va a cumplir con los requerimientos de información de la unidad usuaria.

En la formulación de opciones de un sistema propuesto debe considerarse muy importante la investigación realizada, así como su evaluación, ya que depende de la comprensión y del conocimiento de los procedimientos y problemas del sistema vigente para formular la opción del sistema propuesto para su aprobación.

Cuando se diseña un sistema de procesamiento de datos, debe considerarse sobre todo el perfeccionamiento de las operaciones y la reducción de los costos, así como la oportunidad y calidad de los resultados. Algunos de estos objetivos son los siguientes:

a) Estandarización de procedimientos de las unidades. b) Eliminación de funciones innecesarias.

w -

1 SUGERENCIAS DE SOLUCI~N

c) Eliminación de reportes, registros y formas innecesarios. d) Eliminación de datos superfluos. e) Establecimiento de los controles necesarios y simplificación de los

excesivos. f ) Eliminación de duplicación de funciones. g) Eliminación de duplicación de objetivos. h) Eliminación de duplicación de operaciones. i) Eliminación de duplicación de informes y formatos. j) Facilitación del flujo de trabajo y eliminación del desorden delmismo. k) Oportunidad de los resultados. 1) Calidad de los resultados.

m) Utilización efectiva de los resultados. n) Pero sobre todo, diseñar la nueva estrategia operativa en torno al

uso de tecnología y de procesos completos de información.

Un aspecto importante en el diseño de un sistema es aprovechar al máximo los recursos con que cuenta la infraestructura informática que se va a utilizar. Por tanto, es necesario que el analista conozca las facilidades de cómputo y comunicaciones que tiene a su disposición, tanto en hardware como en software.

Para el diseño de un sistema es de vital importancia desarrollar los siguientes puntos:

1. Estructura del sistema.

Objetivos y políticas del sistema:

- Objetivo general. - Objetivos particulares. - Políticas del sistema.

Resultados por obtener. Operaciones por realizar: manuales, sernirnanuales y electrónicas. Insumos del sistema. Usuarios. Recursos. Proveedores de los recursos. Componentes del sistema: operacionales, apoyo y regulación.

2. Diagramación.

Diagrama general del sistema. Diagrama de captación de información. Diagrama operativo del usuario.


Diagrama de procesamiento electrónico. Tablas de información y de decisiones.

3. Evaluación del diseño.

Sensibilidad. Restricciones. Adaptabilidad. Colapso. Puntos de control. Disponibilidad de recursos. Estrategia de implantación.

4. Presentación del sistema.

Estructura del sistema

El inicio del diseño de un sistema es desarrollar la estructura del mismo; se debe considerar como estructura de un sistema el agrupamien- to ordenado de todos los elementos de éste, los cuales son los siguientes:

Objetivos y políticas del sistema. Con base en la investigación realizada, y en la evaluación de la misma, donde se determinó el objetivo general y los objetivos particulares de cada fase, deberán agruparse en orden de importancia todos y cada uno de ellos, así como las políticas y normas que lo regirán. Estos objetivos y políticas serán la base para el diseño del sistema:

Objetivo general. Por ser lo primordial, marcará la pauta de todo el sistema. (Por ejemplo: que la recaudación fiscal abarque al menos 80% de los contribuyentes. Objetivos particulares. Son aquellos que cubren un fin específico dentro de todo el sistema, y el conjunto de ellos debe lograr el objetivo general. (Por ejemplo: lineamientos y formatos para recau- dación; formas de cobranza; contabilización de lo recaudado, destino y control de lo recaudado; etc.) Políticas. Son aquellas que reglamentarán el sistema; asimismo, marcarán sus límites, alcances y correlaciones con otros sistemas.

Resultados por obtener. Van en función de los objetivos del sistema, los cuales ya fueron determinados por las autoridades usuarias del sistema; además, deben estar documentados.

En esta etapa, el analista puede sugerir otros resultados que no sean los solicitados. Estos resultados serán creatividad del propio analista, ya que con el conocimiento que tiene del sistema, debe considerarlos, siempre y cuando

tanto, al diseñar el sistema deberá hacerse en relación con los resultados fijados durante el análisis.

Operaciones por realizar. En el diseño del sistema es importante considerar todas las operaciones que tengan que realizarse, ya que son parte importante en el mismo. Las operaciones que intervienen en un sistema son básicamente:

Manuales. Semimanuales. Electrónicas.

Estas operaciones deben estar bien definidas, indicando quién o quiénes las tienen que efectuar.

Insumos del sistema. Es indispensable saber dónde se originan las fuentes del sistema (éstas ya debieron ser detectadas en las investigaciones), para considerarlas en el nuevo diseño y determinar cómo y dónde se origina la información que, una vez procesada, dé los resultados deseados.

Usuarios. El conocimiento del ambiente de los usuarios del sistema por diseñar es importante porque en un momento dado deberá establecerse contacto con ellos, pues serán los usuarios quienes utilicen Ios resultados, y por supuesto, quienes saben para qué los quieren.

Recursos. Éstos deberán ser conocidos y tomados en cuenta para el diseño del sistema por automatizar. Aquí se consideran recursos humanos, materiales y económicos.

Proveedores de los recursos. Deberá reconocerse cuáles son los departamentos que proporcionan los recursos, para responsabilizar a cada uno de ellos a la hora de integrar los mismos.

Componentes del sistema. Como ya se indicó anteriormente, éstos son los que integran la estructura de un sistema, los cuales pueden ser los siguientes:

Operaciones: procedimientos, entradas y salidas. Apoyos: servicios, recursos tecnológicos. Regulaciones, ya sea internas: objetivos, políticas, criterios, puntos de control y decisiones; o externas: cambios legales, relaciones con otras empresas, convenios con el gobierno, cambios de moneda, inflación, etcétera.

La diagramación es una herramienta esencial para diseñar un sistema, ya que en ella se especifican gráficamente las actividades por realizar dentro de él, así como la secuencia de las mismas y quién las debe ejecutar. Por tanto, una vez estructurado el sistema, la diagramación

es el planteamiento de cómo se va a desarrollar éste. Debido a los flujos de datos que usualmente intervienen en los sistemas manejados en este medio, se ha generalizado el uso de los siguientes diagramas:

Diagrama general del sistema. Aquí se indica el flujo de la in- formación, donde se separan en cada columna los procesos por desarrollar correspondientes a cada departamento que interviene en el sistema. En cada proceso se describe de manera breve la actividad por desano- llar, indicando gráficamente qué información entra y cómo sale del proceso.

Diagrama de captación de información. Aquí se indican los pasos para h captación de información y los formatos donde se asienta, señalando las fuentes, así como 10s destinatarios de la información trans- crita y los puntos de control específicos de cada procedimiento.

Diagrama operativo del usuario. Existen dos tipos de usuarios: el que únicamente utiliza los resultados del sistema y el que, además, ajusta la información.

En general, este diagrama sólo indica las actividades que realiza el usuario para adecuar la información que entra al sistema y/o la distribu- ción de los resultados obtenidos en el mismo. Es importante, como consecuencia de este diagrama, que todas las actividades por desarrollar queden bien establecidas por los usuarios y que las respeten; de lo contrario, se corre el peligro de que el sistema no cumpla con los objetivos establecidos.

Diagrama de procesamiento electrónico. Este tipo de diagrama es un grupo de símbolos preestablecidos que representan las operaciones en el centro de computación. Estos símbolos se conectan por medio de flechas que indican la secuencia de las operaciones. El diagrama es el plan maestro de los procesos en la computadora; en él se muestran las entradas, las salidas y los procesos que se llevan a cabo para producir las diferentes salidas. Es una representación gráfica del flujo de los datos, a través de todo el proceso electrónico. Para diseñar el flujo electrónico deben considerarse los siguientes aspectos:

Configuración del equipo. Éste deberá tomarse en cuenta con el fin de utilizarlo adecuadamente y optimizar cada uno de los pasos del sistema dentro de la computadora. Las características por considerar son las siguientes:

Capacidad de memoria (relacionada con el nivel de multipro- gramación). Sistema operativo (relacionado con las facilidades técnicas). Periféricos (relacionado con la capacidad de almacenamiento de datos).

Organización de archivos. En este aspecto, el analista debe investigar y evaluar para determinar la organización de archivos adecuada al sistema, dependiendo de las características del mismo; existen las siguientes organizaciones de archivos:

Secuencial. Indexada. Directa. Relativa. Particionada. Tablas de memoria. Bases de datos.

Correlación con otros sistemas. El analista debe tener conocimientos de las funciones de otros sistemas para:

Utilizar archivos ya creados. No duplicar resultados. Proporcionar información a otros sistemas.

Compatibiíidad con otros equipos. Esto está orientado básicamente al soporte en otros equipos para la operación continua del sistema cuando ocurran descomposturas o siniestros en el equipo de cómputo propio.

Programas de utilidad. El analista deberá conocer los programas de utilidad existentes en el centro de procesamiento, con el fin de utilizar- los y evitar redundancia de Dronramas, los más comunes son:

Sort. Merge. Selector. Impresor. Rutinas especiales de uso común.

Lenguajes. Es obligación del analista estandarizar los lenguajes de programación para el desarrollo del sistema, así como certificar la habilidad del personal de programación para el manejo de los mismos. Entre los lenguajes más usados están:

Cobol. Assembler. Teleproceso (macros). PL/1. RPG. Fortran.

Basic. Lenguaje 'C". Excel. Dbase.

Tablas. Es conveniente, si es posible, aprovechar el uso de tablas en el sistema; básicamente existen dos tipos de tablas:

Tablas de decisión. Es un elemento gráfico en forma de matriz, que va a determinar la acción por realizar en función de un determinado problema, dependiendo de la condición presentada. Tablas de información. Es también una matriz, pero a diferencia de las anteriores, aquí se consulta información en vez de tomar una acción.

Evaluación del iiseño

Al terminar el disefio del sistema, y antes de presentarlo a conside- ración de los funcionarios que lo vayan a aprobar, el analista debe evaluar su propio diseño utilizando pruebas de escritorio; una vez realizadas éstas, presentarlo al grupo de analistas designado para el conocimiento y crítica constructiva del mismo, para que a su vez, con estas observaciones determine los siguientes puntos de evaluación:

Sensibilidad. Se caracteriza por detectar fácilmente las variaciones no comprendidas en el sistema.

Restricciones. Se refiere básicamente a las limitaciones del sistema, en cuanto a sus objetivos y políticas definidas para él.

Adaptabilidad. Es la orientación que debe darse al sistema, para operarlo en distintas instalaciones del usuario (en caso de existir). Desde luego, esto depende de los objetivos propios de la institución y del sistema.

Colapso. Se refiere a determinar el punto o parte del sistema en donde no pueda soportar más variaciones de operación, apoyo o regulación; esto origina que se desvirtúe el sistema.

Puntos de control. Básicamente deberán existir puntos de control en las interfases de la operación del sistema, con lo cual deben determinarse cuáles son esos puntos de control y cuáles son las correcciones a las variaciones detectadas por medio de ellos.

Disponibilidad de recursos. Aquí se debe tomar en cuenta qué recursos es posible utilizar para el desarrollo del sistema, y qué disponibilidad existe para contar con ellos en el momento adecuado.

Posibilidades de implantación. Esencialmente este punto está orientado a determinar las posibles opciones de implantación, las cuales dependen primordialmente de tres elementos: tiempo, recursos y costos.

Presentación del sistema

Una vez diseñado y evaluado el sistema, se debe presentar a con- sideración de los funcionarios correspondientes para su aprobación o ajuste. La forma de presentación del sistema depende de los recursos con que se cuente para ello, los más utilizados son los siguientes:

Transparencias y películas. Flip chart (hojas grandes, un caballete). Material para proyectar cuerpos opacos. Material para proyectar cuerpos transparentes. Material adherible para Franelógrafos. Figuras imantadas para pizarrones o superficies. Cartulinas o cartones ilustrados. Carpeta de presentación (hojas cambiables, de tamaño más pe- queño a las utilizadas en el caballete). Presentación por medio de PC.

De no contar con los recursos descritos, se puede auxiliar de un pizarrón, utilizando de preferencia plumones de colores.

Es importante contar con una documentación que respalde esta presentación, la cual debe contener lo siguiente:

Introducción. En la que explica, en forma breve:

Razones por las que se decidió efectuar el estudio de factibilidad de diseño e implantación del nuevo sistema y quién lo solicitó. Indicar el objetivo general del nuevo sistema. Descripción general de las opciones de implantación.

Objetivos del sistema. Describir en forma breve los objetivos, tanto generales como específicos, del sistema, los cuales debieron ser fijados por los altos funcionarios.

Diagrama de flujo de la información del sistema. Deberá ser una representación gráfica con la que cualquier persona de cierto nivel comprenda el flujo de la información; es recomendable utilizar dibujos y/o esquemas ilustrativos.

Ventajas operativas, administrativas e informativas. Describir brevemente las ventajas más importantes del sistema, tanto las operativas como las administrativas. Estas ventajas deberán estar en relación con el sistema actual; o bien, si los dos sistemas se asemejan en algunas ventajas, indicar en forma concisa las diferencias, si es que las hay.

Información por procesar. Indica las distintas fuentes de informa- ción y su contenido, lo cual muestra a los funcionarios el tipo de información con que se cuenta para la obtención de los resultados.

258 CAE! 21. ANALISIS, DISENO Y MANTENIMIENTO

Resultados por obtener. Indicar cada uno de los resultados más importantes que se van a obtener con el sistema. Se debe especificar la utilidad de cada uno; algunos serán autoexplicativos.

Proyecciones a füturo. Indicar en forma concisa lo que el sistema, después de implantado, puede absorber o crecer, lo cual depende de las necesidades que se presenten a futuro.

Conclusiones. Deberá indicarse la importancia que representa para el usuario el buen £un- cionamiento del sistema por implantar y las consideraciones necesarias para el logro de ello, como apoyo, vigilancia, manejo adecuado, etcétera.

Elementos necesarios para la implantación del sistema. Deberán indicarse en cada una de las opciones presentadas los recursos humanos y materiales necesarios para la implantación del sistema, tanto en procedimientos manuales como electrónicos.

Diagrama general del sistema. Es la presentación gráfica de cada una de las fases del sistema, en forma general, donde se especifican y deslindan las responsabilidades y actividades de cada uno de los departamentos que deberán intervenir en el sistema.

Descripción del sistema. Describir cada una de las fases por realizar, qué tipo de información entra, dónde se obtuvo y qué resultados produce esta fase. Se deberá empezar con la acción por realizar más importante.

Tiempo probable de implantación. Se debe considerar el tiempo probable de implantación, representado por un calendario de trabajo, donde se señalen las actividades, la duración y las fechas de cada una, así como los responsabIes de su desarrollo.

Anexos. Aquí se integran las formas utilizables para la captación de información, documentos fuente y ejemplos de cada uno de los resultados por obtener.

Además de la documentación, deben considerarse los siguientes aspectos, para el desarrollo de la presentación:

a) Preparación:

Fijar objetivos. Clarificar el alcance de la presentación. Organización. Deberá organizarse el material de apoyo para la presentación, así como la secuencia del mismo. Simplicidad. Se deberá simplificar lo más posible. Definición. Habrá que utilizar la terminología adecuada con los participantes y, en su caso, definir los términos técnicos utilizables. Analogías. Entre más abstracto sea el contenido, más analogías se necesitan. Conocimiento. El conocimiento total del sistema es indispensable para su presentación, ya que ello dará confianza al analista y podrá responder a las preguntas que se le planteen.

SUGERENCIAS DE SOLUCIÓN 259

b) Presentación. Ésta depende de la habilidad del expositor. Se consideran los siguientes aspectos:

Autoridad. Los participantes deberán tener en cuenta que el expositor cuenta con autoridad Frente a ellos, respaldado por su competencia, sinceridad e integridad y sobre todo por el conocimiento del sistema. Contacto visual. Se debe ver a todos los participantes, esto dará una id$a al expositor de cómo adaptarse a las necesidades de ellos. Voz. Esta deberá ser adecuada, debe ponerse énfasis y hacer las pausas que destaquen ciertos puntos de la presentación. Escritura. Se deberá escribir con letra grande y espaciada, así como suprimir,lo innecesario. Movimientos. Estos deberán estar bien calculados, procurando no distraer la atención de los participantes. Bien empleados, pueden ayudar a subrayar lo que se está explicando. Participación. Durante la presentación, procurar que los participantes intervengan en la misma; para esto, hay que considerar los siguientes elementos:

- Humorismo. Relaja a la gente y ayuda a producir una atrnós- fera agradable, donde los participantes se sienten libres para exteriorizar ideas y formular preguntas.

- Contestar. El expositor debe evitar contestar mucho o con brusquedad. Debe dialogar con todos los participantes, cuidando de no convertir la presentación en una plática generalizada.

NOTA: Se destaca que el conocimiento total del sistema es indispensable para su presentación, ello dará seguridad al analista, quien obtendrá la confianza del auditorio.

IWLANTACI~N DEL SISTEMA

En esta parte se hará referencia únicamente al sistema electrónico, ya que el sistema aprobado puede ser de otro tipo, en cuyo caso, la labor del analista termina en las opciones que expuso.

Una vez aprobado el sistema propuesto, se diseñará con detalle cada paso, tomando en consideración las observaciones que se hayan hecho al sistema durante sus presentaciones.

Otros aspectos por considerar son: la preparación de los elementos humanos que intervendrán en cada una de las actividades que requiere el proyecto; los recursos con los que se decidió implantar el sistema, así como las características del equipo por utilizar, para aprovecharlo

260 CAP 21. ANALISIS, DISENO Y MANTENIMIENTO

mejor. La implantación es la fase donde se pone en práctica el concepto teórico de un sistema, es la más objetiva del desarrollo; es la culmina- ción de actividades como planeación, análisis, diseño y programación del nuevo sistema. Es la parte en la que el analista debe demostrar su habilidad y conocimientos para lograr el máximo aprovechamiento y efectividad de todos los recursos humanos y materiales, mediante una coordinación precisa y cuidadosa.

Lo anterior requiere el conocimiento completo del sistema, pero esto no quiere decir que él lo tenga que hacer todo, sino que mediante bases de planeación y estructura organizacional debe delegar en otras personas ciertas funciones de detalle.

Entre las funciones de la implantación por realizar están las siguientes:

Uso de la diagramación

Como ya se dijo, habrá que considerar las observaciones hechas al sistema durante las presentaciones, y esto deberá reflejarse en los diagramas utilizables en tal sistema.

Diagrama general

Este diagrama especificará en forma muy general el recorrido de la información, indicando las áreas internas y dependencias externas que intervendrán en el sistema.

Diagrama particular de procedimientos manuales

Este diagrama es el desglose específico de las actividades por realizar correspondientes a cada área usuaria, primordialmente en lo que se refiere a captación de información (codificación y realimentación de información) y uso de cada uno de los resultados por obtener en el sistema. Por otro lado, el diagrama también comprende las actividades de conversión de información fuente a medio procesable.

Diagrama de procesamiento electrónico

Es la representación gráfica del flujo y proceso de la mformación en una computadora para obtener los resultados previstos en el sistema. La conformación de este procesamiento dependerá por un lado del tipo y

configuración del equipo de cómputo y, por el otro, de la calidad del personal con que se cuenta en programación. Por último, debe considerarse la no saturación del equipo con un solo proceso.

Definición de programas

El momento en que se debe iniciar la programación es determinante. Al llegar a este punto, el diseñador ha invertido meses de tiempo y esfuerzo en la investigación y diseño; sin embargo, durante el diseño cualquier cambio, cualquier factor descuidado previamente, por lo general no causa retrasos o riesgos; normalmente todo lo que se requiere para rectificar el caso es adicionar una nota de algún registro, cambiar una anotación en el diagrama de proceso, o dar de baja una línea del esquema. No obstante, en el momento de empezar la programación, cambia el panorama. El analista es el responsable de cuidar que los programas desarrollados estén de acuerdo con las especificaciones de los procesos diseñados.

Es importante saber que es fácil hacer cambios en el sistema antes de programarlo, pero una vez hecho, cualquier cambio se dificulta; esto significa que el sistema propuesto debe estar correcto y completo antes de pasar las definiciones a la fase de programación. Por tanto, la definición de los programas del sistema deberá hacerse una vez que se tenga en forma detallada el diagrama de procesamiento electrónico, y que el analista esté totalmente seguro de los objetivos del sistema, así como de lo que va a hacer cada uno de los programas que intervienen en el mismo.

Para llevar a cabo las definiciones de cada uno de los programas es conveniente que el analista se apegue a los siguientes puntos:

Elementos para la dehición de un programa

Identificación. Estará formada por los siguientes datos:

Nombre del sistema y subsistema. Nombre del analista. Clave del programa. Fecha.

Objetivos. Contendrá una explicación concisa de los resultados que se obtendrán en dicho programa y la relación, si la hay, con otros programas.

262 CAE 21. ANÁLISIS, DISENO Y MANTENIMIENTO

Entradas. Aqeií se proporciona la información genérica con las características de los archivos de entrada, tales como:

Nombre externo del archivo. Posiciones por registro. Factor de bloque o registros por bloque. Dispositivo o dispositivos que lo contienen. Posición por la que está clasificado (si está clasificado). Organización. Llaves de acceso. Método de acceso. Tipo de etiquetas. Nombre interno. Número de volumen de dispositivo.

En caso de existir una clasificación previa, la cual se utilizará en el proceso, deberá especificarse la llave de clasificación y los niveles de la misma, referidos al nombre o nombres de los campos, así como las posiciones relativas dentro del registro de datos. Invariablemente se anexará un formato correspondiente a cada uno de los archivos de entrada, en donde se detallarán las posiciones que ocupa cada campo, así como el tipo de caracteres que contiene cada uno (numérico, alfanumérico, alfabético, etc.).

Si el programa utiliza lectura de parámetros, deberá precisarse. En esta sección de entradas deberá anexarse por separado el formato de los parámetros, así como las especificaciones, claras y precisas, donde se explique el uso de todos y cada uno de los parámetros. Cuando el programa requiera armar una tabla, es necesario proporcionar el núme- ro de elementos que la constituirán, así como el formato de los mismos, mencionando la necesidad de por qué se definió.

Salidas. Su contenido es similar a lo expuesto en el párrafo de entradas, salvo para resultados por impresora, en cuyo caso deberá anotarse la clave de la forma de papel que se utilizará, número de tantos, si la impresión es a sextos u octavos y parámetros de control de saltos de impresión.

En lo que respecta a formatos de registro, lo especificado para archivos de salida.

Proceso. Esta parte de la definición de un programa es la que normalmente presenta una mayor dificultad para su realización y entendimiento; esto se debe principalmente al hecho de pretender decir cómo se quiere hacer, y por consiguiente no se atiende lo que se desea que el programa haga. La descripción del proceso debe ser lo más simple posible, atendiendo con precisión los resultados deseados. Esta descrip- ción atenderá lo siguiente:

Procesos de conversión y depuración. En este tipo de procesos es frecuente que sólo se depuren los campos considerados como informa- ción básica, descuidando el resto de los campos. Por consiguiente, sugerimos que este tipo de programas hagan una depuración más exhaustiva de todos y cada uno de los campos que integran un registro de información. Con esto se evita que en programas subsiguientes, ya sean de la propia aplicación o de otra conexa, haya la necesidad de depurar información. De igual forma, es conveniente que no se rechace un registro a la primera inconsistencia detectada, sino que la depuración debe continuar hasta agotar ese registro, marcando todas y cada una de las inconsistencias detectadas. Esto evita correcciones parciales y, por consiguiente, la realimentación de la misma información más de una vez.

Especificación de campos por procesar. Cuando se haga referencia a los campos sujetos al proceso, deberán corresponder, tanto la descrip- ción del campo como las posiciones que ocupa dentro del registro, a las especificaciones en el formato de registro.

Es Frecuente el error de no correspondencia entre nombres y posiciones por fallas de transcripción mecanográfica, por esto es recomendable que el analista cuide esos detalles.

Procesos de datos clasificados. Cuando la información se presenta clasificada, con el propósito de producir uno o más cortes, o bien acumulaciones de información que corresponden a la misma llave de clasificación, es importante que se den los criterios para que, al verificar la secuencia, e1,programa tenga la opción de tratamiento en caso de inconsistencia. Esta puede ser fuera de secuencia, registros duplicados o especificación de que el archivo no está clasificado.

Debe insistirse en que para procesos de corte y10 acumulación por llave de clasificación siempre deberá verificarse la secuencia y, en tal sentido, también se especificará el orden de clasificación de la información; lo mismo procede para cruces de archivos clasificados que pretenden complementar información y/o actualización.

Cruces de archivos para actualización y/o complementos de infor- mación. Aparte de lo expuesto en el párrafo relativo a información clasificada en este tipo de procesos, es importante dar los criterios para cuando la información no encuentra correspondencia en uno o más de los archivos objeto del proceso. Nunca debe presuponerse que toda la información encuentra correspondiente; o que un archivo se termina primero que otro, o bien que el programador tiene los antecedentes para dar un tratamiento adecuado a esta información, ya que sólo producirá resultados inadecuados. Por lo anterior, el analista deberá dar siempre, por escrito, los criterios para el tratamiento de estos casos.

Rutinas de cálculo. Para toda rutina de cálculo el analista debe proveer, dentro de la definición, las fórmulas matemáticas mediante las

cuales se llega al resultado deseado. Lo anterior es más claro y preciso que pretender describir en forma literaria dichas fórmulas.

Se debe poner atención a los campos numéricos con los cuales se van a hacer las operaciones, sobre todo con aquellos que podrían ser negativos, esto último con frecuencia pasa inadvertido en las definiciones. Cuando los campos numéricos por procesar no se hayan depurado previamente, es indispensable hacerlo saber en la definición del programa, para lograr resultados oportunos y adecuados con dicho programa.

Condiciones de excepción. Todas las condiciones previsibles de excepción que sean del conocimiento del analista se deben poner en la definición. Ejemplo: si un programa procesa registros tipo 1, 2 y 3, deberá preverse qué hacer cuando un registro no sea ni 1, ni 2, ni 3.

Programas con dos o más opciones. En estos casos deberá ponerse atención en no hacer confusa la definición, procurando dejar independiente cada opción y dando marcada preferencia a la manera en que el programa optará por alguna de sus opciones; en otras palabras, deberá especificarse e1 método de selección de la opción. Las opciones serán dadas por parámetros de control.

Debe adicionarse todo comentario útil que sirva para aclarar conceptos o dar una idea del tipo de información que se ha de procesar; será de gran ayuda, tanto para el programador como para los analistas que tengan que realizar trabajos futuros de mantenimiento con dichos programas.

Cifras de control. Esta parte de la definición requiere mucha atención por parte del analista; se debe cuidar especialmente que las cifras de control cubran su principal objetivo: controlar los resultados de1 programa. Esta valiosa herramienta, por lo general, no se usa en forma adecuada, resultando a veces muy problemático o imposible cuadrar dichas cifras de control.

Otra gran dificultad que presentan en su mayoría las cifras de control es que no se proporcionan criterios que permitan establecer la relación entre las mismas; por tal motivo, en muchas ocasiones sólo la persona que definió el programa sabe en qué forma se verifican esos resultados, lo cual en un centro de procesamiento no es recomendable. Por lo anterior, se sugiere:

~ e a l & a r un estudio detallado de las cifras de control del programa para que sean contabilizados todos los registros de1 proceso. Proporcionar el número de posiciones de que constará cada cifra de control, ya que es el analista quien conoce los volúmenes por procesar, evitando con ello el sobrepeso de los contadores correspondientes. Anteponer una letra o combinación de letra y número a la leyenda correspondiente a cada una de dichas cifras; así será más fácil

establecer por medio de una fórmula la relación entre ellas. Como ejemplo se muestra la siguiente situación:

A: Registros leídos B : Registros tipo 1 C : Registros tipo 2 D : Registros tipo 3 E: Registros sin tipo F: Registros erróneos

F 1: Tipo 1 F 2: Tipo 2 F 3: Tipo 3

G : Total grabados H : Registros maestros grabados 1: Registros detalle grabados

Fórmulas de verificación:

Sugerencias acerca de la elaboración de programas

Para que el programador realice una prueba eficiente del programa es indispensable que el analista provea a aquél de criterios para elaborar datos prueba, de modo que cubran todas las condiciones que debe prever el programador, como casos de excepción, exclusión, Fuera de secuencia, inconsistencia, etc.; ya que cuando se deja a criterio del programador, normalmente probará condiciones simples o la rutina principal del programa. Debe entenderse que lo que se pide son criterios para elaborar la prueba, los cuales, para una mayor eficiencia, será necesario proporcionarlos por escrito; con ello, el analista estará en condiciones para certificar el buen funcionamiento de dicho programa.

Existen analistas cuyo conocimiento de la aplicación a su cargo les permite concluir la solución de un problema mediante la definición de un solo programa que cubre múltiples opciones y de uso simultáneo de varios dispositivos periféricos, donde se logran obtener los resultados requeridos. Sin embargo, el problema surge cuando:

CAF! 21. ANALISIS, DISEIÚO Y MANTENIMIENTO

Se va a actualizar dicho programa. Quien lo realizó ya no trabaja en la institución.

Además, complica la operación de la computadora, cuando bloquea equipo periférico para otros procesos. Por tanto, si se toma en cuenta el sistema operativo y el equipo disponible, así como la futura depuración y mantenimiento de los actuales sistemas, se sugiere que mejor se busque la posibilidad de producir dos o más programas, que serán más fáciles de realizar, actualizar y mantener, y que también darán una mayor oportunidad de que los analistas que en el futuro atiendan dichas aplicaciones, adquieran en un menor tiempo el conocimiento de los programas correspondientes, tanto en su lógica como en el tipo de resultados que arrojan.

Con el propósito de estandarizar la terminología, se debe entender por:

Modificación. Todo cambio que en mayor o menor grado afecta la definición original de un programa cuando éste aún se encuentra en fase de elaboración o prueba. Actualización. Todo cambio a un programa que ya ha estado en producción.

Para estos casos, lo más importante es que la actualización o modificación se presente siempre por escrito, con fecha, y forme parte de la definición original por medio de hojas anexas, las cuales, para mayor claridad, deberán mencionar la página y10 párrafo que afectan de la mencionada d e h c i ó n original, o bien, las modificaciones o actualizaciones previas. Lo importante es que haya antecedente.

Es importante que el analista dé una plática sobre los objetivos del sistema a los programadores que intervinieron, pues tiene gran trascendencia para la persona conocer cuáles son las áreas de afectación con el trabajo por ellos realizado. Lo anterior obedece al principio establecido en las relaciones de trabajo, que dice: "Todo empleado debe conocer la importancia y alcances de su trabajo en forma integral." Además de lo anterior, cabe mencionar la importancia de los siguientes puntos.

Relación entre programadores y analistas. Una vez estudiada la definición por el programador, deberá establecerse una plática o serie de pláticas con el analista. Esto es para que el programador certifique que la definición del programa ha sido entendida o para que se disipen las dudas que tenga. Si estas pláticas no se hacen oportunamente, retrasa- rán la entrega del programa.

Revisión y aprobación de los programas en h c i ó n del tiempo. Una vez que el área de programación entregue los programas al analista, es

recomendable que éste efectúe la revisión de todos los productos lo más pronto posible, y que no espere a que se efectúen las pruebas de volumen correspondiente, para que el programa sea aprobado o recha- zado, ya que la demora al revisar el programa trae como consecuencia que el programador que lo hizo, lo olvide, o que ya no trabaje en la institución.

Trabajos urgentes. En este tipo de trabajos no deberán pasarse por alto las definiciones por escrito de los programas, ya que la experiencia nos dice que cuando no existen definiciones, ocurren malas interpreta- ciones y, como consecuencia, no se obtienen los resultados deseados.

Acceso a los programas fuente. Este acceso sólo deberá efectuarlo el personal del área de programación y ocasionalmente el personal de análisis.

Elaboración de programas. La elaboración de los programas la llevará a cabo el personal del área de programación, a medida que las definiciones les sean entregadas por el analista. Esos programas deberán reunir los requisitos establecidos; si no es así, deberán regresarlos de inmediato al analista, indicando las condiciones que no cumplen.

Revisión y aprobación de los programas. Esta etapa es una de las más importantes y de ello debe hacer conciencia el analista de sistemas, ya que de una buena revisión de los resultados de los programas depende en gran parte el éxito de un sistema, porque ello evita modificaciones o actualizaciones de los programas en la fase de operación del sistema, por razones de falla de programas o resultados erróneos.

La revisión de los programas, aunque es muy tediosa y aburrida, debe ser muy cuidadosa y tienen que verificarse todas las condiciones posibles, las cuales se deben plantear en los criterios de datos de prueba. El analista nunca deberá confiarse en que el programador haya probado tal o cual condición; deberá comprobarlo él mismo. Una buena revisión de los programas de un sistema se refleja en el manejo del mismo, es decir, durante dicha operación no existen modificaciones o actualizaciones de los programas; si existieran, serían por excepción y con plena justificación.

Pruebas de programas con información real. Para hacer este tipo de pruebas es recomendable que además de las pruebas de los programas con datos prueba, durante su elaboración se hagan otras, pero con información real. Esto se hace para depurar la programación que va a intervenir en el sistema. En este tipo de pruebas es recomendable que los datos que se seleccionen contengan la mayor variabilidad de condiciones posible, con el fin de probar a toda capacidad cada programa, y que los programas donde se detecte alguna anomalía sean modificados de inmediato; además, debe actualizarse la documentación correspondiente. Si se efectúan este tipo de pruebas en forma adecuada, los problemas que se presenten serán mínimos.

CAP 21. ANÁLISIS, DISENO Y MANTENIMIENTO

Pruebas del sistema. Al terminar la programación, el analista tiene ya un grupo de programas definido por él, todos los cuales se ajustan, unos a otros, para formar un sistema funcional. Es probable que debido a la carencia de comunicación, aun cuando se le definió al programador lo que se esperaba que hicieran los programas, éstos no estén de acuerdo con las necesidades del sistema; asimismo, la programación individual de dicho programa los puede hacer inconsistentes unos con otros, y en consecuencia, éstos, como un todo, no trabajen como un sistema completo.

Debe asegurarse que los programas probados por separado no contengan estas deficiencias y, por tanto, constituyan un sistema de proceso aceptable. Esto se obtiene con la prueba del sistema, en donde la secuencia de los procesos debe engranar perfectamente. La prepara- ción de datos es responsabilidad del analista; debe probar todas las opciones posibles para el sistema desde cualquier ángulo, para así detectar los errores que haya cometido el o los programadores.

La prueba del sistema es un procedimiento cíclico, en el cual los errores detectados requieren modificaciones a la programación, y una vez corregidos los programas problema, se procesa nuevamente el sistema para detectar cualquier error que no hubiera surgido antes. Si el sistema es muy grande (más de 100 programas), es conveniente que la prueba se realice por partes o subsistemas. Una vez eliminados los errores de cada uno de ellos, se podrá probar el sistema completo.

Las entradas y salidas en cada uno de los programas deben ser revisadas cuidadosamente, poniendo mayor atención al primero y último registros de cada archivo, ya que es ahí donde existen más errores. La documentación del sistema debe ser actualizada con todos los cambios que se hayan hecho durante estas pruebas. Las pruebas del sistema pueden ser piloto o en paralelo.

Pruebas piloto. Este tipo de prueba es el que se hace cuando no existe ningún sistema anterior contra el cual se comparen los nuevos resultados.

Pruebas en paralelo. Este tipo de pruebas se utiliza cuando anteriormente existía algún sistema con el cual se comparaban los resultados de uno nuevo. Estas pruebas, como su nombre lo indica, consisten en correr simultáneamente el antiguo y el nuevo sistema. El objeto del trabajo en paralelo de los dos sistemas es comprobar si el nuevo funciona con los mismos resultados que el anterior. En este tipo de pruebas deben participar todos los elementos que normalmente inter- vendrán cuando funcione el sistema en forma real.

Por lo general, para estas pruebas es inevitable un aumento temporal de personal, ya que se revisarán los resultados de dos sistemas en vez de uno; por ello, el diseñador debe advertirlo así al usuario. Tanto en la prueba piloto como en paralelo, es la ocasión para que se defina la

fuerza del trabajo manual que servirá en el sistema, así como para detectar errores, corregirlos y reiniciar los procedimientos que se proba- rán en su totalidad, y revisar las estimaciones de tiempos del sistema hechas originalmente, pero a un nivel más realista.

Revisión y evaluación del sistema. Una vez que se ha terminado con la prueba del sistema, el analista y el usuario deberán hacer una revisión y evaluación general de tal sistema en la cual consideren todos los procedimientos que intervengan en él, y comprobar si los resultados que se obtuvieron cumplen realmente con los objetivos establecidos en un principio, ya que en esta etapa se determinará en qué momento se libera el nuevo sistema.

Calendario de implantación. Es inevitable que cualquier sistema trabaje bajo un calendario de actividades elaborado previamente, en el cual se indiquen las actividades de cada uno de los elementos que intervendrán en dicho sistema, así como las fechas en las que deberán desarrollarse tales actividades. El analista del sistema debe elaborar este calendario y tomar en cuenta las necesidades del usuario, otros departamentos que intervengan y las cargas de trabajo en la computadora. Una vez determinado el calendario, es importante que lo aprueben todos los departamentos que intervendrán en las actividades. Cuando el calendario esté aprobado, deberá enviarse una copia a cada uno de los participantes en el sistema, para que las actividades que les correspondan se efectúen en los tiempos señalados.

La documentación adecuada y completa de un sistema que se desea implantar, mantener y actualizar en forma satisfactoria es esencial en cualquier sistema de información; sin embargo, con frecuencia es la parte a la cual se dedica menor tiempo y atención.

Toda persona dedicada a sistemas que haya recibido una solicitud para mantener o modificar un sistema, del cual no se tenga ninguna documentación y en donde la persona que lo diseñó ya no trabaje en la institución, entenderá el problema que representa un sistema en tal situación.

Muchas veces intentar retroceder y documentar un sistema, des- pués que ha estado en operación durante algún tiempo, es más costoso que hacerlo desde la primera vez, aun si se considera que el procedimiento de documentación original sea, de por sí, de alto costo. Este costo materialmente está determinado en mayor grado por el tiempo que el personal de sistemas dedique a la documentación, por lo que el propósito de este instructivo es establecer las normas de documenta- ción por escrito, lo cual reporta las siguientes ventajas:

2 70 CAF! 21. ANÁLISIS, DISEÑO Y MANTENIMIENTO

Estandarización de la documentación. Facilitación del desarrollo de la misma. Ahorro de tiempo.

Una vez que estas normas han quedado establecidas, es importante que se realice el esfuerzo necesario para ponerlas en práctica, puesto que, bajo estas bases, una buena documentación traerá consigo las siguientes ventajas:

Es una magnífica herramienta didáctica para nuevos miembros de la organización de sistemas, así como para nuevos usuarios del mismo. Es requisito básico para quien tenga la responsabilidad de su mantenimiento y/o modificación. Ayuda a los analistas de sistemas que trabajan en áreas relativas, evitando traslapes y redundancias, y facilita la integración a los diferentes sistemas. Asegura que el sistema se opere en forma correcta con e1 mínimo de errores. Se utilizan más eficientemente los recursos de que se dispone.

Si se considera que los sistemas deben cambiar, ya sea por una variación en las necesidades de información, una optimización de los sistemas, un cambio de objetivos o normas, etc., será necesario que la documentación sea actualizada por cada modificación, ya sea de diseño o de programación.

Si no se tiene actualizada, esta documentación pronto será obsoleta, y una documentación así es peIigrosa en extremo, tanto en lo referente a los errores que puedan producir en la operación de1 propio sistema, como por lo que respecta a los problemas que puedan resultar cuando se requieran modificaciones y los cambios previos no hayan sido documentados.

Otro aspecto importante es el nombre del sistema, el cual deberá ser único para cada sistema existente; dicho nombre deberá conservarse invariablemente en todos los documentos referentes a ese sistema, ya que será con ese nombre con el que se identificarán todos los procesos relacionados con éI.

Carpeta administrativa

Esta carpeta contendrá lo siguiente:

Índice. Enunciado de cada apartado de la carpeta. Resumen administrativo (introducción). Es una condensa-

ción de todos 10s demás puntos que se detallan en esa carpeta y cuyo propósito es permitir a los altos ejecutivos enterarse en forma somera de

los objetivos del sistema. Para elaborar este resumen no se establecen normas rígidas que limiten la capacidad de expresión de quien lo realice, excepto la recomendación anterior de ser lo más breve posible.

Plantedento. Esta sección tiene como finalidad dejar registra- dos los antecedentes que sirvieron como punto de partida para el desarrollo del análisis del sistema emprendido. Por esto se deben mencionar los siguientes puntos:

Unidad usuaria que requirió el sistema. Personas y/o los puestos ocupados por éstas en el momento de requerirse el sistema. Los térrninos y10 medios bajo los cuales se hizo el planteamiento del sistema (acuerdos, disposiciones legales, memoranda, etc.). Condiciones y criterios especificados que normaron el desarrollo del sistema. Fechas correspondientes a los puntos anteriores.

Objetivos y políticas. Aquí se dejarán establecidos los objetivos y políticas que debe cubrir el sistema en foma clara y precisa para evitar errores de interpretación. Para lograr lo anterior, se sugiere transcribir, o bien, anexar los documentos en los cuales los interesados fijaron dichos objetivos y políticas.

En virtud de que durante la realización de la investigación por parte del análisis del sistema pudieron surgir objetivos secundarios, se mencionan en esta misma sección.

Considerar que tanto los objetivos primarios como los secundarios fueron aprobados como tales por los interesados. Debe quedar perfectamente aclarada su prioridad; es decir, objetivos a corto plazo o inmediatos, y objetivos a largo plazo o mediatos, ya sean secundarios o primarios.

Entradas al sistema (información por captar). En este punto deben especificarse los documentos fuente que inician las operaciones del sistema, así como la información detallada de los conceptos que serán los datos de captación por el sistema. Es recomendable anexar una copia de todos los documentos.

Lo anterior es conveniente ya que, en ocasiones, al efectuarse el análisis del sistema, los documentos originales presentan ciertas deficiencias para captar los datos por procesar, por lo cual es necesario el diseño de nuevas formas para ese propósito; cuando esto suceda, con mayor razón deberá atenderse la recomendación de anexar dichos documentos con las anotaciones correspondientes.

Además, deberán mencionarse todos los datos que en forrna secundaria o lateral originan una entrada importante al sistema; como ejemplo están los catálogos de qarcas, de artículos, etcétera.

Salidas del sistema (resultados por obtener). Como se habrá observado en el párrafo anterior de entradas al sistema, sólo se hizo mención de los datos de captación por el mismo, así como los datos laterales que pudieran significar una entrada. Ahora bien, siguiendo este criterio, en esta sección solamente se describen los resultados de mayor importancia obtenidos a través de todo el proceso.

Cuando sea posible, se anexarán los documentos que contengan los resultados, por ejemplo: listas, formas preimpresas, etc., o bien, los diseños sobre dichos resultados, por ejemplo: formato de un registro en cinta, diseños de impresión, etcétera.

Cuando se considere de gran importancia el destino de algunos resultados, deberán registrarse los departamentos a los que serán distri- buidos, y la utilización que harán de cada uno.

Diagrama general de flujo del sistema. En esta carpeta apare- cerá un diagrama que muestre en forma condensada el flujo de la información y de las operaciones que se realizan con esa información.

Explicación genérica de las fases del sistema. Esta sección se encuentra relacionada directamente con la anterior; lo que ahí se muestra gráficamente, ahora se describe en forma genérica, explicando los procesos que se lleven a cabo en cada área o departamento, sin profundizar en detalles técnicos o específicos.

Se deberán resaltar en forma preponderante las fases del proceso en las cuales se obtengan resultados de importancia, así como aquellas que requieran una supervisión especial.

Requerimientos. Esta sección se presenta en virtud de que deben quedar establecidos los recursos, tanto humanos como materiales, necesarios para llevar a cabo la operación del sistema.

Dentro de los recursos humanos, deberán tomarse en cuenta todos los tipos de trabajos ordinarios o especializados que se requieran, y con base en ello tomar los elementos con que se cuenta o, de ser necesario, pensar en el reclutamiento de personal especializado si el trabajo lo requiere.

Si el persona1 con que se cuenta debe capacitarse para los fines que se persiguen, se planteará en esta sección el tipo de capacitación que habrá que dar a los elementos a quienes se les proporcionará, así como el tiempo que ello implique; en lo que se refiere a los recursos materiales, quedarán establecidos en esta sección los requerimientos indispensables para que se pueda poner en marcha el sistema, mencionando los dispositivos, archivos y papelería, etc., poniendo énfasis en los elementos materiales que no existan aún y que sean de vital importancia para llevar a cabo las funciones del sistema.

Estimación del tiempo probable de implantación. Es necesario que exista una fecha probable de implantación, cuya base será la terminación de cada etapa considerada dentro del desarrollo del siste-

SUGERENCIAS DE SOLUCIÓN 2 73

ma, tales como análisis, programación, elaboración de formas especiales, capacitación de personal, etcétera.

Un punto importante que debe ser considerado dentro de esta sec- ción es el periodo de congelación, atendiendo a las aprobaciones por parte de los distintos funcionarios a quienes atañe la realización del sistema.

En todo caso, la fecha estimada que se plantea aquí será seguramente una fecha tentativa que pueda ser modificada por consideraciones especiales que se presentarán en el desarrollo del sistema.

Consideraciones generales del nuevo sistema. En caso de haber existido un sistema anterior que cubriera las necesidades que se pretenden satisfacer con el nuevo sistema, quedarán señaladas las ventajas y principales diferencias del nuevo sistema respecto de su antecesor, tales como ahorro de tiempo, disminución de costo, seguridad, flexibilidad, confiabilidad, proyección, etcétera.

Carpeta del usuario


Índice. Enunciado de cada apartado de la carpeta. Diagrama general del sistema. En la carpeta deberá aparecer un

diagrama que muestre en forma condensada el flujo general de la información y de las actividades que se realicen en este sistema.

Este diagrama utilizará los mismos nombres que se utilizaron con anterioridad en el diagrama que aparece en la sección correspondiente a la carpeta administrativa.

Las recomendaciones aplicables en la elaboración de este diagrama son las mismas que se aplicaron en la elaboración del diagrama de la carpeta mencionada anteriormente, de preferencia deben ser iguales.

Diagrama particular de la unidad usuaria. El diagrama representa gráficamente todos los pasos que se efectúan dentro de la unidad usuaria a la que está dirigida esta carpeta.

La simbología utilizada será la misma que la usada en el diseño del sistema, pero se especificarán en forma clara las operaciones a que se refieren estos símbolos.

Deberán precisarse los archivos de entrada y de salida, los resultados obtenidos, comprobaciones, procesos manuales, etcétera.

Explicación de las fases del diagrama particular. En esta sección se expondrán en forma específica y detallada todas las operaciones que aparecen representadas en forma gráfica en el diagrama particular del usuario.

Aquí deben analizarse cada una de las fases de que consta el trabajo, además de señalar el proceso principal que se realiza, entrada de la

información, obtención de un resultado parcial, envío de información a otra unidad o departamento determinado, etc. Para ello debe seguirse el mismo orden que aparece en el diagrama particular de la unidad usuaria.

Instructivo de procedimientos. En cada carpeta de usuario existirá un instructivo de procedimientos que permita establecer los lineamientos generales, con base en los cuales se desarrollará el trabajo por parte del usuario.

Dicho instructivo deberá contener las normas referentes a pasos como:

Codificación. Cuando sea necesario efectuar una codificación, aquí se darán los criterios acerca de cómo se desea llevar a cabo. Ello implica conocer el documento fuente y la hoja donde se vaciará. En caso de ser necesario, también se darán las claves y normas conducentes al logro de los fines que se pretenden con la codificación. De ser posible, se anexarán el documento fuente, o una copia del mismo, y una hoja de vaciado.

Facturación. Cuando el proceso implica el manejo de documentos que pudieran extraviarse, deberá existir una o varias facturas que amparen el envío, manejo, recepción, etc., de dichos documentos. En esta sección se establecerán los tipos de facturas que se definan, los documentos que son amparados en esta fase, así como la fecha. Se anexarán copias de las facturas.

Envío. Debido a que el usuario va a producir resultados que deberán trasmitirse a otras unidades o departamentos, es necesario conocer a dónde se enviarán los resultados obtenidos por ese usuario, volumen estimado, periodicidad con que ello se efectúe y forma de envío.

Confirmación de listas. A veces será necesario verificar las listas obtenidas en algún otro departamento, contra los documentos fuente. El usuario encargado de esta actividad deberá tener una guía para comparar ambos documentos. La forma en que dicha comparación se lleve a cabo, así como los campos esenciales de verificación, quedarán establecidos en este párrafo.

Condiciones anomales. Todas las condiciones anormales no previstas en los párrafos mencionados deberán quedar aclaradas aquí. Entre otras podrían ser: proceso por seguir en caso de encontrar errores, consultas a otros departamentos en caso necesario, etcétera.

Solicitudes de modificaciones y trabajos especiales. Cuan- do se analiza el sistema propuesto, es posible que no se detecten situaciones especiales que afecten su diseño.

Al detectar estas situaciones, es posible que se origine una solicitud de modificaciones al sistema en donde se señalen los procesos que,se desea modificar, las causas por las que se han planteado y las posibilidades de llevarse a cabo, así como las ventajas y desventajas que las modificaciones implican.

En caso de que durante el diseño del sistema se detecte la posibilidad de obtener algún resultado no establecido con anterioridad, se especificará en esta sección el tipo de trabajo que se desea, la fase en la cual puede obtenerse, y todas las demás observaciones relacionadas con ese trabajo especial, por ejemplo: que al vaciarse a una hoja de codifica- ción los datos de un documento fuente, se pueda obtener un catálogo de productos especiales, etcétera.

En ambos casos, ya sea que se trate de una modificación o de un trabajo especial, deberán llevar la fecha en que se haya planteado.

Caducidad de documentos fuente y destino final. En ocasiones, ambas tienen por ley un periodo de retención y un destino específico; en esta sección debe quedar claramente designado el espacio de tiempo con que se cuenta para manejar los documentos fuente y el lugar al que habrán de destinarse.

Carpeta para captación de datos


fndice. Enunciado de cada apartado de la carpeta. Diagrama general de flujo del sistema. En la carpeta aparecerá

un diagrama que muestra en forma condensada el flujo de la informa- ción y de las operaciones que se realizan en este sistema. Este diagrama utilizará los mismos símbolos y nombres que se utilizaron con anterioridad en el diagrama que aparece en la sección correspondiente de la carpeta administrativa.

Las recomendaciones aplicables en la elaboración de este diagrama son las mismas que se aplican en la elaboración de la carpeta mencionada, de preferencia deben ser iguales.

Diagrama particular a detalle. El diagrama particular a detalle será la representación de todos los pasos que sigue la información dentro del departamento de captura de datos.

La simbología que se utilizará será la misma que la usada en el diseño del sistema.

En este diagrama aparecerán todas las operaciones que se efectúen con o sobre la información, tales como: recepciones, comprobaciones y revisiones, procesos manuales, verificación, uso de dispositivos especiales como: pantallas de video, unidad de cinta magnética, así como producción de listas de prueba, envíos, etcétera. I

Explicación de las fases del diagrama particular. En esta sec- ción se explican en forma específica y detallada las operaciones que aparecen representadas en forma gráfica en el diagrama particular de detalle.

Siguiendo el orden que aparece en el diagrama anterior, se procede- rá a explicar en forma detallada cada una de las operaciones que se

276 CAF! 21. ANALISIS, DISENO Y MANTENIMIENTO

efectúen, poniendo énfasis en la obtención de resultados parciales, como: listas de prueba, archivos de paso en cinta o disco, envío de listas, recep- ción de formas especiales para vaciamiento de información, etcétera.

Además, deberá darse una explicación clara y precisa sobre las cifras de control que se hayan establecido para cada fase del proceso.

Fuente de los datos por captar. En esta sección aparecerán las fuentes de donde proceden los datos que se van a captar, tales como el departamento en que se origina la información y el destino de ésta para su proceso.

Al mencionar el origen de la información, éste variará según la si- tuación particular de un sistema, podría ser el propio cliente, una oficina de cobranza, un departamento de contabilidad, etcétera.

Medios utilizados para la captación. Aquí deben mencionarse los medios a través de los cuales las fuentes de datos quedan captados, tales como: formas especiales, solicitudes, avisos, hojas de vaciados, listas de prueba, declaraciones, etcétera.

En caso de que la captación de datos se efectúe mediante dispositivos especiales, será necesario incluir aquí los instructivos correspondientes a dichos dispositivos, así como también establecer los tipos de dispositivos, características, funciones, etcétera.

Formatos donde aparecerán los datos. En virtud de que los datos serán procesados posteriormente, deben conocerse anticipadamente y establecerse los formatos en los cuales aparecerán los datos, tanto al captarse como después de ser procesados.

Deberán anexarse los formatos donde aparecerá la información ya procesada y, de ser posible, una copia de los documentos en que aparezcan (facturas, cheques, etc.). Dichos formatos indicarán la naturaleza de los datos y los nombres con que se designan, así como las posiciones en que se encuentran, longitud, etcétera.

Cuando la información aparezca en cualquier dispositivo magnético, se anexarán formatos de registro especiales para esquematizar el arreglo de los datos.

Transformaciones de la información, previas a su procesamiento electrónico. En esta sección quedarán asentadas todas las transformaciones que la información haya sufrido con anterioridad a su procesamiento electrónico.

Una vez que se ha captado la información, ésta puede entrar a diferentes procesos antes de su transformación electrónica; dichos procesos deberán mencionarse aquí, haciendo resaltar aquellas actividades u operaciones que den como resultado una transformación de la información. Un ejemplo podría ser una sumarización de información, o una clarificación de datos, previa al proceso electrónico.

Instructivo de situaciones anormales. Existirá un instructivo de situaciones anormales que permita prever el curso de las actividades en caso de detectarse situaciones anormales.


Este instructivo marcará de los estándares preestablecidos, y la accidn que debe emprenderse en cada caso.

Entregas al centro de cómputo. En esta sección deberá existir un calendario que establezca los horarios y la periodicidad de las entregas al área de operación, la recepción por parte del centro de cómputo, el envío de facturas, la forma de verificar las cifras de control, tanto de la entrada de información como de salida, la duración del proceso y las fechas probables de entrega de resultados; se deben mencionar también los conductos por los cuales se hagan las entregas al centro de cómputo.

Caducidad de los datos fuente. Debido a los grandes volúme- nes de información con que se trabaja, es necesario establecer por escrito la fecha de caducidad de los documentos fuente y el fin a que han de destinarse, ya sea para su destrucción, devolución o conserva- ción en un archivo determinado.

Si se destina a un archivo determinado, ello implica llenar una forma que indique el volumen, fecha de entrega, fecha de caducidad y destino final al cumplirse el lapso en que han de ser archivados.

Carpeta de programación


fndice. Enunciado de cada apartado de la carpeta. Diagrama general. En la carpeta aparecerá un diagrama que

muestre en forma condensada el flujo general de la información y de las actividades que se realicen en este sistema.

Este diagrama utilizará los mismos símbolos y nombres que se utilizaron con anterioridad en el diagrama que aparece en la sección correspondiente a la carpeta administrativa.

Las recomendaciones aplicables en la elaboración de este diagrama son las mismas que se aplicaron en la elaboración del diagrama de la carpeta administrativa, de preferencia deben ser iguales.

Diagrama de flujo del proceso electrónico. En este diagrama se presentarán gráficamente todos los pasos que se siguen en el área de operación en forma detallada y específica, desde la entrada de informa- ción hasta la obtención de resultados finales.

Para ello es necesario que aparezcan en dicho diagrama todas las operaciones y dispositivos requeridos, donde se identifiquen todas ellas por el uso de la simbología utilizada en el área de sistemas, se marcará cada una de las fases (conversión, copiado de archivos, impresión de listas, etc.) por una leyenda que así lo explique, además, dentro del símbolo utilizado para el proceso, irá la clave del programa correspondiente.

2 78 CAF! 21. ANÁLISIS, DISEÑO Y MANTENIMIENTO

También aparecerá en forma clara y precisa el nombre de los archivos que entran al proceso, y deberá ponerse una leyenda que, de ser necesario, aclare la situación especial de un archivo, como podría ser el tipo de acceso que tendrá.

Descripción general de las fases. En vista de que, por lo general, una fase del proceso se identifica con el programa que lleva a cabo esa parte determinada, no es necesario explicar en forma detallada todas las fases que se encuentran incluidas en el diagrama general de flujo, y será suficiente con mencionar la fase de que se trata, el programa que la identifica y, si fuera necesario, algunas características esenciales de ese programa.

Por cada programa con que cuenta el sistema se incluirá la siguiente documentación:

Índice. Enunciado de cada sección. Definición del programa. Esta sección deberá llevar el nombre o

clave del programa, fecha y el sistema a que pertenece, estableciendo por escrito los objetivos fundamentales del programa, los dispositivos en donde se encuentran contenidos los archivos de entrada, etiquetas, posiciones por registro, factor de bloque y clasificación, y también los dispositivos donde se desea contener los archivos de salida, etiquetas y posiciones en el registro.

También contendrá la explicación del proceso para obtener los resultados deseados en forma detallada, sobre todo en los casos en que se desea un proceso estrictamente señalado (cálculo del impuesto a determinados causantes, reporte de clientes morosos, etc.) y las cifras de control que se desea obtener y sus fórmulas de verificación.

Diseño de formatos de registro e impresión. Como complemento necesario de la definición, existen los formatos de registro e impresión. Como los registros pueden estar contenidos en cinta magnética o en cualquier otro medio, aquí se mencionará el archivo de que se trata, así como el dispositivo que lo contiene, utilizando los siguientes elementos, tanto para modo de entrada como de salida:

a) Registros múltiples. En caso de existir dos o más tipos de registro para el programa, se recomienda usar el formato múltiple; podrá usar el diagrama (layout) de campos, o bien, dibujarlo. En cualquier caso deberá contener la clave del programa (que servirá para su identificación), así como también la clave del sistema al que pertenece. Se marcarán y escribirán con claridad todos y cada uno de los campos. En caso de que contenga claves, se deberá anotar una tabla que explique el significado de las mismas, esto deberá quedar en la misma hoja en que se hizo el formato.

b) Formato de registro. Esta forma se usará para diseño de registros, tanto en cinta magnética como en dispositivos de acceso directo, y se debe emplear como a continuación se indica:

Clave de programa. La correspondiente. Dispositivo de almacenamiento. Se pondrá el nombre genérico del dispositivo, por ejemplo: cinta magnética, disco, etcétera. Salida. Se marcará si se trata de un archivo de salida. Cuando el mismo formato corresponde tanto a entrada como a salida, se marcará en ambos casos. Fecha. Día, mes y año de cuando se entrega el instructivo, o cuando el analista diseñó el Formato. Notas. Se anotarán las características generales del archivo, como son: nombre, etiquetas, número de posiciones por registro, Factor de bloque, organización, llave de acceso, etc., así como las que se consideren pertinentes.

c) Impresión. Se empleará el diseño más adecuado de acuerdo con las necesidades de la impresión, pero procurando anotar las posiciones que ocupan los distintos conceptos por imprimir dentro de las 132 posiciones disponibles, para lo cual se recomienda usar el diagrama de impresión. En el formato de impresión se anotan:

Los títulos deseados. El formato de la fecha. 1.0s campos deseados por sacar a impresión. La separación entre una línea y la siguiente. Impresión de signos especiales. Posiciones de los campos por imprimir. Pie de página, etcétera.

d ) Descripción de campos. Para todos los formatos de registro es recomendable usar la estructura de renglones:

En el primer renglón se escribirá el nombre correspondiente a cada campo y10 subcampo. En el segundo renglón se escribirán las posiciones de inicio y fin del campo o subcampo. En el tercer renglón se especificará el número de posiciones que ocupa dicho campo dentro del registro, para lo cual, según el tipo de caracteres que contendrá cada campo, se adopta la siguiente anotación convencional:

- Alfabético: An. - Alfanumérico: Xn. - Número decimal: Zn. - Empacado: Pn.

Donde n es número de posiciones, por ejemplo:

Lista de la última compilación. Para tener un respaldo del programa que se encuentra en disquete (o en cualquier otro medio), deberá contarse con una lista que se haya obtenido inmediatamente después de la última compilación del programa, y el cual se identifique con la clave del programa, clave del sistema y fecha en que se obtuvo.

Cláusulas de lenguaje de control de trabajos ( JCL). Deberá contarse con una lista de las cláusulas de control para que el programa pueda ser utilizado en cualquier momento. Aun cuando no se cuente con las cláusulas de control, bastará con recurrir a esta lista para elaborarlas en forma inmediata.

Lo anterior es necesario en vista de que los programas se encuentran catalogados; con el fLn de ejecutarlos debe existir un juego de cláusulas para iniciar el programa y otro juego para su reinicio.

El reflejo de esos juegos de cláusulas serán las propias listas de las cláusulas de control.

Cifras de control. En esta sección se establecen por escrito todas aquellas cifras necesarias para conocer la actividad de un programa.

Serán tantas como sea necesario, con una longitud variable que será determinada por 10s volúmenes estimados con los que trabajará el programa.

En esta sección quedarán escritos los conceptos para interpretar las cifras de control, así como las fórmulas que permitan verificar dichas cifras para hacer una evaluación y saber si los resultados obtenidos en ellas son correctos.

Una copia de la prueba final del programa servirá para anexarla al instructivo de operación al cual nos referimos más adelante.

Listas de datos prueba. Esta sección está formada por las listas de los datos prueba que se hayan utilizado para la prueba del programa, ya que servirán como referencia en caso de que desearan verificarse con posterioridad los resultados obtenidos en las pruebas.

Resultados de la última prueba del programa. Los resultados a que se refiere esta sección son las listas de impresión obtenidas durante la última prueba, verificando que los resultados que aquí se muestran coincidan en longitud, posiciones, espaciados, etc., con lo especificado en el formato de impresión, al igual que el formato de la fecha, el pie de página, los títulos, etcétera.

En caso de que no se obtengan los resultados impresos, lo único que se verificará serán las cifras de control (formato, leyenda, etc.), con excepción de aquellos casos en los que se haya especificado que no se obtendrán cifras de control.

Todos los documentos inherentes al programa y que no se hayan incluido en los párrafos anteriores se agregarán como anexos al final del resultado de la última prueba, marcándose también con la clave del programa, la fecha y una leyenda que identifique cada anexo.

Carpeta de operación


Índice. Enunciado de cada apartado de la carpeta. Diagrama general. En la carpeta aparecerá un diagrama que

muestra, en forma condensada, el flujo general de la información y de las actividades que se realicen en este sistema.

Este diagrama utilizará los mismos símbolos y nombres que se utilizaron con anterioridad en el diagrama que aparece en la sección correspondiente de la carpeta administrativa.

Las recomendaciones aplicables en la elaboración de este diagrama son las mismas que se aplicaron en la elaboración del diagrama de la carpeta ya mencionada, de preferencia deben ser iguales.

Diagrama de flujo del proceso electrónico. En este diagrama se presentarán gráficamente todos los pasos que se siguen en el centro de cómputo, en forma detallada y específica, desde la entrada de la información hasta obtener los resultados finales.

Para ello es necesario que en dicho diagrama aparezcan todas las operaciones y dispositivos requeridos, los cuales deben identificarse con la simbología utilizada en dicho centro; se marcará cada una de las fases (conversión, copia de archivos, impresión de listas, etc.) con una leyenda que así lo explique, además, dentro del símbolo utilizado para cada proceso deberá ir la clave del programa con que lleve a cabo este proceso.

También aparecerá en forma clara y precisa el nombre de los archivos que entran y salen en el proceso; y en cada caso se pondrá una leyenda que de ser necesario aclare la situación especial de un archivo.

Descripción general de las fases. En vista de que, en general, una fase del proceso se identifica con el programa que lleva a cabo esa parte determinada, no es necesario explicar en forma detallada todas las fases que se encuentran incluidas en el diagrama general de flujo; bastará con mencionar la fase de que se trata, el programa que la identifica y si fuera necesario, algunas características esenciales de ese programa.

Caducidad de archivos. En este punto el analista deberá especificar la caducidad de los archivos que maneje el sistema, y tomar en consideración los respaldos necesarios.

Asimismo, habrá un instructivo de operación por cada programa existente en el sistema, con lo siguiente:

Diagrama general de entradas-salidas. En la primera hoja del instructivo pueden existir tantos diagramas como opciones tenga el programa correspondiente. Se llena de la siguiente manera:

Nombre o clave del programa. Se anotará el nombre o clave que el analista asignó al programa, éste debe ser el mismo que aparezca en la tapa de la carpeta del instructivo individual del programa. Sistema. Nombre del sistema. Analista programador. Iniciales de los nombres y apellidos pater- nos, tanto del analista como del programador. Fecha. Día, mes y año en que se elabora el instructivo. tEntradas/Salidas. Se conectarán a la unidad central (representada por un rectángulo), por medio de líneas, los dispositivos por utilizar, y se iíenarán las especificaciones correspondientes a los ardirvos particulares. En el caso de la impresora, se anotará a su lado la forma, medida y tantos por utilizar, así como la especificación de control de salto. Observaciones. Se anotarán condiciones especiales de arranque, lo que hace el programa, así como la opción de que se trate cuando existan más de una o, en su caso, cuando lo que se pretenda anotar sea extenso, se anexará una sección de aclaraciones especiales, donde se anote la existencia de dicha sección.

Mensajes. Si el programa, como caso excepcional, requiere enviar mensajes por consola, se anexará una forrna de mensajes, que debe llenarse de la siguiente manera:

Clave del programa. La que corresponda. Fecha. Día, mes y año de la elaboración del instructivo. Hoja. Número progresivo que le corresponde dentro del instructivo. Mensaje. Texto del mismo, o bien su identificación cuando así se use. (Esto será por cada mensaje que envíe el programa.) Causa. Lo que origina en el proceso que sea enviado el mensaje, se puede usar la palabra autoexplicativo cuando sea así el mensaje y se haya escrito en esta forma. Acción. Lo que debe hacer el operador cuando se presente esta

Cláusulas de lenguaje de control de trabajos (JCL). Deberá contarse con una lista de las cláusulas de JCL para que el programa se

pueda utilizar en cualquier momento; así, cuando no se cuente con estas cláusulas de control, bastará con recurrir a esta lista para elaborarlas inmediatamente.

Lo anterior es necesario porque los programas se encuentran catalogados, y con el fin de ejecutarlos debe existir un juego de cláusulas para iniciar el programa y otro juego para su reinicio, si el programa contiene la rutina de checkpoint (punto de control).

El reflejo de esos juegos de cláusulas serán las propias listas de las cláusulas de control.

Aclaraciones particulares de cada programa. La finalidad de esta sección es dejar por escrito y a manera de instrucciones para operación todas las condiciones que, por su naturaleza, se consideren como especiales dentro de un programa particular y que, por lo mismo, deberán atenderse en forma preponderante.

Para ello, en el diagrama general de entradas-salidas se hará la anotación que indique la existencia de la sección de aclaraciones. Resulta ocioso, pero oportuno, insistir en que no todo programa va a requerir esta sección, ya que las "condiciones especiales" que se mencionan son en el nivel operacional y no de lógica interna.

Cifras de control. En esta sección se establecerán por escrito todas las cifras necesarias para conocer la actividad de un programa, teniendo una longitud variable que se determinará por los volúmenes estimados de datos con los que trabajará el programa.

En esta sección quedarán escritos los conceptos para interpretar las cifras de control que aquí aparezcan, así como las fórmulas que permitan verificarlas para hacer una evaluación y saber si los resultados obtenidos en estas cifras son correctos.

Se podrá usar una copia exacta de lo que ya exista en la carpeta de programación.

Diseños de impresión. En esta carpeta de operación debe existir un formato de resultados en el cual se mostrarán:

Títulos deseados. Subtítulos. Formato de la fecha. Campos deseados para sacar la impresión. Espacio entre una línea y la siguiente. Impresión de signos especiales. Posiciones de los campos de impresión. Pie de página, etcétera.

En el caso particular de forma preimpresa deberá anexarse un ejemplar que muestre el diseño ya impreso, que facilite el centrado de la misma; no hay que olvidar las especificaciones de control de salto.

Los resultados impresos obtenidos por el programa deberán ajustar- se a los especificados en el formato de impresión.

Formatos de registro. En esta carpeta deberán existir los formatos de registro de entradas y salidas que utilice el programa.

Distribución de resultados. Para hacer más fluido el proceso que se realice en determinado sistema, es necesario conocer de antema- no los lugares hacia donde se van a canalizar los resultados obtenidos, éstos son:

Bodega. Archivo. Cintoteca. Usuarios.

Por escrito, quedará la cantidad y lugares hacia los cuales se hará la distribución de los resultados que se hayan obtenido.

Todo cambio en el sistema deberá ser reflejado en su respectiva documentación para tenerla actualizada.

Las carpetas referidas anteriormente son las requeridas para lograr una buena documentación del sistema en cuestión. Sin embargo, deberá considerarse como un tipo de documentación importante para la ins- trucción del personal que maneja el sistema; por tanto, el siguiente punto deberá ser necesario.

Instrucción sobre manejo del sistema

Debido a que el analista es quien tiene un conocimiento pleno del sistema, es la persona más adecuada para impartir la instrucción que sea necesaria para el manejo del sistema. Esta instrucción debe darse a todas las personas que intervengan en el manejo del mismo, para que sepan manejar la información que a cada uno le corresponde, y para hacerles sentir la importancia de sus actividades y el objetivo que se persigue con el sistema, así como las repercusiones que puede tener un mal manejo de la información.

Ahora bien, como los instructivos facilitan el entrenamiento y la capacitación del personal, es también labor del analista elaborarlos.

La elaboración de manuales facilita el entrenamiento y la capacita- ción del personal. A continuación se mencionan otros t i ~ o s de instructivos.

Instructivos de procedimientos manuales

Instructivos de coMcación y manejo de archivos

Este instructivo indica cuáles datos deben captarse, de qué documentos fuente, en qué orden, el lugar del cual deben tomarse, bajo qué condiciones, etc.; debe contener como'mínimo:

Introducción. Generalidades. Documento fuente. Datos por captar y condiciones (ejemplos). Elaboración de cifras de control. Cuotas por cubrir. Calendario de entrega.

Instructivo de realimentación de información

Debido a que la información puede presentar diferentes condiciones de error y al volumen de los mismos, el analista debe estudiar con cuidado cuál será el método para eliminar o corregir las inconsistencias que se presenten. Este método debe ser económico y práctico, además de cumplir con todas las condiciones posibles para la realimentación de correcciones,

Los rechazos o señalamientos de inconsistencias se hacen por lotes, facturas, documentos o campo. La corrección y realirnentación, por tanto, pueden hacerse en la misma forma.

Es el instructivo que para este fin se elabore el que indicará los medios más apropiadd. ~ & e instructivo deberá contener como mínimo: w

Introducción. Generalidades. Causas del rechazo. Formas de corrección. Cuotas por cubrir. Calendario de entrega.

OPERACI~N DEL SISTEMA

La operación de un sistema es la parte que, dependiendo de la consistencia del sistema y de su documentación, será la que integralmente

arrojará los resultados producto del mismo. Este manejo será regulado por los siguientes elementos:

Calendario de recepción de información y entrega de resultados

Debido a que es necesario prever las cargas de captación de datos y responsabilizar al usuario de la entrega oportuna de su información, se debe elaborar un calendario de recepción de información y de entrega de resultados, porque también el centro de cómputo está obligado a entregar resultados en forma oportuna para lograr la continuidad en el trabajo de los usuarios.

El calendario deberá contener lo siguiente:

Departamentos que intervienen en el sistema. Actividades por realizar en cada departamento. Duración de la actividad (tiempo estimado y tiempo real). Observaciones.

El calendario acordado debe respetarse; de lo contrario, los departamentos que intervienen en el sistema se verían afectados en la planifi- cación de su trabajo.

El calendario acordado debe,darse a conocer a los distintos departamentos, y cada uno de ellos debe aprobarlo por escrito.

Existen algunos resultados estimados por el sistema o algunos resultados especiales no considerados dentro de éste, que no podrán sujetarse al ciclo de un calendario por ser emitidos en forma exclusiva a petición del usuario. Estos resultados se manejarán por órdenes de proceso y las fechas de entrega de resultados se acordarán después de recibir la solicitud del trabajo, previa aprobación de ésta.

Caducidad y respaldo de información

Al tomar en cuenta los grandes volúmenes de información que se manejan, es necesario establecer por escrito la fecha de caducidad de la información y el destino, ya sea para destrucción o archivarlo. Existen dos tipos de caducidades:

Caducidad de información documental. Esta caducidad queda sujeta a la reglamentación de la unidad usuaria respectiva, que en la mayoría de los casos es la depositaria y responsable de dichos documentos.

SUGERENCIAS DE SULULIUN 287

En los casos de excepción, el usuario respectivo, así como el analista responsable, determinarán en conjunto la fecha de caducidad de la información documental, ésta es normalmente cada tres actualizaciones del archivo afectado.

Caducidad de idomcióa, magnética. La caducidad de infor- mación contenida en dispositivos magnéticos se determinará cada tres actualizaciones del archivo base, ya que sirven como respaldo de éste en caso de ser necesario repetir algún proceso. Los tipos de archivo contenidos en dispositivos magnéticos pueden ser:

Archivos base. Son los generados por el propio sistema y que servirán para obtener datos estadísticos o resultados del mismo. La caducidad de cada archivo variará de acuerdo con las actualizaciones del mismo. Usualmente es cada tres actualizaciones, ya que sirve de respaldo al archivo actualizado. Algunos archivos base llegan a convertirse, al cierre de determinado ejercicio, en archivos de consulta, por lo que se les dará caducidad histórica. Archivos de paso. Son aquellos archivos que, como su nombre lo indica, sólo intervienen en alguna fase de un proceso. La caducidad de estos archivos por lo general será inmediata una vez validado el proceso mediante las cifras de control correspondientes. Este tipo de archivos normalmente se generan de programas de utilidad (Sort, Merge, Selector, etc.). Archivos de movimientos. Son aquellos archivos que afectan de alguna manera a los archivos base o de consulta. La caducidad de estos archivos será cada tres actualizaciones, ya que sirven de respaldo a los archivos actualizados.

Regulación de la operación del sistema

Para lograr que un sistema funcione con alto grado de confiabilidad es necesario, además del buen diseño del sistema, tener una regulación operacional del mismo; es decir, ejercer una constante vigilancia sobre los resultados que se obtienen, utilizando para ello los siguientes elementos:

Cifras de control. Las cifras de control deben dar la garantía a un analista de los buenos resultados obtenidos en un proceso; además, deben ser precisas, claras y lógicas, para llegar a una validación rápida y confiabie.

Tiempos de proceso. Es necesario considerar los tiempos de proceso dentro de un sistema, porque los procesos que no justifican un consumo de tiempo considerable se disparan en éste, y es indispensable revisar el programa afectado y buscar su optimización.

288 CAF! 21. ANALISIS, DISENO Y MANTENIMIENTO

Si esta política se aplica a un sistema en su conjunto, se reducirán los tiempos de proceso, y en consecuencia, las horas-máquina ocupadas por un sistema.

Puntos de control. Un sistema debe tener puntos de control estrictos, dado el manejo de q,ue es objeto la información por procesar. Estos puntos de control son la facturación de documentos por captar, y posteriormente de los registros capturados, para verificar estas cifras contra las de control obtenidas electrónicamente y cualquier control que verifique la validez de los procesos.

Oportunidad de resultados. Los resultados obtenidos por un sistema se deben entregar en forma oportuna y veraz; si no es así, serán inútiles para el usuario.

Mantenimiento de la biblioteca de documentación de sistemas

Cuando se diseña un sistema, debe hacerse considerando que debe ser permanente en una institución, no así las personas; por lo que es necesario crear una biblioteca de sistemas en la cual existirán tantas documentaciones de sistemas, como sistemas existan.

Todo sistema es viable de opthnizarse o modificarse, por lo que es necesario actualizar su documentación; cuando así sea, podrían afectar- se las siguientes carpetas:

Carpeta administrativa. Carpeta del usuario. Carpeta de captación de datos. Carpeta de programación. Carpeta de operación.

Dentro de la biblioteca, cada sistema debe estar integrado por las carpetas mencionadas; asimismo, es recomendable agrupar sistemas por áreas de servicios similares, para mayor facilidad de consulta.

Variaciones de operación (permitidas por el sistema)

Cuando un sistema ya ha sido implantado, es posible que surja la necesidad de variar la operación sin que afecte al sistema en sí. Estas variaciones podrán ser:

Número de copias impresas. Destino de resultados.

Distribución de resultados. Parámetros de control. Modificaciones de encabezados.

Distribución de resultados

La distribución de resultados se hará de acuerdo con las necesidades del usuario, y podrá ser:

Directamente al usuario. Aunque la entrega de resultados se haga por medio de una oficina de servicios, los resultados son enviados directamente al usuario, siendo éste el que les dé el destino final.

Por medio de la oficina de servicios. En este tipo de entrega se decide previamente el destino de los resultados obtenidos por un sistema. Es decir que la oficina de servicios se encargará de distribuir los resultados obtenidos por un sistema de acuerdo con lo establecido en éste.

Por correo. Este tipo de entrega puede variar en su procedimiento; es decir, se le pueden enviar los resultados bajo responsabilidad de la oficina de correos según lo crea conveniente, o bien, el centro de cómputo se puede encargar de rotular los envíos y hacerlos llegar a su destinatario por embarque particular.

Una vez implantado un sistema, es necesario darle mantenimiento para cerciorarse de su buen funcionamiento y adaptación a las necesidades del momento, ya sean del sistema electrónico o de recursos técni- GOS. A un sistema se le debe dar mantenimiento básicamente por actualizaciones del sistema o por racionalización del mismo.

Actualizaciones

Un sistema se puede actualizar por:

Nuevos resultados. Los nuevos resultados dentro de un sistema pueden afectarlo, desde los procedimientos manuales, el proceso elec- trónico del mismo, los recursos humanos o sólo algunos de éstos, y es necesario actualizar el sistema según se requiera.

ModEcación a resultados existentes. Como en el punto anterior, un sistema se puede ver afectado en cualquiera de sus puntos; por tanto, será necesario actualizar el sistema, incluso por disposiciones legales.

290 CAF! 21. ANÁLISIS. DISENO Y MANTENIMIENTO

Variaciones de procesos y10 de recursos. Las variaciones de procesos pueden ser:

Entradas. Las variaciones en las entradas de un sistema pueden estar relacionadas con el cambio del documento Fuente y10 con los recursos de captación, generándose una variación en el sistema, por lo que es necesario actualizarlo. Salidas. Las variaciones en las salidas de un sistema pueden estar relacionadas con las variaciones de entrada y10 con las variaciones de operación. Es decir, si la creación de un nuevo resultado, o la modificación a otro ya existente, afectan las entradas de un sistema, lógicamente afectarán las salidas del mismo, y en consecuencia su operación, por lo que es necesario actualizar el sistema. Operación. Las variaciones de operación son producto de las variaciones de entradas y10 salidas de un sistema, o bien por fallas de proceso; por lo que es necesario actualizarlo. Habrá variaciones de operación en donde no será necesaria la actua- lización del sistema, únicamente se hará un ajuste en la fase afectada.

Los recursos variables de un sistema pueden ser:

Humanos. En la implantación de un sistema se deben indicar los recursos humanos necesarios para el manejo del mismo. La variación de este recurso puede repercutir en el buen funcionamiento del sistema; por lo cual será necesario realizar los ajustes correspondientes para que estas variaciones no interfieran en su funcionamiento. Materiales. Los recursos materiales de que dispone un sistema están estrechamente ligados con los recursos materiales de que disponen las unidades usuarias que intervienen en él. AL cambiar el tipo de los recursos materiales de las unidades, un sistema podrá variar con el fin de adaptar el sistema a estos nuevos recursos, sin que esto afecte los objetivos originales.

Documentación. Las variaciones que sufra un sistema por actua- lización, lógicamente repercutirán en la documentación del sistema, ya que ésta servirá de consulta para cualquier persona relacionada con el mismo.

Las actualizaciones de documentación del sistema deberán efectuarse a la mayor brevedad después de ocurrida la variación, de lo contrario, llega un momento en que la documentación no corresponde a la realidad o se olvida la modificación.

Regionalización. Al actualizar un sistema se debe investigar si esta actualización es aplicable al sistema implantado en las regiones. El concepto de regionalización es común en empresas gubernamentales, bancos y, en general, en empresas que implantan los sistemas centrales en las demás regiones del interior del país en donde también dan servicio.

Racionalización. Todo sistema debe estar sujeto a una racio- nalización, es decir, a una organización sistemática del trabajo para obtener un mayor rendimiento, este objetivo se logrará mediante la evaluación periódica del sistema.

La evaluación periódica es una investigación profunda del sistema, cuya finalidad es determinar las necesidades actuales del usuario y si el sistema cubre las mismas. Esta investigación se debe efectuar como si se tratara de un sistema nuevo, y se considerarán los siguientes puntos:

Objetivos actuales. Éstos se determinarán en forma conjunta con el usuario, según sus necesidades. Políticas actuales. Las políticas establecidas para un sistema pueden variar por diferentes motivos, entre otros, pueden ser: nuevos resultados, nuevos objetivos, recursos materiales, etc.; estos factores harán necesario determinar nuevas políticas para manejar el sistema. Entradas. Se investigarán los procedimientos manuales y de cap- tación, para determinar si aún son funcionales o deben modificarse o cambiarse en su totalidad. Salidas. En este aspecto básicamente se investigará la funcionalidad de los resultados que se obtienen en el sistema. Esto se logra con una determinación del objetivo, donde se busca un resultado y la utilización real de éste. Utilización de resultados. Si al hacer la investigación de la funcionalidad de un resultado obtenido por un sistema se determina que no ha sido utilizado en forma adecuada, es necesario hacer notar al usuario esta deficiencia en el manejo del sistema, indicándole la mejor manera de utilizar el resultado. Operación del sistema. Este estudio está dirigido al manejo del sistema; la evaluación de este punto determinará los ajustes que se deban hacer. Rediseño o actualización del sistema evaluado. De la evaluación de los puntos detallados anteriormente se determinará lo siguiente:

- El sistema cubre las necesidades para las que se creó, y no es necesario hacerle ningún ajuste.

- El sistema cubre las necesidades para las que fue creado, pero es necesario hacer algún ajuste en algún(os) punto(s) evaluado(s),

La improvisación en el desarrollo de sistemas conduce irremediablemente al despilfarro computacional.

sin llegar a rediseñar el sistema. Si éste es el caso, se deben seguir los pasos descritos en el punto de actualizaciones a un sistema.

- Ya no cubre las necesidades para las que se creó, y por este motivo es necesario rediseñar el sistema. Si es así, se deben seguir los pasos descritos en esta metodología en lo referente al diseño de un sistema.

RESUMEN

Desarrollar un sistema no es tarea sencilla, requiere mucho tiempo de estudio y dedicación; representa una gran dosis de investigación y otro tanto de pdaneación. Implica bastante creatividad por ambos lados: del usuario y del analista. Obliga a una labor muy £uerte de análisis de necesidades de información, y por tanto, un alto grado de conocimiento del medio para el cual se hará el diseño. Esto no se puede adquirir de un día para otro, ni se puede improvisar con suposiciones superficiales. Se sabe que muchos sistemas, desde su nacimiento y hasta la fecha, representan sólo altos costos y poco aprovechamiento de resultados. Los usuarios no están satisfechos con tales sistemas, pues su aprovechamiento es deficiente, y se dan casos en que para obtener un raquítico

RESUMEN

resultado, se pasan semanas de proceso, que arrojan infinidad de resultados que a nadie sirven, o a los que habrá que hacer todavía infinidad de ajustes, surgidos de los datos obtenidos por los procedimientos manuales del propio usuario. En auditorías practicadas en algunas instalaciones, se ha encontrado que 30 % de los resultados de un sistema que consume semanas de proceso son desperdiciados por no interesar a nadie. La palabra análisis conduce a un proceso de investiga- ción minucioso. El concepto diseño representa un alto grado de inventiva y creatividad. Los pasos del análisis y el diseño obligan a un proceso perfectamente definido. Significan secuencia, estructura, orden, previ- sión, precisión y cualquier ingrediente lógico que ofrezca seguridad y confianza de que se cubren las necesidades completas de información para lo que el sistema fue concebido.

La productividad en la Informática 2

Problema

El aspecto de productividad sigue siendo un factor muy pobre en el ámbito inforrn6tico.

A lo largo de mi carrera profesional, en el campo de la informática, he tenido la oportunidad de participar en toda índole de proyectos, desde los más simples hasta los más complejos, calificados así dentro de la esfera tecnológica de nuestro país. Asimismo, he sentido el peso de la responsabilidad en la mayoría de los puestos tecnicoadministrativos desde auxiliar de operador de computadora hasta los niveles gerenciales y de liderazgo en las instalaciones más grandes de México.

Esto me ha hecho reconocer una realidad poco aceptada y muy difusa por su naturaleza y alcance, me refiero en concreto a la productividad, concepto que, por lo general, se define como el conjunto de técnicas y procedimientos encauzados para obtener el máximo provecho de los recursos que tenemos a nuestra disposición, en este caso, recursos de cóm uto.

La computa 1 ora es sólo una herramienta de trabajo, recurso con el cual podemos abreviar la labor de administración y explotación de datos. Sin embargo, $cuál es el máximo provecho que el hombre puede obtener de dicha computadora< La respuesta no es sencilla, pues, hones- tamente, no es posible determinar si la estamos aprovechando con eficiencia; aquí surgen otras preguntas: jqué significa un uso eficiente<,

jcuándo resulta deficiente¿, jhasta dónde es el alcance hacia arriba y hasta dónde hacia abajo¿, jen qué posición nos encontramos¿ Por tanto, jproducirnos o no producimos< El hecho de que algunos procesos salgan mediante la computadora, no necesariamente nos indica que en realidad la estamos aprovechando en forma adecuada, pues podríamos plantear otras preguntas: jpodemos producir más con la misma computadora¿, jpodemos optimizar los tiempos de los procesos¿, jrealmente necesitamos más gente para la obtención de más resultadosf, jya se encuentra saturada la computadora¿, jestá saturada por el mal uso que hacemos de ella¿, !se requiere una computadora más poderosa¿, jqué tan poderosa., etcetera.

Ya no es necesario plantear otras preguntas, pues sólo nos confun- dirían más y no quedaríamos satisfechos, ya que podemos complicarlo tanto como queramos. Sin embargo, el problema está ahí, y es tan real que lo vivimos a diario.

Es frecuente observar una preocupación latente en toda instalación, por lo difícil que resulta justificar las altas inversiones de capital que requieren estos equipos, además de b costoso que resulta contar con técnicos verdaderamente capacitados. Es notorio también palpar un cierto grado de com etencia de instalación a instalación, por demostrar quién ha desarrolla d?' o mejores sistemas; e incluso se dice que la instala- ción más grande es la mejor, sin reconocer que en algunos casos es en donde mayores despilfarros ocurren.

1. Aunque este punto podría culminar con cientos de comentarios, la verdad es que para encontrar la medida que nos ubique dentro de un marco productivo, se necesita en primera instancia establecer que no importa si el área de informática es grande o pequeña, ya que siempre existe la posibilidad de hacer las cosas mejor y, de esta manera, eliminar o reducir la costumbre del "ai se va", pues no existen límites para mejorar, y esto sí lo podemos saber; es decir, si cada vez mejoramos en calidad, orden, satisfactores de inforrnación a los usuarios, optimización en el uso de recursos de cómputo, capacitación del personal y cualquier indicio de madurez técnica.

2. Es obvio que para lograr lo anterior se requieren métodos de trabajo perfectamente definidos en cada área, que nos perrnitan conocer el grado de avance. Esta medida es la única que necesitamos, por lo cual es de vital importancia que cada departamento fije sus objetivos concretos, así como los niveles de servicio que persigue, para que así, en ciertos lapsos pueda comparar si dichos niveles de servicio se están acercando hacia los objetivos establecidos de acuerdo con lo planeado.

G4F! 22. LA PRODUCTIVIDAD EN LA INFORMATICA

Si no es así, se requerirá hacer auditorías técnicas que detecten las razones y establezcan Los comecdvos oportunos para encauzar el c m i - no. De lo coatrasio, si nuestros objetivos ae van cubriendo, será sencillo comprender el nivel de productividad y mantener los esfuerzas en forma persistente con el fin de continuar la trayeatoria hacia arriba, sin descuidar ningntrt factor necesario para mantener dicha trayectoria. De cualquier manera, mediante esta estrategia, también será p~sibhe identificar esmncmnientos o desviaciones, de una manera oportuna.

La productividad sigue siendo un aspecto muy difuso en las dreas de intormhtica.

RESUMEN

Al concepto productividad normalmente se le define como el conjunto de técnicas y procedimientos encauzados a obtener el máximo provecho de los recursos que tenemos a nuestra disposición; en nuestro caso, recursos de computación. Pese a que es un factor vital para contrarrestar el fenómeno del "despilfarro computacional", aún no se le da la debida importancia. Sin embargo, para entender su profundidad y alcance, basta con eliminar la costumbre del "ai se va". Es obvio que para lograr lo anterior es necesario apegamos a métodos de trabajo perfectamente delineados para medir nuestro grado de avance. Esta medida es la única que necesitamos, por lo cual es vital que cada departamento fije sus objetivos concretos, así como los niveles de servicio que persigue, para que así, en ciertos periodos pueda comparar si dichos niveles se están acercando a tales objetivos; será muy claro entonces entender el nivel de productividad alcanzado.

Operación de sistemas 1

Problema

Con frecuencia, los sistemas en producción se operan con poco control; esto origina reprocesos constantes y demora en la entrega de resultados a los usuarios.

Es importante destacar que la función de operador de computadora ha cambiado. Tradicionalmente, los operadores de computadora operaban también los sistemas en producción. Esta práctica es obsoleta, aunque en instalaciones pequeñas aún se practica. Por el gran auge que ha tenido la demanda de uso de equipos de cómputo y la incorporación exponencial de nuevos usuarios, las labores de operación han tenido que especializarse. En la actualidad, es usual distinguir los siguientes tipos de operadores:

a) Operadores de computadora. b) Operadores de periféricos magnéticos. C) Operadores de impresoras.

d ) Operadores de la red on line, e) Operadores de sistemas.

La función de cada especialidad es muy concreta; los operadores de computadora se dedican a vigilar mediante los monitores de control (consolas) que el servicio llegue correctamente a todos los usuarios, y a

298 CAP 23. OPERACI~N DE SISTEMAS

cerrar y abrir servicios según los horarios establecidos. También coordi- nan las actividades de otros operadores.

Los operadores de periféíicos magnéticos se encargan básicamente del montaje de cintas magnéticas y de habilitación de discos, para mantener un servicio ágil y rápido en este tipo de labores manuales.

Los operadores de impresoras tienen a su cargo el montaje de los distintos tipos de papel, y distribuyen con fluidez los reportes impresos hacia las distintas unidades usuarias.

Los operadores de la red on h e vigilan la disponibilidad del servicio remoto hacia las distintas localidades y detectan anomalías en las comunicaciones, además de habilitar trayectorias opcionales en caso de fallas. Están en estrecha comunicación con todos los usuarios de la red, con el fin de mantener un nivel eficiente de servicio. Llevan control estricto de los horarios de servicio y cierran o enlazan la comunicación hacia las distintas localidades.

Además, aun cuando los sistemas on h e han simplificado el acceso a la información mediante terminales de video (como un método ya establecido), todas las transacciones en tiempo real vuelven a verificarse mediante procesos batch, lo cual obliga a trabajar a marcha forzada, con el fin de que las transacciones de todo un día puedan verificarse una vez cerrado el servicio on line, y tener la certeza al día siguiente de que la inFormación disponible es confiable. Los operadores de sistemas son los encargados de procesar de día y de noche los sistemas batch y, por lo general, trabajan contra el reloj ya que cualquier retraso en la produc- ción pone en riesgo el servicio puntual del día siguiente.

Aun así, pese a la gran responsabilidad que tienen los operadores de sistemas, existen serias deficiencias en su modo de trabajar. Por lo general, quienes operan los sistemas son verdaderos conocedores de cada proceso; conocen con tal detalle la secuencia de cada corrida, que cuando ocurre una falla de h e d i a t o saben qué hacer para activar un reproceso y continuar; son personas que han trabajado varios años con los mismos sistemas, y han adquirido tal experiencia que se les considera expertos en su manejo, al grado que en casos específicos de falla utilizan trucos ingeniosos para dar soluciones, Todo esto es excelente, si no fuera porque gran parte de su valioso conocimiento está en su cabeza, y cuando mucho se les asigna un ayudante con la intención de que, aunque sea superficialmente, asimile parte de la experiencia; pero jqué sucede cuando el experto se ausenta o renuncia¿ De inmediato se moviliza al analista, al programador o a cualquier persona que conozca algo de dichos procesos. Surge el pánico y, como pueden, aun con demoras en la producción, resuelven el problema rogando que se presente el experto. He visto casos en que se ha sacado de la cama al experto, inclusive enfermo, para que vaya a corregir algún error. He sido testigo de la regularidad con que se le cancelan vacaciones por no haber

quién se quede en su lugar. En muchos casos, se dispone de instructivos dispersos que el analista y el jefe de operación tratan de entender para corregir alglin error en ausencia del experto.

Este tipo de situaciones son comunes en la mayoría de los centros de e

cómputo. Los reprocesos se repiten a diario una y otra vez, no importa el gasto de recursos técnicos, humanos y hancieros; lo importante es lograr los resultados. Muchas veces todo vuelve a la normalidad; es decir, a depender del experto, pero, así también en bastantes ocasiones la falla no se controla con rapidez, y es cuando miles de personas llegan temprano a los bancos, a alguna oficina gubernamental o simplemente a confirmar un vuelo y encuentran un tumulto de gente desesperada y molesta porque sencillamente jno hay sistema!

$Cuál es el costo en tiempo y dinero de este tipo de situaciones< Prác- ticamente es incalculable, porque se tendría que preguntar: $cuánto vale el tiempo de toda esa gente?, $cuánto podrían estar produciendo en vez de esperad, $cuántas operaciones comerciales se afectaron<, etc. Ahora bien, $cuántas veces ha sucedido esto<; no se sabe porque no hay estadísticas.

Como puede observarse, actividades al parecer sin importancia propician situaciones sumamente serias y costosas. Por ello, es impostergable asegurar un control estricto en la operación de sistemas, ya que es una actividad de alto riesgo en la cual culmina el proceso de datos de un centro de cómputo.

1. Como primera condición para tratar de solucionar este problema se debe estar consciente de que la función de operación de sistemas es vital en el entorno del centro de cómputo.

2. Cuando ya se tiene conciencia de su importancia, es conveniente quitar dicho control de las manos de un experto.

3. Es imprescindible elaborar la documentación necesaria y vigilar que esté actualizada, de tal manera que personas diestras, pero no expertas en la operación específica de los sistemas, puedan operarlos con facilidad.

4. A continuación propongo un método para documentar la operación de cada sistema. Es consecuencia de múltiples experiencias y dio resultados muy satisfactorios. Para esto, me referiré a un caso difícil que fue resuelto y cuyo método se aplicó también con provecho en otras instalaciones:

Una vez se me pidió que realizara una investigación en el área de control de la producción (operación de sistemas), ya que se retrasaba la entrega de resultados a los usuarios en forma constante.


Para empezar, asistí varias noches a examinar cuál era el método con que operaban los sistemas. Encontré que no había método, todo el proceso lo administraba de manera completamente improvisada un experto que dominaba a ojos cerrados la mayoría de los sistemas. Los procesos principales iniciaban entre las 7 y 9 de la noche y terminaban cerca de las 6 de la mañana del día siguiente, siempre y cuando se hubieran resuelto los problemas que invariablemente ocurrían. Observé que estos problemas casi siempre tenían relación con las siguientes condiciones:

a) Errores en la codificación de parámetros de control de los procesos.

b) Archivos con inconsistencia de datos. c) Errores en el orden de secuencia de los procesos; es decir, se

olvidaba que era requisito correr tal o cual proceso en esa fecha en particular.

d ) No cuadraban las cifras de verificación de algunos procesos debido a falta de control de los archivos de movimientos que afectaban a los archivos maestros, ya sea que no se introducían los archivos correctos o sus datos estaban incompletos.

e) Inconsistencias en la codificación de las cláusulas de control (JCL), porque se codificaban o cuando menos se modificaban diariamente.

f ) Cuando ocurría algún error, hasta ese preciso momento se defi- nía la estrategia del reproceso por seguir, lo que muchas veces no resultaba, y se procedía a buscar otra solución.

Como se puede apreciar, al iniciar la operación de los sistemas, prácticamente no existía la preparación de todos los elementos de trabajo, por lo que durante la noche éstos se preparaban bajo presión.

Con base en el análisis anterior de la situación, establecí los siguientes objetivos:

a) Documentar el conocimiento de la operación de los sistemas que de ellos tenía el experto. Esto se haría de manera prudente, con el fin de no causar renuencia por parte de aquél.

b) La documentación se estructuraría de tal manera que al mismo tiempo quedaran asentados todos los parámetros necesarios para las corridas, así como todo el conjunto de cláusulas de control (JCL) necesarias para todos los casos de procesos y reprocesos.

c) Una vez que se dispusiera de todos los elementos anteriores, se le pediría al experto que aceptara el puesto de supervisor de control de la producción, con el fin de que los procesos comenzaran a ser operados por personas diestras, pero con pocos conocimien-


tos de los sistemas. Esto permitiría conocer el grado de efectividad alcanzado en la documentación. Y sólo intervendría el exper- to en caso de que se presentara un tipo de falla y la estrategia de solución estuviera mal planteada o no se hubiera considerado. La idea era depender cada vez menos del experto.

Con base en el planteamiento de los objetivos anteriores, el problema ahora era establecer un formato práctico que permitiera plasmar el conocimiento del experto, así como la preparación completa de todos los parámetros y cláusulas de control, necesarios para cada caso, tanto de proceso como de reproceso, y que además considerara las múltiples variantes de acuerdo con corridas especiales de fechas específicas. Hacer un manual de tal magnitud no sólo sería tardado, sino que se correría el riesgo de meterse en un círculo vicioso de correcciones infi- nitas, y con el tiempo propiciar que el experto no trasmitiera con claridad sus conocimientos.

Hice varios formatos, y finalmente logré uno que resultó ser muy sencillo y práctico para tales fines, lo denominé "Control matricial de procesos". Consistía en un calendario en forma de matriz, uno por cada mes, el cual contenía los días del mes, y dentro de cada día los nombres de otras matrices, las cuales venían a ser los procesos particulares de cada sistema para cada día. En las matrices estaba asentada la secuencia en la cual se tenía que iniciar cada proceso y todos los casos posibles de reproceso.

A continuación, se da un ejemplo del calendario y su relación con cada matriz de proceso.

RESUMEN 303 - A

Para aclarar el contenido de la matriz de procesos del día se tienen las siguientes descripciones:

Secuencia. Orden en el que debe activarse cada disparador. Clave del disparador. Identificación de un pequeño conjunto de cláusulas de control (JCL), que a su vez inician un procedimiento completo. Clave del procedimiento de JCL. Identificación de una agrupación grande de cláusulas de control (JCL), que cumplen con un proceso completo dentro del entorno del sistema. Clave del paso dentro del procedimiento de JCL. Internamente, un procedimiento consta de pasos. Cada uno de ellos representa la corrida de un programa determinado. Clave del disparador en caso de reproceso. Identificación de una agrupación de cláusulas de control (JCL), previamente preparadas para prever la posibilidad de un reproceso si fallara cualquier paso. Condiciones especiales de reproceso. Comentario acerca de una condición de cuidado para el caso de reprocesos. Si no hay comentario, el reproceso es normal.

En sí, ésta fue la filosofía determinada para la o eración de sistemas. La estrategia resultó efectiva, porque dada la senci 8 ez del llenado de las matrices, quien lo hizo realmente fue el experto, y lo sintió como creación suya, por lo que no hubo resistencia para trasmitir sus conocimientos. La codificación de los parámetros y las cláusulas de control he-. ron también labor suya, y aunque esto tomó mucho tiempo, resultk relativamente sencilío gracias a las facilidades de edición en la computadora. Hubo casos en que por un solo parámetro de control que va- riaba, se tenían que repetir cientos de cláusulas de control, para que así quedara preparada una corrida específica, y no correr el riesgo de hacerlo el mismo día del proceso. La consigna era que todo lo que se tuviera que hacer para cualquier caso, ya estuviera preparado.

RESUMEN l M

m 8 - 1 F.

La operación de sistemas es una actividad de mucho cuidado. En sí representa la culminación de todo el esfuerzo del análisis, diseño y programación de los sistemas de información. Se ha comprobado que no se le da la debida importancia, y que ello significa constantes errores y retrasos en el servicio de cómputo a los múltiples usuarios. No es admisible que por falta de una documentación sencilla y eficiente para el control de la producción, se ponga en riesgo la efectividad del centro


de cómputo. Por eso es impostergable implantar procedimientos estrictos para el control de los procesos y documentarlos para no depender de los conocimientos de un experto. Esta documentación debe ser capaz de lograr que los sistemas los operen personas diestras, pero no expertas en los sistemas. La consecución de este objetivo quizá tome tiempo, sobre todo por la preparación minuciosa a que obliga la codificación de parámetros y las cláusulas de control. Sin embargo, los beneficios lo justifican ampliamente. Analice con detenimiento el "Control matricial de procesos" expuesto anteriormente. Estoy seguro de que podrá establecer una estrategia similar con los mismos objetivos.

Usemos las microcomputadoras, pero Len qué?

Problema

Se dotó de microcomputadoras a los usuarios de las areas operativas y se les abandonó

Es evidente que se dio nuevamente un paso gigantesco con rumbo a la automatización en nuestro país, pero sin dirección. A lo largo del desarrollo de este libro se ha hecho hincapié en que en México y en la mayoría de los países en vías de desarrollo, se ado tó una tecnología como quien simplemente adopta un niño sin ha E er pasado por el complicado proceso del embarazo y el doloroso parto; es decir, adoptamos la tecnología de la computación electrónica sin haber sufrido el laborioso y costoso caminar de la investigación que tuvieron que recorrer sus descubridores e inventores. Ahora la tenemos a disposición, pero nos seguimos resistiendo a pagar el costo de sus beneficios, sin querer damos cuenta de que con lo que estamos haciendo, perdemos mucho más. No terminamos de entender que esta tecnología es compleja y requiere una preparación a conciencia para dominarla. Queramos o no, el uso de computadoras en nuestro país todavía resulta ser un enfoque novedoso.

En la década de los sesenta, con la llegada de las primeras computadoras a nuestro país, simplemente las adquirimos como una moda y, en nuestra prisa por utilizarlas, no nos dimos el tiempo suficiente para formamos con una capacitación planeada y adecuada a

w: CAF! 24. USEMOS LAS MICROCOMPUTADORAS

los problemas que deseábamos resolver con estos equipos. Nos desbocarnos, nos precipitamos sin uso de razón; nos fuimos adentrando a tumbos, tropiezo tras tropiezo. Así creamos nuestra propia cultura informática, la cual nos lanzó al "ojo del huracán" del despilfarro computacional. Al paso del tiempo creímos con firmeza que esa debía ser nuestra "realidad informática" y nos la adjudicamos, la hicimos verdaderamente nuestra.

Pese a los esfuerzos de algunos colegas con visión, quienes han tratado de liberarnos del centro mismo del huracán, hacia el cual nuestra ignorancia nos encaminó; por desgracia, como 10 comprueba este libro, seguimos cautivos víctimas de vicios poderosos que por años se han arraigado, al grado de que los hemos aceptado como parte misma de nuestra deforme cultura informática: son "males necesarios" con los que hay que aprender a vivir, iy vaya que los hemos vivido!

Pues bien, si aún existiera duda de lo antes dicho, y si en verdad hubiéramos madurado ya con suficiente firmeza para emprender un camino más productivo y provechoso en el ámbito inforrnático, jcómo explicar el segundo gran tropiezo que tuvimos con la aparición de las microcomputadorasC

Analicémoslo. A mediados de la década de los ochenta, ya habiendo tomado impulso la gran ola que se había venido formando desde los inicios de esa misma década, nos atropelló frontahente y nos lanzó hacia la "epidemia de las microcomputadoras". Nuevamente resultó más poderoso el impulso de esa gran ola que nuestra frágil preparación, cautivándonos ingenuamente, y en un par de años inundamos las oficinas de centenares de empresas con cientos de miles de microcomputadoras. Volvimos a engañarnos nosotros mismos, creyendo que estos pequeños artefactos trabajan por sí solos y que reclaman poca o nula preparación por parte de los usuarios. Y así como sucedió en la década de los sesenta, repetimos la misma historia: se lanzaron al mercado cursos completamente improvisados, con duración de sólo unos días, enlos cuales se enseñó fugazmente algo del D.O.S., procesador de textos y hoja de cálculo. Dado que quienes cursaron dichos temas en su mayoría era personal secretaria1 y de áreas operativas, resultó que académicamente sus estudios eran de nivel medio y bajo. Además, había que agregar que dicho personal no contaba con antecedentes mínimos sobre esta tecnología, por lo que la asimilación de los conocimientos fue bastante pobre. Aun así se les dotó de microcomputadoras y se les abandonó a su suerte, esperando que por arte de magia dichos equipos comenzaran a producir. Resultado: miles y miles de microcomputadoras inactivas; miles de usuarios operativos frustrados; miles de millones de pesos despilfarrados en equipos que pronto fueron obsoletos; peor aún, un esfuerzo colosal de recursos humanos sin

USEMOS LAS MICROCOMPUTADORAS 307

provecho importante y la pérdida de una invaluable oportunidad de haber tomado control de un fenómeno que nos hubiera perrnitido de una sola vez crear de manera planeada una cultura informática en el nivel de empresa.

Habiéndonos percatado de esta situación, un grupo de colegas y yo, lejos de darlo todo por perdido, creímos que el problema ahí estaba, así como sus causas. No podíamos desaprovechar esta oportunidad, pues esto nos podría marcar el camino por seguir para superar las deficiencias. Iniciamos una investigación y encontramos lo siguiente.

Era evidente que la tendencia de las áreas operativas se encaminaba al uso de microcomputadoras. Sin embargo, también era notorio que donde se habían instalado estos equipos, o bien no se estaban utilizando o se usaban con un provecho mínimo. Nos percatamos de que muchos usuarios, al llegar por la mañana, encendían la microcomputadora, seleccionaban el menú más vistoso y así la dejaban el resto del día. Cuando nos acercamos a preguntarles a varios de ellos por qué hacían eso, su respuesta por lo general fue: "No sé que es lo que verdaderamente puedo hacer con este equipo que resulte de provecho para el tipo de trabajo que realizo, por eso sólo lo enciendo para que se crea que lo estoy utilizando." Esto nos llevó a iniciar una encuesta más profunda con el fin de detectar las verdaderas causas de esa situación. Encontramos lo siguiente.

a) Se habían adquirido microcomputadoras, pero no se había capacitado a nadie para su utilización.

b) En algunos casos, se había capacitado a algún personal, pero con cursos aislados que no dieron una orientación que les permitiera realmente sacar provecho; dicha capacitación no fue planeada, ni se establecieron objetivos específicos para el buen uso de la computadora.

c) Cuando mode~t~imente se sabía a qué resultados se quería llegar con la computadora, se capacitó a algunos mediante cursos improvisados, pero no se les enseñó a transportar un problema administrativo para ser representado y resuelto mediante técni- cas de computación. Por esto, el equipo prácticamente perma- necía sin utilizarse para la obtención de resultados de uso productivo.

d ) Algunos usuarios que fueron mejor capacitados y que pusieron empeño en la utilización de la computadora, de algún modo se estancaron, al perderse en un mar de documentos fuente, una gran cantidad de archivos que habían creado dentro de la computadora y que ahora les era muy difícil identificar si eran importantes o no; se confundieron entre muchos intentos de resultados con lo que contaminaban tremendamente el ambiente

CAF! 24. USEMOS Lis MICROCOMPUTADORAS

de discos de la computadora; no sabían cómo respaldar los archivos verdaderos, y perdían muchas horas y días de trabajo cuando por error o accidente los borraban. Prácticamente traba jaban "en el aire" de una manera improvisada, ya que no docu- mentaban todos los trabajos que iban desarrollando; o sea, no eqtaban preparados para administrar todos los elementos de la computadora. Al trabajar de esta manera terminaban por abru- marse y abandonaban el uso de este equipo. .

Con base en lo anterior, diseñamos y comprobamos la efectividad de un plan de capacitación para secretarias y personal operativo de oficinas, al cual le dimos un nivel de diplomado, que aparte de dar un reconocimiento curricular a los asistentes, también representó el haber cursado una capacitación seria, efectiva y, sobre todo, completa, con base en objetivos concretos, imposible de ser adquirida mediante cursos aislados.

Comprobamos que los módulos con los que estructuramos dicha capacitación, bien impartida y con énfasis en la solución de los problemas específicos de las áreas en las que laboraban los estudiantes, lograba que ellos pudieran resolver la mayoría de los problemas administrativos inherentes a su área, gerencia o departamento.

Por lo anterior, queremos poner a disposición del lector el temario completo en el cual se basa la capacitación que comprobamos resolvía en mayor medida la problemática detectada, así como los argumentos por los que cada uno de los módulos fue seleccionado. Por supuesto que es sólo una sugerencia de solución, rnisma que el lector podrá evaluar. Lo que es un hecho es que a nosotros nos dio muy buenos resultados.

Se sabe que gran parte de los problemas administrativos ae los departamentos y gerencias, sobre todo de grandes empresas, son de vital importancia, pero resultan insignificantes vistos por el área de informática. De tal manera, que no justifican, aparentemente, el ser atendidos con carácter prioritario, por lo cual, pasan meses, incluso años, sin ser resueltos, ocasionando enormes esfuerzos operativos para las áreas que los padecen.

Para aquellas empresas que no cuentan con centro de cómputo, el hecho de capacitar a su personal operativo y secretaria1 les permitirá ir reconociendo paulatinamente si en verdad requieren un equipo mayor, o si con una o varias ~crocomputadoras pudieran satisfacer sus requerimientos. Pero esto solamente lo sabrán si empiezan a obtener resultados efectivos en su microcomputadora, lo que' les permitirá detectar si

L . i i .Ir 8 -- =iw I i

1

el nivel de sus problemas administrativos coincide con el nivel de los resultados obtenidos. De cualquier manera, en este momento sí sabrán qué tan cerca o lejos están de satisfacer sus requerimientos reales, La gran ventaja es que no necesitarán una gran inversión para hacerse de este conocimiento.

El objetivo de esta capacitación en el nivel de diplomado, es precisamente instruir al personal secretaria1 y operativo de dichas áreas, con el fin de que sin ser expertos en computación, puedan resolver gran parte de sus problemas valiéndose de sus propios recursos, sin la necesidad de depender para estos casos del área de informática.

Mediante la estrategia anterior se alcanzan las siguientes ventajas:

Los departamentos y oficinas podrán resolver muchos de sus problemas administrativos de manera completamente autónoma, sin la necesidad de contratar especialistas en computación. Los departamentos y oficinas podrán contar con información procesada exactamente como la requieren, porque son ellos quienes conocen con precisión sus requerimientos. Los resultados los podrán tener casi de inmediato, incluso podrán experimentar varias presentaciones, sin pasar por mayores trámites, La computadora central no se verá sobrecargada con infinidad de pequeños requerimientos. El área de informática podrá dedicar, con toda su fuerza, tanto recursos humanos como materiales para resolver los proyectos altamente prioritarios para la empresa, encauzando dicho esfuerzo al desarrollo y operación de sistemas de un elevado nivel de servicio, y al proceso de datos de alta calidad. El área de informática no tendrá necesidad de incrementar su personal técnico para satisfacer requerimientos no prioritarios, pero de alta relevancia para las gerencias y departamentos que los solicitan. La empresa se verá beneficiada al promover la elevación del nivel académico y productivo del personal operativo, el cual en su mayoría carece de estudios superiores, y elevará la moral y la calidad de trabajo de aquellos que obtengan su diplomado. El personal operativo empezará a ser orientado para interpretar las soluciones de los problemas en términos de sistemas de información, lo cual indudablemente redituará en buenos niveles de automatización de la empresa.

Es importante destacar que el plan de capacitación informática en el nivel de diplomado para las áreas operativas tiene como finalidad básica el fomento de una cultura informática en esos sectores operativos, que a mediano plazo sea el inicio de la estrategia de descentralización

31 0 CAP. 24. USEMOS LAS MICROCOMPUTADORAS

de la función informática de las empresas, opción que ya es reclamada con urgencia por la dinámica acelerada con que se están moviendo los modernos mecanismos administrativos dentro de las empresas de esta época. La tremenda movilidad que se está dando en los esquemas organizacionales de las empresas sugiere que dichas organizaciones están sufriendo vertiginosamente adaptaciones que tratan de ser congruentes con novedosos esquemas administrativos acordes COK lo que se ha dado en llamar "la empresa moderna"; lo que, en otras palabras, significa que la función informática tendrá necesariamente que cambiar; es decir, la informática tradicional ya no cumple con los requerimientos que están surgiendo en estas nuevas organizaciones que se están formando aceleradamente.

El concepto de sistematización ya no es posible gestarlo sólo en el área de informática. El tipo antiguo de sistemas de información nacientes sólo del área de informática ya no funciona en los nuevos esquemas ni se adapta con flexibilidad al ritmo de cambios que están sufriendo en sus estructuras las empresas actuales. Ahora se vuelve necesario que la informática se dé en cada unidad usuaria, es decir, en el terreno de los hechos. Por lo mismo, quienes deberán tener que sistematizar los mecanismos operativos valiéndose del hardware y software idóneos son los propios usuarios. Por tanto, el concepto de usuario de los sistemas de información también tiene que evolucionar. Ahora serán ellos quienes con sus propios medios y con la velocidad requerida automaticen la gran mayoría de sus actividades operativas. Esto no es una simple idea; es una necesidad actual que permitirá agilizar los procedimientos operativos, con miras a dar un servicio de excelencia hacia los múltiples clientes de las empresas. Aquellos que lo consigan, entonces y sólo entonces estarán preparados para competir en los años que se avecinan.

1. Principios de computación y operación del sistema Windows

Este módulo tiene básicamente dos objetivos. Primero, se persigue que el alumno aprenda los conceptos básicos del ambiente de microcomputadoras, con el fin de hacer que entienda que la computadora es un equipo sofisticado en su arquitectura, pero dicha complejidad no tiene que ver con el hecho de utilizar la computadora. En segundo término se le da confianza haciendo que él mismo la maneje mediante ejercicios de comunicación con la computadora, creándole hasta este momento la certeza de que prácticamente todo lo que está haciendo en dicha comunicación resulta sencillo. Esto se logra a través de ejercicios con el manejo de Windows.

SUGERENCIAS DE S O L U C ~ ~ N 31 1

Este módulo se aprovecha para explicar al estudiante el concepto de sistema, y para lograr que aprenda con claridad la manera como se identifica un problema administrativo que amerite ser automatizado, y los pasos ordenados que habrá que dar para transportarlo a la computadora para su resolución.

Temario del módulo I

Terminología utilizada en computación. Características de los componentes de una microcomputadora personal. Conceptos del sistema operativo Windows. Descripción de la estructura de directorios. Uso de comandos para crear, organizar, imprimir y depurar directorios. Uso de comandos para copiar, imprimir, mover y depurar ambientes de archivos en discos. Metodo para respaldo y recuperación de archivos. Estructuración y ejecución de grupos de comandos. Identificación de problemas y pasos por seguir para resolverlos en la computadora. Laboratorios de todos los puntos anteriores. Evaluación final del asistente.

Duración del módulo 1: 40 horas.

11. Operación de la hoja de cálculo

Con base en el módulo anterior, en este momento el alumno ya expe- rimentó la comunicación con la computadora y ya cuenta con la certifi- cación de que ha entendido los conceptos básicos, pues así está dise- ñado el módulo; es decir, no se permite pasar a un siguiente tópico hasta no haber logrado los objetivos previos. Las evaluaciones certificadas por los resultados obtenidos en la propia computadora nos dan esta garantía.

En este segundo módulo se le capacita al alumno primeramente en la operación del programa de hoja de cálculo, con el fin de que pueda crear archivos partiendo de la estructura de hojas de cálculo. Asimismo, se le enseña a procesar dichos archivos y a obtener resultados objetivos. Una vez logrado el manejo de la hoja mediante la estrategia anterior, ahora se procede a definir el planteamiento de un problema teórico, pero muy fácil de entender, con el fin de ir aplicando la metodología para lograr transportarlo a la computadora y finalmente obtener los resultados planeados. En este punto el alumno adquiere la capacidad, y además se convence de que lo que está haciendo requiere mucha atención, pero es

..1

31 2 CAP. 24. USEMOS LAS MICROCOMPUTADORAS

como si estuviera aprendiendo cualquier otra materia académica. La ventaja es que aquí lo está haciendo él mismo y está comprobando inrne- diatamente el resultado de sus acciones. Para afianzar los conceptos se hacen varias prácticas con distintos planteamientos. Lo importante es comprobar que aún sin el dominio de algún lenguaje de programación es factible automatizar en gran medida una oficina o departamento.

Temario del módulo II

Procedimiento para instalar el programa. Cómo entrar y salir del programa de Hoja de cálculo y cómo accesar una hoja de cálculo. Características de las hojas de cálculo. Operación para el movimiento del cursor y manejo de páginas en la pantalla mediante el mouse. Manejo y selección de menús de comandos. Creación y borrado de las hojas de cálculo. Captura de datos y fórmulas de proceso. Manejo de comandos para estructurar celdas. Manejo de comandos para copiar y mover celdas. Uso de comandos para insertar y borrar columnas y renglones de las hojas de cálculo. Comandos para imprimir las hojas de cálculo. Uso de teclas de funciones especiales. Definición de problemas y solución mediante el esquema de hojas de

' cálculo. Evaluación final del asistente.

Duración del módulo II: 60 horas.

111. Operación del procesador de textos

Este módulo tiene un objetivo concreto: adaptar al alumno al concepto de archivo magnético. Es evidente que el personal de oficina lo que más conoce y ha practicado por años es que el elemento de papel escrito es sin duda el objeto de mayor uso en dichos lugares, a tal grado que con frecuencia se tiran toneladas cuando rebasan la capacidad de almacenamiento; por supuesto, no sin antes dedicar días y semanas a una depu- ración Aun con mucho cuidado, el extravío de documentos importantes es mayor al que se pueda uno imaginar. Por otro lado, el esfuerzo para archivarlos y mantenerlos en orden para un fácil acceso es tan alto, que muchas veces es la actividad que mayor tiempo le toma a los oficinistas.


El concepto de arhvo magnético suprime de inmediato muchas actividades tradicionales y simplifica muchas otras, y ahorra además espacio Físico dedicado al archivo y, por supuesto, reduce enormemente los riesgos de extravíos.

Durante este módulo se le instruye al estudiante para utilizar el procesador de palabras, con el fin de lograr mayor velocidad en la mecanografía, correcciones mecanográficas instantáneas, eliminación del desperdicio de papel, y organización y consulta instantáneas del archivo. Se le capacita también para obtener escritos con presentaciones agradables a la vista y de muy alta calidad, al combinar distintos tipos de letras. Finalmente, se le enseña al alumno a combinar el procesador de palabras con archivos de datos, con el Fin de hacer comunicados masivos, personalizando cada carta con los datos de clientes, proveedores, destinatarios administrativos, etcétera.

Temario del módulo III

Procedimiento para instalar el programa Procesador de Texto. Cómo entrar y salir del Procesador de Texto y cómo crear documentos. Procedimiento para capturar textos. Operación para el movimiento del cursor y manejo de páginas en la pantalla. Uso de comandos para borrar textos. Uso de comandos para mover textos. Uso de comandos para copiar textos. Uso de comandos para insertar textos. Uso de comandos para grabar los textos en disco. Uso de comandos para búsqueda y sustitución de textos. Uso de comandos para im rimir textos. Uso de comandos para de /' inir un formato al documento. Uso de comandos especiales. Combinación de documentos y datos variables. Planteamiento de problemas y laboratorio. Evaluación final del asistente.

Duración del módulo 111: 40 horas.

IV. Operación de utilería de escritorio

Con el uso de estos programas de utilería se capacitará al asistente para: organizar, actualizar, consultar e imprimir agendas de citas, directorios telefónicos, bibliografía, documentos de oficina, control de actividades de empleados, control de asistencias, uso de calculadora, control de gastos y actividades muy rutinarias en general. El objetivo es simplificar el esfuerzo y reducir el tiemoo oara llevarlas a cabo.

Temario del módulo IV

Procedimiento para instalar el programa de escritorio. Características generales y modo de ejecución del programa. Manejo de ventanas (windows). Operación de la calculadora. Operación del calendario y la agenda. Operación del cuaderno de notas y recados. Operación del directorio telefónico. Planteamiento de problemas y laboratorio. Evaluación final del asistente.

Duración del módulo 1V 40 horas.

V. Administración de un ambiente automatizado en computadora

En este módulo se enseña al alumno las técnicas necesarias para lograr la administración de un ambiente automatizado, de tal manera que obtenga el máximo provecho al aplicar lo aprendido en los módulos anteriores. Se le prepara así para: documentar los trabajos hechos en la computadora; depurar y mantener un ambiente confiable de archivos generados en sus dispositivos de disco; recuperar datos perdidos por daños físicos de su computadora o por errores cometidos, establecer nomenclaturas de identificación requeridas en actividades de computación; dise- ñar formatos de apoyo para Facilitar la automatización y, en general, tener la disciplina necesaria para el buen uso de los recursos de cómputo.

Temario del módulo V

Metodología para la administración de los elementos que intervienen en la automatización de los sistemas de información. Nomenclatura de control para la automatización. Técnicas de seguridad de datos. Estrategias de respaldo y recuperación de archivos. Metodología en el desarrollo de sistemas de información. Técnicas de documentación. Aplicación de los conceptos anteriores a un problema real con base en las necesidades de información de la oficina en la que trabaja el propio asistente.

Duración del módulo V 40 horas.

RESUMEN

En conjunto, los cinco módulos permiten al personal secretaria1 y operativo de oficina hacer un uso efectivo de la microcomputadora, para automatizar gran parte de las operaciones administrativas de un departamento o gerencia. Debe apreciarse que cada módulo de capacitación se entrelaza con los otros; es decir, es una capacitación integral que hace que se aprecie como un todo y no como simples cursos aislados.

Seguirnien to

Una vez terminada la capacitación, deberá asignarse un coordinador cuyo propósito sea hacer un seguimiento efectivo con el fin de comprobar que quien ya es diplomado en computación, verdaderamente emprenda la aplicación de sus conocimientos, y aquél lo asesorará para que inicie un análisis de requerimientos de su propia oficina o departamento. Asimismo, el coordinador deberá hacer visitas periódicas con el objeto de comprobar la eficiencia del uso de la computadora por parte del diplomado y, en su defecto, analizar las causas de una baja productividad, y tomar medidas correctivas. El objetivo es no permitir que se desperdicie lo aprendido, sino que por el contrario, se amplíe el buen uso de la computadora. Fomentar la disciplina en el buen uso de los recursos de cómputo por parte de los usuarios operativos, en gran medida también depende de la motivación que generen los jefes o gerentes de los distintos departamentos y, por supuesto, de la creatividad de ellos para hacer que la computadora sea utilizada en la solución de los verdaderos problemas de cada área.

RESUMEN

La "moda" de las microcomputadoras nos tomó por sorpresa y, dado que no aprendimos de nuestra triste experiencia en la década de los sesenta con las primeras computadoras, ahora volvemos a repetir la historia, precipitándonos a inundar las oficinas con estos equipos, creyendo que con una capacitación superficial y no planeada, los usuarios de nivel operativo podrán sacarles realmente provecho. Los resultados de esta experiencia (no podemos decir "esta estrategia" porque no la hubo) nuevamente se coronaron con un enorme despilfarro en todos los sentidos. Sin embargo, aquellos que de alguna manera quisimos participar en rescatar algo de lo mucho desperdiciado, exploramos un plan de capa- citación integral en el nivel de diplomado, el cual, por los resultados satisfactorios obtenidos, ponemos a disposición en este capítulo.

Insistimos en que el temario aquí expuesto es sólo una sugerencia, y puede ser complementado o afinado. Sin embargo, la experiencia nos demostró que bien llevado a la práctica, el objetivo se cumple cabalmente.

CAP 24. USEMOS LAS MICROCOMPUTADORAS

Debe destacarse que el elemento más importante de este plan de capacitación es el seguimiento posterior, con el Fin de supervisar la correcta aplicación de los conocimientos, directamente en las labores diarias de quienes recibieron el diplomado. Sin este elemento de seguimiento, comprobamos que los estudiantes no llegan, en su mayoría, a ser productivos en el uso de la computadora, y un alto porcentaje termina por dejarla en el olvido o en un aprovechamiento muy ligero.

Funciones y responsabilidades del área de informática

Problema

Muchos de los integrantes del hrea de informática trabajan por órdenes de trabajo, según se van presentando, y no por conocimiento de sus funciones y responsabilidades que enmarquen los objetivos concretos que los justifiquen claramente dentro de la organización.

Cuando en el área de informática no existe la definición precisa de funciones y responsabilidades, es muy difícil distinguir los lírnites de trabajo que deberá cubrir cada departamento. Esto origina una tendencia muy alta a la asignación empírica de las actividades por desarrollar para la culminación de cada proyecto; y en consecuencia, a delegar la mayoría de las actividades en los técnicos más capacitados, convirtién- dolos así en "todólogos"; es decir, aunque determinadas actividades no recaigan dentro del marco de responsabilidad de éstos, por su capacidad técnica, las absorben tan sólo porque les fueron asignadas, aunque esto desequilibre las cargas de trabajo, ya que mientras a ellos se les satura, otros técnicos permanecen inactivos

Otro problema resulta cuando algún técnico es controlado y empieza a recibir asignación de trabajos a diestra y siniestra y sin una orientación específica de un puesto claramente definido. Esto lo desorienta y no logra distinguir cuáles son sus funciones y responsabilidades, y cuáles sus límites de acción. Simplemente, lo absorbe la desorga-

CAF! 25. FUNCIONES Y RESPONSABILIDADES

nización del área de informática y al poco tiempo es un "todólogo" más, inmerso en la terrible confusión que impera.

Este esquema elimina prácticamente la posibdidad de estructurar planes de capacitación por objetivos, ya que en cierto momento todos hacen de todo, y nunca sabrán cuál será su avance dentro de esa desorganización.

El peligro a que conduce esta situación salta a la vista para aquellos que lo observan desde afuera. Sin embargo, adentro todo es tan confuso que se dejan llevar simplemente por la inercia del terrible descontrol, hasta que tarde o temprano el área de informática se vuelve inestable. Esto lo detectan cuando comienzan las inconformidades personales; las renuncias en masa; el incumplimiento de los satisfactores de informa- ción hacia los usuarios; los problemas frecuentes de falla en procesos de producción, los cuales día con día se acumulan; la impotencia para organizar en situaciones de crisis; etc. En ese momento nadie se siente responsable de lo que está sucediendo, sino hasta que alguien decide afrontar el problema y establece, como única medida sensata, que la solución es estructurar cada área de acuerdo con responsabilidades y funciones que permitan distinguir claramente quién, cuá.do hasta dónde deberán cubrir cada fase de un proyecto dado. I

- ii m

SUGERENCIAS DE SOLUCI~N y- d-+

En estos casos no es tan difícil proponer una solución, lo difícil es estructurar el esquema funcional de la organización a través de un planteamiento integral, en el cual se vislumbren los distintos departamentos que deben conformar al área de infomática: la descripción de cada puesto, la descripción de su responsabilidad concreta y la defini- ción de actividades de detalle que deberán cubrir para lograr la correcta consecución de los objetivos por los que cada puesto fue concebido.

RESUMEN

Cuando en el área de informática no existe la definición precisa de las funciones y responsabilidades de cada departamento, se origina una tendencia muy alta para la asignación empírica del trabajo. Así nacen los "todólogos", quienes sólo destapan un hoyo para tapar otro, sin concre- tar ningún trabajo. Asimismo, cuando un inforrnático nuevo es contratado, se le empieza a asignar trabajo a diestra y siniestra y sin orientación específica. Esto lo desorienta y es absorbido por la terrible desorganiza- ción de la instalación, así nace otro "todólogo". Este esquema elimina prácticamente la posibilidad de estructurar planes de capacitación por objetivos. Será necesario que los jefes instrumenten un or anigrama

nes y responsabilidades que deberá cubrir (véase apéndice). H funcional donde se pueda justificar cada puesto con base en as funcio-

Problema

N o existe excelencia en la función informática.

Antes de entrar en materia, debo aclarar que voy a reiterar parte de la información que ya ofrecí en los primeros capítulos. Esto es necesario, ya que a esta altura es probable que el lector haya olvidado algunos detalles de importancia. En este capítulo se concentran los conceptos más sobresalientes del libro, por lo que se recomienda especial atención.

Como se habrá percatado el lector, los temas tratados en el presente trabajo reflejan una realidad expuesta con frialdad, que incluso pudo haber llegado a incomodar a aquellos que de alguna manera se identifi- caron como partícipes de alguno o varios problemas aquí descritos. Pero como fue señalado al principio del libro, no se trata de ver hacia atrás con el propósito de encontrar culpables; por el contrario, los errores vistos como ex eriencias son los resortes impulsores que permiten f encontrar las so uciones; ofrecen sobre todo la valiosa oportunidad de participar en la consecución de dichas soluciones; y en el trayecto que incluso puede resultar agotador, poner a prueba nuestra capacidad profesional y beneficiar tanto a nuestros centros de trabajo como a nosotros mismos con ese nuevo cúmulo de experiencias que encontra- remos en el camino.

Por otro lado, confío en que los estudiantes hayan comprendido, a costa de nuestras deficiencias técnicas, la enorme cantidad de trabajo

CAF! 26. EN BUSCA DE LA EXCELENCIA

que falta por hacer, y adviertan que les espera un amplio campo de acción, que visto otra vez como oportunidad, representa un trayecto sumamente apasionante, el cual, si se descubre con esfuerzo, tesón y constancia, el futuro de la informática en nuestro país será más promisorio.

Al titular este último capítulo del libro "En busca de la excelencia en la función informática" deseo destacar la enorme importancia que representa esta tecnolo ía como acelerador del desarrollo de un país.

Si se parte de la %ase de que los países en vías de desarrollo heredaron dicha tecnología, adquirida sin haber pasado por el laborioso y costoso proceso de investigación que realizaron sus descubridores, no es admisible que se desperdicien sus bondades al hacer un uso deficiente, muchas veces tendiente al despilfarro Por eso es importante reconocer que la función administrativa en las áreas de informática podrá servir de indicador para detectar el nivel de eficiencia del uso de los recursos de cómputo o, en su defecto, el grado de desaprovechamiento y, peor aún, el grado de despilfarro.

En busca de la excelencia en la función informática quiere decir: entender esta tecnología; reconocer su importancia como impulsora de las demás tecnologías y, sobre todo, obtener el máximo provecho al aplicarla. También significa: aceptar que es una tecnología nueva en nuestro país, cuya difusión ha sido lenta, sobre todo en el ámbito educativo; reconocer que no estamos preparados académicamente para el nivel que reclama su complejidad; comprender que no se le ha dado la importancia que merece. Pero ante todo indica que nos hemos dado cuenta de que sin esta tecnología ningún país saldrá del subdesarrollo; que estamos dispuestos a reconocer su importancia y a promover su comprensión en las escuelas; que estamos dispuestos a pagar el precio de sus beneficios, aceptando que su utilización requiere un alto grado de especialización y no puede tolerarse la improvisación al respecto.

En la década de los noventa muchos países, entre ellos México, emprendieron su modernización. Su objetivo era entrar al nuevo milenio con un nivel tal de competitividad que permitiera subir peldaños de prosperidad y acercarse lo más posible al bloque de los países más desarrollados. No hacerlo significaría no sólo rezagarse, aumentando así la distancia tecnológica entre unos y otros, sino que sería tremendamente peligroso para la humanidad la existencia de más países consumidores que productores.

Parte de la estrategia de modernización consiste en abrir las econo- mías, de tal forma que otros países inviertan grandes capitales en industrias y en un sinnúmero de empresas, con el fin de incrementar la producción, aumentar las fuentes de trabajo, promover el comercio internacional, reactivar la economía, etcétera.

RESULTADOS MÁS RECIENTES m 321 m

Visto desde otra perspectiva, si existen más ?nduttrías, comercios, transacciones económicas, producción, empleos y dinero, habrá mucho más intercambio y control de información. $Qué se deduce de esto¿; sencillamente que el uso de las computadoras se incrementará considerablemente. Y $qué importancia tiene lo anterior<; significa una gran responsabilidad para los informáticos del país, ya que los recursos tecnológicos para proceso de datos que habrán de introducir los inversionistas extranjeros serán los más modernos y complejos de la actualidad. Por principio, debemos preguntarnos si existen suficientes técnicos y profesionales en informática para estos nuevos centros de computo. Segundo, jnuestro nivel tecnológico nos permitirá rápida- mente ser diestros en el uso de esos nuevos equipost Tercero, si no es así, jnos estamos preparando para ese momento¿ Sinceramente no tengo la respuesta. En lo que sí puedo colaborar es en dar a conocer los últimos resultados de mi investigación sobre administración de la función informática, con el fin de recomendar mis experiencias para reducir el despilfarro computacional, y en la medida de las acciones por emprender, lograr un mayor nivel de excelencia en la función informática, al realizar un uso más eficiente de los recursos de cómputo que tenemos a nuestra disposición actualmente. Mi propósito es que cuando esté en auge la modernización del país, hayamos alcanzado un mayor grado de madurez en materia de informática, y estemos ya en mejores posibilidades de ser eficientes en el uso de la nueva tecnología que llegue, pero no como simples operadores de ella sino aplicándola con estricto apego a los objetivos de negocio de las empresas mexicanas.

RESULTADOS MÁs RECIENTES DE MI INVESTIGACI~N SOBRE ADMINISTRACI~N DE LA FUNCIÓN INFORMÁTICA

Antes de comenzar con la descripción de estos resultados, quiero mencionar que en octubre de 1989 tuve la oportunidad de ofrecer una conferencia en el evento internacional Compumundo 89, celebrado en el salón de la informática del hotel MarlaIsabel Sheraton de la ciudad de México. Allí expuse los resultados de mis investigaciones entre conocidos especialistas en informática y directivos de los centros de cómputo más grandes del país. Los comentarios con los que fui retroalimentado certih can la veracidad de mi exposición, porque no sólo conseguí el acuerdo uná- nime, sino la disponibilidad para poner en práctica mis recomendaciones.

Meses después comencé a tener las primeras noticias sobre la puesta en marcha de la estrategia recomendada en mi estudio, y los resultados han sido considerablemente eficaces, y sobre todo positivos casi de inmediato. Por eso, estimo útil hacerlo extensivo a los lectores, con el firme propósito de aportación.

El objetivo es demostrar que la falta de la función administrativa global en el área de informática es la razón básica de los errores que en ella se cometen.

Para lo anterior, se partirá de la siguiente proposición:

El área de informática no está administrada.

Parecería que la anterior es una aseveración demasiado aventurada; sin embargo, fue la conclusión rotunda que arrojó el estudio.

Empezaré por señalar al unos puntos sumamente irnpoí-tantes sobre la representatividad que a alcanzado el área de informática dentro de las instituciones:

E a) En sí, el área de informática representa una entidad dentro de la

empresa, la cual tiene como objetivo satisfacer los requerimientos de información de la misma.

b) Su función primordial es sostener con eficiencia la labor adrninistra- tiva de la empresa, para hacerla más segura, fluida y simplificada.

c) En el área de informática recae la responsabilidad de la centrali- zación, custodia y proceso de la mayoría de los datos con los que opera la empresa.

d ) Prácticamente la mayoría de las actividades del resto de las áreas de la organización toman como base para su operación la informa- ción que le provee el área de informática.

e) La toma de decisiones en los distintos niveles se ve influida por la calidad que posea la información y por la capacidad de respuesta del procesamiento de datos.

f ) En gran medida, la eficiencia del área de informática representa el nivel de sistematización operativa y de control alcanzado por la empresa

g) La importancia que adquiere el área de informática dentro de la organización la compromete fuertemente en las decisiones administrativas y de proyección de la empresa.

Si se observa con cuidado lo anterior, llegamos a la siguiente conclusión:

. El área de inhormática es uno de los engranes vitales dentro de la organización, el cual hace que muchos otros se detengan o caminen sistemáticamente.

Si en este momento evaluamos la afirmación: "El área de informá- tica no está administrada", y las consecuencias en el sentido de "es la razón básica de los errores que en ella se cometen", y las confrontamos

con "la importancia del área de informática dentro de la organización", resulta estremecedor imaginar el altísimo costo y las graves repercusiones de dicha situación.

Ahora hagamos un análisis de cómo fue identificado el problema y por qué se llegó a tal afirmación.

Esto surgió como resultado de una profunda investigación que me fue solicitada por el director del área de informática de una de las empresas más grandes del país. Allí encontré lo siguiente:

1. Evaluación de los compromisos de trabajo.

a) La mayoría de los jefes del área de informática se compro- metían a entregar resultados en tiempos récord, y muy Fre- cuentemente no consideraban la opinión de los que realrnen- te lo harían, simplemente lo exigían anteponiendo su autoridad.

6) En otros casos, resultaba que dichos jefes prácticamente no tenían otra opción más que aceptar los tiempos marcados por los directivos de mayor nivel de la organización. Se detectó que esto se derivaba del distanciamiento y poco conocimiento que sobre Ias labores del área de informática tenían dichos directivos.

2. Equilibrio de las cargas de trabajo.

a) Con frecuencia había saturación de trabajo por falta de controles efectivos, razón por la cual prácticamente no exis- tía labor de investigación orientada al mejor aprovechamien- to de los recursos de cómputo, pese a que era evidente una utilización deficiente.

b) En forma contradictoria, mientras ciertas áreas estaban satu- radas de trabajo, otras permanecían inactivas.

3. Evaluación del hardware y el software.

a) Se detectó que se había adquirido mucho software, su utili- zación era escasa y varios productos prácticamente no eran utilizados; es más, la mayoría de los técnicos desconocían que existieran. La sorpresa fue mayor cuando se encontró que aún se pagaba renta de algunos que nunca se utilizaban.

6) Al no haber mediciones o no ser reales, en cuanto a la creciente saturación de hardware, con Frecuencia se precipi- taba su adquisición cuando comenzaban los cuellos de bote- lla en la producción y10 los tiempos de respuesta de los sistemas on line se tornaban críticos.

324 CAP 26. EN BUSCA DE LA EXCELENCIA

4. Los métodos de trabajo.

a ) Se encontró que, en caso de que los hubiera, éstos eran muy superficiales y carecían de una correcta documentación, razón por la cual no existía un nivel de calidad estándar en el desarrollo de los trabajos, obligando muchas veces a la improvisación.

b) Debe decirse que en algunas áreas se encontraron manuales de control perfectamente documentados, pero algunos no se respetaban, dadas las cotidianas prisas.

5. Control de cambios.

a ) Pese a la importancia de este punto, frecuentemente cuando por fallas de programas se necesitaban correcciones, o cuando por la dinámica operativa y de vigencia de los sistemas se requerían cambios, la mayoría era realizada en forma apresurada mediante reparaciones improvisadas, bajo controles superficiales o simplemente sin control.

b) Lo anterior ocasionaba reprocesos por nuevas fallas o resultados incorrectos, muchos de ellos detectados no en el área de informática sino hasta que el usuario recibía la información de los procesos.

6. Elaboración de programas.

a) Cuando se analizaron los reportes estadísticos sobre la cantidad de veces que se requería compilar y probar los programas en desarrollo, nunca imaginamos lo que íbamos a encontrar. El promedio de compiIaciones para depurar un programa nuevo consistía en 50 entradas a la computadora. Por si fuera poco, las entradas que se efectuaban durante la etapa de pruebas, hasta lograr los resultados correctos, superaban las 85.

b) Entonces comprendimos por qué había una computadora de capacidad considerable, exclusiva para el desarrollo de sistemas.

7. Operación de sistemas.

a) Respecto de la operación de los sistemas en producción, se detectó que la preparación de los elementos necesarios para los procesos en batch se realizaba generalmente hasta el momento de las corridas, lo cual al hacerse en forma precipitada generaba constantes errores.

b) Las personas que tenían a su cargo esa labor eran técnicos de bajo nivel en la mayoría de los casos, lo cual resultaba insólito, sobre todo cuando precisamente la culminación del tremendo esfuerzo del análisis de sistemas, programación y

puesta en marcha de dichos sistemas se da en el momento de la producción real de los procesos. No es admisible que por la poca preparación de estas personas se vea altamente deteriorada la eficiencia de esos sistemas.

c) Se encontró que además no era adecuada la calidad de los instructivos para la operación de los sistemas, cuando éstos existían; porque había varios sistemas que carecían de ellos.

8. Análisis y diseño de sistemas.

a) A este respecto, era evidente que no se seguía un método estándar bajo el cual se pudiera garantizar que todos los sistemas, sin excepción, serían administrados durante su desarrollo y su puesta en operación.

6) Durante las pláticas con algunos usuarios, hubo comentarios acerca de que varios sistemas les fueron impuestos, y que en la práctica los resultados de éstos no satisfacían plenamente los requerimientos de información; de esta manera, varios resultados jamás eran utilizados.

c) Se identificó la gravedad de que varios sistemas partían de problemas supuestos en donde no se había hecho un análisis profundo, por lo que con el tiempo originaban ajustes frecuentes, debido a la poca previsión que se tuvo.

d ) Se encontró que en no pocos casos se desarrollaban sistemas para áreas que no estaban todavía administrativamente estabilizadas. Dicho fenómeno por supuesto puso en duda la efectividad de estos sistemas.

9. Administración de archivos.

a) La nomenclatura utilizada para identificar cada archivo no estaba sujeta a estándares.

6) Lo anterior originaba la saturación injustificada, principalmente en los paquetes de disco.

c) Dicho desorden complicaba terriblemente la depuración sis- temática de archivos; entonces tenía que realizarse en forma manual, con la consiguiente incertidumbre y riesgo constante de pérdida de información valiosa, lo cual ya había ocurrido en no pocos casos.

d ) Otro problema generado por tal situación consistía en las equivocaciones frecuentes, ya fuera al correr programas de versiones obsoletas, al accesar librerías de versiones viejas, parámetros erróneos, etcétera.

326 CAF! 26. EN BUSCA DE L4 EXCELENCIA

e) En ese ambiente de confusión era evidente que la confidencialidad, integridad y seguridad de los datos resultaba prácticamente nula.

10. Administración del sistema operativo.

a) Se descubrió que se instalaban sistemas operativos no depu- rados, los cuales tenían muchos errores de diseño, para los que generalmente ya existían las correcciones; sin embargo no se realizaba en forma anticipada la investigación corres. pondiente.

b) Cuando atinadamente se descubrían algunos errores del sistema operativo y se aplicaban las correcciones necesarias, éstas no eran probadas en forma rigurosa; y como es sabido, algunas correcciones originan otros errores.

c) Cuando se decidía migrar de una versión a otra, ya fuera por demasiados errores en la anterior o facilidades útiles en la nueva, generalmente no pasaba por un examen de pruebas masivas; por tanto, en la nueva versión ocurrían fallas que en la anterior no habían sucedido. Por supuesto que esto llegaba a crear descontrol y pérdidas cuantiosas en los procesos.

d ) En muchas ocasiones permanecían los mismos parámetros de control de la versión de un sistema operativo anterior, s610 para desperdiciar Ias nuevas facilidades con que contaba el más reciente. También sucedía que se dejaban los parámetros de la nueva versión tal y como era recibida del distribuidor y tiempo después se detectaba que éstos no eran congruentes con las características particulares de la configuración de equipo con que contaban. Para entonces, ya habían surgido problemas.

11. Las bases de datos.

a) En la instalación donde se realizó la investigación, se acudió . al historial con el fin de conocer qué proceso se utilizó en la migración a las bases de datos. Se encontró que no había ningún estudio que estableciera el plan bajo el cual se traba- jó. Se concluyó así que no se había hecho conciencia de sus implicaciones.

b) Se detectó que efectivamente ya estaban trabajando en un ambiente de base de datos, pero que su explotación era deficiente. Las razones para esta afirmación se fundaron en las siguientes observaciones:

Era una base de datos "forzada", es decir, que simplemente habían convertido sus archivos tradicionales al nuevo

RESULTADOS MÁS RECIENTES

ambiente, acarreando mucha de la redundancia de datos que ya existía. Por lo anterior, los nuevos sistemas prácticamente seguían siendo independientes, con el consiguiente desperdicio del enorme potencial que las bases de datos ofrecen en los sistemas integrales.

Con todos los datos anteriores se realizó un documento, en calidad de informe preliminar, el cual fue presentado en una junta donde acudieron los distintos departamentos investigados. El objeto era sensibilizar a los jefes, con el acuerdo de que no se malinterpretara el informe, ya que reflejaba una realidad lastimosa en donde sólo se hablaba de la parte negativa. Pero se les aclaró que la razón de esto era encontrar las causas con el fin de subsanar las deficiencias detectadas, lo cual redundaría en beneficio de todos.

El primer paso para lograr lo anterior era aceptar o desmentir las deficiencias señaladas. Se acordó que se iban a analizar punto por punto hasta lograr un consenso general sobre los problemas reales, y apartar aquellos que resultaran aparentes. Al final de la reunión se concluyó que la mayoría de los puntos eran verdaderos. Esto representó el primer gran avance, es decir, la aceptación de que la investigación era veraz.

Se tuvo mucho cuidado de no aventurar de manera precipitada estrategias de solución, ya que esto se había intentado en el pasado un sinfín de ocasiones sin haber logrado los resultados deseados.

Ahora el siguiente paso era identificar las causas reales, incluso aparentes, con el fin de partir de bases firmes hacia la determinación de las posibles opciones de solución.

REMOCI~N DEL HISTORIAL DEL h E A D E INFoRI~TIcA

De momento caí en un dilema. iPor qué existían tantos errores, aun cuando el personal del área de informática era de buen nivelt, $por qué no había resultado efectiva ninguna estrategia de solución, o habiendo sido efectiva al principio, luego decaíat, ?por qué, si todos los puntos que se encontraron eran conocidos, y ante los ojos de los jefes resultaban ciertos, no mejoraban las cosas de manera permanente¿

Concluí que cualquier estrategia tradicional de solución que reco- mendara seguramente ya se había intentado, y por supuesto no habría sido necesaria semejante investigación para simplemente decir: "Seño- res, pónganse a trabajar de una manera más profesional y verán que

CAP 26. EN BUSCA DE LA EXCELENCIA

todos los problemas desaparecerán."No, esto no solucionaría nada; es más, la mayoría del personal se desempeñaba con un alto sentido profesional. Entonces, icuál podría ser la solución adecuadat, o peor aún: 3110 existía soluciónt, ?era un mal necesario<

Poco a poco me encaminé hacia una idea, que en principio ya había desechado en varias ocasiones; pero al no encontrar mejor opción decidí acogerla con el convencimiento previo de que ahí encontraría algo.

La idea consistía en acudir al historial del área de informática con el propósito ya más claro de que las verdaderas razones de los problemas ahí estaban, y que por lo mismo no eran fácilmente identificadas por el personal actual, ya que la mayoría era de reciente ingreso. Por esto, me dirigf al ersonal de mayor antigüedad, que por suerte ocupaba los puestos 1 e más alto nivel. Por supuesto que al principio no resultó fácil, ya que había mucha renuencia a proporcionar información que a veces se calificaba de confidencial. Poco a poco fui construyendo el rompecabezas, valiéndome de varios documentos y memorandos que conseguí, y encontré lo siguiente:

Aproximadamente entre diez y doce años atrás, el área de informá- tica se había formado con los siguientes departamentos.

k p r i m í ~ del

usuario

Por espacio de dos años aproximadamente el esquema fue el mismo, y aunque hubo algunas variantes, éstas no fueron significativas. Sin embargo, con la aparición de los sistemas on line súbitamente el panorama cambió, y la organización del área de informática adquirió la siguiente estructura:

332 CAK ~ b . EN BUSCA DE LA EXCELENCIA

Los efectos de la incorporación de los sistemas on line, Fueron los siguientes:

Hubo cambio de organización en el área de informática. Se estabIecieron especialidades. Los procedimientos de control tuvieron una variación drástica. Se establecieron nuevos estándares de trabajo. Se incrementó el número de usuarios. Se incrementó la configuración del equipo de cómputo. Las cargas de trabajo aumentaron, ya que varios sistemas batch pasaron a ser on line. El personal del área de informática aumentó a 28.

Como puede notarse, dentro de la institución el área de informá- tica adquirió mayor importancia, debido a que alcanzó el nivel de gerencia.

Transcurridos dos año más o menos, cuando esta nueva estructura todavía no se consolidaba plenamente, el impacto de las bases de datos y los adelantos en el hardware y software volvieron a conformar una nueva estructura en el área de informática (véase organigrama correspondiente a la etapa 111).

Los efectos fueron los siguientes:

Cambio de organización nuevamente. Cambio de procedimientos de control. Cambio de métodos de trabajo. Cambio de Funciones y responsabilidades. Las cuotas de producción se elevaron. Se abrieron más horarios de servicio. Hubo más usuarios. El personal del área de informática aumentó a 40.

Obsérvese que ahora (en la etapa 111) el área de informática participa en el nivel de subdirección dentro del esquema organizacional de la empresa.

Esta organización Fue también temporal, pues en lapsos breves cam- bió dinámicamente hasta alcanzar el nivel de dirección, bajo la cual existían varias subdirecciones, de las cuales, para abreviar, sólo se es- quematizan dos de ellas; la complejidad de su estructura salta de inmediato a la vista.

Las dos subdirecciones, de entre las seis que existían al momento de realizar la investigación, se conformaban como se ilustra en e1 organigrama de la etapa IV.

Al momento de la investigación, en 1 situación destacaba lo siguiente:

La cantidad de controles era muy complicada y confusa. Las funciones, responsabilidades y límites de acción no estaban daros. De alguna manera se presentaban confrontaciones entre departamentos. La organización requería cerca de 70 personas. El tipo de errores se diversificó y la cantidad se incrementó.

Con base en los datos que arrojó la búsqueda en el historial del área de inforrnática, detecté indicios de lo que sucedía en dicha instalación. Era, con mucho, consecuencia de las circunstancias en las cuales se fue creando la compleja estructura; pero más importante aún, de la tremenda improvisación que originó este crecimiento, para el cual no había existido previsión, ni mucho menos una estrategia planeada; es decir, se adoptó una tecnología nueva en forma tan rápida que la preparación de los técnicos se fue adquiriendo casi de manera emergente sin haber dedicado el tiempo necesario para establecer estrategias de control y de administración de los recursos técnicos, humanos y materiales. Por eso no se adquirió madurez; el objetivo básico se centró en explotar, a como diera lugar, dicha tecnología. Y efectivamente, hubo resultados a corto plazo, pero a un costo muy elevado. Esto se convirtió en un modo permanente de trabajo. Hasta ahora, las cosas siguen casi iguales, y aunque es cierto que se ha intentado una mayor eficiencia en la explotación de los recursos técnicos, poco se ha logrado, debido a que se ha arraigado el método de trabajo de muchos años.

Las observaciones concretas a las que se Uegó después del análisis histórico del área de informática las resumí como sigue:

Dentro de una organización (la de la empresa) había nacido otra organización (la del área de informática). La organización del área de informática s @ f ~ W , o r etapas y en forma improvisada. Cada departamento del área de informática se autoadministraba con independencia casi total. Resultaba muy difícil comprender la interrelación global de todos los departamentos del área de inforrnática. El esquema organizacional sigue móvil actualmente.

Como consecuencia de lo anterior, detallé un documento que denominé uResultados finales de la investigación", el cual contenía todo lo expuesto en el informe preliminar, analizado anteriormente con los jefes de cada departamento, lo cual daba veracidad acerca de la deterio-

336 CAP 26. EN BUSCA DE LA EXCELENCIA

rada situación que en dicho documento se reflejaba, avalado por las firmas de cada uno de los jefes. También incluí la explicación de las conclusiones surgidas en el historial.

El documento se lo entregué al directivo solicitante de la investiga- ción, quien me pidió una semana para revisarlo con detenimiento, bajo el acuerdo de que no lo comentaría con ninguno de sus subalternos, hasta que él y yo tuviéramos claramente definidas las medidas por tomar.

Transcurrida la semana, acudí a la cita previamente acordada, y me encontré ante un directivo sumamente serio; con tranquilidad me pidió que Fuéramos a la mesa de juntas. Me dijo: "He leído una y otra vez este documento, y conforme más lo repaso, menos lo entiendo", esperó un momento, y corrigió: "Mejor dicho, menos lo quiero entender; siento que lo que me quieres decir es que mi área de informática no está administrada, jte das cuenta de lo que eso significa para mít jMe quieres decir que no he cumplido con mi trabajot" Levanté la mano en señal de pedir la palabra, y le dije con voz tranquila: "Señor director, yo no he imaginado siquiera que usted no ha cumplido con su trabajo, sin embargo, ya lo dijo, su área de informática n o está administrada, y créame que después de mucho analizarlo ésta fue la conclusión rotunda a la que he llegado. Como habrá notado, tal aseveración no está en ninguna parte del documento que tiene en sus manos; pero resulta sorprendente que lo que usted ha intuido, es precisamente lo que explico en este nuevo documento que le traigo; en donde también establezco la única solución viable que se me ocurre. Por supuesto, he considerado todos los detalles de mi investigación y con base en más de 15 años de experiencia, concluyo que será necesario experimentar su efectividad." De inmediato agregué, sin dar oportunidad a que me interrumpiera: "Por desgracia habrá necesidad de experimentar la estrategia que propongo, ya que no conozco ninguna instalación que la tenga en práctica actualmente, pero lo que sí le aseguro es que se basa en un hecho real que se ha estado aplicando desde hace mucho tiempo con resultados muy efectivos, pero se aplica sólo en momentos, es decir, es un remedio al que se ha recurrido por excepción y no como función, y esto último es exactamente lo que yo establezco como solución permanente para reducir los errores y minimizar sus efectos lo más posible. No garantizo que mi estrategia elimine los errores de su área de informática, porque eso por desgracia no es posible, pero estoy seguro de que la situación debe mejorar sustancialmente; y algo más, si mi estrategia no es efect?va, en poco tiempo se sabrá, porque de igual manera, si en verdad es acertada, los resultados se verán de inmediato." A continuación procedí a explicar mi sugerencia, misma que conforme se la describía acaparaba su interés; hasta que terminada mi exposición, dijo: "Me cuesta trabajo creer que la solución sea tan sencilláypero encuentro todas las evidencias lógicas, mismas que no puedo objetar, ya


que demuestran un alto sentido común." Luego agregó: "Sobre todo, lo que más me impresiona es que su puesta en marcha resulta considerablemente económica, por lo cual, aunque no diera los resultados deseados, bien vale la pena experimentarla; sin embargo, todo parece indicar que algún buen resultado puede esperarse de esto."

La estrategia se puso en marcha en forma paulatina, y aunque no había pasado mucho tiempo, los resultados positivos fueron inmediatos; y se puede percibir que si la estrategia no es abandonada, posiblemente esté abriendo un nuevo campo de acción para los informáticos actuales. Dicha estrategia se describe a continuación.


Crear un departamento ex profeso para la administración del área de informática como staff de la dirección.

El objetivo de ese departamento será implantar un mecanismo administrativo completo, en el cual se considere la organización del área de informática en su entorno global.

La función básica de este departamento será hacer el seguimiento de cualquier evento problema que tenga que ver con la responsabilidad y10 el servicio del área de informática.

La estrategia es que dicho seguimiento sea permanente desde el nacimiento del evento hasta lograr su control, y dejar establecido un procedimiento confiable de prevención.

Argumentos de las sugerencias

Cuando existe algún problema en el área de informática, y éste es atendido, invariablemente es resuelto. En otras palabras, no existe un problema en el ambiente de informática en el que de alguna manera no haya una opción de solución.

Se ha comprobado que cualquier departamento problema del área de informática, al cual se le asigna un auditor, en corto tiempo norma- liza su Funcionamiento.

Proyectos complejos del ámbito informático que Fueron administrados en forma permanente durante su desarrollo se han realizado con un alto grado de eficiencia.

Lo anterior demuestra que mientras existe un seguimiento efectivo, hay avance positivo. Por otro lado: si un problema se ataca, pero no se deja establecida una estrategia de control, vuelve a aparecer.

Si se establece una estrategia de control y no se le da seguimiento para su cumplimiento, pronto se abandona.

338 CAP 26. EN BUSCA DE LA EXCELEWCIA

Proyectos administrados y cuhinados exitosamente, pero que se descuidan, con el tiempo decaen.

Lo anterior significa que si no se establece el seguimiento efectivo y permanente, se tiende al retroceso.

En función de los argumentos anteriores, Ilegué a la conclusión de que el concepto de seguimiento es el mecanismo más importante dentro del contexto de cualquier función administrativa. Obsérvese la siguiente definición y la equivalencia que descubro, como carta válida de la eficiencia administrativa.

La definición que se da del concepto administrar, en forma sintética, es la siguiente: establecer mecanismos de control necesarios para el cumplimiento de actividades. Lo que en otras palabras sencillas equivale al seguimiento. Pero no un seguimiento por excepción, sino como función, ya que eso es lo que reclaman los mecanismos de control.

Lo anterior me llevó a otro descubrimiento no menos importante, del que existe suficiente evidencia en los resultados de mi investigación. La mayoría de los errores detectados en el área de informática investi- gada eran atendidos al momento de surgir, y se hacía un seguimiento persistente durante la búsqueda y aplicación de la solución. Una vez encontrada ésta y aplicada, en donde a veces intervenían técnicos que no pertenecían al departamento en la cual se había presentado la falla, ahí terrninaba todo; se salía del apuro y el problema se daba por concluido. No se realizaba un análisis serio con el fin de detectar las causas de raíz y, sobre todo, dejar establecido un procedimiento de control para asegurar que dicho error quede controlado en el futuro.

Está claro que siempre se acudía a un seguimiento por excepción, dirigido meramente a la corrección momentánea y no al establecirnien- to de controles en función de las causas. Un esquema de esto se muestra a continuación:

Seguimiento por excepción


Como puede apreciarse, con un seguimiento por excepción la cantidad de errores es frecuente y su impacto es elevado. Prácticamente, al no analizar las causas y no establecer los controles, la probabilidad de que un mismo tipo de error se presente de nuevo es alta; y sumada la frecuencia, el impacto se vuelve crítico.

Por otro lado, al estructurar un departamento cuya responsabilidad sea la administración del área de informática en su entorno global, y que se lleve a la práctica mediante un seguimiento como función, el esquema debe comportarse como sigue:

Segulmlento como función

Todo error tratado de esta manera, es decir, donde se analice, corrija y se deje un procedimiento de control, tenderá necesariamente a su eliminación, o cuando menos, a su aparición en espacios de tiempo más aislados. La aparición repetida en este caso puede obedecer a la misma dinámica de los sistemas. Al cambiar éstos, pueden hacer que un procedimiento establecido ya no sea adecuado. El impacto tiende a minimizarse. La explicación gráfica de este efecto se muestra en el esquema denominado Modelo de aprendizaje por seguim'ento como función.

Cabe señalar que la estrategia que propongo es simple, y se puede apreciar con claridad que los resultados positivos de la misma necesariamente tienen que darse en el corto plazo.

Al no conformarme con establecer la estrategia de la cual ya no tenía duda de su eficiencia, todavía fui más allá. Comparé este estudio con los ambientes de informática de otras empresas. Lo que encontré se ilustra en el diagrama Comparación del estudio.

Modelo de aprendizaje por seguimiento como función

surge e efFx

Compamción del estudio

A ~amblb de: \ i barme cantidad

de tiempo requerido parca

juntas de trabajo

CAi? 26. EN BUSCA DE LA EXCELENCIA

En resumen, se observa que el panorama en otras instalaciones (áreas de informática) no es tan distinto; con la aclaración de que esto es en relación con el tipo de errores detectados en la primera investigación. Es preciso subrayar que aquí no se destaca el grado de eficiencia logrado en las distintas instalaciones; más bien se señalan los problemas, los que en gran medida demeritan el nivel positivo alcanzado, pues recuérdese que el objetivo del estudio es controlar los errores; por consiguiente, al lograrlo, automáticamente la eficiencia de cualquier área de informática se eleva.

Como subproducto de la investigación, confirmé algo que con frecuencia se pierde de vista, y que bien vale la pena subrayar. El área de informática es un área de servicio, cuyo objetivo es apoyar al resto de las áreas de la organización. Por tanto, debe hacerse conciencia de lo siguiente:

El 10 % de la productividad del personal del área de informática debe ver hacia adentro.

El 90 % restante debe proyectarse hacia afuera.

La aseveración anterior obedece a que el trabajo del profesional en informática es muy apasionante, y por tratarse de una tecnología novedosa y en constante auge, a uél se llega a enfrascar en la idea de que sus actividades se circunscri 1 en al ambiente interno del área de informática, sin darse cuenta de que el beneficio de la eficiencia de su trabajo se producirá Pera de dicha área. Ejemplo: obsérvese a un programador cuando está satisfecho por una solución ingeniosa que encontró en la elaboración de un pro rama, sus expresiones se inclinan a comentar los detalles técnicos y de f ógica que utilizó, pero no destaca la importancia del servicio que dará el sistema para el cual desarrolló el programa. Es decir, su principal interés se mantiene en el ámbito técnico, El usuario no pertenece a este medio, notrnalmente se descuida que la razón primordial de la existencia del área de informática es el usuario. En este punto, cabe mencionar los siguientes niveles de usuarios dentro y fuera de la empresa:

a) Usuarios de nivel directivo. b) Usuarios de nivel operativo. c) Usuarios finales (clientes, proveedores, etc.).

La eficiencia del área de informática, en cuanto a la calidad y oportunidad de la información que genera, representa un poderoso eslabón, el cual unido a la cadena de los servicios que presta la empresa o institución, conforma el esquema de información-usuarios-servicio.

344 CAP. 26. EN BUSCA DE LA EXCELENCIA m -- * La experiencia que ha demostrado la estrx egia aquí expuesta, dado

su corto periodo de aplicación, permite dar a conocer que es más rápido llevar a un técnico a realizar labores administrativas que convertir a un administrador en técnico; por eso se recomienda, en espera de que el sector educativo genere administradores del área de informática, que por el momento las personas que integren esta área administrativa se apeguen lo más posible al siguiente perfil:

1. Deben tener una experiencia técnica de cuando menos 10 años. 2. Serán candidatos prioritarios los que hayan participado como

asesores técnicos. La razón es que incluso en la actualidad el personal de soporte técnico es asesor de algunos otros departamentos del área de informática, lo cual demuestra que tiene ya un cierto reconocimiento dentro de la instalación.

3. Es indispensable que hayan fungido como líderes de proyectos de importancia donde se integraron áreas usuarias e informáticos.

A lo anterior me gustaría agregar los siguientes comentarios anecdóticos: en cierta ocasión, alguien con quien intercambiaba irnpre- siones sobre la estrategia que recomiendo, me decía lo siguiente: "Perfecto, tu estrategia sí convence, pues cuenta con un razonamiento profundo, que incluso invita a la reflexión. Aí mismo tiempo, pone de manifiesto tal cantidad de situaciones obvias y conocidas por todos nosotros que no es posible refutarlas." Luego agregó: "Todo parece tan obvio, incluso tu recomendación; y creo que ahí radica el secreto, es decir, es tan trivial que precisamente a nadie, que yo sepa, se le había ocurrido, sobre todo porque resulta tan sencillo que se antoja que no merecía importancia." Y aún abundó más: "Yo lo describiría semejante a lo que alguna vez leí: 'como un tremendo destello de lo obvio, que produce ceguera'. Y continuamos metidos en el mismo agujero desde hace años." Finalmente, con una leve ironía apuntó: "Pero jme quieres decir de dónde sacaremos a los superhombres que se requiere para estructurar el área administrativa de la función informática¿"

No me incomodó su pregunta; con plena seguridad le contesté: "Re- sulta que no se tendría que buscar demasiado, porque esos superhombres, como ti5 los llamas, hace años que se encuentran en las instalaciones. El problema está en que se han dedicado a hacer el seguimiento por excepción, y además están tan escondidos dentro de la organización que prác- ticamente no se les toma en cuenta. $Sabes a quiénes me refiero¿, son aquellos del área gris de métodos y procedimientos. Algunos otros realizan las labores de seguimiento de problemas, mismas que a nadie importa. Sí, ahí están desde hace años, haciendo un trabajo insignificante ante los ojos de las demás áreas. ¡Sí, ahí están!". Ahora hay que formarlos en las universidades y tecnológicos a nivel profesional.

CONCLUSIONES

Si leyó con detenimiento este libro, recordará que en el prólogo mencioné que cuando llegara al final usted habría adquirido mucho de la buena "educación informática". Pero también mencioné que sólo llegaría hasta una gran puerta que se abriría automáticamente y que al encontrarse del otro lado ésta se cerraría por un mecanismo que ya no permitiría su regreso. Asimismo, aclaré que encontrándose del otro lado, su trayecto apenas comenzaría, y que sería mucho más difícil el camino por andar que el ya andado. Pues bien, usted ya se encuentra del otro lado, ahora con el conocimiento que ya adquirió, le pregunto lo siguiente:

?Está dispuesto a continuad

No conozco su respuesta, pero lo invito a que continúe. Si es un técnico o profesional en informática ya en ejercicio, encuentre la excelencia informática y convierta su actividad en excelente. Si es estudiante de esta especialidad, aprecie el vasto campo de acción y participe con una nueva mentalidad, decidido a fortalecer el nivel tecnológico de nuestro país.

Conseguir la meta del presente trabajo realmente depende de usted. Para terminar sólo agregaré una frase que ya he utilizado en otras

ocasiones y que quiero compartir, por la gran verdad que de ella emana;

La esencia de todo propósito no está en el impetu con el que se inicie, sino en la persistencia para su realización.

Descripción de responsabilidad y funclones por puesto, de acuerdo con el organigralma de una dirección de informática

Objetivo

Este documento permite la estructuración completa de la organización funcional de una dirección de informática, considerando los requerimientos de las áreas especializadas y los recursos humanos necesarios para cubrirlas. Asimismo, permite la ubicación del personal existente de acuerdo con sus habilidades y, en consecuencia, los requerimientos de contratación necesarios.

Cuando no están definidas claramente las funciones y responsabilidades, se fomenta la "todologia"

A través de la descripción de la responsabilidad por cubrir en cada área, y vislumbrando las £unciones por desarrollar, se puede comprobar la justificación de cada puesto.

Diagmma funciona! de la dirección de informiitica

Gerencia de desarrollo de sistemlas 1

PUESTO: GERENCIA DE DESARROLLO DE SISTEMAS

Es responsable de automatizar los requerimientos de información de aquellas unidades usuarias que por el alcance de sus operaciones dentro de la empresa, volúmenes de datos y requerimientos específicos de servicio, necesitan ser satisfechas mediante el desarrollo de sistemas de informática, o el aprovechamiento del banco de datos centralizado en la computadora principal.

De planeación

a) En conjunto con el usuario y en coordinación con la gerencia de consultoría técnica a usuarios, precisa objetivos, alcances, normas y políticas que regirán cada sistema.

b) En conjunto con el director de informática y los directivos de las unidades usuarias, analiza el alcance posible de los proyectos de sistemas que consideren inversiones no previstas con anterioridad, con el fin de lograr su autorización.

c) Participa en la planeación para que los requerimientos de hardware y software que estarán involucrados en el desarrollo de los sistemas se

encuentren disponibles en las fechas en que serán utilizados. Esto lo hace en coordinación con la gerencia de desarrollo técnico.

d) Establece, junto con el usuario, el plan estratégico para el inicio y desarrollo de los sistemas por diseñar.

e) Analiza las cargas de trabajo del personal bajo su dirección, establece los equilibrios necesarios en función de los requerimientos de cada sistema.

f) Formaliza compromisos con apego a la capacidad y disponibilidad de su personal. g) Asigna los proyectos para los coordinadores de sistemas, en función de la

importancia de servicio de cada sistema.

De administración

a) Participa en el desarrollo de metodologías de trabajo ex profeso para su área de acción.

b) Evalúa la funcionalidad de los métodos de trabajo establecidos, y regula las deficiencias detectadas.

c) Se asegura de que los métodos de trabajo establecidos sean respetados y puestos en práctica.

d) Observa que los procedimientos establecidos conduzcan a trabajos con la calidad suficiente, y que permitan labores de mantenimiento seguras y bajo control.

e) Establece mecanismos de medición que le permitan detectar a tiempo desviaciones en los calendarios de compromisos, para establecer correctivos oportunos.

f) Evalúa periódicamente el nivel técnico de su personal, y analiza si es congruente con la magnitud de los proyectos en cartera, o en su defecto, la tendencia de éstos, para establecer los requerimientos de capacitación necesarios, haciendo las solicitudes correspondientes a la gerencia de desarrollo técnico.

g) Lleva registro sistemático de fallas en sistemas puestos en producción, y las analiza para determinar las causas y acciones por emprender.

h) Evalúa en forma periódica el desempeño de los recursos humanos, y establece planes de incentivos para evitar rotación de personal.

i) Periódicamente coordina juntas con los usuarios para percatarse de que los resultados que éstos reciben satisfacen los requerimientos de infor- mación, tanto en oportunidad como en calidad.

j) Informa de compromisos adquiridos, avances, logros, requerimientos y cualquier dato de importancia para el director de automatización.

Técnicas

a) Participa en seminarios técnicos que le permitan conocer la evolución de los recursos de cómputo para que los diseños se apeguen a los métodos modernos.

b) Evalúa permanentemente en conjunto con las distintas unidades usuarias la vigencia de los procesos de trabajo y, en consecuencia, ofrecer la Función informática al servicio de los trabajos de reingeniería.

PUESTO: COORDINADOR DE SISTEMAS

Es responsable de cubrir los requerimientos de información de un módulo específico dentro del ámbito de la compañía.

De planeación

a) En conjunto con el gerente de desarrollo de sistemas, analiza los objetivos, alcances, normas y políticas que regirán al sistema, con el fin de establecer las bases para el diseño. '- 6) En conjunto con el gerente de desarrollo de sistemas, verifica la disponibilidad de recursos técnicos y humanos, para estructurar un plan maestro de actividades que garanticen la correcta consecución del mismo.

c) En conjunto con los usuarios, establece las responsabilidades mutuas para el desarrollo de cada sistema.

d ) Lleva a cabo la asignación del sistema para el líder de proyecto correspondiente.

e) En conjunto con el líder de proyecto, analiza el plan maestro y establece fechas de compromiso.

De administración

a) Vigila que las actividades establecidas en el plan maestro sean cubiertas cabalmente.

6) En conjunto con el líder de proyecto correspondiente, inicia las visitas a usuarios directivos a fin de empezar con pláticas de detalle para el inicio del diseño del sistema.

e) Verifica que el desarrollo de todo sistema se apegue a la metodología detallada establecida para tal fin.

d ) Administra el control de actividades y calendarios de los líderes de proyecto, para vislumbrar desviaciones y detectar causas y opciones de solución.

e) Lleva informes de avances para mantener informado al gerente de desarrollo de sistemas.

E ) Coordina juntas con los usuarios directivos, para precisar los resultados de cada sistema.

g) Lleva a cabo presentaciones de avance hacia los usuarios directivos, para lograr congruencia de actividades durante el desarrollo del sistema.

h) Supenrisa y autoriza el control de cambios a los sistemas bajo su responsabilidad.

Técnicas

a) Participa en seminarios técnicos que le permitan conocer la evolución de los recursos de cómputo, para que los diseños se apeguen a los métodos modernos.

PUESTO: L~DER DE PROYECTOS

Es responsable del diseño, programación y mantenimiento de varios sistemas de un mismo tipo.

De planeación

a) Realiza visitas y entrevistas en el nivel de usuarios operativos, para elaborar el diseño conce tual de cada sistema.

b) Establece el plan detalla ¿' o de actividades para todo sistema, en conjun- to con los analistas programadores.

c) En conjunto con los usuarios operativos, analiza la utilidad práctica de los resultados por obtener de cada sistema.

d ) Descompone en módulos cada sistema, y establece prioridades de desarrollo acordadas con el usuario.

e) Asigna cada módulo al analista-programador correspondiente. f ) En conjunto con los usuarios, establece el plan de implantación de cada

sistema por liberar.

De administración

a) Administra los calendarios de detalie del desarrollo del sistema, de manera que no existan retrasos.

b) Verifica que el desarrollo de cada sistema se apegue a los estándares de documentación establecidos.

c) Verifica que las pruebas de módulos e integrales cubran todas las condiciones determinadas para el proceso de los datos de cada sistema.

d ) Vigila que la calidad del diseño y la programación se sujete a los estándares técnicos establecidos.

e) Lleva a cabo presentaciones al usuario sobre ejemplos de los resultados obtenidos en las pruebas.

f ) En conjunto con el usuario, administra la puesta en marcha de los módulos de cada sisten

g) Vigila que el mantenimiento de los sistemas se lleve a cabo por medio de un control efectivo de cambios.

Técnicas

a) Desarrolla el diseño conceptual de cada sistema. 6) Participa en cursos específicos sobre las facilidades técnicas del e&ipo

de cómputo, para que sus diseños consideren las facilidades que tiene disponibles.

c) Se mantiene informado sobre paquetes de software que existen en el mercado, para abreviar el diseño y la programación de algunos sistemas.

d ) Participa en seminarios de actualización que le permitan conocer la evolución de los recursos de cómputo para que los diseños y la progra- mación sean más efectivos y confiables.

PUESTO: ANALISTA-PROGRAMADOR

Es responsable del diseño detallado y de la programación de los módulos de un sistema asignados a él.

De planeación

4 Realiza investigaciones y entrevistas en el nivel usuario operativo, para 'i desarrollar el diseño detallado de los módulos del sistema asignados a - - él.

b) Elabora el calendario de actividades detallado para el diseño y progra- mación de los módulos asignados a él.

De administración

a) Administra su tiempo en función de las actividades por cubrir con el fin de cumplir ron las fechas de compromiso.

b) Coordina las pruebas con el usuario de los módulos del sistema por liberar.

Técnicas

a) Desarrolla el diseño detallado de los módulos del sistema asignados a él. 6) Desarrolla la definición de cada programa resultante del diseño detalla-

do. c) Documenta el diseño detallado con base en los estándares establecidos.

d ) Lleva a cabo la programación y prueba de cada programa resultante del diseño detallado, y lo documenta.

e) Realiza la prueba integral de cada módulo asignado a él, y la valida.

f ) Capacita técnicamente a los usuarios en la implantación de los módulos del sistema asignados a él.

g) Participa en cursos específicos sobre las facilidades técnicas del equi o

facilidades que tiene disponibles. f de cómputo para que sus diseños y programación consideren as

h) Participa en seminarios de actualización que le permitan mejorar sus disefios y programación.

i) Imparte cursos específicos de su área de acción, a analistas y programadores de nuevo ingreso a la instalación.

j) Realiza el mantenimiento necesario para 10s módulos responsabilidad de él, con el fin de que los resultados de los mismos siempre sean satisfactorios para las necesidades cambiantes de los usuarios.

PUESTO: MESA DE CONTROL Y RESGUARDO DE DOCUMENTACI~N

Es responsable de resguardar, controlar, depurar y actualizar la documenta- ción correspondiente a cada sistema.

De planeación

a) No realiza funciones de planeación.

De administración

a) Centraliza la documentación integral de cada sistema. 6) Actualiza la documentación con los cambios que le reportan. c) Depura la documentación obsoleta, bajo autorización del gerente de

desarrollo de sistemas. d ) Lleva registro de la documentación existente. e) Controla la documentación que le solicitan y la recupera. f ) Mantiene la existencia de papelería y artículos varios para el personal de la

gerencia de desarrollo de sistemas, y los reparte en forma racional. g) Archiva y controla la documentación administrativa de apoyo a la

gerencia de desarrollo de sistemas (por ejemplo: hojas de control de cambios, control de proyectos, reportes estadísticos, solicitudes de usuarios, reportes de fallas, etc.).

Técnicas

a) No realiza funciones técnicas.

Estructum específica de la gerencia de desarrullo de sistemas

Gerencia de consultoría técnica a usuarios

PUESTO: GERENCIA DE CONSULTOR~A TÉCNICA A USUARIOS

Es responsable de asesorar a las unidades usuarias para determinar el tipo y nivel de tecnología que satisfaga sus requerimientos de información, y encaminarlas hacia la opción más apropiada. Esta área es la que integra al usuario a los servicios de cómputo.

DESARROLLO DE FUNCIONES

D e planeación

a) En conjunto con el usuario, analiza los requerimientos específicos de información solicitados.

6) Determina si los requerimientos de información pueden ser satisfechos por el desarrollo de algún sistema procesable en el equipo de cómputo central, y participa en la delegación del proyecto hacia la gerencia de desarrollo de sistemas.

e) Determina si los requerimientos de información del usuario deberían ser satisfechos por equipo y software autónomos a la computadora central.

d) En conjunto con el director de informática y con los directivos de las unidades usuarias solicitantes, analiza la inversión requerida para la adquisición de equipo de cómputo y determina las posibilidades de alcance para lograr la autorización.

e) Participa en la planeación para que los requerimientos de hardware y sokware que estarán involucrados en el proyecto se encuentren disponibles en las fechas planeadas. Esto lo hace en coordinación con la gerencia de desarrollo técnico.

f ) Establece en conjunto con el usuario el plan estratégico para el inicio y desarrollo del proyecto.

g) Analiza las cargas de trabajo del personal que está bajo su dirección, y establece los equilibrios necesarios en función de la magnitud de cada proyecto.

h) Formaliza compromisos en apego a la capacidad y disponibilidad de su personal.

i) Asigna los proyectos al personal a su cargo.

De administración

a) Participa en el desarrollo de metodologías de trabajo dirigidas a su área de acción.

b) Evalúa la funcionalidad de los métodos de trabajo establecidos y regula las deficiencias detectadas.

c) Comprueba que los métodos de trabajo establecidos sean respetados y puestos en práctica.

d ) Observa que los procedimientos establecidos conduzcan a trabajos con calidad suficiente y que permitan labores de mantenimiento seguras y bajo control.

e) Establece mecanismos de medición que le permiten detectar a tiempo desviaciones en los calendarios de compromisos, con el fin de establecer correctivos oportunos.

E ) Evalúa periódicamente el nivel técnico de su personal y analiza si es congruente con la magnitud de los proyectos en cartera, o en su defecto, la tendencia de éstos, para establecer los requerimientos de capacita- ción necesarios, y hace las solicitudes pertinentes a la gerencia de desarrollo técnico.

g) Lleva registro sistemático de las fallas de los sistemas detectadas por los usuarios y analiza para determinar cuáles son las causas y las acciones por emprender.

h) Evalúa en forma periódica el desempeño de su personal y establece planes de incentivos para evitar rotación de personal.

i ) Periódicamente coordina juntas con los usuarios para percatarse de que los resultados que éstos obtienen satisfacen los requerimientos de información predehdos.

j) Elabora informes de compromisos adquiridos, avances, logros, requerimientos y cualquier dato de importancia para el director de informática.

Técnicas

a) Participa en seminarios técnicos de actualización, para conocer nuevos equipos y paquetes disponibles que ofrezcan a los usuarios más ventajas operativas y de información.

PUESTO: CONSULTOR DE MÉTODOS Y PROCEDIMIENTOS

Es responsable de asesorar técnicamente a los usuarios para sistematizar sus requerimientos de información, ya sea optimizando los procedimientos de trabajo o por medio de equipos de cómputo para oficina.

De planeación

a) En conjunto con el usuario, analiza los requerimientos específicos de información para evaluar la utilidad que éstos representan, tanto en calidad como en oportunidad.

b) En conjunto con el usuario, analiza los volúmenes de datos por procesar, para vislumbrar si se requiere la automatización de éstos y el tipo de equipo necesario, ya que puede ser sólo la instrumentación de procedimientos administrativos y equipo especial de oficina lo requerido para satisfacer las necesidades de información.

c) En caso de que la solución sea una computadora de oficina, participa en coordinación con el usuario para elaborar un plan de actividades conjuntas, a efecto de hacerlo autosuficiente en el manejo y aprovechamiento de este equipo.

De administración

a) En conjunto con el usuario, administra el plan de actividades para cumplir con las fechas de compromiso.

Técnicas

a) Asesora técnicamente al usuario para la elaboración del manual de métodos y procedimientos, cuando se trate del desarrollo de un sistema administrativo.

b) Asesora técnicamente al usuario en la implantación de un sistema administrativo. c) Asesora técnicamente al usuario para la elaboración del manual de re-

querimientos de automatización. Esto es para cuando se soliciten computadora~ para oficina.

d) Presenta el manual de requerimientos de automatización al gerente de consultoría técnica, para tramitar la adquisición de software y hardware a través de la gerencia de desarrollo técnico.

e) Si es necesario desarrollar un sistema por la falta de un paquete de software que satisfaga los requerimientos de información, o porque resulte más costeable, dará la asesoría al usuario para el desarrollo del análisis y diseño del sistema y su documentación en caso de que esa

unidad ya sea autónoma desde el punto de vista inforrnático o, en su caso, promueve el desarrollo del sistema en el área de informática.

f ) Participa en seminarios técnicos de actualización para conocer nuevos productos de hardware y software que existen en el mercado.

PUESTO: CONSULTOR TÉCNICO

Es responsable de la puesta en marcha del hardware y el software para los usuarios con sistemas automatizados autónomos a la computadora central.

De planeación

a) Elabora el plan de trabajo para la instalación de hardware y software requeridos.

De administración

a) Lleva registro de fallas en los paquetes de software contratados e instalados en las computadoras propias de los usuarios, así como de las correcciones.

b) Lleva registro de los paquetes instalados en las computadoras propias de los usuarios y proveedores de éstas.

Técnicas

a) Coordina la instalación de hardware y software en la fase de puesta en marcha.

b) Verifica que funcionen correctamente. c) Coordina la capacitación técnica para la autosuficiencia de los propios

usuarios. d) Asesora al usuario en la contratación de su propio personal técnico. e) Asesora al personal técnico propio del usuario cuando se trate del

desarrollo y programación de un sistema automatizado. f ) Realiza visitas de auditoría técnica cuando los sistemas ya están en

producción, asesora al personal técnico propio del usuario cuando detecta deficiencias en la utilización del equipo de cómputo.

g) Evalúa la autosuficiencia técnica del personal técnico propio del usuario, y emite dictamen y sugerencias.

h) Imparte seminarios de informática a nuevos usuarios.

Estructura específica de la gerencia de consultorla tbcnica a usuarios

Gerencia de servicios de cómputo

PUESTO: GERENCIA DE SERVICIOS DE CÓMPUTO

Es responsable de mantener en forma permanente la disponibilidad de hardware y software central y de las estaciones remotas conectadas al mismo, en condiciones para permitir la operatividad de las unidades usuarias que reciben el servicio, además de cubrir a tiempo los calendarios de producción de los sistemas liberados.

De planeación

a) En conjunto con la gerencia de desarrollo de sistemas, estructura los planes de servicio requeridos por las unidades usuarias.

b) En conjunto con la gerencia de desarrollo técnico, establece los planes de instalación, puesta en marcha y mantenimiento del hardware y software requeridos por los sistemas tanto centrales como descentralizados en las

c) unidades usuarias. Desarrolla los planos Físicos considerando dimensiones locales, ubicación estratégica de equipo, seguridad de las instalaciones, configuraciones óp- timas de equipo e instalaciones físicas de acondicionamiento ambiental.

d ) Lleva la planeación de las cargas de trabajo, de manera que se pueda vislumbrar a tiempo la posible saturación en cualquiera de los servicios de cómputo responsabilidad de él.

De administración

Establece las medidas de control y seguridad de acceso a las distintas áreas restringidas. Participa en el desarrollo de metodologías de trabajo dirigidas a su área de acción. Evalúa la funcionalidad de los métodos de trabajo establecidos, y regula las deficiencias detectadas. Se asegura de que los métodos de trabajo establecidos sean respetados y puestos en práctica. Establece mecanismos de medición que le permitan detectar con tiempo desviaciones en los calendarios de servicio y establecer medidas correctivas. Lleva el control de facturación para los servicios de mantenimiento de hardware, software e instalaciones diversas, y canaliza las facturas para su autorización cuando los servicios son satisfactorios a plenitud. Vigila que el mantenimiento del hardware, software e instalaciones diversas reúnan los niveles de calidad que le permitan dar un servicio continuo. Lleva registro sistemático de fallas de hardware, software y sistemas en producción, y emprende las acciones necesarias para su corrección. Evalúa periódicamente el nivel técnico y administrativo de su personal y analiza si es congruente con el nivel de la tecnología operada bajo su responsabilidad. Asimismo establece los requerimientos de capacita- ción necesarios y los solicita a la gerencia de desarrollo técnico. Evalúa en forma eriódica el desempeño de los recursos humanos y establece planes c f e incentivos para evitar rotación de personal. Periódicamente coordina juntas con la gerencia de desarrollo de siste mas y la gerencia de desarrollo técnico para evaluar si los niveles de servicio cubren las necesidades de información de las distintas unidades usuarias, o en su defecto, estructurar acciones conjuntas. Recibe solicitudes de operación de nuevos sistemas, variantes en los calendarios de servicio, instalación de hardware y software adicionales, y se asegura de que tales solicitudes sean satisfechas según los calendarios establecidos. Elabora informes de compromisos adquiridos, avances, logros, requerimientos y cualquier dato de importancia para el director de automa- tización.

Técnicas

a) Participa en seminarios técnicos de actualización que le permitan coordinar la explotación más efectiva de los recursos de hardware y software disponibles.

PUESTO: JEFE DEL CENTRO DE PROCESAMIENTO DE DATOS

Es responsable de vigilar el mantenimiento sistemático del equipo de cómputo para lograr que el servicio sea congruente con los horarios establecidos.

De planeación

a) Elabora el plan de mantenimiento detallado de la computadora y sus periféricos para obtener la máxima disponibilidad.

b) Elabora el plan de mantenimiento específico para mantener la computadora en condiciones óptimas ambientales y de limpieza.

De administración

Lleva la administración y el seguimiento para que los planes de mantenimiento de la computadora y las condiciones ambientales sean cubiertas satisfactoriamente. Lleva récord de fallas de hardware y software y hace el seguimiento para que sean corregidas a la mayor brevedad. Elabora diariamente los horarios y servicios que han de ser cubiertos por el centro de cómputo. Establece las estrategias de operación, tanto de la computadora principal como de sus periféricos, y determina los turnos de servicio. Coordina la asignación de operadores en función de turnos y tipos de servicio. En casos de caídas del servicio de cómputo, además de tomar parte para una rápida continuidad, informa a los usuarios sobre la situación. Supervisa que los procedimientos de seguridad de las áreas restringidas sean respetados. Lleva estadísticas de servicio y prevé los horarios extra de servicio cuando los normales han sido rebasados. Estructura la rotación de turnos y asignación de operadores. Lleva registro de uso de dispositivos magnéticos, papelería y diversos, para mantener en forma continua una disponibilidad suficiente. Lleva informes de niveles de servicio, disponibilidad de tiempo máqui- na, cargas pico y cualquier dato de interés para el gerente de servicios de cómputo. Evalúa los requerimientos específicos de capacitación cuando detecta deficiencias técnicas en los operadores y reporta a la gerencia de servicios de cómputo con el fin de tramitar su solicitud. Implanta los métodos de trabajo específicos de su área.

Técnicas

a) Participa en seminarios técnicos de actualización para conocer con más detalle el potencial de servicio del equipo del cual es responsable.

PUESTO: SUPERVISOR DE TURNO DE OPERACIÓN

Es responsable de la operación del centro de cómputo y de cubrir los requerimientos específicos de servicio del turno al cual está asignado.

De planeación

a) Realiza un plan de trabajo que cubre 10s requerimientos de servicio de su turno.

De administración

a) Administra el plan de trabajo que corresponde a su turno, para que sea cubierto sin demoras.

Técnicas

a) Se asegura de que los servicios de la red de teleproceso sean proporcio- nados exactamente en los horarios establecidos.

6) Tiene a su cargo la operación de los monitores de control y la consola maestra, desde los cuales se asegura de que los servicios planeados sean satisfechos.

c) Llena la bitácora de servicios cubiertos en su turno y registra eventualidades.

d) Entrega el turno bajo continuidad de servicios e informa sobre eventualidades que pudieran importar o impactar al turno que recibe.

e) Coordina la función de los operadores de la red y de la computadora para que no desatiendan sus actividades.

f ) Levanta los reportes de fallas de hardware y software y comprueba su funcionalidad cuando éstas ya estén corregidas.

g) Supervisa que los archivos en dispositivos magnéticos estén identificados de acuerdo con las normas establecidas.

h) Lleva a cabo procedimientos de recuperación en caso de fallas de hardware y software, los cuales están previstos.

i ) Reúne el material necesario de diagnóstico para casos de fallas de hardware y software, para que sean investigadas las causas.

j) Analiza las cargas de trabajo y mide los niveles de multiprogramación, paginación y actividad de los periféricos, para no saturar la computadora, estableciendo las estrategias de nivelación operativa.

PUESTO: OPERADOR DE LA RED DE TELEPROCESO

Es responsable de mantener en línea los servicios de la red en función de los horarios establecidos para cada tipo de servicio.

De planeación

a) Diariamente elabora un plan de servicio sujeto a horarios, ubicaciones y tipo de servicios.

De administración

a) Diariamente lleva un registro de los usuarios, localidades, horarios y tipo de servicios que se proporcionaron.

6) Diariamente lleva registro de falias y suspensiones de servicio, anexan- do los motivos que las originaron.

c) Lleva estadísticas del servicio en línea para determinar si los servicios de la red son satisfactorios en función de las necesidades de los distintos usuarios.

Técnicas

a) Emite los comandos de control que son necesarios para poner en línea las distintas unidades usuarias, todo esto, de acuerdo con el plan de horarios preestablecidos.

6) Monitorea en forma permanente el comportamiento de la red. c) Lleva a la práctica los procedimientos de reconfiguración de líneas en

caso de fallas previstas. d) Lleva a la práctica los procedimientos de recuperación en caso de caídas

de hardware y software previstas. e) Cierra servicios de la red de acuerdo con lo planeado para no dejar

terminales activas que en un momento determinado pudieran ser manipuladas por personas no autorizadas.

PUESTO: OPERADOR DE COMPUTADORA

Es responsable de mantener activos los servicios de la computadora central.

De planeación

a) Eventualmente realiza las funciones de planeación encomendadas al supervisor de operación.

De administración

a) Eventualmente realiza las funciones de administración encomendadas al supervisor de operación.

Técnicas

a) Opera las consolas alternas de la computadora para atender los requerimientos de periféricos de cada proceso.

6) Opera los periféricos de la computadora para efecto de montaje de cintas y papelería de impresoras y cualquier otro medio que requiera opera- ción manual.

c) Mantiene la ubicación ordenada de las cintas magnéticas y las identifica en caso necesario.

d ) Ejecuta procesos propios de operación tales como respaldos de archivos, volúmenes, depuración de ambiente de discos y cualquier proceso propio de operación, de acuerdo con los calendarios establecidos.

e) Periódicamente hace limpieza de las unidades periHricas de la computadora para evitar fallas de grabación, lectura e impresión de reportes.

f ) Eventualmente realiza las funciones técnicas encomendadas al supervisor de operación.

PUESTO: INGENIERÍA Y SEGURIDAD DE INSTALACIONES DE EQUIPO

Es responsable de coordinar la instalación y los cambios físicos de equipo de cómputo, líneas de comunicación y terminales, garantizando que reúnan los requerimientos corhables de seguridad para evitar accidentes o fallas constantes.

De planeación

a) Participa en la planeación física de instalación o cambio de equipo, en conjunto con la gerencia de servicios de cómputo y la gerencia de desarrollo técnico, incluyendo la arquitectura de la red de servicios en línea.

b) Elabora el plan detallado para la instalación, puesta en marcha y cambios de equipo de cómputo, incluyendo la red de servicios en línea.

c) Participa en la planeación de la instalación del equipo ambiental (ener- gía eléctrica, aire acondicionado, distribución de equipo, dispositivos de seguridad, etc.).

De administración

a) Lleva la administración de equipo instalado en relación con conexiones físicas, tanto local como remoto.

b) Mantiene el inventario actualizado de equipo instalado y localidades de ubicación.

c) Mantiene identificado cada dispositivo para conocer su interrelación conjunta.

d ) Lleva registro de fallas en equipo de comunicaciones, instalaciones eléctricas, terminales, aire acondicionado y líneas, para investigar causas frecuentes y acciones por emprender.

e) Elabora informes de compromisos adquiridos, avances, logros, requerimientos y cualquier dato de importancia para el gerente de servicios de cómputo.

Técnicas

a) Coordina la instalación y los cambios planteados de equipo, además supervisa los niveles de seguridad.

b) Calculo matemáticamente los requerimientos físicos de energía eléctri- ca, y supervisa que se mantenga en los límites de seguridad, aun con la adición de equipo nuevo.

c) Supervisa que las instalaciones eléctricas estén conectadas en ubicaciones no riesgosas y con las normas de calidad confiables.

d ) Supervisa que el equipo contra incendios sea el adecuado y esté ubicado en lugares estratégicos, además de que reciba el mantenimiento adecuado.

e) Coordina la tramitación de líneas para la red del servicio de teleproceso, y considera las posibilidades de respaldo.

f ) Coordina la reparación de líneas y se asegura de que sean confiables para reiniciar el servicio.

g) Atiende repones para corregir fallas mínimas de equipo e instalaciones. h) Coordina la instalación de terminales nuevas.

i ) Coordina la reparación de terminales dañadas. j) Coordina simulacros de incendio, terremotos, etc., para practicar las

medidas de seguridad. k) Elabora los planos de distribución, instalaciones Físicas de equipo,

arquitectura de la red del servicio en línea, y los mantiene actualizados de acuerdo con los cambios que ocurran.

PUESTO: AUXILIAR DE INSTALACIONES

Es responsable de cumplir con los planes de instalación de equipo y medidas de seguridad delegados por el ingeniero a cargo del área de instalaciones.

a) Efectúa el plan de detalle propio de un trabajo delegado en él, principalmente cuando se trata de analizar las medidas de seguridad que deben existir en dicho trabajo.

De administración

a) Administra las actividades de su plan de trabajo para lograr una conse- cución lógica y evitar posibles accidentes.

Técnicas

a) Periódicamente realiza recorridos de observación para verificar que las instalaciones de equipo de cómputo, aire acondicionado, energía eléc- trica, equipo de seguridad, equipo de comunicaciones, líneas y terminales se encuentran en estado satisfactorio.

6) Realiza un diagnóstico por cada recorrido y determina acciones por emprender.

c) Acude a reportes de fallas mínimas del equipo e instalaciones mencionados en el inciso a, y las corrige.

d ) Participa en los cambios planeados para el equipo y las instalaciones que han sido mencionados en el inciso a, y además supervisa las normas de seguridad.

PUESTO: JEFE DE OPERACIÓN DE SISTEMAS

Es responsable de cubrir los calendarios de producción de los sistemas liberados.

De planeación

a) Elabora el plan de producción, donde establece las cuotas de captura de datos diariamente.

6) Elabora el plan de producción diariamente donde establece los flujos de los procesos por ser operados.

c) Elabora el plan de distribución de resultados, donde establece diariamente los horarios de entrega y destinatarios.

De administración

a) Lleva el control de recepción y entrega de documentos fuente para captura.

6) Lleva registro de los procesos que han de ser cubiertos por cada sistema liberado.

c) Lleva registro de la entrega de resultados de cada usuario. d ) Formaliza la recepción de nuevas cuotas de documentos por capturar, y

establece en conjunto con el usuario los horarios de recepción y entrega. e) Formaliza la recepción de nuevos sistemas por operar y establece en

conjunto con el usuario los periodos y horarios de las corridas de cada proceso.

f ) En conjunto con el usuario, establece los horarios y periodos de entrega de resultados de los sistemas liberados a producción.

PUESTO: SUPERVISOR DE CAPTURA DE DATOS

Es responsable de cubrir las cuotas de captura de datos, de acuerdo con la planeación establecida por el jefe de operación de sistemas.

De planeación

a) En función de las cuotas por cubrir, elabora diariamente un plan de asignación de trabajo de captura para garantizar su consecución.

De administración

a) Administra la recepción, asignación, recolección y entrega de documentos fuente para mantener su integridad.

b) Supervisa la calidad del asentamiento de datos en los documentos fuente, y levanta reportes en aquellos que le originan retrasos o errores de captura, para que el jefe del área lo comunique al usuario correspondiente.

e) Verifica cifras de control con el fin de subsanar los diferencias detectadas. d ) Coordina la trasmisión de archivos de datos en conjunto con e1 super-

visor de ~~peración de la computadora. e) Administra las cargas de trabajo hacia el persona1 de captura y lleva

registro de la productividad individual para lograr un mejor aprovechamiento.

f) Lleva estadísticas de cargos de trabajo para prevenir la saturación de sus recursos.

g) En las cargas pico administra la asignación con el fin de cubrir, incluso, tiempos extra.

h) Lleva registro de fallas de equipo de captura y realiza las acciones necesarias para lograr una disponibilidad constante.

i ) Lleva operación del equipo de captura a través de la consola maestra. j ) Lleva la bitácora del turno correspondiente para lograr continuidad en la

entrega a otros turnos. k) Asesora a personal de captura nuevo en el área.

Técnicas

a) Participa en seminarios técnicos de actualización para lograr un mejor dominio del equipo de captura.

PUESTO: CAPTURISTA DE DATOS

Es responsable de cubrir las cuotas de captura de datos asignados por el supervisor.

De planeación


De administración

a) No realiza funciones de administración.

Técnicas

a) Lleva el control de los documentos fuente que le asignaron para no revolverlos u originar omisiones de captura o duplicidad.

b) Verifica la calidad individual de cada documento fuente por ca turar, y

exista un alto riesgo de capturas erróneas. P en su caso, lo reporta al supervisor cuando no se entienda su ectura y

c) Debe poner especial cuidado en la captura para evitar reprocesos que ocasionen desfasamientos en los horarios de compromiso.

d) Debe cubrir en tiempo las cuotas de captura agignadas a él. e) Regula la intensidad de su terminal para que le permita una mejor

visibilidad en los mentís de captura. i) Reporta al supervisor fallas que detecte en la terminal y que le impidan

I la rapidez adecuada de captura.

PUES'I'O: SUPERVISOR DE CONTROL DE PROCESOS

Es responsable de la operación de los sistemas en producción, de acuerdo con la planeación establecida por el jefe de operación de sistemas.

De planeación

a) En función de la secuencia y prioridades de los procesos, diariamente elabora el plan de producción detallado.

De administración

a) Lleva la administración de archivos y bibliotecas que intervienen en la operación de los sistemas, con la finalidad de asegurar que se acceda a los apropiados.

b) Estructura las matrices de procesos y reprocesos establecidos dentro de cada sistema.

c) Codifica los procedimientos de postulados de job control (control de trabajo), de acuerdo con la matriz de control.

d ) Lleva registro de fallas de proceso y los reporta al jefe de operación de sistemas.

e) Decide las estrategias de reprocesos en las fallas predefinidas. f ) Asigna los procesos a los operadores de sistemas. g) Administra la producción de tal manera que cubra los horarios estable-

cidos. h) Lleva la bitácora de control de procesos e incidencias para hacer entrega

de turno. i ) Coordina la entrega de resultados a la mesa de control.

Técnicas

a) Participa en seminarios específicos de la política de cada sistema en operación, para tener un conocimiento más completo de sus actividades.

PUESTO: OPERADOR DE SISTEMAS

Es responsable de operar cada sistema de acuerdo con la matriz de control.

De planeación

a) Eventualmente realiza las funciones de planeación de supervisor de control de procesos.

De administración

a) Eventualmente realiza las funciones de administración del supervisor de control de procesos.

Técnicas

a) Accesa las bibliotecas de postulados de job control y las mantiene actualizadas en función del contenido de cada matriz de control.

b) Ejecuta cada proceso en función del orden determinado en la matriz de control.

c) Verifica las cifras de control de cada proceso para asegurarse de su validez.

d ) Ejecuta reprocesos en caso de fallas predefinidas o de operación de procesos de acuerdo con la estrategia del supervisor.

e) Prepara parámetros de control solicitados por los procesos y verifica su validez.

f ) Participa en conjunto con el supervisor en la entrega de turno para evitar malos entendidos.

PUESTO: SUPERVISOR DE LA MESA DE CONTROL

Es responsable del control de calidad, registro histórico de procesos y de la preparación y distribución de resultados a las distintas áreas usuarias.

De planeación

a) Elabora diariamente un plan de trabajo por cubrir en su turno correspondiente.

De administración

a) Lleva registro de los resultados y los verifica en conjunto con el supervisor de control de procesos, para que sean congruentes con la bitácora de procesos.

6) Lleva registro histórico de corrida de procesos y cifras de control de cada sistema.

c) Lleva registro histórico de entrega de resultados a las distintas unidades usuarias, considerando volúmenes, horarios y fechas.

d ) Coordina la asignación de trabajo hacia el personal. e) Lleva registro de resultados de mala calidad o incongruentes en cifras de

control, y los reporta al supervisor de control de procesos para determinar causas y acciones por emprender.

f ) Levanta reportes de falías en equipo de apoyo (desempapeladoras, cortadoras de papel, etc.) y solicita el mantenimiento necesario.

g) Lleva bitácora de control correspondiente a su turno de trabajo para hacer entrega del turno.

Técnicas

a) Participa en seminarios específicos de la política de cada sistema en operación, para tener un conocimiento más completo de sus actividades.

PUESTO: CONTROL DE CALIDAD DE RESULTADOS

Es responsable de verificar que los resultados de los procesos reúnan los niveles de calidad, orden, presentación y veracidad.

De planeación


De administración

a) Verifica que los' reportes impresos tengan la calidad suficiente de legibilidad y limpieza.

b) Verifica que los reportes tengan encabezados reglamentarios en identi- ficación de reportes, sistema, programa, fechas correctas, usuario correspondiente y, en general, sean perfectamente identificables.

c) Verifica la consistencia de las cifras de control en relación con procesos anteriores.

d ) Archiva un ejemplar de las cifras de control por cada proceso para verificaciones futuras e investigación y rastreo de fallas de procesos.

e) Verifica que los reportes impresos estén en orden en relación con su número de hoja consecutivo.

f ) Levanta reportes de inconsistencias detectadas y las comunica al supervisor.

g) Identifica cada reporte con destinatario, fecha y hora en que debe ser entregado.

Técnicas


PUESTO: PREPARACI~N Y DISTRIBUCI~N DE RESULTADOS

Es responsable de que los usuarios reciban en tiempo los resultados de cada sistema en operación.

De planeación


De administración

a) Lleva registro de lo que recibe y distribuye.

Técnicas

a) Opera el equipo de apoyo (desempapeladoras, cortadoras de papel, etc.). b) Lleva el control de fallas del equipo y reportes de mantenimiento necesario. c) Encuaderna los tomos de reportes según lo requerido por cada usuario.

d ) Envía los tomos al usuario correspondiente, de acuerdo con las fechas y horarios establecidos, incluyendo usuarios foráneos.

PUESTO: JEFE D E SOPORTE TÉCNICO

Es responsable de la instalación, puesta en marcha, mantenimiento y disponibilidad continua del software requerido para la función de la computadora y paquetes de apoyo para el desarrollo de sistemas.

De . planeación

a) Participa en la planeación de la configuración del equipo y el diseño de la arquitectura de la red de servicios en línea.

b) Desarrolla la planeación requerida para la instalación y uesta en marcha del software necesario para el funcionamiento de P a computadora y sokvare de apoyo para el desarrollo de sistemas, de manera que sea congruente con las fechas de compromiso.

c) Desarrolla la laneación requerida para la instalación y puesta en marcha del s o L a r e específico para el servicio en línea, de manera que se apegue a la arquitectura diseñada para la red.

d) Desarrolla la planeación requerida para la instalación y puesta en marcha del software específico para el control y acceso de h s bases de datos.

e) Participa en conjunto con la gerencia de desarrollo de sistemas en la planeación del diseño de las configuraciones de las bases de datos.

De administración

a) Lleva inventario y control de los niveles de software instalados en la computadora.

b) Lleva registro de fallas de software y realiza los reportes necesarios a los proveedores con el fin de obtener las correcciones.

e) Lleva registro de los niveles de mantenimiento aplicados al software instalado en la computadora, supervisa que se mantenga actualizado.

d) Establece los controles necesarios para evitar caídas de servicio por errores en la instalación y mantenimiento de software.

e) Lleva a cabo la implantación de metodologías de trabajo dirigidas a su área de acción.

f ) Supervisa que éstas sean respetadas en sus detalles y puesta en práctica. g) Administra las cargas de trabajo del personal a su cargo para evitar

saturación y desfasamiento de proyectos. h) Elabora los calendarios de compromisos de su área y supervisa que éstos

sean cubiertos. i ) Elabora informes de compromisos adquiridos, avances, logros, requeri-

mientos y cualquier dato de importancia para el gerente de servicios de cómputo.

j ) Lleva estadísticas de fallas para identificar las razones más frecuentes y establecer correctivos.

k) Lleva estadísticas del comportamiento del equipo de cómputo en cuanto a uso de canales, periféricos, paginación, unidades de servicio, etc., para prevenir una posible saturación.

1) Lleva la administración de los trabajos asignados a su personal de manera que se cubran posibles saturaciones y compromisos que no se puedan cumplir.

m) Supervisa la correcta funcionalidad de las bases de datos, tanto por su estructura como por el software que soporta su acceso.

n) Lleva estadísticas del comportamiento de la red de servicios en Enea y verifica que los tiempos de respuesta sean los previstos, en su defecto,, analiza las causas y acciones por emprender.

o) Evalúa el nivel técnico del personal a su cargo y se asegura de que sea congruente con el nivel de tecnología que maneja, o en su defecto, establece calendarios de capacitación para solicitarlos a la gerencia de desarrollo técnico.

p) Establece contacto con otras instalaciones modelo para iniciar intercambio de conocimientos y apoyo mutuo.

Técnicas

a) Participa en seminarios técnicos de actualización para optimizar el uso de los recursos técnicos de la instalación.

PUESTO: PROGRAMADOR DE SISTEMAS PARA EL SOPORTE TÉCMCO E INSTALACI~N DE SOFTWARE EN L~NEA

Es responsable de la generación, prueba y puesta en marcha del software específico de soporte a los sistemas del servicio en línea.

De planeación

a) Desarrolla el plan detallado para la instalación y prueba del software en Enea.

De administración

a) Documenta la instalación de cada software, de acuerdo con los estándares establecidos para tal h.

Técnicas

a) Lleva a cabo la generación, prueba y puesta en marcha del software de soporte al servicio en línea.

b) Asesora técnicamente al personal de análisis y programación de sistemas en aquellos proyectos orientados al servicio en línea.

c) Realiza periódicamente estudios de detalle sobre el comportamiento integral de los servicios en línea, para detectar deficiencias en los tiempos de respuesta, y desarroíla las investigaciones necesarias para determinar causas y acciones por emprender.

d) Efectúa el mantenimiento preventivo y correctivo al software en línea para garantizar una máxima disponibilidad de servicio.

e) Efectúa los cambios necesarios al software en línea para soportar las reconfiguraciones que ocurran en la red y realiza las pruebas necesarias para su correcta operación.

f ) Desarrolla los estándares de uso para la mejor utilización del software en línea.

g) Efectúa los análisis necesarios sobre posibles caídas de los servicios en línea y determina los procedimientos de recuperación en los casos donde son factibles.

h) Desarrolla el manual de procedimientos de recuperación y prueba la funcionalidad de cada uno.

i ) Capacita al personal de operación de la red para que conozca y domine cada procedimiento de recuperación.

j ) Atiende reportes de caídas no recuperables del servicio en línea, e investiga causas y acciones por emprender.

k) Imparte seminarios técnicos sobre métodos de uso para el s o b a r e en línea.

1 ) Participa en la capacitación técnica para personal de nuevo ingreso.

PUESTO: PROGRAMADOR DE SISTEMAS PARA EL SOPORTE TÉCNICO E INSTALACIÓN DE SOFTWARE LOCAL

Es responsable de la generación, prueba y puesta en marcha del sistema operativo de la computadora y paquetes de apoyo en calidad de servicio local.

De planeación

a) Desarrolla el plan detallado para la instalación y prueba del software local.

De administración

a) Documenta la instalación de cada software, de acuerdo con los estándares establecidos para tal fin.

Técnicas

Lleva a cabo la generación, prueba y puesta en marcha del sistema operativo de la computadora y paquetes de apoyo en calidad de servicio local. Asesora al personal de análisis y programación para que hagan un mejor aprovechamiento del software local. Realiza periódicamente estudios de detalle sobre el comportamiento de la relación sistema operativo-computadora, para detectar deficiencias técnicas y desarrolla las investigaciones necesarias con el fin de determinar causas y acciones por emprender. Efectúa el mantenimiento preventivo y correctivo al software local para garantizar una máxima disponibilidad de servicio. Efectúa los cambios necesarios al software local con el fin de soportar las reconfiguraciones de la computadora y realiza las pruebas necesarias para comprobar su funcionalidad. Desarrolla los estándares de uso para la mejor utilización del software local. Efectúa los análisis necesarios sobre posibles caídas en los servicios de la computadora, y determina los procedimientos de recuperación en los casos donde son Factibles. Desarrolla el manual de procedimientos de recuperación y prueba la Pncionalidad de cada uno. Capacita al personal de operación de la computadora para que conozca y domine cada procedimiento de recuperación. Elabora el esquema de configuración y uso de paquetes de discos. Atiende reportes de caídas no recuperables del servicio de la computadora e investiga causas y acciones por emprender. Imparte seminarios técnicos sobre métodos de uso para el sistema operativo y paquetes de software de tipo local. Participa en la capacitación técnica para el personal de nuevo ingreso.

PUESTO: PROGRAMADOR DE SISTEMAS PARA EL SOPORTE E INSTALACIÓN DE SOFTWARE DE BASES DE DATOS

Es responsable de la generación, prueba y puesta en marcha del software para servicio del manejo de las bases de datos.

D e planeación

a) Desarrolla el plan detallado para la instalación y prueba del software de bases de datos.

6) Participa en la planeación de la estructura de las bases de datos.

D e administración

a) Documenta la instalación de cada software, de acuerdo con los estándares establecidos para tal fin.

Técnicas

Lleva a cabo la eneración, prueba y puesta en marcha del software para el manejo j e bases de datos. Asesora al personal de análisis y programación para que hagan un mejor aprovechamiento del software de base de datos. Realiza periódicamente estudios de detalle sobre el aprovechamiento técnico del software de base de datos para detectar deficiencias en su uso y desarrolla las investigaciones necesarias con el fin de determinar causas y acciones por emprender. Efectúa el mantenimiento preventivo y correctivo al software de las bases de datos para garantizar una máxima disponibilidad de servicio. Efectúa los cambios necesarios al software para que soporte las reconfiguraciones de la ar uitectura de las bases de datos y realiza las 9 pruebas necesarias con el in de comprobar su funcionalidad. Desarrolla los estándares de uso para la mejor utilización del software de las bases de datos. Efectúa los análisis de impacto a las bases de datos en casos de caídas de servicio y determina los procedimientos de restablecimiento. Desarrolla el manual de procedimientos de recuperación y prueba la funcionalidad de cada uno. Capacita al personal de operación de la computadora para que conozcan y dominen cada procedimiento de recuperación. Elabora el esquema de distribución de las bases de datos en los paquetes de disco y realiza los cálculos de espacio requerido. Atiende reportes de caídas no recuperables del servicio de bases de datos e investiga causas y acciones por emprender. Imparte seminarios técnicos sobre métodos de uso para el software de bases de datos. Participa en la capacitación técnica del personal de nuevo ingreso.

Gerencia de desarrolllo tecnico

PUESTO: GERENCIA DE DESARROLLO TÉCMCO

Es responsable de mantener la instalación en un ambiente tecnológico actualizado que satisfaga los requerimientos de información de la empresa a corto, mediano y largo plazos.

De planeación

a) En conjunto con la gerencia de desarrollo de sistemas y la gerencia de consultoría técnica, determina la planeación de requerimientos técnicos necesarios para cubrir los requerimientos de información de las unidades usuarias.

6) Establece el plan maestro para investigación de mercado con miras a adquirir el hardware y sofnvare con más ventajas para satisfacer los requerimientos de información planteados.

c) Determina el plan de negociación con los diferentes proveedores. d ) En conjunto con el director de automatización, determina el plan

presupuestal para la adquisición de hardware y software. e) En conjunto con el director de automatización, determina el plan

presupuestal, la adquisición de bóvedas o cajas para seguridad de datos de la compañía.

f ) En conjunto con el director de automatización, determina el plan presupuestal para los planes de capacitación y contratación de asesores externos.

a) Lleva control y registro de los gastos presupuestales del área de informática y conceptos de los mismos.

6) Realiza estudios periódicos del costo-beneficio de las inversiones. c) Lleva registro del hardware y software contratado, en uso y desconti-

nuado para vislumbrar la inversión global y las amortizaciones logradas. d ) Lleva a cabo las negociaciones de adquisición de hardware y software. e) Supervisa que el hardware y software contratados estén disponibles

según lo planeado. f ) Administra el pago de las rentas de hardware y software en función de

las condiciones de adquisición. g) Lleva registro del récord de falIas y problemas ocasionados por hardware

y software para negociar con los proveedores sustituciones necesarias, o en su defecto, indemnizaciones económicas por interrupción de servicio.

h) Coordina los concursos de proveedores para lograr adquisiciones de hardware y software más ventajosas en servicio y precio.

i ) ~ Supervisa que el desarrollo tecnológico de la empresa se ape ue a una f3 estandarización de hardware y software para evitar incompati ilidades.

j ) Administra la asignación de trabajos para el personal a su cargo. k) Prepara informes de compromisos adquiridos, avances, logros presu-

puestales, requerimientos y cualquier dato de importancia para el director de informática.

Técnicas

a) Asiste con regularidad a presentaciones de hardware y software nuevo en el mercado, por considerarlo de importancia para la compañía.

PUESTO: ADMINISTRACIÓN Y SEGURIDAD DE ARCHIVOS Y BASES DE DATOS

Es responsable de mantener la integridad y el resguardo de los archivos críticos de la empresa.

De planeación

a) Elabora el plan detallado para determinar el nivel de resguardo que le corresponde a cada archivo, con base en su importancia y complejidad de recuperación.

b) Elabora el plan detallado para determinar el número y versiones de res aldos para cada archivo concentrado en la computadora, así como la l. ecuencia de éstos.

c) Elabora el plan de depuración y caducidad de archivos obsoletos. d) Participa en la planeación de administración de espacio en paquetes de

disco y voliímenes de cinta magnética. e) Participa en la planeación de la administración de las bases de datos.

De administración

Lleva el control de resguardo de archivos locales en bóveda fuera de sitio. Establece las políticas de seguridad y acceso a los lugares donde se encuentran res uardados los archivos locales y en bóveda hera de sitio. f- Lleva contro de respaldos de archivos y supervisa la frecuencia con que éstos son tomados. Establece las políticas de depuración de archivos y supervisa que se cumplan. Lleva registro de utilización de espacio en disco y uso de volúmenes de cinta para evitar saturaciones que pudieran retrasar procesos en pro- ducción. Analiza los requerimientos de espacio en disco y cantidad de volúme nes de cinta por utilizar en nuevos sistemas y se ase ura de que no sobrepasen la capacidad existente; en su defecto, estab ece los requerimientos necesarios.

k Establece los estándares de identificación externa e interna para volú- menes de disco y cintas magnéticas. Define los estándares de nomenclatura para la identificación de archivos en disco y cinta. Elabora los estándares de nomenclatura para la identificación interna de la estructura de las bases de datos. Lleva registro de los movimientos de afectación de las bases de datos y verifica la integridad. En caso de pérdida o destrucción de archivos críticos, supervisa su correcta recuperación y coordina a las distintas áreas para asegurar la validez de los datos. Lleva registro de falla de proceso por inconsistencia de datos, y analiza las causas y acciones por emprender. Elabora informes de compromisos adquiridos, avances, logros, requerimientos y cualquier dato de importancia para el gerente de desarrollo técnico.

Técnicas

a) Participa en seminarios técnicos de actualización para conocer herramientas de software que garanticen mayor seguridad a los datos y evalúa su adquisición.

PUESTO: DESARROLLO DE &TODOS DE TRABAJO, AUDITOR~A ~ C N I C A Y SEGULMIENTO DE FALLAS Y PROBLEMAS

Es responsable de que las actividades de todas las áreas de la dirección de informática estén reguladas por métodos de trabajo encauzados a obtener mayor productividad, orden y seguridad.

De planeación

a) Elabora los planes de auditoría para evaluar el desarrollo de actividades por área y se asegura de que los métodos de trabajo se respeten y sean funcionales.

De administración

a) Con base en el plan estratégico, realiza visitas de auditoría para levantar diagnósticos de áreas problema.

b) Realiza investigaciones sobre áreas problema y establece los métodos de trabajo que regulen las actividades.

c) Establece estándares de productividad por área y elabora los métodos de trabajo para alcanzarlos.

d ) Lleva registro de fallas y problemas para determinar si es por falta o deficiencia de métodos de trabajo y establece acciones por emprender.

e) Supervisa periódicamente la calidad, orden y seguridad del trabajo de cada área.

f ) Establece las normas de calidad para el trabajo de cada área. g) Lleva registro de fallas y probIemas, y establece el seguimiento necesa-

rio para la solución de cada uno. h) Analiza si las interfases de comunicación entre áreas están limitadas por

funciones y responsabilidades precisas y que no existan discrepancias o confusiones. En su caso, determina causas y acciones por emprender.

i ) Elabora informes de compromisos adquiridos, avances, lo ros, re uerirnien- %; 9 tos y cualquier dato de importancia para el gerente de esarro o técnico. j ) Analiza si el nivel técnico del personal de cada área, en su conjunto, es

suficiente para lograr trabajos de calidad, congruentes con la magnitud de sus funciones y responsabilidades. En su caso, determina acciones por emprender.

Técnicas

a) Participa en seminarios de actualización específicos de administración de centros de cómputo.

PUESTO: EVALUACIÓN DE HARDWARE Y SOFTWARE, Y YDICIÓN DE NIVELES DE SERVICIO

Es responsable de la adquisición de hardware y software requerido por la instalación, cuidando que satisfaga los niveles de calidad, tecnología y volúme- nes de datos por procesar.

De planeación

a) En conjunto con el gerente de desarrollo técnico, establece los planes de adquisición de hardware y software sujetos a los presupuestos.

a) Elabora los estudios de justificación para la adquisición de hardware y software requeridos por la instalación.

b) Lleva a cabo la investigación de mercado para la obtención de hardware y software con el fin de adquirir lo más a ropiado para la instalación.

que refina las características solicitadas. K, c) Coordina la recepción del hardware y so are con el fin de verificar

d) Lleva un inventario actualizado de hardware y software obtenidos y hace el análisis de los niveles de servicio que proporcionan.

e) Coordina las presentaciones que los proveedores hacen sobre sus productos.

f ) Hace el seguimiento con los proveedores para que sean cumplidas las fechas de entrega del hardware y software solicitado.

g) Supervisa que las garantías de servicio del software y hardware adquiridos sean respetadas por los proveedores.

h) Lleva registro sistemático de los niveles de servicio del hardware contratado y hace un detallado análisis de crecimiento para vislumbrar posibles samraciones.

i ) Elabora informes de compromisos obtenidos, avances, logros, requerimientos y cualquier dato de importancia para el gerente de desarrollo técnico.

Técnicas

a) Asiste con regularidad a presentaciones de hardware y software nuevo en el mercado por considerarlo de importancia para Ia compañía.

PUESTO: PLANEACIÓN Y CONTROL DE CAPACITACIÓN TÉCNICA

8d Es responsable de estructurar los planes de capacitación en función de las

necesidades requeridas por cada área, para mantener un nivel de conocimientos congruentes con la tecnología adquirida por la instalación.

De planeación

a) Estructura la planeación básica de capacitación anual requerida por cada área.

De administración

Hace la investigación del mercado de capacitación para seleccionar aquellas instituciones que cubrirán el plan anual de capacitación. Formaliza la contratación de cursos de capacitación para asegurar las plazas necesarias de acuerdo con los calendarios previstos. Analiza que la capacitación cubra los objetivos congruentes con los proyectos de instalación. Elabora las carreras de avance en función de la especialización de cada puesto. Lleva el registro individual de cada persona con respecto a la capacita- ción recibida, para conocer el nivel de preparación de cada integrante. Elabora el presupuesto anual requerido para cubrir los planes de capaci- tación. Coordina los recursos internos que han de ser cubiertos por personal de la propia instalación. Administra los medios para cursos y presentaciones internas, como locales, proyectores, preparación de material didáctico, etcétera. Coordina la capacitación técnica a usuarios de la empresa. Coordina la capacitación técnica del personal de nuevo ingreso a la dirección de automatización. Promueve los requerimientos de contratación de personal solicitados por las áreas de la dirección de informática. Lleva a cabo, dp_s exámenes de selección para personal técnico por contratar. p , ~T Lleva registro de la asignación del personal de la dirección en relación con sus puestos, y lo mantiene actualizado. Coordina las entrevistas entre personal nuevo por contratar y responsables de área. Administra la biblioteca maestra de manuales, revistas y periódicos técnicos a los cuales se está inscrito.

p) Actualiza manuales con cambios y anexos que les llegan. q) Depura manuales, revistas y periódicos obsoletos. r ) Controla manuales, revistas y periódicos técnicos que le solicitan y los

recupera. S) Solicita y hace el seguimiento para la obtención de manuales, revistas

y periódicos técnicos faltantes y requeridos por las áreas.

Técnicas


Acceso, 202, 234, 278, 298, 313, 361, 374-375 aleatorio, 198 rupos de, 216-226, 230-232

%ave(s) de, 262, 279 secuencial, 198

Actividad(es), 51-52, 56, 59, 61, 76, 85, 120, 123, 128, 131, 136, 139, 159, 161, 178, 190, 192, 240, 247, 249, 253-254, 258-260, 269, 273, 281, 283, 286, 298, 313-314, 317-318, 322, 338, 350-352, 357, 363-364, 366-367, 371- 373, 383 administrativa(s), 59, 61, 65, 119 calendarizarlas, 36, 269 de control, 59, 65 flujo de, 328 industrial, 8 inEormática(s), 10, 52 operativa(s), 59, 65, 74, 310

Actu&zación(es), 119, 181, 183, 197- 198, 213, 263, 266-267, 287, 289-292, 352, 356, 358, 361, 363, 369, 375, 383

Adams, T., 20 Adaptabilidad, 252, 256 Adaptación, 55, 289 Administración, 10, 26, 28, 46, 64, 86,

88, 104, 108, 110-111, 114, 127-

128, 161, 188, 214, 294, 314, 326, 349-350, 353, 356, 358, 361-362, 366- 375, 377-378, 381, 383-385 como función, 105, 320, 322 de empresas, 61 de la Función Informativa, 9-14, 20, 42-43, 49-51, 57-58, 70, 72-73, 88-89, 91-93, 104-112, 120-121, 123-126, 321 global, 58, 60, 62

Administrador(es), 27, 37, 108, 110, 120, 124, 126, 128, 344, 371 de bases de datos, 37, 48, 331 . . . de empresas, 126 de espacios en discos, 48 de la función informativa, 10, 90, 120, 126-127

Agilidad administrativa, 343 Agricultura, 107 Ajustes, 51, 133, 145, 293 Almacenamiento

dispositivos de, 226, 279 medios de, 215

Analfabetismo computacionaI, 59, 64-65 Análisis, 12, 34, 53, 55, 66-67, 72, 83,

91, 93, 112, 114-117, 121-122, 132, 145-146, 148, 155, 157, 165-166, 170, 174, 181-182, 188, 195, 197, 237-239, 248, 260, 271, 273, 293, 300, 303,

315, 323-325, 328-331, 333, 338, 357, 376, 378, 384

Analista(s), 39, 115, 117, 127, 144, 175, 196-197, 204-205, 208, 211, 237, 240, 243, 250-251, 255-256, 258-261, 263- 269, 279, 282, 284-285, 287, 292, 298-299, 351-354

Apertura comercial, 27 Aplicación(es), 34, 64, 87, 119, 122, 176,

182, 206, 211, 266, 315-336, 338, 344 horizonte de, 11

Aprendizaie, 43, 72, 104, 109, 125 ' método de, 78

modelo de, 13, 20, 61-63, 89, 125,

363; 365; 381-382; 386' actualizados, 287, 325 administración de, 213, 325, 335, 370 alternos, 210-211, 220 base, 287 clasi!3cados, 263 confusión en, 104 copia de, 281 dañados, 177 de datos, 46, 92, 187, 213-214, 223, 236, 313, 369 de docu&entos, 81 de movimientos, 287, 300 de paso, 287 de producción, 210-211, 214 de programas, 216 de seguridad, 234, 386 de uso universal, 222-223 directo(s), 216, 219, 222-223 históricos, 215, 225, 236 indexados, 222 inválidos, 2 13 locales, 215, 382 maestro(s), 213, 215, 224-226, 300 magnético, 312-313 manejo de, 285 organización de, 255 para pruebas, 225 resguardados, 214 secuenciales, 216-218

indexados, 216, 218 VSAM, 216, 219-220, 223

hea(s), 120, 214, 238, 249, 260, 270, 272. 322, 325, 342, 347, 361-362,

371, 383, 385 administrativa(s), 36, 61, 344

estructuración del, 61 de acción, 192, 349, 353, 356, 361,374 de asesoría técnica, 75, 117 de capacitación, 70-71, 331 de control, 299 de especialistas, 189 de informática, 5, 12-13, 21, 23-29, 35, 48-50, 52-54, 57-62, 68, 73, 75- 76, 78, 81, 84-86, 101, 113-115, 117- 120, 125, 128, 134, 136-137, 139-142, 144, 147-149, 152, 154, 164, 170, 173, 177, 180, 182, 239, 295-296, 308-310, 317-318, 320, 322-323, 327, 329-334, 336, 338, 342-344

administración del, 47, 49, 118, 337, 339

administradores del, 344 centralizada, 55-57 descentralización del, 28, 51, 56,

61, 69 descentralizada, 55, 60 funciones del, 149 historial del, 114, 328, 333, 336 modernización del, 58 organización del, 143 reorganización del, 51 servicio del, 337

de instalaciones, 367 de procesamiento de datos, 70-71 de programación, 175, 266 de servicio, 288, 342 de sistemas, 240, 277 de teleproceso, 176 operativa(s), 13, 134, 177, 277, 305- 306, 309

Arte, 98, 114 Asesor(es), 77, 87, 113, 141-142, 152-

153, 155-158, 160-163, 174, 381 Asesoría, 75, 77, 117, 154, 157, 162-163,

188 Auditor, 337 Auditoría(s), 10, 175-177, 238, 293, 383

de sistemas, 117 técnica(s), 114, 146, 173-174, 178, 296, 335, 358, 383, 886

Autoexplicativo, 282 Automatización, 12, 33, 50, 56, 68, 74,

92, 126, 245, 248, 250, 305, 309, 314- 315, 349, 355-357, 361, 380-381, 383, 385 necesidades de, 83, 357

Autonomía operativa, 54

Bemúdez Limón, R., 167 Bibliografía, 314 Biblioteca(s), 216-217, 222-223, 226-231,

234, 288, 370-371, 385 alternas, 210-21 1 carga, 227-232 de producción, 211 fuente, 227-232 primarias, 233 secundarias, 233

Bloferismo, 33

Caducidad, 215, 236, 245, 247, 275, 277, 282, 286-287, 382

Calidad, 13, 61, 65-66, 79-80, 82-83, 156, 159, 191, 194, 250, 295, 309, 313, 322, 325, 327, 335, 342, 349, 351, 357, 361, 366, 369-373, 376-377, 379, 383-384

Calificador, 223 Cambio(s), 51, 58, 181, 209, 211-212,

253, 268, 284, 324, 332, 341, 353, 365-367, 376, 378, 386 en las actitudes, 67 organizacionales, 49, 332 permanentes, 210 procesamiento de, 212 temporales, 210

Capacidad(es), 82, 88, 141, 145, 147, 267, 271, 349, 356 de almacenamiento, 95-96, 254, 313 de las computadoras, 34, 324 de memoria, 43, 46, 96, 254 de res uesta, 113, 322 de tra k' ajo, 154 Financieras, 132 informática, 55 organizacionales, 132 profesional, 6, 140, 319 técnica, 26, 29, 53, 85, 135, 137, 317

Capacitación, 64, 66, 69-71, 78, 82, 116- 117, 148-151, 153, 175-177, 188, 272- 273, 284, 295, 307-309, 315-316, 331, 349, 356, 358, 361-362, 375, 376, 385 especializada, 48 externa, 149-150 informática, 125 interna, 149-150 técnica, 37, 39, 149, 335, 377-378, 385-386

Capote, A,, 14 Captación, 203-206, 251, 254, 258, 271-

272, 275-276, 290-291 Captura, centro de, 117

Carpeta administrativa, 270, 273, 275, 277, 281, 288 de captación de datos, 288

Castañeda M a h , F., 14 Catalogación, 145, 204, 206 Catálo o(s), 244, 250, 271, 275 Centrafización, 59, 322 Ciencia(s), 8, 99

computacionales, 167 Científicos, 168 Cintoteca, 284 Circuitos electrónicos, 92 Clasificación, 263, 278 Cliente(s), 9, 13, 35, 37, 50, 57, 65, 68,

80, 85, 87, 89, 95, 99-100, 125, 139, 158, 168, 276, 310, 313, 342-343 atención a, 66, 82

Codificación, 145, 186, 196, 198-199, 203, 205-206, 224, 227, 245, 260, 274-275, 285, 300, 303-304

Colapso, 8, 252, 256 Comercialización, 123 Comercio(s), 7-8, 107, 320-321 Compatibilidad, 181, 255 Competencia, 12, 50, 52, 55, 66, 81,

124, 130-133, 295 Competitividad, 68, 82, 130-131, 133,

320 requerimientos de, 130

Compilación(es), 145, 175, 204, 206- 207, 280, 324

Compromiso(s) de trabajo, 134, 143- 145, 160-161, 198, 323, 349-350, 352, 356-357, 361, 370, 374-375, 381-384

Computación, 30, 37, 43, 64, 121-122, 128, 167-169, 305, 309-310, 314-315 técnicas de, 238, 307, 314

Computadora(s), 27, 30-32, 34-35, 39, 42-45, 48, 50, 62, 64, 67, 69, 74, 76, 78, 81, 91-97, 102, 108, 112, 127, 139-140, 142, 145, 155, 164, 167-172, 176-178, 185-186, 194, 204-206, 208, 235, 254, 260, 266, 269, 294-295, 297, 307-308, 311-312, 314-316, 321, 324, 328, 330-331, 355, 357-358, 362- 365, 369, 374, 376-377, 382 arquitectura, 310 central, 309, 348, 358, 365 distribuidores de, 39 edición en, 303 personales, 64, 68

Cómputo, 31, 91, 251, 360 centro@) de, 25-27, 33, 36, 45-46, 48-

49, 57, 68, 85, 93, 96, 113, 140, 148, 150, 165-166, 170-171, 187, 207-210, 213-216, 223, 235, 254, 277, 281, 286, 289, 299, 303-304, 308, 321, 362-363, 383

administración de, 43, 46-49, 73 protección de, 47

equipo(s) de, 5, 36, 38, 40, 44, 47, 50, 60, 64, 68, 71, 96, 99, 116, 123, 127, 139-142, 148, 150, 153, 155, 168-169, 172, 176, 179, 234, 255, 261, 295, 306, 316, 332, 334, 352- 353, 355-358, 360, 362-363, 365-367 369, 373, 375 3 recursos de, 23-24, 42, 55, 71-72, 80- 81, 89, 114, 141, 143, 146, 148, 171, 195, 234, 251, 259, 256-257, 270, 290, 294, 296, 314-315, 320-321, 323, 349, 351-352 requerimientos de, 56, 180, 239, 250, 308

Comunicación(es), 34, 43, 99, 112, 115, 118, 126-127, 139, 146-147, 165, 177- 178, 242, 268, 298, 311, 365-367, 383 falta de, 147, 164, 178 medios de, 65 tecnología de, 48 vía

microondas, 36 satélite, 36 telefónica, 36

Confiabilidad, 125, 247, 273 Confidencialidad, 125, 214, 326 Configuración del equipo, 141, 254,

261, 326, 332, 360, 374, 377 Conocimiento(s), 7, 47, 53, 64, 72, 75,

78, 83, 85, 119, 121, 126, 135, 137, 140, 148-149, 152, 156-158, 160, 162, 168, 186, 191-192, 237, 240-242, 246, 250, 252-253, 255-256, 258-260, 264, 266, 292, 298, 300-301, 303-304, 306, 309, 315-317, 323, 371-372, 375, 385 certero, 109

Consulta(s), 34-35, 213, 216, 235, 245, 274, 287-288

Consultor(es), 154, 156, 178, 191, 358- 359

Consultosfa, 154-155, 347-348, 355, 357, 359. 380

contadores, 201, 264 Contexto, 106, 338

administrativo, 61 mformático, 59, 61, 67, 89 integral del programa, 196

Contratación, 151-154, 157, 346, 358, 381. 385

~on&~(es) , 118, 122, 125, 143, 145, 147, 159-160, 174-175, 183, 187, 209, 211, 213, 236, 245, 251, 280, 299- 300, 314, 323-324, 333, 337-339, 349, 361, 363-364, 368, 370, 372, 374, 385-386 administrativos, 155 cifras de, 115, 175, 195-196, 207-208, 245, 264, 276-278, 280-281, 283, 285, 287, 369, 371-373 cláusula(s) de, 207-208, 210-211, 280, ' 8282-283, 300-304 de avance, 136, 184 de cambios, 211, 324, 350-351 de inventario(s), 61 de la información, 169, 321 de la producción, 46, 61, 116, 177, 303 - - - de procesos, 304, 334, 370-372, 379 de salto, 282-283 lineamientos de, 123 matrical de procesos, 301, 304 matriz de, 370-371 mesa de, 116-117, 182-184, 197, 331, 334, 353-354, 370-371, 379 parámetro(s) de, 232, 262, 264, 289, 300, 303, 326 punto(s) de, 252-254, 256, 283, 288

Conversión, 263, 277, 281 Coordinación, 118, 124, 349 Creatividad, 134, 292-293, 315 Crecimiento, 130-133, 333, 384

alternativas de, 131 competitivo, ciclo de, 127, 129-133 empresarial, 132 expectativas de, 61

Cuerpos opacos, 257 Cultura

computacional, 46 informática, 12, 31, 38-39, 55, 64-66, 68-69, 71, 80-81, 83, 306-307, 309

Dato(s), 11, 36, 43, 56, 93-95, 97-98, 102, 113, 165, 187, 195, 198, 201, 204, 213-214, 216, 235-236, 245, 248, 254, 262, 267, 271-272, 275-276, 285, 294, 300, 309, 322, 326-327, 348, 357, 366, 369, 374, 382, 384 acceso a, 125, 177, 374-375

directo, 97 remoto, 40

banco de, 64, 155, 348

base(s) de, 32, 34, 36, 47-48! 116, 185-189, 216, 221-223, 255, 326-327, 331-332, 335, 374-375, 377-379, 381- 382, 386

arquitectura de, 378 captura de, 173, 178, 275, 286, 312, 328, 330-331, 334, 368-370, 379 capturista de, 335, 369, 379 clasificación, 263, 276 datos, 277 de cuantificación, 244 estadísticos, 287 flujos de, 254 históricos, 47, 214 laterales, 272 organización de, 185-186, 189, 197 procesamiento de, 5, 22, 31-32, 70- 71, 97, 165-166, 173-174, 177, 238, 250, 252, 255, 260, 276, 322

centro de, 264, 362, 379 equipos de, 42

proceso de, 47, 53, 58-59, 67, 108, 113. 299. 321.351

recuperación de, 314 seguridad de, 37, 117, 125, 315, 335, 380 superfluos, 251 trasmisión de, 34, 155

Dependencias gubernamentales, 7, 46, 95 Depuración, 145, 204, 206, 263, 266,

313, 325-326, 382 Desarrollo, 30, 33, 38, 42, 86, 98-99,

126, 129, 132, 144, 147, 149, 161, 165, 174, 178-179, 188, 190, 204, 214, 235, 239, 241-243, 255-256, 258, 260, 270-273, 292, 305, 309, 315, 320, 322, 324-325, 347-351, 353-858, 360-362, 364-376, 378, 380-381, 383- 386 humano, 98 técnico, 145, 347, 349, 356-357, 360- 361, 366, 375, 380, 382-384, 386 tecnológico, 335

Descentralización, 28, 51, 53-54, 56, 309 estudio de, 53

Desem leo, 9 Despil ? amo, 76, 120, 155, 204, 295, 316,

320 computacional, 5, 9, 27-28, 41-43, 48, 52, 54-55! 59, 61, 72-73, 75-76, 78, 89, 104, 114, 121, 124, 128, 135, 292, 296, 306, 321

infomático, 5, 20, 75 Devaluación, 8 Diagrama(s), 249, 251, 254, 258, 260,

273-275, 277, 281, 339, 347 de bloque, 145, 198, 203-205 de entradas-salidas, 282-283 de flujo, 248-250, 257, 272, 277, 281 de impresión, 279 de proceso, 195, 207 operativo, 252, 254

Diagrarnación, 251, 253 Dinámica, 310

de la competencia, 124 del mercado, 124 del negocio, 124 organizacional, 29, 124

Discos, 95-96, 213, 276, 279, 298, 311, 313, 325 espacio en, 176, 186, 382

Diseño(s), 22, 93, 145, 148, 165, 188, 195, 207, 237-239, 252, 256, 260-261, 270-271, 274, 279, 292-293, 303, 326, 328-329, 331, 349-353, 374 conceptual, 352 de bases de datos, 34 de impresión, 272, 283 de sistema(s), 48, 97, 114-117, 164- 165, 169, 174, 188, 250-251, 253, 256-257, 273, 275, 287, 292, 325, 330, 350, 357 de software, 185 del hardware, 185

Disparador(es), 232, 303 Disponibilidad, 252, 256, 298, 349-350,

356, 360, 362, 369, 374, 376, 378 Dispositivo(s), 186, 262, 265, 272, 275-

277, 281-282, 314, 366 de acceso directo, 95-98, 279 magnéticos, 155, 276, 287, 362-363

Distancia tecnológica, 320 Documentación, 22, 104, 115, 119, 135,

144-146, 159, 174-175, 195-196, 204, 207-208, 240, 243, 248-249, 257-258, 268-270, 278, 284-285, 288, 290, 299- 301, 303-304, 324, 351, 353-354, 357 administrativa, 353 carpetas de, 211-212, 282 estándares de, 176-177 técnicas de, 315

Documento(s), 248-250, 271-272, 281, 285-286, 288, 307, 313, 327, 333, 336, 346, 368 fuente, 245, 247, 258, 274-275, 285, 290. 368-370

Ecología, 8 Economía(s), 8, 65, 80, 320 Educación, 8, 122, 128

informática, 345 Eficiencia administrativa, 114, 320, 322,

325, 338 Electricidad, 101 Electrónica, 99, 152, 185 Electrónicos, 33 Empacado, 280 Empleo(s), 8, 321 Empresa(s), 5, 8, 10, 13, 22, 27-29, 34,

36, 41, 49-50, 53-60, 62, 64-69, 71, 74, 77-82, 88-89, 91-92, 94, 97-100, 104-106, 110, 112-113, 120, 123-127, 129-130, 132, 139-140, 144, 151, 163, 216, 253, 291, 306-310, 320, 322-323, 332-333, 339, 342, 348 decisiones administrativas de, 113 directivos de la, 56 en colapso, 130, 132 necesidades de, 151, 153 organización de la, 118 perezosas, 83 proyección de, 113, 124, 139 sistematización de la, 113-1 14

Encuestas, 21, 24 Energía, 8, 101, 112, 133, 366-367 Enseñanza, 121-122 Entrenamiento, 284 Error(es), 62-63, 72, 85, 89, 103, 113-

114, 117-1 19, 174, 206, 269-271, 285, 298, 308, 314, 319, 322, 324, 326, 333, 336, 340, 342, 374 controlar los, 62 de sintaxis, 205-206 depuración de, 145 en el tiempo, 338 mensajes de, 200

Esquema(s), 54, 56, 59, 72, 109, 133, 135, 140, 196, 205, 214-216, 257, 261, 310, 329, 339, 342, 377-378 administrativos, 310 competitivo, 132 de modernización informática, 70 funcional, 318 informático, 48, 90, 123, 129-130, 143 organizacional(es), 12, 54, 56, 60, 76, 81, 90, 119-120, 310, 332-333

Estabilidad, 63, 140, 340 Estadísticas, 176, 187, 299, 362, 364,

369, 375 Estancamiento(s), 80, 296

Estandarización, 78, 11 9, 25 1, 266, 270 Estrategia(s), 65, 71-72, 78-79, 84, 87-88,

114, 119, 122, 128, 133, 135, 140, 144, 147, 155, 157, 165, 188, 296, 300-301, 303, 309, 312, 315-316, 321, 327, 333, 336-337, 339, 343-344, 362, 364, 371 administrativas, 61, 81-82, 333 de cambio, 67 de capacitación, 148 de competencia, 131 de control, 62, 333, 337 de descentralización, 309 de instalación, 136 de investigación, 240 de negocio, 49 de trabajo, 68, 76, 82 didácticas, 122 informática(s), 6, 12, 49-50, 68 operativa(s), 82, 11 1

Estructura(s), 56-58, 68, 73, 88, 158, 186, 232, 238, 240, 249, 251-253, 279, 293, 310-311, 329, 332, 354, 359, 375, 378-379 de directorios, 311 descentralizada, 60 Funcional, 233 jerárquica, 249 organizacional, 149, 158, 260

Estructuración, 119, 185, 188, 247, 311, 346

Ética profesional, 155 Evaluación(es), 121, 124-125, 132, 179-

181, 248, 250, 252, 256, 269, 280, 283, 291, 311-314, 323, 335, 343, 384, 386

Excelencia informática, 13, 70, 80, 131, 133, 319-320, 345

Expansión, 43 Experiencia(s), 6, 8-9, 11, 21, 37, 51, 53,

62-64, 72, 75, 83-84, 86, 88, 92, 104,

152; 154-155,' 157-158,' 161-163,' 171, 175, 183, 199, 214, 232, 238, 267, 298-299, 315-316, 319, 321, 336, 340, 344 académica, 108 capitalización de las, 62 laboral, 108 profesional, 6 técnica, 344

Factor(es) Administrativo de la Función

Informática. Véase Factor AFI AFI, 9-14, 20, 25, 28-29, 50, 73, 106, 128 de bloque, 195-196, 279

Filosofía, 66, 165, 175, 181, 209, 212, 239, 303 de la computación, 171 del producto terminado, 150, 158, 160

Finanzas, 89, 101 Jormación i i cultural informática, 66-67

profesional, 120 Formato(s), 207, 224-226, 229, 231, 251.

262-263, 278-279, 281, 283, 301, 313 de arámetros, 208 mú l' tiple, 278

Fórmula(s), 196, 201, 208, 263, 265, 312 Franelógrafos, 257 Funcionalidad, 22, 50, 140, 244, 291,

356, 361, 375

Generación cuarta, 47 tercera, 40, 46

Globalización, 8, 49 Grabación, 44, 365 Gráficas, 197, 228-232 Gran depresión, 8

Hábitos de trabajo, 66 Hardware, 29, 43, 48, 50, 94, 126, 156-

157, 177, 179, 185-186, 188, 251, 310, 323, 332, 335, 348, 356-358, 360-364, 380-381, 384, 386

Hemández H., E,, 10 Hernández Jiménez, R., 13, 19-20 Hernández Marthez, E., 167 Historia viciada, 7 Hoja de cálculo, 306, 311-312

esquema de, 312 Humanidad, 107-108, 112, 127

Identificación, 95, 233-234, 236, 261, 278, 282, 303,311,314, 373, 382

Implantación, 58, 252, 256.260, 269, 272. 290. 351. 353. 357

- , - , formatos de, 196, 208, 280, 284

Impresora(s), 43, 45, 262, 282, 365 Incertidumbre administrativa, 11 Industxfas, 107, 320-321 Idormación, 7, 46, 49-50, 53, 56, 61,

64, 67-68, 81, 88, 94, 97, 108, 113- 114, 121, 123, 139, 144-145, 164-165, 169-173, 177, 188-189, 191, 207, 222, 241, 243, 247-249, 253-254, 256-257, 260, 262-264, 267, 274, 276-277, 281, 284, 286, 288, 292-293, 295, 298, 319, 322, 325, 328, 342-343, 356 actualizada, 65, 97-98 complementación de, 245, 263 de calidad, 129 distribución de la, 245, 289, 335 documental, 243, 286-287 estratégica, 97 flujo de, 242, 250, 254, 257, 260, 273, 275, 277, 281 fuente(s) de, 170, 244, 250, 257, 260 indicadores de, 79, 131-132, 343 magnética, 287 modificación de, 145 parámetros de, 131, 210-211, 235 procesada, 38, 309 proceso de, 66, 247, 260, 324 realirnentación, 260, 263, 285 recepción de, 285 recorrido de la, 244, 247 recursos de, 8, 108 requerimientos de, 50, 54, 56, 66-68, 71, 89, 99, 170, 237, 250, 270, 309, 322, 325, 348-350, 355-357, 361, 380 satisfactores de, 318 sumarización, 276 su ercarreteras de, 49 vorumen(es) de, 247-248, 286

Informática(s), 5, 11, 20, 23, 29, 31, 33, 35, 42, 52, 54, 64, 68, 79, 81, 84, 88, 92-94, 98-99, 104-105, 108-113, 120, 122, 123, 126, 129-130, 132, 135, 151, 153-154, 157, 168, 170, 294, 310, 320-321, 339, 342, 345-348, 358 auditoría, 10 comité de política, 53, 60 conciencia, 67-69 crisis de la, 20, 89 deficiencias, 1Q4 desarrollo de la, 31, 33, 39 diseño de la, 8 era de la, 36 esencia, 84 especialistas en, 25 estrategia(s), 6, 12, 49-50 £unción, 10, 20, 38, 41, 50, 52, 56, 59-61, 86, 89, 93, 100, 104-105, 111, 120, 123-124, 127-129, 132, 310, 319- 320, 344

esquematización, 56 misión de la, 124-125, 127

erencia de, 56 I[ erramientas de, 126 historia, 62, 72-73, 127 infraestructura, 8, 39-40, 54, 111 materia(s) de, 9, 321 realidad, 14, 128, 306 recursos de, 109, 124, 140-141, 170 renovación, 54 singularidad, 124 tecnología de la, 20, 64, 68, 122-123, 126-127 visión, 6

Mormático(s), 12-13, 14, 20, 27, 33, 47, 52, 58, 68-69, 73, 80-81, 83-84, 88, 90, 98, 105, 110, 122, 126-127, 135, 137, 165-166, 171, 321, 337 abatimiento, 36 ambiente, 21, 79-80, 89, 128, 134, 337 apoyo, 55, 60, 89, 165-166, 251 aprovechamiento, 104 aspecto, 104

administrativo, 59 campo, 78 desarrollo, 30, 33, 38, 42, 105 destino, 69, 88 deterioro, 20, 26, 89, 120 enfoque, 52 entorno, 26, 35, 60, 69, 84

administrativo, 119 evento, 91 jefes, 135-138, 140, 145, 148, 191- 192 juego, 8 medio, 28, 34, 54 panorama, 123 potencial, 56, 82, 110, 124, 126 procesos, 104 recursos, 93, 122 sector, 78

Informe(s), 87, 141, 251, 327, 350, 356, 366, 374, 382-383

Mraestructura tecnológica, 109, 157 Ingeniería, 65, 117, 334, 365

de instalaciones, 117 Ingeniero(s), 185, 367 Instalación(es), 33, 39, 46-47, 75, 78, 84-

85, 87, 113, 117, 136, 141, 144, 147, 148, 150, 152, 154, 157, 162, 174, 179-186, 188, 190, 193, 203-205, 208, 213-215, 236-238, 256, 293-295, 299, 318, 326, 333-336, 341-342, 344, 353,

358, 360-361, 365-367, 374-380, 384- 385 Físicas, 46, 78, 367 modelo, 187-188, 375

Institución(es), 26, 34-35, 37, 91, 100, 209, 266-267, 322, 342, 385 bancaria, 31 educativa, 106

Instrucciones, 34, 96, 146, 205-206, 283 Instructivo(s), 183, 207, 269, 274, 276-

277, 279-280, 282, 284-285, 299, 302 Instructores, 149, 152 Integración, 270 Integridad, 125, 326, 382 Interfases, 256 Intemet, 49, 123 Interrelación, 101, 333 Investigación(es), 5, 7, 10, 14, 21, 48,

69, 77-78, 86, 88, 113-114, 118, 120, 128, 132, 143, 146-147, 175, 237-244, 247-250, 252-253, 261, 271, 291-293, 299, 305, 307, 320-321, 323, 326-328, 332-333, 336, 338, 342, 352, 373, 376, 378, 380, 383-385

Laboratorio(s), 151, 311, 313-314 Legalidad, 244 Legislación, 12 Lenguaje(s), 34, 38-39, 139, 168, 205,

246, 255-256, 282 de informática, 152 fuente, 206 máquina, 206

Lessing, D., 19 Libro(s), 5-6, 9-11, 26, 45, 48-49, 64, 70,

78, 80, 86, 88, 119, 128. 130. 305- 306, 319, 345

Liderazgo, 83, 294 Literatura, 98 Lógica, 342

Macroactividades, 135 Macrocomputadoras, 96 Macroempresas, 127 Macroinstrucciones, 232 Mantenimiento, 46, 61, 144, 148-149,

161, 174, 176-177, 180-181, 188, 190, 235, 237, 264, 266, 270, 288-289, 349, 351, 353, 356, 360.362, 366, 372-374, 376, 378

Manual(es), 183, 251, 301, 324, 357, 377, 385-386

Maquinaria organizacional, 113 Máquinas de apoyo, 108

electromecánicas, 108 electrónicas, 108 mecánicas, 108

Márquez López, P. E., 14 Materia prima, 61 Material didáctico, 182, 385 Mecánica, 65 Mecanismo(s), 58, 65, 87, 108, 127, 144,

338, 345, 349 administrativo(s), 12, 29, 60-62, 79- 83, 107-108, 113, 310, 337 comerciales, 49 correctivos, 131 de control, 29, 79-83, 107, 338 de evaluación, 124 de medición, 356, 361 de planeación, 107 de seguimiento, 124-125 de servicio, 49 de trabajo, 74 operativo(s), 66, 129-130, 310 organización del, 337

Mecanización, 357 Mecanografía, 313 Memoria, 43, 95-97

posiciones de, 96 Mentalidad, 345 Mercadotecnia, 65 Método(s), 41, 67, 114, 117, 121, 128,

145, 162, 166, 172, 174, 185, 199, 264, 298-300, 311, 325, 349, 351, 357, 359, 376-378, 383, 386 administrativos, 60, 120 de acceso, 186, 188, 195, 262 de control, 60, 120 de prueba, 176 de seguimiento, 125 de trabajo, 36, 62, 78, 117, 173, 177, 184, 190, 295, 324, 332-333, 335, 349, 356, 361-362, 383, 386

Metodología(s), 24, 109, 144-145, 147, 174-176, 190-193, 195, 208, 239, 292, 312, 314-315, 349-350, 356, 361, 374

~i&ocom~utadora(s), 38, 41, 81, 305- 308, 310-311, 315 epidemia de las, 306

Microempresas, 127 Microsistemas, 117 Migración, 326 Moda(s), 99, 315 Modelo(s), 99, 128

matemáticos, 87 Modernidad, 108

Modernización, 52, 54, 59, 65, 67, 83, 320-321 de la(s) empresa(s), 13, 29, 52, 55, 58-61, 65, 82

elementos para, 82 informática, 9, 29, 61, 70 plan(es) de, 27, 55, 79-80, 83 proceso de, 54, 58-59

Modificación(es), 145, 266-267, 270, 274-275, 289-290

M ó d ~ l ~ ( s ) , 232-233, 308, 314-315, 350- 354

Muestreos, 248 Multiprogramación, 32, 177, 254, 364 Mundo

globalizado, 105 informática deteriorado, 7

Música, 98

Navegación, 123 Necesidad(es), 154, 156, 164, 186, 188-

189, 214, 237, 239, 258-259, 268, 273, 289, 292-293, 346 administrativas, 59, 61, 81, 126 de información, 55-56, 67, 113, 164, 169-171, 181, 209, 315 técnicas, 148

Negocio(s), 12, 49-50, 55, 68, 97, 104, 107, 111, 124-125, 139, 162, 216 mundiales, 8

Nomenclatura, 176, 196, 215, 314, 325, 382 de control, 315 esquema de, 234 formato de, 216-224, 226, 234 modelos de, 216

Normas, 247, 249, 252, 269, 274, 348, 350, 363, 366-367, 383

Objetivo(s), 6, 53-55, 71, 130-131, 133, 150, 157-158, 173-174, 177-178, 181- 182, 188, 196-197, 239-244, 246, 249- 254, 256-258, 261, 266, 271, 290-291, 296, 300, 304, 308, 312, 314, 316- 318, 322, 342-343, 348, 350 comerciales, 8 de negocio, 124

Operación(es), 34, 47, 50, 63, 68, 103- 104, 114-117, 130, 144-145, 148, 163, 169, 172, 174, 182, 190, 193, 195, 198, 201, 204, 207-208, 213-214, 235, 239, 243, 245-247, 249-251, 253, 255- 256, 264, 266-267, 269-273, 275, 277, 280-282, 285, 287-288, 290-291, 297,

299-300, 303, 309-312, 314, 324-325, 328, 330, 334, 348, 362-363, 365, 367-371, 373, 376, 379 administrativas, 315 aritméticas, 201 básicas, 241 carpe& de, 207-208, 281, 283-284, 288 de utilería de escritorio, 314 electromecánicas, 244 electrónicas, 251, 253 integral, 50 manual(es), 61, 244, 251, 253, 365 mecánicas, 244 problemas de, 21 semimanuales, 251, 253

Operador(es), 39, 43, 45-46, 48, 116, 177, 282, 297, 362 auxiliar de, 31 de computador, 116-1 17, 235, 297, 335, 365, 379 de impresoras, 297-298 de la red, 116-117, 297-298, 335, 363-364, 379 de periféricos, 116-117, 297-298, 335 de sistemas, 297-298, 335, 370-371, 379

Operatividad, 56, 126, 161, 248, 360 Oportunidad, 7, 250-251, 288, 294, 307,

319-321, 336, 342, 349, 357 Organigrama, 51, 249, 318, 332, 346 Organización(es), 10-12, 14, 35, 45-46,

48, 50, 52, 56-58, 65-66, 68-70, 73, 76, 82, 89, 108, 113-118, 123, 125- 126, 129, 132, 143, 147, 177, 187, 216, 240, 258, 262, 270, 279, 310, 313, 317-318, 322-323, 329, 332-333, 342, 344, 346 control de la, 52 indexada. 198 requerimientos administrativos de, 81. 310 ~ -

sef&cial, 198 visualización de la, 54, 56

Pantalla(s), 35, 81, 232, 275, 312-313 Parámetros, 131, 208, 210-211, 232, 235,

262, 264, 289, 300-301, 303-304, 325 PC, 41, 43, 48, 50, 74, 96, 172, 257 Películas, 257 Perfil(es) técnico(s), 175-177 Periférico(s), 116-1 17, 254, 265-266, 331,

362, 364-365, 375 Periodicidad, 247, 274, 277

Personal, 37, 58, 65-66, 68, 75, 83, 115, 117, 135-137, 141, 144, 148-151, 157, 168, 178, 181, 192, 235, 239, 241- 242, 245, 247, 255, 261, 268, 272- 273, 284, 295, 312, 327-328, 342, 344, 346, 349, 353, 356, 361, 369, 372, 374-378, 381, 385 administrativo, 64 de informática, 33-34, 60, 140, 144, 332 de mando y supe~isión, 82 especialización del, 144, 188, 332 gerencial, 64 motivación del, 149, 315 operativo, 64, 244, 246, 308-309, 315, 377-378 rotación de, 23, 149, 158, 349, 356, 361-362 secretarial, 64, 306, 308-309, 315 técnico, 147, 149, 153, 161-162, 165. 181, 309, 358, 385

formación de, 151 Pirateo, 23-24, 35, 151 Piratería, 37 Plan(es), 83, 107, 131, 188, 208, 239-

240, 246, 326, 349, 351, 356-358, 360, 363, 367, 372, 380-382, 385 de acción, 51, 131, 133 de auditoría, 383 de capacitación, 78, 116-1 17, 148- 150, 308-309, 316, 318, 381, 385 de estudio, 167 de incentivos, 361 de mantenimiento, 362 de producción, 370 de restauración, 155 de servicio, 364 maestro, 71, 254, 350, 380

Planeación, 23, 65, 79, 87-88, 137, 146- 147, 237, 260, 292, 335, 348, 350, 352-353, 355-358, 360, 362, 364-376, 378, 380-386

Planificación, 286 Planificador, 51 Política(s), 7, 176, 239-240, 242-244,

246, 249-253, 256, 271, 288, 291, 348, 350, 371-372, 382 de trabajo, 160

Políticos, 65 Presupuesto, 113 Problema(s)

administrativo, 307-309, 311 informático, 93-94, 101 operativo(s), 67, 161

teórico, 312 Procedimiento(s), 88, 117, 152, 161,

169-170, 174, 176-177, 182, 194, 203, 209, 239, 243, 250, 251, 253-254, 269, 274, 289, 294, 296, 302-304, 337, 344, 349, 356-357, 359, 377-378 administrativos, 11, 34, 108, 123, 126, 129, 169, 357 catalogados, 232 cíclico, 268 críticos, 250 de control, 63, 76, 116-117, 123, 146, 332, 338-340, 370 de emergencia, 50, 85 de instalación, 182-183, 312-314 de reconfiguración, 364 de se uridad, 362 de so y ución, 6 de trabajo, 119, 191, 357 electrónicos, 258 manuales, 238, 258, 260, 285, 289, 291, 293 operativos, 310

Procesador de textos, 306, 312-313 Proceso(s), 65, 82, 93-94, 97, 100, 140,

164, 176, 194, 197, 207, 210, 213, 215, 232, 235, 254, 261-264, 268, 274, 276-278, 284, 286, 288, 290, 293, 295, 298, 300-303, 312, 318, 322, 324-326, 365, 368, 370-372, 379, 382 administrativo(s), 56, 109, 118, 126, 240 automáticos, 215 complejidad del, 247-248 de instalación, 183 de servicio, 56 de trabajo, 104, 108, 111 electrónico, 254, 277, 281, 289 fallas de, 104, 290, 373 manuales, 273 matriz de, 301-303 operativos, 56, 131 secuenciales, 96-98 tiempo de, 97-98, 185 variaciones, 290

Producción, 8, 22, 60, 112, 115-1 16, 141, 145, 147, 174-175, 184, 191, 208, 225, 229-230, 236-237, 266, 297- 298, 300, 318, 320-321, 323-325, 329, 334, 349, 358, 360-361, 367-368, 370 cuotas de, 117, 332

Productividad, 11, 59, 65, 78, 208, 294, 296, 315, 342, 369, 383

problemas de, 5 Profesionalismo, 6, 192 Programa(s), 29, 30, 34, 39, 45, 91-94,

96-97, 99-103, 106, 115, 121, 145, 168, 171, 173-174, 177, 194-199, 201, 203-209, 216, 232, 235, 239-240, 255, 261, 263-268, 278, 280-283, 287, 311- 314, 324-325, 342, 373 aplicativos, 194 asignación del, 197-198 captación del, 209-204 clave del, 278-282 deFinición del, 145, 278 fragmentación de, 98 fuente, 21 1, 232, 267 impresor, 255 inse uros, 104 probucto, 230-232 prueba(s) de, 22, 145, 204, 207, 211, 214, 265-266, 280, 324, 351-852, 375, 377-378

de escritorio, 175, 198, 203, 205, 256 Satélite, 238 selector, 255

Programación, 34, 38, 48, 61, 93, 115- 117, 145-146, 148, 169, 175, 186, 195-197, 235, 255, 260-261, 268, 270, 273, 303, 324, 328-331, 351-353, 358, 376, 378 carpeta de, 207-208, 277, 288 estándares de, 175 lenguaje(s) de, 34, 38, 47, 145, 198, 31- JlL

modular, 34 Programador(es), 34, 36-37, 39, 45, 48,

96, 99-100, 115-117, 127, 136, 144- 145, 170, 175-176, 194-198, 202-206, 208, 227, 263, 265-268, 282, 298, 342, 351-354, 375-377

Proyección(es), 12, 113, 124, 139, 209, 258, 273, 322

Proyecto(s), 88, 118, 127, 135-136, 139- 145, 147, 149-150, 152, 154-163, 165-166, 180, 191, 259, 294, 317, 337, 341, 344, 348-351, 353-356, 374, 385 administrativos, 84, 338 de idomiática, 55 director(es) de, 48, 162 exitosos, 84 requerimientos del, 159, 181 técnicos, 84

Publicidad, 65, 123

Racionalización, 289 Radiotécnicos, 33 Rechazo(s), 285 Recuperación, 46, 176, 215, 311, 314-

315, 363, 376-378, 381 Red(es), 38, 68, 74, 116-117, 176, 186,

298, 330-331, 363-364, 366, 375-376 arquitectura de la, 366-367, 374

Rediseño, 240, 291 Regionalización, 291 Registro(s), 76, 96, 183, 202, 251, 261-

265, 272, 279, 288, 349, 356, 358, 371-372, 381, 384-385 de datos, 93, 95-96, 186 de entrada, 196, 200, 207-208 de fallas, 361-363, 366, 370, 372-375, 381 de salida, 196, 200, 207-208 directo, 32, 42

equipo de, 43-44 máquinas de, 32, 44

formato(s) de, 99, 279, 284 longitudes de, 195-196 maestros, 265 múltiples, 278

Reglamentación(es), 247, 286 Reglas, 234

de codificación, 224, 227 de sintaxis,205

Reingeniería, 11, 66, 123, 126 de aplicaciones, 11 de datos, 11 de procesos, 11 de programación, 11 de sistemas, 11, 29

de información, 11, 27,55, 126 de software, 11

Reinicio, 208, 280 Reporte(s), 187, 197-198, 202, 207, 250-

251, 353, 365-366, 369, 372-373, 376, 378 ~s~dísticos, 324, 353 impreso(s), 35, 95, 196, 298, 373

Reproceso(s), 298-303, 324, 370-371 Resguardo, 46, 125, 177, 215, 236, 358-

354, 381-382 esquemas de, 236 fuera de sitio, 215 local, 215

Res aIdo(s), 176, 215, 224, 236, 247, f80, 282, 286, 311, 315, 365-366, 382

Responsabilidad(es), 6, 42, 68-70 109, 114, 117-120, 126, 140, 145, 159, 178, 180, 192, 214, 235, 268, 270,

289, 294, 298, 317-318, 321-322, 332- 333, 337, 339, 346-347, 350, 361

Restricciones, 252, 256 Revolución

Industrial, 60-61, 64, 108, 120 Informática, 64, 120

Rutas, 61, 216, 220-221 Rutina(s), 205, 255, 265

de cálculo, 197-198, 263 de cortes, 202 de formas preirnpresas, 201 de utilidad, 146 externas, 197-198

Satélite(s), 36, 99 Secuencia, 239-240, 246, 254, 263, 265,

268, 293, 300-303, 370 Seguimiento, 124-125, 136, 315-316,

335, 337-338, 344, 362, 383, 386 como función, 13, 20, 61-63, 71, 83, 89, 125, 339-340 por excepción, 20, 62, 89, 338-339, 344

Segunda Guerra Mundial, 8, 98 Seguridad, 37, 46-47, 117, 125, 177,

194, 208, 215-216, 234, 238, 246, 273, 293, 326, 334-335, 360-362, 365- 367, 379-383, 386 social, 8

Senderos, L., 167 Sensibilidad, 252, 256 Sentido

común, 337 profesional, 53, 180

Servicio(s), 12, 46, 49-50, 52, 56-57, 61, 65, 68, 80, 82-83, 112-113, 116, 124, 141, 143-144, 147-149, 155, 157, 159, 161, 164-165, 176-177, 179, 182, 184, 188, 224-225, 228, 242, 247, 253, 288-289, 291, 295-296, 298, 310, 335, 337, 342-343, 348, 360-364, 366, 378, 381, 384, 386 calidad en, 65-66, 99, 374-377 computacional(es), 71, 85, 156, 180, 303, 334, 347, 355, 360, 365, 374, 379 de apoyo informático, 50, 154, 170 de información, 144 en línea, 37, 40, 78, 367, 375-376 horarios de, 117, 329, 332, 362-364, 372-373 informático, 50, 61, 101, 125

Seudosistemas, 76 Sistema(s), 22, 36, 56, 65, 80, 93, 99-

102, 115-117, 144, 165-166, 169-170, 175, 186, 188, 190, 194, 196, 204, 207-208, 211-212, 214, 216, 228, 230, 232, 235-248, 250, 252-261, 266-275, 278, 281-282, 284-285, 287-288, 290- 293, 297-302, 304, 311, 324-325, 327, 339, 347-350, 352-355, 357, 360-361, 367-368, 370-377, 379-380 analista(s) de, 34, 45, 99, 115, 152, 169-170, 195, 246, 250, 267, 269-270 aplicativos, 224-226, 228 automatizado(s), 358 avanzados, 34 batch, 40, 116, 298, 330, 332 caía el, 46 centrales, 291 clave de, 224-226, 228, 280 colaterales, 238 comercial, 144 computarizado, 161 correlación(es), 252, 255 de comunicación, 146 de consulta, 34-35 de control, 156, 238 de devaluación, 33 de información, 11, 46, 54, 56, 59, 64, 66-68, 71, 79-80, 92-93? 97-99, 104, 114, 126, 129-132, 164-165, 167, 209, 212, 269, 303, 309, 314-315

automatizados, 34 institucionales, 68 reorientación de los, 11

de interruptores automáticos, 50 de teleproceso, 48, 187 electrónico, 259, 289 en línea, 40, 115-117, 323, 329-332 especiales, 116 fuentes del, 251, 253 funcional, 268 improvisados, 55, 135, 237 informáticos, 41, 92 integraI(es), 22, 47, 214, 327 interactivos, 232 locales, 115-117, 331 operabilidad de, 207 operativo(s), 34, 36, 48, 115-117, 146, 176, 197, 214, 216, 223, 226, 230-231, 233-235, 254, 266, 311, 326, 376-377 optimización de, 270, 295 original(es), 22, 238 planteamiento del, 271 prueba(s) de, 173, 224, 228, 230, 268- 269, 275-276, 376-377

en paralelo, 268 piloto, 268

Sistematización, 113-1 14, 310, 322 Sociedad, 7-9, 122 Software, 9, 29, 43, 48, 50, 94, 125-126,

149, 156-157, 172, 177, 179-180, 182- 184, 186, 188, 230-231, 233, 251, 310, 323, 330-332, 335, 348, 355-358, 360-364, 374-382, 384, 386 data base, 117, 377-379 inte ral aplicativo, 126 on &eJ 116-117, 330-331, 334, 375, 379 paquete@) de, 36-38, 64, 104, 136, 170-171, 176, 179-180, 186, 311, 325, 352, 356-358, 374, 376-378, 382 paquetería de, 64

Soporte, 181, 227, 255, 335, 376-377, 379 a la producción, 22, 72 aplicativo, 235 técnico, 48, 60, 115-116, 183, 234- 235, 330-331, 334, 344, 374-376, 379

Subsistema(s), 224-226, 228-230, 232, 261, 268

Sueldos, inflación de, 23, 33 Supercomputadoras, 47

Tabla($, 255-256, 262, 278 de decisión, 256 de información, 256 internas, 196-198, 201-202

Tablero, 32 Tarjeta(s)

inteligente, 50 perforadas, 32, 35, 43, 45, 276

lectora de, 43-44 perforadoras de, 44 sistema de, 35

Tecnicismos, 165, 242, 246 Técnico(s), 12, 22-23, 28, 30-35, 38, 42,

72, 78, 84, 124, 136-137, 139, 141, 148, 154-157, 162, 166-167, 172, 174, 184-189, 191-192, 214, 253, 317-318, 321, 323-324, 333, 338, 342, 344-345, 349, 351 desarrollo, 145, 347, 349, 356-357, 360-361, 366, 375, 380, 382-384, 386 en informática, 37, 180 equipo, 113 recursos, 120, 135, 137, 142, 154- 155, 157, 248-250, 258, 260, 272, 289-290, 296, 299, 306, 309, 333, 349-350, 375

Tecnología(s), 5, 8, 11, 20, 23, 29-32, 40, 43, 50, 59, 64, 68, 75, 78, 80, 83- 84, 92, 95, 98, 104, 108, 112, 120, 122-124, 151, 167-168, 172, 179, 185,

1 188, 305-806, 320-321, 333, 342, 355, ' 361, 375, 384-385 . computacional, 40, 78 1 1 de unta, 35, 79

1 ~ecnok~ico(s) , 11, 35-37, 49, 104, 106, M 126

I avance, 95, 128 atraso, 42, 168 desarrollo, 98 1 1 nivel, 41 potencial, 93, 109

Telecomunicaciones, 29, 101 Teleproceso, 32, 34, 36-37, 47-48, 64,

97-98, 176-177, 187, 255, 366 red(es) de, 38, 176, 364

Teorías administrativas, 107 Tiempo(s), 135-137, 140, 176, 199, 201-

204, 238, 241-242, 247-248, 256, 258, 261, 266, 269-270, 272-273, 275, 299,

m 314, 318, 323, 341, 361, 369, 375-

i 376 asignación de, 204 de proceso(s), 287-288, 295 estimado, 286 máquina, 46, 206, 208, 213, 362

1 real, 32, 37, 187, 286, 298 Trabajo, flujo de, 251 Traducción, 206 Transkrencia, proceso de, 31 Transparencias, 257 Transportación, 101 Tratado de Libre Comercio, 13, 27, 82

Unidad(es) central de proceso, 185, 282 de operación, 115, 330-331 de programación, 115, 330 técnicas, 125 usuaria(s), 50, 54-60, 66-67, 69-71,

118, 124-125, 154, 216-222, 234-235, 240-242, 246, 249-250, 271, 273, 290, 298, 348, 355, 360, 364, 372, 380

estructura, 242 políticas, 242 relaciones, 241-242

Universidades, 13, 35, 38, 49, 104-105, 122, 126-127, 151

Usuano(s), 23, 35, 38, 53, 55-56, 59, 67- 69, 76, 78, 100, 116, 117, 137, 149, 161, 167, 169-173, 176, 179-182, 184, 186, 191, 197, 209, 212, 237-241, 252-254, 256, 269-270, 273-274, 284, 286-289, 292, 295, 297-299, 303, 305, 307, 310, 316, 318, 324, 332, 342- 343, 347-350, 353, 355-359, 362, 364, 368-369, 373, 385 carpeta del, 273-274, 288 Final(es), 78, 342-343 internos, 78 operativo(s), 306, 315, 351-352 requerimientos de, 164-166, 181, 238, 269, 329

Validación, 204, 206, 287 Validez, 244-245, 288 Valor

absoluto, 103 negativo, 103

Variantes del medio, 51 Veracidad, 6-7, 49, 372 Verificación(es), 145, 183, 206-208, 265,

274-275, 373 cibas de, 300 lista de, 136

Vicio(s), 131, 133, 156, 210 Vila, I., 14 Visión

administrativa, 109 penonalizada, 119

Vo atilidad organizacional, 90

Actualmente el ingeniero Hernández Ji- ménez es socio y director del despacho de consultores en informdtica SECONE.

Ha publicado más de cincuenta artlculos en diversas revistas y periódicos del ám- bito informático. Es autor de alrededor de veinte libros de informática, hecho que lo sitúa entre los autores que más obras han escrito sobre este tema en América Latina. De ellas destaca Administración de lafun- ción informhtica, FactorAFI, concepto que ha sido adoptado ya en México como una materia de nivel universitario.

Asimismo, el autor ha participado ampliamente como conferenciante en el ámbito internacional.

Es autor del Taller de computación (en tres volúmenes) dirigido a alumnos de secundaria, bachiiierato y carreras técnicas. Este taller fue el primer curso integral de computación que apareció en el mercado para esos niveles educativos.Por esta razón ha sido considerado por las autoridades académicas como base de los temarios oficiales de computación.

administracion de la funcion informatica

Services