METODOLOGA PARA EL ESTUDIO DE SISTEMAS

Profesor: Ral SAROKA

1. INTRODUCCIN

1. NECESIDAD DE UNA METODOLOGA El primer problema que se nos presenta en el desarrollo de esta metodologa, es justamente saber si estamos usando correctamente este trmino. En primer lugar, deseamos clarificar qu entendemos por metodologa. Con referencia al trabajo cientfico F. Pardinas la define como el estudio crtico del mtodo y a mtodo como una sucesin de pasos ligados entre s por un propsito. Por su parte el diccionario de la Real Academia Espaola define metodologa como la ciencia del mtodo y a mtodo como modo de decir o hacer con orden una cosa y tambin como el modo de obrar o proceder. Guardando la debida distancia con un trabajo de orden cientfico nos atrevemos a utilizar dichos trminos dndoles las siguientes acepciones. Mtodo: conjunto de etapas que se llevan a cabo en un orden determinado y que mantienen entre s una estrecha relacin con el propsito de estudiar un sistema de informacin. Metodologa: estudio del mtodo que se utiliza en el anlisis, diseo e implementacin de sistemas de informacin. Cul es la justificacin para desarrollar y hacer conocer una metodologa? Hay varias razones. En primer lugar pensamos que no existe ningn misterio asociado con la tarea de sistemas y que, por el contrario, es beneficioso que tanto usuarios como hombres de sistemas tengan una muy clara idea de cules son los propsitos de cada etapa y sus respectivas fases (subetapas). Otra razn fundamental es que nicamente a travs de una metodologa ordenada y clara es posible obtener resultados satisfactorios de un trabajo en equipo, pues ella permite coordinar y hacer comprender a cada integrante del grupo de trabajo su participacin e integracin de su respectiva tarea con las del resto. La existencia de una metodologa nos permite tambin satisfacer el propsito de esta publicacin, dar una clara introduccin sistemtica a quienes estn interesados en conocer el trabajo de sistemas.

2. ETAPAS DEL ESTUDIO DE SISTEMAS Hemos dividido el estudio de sistemas en tres etapas y stas a su vez un nmero variable de fases. El criterio para fijar esta divisin ha respondido simplemente a un propsito prctico. Es tan discutible el criterio de clasificacin adoptado como cualquier otro que fije 10 o 40 etapas. Hemos pensado que siguiendo el criterio de factorizacin progresiva que tan a menudo se estudia en relacin con sistemas en general y que luego lo mencionaremos como premisa bsica de trabajo, era preferible crear pocas y claras divisiones para ir gradualmente abriendo cada una de las cajas negras de las etapas, para llegar a las fases, a sub-fases y a tareas elementales si fuera necesario. As fijamos que las tres etapas son:

ANLISIS DISEO IMPLEMENTACIN

A continuacin describimos brevemente el propsito de cada etapa y sus respectivas fases. El ANLISIS es el estudio de la situacin actual que se concreta a travs de las siguientes fases: Estudio preliminar: tener una idea general de sistema a estudiar que permite llevar a cabo la siguiente fase: Planeamiento del proyecto: fijar un plan que involucre las fases siguientes con fijacin plazos, recursos y presupuesto. Relevamiento detallado: recoger toda la informacin necesaria que permita concretar la siguiente fase: Evaluacin y Diagnstico: emitir un dictamen crtico sobre la situacin actual que dar origen a la necesidad de planear el mejoramiento del sistema actual o su remplazo por uno nuevo. El DISEO se relaciona con el nuevo sistema y comprende las siguientes fases: Diseo global: plantear en trminos generales la mejora del sistema anterior o la nueva propuesta con especificacin de sus posibilidades y costo. Diseo detallado: traducir el diseo global en trminos en que el mismo pueda ser operable. La IMPLEMENTACIN involucra trasladar a los hechos la fase de diseo. Para ello se concreta en tres fases: Planeamiento del proyecto: coordinar los recursos necesarios para la implementacin propiamente dicha del proyecto. Puesta en marcha: dar comienzo efectivo al sistema diseado. Seguimiento: asegurar que el sistema diseado es correctamente implementado y que se solucionen los imprevistos que vayan surgiendo durante la puesta en marcha.

En rigor debemos recordar como Simone que cualquier metodologa para resolver problemas finalmente encaja dentro de las etapas que por primera vez desarrollar John Dewey: 1. Cul es el problema? 2. Cules son las alternativas? 3. Cul es la mejor alternativa? Quien haya estudiado la metodologa para tomar decisiones o la metodologa para resolucin de problemas mediante la investigacin de operaciones recordar la gran semejanza con la propuesta de Dewey. Tal como se ver en nuestro desarrollo el ANLISIS se asemeja a la primera etapa (cul es el problema?) mientras que el DISEO a las dos siguientes. Quedara solamente considerar la etapa que hemos denominado IMPLEMENTACIN que interpretamos est implcita en la tercera etapa de Dewey.

Si bien las etapas se exponen en un orden secuencial, no debe interpretarse que una fase comienza exactamente con la terminacin de la anterior. En realidad muchas de las fases se superponen y an puede decirse que se desarrollan casi paralelamente. En los grficos que a continuacin se presentan se muestra: en el grfico 1 las fases del estudio de sistemas tal cual se encuentra presentados en este trabajo. En cambio, en el grfico 2 se pretende ejemplificar cmo se suelen superponer en la realidad dichas subetapas.

|ANLISIS |DISEO |IMPLEMENTACIN | |Estudio | | | |Prelimimar | | |

Estudio Prelimimar | | | |DISEO | | | | | |Planeamiento Proyecto | | | | |IMPLEMENTACIN | | | |Relevamiento Detallado | | | | | | | | | | |Evaluacin y Diagnstico | | | | | | | | | | |Diseo Global | | | | | | | | | | |Diseo Detallado | | | | | | | | | | |Planeamiento Implementacin | | | | | | | | | | |Puesta en marcha | | |FIGURA 2 | | | | | | | |Seguimiento | | An ms, podemos decir que no solamente existe una necesaria superposicin sino que es frecuente volver atrs a raz de descubrir falta de informacin o fallas de la actividad previa. Insistimos, por lo tanto, en la idea de que no se trata de una metodologa rgida, la metodologa aqu descripta pretende ser universal en cuanto a sistemas de informacin se refiere y es independiente del medio de procesamiento que podra ser utilizado. No obstante ello, se hace alguna referencia a los mismos, con el propsito de dar ejemplos que clarifiquen alguna situacin o bien para enfatizar las diferencias que se presentan en la utilizacin de los mismos. Quin lleva a cabo el trabajo de sistemas? Podramos encontrar dos clases bien diferenciadas: Profesionales y Tcnicos, (a) en carcter de consultores externos, (b) como parte de un rea de sistemas dentro de una organizacin, o sea, en relacin de dependencia. Ambas posibilidades del trabajo profesional son igualmente vlidas y dependen de cada situacin en particular, recomendar una u otra. Si bien hay algunas variantes en el desarrollo de alguna de las etapas, en general la exposicin de la metodologa es aplicable a ambos casos, razn por la cual hemos adoptado el punto de vista del consultor externo, pues las prescripciones para este caso, salvo algunas restricciones, operan vlidamente para el otro. Aprovechando la breve descripcin que se ha realizado de las etapas, aclararemos un aspecto de la terminologa que utilizaremos en este trabajo y podra ser objeto de confusin. En la jerga tcnica es comn hablar de ANLISIS DE SISTEMAS al quehacer relacionado con la metodologa aqu desarrollada, y ANALISTA DE SISTEMAS al tcnico o profesional involucrado en dicho quehacer. Nosotros, en cambio, utilizaremos los trminos ESTUDIO DE SISTEMAS y HOMBRE DE SISTEMAS, pues como se podr apreciar de lo desarrollado ms arriba, para nosotros, el anlisis corresponde a una de las etapas de la Metodologa y por lo tanto se generaran evidentes confusiones, si persistiramos en la utilizacin de los trminos ms difundidos.

3. PREMISAS DEL TRABAJO DE SISTEMAS A continuacin exponemos una serie de recomendaciones o prescripciones generales referidas al trabajo de sistemas:

1. Trabajo en equipo Nos referimos a la conveniencia de integrar, a la actividad del equipo de sistemas, la gente de la lnea. La necesidad de que el propio grupo de sistemas trabaje en equipo es por dems obvia. Esta proposicin reconoce varios fundamentos: a) El primero y principal se basa en reconocer realmente y no como un argumento de venta que el hombre de lnea tiene mucho de s para aportar al anlisis, diseo e implementacin del sistema. Comnmente se reconoce ente las ventajas del hombre de sistemas en relacin con la lnea, la capacitacin, experiencia, objetividad, independencia de criterio y fundamentalmente su dedicacin especfica a la actividad de sistemas. Ratificamos por nuestra parte estas apreciaciones pero deseamos agregar que por su parte el hombre de lnea tiene una gran experiencia lograda en su trabajo y generalmente un potencial de ideas que pueden ser muy tiles para cualquiera de las etapas de la metodologa. Nos podramos preguntar entonces: por qu cuando el hombre de lnea tiene buenas ideas no las implementa? Lo expuesto en el prrafo anterior contiene la respuesta: El hombre de lnea no tiene el tiempo necesario, no es lo suficientemente objetivo, no tiene tampoco la capacitacin adecuada para este tipo de tareas, etc. b) En segundo lugar el xito final de un proyecto de sistema se demuestra con la implementacin del mismo, y en esta etapa se dependen considerablemente de la actitud favorable o adversa que demuestra el hombre de lnea. Por ello es importante integrarlo desde el primer momento, hacindolo participar activamente transmitindole claramente y hacindolo participar de las decisiones que se vayan tomando. La participacin es una excelente medida para motivar favorablemente al hombre de lnea hacia el trabajo de sistemas. Ratificando lo expuesto, entendemos que el trabajo de sistemas llevado a cabo unilateralmente tiene una alta posibilidad de fracaso (total o parcial). Es un trabajo en equipo donde cada parte aporta sus propias virtudes. Sugerimos inclusive, siempre que sea posible, incorporar al equipo mientras dure el desarrollo del proyecto uno o ms de los integrantes de la lnea. Esto no slo involucra poner en prctica los conceptos anteriores, sino que logra una mayor comprensin por parte de la lnea de las dificultades de nuestra tarea y lograr un mayor grado de fluidez en la obtencin de la informacin, la labor de diseo y su posterior implementacin.

