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 conocimient
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.