2. Requisito fundamental: la implementacin del sistema Si nos atenemos a las tres grandes etapas del estudio de sistemas enunciadas: anlisis, diseo e implementacin; podemos pensar en proyectos que involucren la realizacin de una, dos o tres de las etapas. Si el proyecto cubriere nicamente la primera etapa nos encontraramos con los trabajos comnmente denominados diagnstico o diagnstico y recomendaciones generales. Este, es a nuestro juicio, un proyecto vlido de realizar, siempre que se establezca con claridad sus alcances y limitaciones. Una tarea de esta naturaleza no brinda realmente soluciones, sino que solamente ofrece una descripcin crtica de la situacin actual del funcionamiento de un sistema y eventualmente sugerencias generales para su mejoramiento o remplazo. Hacemos hincapi en esta aclaracin pues es comn que se generen decepciones en quienes han contratado una tarea de diagnstico al no encontrar en las propuestas soluciones concretas para sus problemas. En nuestra opinin no debera comprometerse la realizacin de proyectos que involucraran la primera y segunda de las etapas, o sea de anlisis y diseo. La fundamentacin es la que sigue: La validez de un diseo slo se logra demostrarla implementndola, y generalmente no se logran buenos resultados si esta etapa se deja exclusivamente en manos de la lnea. Si se ha realizado un diseo que no es luego implementado es evidente el despilfarro de recursos realizados. Si se implementa regular o mal, seguramente la lnea har cargos a los diseadores. Por lo tanto el hombre de sistemas no debera aceptar un proyecto que no involucre su participacin activa en la implementacin, excepto en proyectos de diagnstico con la aclaracin de sus limitaciones a quienes los contratan.

3. Modularidad y factorizacin progresiva Si bien son dos premisas que podran tratarse por separado, optamos por su presentacin conjunta pues interactan de manera tal que es preferible desarrollarlas de esta manera. Diremos que la modularidad implica la necesidad de acotar el tamao del sistema a estudiar de manera tal que el subconjunto sujeto a anlisis, no entre en conflicto con el resto de los subsistemas, y por factorizacin progresiva la idea de ir resolviendo los problemas respetando una jerarqua de mayor a menor. Trataremos de aclarar ambos conceptos en las lneas que siguen. En primer lugar, debe recordarse que siendo las organizaciones en extremo dinmicas, los proyectos deben tener una duracin limitada pues de lo contrario es posible que conclusiones y/o diseos generados en un momento pierdan validez al momento de querer implementarlos. Asimismo debe reconocerse la imposibilidad prctica de ir actualizando permanentemente la informacin relevada para ir ajustando el diseo y la implementacin. Por lo tanto si el proyecto es lo suficientemente grande como para que el mismo se extienda por un perodo prolongado deber arbitrarse el procedimiento de crear mdulos relativamente independientes adecuados a un tiempo razonable, que no resten validez al momento de implementarse a las tareas de anlisis y diseo ya realizadas. Como bien lo trata Emery la factorizacin del sistema total en subsistemas acarrea necesariamente la penalidad de la suboptimizacin, sin embargo, es necesaria asumirla, si pretendemos ser realistas y lograr cumplir con los objetivos del proyecto. Es evidente que la definicin de los lmites de cada mdulo y la interaccin entre los mismos es una tarea sumamente delicada y queda por lo tanto como responsabilidad de quien dirige el proyecto. Se deber seguir el criterio de factorizacin progresiva que en sntesis implica fijar una clara jerarqua del sistema de mayor a menor, en donde primero se estudiar el todo y sus relaciones y luego cada una de las partes dentro del marco fijado en la primera etapa. Debe recordarse que el tamao del equipo de sistema condiciona, asimismo, el tamao de los lmites del mdulo a estudiar.

4. Efectividad y eficiencia Es comn hacer uso de estos trminos en relacin con proyectos. Veamos cmo se relacionan con la tarea de sistemas. Por efectividad entendemos la medida en que se alcanzan objetivos prefijados. Por eficiencia, en cambio, la relacin de insumo / producto involucrado en la ejecucin de determinado sistema. As decimos que un sistema es efectivo si logra los resultados previstos como meta. Por ejemplo un sistema de informacin ser efectivo si proporciona la informacin necesaria en la oportunidad fijada. Por su parte diremos que un sistema es eficiente si los resultados obtenidos son ms valiosos que los recursos empleados en su obtencin. As, en el caso de un sistema de informacin el grado de eficiencia estar en relacin con los insumos, horas hombre, hora mquina, elementos materiales, etc. utilizados. Un sistema efectivo puede ser eficiente o ineficiente en la medida del aprovechamiento de los insumos. No tiene sentido hablar de eficiencia de un sistema que no efectivo. Cul es la importancia de desentraar el significado de estos trminos? Pues bien diremos que si bien el hombre de sistemas dedica la mayor parte de su tiempo a estudiar problemas de eficiencia, no debe quedar dudas que la labor fundamental del experto en sistemas reside en determinar la efectividad de un sistema. Es probable que esta actividad le demande, la mayora de las veces un tiempo significativamente menor que el estudio de la eficiencia. Sin embargo el anlisis de efectividad debe preceder necesariamente al otro y realizarse con absoluta idoneidad. Ambos conceptos estn presentes en la etapa del anlisis en particular en el diagnstico cuando debemos emitir juicio acerca de la situacin actual. Tambin estn presentes en el diseo global (en particular el de efectividad) y en el diseo detallado (en particular el de eficiencia). Por ltimo ambos conceptos servirn de gua bsica durante la implementacin.

2. ANLISIS

1. INTRODUCCIN Las tareas de anlisis pueden separarse en dos grupos bien diferenciados. Las dos primeras: estudio preliminar y planeamiento del proyecto son actividades que podran tomarse como previas al anlisis. Se encuentran siempre presente en el caso de un consultor externo dada la necesidad de elaborar un presupuesto. No ocurre lo mismo con un rea de sistemas interna a la empresa que a veces omite la realizacin de las mencionadas fases, aunque a nuestro juicio siempre deberan realizarse. Las dos tareas siguientes corresponden al anlisis propiamente dicho pues involucra la recoleccin detallada de datos y su evaluacin para emitir en funcin de ellos el diagnstico. Las fases del anlisis estn vinculadas al presente, aunque sin perder de vista los objetivos futuros, pues estos pueden mostrar la inaplicabilidad parcial o total de la situacin actual.

2. ESTUDIO PRELIMINAR

1. Objetivo El propsito fundamental de esta primera fase de la metodologa del estudio de sistemas es la de definir el objetivo del proyecto. Para ello debemos tener, al menos, algn conocimiento de la organizacin y conocer los requerimientos de la direccin en relacin a un trabajo de esta naturaleza. Esta fase, que tambin se la conoce con otras denominaciones, como estudio preliminar, definicin de los objetivos, anlisis de antecedentes, etc. est orientada a separar e identificar factores de un problema y no a descubrir o aportar soluciones. El tiempo que demanda esta actividad estar en funcin de los requerimientos fijados por la direccin y el grado de conocimiento que los hombres de sistemas tienen de la organizacin.

2. Desarrollo y herramientas La obtencin de la informacin se realiza a travs de los siguientes medios: 1. Entrevistas. 2. Observacin y visitas. 3. Estudio de documentacin y antecedentes.

Es conveniente tener algn tipo de informacin de la organizacin y el mercado (si es empresa), previamente a la primera entrevista que deba realizarse con los directivos de una organizacin. Esta informacin referida a qu produce, vende o servicios que presta, quines son sus directivos, cul es la participacin en el mercado, cules son las caractersticas de este ltimo, etc. pueden obtenerse a travs de la lectura de las memorias y balances, revistas empresarias, consulta a otros colegas, etc. Es imposible definir con precisin el tipo de informacin y la profundidad con que sta recabarse en esta fase, razn por la cual las sugerencias que se indican en este desarrollo deben entenderse como ejemplificativas y de ninguna manera como datos mnimos o taxativos. De cualquier manera todos los elementos que se mencionan son informaciones que debe poseer el hombre de sistemas y de no obtenerlas en estas circunstancias, lo har, si el proyecto prospera, en la fase del relevamiento detallado. La entrevista se constituye en el medio ms utilizado e idneo para obtener la informacin requerida. Podemos sintetizar diciendo que la entrevista debe, en esta fase, satisfacer bsicamente los siguientes objetivos: 1. Recoger la informacin para poder cumplir con el propsito expresado de esta primera etapa. 2. Vender ideas: Aun cuando nuestros servicios hayan sido requeridos, no implica un pleno convencimiento acerca de la utilidad del estudio de sistemas. Adems, algunos pueden estar de acuerdo y otros no. Tambin puede ser que debamos competir con otros colegas en la obtencin del contrato. Por lo tanto la entrevista debe permitir al hombre de sistemas mostrar sus condiciones tcnicas pero tambin su habilidad para la venta de este servicio, que no se encuentra entre los ms fciles de comercializar. 3. Ganar confianza: Tal como expresramos en el prrafo anterior el trabajo de sistemas no es de fcil venta pues no existe una clara conciencia acerca de las ventajas y beneficios del mismo. Pero adems debe sumarse la aprensin de los individuos que por diversas razones (resistencia al cambio, por ejemplo) ven con temor la posible intervencin en la organizacin y en su trabajo de un hombre de sistemas. Es por ello, que ste debe demostrar que no solo la organizacin es la beneficiaria de un trabajo de sistemas, sino tambin cada uno de sus integrantes quienes tienen en los analistas un colaborador y no un enemigo. 4. Comunicar el objetivo del proyecto: Resulta de fundamental importancia que el objetivo del proyecto se transmita claramente a cada uno de los integrantes de la organizacin, an en esta fase del anlisis, pues se trata de informacin fcilmente deformable y susceptible de crear un verdadero caos en el personal. Si por ejemplo en la cpula de la organizacin se dijera que el objetivo es de racionalizar la empresa, no es extrao, que luego que dicha informacin haya atravesado algunos niveles la denominacin del proyecto haya sido rebautizado vienen a echar empleados. Por lo tanto, aun cuando la empresa lo haya hecho previamente es importante que el hombre de sistemas aproveche la oportunidad de la entrevista para transmitir claramente el objetivo del proyecto y en especial el propsito limitado de esta primera etapa. 5. Requerir colaboracin: Como ya fuera expuesto en el punto. 1.3 la tarea de sistemas es un trabajo en equipo. El trabajo de sistemas, para que tenga xito, requiere el aporte y comprensin de ambas partes. Insistimos entonces que esta situacin debe exponerse claramente al personal de la empresa. En primer lugar para que ellos comprendan en trminos generales cmo se desarrolla la tarea de sistemas. En segundo lugar porque es importante que ellos comprendan que no quedan marginados del proceso sino que por el contrario tienen una participacin activa y necesaria en el desarrollo del proyecto. Por ltimo porque es un fuerte elemento motivador el reconocimiento por parte de los hombres de sistemas la fundamental importancia que el personal juega en todo el proceso de cambio. Quines son los sujetos de la entrevista en esta primera fase, como ya dijramos, depende del alcance que se le ha fijado tentativamente al proyecto y tambin suele incidir el factor tiempo. En general las entrevistas pueden clasificarse en tres categoras que estn en funcin del nivel entrevistado y de la informacin que en cada situacin podemos obtener.

As en las entrevistas con el nivel directivo se trata de obtener: El cuadro global de la organizacin. Objetivos y polticas. Opinin acerca del problema. Estructura de la empresa (Organigrama). Funciones a su cargo. Proyeccin de la organizacin. Estudios anteriores: experiencias.

En las entrevistas con el nivel ejecutivo se trata de obtener: Funciones de sus respectivas reas. Personal a su cargo: cantidad y calidad. Organigrama de sus respectivas reas. Principales flujos de materiales y de informacin. Relacin con las otras reas. Principales problemas de su rea. Estudios anteriores: experiencias.

Finalmente con las entrevistas con el nivel operativo se trata de obtener: Caractersticas de la operacin que realiza (volmenes, mtodo de trabajo, medios mecnicos, formularios y registros que utiliza). Tareas a su cargo.

Mediante la observacin y visitas se trata de obtener una visin global de la ubicacin geogrfica de la organizacin, la disposicin de sus lugares de trabajo (disposicin de la planta, salones de venta y oficinas administrativas en el caso de una empresa), el flujo del proceso industrial, comercial y/o administrativo que se realiza, etc. Este propsito se logra realizando una visita guiada por las instalaciones de la organizacin cuya duracin o atencin a sectores particulares estar en funcin de los propsitos del proyecto. El estudio de documentacin de antecedentes se refiere a la lectura y anlisis de elementos que puedan brindar al hombre de sistemas una idea acerca de la realidad de la organizacin como ser cmo est organizada, cul es su patrimonio, sus ventas, niveles de gastos, restricciones legales a las cuales est sometido, etc. Entre los tpicos elementos que incluimos en esta categora estn:

Memorias y balances. Organigrama y manual de organizacin. Manuales de procedimientos. Informes especiales. Estatutos y/o leyes que regulan su creacin y/o actividad. Estudios de sistemas anteriores. Archivos, registros y formularios.

A continuacin se seala una resea ejemplificativa de los datos que como resultado de las entrevistas, visitas y estudio de documentacin deben contar los hombres de sistemas:

Productos que fabrica y/o vende. Dotacin total y sectorial de personal. Volumen de Ventas. Volumen de Compras. Metros cuadrados ocupados. Nmina de propietarios. Patrimonio Neto. Resultados. Nmina de autoridades. Participacin en el mercado. Principales competidores. Principales proveedores. Principales clientes. Otros asesores. Regmenes legales a los cuales est sometida la organizacin. Medios de procesamiento que se utilizan.

Para la mayora de los tems antes mencionados es til tener los datos para un perodo de 3 a 5 aos de manera tal que permitan dar una imagen adecuada de la evolucin sufrida en los ltimos aos que muchas vece suelen ser los condicionantes del motivo que origina el pedido de estado de sistemas. Para facilitar la labor de recoleccin de los datos se utilizan comnmente listas de control (check-lists). Estas listas o guas de relevamiento son un enunciado generalmente bastante largo y detallado de las preguntas que uno debe formular a los datos que debe recoger de manera tal que la tarea de los analistas se realice en forma ordenada y principalmente no se omita la recoleccin de datos importantes. Ahora bien, de ninguna manera contemplan todas las organizaciones y situaciones posibles. El analista deber en todo caso seleccionar aquellos tems que son aplicables y agregar aquellos otros que su experiencia y las circunstancias le sugieran. Al margen de las que se puedan elaborar para cada una de las etapas de la metodologa, cada una de las tcnicas permite tambin elaborar para cada una de las etapas de la metodologa, una lista de control. As por ejemplo tenemos listas para anlisis y diseo de formularios, medicin de trabajo administrativo, para anlisis de registro y archivo, etc. Quienes tienen experiencia en el campo de la auditora contable, han utilizado o consultado con seguridad las guas de evaluacin de control interno o de procedimientos de verificacin. Esta primera etapa concluye con la definicin del objetivo del proyecto. Recordemos que es probable que frente a una exposicin de un problema o una serie de ellos, el analista haya procedido a realizar un relevamiento preliminar que le permitir interpretar ms acertadamente los requerimientos fijados por la organizacin. Este relevamiento podr en definitiva confirmar la posicin expuesta por la organizacin, o bien le dar elementos como para redefinir de comn acuerdo con la direccin el objetivo del proyecto. En cualquiera de las circunstancias debe quedar perfectamente establecido que la fijacin del o los objetivos del proyecto debe contar con la aprobacin de ambas partes la direccin de la organizacin y los hombres de sistemas-. Debe definirse en forma muy clara y precisa, y determinar qu se espera de cada una de las partes y tambin cul ser el resultado del estudio. De todas maneras, esto no implica que durante el desarrollo del estudio (especialmente durante el relevamiento detallado y diagnstico) el aporte de elementos adicionales lleve a redefinir, nuevamente de comn acuerdo, el objetivo del proyecto. Como advertencia general debe sealarse, tal como se hace en la descripcin de la metodologa para tomar decisiones, que no deben confundirse los sntomas exteriores del problema planteado con el o los verdaderos factores crticos (reales versus aparentes).

3. PLANEAMIENTO DEL PROYECTO

1. Objetivo El propsito de esta fase es elaborar el plan de trabajo correspondiente a las fases siguientes. Tratndose de un servicio externo, deber elaborarse adicionalmente, como mnimo, un presupuesto. La fase anterior ha servido entonces para reunir informacin que permite concretar sta.

2. Desarrollo y herramientas El desarrollo de esta fase corresponder fundamentalmente a la planificacin del anlisis, pues a esta altura del proyecto no siempre es posible incluir en los planes la labor de diseo y menos an la de implementacin. Aun cuando un plan incluya la totalidad del proyecto no elimina la necesidad de planeamiento de las respectivas etapas, en particular en la implementacin para la cual se ha previsto una fase especfica. En particular se desea mostrar las caractersticas de una tpica presentacin de servicios profesionales. Como en cualquier proyecto que se planifique se deber determinar en primer lugar las distintas tareas que deben cumplirse. A cada una de ellas corresponder asignarle tiempos estimados y establecer el calendario resultante. En esta fase resulta til, cuando no imprescindible, la utilizacin de las tcnicas comunes de programacin y control. Nos referimos por ejemplo a los grficos Gantt o bien las tcnicas de programacin por camino crtico (Pert, CMP, etc.). En muchos casos, la relativa complejidad del proyecto parecera no justificar la utilizacin de estas tcnicas. Sin embargo, entendemos que cualquier proyecto, aun los ms sencillos justifican utilizar los diagramas de barra (tipo Gantt) y siendo un poco ms complejos, un diagrama de flechas (camino crtico) aunque sin llegar a su grado de aplicacin ms sofisticada. Corresponde, asimismo, determinar el equipo humano interviniente. Implica una definicin de la cantidad y calidad de los mismos. La calidad a la cual nos referimos, es la relacionada con la distinta capacidad, experiencia y capacitacin e los integrantes de un equipo de sistemas. As podemos tener la siguiente categorizacin: Director de Proyecto. Supervisores o Analistas Jefe. Analistas Principales. Analistas Auxiliares. Un equipo de sistemas suele contar, adems, con la colaboracin de dibujantes, dactilgrafas y asesores especiales. Es comn, por otro lado, que en el caso de consultores externos se requiere a la empresa que provea determinados elementos materiales (ubicacin fsica, mobiliario, mquinas, etc.). Tambin con referencia a una presentacin a realizar por consultores externos es comn incluir la metodologa del trabajo a aplicar y los antecedentes profesionales del equipo y/o cada uno de sus integrantes. A continuacin se muestra lo que podra ser un ndice tpico de una propuesta de servicios profesionales. 1. Carta de presentacin 2. Definicin del objetivo del proyecto. Tareas realizadas durante el estudio preliminar. Conclusiones previas obtenidas. 3. Metodologa a aplicar. 4. Plan de trabajo, programas. Diagrama de barras. Diagrama de flechas. 5. Equipo de trabajo. Propio: Recursos humanos por niveles Tiempo de afectacin por reas o tareas. De la empresa: Recursos humanos a aportar Recursos materiales. 6. Informe a presentar. Tipo y periodicidad. 7. Precio. Detallado o global. Condiciones de pago. Garantas. Mantenimiento de oferta. 8. Antecedentes del equipo de trabajo. Curriculum Vitae de los integrantes. Trabajos realizados con particular en tareas similares.

Cuando la intervencin del hombre de sistemas se produce con motivo de la posibilidad de incorporar un medio de procesamiento de datos, es comn realizar en esta fase un estudio de prefactibilidad tcnica y econmica. En efecto, antes de comenzar a recorrer el largo camino de las fases siguientes es conveniente tener una adecuada aproximacin acerca de la factibilidad tcnica y econmica del proyecto que se desea encarar. Llamamos de prefactibilidad, pues a esta altura del proceso se cuenta an con muy poca informacin. En general se intenta recoger los volmenes, frecuencia y oportunidad de entrada y salida para encasillarlos aproximadamente dentro de una variedad limitada de procesamiento. De esta manera, an con una idea slo aproximada de su viabilidad tcnica y relacin costo/beneficio, se puede tomar como decisin acerca de la conveniencia o no de seguir adelante con el proyecto.

4. RELEVAMIENTO DETALLADO

1. Objetivo El propsito de esta fase es el obtener informacin acerca de la situacin actual. Obviamente la situacin actual abarca numerosos aspectos, razn por la cual debe definirse el alcance de la recoleccin en funcin del objetivo que se ha fijado al proyecto. Si e proyecto consiste en el diseo de un sistema de costos es necesario un relevamiento detallado y profundo de los procedimientos de fabricacin, sin embargo, si se trata de analizar y redisear el sistema de facturacin es probable que slo requiera un conocimiento general y breve del proceso productivo. Tal como lo expresramos anteriormente la descripcin que hacemos corresponde al caso de un estudio integral de una organizacin con el objeto de optimizar un sistema de informacin administrativo.

2. Desarrollo y herramientas Intentaremos en primer lugar tomar conocimiento en forma detallada de la estructura actual de la Empresa, para lo cual no nos conformaremos simplemente con el organigrama que nos pueda presentar la empresa (si es que lo tiene) sino que nuestra intencin debe ser la de detectar la verdadera estructura, es decir la formal modificada por la informal. La construccin del organigrama real se realiza a partir de las entrevistas o cuestionarios. Se los interroga acerca de las personas que se encuentran por encima, por debajo o a igual nivel. Tambin se suele pedir una descripcin de su percepcin acerca del resto de la estructura. Como es obvio puede resultar que debamos construir ms de un organigrama de acuerdo con la informacin recibida. Estos diagramas sern un punto de partida para el mejor conocimiento de la organizacin y de los distintos problemas de estructura que le aquejan. Si bien hemos establecido como restricciones de este trabajo que no comprende el anlisis de la estructura, es indispensable tomar conocimiento de la misma pues seala el marco general dentro del cual se desenvuelven en forma interrelacionada, los distintos circuitos administrativos. Las entrevistas o cuestionarios, en particular la primera, nos permitirn obtener un cuadro lo ms claro posible de los objetivos y polticas tanto generales como sectoriales, las funciones y tareas de cada uno de los sectores e integrantes de la organizacin, sus niveles de autoridad y responsabilidad y todos los aspectos de la organizacin y estructura que nos den pautas acerca del comportamiento administrativo de la misma. Es tambin importante relevar cuidadosamente las interrelaciones entre las distintas reas y funciones de la organizacin. Una vez que se cuenta con la informacin de tipo global iremos a la bsqueda de datos ms detallados acerca de los procedimientos y operaciones que tienen lugar en la organizacin. De esta forma relevaremos las operaciones en secuencia que corresponde a los procedimientos -a travs de tcnicas de diagramacin como los cursogramas- los formularios y otros portadores de informacin que circula, sus frecuencias y sus volmenes. Con respecto a las tareas, nos puede interesar el detalle que cada uno de los empleados seleccionados realiza, construyendo en base a ellas un cuadro de distribucin de trabajo. En el anlisis que luego se realizar de la eficiencia de los procedimientos influirn naturalmente las condiciones ambientales y fsicas en las cuales se desarrolla el trabajo administrativo. As pueden interesar el espacio disponible, la disposicin de los muebles y mquinas, la iluminacin, ventilacin (los aspectos especficos de este punto corresponden al desarrollo de la tcnica denomina: disposicin de oficinas). En resumen podemos sealar que la informacin a recoger incluye los siguientes tems: Objetivo de la dependencia. Estructura de la dependencia. Funciones de la dependencia. Autoridad y responsabilidad. Procedimientos y formularios. Volumen de trabajo, frecuencia. Distribucin del trabajo. Relaciones con otras dependencias. Condiciones de trabajo (luz, ventilacin). Usuarios del servicio. Un problema que debemos resolver en el proceso de relevamiento es la forma en que encaramos la recoleccin de los datos necesarios. Como primera aproximacin diremos que es obvia la imposibilidad fsica de atacar todo simultneamente y es por ello que debemos adoptar un criterio de divisin de subsistemas. Los criterios de divisin son tradicionalmente dos: A. Factorizacin en rea funcionales (departamentos, divisiones, funciones) con lo cual el relevamiento sigue bsicamente las lneas del organigrama. Tiene como principal ventaja la sencillez en la discriminacin de los sectores y permite recoger el conjunto de informacin que interesa a un rea de la organizacin. Como principal desventaja es los acontecimientos que debemos realizar en el relevamiento de los procedimientos y las interrelaciones entre reas. B. Factorizacin por procedimientos. En este caso el relevamiento adquiere caractersticas de horizontalidad pues se parte de un momento que puede definirse como originador y se lo sigue a travs de toda la organizacin hasta que pueda darse por finalizado. Por ejemplo sera el caso de tomar como momento de origen, una nota de pedido de un cliente, que es seguida a travs del proceso de verificacin de crdito, verificacin de existencia, despacho, facturacin registracin contable y finalmente su cobranza. Sin embargo debe observarse que no siempre es fcil decidir donde comienza y termina un determinado procedimiento, siendo en general estas definiciones arbitrarias. Las ventajas y desventajas de este mtodo son las recprocas del mencionado en el caso anterior. En general predomina el primer criterio aunque debe quedar en claro que ambos no soy excluyentes, se trata en realidad de un problema de nfasis. Un aspecto sumamente importante en esta etapa es el volumen o cantidad de informacin a recoger. Una respuesta aparentemente sencilla pareciera indicar que debe recogerse la mayor cantidad posible de datos y hechos acerca de la realidad de la empresa. Sin embargo esto no es cierto. En primer lugar toda tarea consume tiempo y recursos humanos y materiales. Cualquiera de ellas es considerablemente costosa como para no ejercer un control en el consumo. Por otra parte un exceso de informacin suele causar ms de las veces una mayor confusin, especialmente si la misma no ha sido ordenada y clasificada satisfactoriamente. Por ltimo quienes proporcionan los datos y hechos son en su mayor parte los integrantes de la organizacin, quienes pueden llegar a percibir la recoleccin de informacin en exceso produciendo en ellos una mala impresin de los analistas a la vez de sentirse molestos por tener que realizar un esfuerzo intil. La solucin no reside en recoger poca informacin es una primera oportunidad para ir completndola a medida que se manifiesta la necesidad. Nuevamente puede crear una imagen desfavorable de los analistas y adems consume tambin excesivo tiempo. Por ello y aunque no es fcil, ni puede llegarse a un alto grado de exactitud, es una exigencia bsica de un buen trabajo de relevamiento, el que est adecuadamente planificado, de forma tal que cada hombre de sistemas interviniente posea un programa, que sin ser inflexible, pueda coordinar adecuadamente su tarea. La calidad de la informacin plantea tambin algunos comentarios. En la actividad de relevamiento, muy especialmente, en la entrevista, es posible obtener informacin que puede se calificada de la ms variada forma. As tenemos hechos (datos objetivos verificados o verificables), opiniones (juicios acerca de personas o cosas), suposiciones (opiniones no fundadas), comentarios confidenciales, etc. Toda informacin suele ser til en nuestra tarea, an las suposiciones; sin embargo, debemos cuidarnos mucho al momento de usarlas y cmo pueden incidir en nuestro juicio definitivo. Como una regla bsica deber recordarse que la elaboracin final de nuestro informe slo se basar en situaciones objetivamente comprobables y vlidas respecto de las conclusiones.

MEDIOS DE RECOLECCIN DE INFORMACIN

Los medios de recoleccin son normalmente cuatro: Entrevistas. Cuestionarios. Observacin personal. Estudio de antecedentes y documentacin. Como puede observarse existe similitud con los medios utilizados en el estudio preliminar. En efecto se trata como en el caso anterior de recolectar informacin, aunque en este caso con mayor amplitud y detalle. Debe entenderse que los medios enunciados no soy excluyentes, sino que por el contrario son complementarios.

ENTREVISTAS Por entrevista entendemos la reunin, en general, de dos personas en la cual se mantiene una conversacin dirigida a satisfacer las necesidades de informacin del entrevistado. Si bien trataremos de explicar brevemente su utilizacin en esta fase, debe reconocerse que la entrevista es un instrumento de permanente uso a travs de todas las fases de la metodologa y por lo tanto merecera un tratamiento por separado e in extenso. Sin lugar a dudas en el medio de recoleccin por excelencia, la posibilidad del contacto personal con la lnea le da sensibles ventajas sobre cualquier otro mtodo. En general podemos clasificar las entrevistas en tres categoras: a) Iniciales. b) De recoleccin de datos. c) De seguimiento. Las iniciales ya han sido tratadas al estudiar la fase de estudio preliminar, las de recoleccin de datos las aplicamos en esta fase y las de seguimiento cubren entre otras las siguientes necesidades: I. Llenar vacos de informacin. II. Testear nuevas ideas. III. Testear conclusiones. IV. Testear propuestas. El entrevistador debe comprender que el entrevistado reacciona frente a l y el tema de la entrevista, por lo tanto debe preocuparse de los objetivos, actitudes, creencias y motivaciones de ste. La entrevista es de alguna manera un arte que requiere cualidades generalmente innatas, pero que como cualquier habilidad puede adquirirse con su ejercitacin y el transcurso del tiempo. Daremos algunas recomendaciones para lograr buenos resultados de una entrevista, sin que esto se interprete como una receta definitiva y que pueda adems sustituir las falencias personales en cuanto a habilidad del entrevistado. 1. Tener claro el objetivo de la entrevista y de los aspectos que deben relevarse. 2. Obtener datos acerca del entrevistado, previo a la reunin, o sea conocer, si fuera posible, aspectos de su tarea, personalidad, etc. 3. Concertar la entrevista con anticipacin. No slo ahorrar tiempo sino que es una actitud de respeto hacia el entrevistado, incluso suele ser conveniente adelantarle el tema de la reunin. 4. La entrevista debe ser lo ms privada posible y de corta duracin. 5. Obtener confianza del entrevistado. Motivarlo con temas interesantes. 6. Tener una gua de la entrevista y mantener el control de la misma. Si fuera necesario tomar notas, pero en forma abierta.

CUESTIONARIOS Los cuestionarios o tambin denominados encuestas remplazan, en principio, el contacto personal de la entrevista por medio de un listado de preguntas pre-impreso que debe ser contestado por el hombre de lnea. Decimos, en principio, pues luego de evaluar sus ventajas y limitaciones, se llega inexorablemente a concluir en la necesidad, de que aunque de forma mnima, debe existir contacto personal entre los hombres de sistema y los de lnea. Sus ventajas ms notorias son que permiten obtener informacin con menos tiempo y con menos inversin de horas del hombre de sistemas. Es el nico medio factible en caso de estar el sujeto informante a grandes distancias. Sus desventajas son, por otra parte, los serios problemas de interpretacin que suelen presentarse. An, cuando haya sido motivo de cuidadosa elaboracin, no est exento de ofrecer dificultades. El cuestionario puede transformarse en una labor desagradable para quien lo llena, si no ha mediado una adecuada explicacin de sus objetivos. Diremos por lo tanto que los cuestionarios pueden aplicarse, siempre y cuando se los utilice para recoger informacin cuyo propsito y forma de completar los mismos haya sido explicada por el hombre de sistemas a la lnea; estar dispuestos a contestar cualquier duda y cumplir con el retiro, lectura y comentario de las encuestas completadas.

OBSERVACIN PERSONAL Este mtodo de recoleccin es solamente aplicable para determinado tipo de informacin. Se trata de un examen realizado en el sitio de trabajo y mediante observacin del propio hombre de sistemas. Por ello es susceptible de estudiar con este mtodo, el flujo de clientes a un mostrador de venta, la forma de operar con mquinas y equipos, condiciones ambientales y de distribucin de oficinas, etc. El principal inconveniente que ofrece este mtodo al margen del enunciado en el primer prrafo, reside en las reacciones de la gente de lnea al ser observado por un tercero. Estas reacciones pueden resultar frente al hombre de sistemas.

ESTUDIOS DE ANTECEDENTES Y DOCUMENTACIN Se trata de un mtodo complementario y consiste en el relevamiento de informacin contenida en archivos, registros, balances, manuales, etc. Con este mtodo se recogen volmenes de actividad, tales como facturas emitidas por da o mes, cantidad de tems promedio por factura, distribucin de la facturacin en el mes, etc. Aunque no sea el lugar ms apropiado, queremos dejar dicho algo acerca de una de las tcnicas profusamente utilizadas en el relevamiento y el diseo detallados: el cursograma. En particular, referido a la fase que nos encontramos desarrollando, el cursograma nos permite recoger datos acerca de los procedimientos que se estn utilizando en la organizacin. Recordemos que el cursograma nos muestra en detalle la circulacin de los formularios a travs de las distintas estaciones de procesamiento y que la correcta utilizacin de su tcnica de diagramacin garantiza que no se omita ningn paso del circuito. Conjuntamente con la confeccin del cursograma se van solicitando los modelos de formularios y registros utilizados que servirn luego como papeles de trabajo del analista de sistemas. Los medios de recoleccin enunciados en particular la entrevista, son los que permiten elaborar los cursogramas. Aun siendo una importante herramienta, debemos hacer notar que no siempre se justifica utilizarla en esta fase, por ejemplo, cuando el objetivo del relevamiento es obtener informacin acerca de los modos de operacin para incorporar un nuevo medio de procesamiento.

RECOMENDACIONES PARA LA TAREA DE RELEVAMIENTO A continuacin exponemos una serie de recomendaciones que no son solamente vlidas en esta fase, sino que pueden ser tiles en algn otro momento del estudio de sistemas. Estas sugerencias son producto de experiencias prcticas antes que de un desarrollo cientfico, razn por la cual deben tomarse como recomendaciones generales y no como leyes absolutas en el comportamiento del hombre de sistemas. a) Localizar el origen de las prcticas existentes: con ello queremos expresar que debemos tomar conocimiento cierto de la persona y/o oportunidad que dieron origen a un determinado procedimiento, formulario, etc. No es extrao encontrar casos en los cuales no subsiste la persona y/o la circunstancia originante y sin embargo se sigue produciendo una informacin que en realidad nadie utiliza o ya no tiene valor. b) Obtener informacin de la fuente original. En otras palabras que la mayor parte de toda la informacin segn las circunstancias deba provenir o ser confirmada por la persona que directamente interviene en un procedimiento u operacin o bien a travs de la consulta directa con los elementos que intervienen en un determinado procedimiento (por ej. verificar visualmente un registro, calcular la frecuencia promedio y pico de la emisin de un formulario), pues es comn que la informacin obtenida a travs de los participantes indirectos sea, aun cuando medie buena fe, est parcial o totalmente errada. c) Obtener pruebas por s mismos: los empleados y funcionarios no siempre tienen una idea acerca de datos de movimiento como son los volmenes promedio y pico en la emisin o recepcin de un determinado soporte. Es por ello que debe realizarse una verificacin personal de los registros y archivos para confirmar o directamente obtener dichos datos. d) Respetar horarios y cargas de trabajo: El relevamiento exige una participacin activa de los miembros de la organizacin, quienes adems de prestar a los analistas la colaboracin requerida deben cumplir con sus obligaciones diarias. Es por ello que se recomienda que el analista planifique adecuadamente sus tareas de relevamiento de manera tal que no genere interferencias en el desempeo de las tareas que normalmente debe cumplir un empleado. Para ello debe tenerse fundamentalmente en cuenta las cargas peridicas de trabajo y concertar, las entrevistas en los momentos de menor volumen de tareas. Por ejemplo, no parece razonable interrumpir el trabajo de los empleados de sueldos y jornales a fin de mes cuando los mismos se encuentran abocados a finalizar la liquidacin de los mismos. De la misma manera puede contemplarse que las entrevistas al personal de Tesorera se realice por la tarde, si los mismos tienen a su cargo los pagos a proveedores por la maana. Por su parte tambin deben respetarse los horarios de salida como as tambin los que el personal dispone para su comida o merienda. e) Evitar el uso de trminos ambiguos. Al ser esta etapa una de las que se preocupa por obtener volmenes y frecuencias se presta considerablemente a obtener calificativos como mucho, poco, a menudo, rara vez, que no sern operativos para la tarea del analista en tanto que los mismos significan distintas cosas para cada uno de los intervinientes. Es por ello que debe procurarse la cuantificacin de los datos que se recojan. f) Registro de la informacin recogida: Cualquiera sea el mtodo empleado en la recoleccin de los datos el analista deber disponer los medios adecuados para registrar en forma inmediata, clara y recuperable. Para que ello sea posible deber prever con anticipacin un mtodo de clasificacin y archivo por un lado y utilizar una redaccin clara y breve que permita eventualmente a otra persona comprender estas anotaciones.

ORGANIZACIN DE LA INFORMACIN RECOGIDA Con el propsito de que la tarea de relevamiento sea eficiente, resulta importante definir con anticipacin el criterio de ordenamiento de la informacin recogida. No slo facilita la consulta del material en las bases de diagnstico y luego en las etapas de diseo e implementacin, sino que tambin constituir la documentacin del trabajo realizado por cualquier necesidad de justificacin del mismo que pudiera surgir. A continuacin mostramos un ejemplo, que insistimos que debe tomarse como punto de referencia y no con la mayor proposicin acerca del tema. Esta organizacin est basada en un listado de carpetas de acuerdo al siguiente ndice:

I. ESTRUCTURA CAPTULO 1: Generalidades Nombre de la organizacin. Direcciones. Organigramas. Estatutos y otras disposiciones. Autoridades: nombres, ubicacin, telfono, etc. CAPTULO 2: Dependencia Funcionario que requiri el servicio. Nombre, direccin, telfono. Cargo. Organigrama de su sector. Personas que dependen de l (nombre, direccin, cargo, etc.). Funciones del sector. CAPTULO 3: Dependencia dem Captulo 2

II. PROCEDIMIENTOS CAPTULO 1: Generalidades Listas de procedimientos. Normas generales sobre los procedimientos. CAPTULO 2: Procedimiento Finalidad del procedimiento. Unidades intervinientes. Diagramas del procedimiento. Volmenes. Mquinas y equipos. Listado de formularios. Registros. Archivos. CAPTULO 3: Procedimiento dem Captulo 2.

5. EVALUACIN Y DIAGNSTICO

1. Objetivo El propsito de esta etapa es el de formular las conclusiones acerca de la efectividad y eficiencia de los sistemas relevados. Como tal, se halla inevitablemente asociada a la etapa previa y puede decirse que as como el diagnstico no puede realizarse si previamente no ha mediado un relevamiento, ste no tiene ningn sentido o valor si no da lugar a la formulacin de un diagnstico. Debemos aclarar sin embargo que no existe en la realidad una divisin clara y tajante entre estas dos etapas y menos an que una se realiza cuando finaliza la otra. En rigor el diagnstico se va produciendo casi simultneamente a la recoleccin de los hechos, por ejemplo mientras recogemos datos a travs de una entrevista es posible que vayamos sacando conclusiones en forma inmediata a los comentarios de nuestro interlocutor. Sin embargo las conclusiones no pueden ser definitivas si no se cuenta con la totalidad o buena parte de la informacin, de manera tal que exista un momento, digamos cuando se ha completado el relevamiento en el cual ratificamos o rectificamos conclusiones previas y elaboramos un conjunto coherente de definiciones acerca del material relevado. El ncleo fundamental de esta etapa es el anlisis de la efectividad y eficiencia de los sistemas relevados. Recordemos la preminencia del primero sobre el segundo, aun cuando ste posiblemente demande mucho mayor tiempo que aqul.

2. Desarrollo y herramientas En esta etapa del anlisis, resulta de gran utilidad el uso de una lista de control compuesta por las conocidas preguntas siguientes:

QU? y POR QU? CUNDO? y POR QU? DNDE? y POR QU? QUIN? y POR QU? CMO? y POR QU?

Las respuestas a estas breves pero importantes preguntas, nos darn no solamente las bases para el anlisis de efectividad y eficiencia, sino que tambin dan una cabal idea al analista si ha realmente recogido todos los datos que necesita para tener un cuadro completo de la situacin actual. La respuesta a la primera pregunta QU? nos permite saber acerca de lo que se est realizando: El POR QU? nos dar la base para el anlisis de efectividad. El CUNDO? hace referencia a la oportunidad en que cierta accin tiene lugar y el POR QU? pretender indagar acerca de la existencia de oportunidades mejores para su realizacin. El DNDE? nos presenta el lugar de realizacin de cierta accin y el POR QU? nos llevar a investigar la posibilidad de un espacio ms adecuado. QUIN? nos relaciona la persona responsable de una determinada accin y el POR QU? nos impulsa a pensar si es realmente la persona adecuada, si no es preferible remplazarlo por otra persona de mayor o menor experiencia, nivel intelectual, etc. CMO? nos trae a colacin el mtodo y el POR QU? va a dar lugar a un anlisis de la posibilidad de ahorrar pesos, remplazar formularios, instalacin de equipos, etc. En general el uso de estas preguntas permiten darse cuenta si uno tiene toda la informacin relevante, o de tenerla, sta es lo suficientemente clara como para sentirse satisfecho con la informacin relevada. Como se ha expresado con anterioridad en esta etapa se formulan conclusiones que darn las bases para el diseo de un nuevo sistema. Estas conclusiones no slo estn en funcin de la informacin relevada, sino tambin en funcin de la experiencia, la comparacin con otras empresas con sistemas similares, los conocimientos adquiridos a travs de estudios, etc. La presentacin de las conclusiones ser motivo de la confeccin de un informe en donde quedarn impresos los aspectos principales de la etapa de anlisis. Antes de presentar un informe de diagnstico, deber sin embargo prestar atencin a una recomendacin importante: las conclusiones deben ser testeadas con el personal o parte de l (jefes por ejemplo), con el objeto de verificar la correccin de las conclusiones. Esto no implica de ninguna manera que los miembros de la organizacin estarn de acuerdo con nuestras conclusiones, ni que deber comentarse todo el informe, pues ste puede contener aspectos confidenciales, pero la experiencia muestra que la mayora de las conclusiones pueden dar lugar a comentarios y recibir crticas de los propios interesados. Al usarlos como abogados del diablo no slo verificamos nuestras conclusiones, sino tambin creamos una actitud favorable de parte del personal quien conoce en forma directa las conclusiones y no se crean falsas expectativas acerca del mismo. La etapa de anlisis culmina normalmente con la presentacin de un informe, acerca de las conclusiones del sistema estudiado. Como muchos de los temarios expuestos en este trabajo, la presentacin de informes se encuentra presente en cualquiera de las etapas de la metodologa, ya sea como informes preliminares, parciales, finales o de actividad. En razn del objetivo de este trabajo no haremos una descripcin de tallada de esta tcnica, sino que nos limitaremos a comentar algunos aspectos que deben tenerse en cuenta en esta fase. As se sugiere que el informe sea escrito, aunque puede ser completado con explicaciones orales y/o demostraciones. Es importante que en el mismo se refleje la colaboracin prestada por el personal de lnea y el aporte que a determinadas sugerencias por ellos hayan realizado. Nuestra preferencia por el informe escrito, aun considerando su alto costo de preparacin, est basada en las ventajas que implica dejar claramente documentado lo actuado y la opinin emitida. A ttulo de ejemplo exponemos un contenido de un informe de diagnstico.

Portada o cartula ndice Introduccin

Objetivo del proyecto Objetivo del informe Alcance y limitaciones. Antecedentes

Tareas realizadas Descripcin de la situacin actual Observaciones y conclusiones (diagnstico) Recomendaciones generales Apndice

Cursograma Formularios Volmenes

3. DISEO

1. INTRODUCCIN

La etapa de diseo se encuentra tambin dividida en sub-etapas. Ellas son: diseo global y diseo detallado. As como la etapa de anlisis se desarrollaba fundamentalmente en funcin del Presente aunque sin perder de vista el futuro, esta etapa se relaciona fundamentalmente con el futuro aunque como es obvio basndose en el presente. Es la etapa de las proyecciones, por lo que requiere una gran dosis de imaginacin y creatividad. Estas cualidades importantes en el hombre de sistemas no son necesariamente coincidentes con las requeridas para la etapa del anlisis, razn por la cual un buen analista puede ser un mediocre diseador y la afirmacin contraria tambin es vlida. Es asimismo, la etapa que requiere mayor dosis de inteligencia y capacidad. La divisin en las fases antes mencionadas reconoce la siguiente explicacin: una vez producido el diagnstico se debe desarrollar una o varias alternativas idneas que satisfagan los requerimientos del proyecto. Estas proyecciones se deben realizar poniendo nfasis en la determinacin de las salidas previstas del sistema, las entradas requeridas, la especificacin de los archivos , y la definicin general del proceso, incluyendo el probable medio de procesamiento: Estas alternativas ofrecern determinados beneficios, que deben ser necesariamente contrapuestos con sus respectivos costos. Recin cuando la relacin econmica justifique la alternativa elegida tendr sentido comenzar con un diseo detallado. sta demandar normalmente mucho ms tiempo que la sub-etapa anterior y debe realizarse dentro del marco fijado por sta.

2. DISEO GLOBAL

1. Objetivo El propsito de esta fase es desarrollar propuestas alternativas que satisfagan los requerimientos de la organizacin. Requiere, por lo tanto, la inexcusable participacin del responsable del proyecto, pues es uno de los momentos claves de toda la actividad de sistemas.

2. Desarrollo y herramientas Veamos cules son los elementos o actividades fundamentales del diseo global: a) Definir los objetivos del sistema: Recordemos que los objetivos del sistema ya han sido definidos con anterioridad, sin embargo, es fundamental que a esta altura sean nuevamente evaluados y como consecuencia de ello ratificados, o parcial o totalmente modificados. Son requisitos fundamentales de esta definicin que se realice con absoluta claridad y por escrito. Si es posible, deber ser expresado en trminos de qu es, lo que la direccin har con la informacin generada por el sistema proyectado. No debe perderse nunca de vista el concepto y enfoque de sistema y tener por lo tanto en cuenta la interrelacin del contenido y objetivos del proyecto con el resto de las actividades y objetivos organizacionales. Debe recordarse asimismo la importancia de tomar en consideracin los futuros cambios previstos en la organizacin tales como nuevos productos, canales de venta, variaciones en volmenes de la produccin, nuevos clientes o proveedores, cambios en la poltica gubernamental, etc. b) Establecer las restricciones del sistema: Como ocurre en la descripcin de cualquier proceso decisorio no es posible ni tiene sentido generar infinitas alternativas, es por ello importante definir el marco decisorio, es decir fijar los lmites o restricciones dentro de los cuales se generan una reducida cantidad de alternativas; muchas veces una sola. Podemos establecer dos grandes categoras arbitrarias de restricciones: las internas y las externas. Entre las primeras nos encontramos las generadas por las polticas de cada una de las actividades de la organizacin. Tambin es una restriccin interna la implementada por la cantidad y calidad de los recursos humanos disponibles. La direccin de la organizacin es tambin un factor como as tambin el grado de capacitacin a los cambios que manifiesta su personal. Debemos dejar en claro, que las restricciones enunciadas no deben asumirse como lmites imposibles de trasgredir, pues existe un grado determinado de flexibilidad que deber analizarse como parte de esta fase de diseo global. Entre las restricciones externas podamos mencionar las generadas por determinadas exigencias a cumplir con clientes y proveedores, por voluntad o conveniencia de los mismos por disposiciones legales. Las disposiciones emanadas por los organismos oficiales (impositivas, laborales, comerciales, etc.) generan tambin restricciones que es debido asumir en el diseo de los sistemas de informacin. c) Determinar las necesidades de informacin: Una vez establecidos los objetivos y las restricciones dentro del cual se enmarca el diseo del sistema, estamos en condiciones de definir lo que en la jerga tcnica se denomina Salidas. Tratndose de un sistema de informacin se entiende que dichas salidas servirn a un propsito bsico que es el de proporcionar al usuario los medios necesarios para tomar decisiones. Al respecto consideramos que el cumplimiento de cierta exigencia legal (p. e. la ficha individual rubricada en la liquidacin de sueldos y jornales) constituye a nuestro juicio una de las restricciones externas y no una necesidad de informacin. Ahora bien quin determina qu decisiones deben tomarse y qu informacin necesita como alimentacin? Podramos, en principio determinar tres posibilidades: el usuario, el hombre de sistemas y ambos. Non inclinamos decididamente por esta ltima alternativa. Cuando el hombre de sistemas determina por su parte las salidas y sus caractersticas sin participacin del usuario, es muy probable que dicha informacin no sea utilizada o bien deformada en sus intenciones. Si el usuario determina unilateralmente sus necesidades puede hacerlo correctamente o bien hacerlo sin el mnimo criterio. Por ello, sin descartar que el usuario determine por s solo las necesidades nos inclinamos por la definicin conjunta del hombre de sistemas y el usuario, acerca de las salidas que debern obtenerse a travs del sistema a disear. La descripcin de las salidas propuestas debe realizarse a un nivel que sea claro para el usuario y valorar los beneficios que la misma puede ofrecerle. No corresponde a esta sub-etapa elaborar un proyecto detallado y realizar diseos grficos definitivos, pues ello corresponde a la prxima fase.

d) Determinar las fuentes de informacin: Como en cualquier sistema la obtencin de salidas (producto final) requiere definir cules sern los elementos de entrada (materia prima), que son requeridos en su preparacin. En este aspecto existen dos alternativas que son las siguientes: La primera consiste en determinar las entradas a partir de los conocimientos adquiridos durante la etapa de relevamiento. El segundo, conocido como el fresh approach por los americanos reside en idear las necesidades de entrada ignorando el sistema actual en razn de que si as se procede, se copian las eventuales fallas que el sistema actual presenta y se pierde objetividad. Este ltimo enfoque no deja de tener razn en cuanto a la prdida de objetividad y tendencia a copiar el viejo sistema, pero parece demasiado arriesgado en cuanto a que exigen un esfuerzo mucho mayor y se puede incurrir en omisiones importantes. A nuestro juicio las ventajas de ambos enfoques pueden conjugarse en un equipo de hombres de sistemas, en los cuales uno o alguno que no han participado en el relevamiento detallado ponen a prueba su propuesta con aquel o aquellos que participaron activamente en el relevamiento detallado. e) Determinacin del proceso y los medios de procesamiento: Es obvio que una vez que tenemos la salida (producto final) y las entradas (materias primas), debemos definir los procedimientos por los cuales stos ltimos se transformen en lo primero. El procedimiento puede ser muy sencillo tal como agregar ciertos datos de entradas y producir una informacin de salida para lo cual se requiere un breve ejercicio de clculo o quizs una sencilla mquina de calcular. En otros casos el procedimiento es largo y complejo y requiere la utilizacin de los medios de procesamiento ms sofisticados disponibles. Cules son entonces los elementos que permitirn definir las caractersticas del proceso? Fundamentalmente el volumen de los datos de entrada, su frecuencia, velocidad con que deben obtenerse los resultados y complejidad del proceso de transformacin. Es en este momento donde es ms probable la aparicin de ms de una alternativa, las cuales como es natural, van a ofrecer distintos costos y beneficios esperados. Paralelamente al diseo del proceso se requiere definir: f) Especificacin de los archivos: entre los datos que deben ingresar al procesamiento, existen aquellos que son repetitivos y por lo tanto se ahorrara costo y tiempo si los mismos estuvieran almacenados convenientemente en medios de acceso tales que permitiera su utilizacin cuando fuera necesario. De la misma manera se justifica conservar informacin producida por el proceso, ya sea que sirva como elemento de entrada para el proceso siguiente o bien para recuperarlos en otro momento ms conveniente a los efectos de su utilizacin. Para ello debemos definir el tipo y cantidad de archivos necesarios y la informacin que en ellos estar contenida. En un primer momento, lo que en realidad se define es el contenido de los archivos, luego, cuando se haya definido el medio de procesamiento se podr en realidad definir el tipo de archivo. Los elementos que habrn de ser considerados en su oportunidad son entre otros: capacidad de almacenamiento, velocidad y modalidad de accin y costo.

g) Justificacin del proyecto: Una vez satisfechos los pasos anteriores es necesario evaluar la factibilidad tcnica y econmica del diseo realizado. La factibilidad tcnica implica demostrar que el sistema realmente satisface los objetivos propuestos. No slo implica la evaluacin de las salidas sino tambin de las entradas, los archivos y el proceso. Esta prueba de factibilidad no consiste siempre en una comprobacin fsica por tratarse de un diseo global: debe recurrir entonces, a los conocimientos y experiencia de los hombres de sistemas. Una vez resuelta la factibilidad tcnica corresponde evaluar la factibilidad econmica que implica determina cul es la relacin costo-beneficio del proyecto. Al respecto pueden utilizarse cualquiera de las tcnicas difundidas de evaluacin de proyectos. Para los proyectos de sistemas es relativamente fcil determinar los costos en que se habr de incurrir. En cambio los beneficios estimados son muy difciles de determinar en trminos monetarios. Para ello se recurre alternativamente a evaluar la diferencia de costos con relacin al sistema que se remplaza y/o la valoracin subjetiva que el usuario le le adjudica a la informacin que generar el nuevo sistema. Para ello tomar en cuenta entre otras cosas la velocidad de obtencin de la informacin, la seguridad o el valor de la informacin adicional. En este momento se producir la ratificacin o rectificacin de los estudios de prefactibilidad que pudieran haber sido encarados durante la fase del planeamiento del proyecto.

3. DISEO DETALLADO

Esta fase comienza una vez que el diseo general ha sido aprobado. Comprende el desarrollo de los distintos elementos que comprende el sistema diseado a nivel global. En general el tiempo insumido en esta fase es mayor que el dedicado a la fase anterior. En particular en el diseo de un sistema con utilizacin de medios de procesamiento electrnico de datos, el tiempo demandado es significativamente mayor. En estos casos la fase suele denominarse especificacin. En el diseo detallado, se hace uso intenso de las distintas herramientas del estudio de temas tales como: Cursogramas Redaccin de normas y manuales Diseo de formularios y registros Diagrama de lgica Diseo de organigramas As como en la fase de diseo general, la participacin de la lnea es grande, no ocurre lo mismo durante esta fase en la cual la actividad se desarrollar por los hombres de sistemas, incluyendo la participacin externa de auxiliares, tales como dibujantes y dactilgrafos. Veamos cules son tareas propias del diseo detallado cuando se trata de un sistema cuyo medio de procesamiento es estrictamente manual, y cuando se trata de equipo PED.

Cursograma del circuito de los documentos Diseo de los formularios y registros Instrucciones para el llenado de los formularios y registros Especificacin de tareas de cada puesto de trabajo Redaccin del manual de procedimiento.

Y en el caso particular del PED se agregar:

Preparacin de flujograma para computadora Diseo de salidas Diseo de archivos Diseo de entradas Especificacin de los programas Diseo de los diagramas en bloque y de lgica Programacin Prueba en programas

Hay tareas que son difciles de ubicar entre el diseo detallado y el planeamiento de la implementacin. Ellos son: la preparacin de los manuales y la realizacin de las pruebas operativas. A nuestro juicio pertenecen conceptualmente al diseo detallado, aunque temporalmente se realicen paralelamente a las tareas de planeamiento de la implementacin. La tarea de disear los manuales comprende la descripcin por escrito de los procedimientos y normas especficas de operacin y la descripcin de funciones y tareas de las distintas personas involucradas en el sistema diseado. La redaccin de manuales requiere habilidad y experiencia para que los mismos satisfagan su creacin. Entre las recomendaciones bsicas estn la de ser lectura sencilla tanto en lo que se refiere a su redaccin (sintaxis y terminologa) como en su diagramacin fsica. Tambin es importante prever la posibilidad de su actualizacin permanente. La prueba operativa tambin llamada prueba piloto tiene como propsito poner a prueba la efectividad del diseo. Para ello se requiere preparar datos de entrada reales o simulados que habrn de ser procesados con el nuevo sistema. Los resultados previstos debern ser preparados de antemano y por otro procedimiento a los efectos de que pueda ser comparado con lo obtenido en la prueba operativa. Es de fundamental importancia que los elementos para la prueba operativa sean preparados por los usuarios con amplia participacin de stos y que tambin participen en el control de la prueba. Esta necesidad est fundada en dos motivos: 1) El diseador del sistema tiende a preparar la prueba de acuerdo con los mismos elementos que se utilizaron para el diseo, y ello puede concluir en una falsa apreciacin de los resultados de la prueba. 2) Es importante la amplia participacin del usuario para integrarlo al trabajo de sistemas y lograr una mejor comprensin del sistema por parte de los mismos. En algunos casos una buena prueba operativa puede ahorrarnos luego, el trabajo en paralelo.

4. IMPLEMENTACIN

1. INTRODUCCIN

La etapa de implementacin la dividimos en tres sub-etapas:

Planeamiento de la implementacin Implementacin propiamente dicha o puesta en marcha Seguimiento

Tal como se dijera en el punto 1.3.2. la importancia de esta etapa est dada por la probable inutilidad de las etapas anteriores si finalmente todo un diseo detallado no es implantado, que en definitiva es la nica medida real de su valor. El planeamiento de la implementacin se refiere a todas las tareas previas al momento de la puesta en marcha. Luego corresponde realizar una verificacin de que la implementacin se comporte de acuerdo a lo prescripto en el diseo detallado.

2. PLANEAMIENTO DE LA IMPLEMENTACIN

1. Objetivo Tal como lo indica su nombre el propsito de esta etapa es realizar un plan, en este caso, tendiente a coordinar los distintos recursos (materiales, humanos y tiempo) para lograr poner en marcha el proyecto. Como en toda tarea de planeamiento es posible y conveniente utilizar las tcnicas de programacin por camino crtico o ms sencillas del tipo de los grficos de GANTT.

2. Desarrollo y herramientas Con respecto a los recursos humanos se habr de determinar la cantidad y calidad necesaria. Normalmente se requiere capacitar a los participantes y usuarios del nuevo sistema aun cuando el grado de complejidad del nuevo sistema sea mnimo. La capacitacin adquiere gran importancia dado que es uno de los medios ms idneos para vencer la resistencia al cambio. Es necesario comprender que por ms sencillos que sean los cambios stos interfieren con los conocimientos y hbitos ya adquiridos. La capacitacin se debe realizar en todos los niveles. Es fundamental sin embargo, hacerlo en forma independiente pues por un lado las explicaciones requeridas para cada nivel tienen distinto grado de detalle y perspectiva y por otro lado no es prudente que se plantee la competencia entre jefes y subordinados. La capacitacin debera realizarse tomando como base los manuales elaborados en la fase de diseo detallado, lo que a la vez de ensear a los usuarios la utilizacin de los mismos permite comprobar su grado de comprensin. Forma parte de esta fase la elaboracin de las instrucciones de implantacin. A diferencia de las preparadas durante el diseo detallado, que se supone sern vlidas como elemento de referencia permanente mientras subsista el sistema implementado, estas instrucciones son de utilizacin exclusiva para lograr la puesta en marcha. Como ejemplo de las mismas podemos mencionar las instrucciones para la apertura de nuevos archivos, carga inicial de mquina, controles de inicio, etc. Junto con las instrucciones deber elaborarse el calendario de implementacin y la determinacin de los responsables de cada uno de los momentos y actividades comprendidas. En relacin con los recursos materiales esta fase prev las gestiones conducentes a que los distintos componentes fsicos del nuevo sistema estn disponibles para la fecha de puesta en marcha. Comprende por lo tanto tareas de impresin de formularios y registros, la compra de ficheros, el seguimiento de entrega de los equipos de procesamiento adquiridos, la preparacin de locales o instalaciones correspondientes, etc. Una importante actividad de esta fase lo constituye la fijacin de los puntos de control que se utilizarn durante el seguimiento que nos permitan asegurar que el sistema puesto en marcha funciona satisfactoriamente o bien que permita detectar fallas u omisiones del diseo. No slo deber determinar los mecanismos de control, sino tambin los responsables, la frecuencia y los criterios para evaluar los resultados. Tambin forma parte de esta fase la conversin de los archivos. Si el nuevo sistema utiliza un soporte fsico distinto o su contenido vara, deben prepararse los nuevos archivos tanto en su aspecto fsico como en su conjunto lgico. Es ms comn encontrarnos con el primer caso o con la combinacin de ambos antes que la segunda de las situaciones. En todas las oportunidades se requiere transferir saldos, es posible que la conversin se realice en el momento de la puesta en marcha. A veces es posible anticipar parte de la tarea como ser el encabezamiento de las fichas en un sistema manual o de registro directo dejando para ltimo momento la transferencia de los saldos. La tarea de conversin suele demandar una inversin considerable de horas hombre y es comn requerir personal temporario o de la misma organizacin que no est suficientemente compenetrado con la tarea a realizar. Estn encargados de una tarea de transcripcin y por lo enunciado en el prrafo anterior, esta tarea est sujeta a un porcentaje significativo de errores, razn por la cual deber preverse la forma de verificar la correccin de la tarea realizada. Por ello se recurre normalmente a crear lotes de correccin que permitan localizar con mayor facilidad cualquier error que se pudiera cometer.

3. PUESTA EN MARCHA

1. Objetivo La puesta en marcha es el momento clave en el cual el sistema comienza operar. Es en este momento que la importancia activa o pasiva de la gente de lnea puede marcarse con mayor fuerza. Del grado en que esta situacin se presente resultar cmo se instrumente esta fase. Esta fase se debe complementar con las anteriores.

2. Desarrollo Si queremos explicar las tareas incluidas en esta fase, quizs no podramos decir nada ms, que consiste en poner en funcionamiento el sistema diseado. Sin embargo hay algunos puntos que son importantes considerar, como los que siguen:

Ejecucin del punto de corte: se refiere al momento en el cual comenzarn a operar los cambios. Se recomienda en general tener en cuenta las cargas de tareas, los cortes con tablas y cualquier otro acontecimiento que no favorecera el proceso de cambio. En general, siempre que sea posible, deber elegirse un perodo de baja actividad, As es, como un nuevo plan de cuenta se suele introducir al comienzo de un nuevo ejercicio, se modifican circuitos de venta cuando se est en baja temporada, etc. Como ya fue planteado en la fase anterior en muchos casos el punto de corte es el momento en el cual deben convertirse los archivos a los nuevos soportes, pues no fue posible hacerlo con anterioridad, y por lo tanto se origina una gran sobrecarga de tareas y/o deben trabajarse das feriados o bien suspender la actividad normal por algunos das.

Trabajo en paralelo: Se entiende por paralelo el funcionamiento simultneo del viejo y nuevo sistema. Esta situacin no siempre es posible, ya sea por imposibilidad fsica de que as ocurra o bien por razones econmicas. En otras ocasiones resulta una exigencia lgica, pues ante el posible fracaso del nuevo sistema los riesgos inherentes al abandonar el anterior son muy graves. Un caso tpico de lo que acabamos de mencionar resulta de la conversin de un sistema manual de liquidacin de sueldos y jornales a uno procesado por computador. En estos casos se suele mantener el paralelo hasta que el nuevo sistema no ofrezca duda alguna o que supla al menos la informacin proporcionada por el anterior en cuanto a calidad, cantidad y oportunidad. La tarea en paralelo es costosa y la ms de las veces incmoda por los inconvenientes que ofrece. En muchos casos la tarea en paralelo podra evitarse si se realizara una buena prueba operativa o varias de ellas.

Implantacin total o gradual: Al margen de la discusin acerca de la conveniencia de uno u otro mtodo, lo cierto es que no siempre es posible implantar en forma simultnea los distintos sistemas diseados, o las varias partes de un mismo sistema. Razones de capacitacin, adaptacin, tiempo, etc. fundamentan esta afirmacin. En este caso, debe asegurarse: 1) que cada parte que se implemente ofrezca la mayor coordinacin posible con lo que ya hubiera sido implementado y con lo que an est a la espera; 2) que se implemente todo. Esto ltimo requiere un claro plan de actividades y la fuerte conviccin de que debe llegarse hasta el final.

4. SEGUIMIENTO

1. Objetivo El propsito de esta fase es asegurarse que el sistema diseado se implemente de acuerdo a lo planificado, corrigiendo si fuera necesario las fallas que se vayan detectando. Es la fase de la consolidacin del sistema.

2. Desarrollo y Herramientas Esta fase comienza en el mismo momento que la fase anterior. Se procura ir verificando los resultados del nuevo sistema prestando especial nfasis a los controles planificados durante la fase de planeamiento de la implementacin. Se recurre a la observacin directa, como as tambin a las entrevistas personales para requerir la opinin del usuario acerca de los problemas que pudieran haber surgido. El hombre de sistemas se ve obligado a solucionar numerosas situaciones originadas en problemas de interpretacin, de adaptacin, comprensin y de resistencia a aceptar el cambio de alguno de los integrantes de la organizacin. Se advierte en esta etapa los problemas que han generado un mal relevamiento o errneo diseo, como as tambin, la aparicin de nuevos hechos que requieran algn tipo de solucin. Esta fase podemos decir que concluye, cuando queda demostrado fehacientemente que el sistema diseado funciona, an con los cambios que se le puede hacer incorporado. En base al grado de comprensin obtenido de los manuales y de los ajustes que tuvieron lugar, esta fase genera la necesidad de corregir y mejorarlos donde fuera necesario. En ciertos casos, recin en este momento, se coordinan las diversas normase instrucciones generadas antes de la puesta en marcha, para conformar el verdadero manual.