Metodo TQSD/1 1993

CALIDAD TOTAL EN EL
DESARROLLO SISTÉMICO DE
LA ORGANIZACIÓN
TQSD/1(R)
( Total Quality Systemic Development / 1 )
"Una metodología para el Cambio sostenido”
GUSTAVO E. GIORGETTI
Dirección Nacional del Derecho de Autor
Certificado Nro. 54853 Exp 332288, 1993

2
INDICE
INDICE 2
Calidad Total en el Desarrollo de Sistemas 4
Introducción 4
El enfoque integral 4
Una visión del resultado 9
La forma de avanzar 12
Una visión del sueño informático 14
Los problemas 16
La falta de sentido común 16
La Escala 16
El Cambio 17
Las mil Opciones 18
El Sincronismo 19
La Clasificación 19
La resistencia al cambio 20
Las zonas grises 20
Entre áreas de la empresa 20
Entre informáticos y usuario 20
Resumen 21
TQSD/1 (Total Quality Systems Development /1) 22
Introducción 22
Concientizacion de la organización: 23
Definición de requerimientos: 23
Definición de las estructuras de información: 23
Diseño de transacciones: 23
Implementación 23
Puesta en marcha y operación 24
Resumen 25
Concientización de la Organización 26
Q (Total Quality) 26
La Calidad 26
Circuitos de procesos equilibrados y sincronizados 26
Intervención de los integrantes de la organización 27
Los costos de la No Calidad 27
Resumen 29
Definición de los requerimientos 30
Diagramas de entidad 31
Diagrama de entidad individual a nivel del usuario 31
Diagrama de entidad combinado 35
Diagrama de entidad a nivel de aplicación 39
Los Objetivos 40
Reingeniería de procesos 41
Diagrama de línea de Ensamblaje 42
Una forma de ver el avance 46
Diagrama de ciclos o frecuencias 49
Resumen 51
Definición de la estructura de Información 52
Introducción 52
LCS (Logical Construction of Systems) 53
Las Bases de Datos Lógicas 53
Resumen 57
Diseño de las transacciones 58
Matrizado de las etapas 58
Especificación de la transacción 58
El modelo Client-Server 60
La "estandarización" a medida 61

3
Servidor de Procesos Específicos 62
Servidor de Administración Preventiva de Procesos 62
La prevención 63
Las clases de prevención 63
Servidor de Base de Datos 64
Resumen 65
Implementación 66
Arquitectura Abierta 66
Puesta en marcha y operación 68
Los procesos reales 68
El método Drum Buffer Rope 69
Conclusiones: 72
Bibliografia 73

4
Calidad Total en el Desarrollo de Sistemas
Introducción
El objetivo de este libro es presentar una metodología para generar los
sistemas de información de una organización mediante un proceso de mejora
continua, cubriendo los aspectos centrales desde la etapa de especificación hasta la
de operación. Es el resultado de una larga búsqueda de más de diez años, de
principios y métodos, de tratar de rescatar lo mejor y esencial de cada uno e
integrarlos en una metodología coherente y de aplicación práctica.
Los aportes que más favorecieron la gestación de esta metodología son los trabajos realizados por
Jean Dominique Warnier, que luego fueron continuados por Ken Orr en el área de definición de
requerimientos. Ambos tuvieron la visión de atacar los problemas en forma distinta al común de los
informáticos, esto es, una estrategia orientada a los objetivos, comenzando el análisis por el final del proceso y
no por el principio.
Luego de innumerables pruebas y experiencias, con resultados más o menos aceptables, se notaba que
faltaba algo. Ese algo, esa intuición que nos guía en todo momento cuando tenemos que optar por distintos
caminos: el 'sentido común' que no sólo debe ser utilizado por los informáticos, sino que debe ser compartido
por todos los involucrados en un proyecto.
Aquí los principios de la Calidad Total brindaron una forma de avanzar hacia la formación de ese
'sentido común'. En este terreno "gurús" como Deming, Juran, Crosby, entre otros, fijaron el camino de la
mejora continua, de los procesos de la organización. Pero en esa búsqueda incesante hay problemas de distinta
complejidad que hacen surgir nuevas corrientes tratando de abordarlos, como 'La Organización inteligente'
con Peter Senge y Jay Forrester entre otros. Por otra parte la 'Teoría de las Restricciones' de Eliyahu Goldratt
permitió resolver el problema de cómo fijar racionalmente las prioridades de los procesos a atacar, terminando
con el dilema de lo urgente y lo importante.
La metodología aquí presentada se basa en el trabajo de todos estos grandes autores del campo de
sistemas, de la calidad total, del aprendizaje organizacional y de la teoría de la restricciones. Todos estos
aportes, adecuada y equilibradamente integrados dan por resultado una metodología para el desarrollo y
explotación de los sistemas de información de una organización.
El enfoque integral
La realidad que nos toca vivir tiene un alto grado de complejidad; ésta se presenta como una
interminable interacción de todo con todo.
Para asegurar nuestra permanencia como organización o como individuos, es necesario, no sólo la
adaptación con el medio, sino la colaboración consistente con él. Esto produce un constante estado de cambio,
que mientras se encuentre bajo control, permitirá la permanencia. De lo contrario se producirá el caos y, por
ende, la destrucción.
Nadie puede sobrevivir a la destrucción de su entorno
Podemos así dar una definición aproximada de nuestra meta, como sigue:
La meta:
Permanecer, armónicamente, en un medio de complejidad creciente.1
Descubriendo qué cambiar.
Creando a qué cambiar.
Produciendo los cambios.2
Quizás una buena definición de lo que es el 'sentido común' sea la intuición aplicada a esta meta: la intuición
que nos permite permanecer.
1 Basado en metodología CTCID, Roberto Campitelli
2 Basado en 'La Meta' Eliyahu M. Goldratt

5
Hoy nuestras vidas y la de las organizaciones forman un enorme y complejo proceso de cambio que,
como toda cadena de eventos, tiene al menos un eslabón débil o restricción del sistema.
Por otra parte los constantes rebotes de las incontables relaciones causa- efecto, golpean
aleatoriamente nuestro proceso.- Estos ataques no distinguen entre puntos fuertes y débiles, pero cuando
golpean sobre las restricciones de nuestro proceso, los sentimos y decimos que se ha cumplido una vez más la
famosa ley de Murphy.- Estos hechos son los que nos pueden hacer perder el control de la complejidad, dando
entonces origen al caos,('el hilo se corta por lo más delgado).
Se imagina qué pasaría en un sistema que pudiera alcanzar el óptimo? Todos los eslabones estarían
dando su máxima capacidad.- En principio esto es imposible porque si se pudiera, al acercarnos más y más a
este óptimo empezarían a aparecer eslabones débiles en forma interactiva que cambiarían de lugar por el solo
hecho de recibir los impactos aleatorios de la realidad.- Un proceso así sería terriblemente vulnerable ya que
cualquier golpe, en cualquier parte, produciría estragos.- Quizás sea este el mejor ejemplo de un sistema
inestable que, por ser tal, no tiene posibilidad de permanencia. Podemos decir que este tipo de óptimo, el que
solo busca maximizar el uso de los recursos, está separado del caos por una delgada línea.
El óptimo al que tendemos es otro: "es la tendencia que logra ser calificada desde el cliente, como el
cumplimiento confiable de los acuerdos establecidos, de acuerdo a sus requisitos y especificaciones, en el
tiempo y costo acordado y que logra a través de su eficacia demostrar la permanente disminución de la
variabilidad y el incremento de su estabilidad con respecto a los parámetros esperados"3.
Ese óptimo lo perseguimos mediante nuestros proceso que siempre tendrán algún punto débil o
restricción. Lo importante es poder identificar nuestras limitaciones, para cambiarlas si es posible o trabajar en
función de ellas, de manera que nuestro sistema avance en forma estable y controlada, minimizando el gasto de
energía. Por lo tanto conocer las restricciones, los puntos débiles de nuestro sistema (su talón de Aquiles), pasa
a ser un dato crítico de nuestro proceso de cambio. Resolver o levantar una restricción produce como resultado
un aumento de nuestra velocidad de avance hacia la meta, pero ¡cuidado!, ahora, a esta nueva velocidad, otro
eslabón pasará a ser el más débil y deberemos volver a comenzar. Lo importante a rescatar aquí es que el
proceso de mejora es continuo y las prioridades están dadas por el orden en que se presentan las
restricciones.
Se puede pensar que esto no es tan terminante y que las prioridades pueden ser otras. Esto puede ser
cierto a nivel local, pero no a nivel global de la organización. Aceptar las prioridades naturales, subyacentes a
los procesos, es la única forma de maximizar nuestro avance hacia la meta.- "No hay nada más improductivo,
que hacer productivamente algo innecesario"4.
Solo hay una forma de influenciar sobre la aparición de estas restricciones y el orden en que se
presentan y se llama 'prevención'. La prevención es un arma eficaz para asegurar nuestro avance hacia la
meta.
Es fundamental poder anticiparnos a los problemas, a la aparición de nuevas restricciones, actuando
preventivamente y no correctivamente (más vale prevenir que curar), Para resolver los ataques aleatorios no
podemos hacer otra cosa que proteger estratégicamente nuestros puntos débiles, que por suerte siempre son
pocos.
La prevención es una característica necesaria en sistemas complejos, pero para que ésta no sea
costosa, por la simple aplicación de márgenes de seguridad que sólo ocultan nuestra ignorancia sobre el tema,
debemos mejorar el conocimiento sobre las leyes subyacentes que gobiernan los procesos complejos.- En
definitiva: mejorar nuestros supuestos. Es así que el aprendizaje continuo pasa a ser una forma de vida.
Sabemos por los estudios sistémicos, que hay dos tipos de problemas: los convergentes y los divergentes.- Es un
problema divergente determinar el a que cambiar, es la parte creativa, el que de la cuestión, para seguir
siempre hacia la meta. En cambio, es un problema convergente el determinar el como producir un cambio, una
vez definido el mismo.- Decidir cual será el lugar para pasar las próximas vacaciones es un típico problema
divergente. Cuanto más consideraciones hacemos, más contradicciones se nos presentan, y aún a punto de
tomar una meditada decisión, el comentario de un amigo nos la hace cambiar de inmediato. Pero eso sí, una vez
decidido a dónde ir, el como llegar allí, es un problema convergente que tiene una solución eficaz. Por otra
parte los problemas divergentes tienen normalmente una complejidad dinámica donde la causa y el efecto no
están próximos en el espacio y el tiempo y las intervenciones obvias no producen los resultados esperados.
Mucho de nuestro aprendizaje se basa en la observación de la causa y el efecto, pero ¿qué ocurre cuando éstos
están distantes en espacio y tiempo? Sencillamente no aprendemos. Si alguien toca algo que quema, no lo
vuelve a tocar: aprendió. Pero supongamos que el dolor lo percibe una hora después, ¿cual de todas las cosas
3 CTCID - Roberto Campitelli
4 Basado en Peter Drucker

6
que se tocaron, quemó?. Conclusión: no aprendió, sólo sabe que se quemó. Muchos de las decisiones que toma
la dirección tienen problemas de retardo que nos impiden aprender. No podemos asociar los efectos con las
verdaderas causas.
Los problemas convergentes tienen una complejidad de detalle con muchas variables, algo muy difícil
de manejar conscientemente5.
No cabe duda que dada la naturaleza dinámica de los problemas divergentes, la simulación es el
camino más adecuado para determinar rumbos y objetivos, ya que podemos disminuir los retardos que nos
dificultan distinguir la relación causa-efecto. Debemos crear laboratorios de ensayo de toma de decisiones
dentro de la organización. En estos modelos de simulación se pueden poner a prueba nuestros supuestos, sin
tener que aplicarlos directamente en la realidad: otra forma de prevención.
¿Pero que hacer con los problemas de complejidad de detalle?. ¿Qué hacer cuando ya nos decidimos por un
objetivo?. ¿Cómo atacamos el problema de la implementación, sin quedar atrapados en el intento?.
Veamos como la mala resolución de los problemas convergentes retrasan el posible crecimiento de una
organización.
Dentro de la teoría de sistemas es famosa la curva 'S' de crecimiento6, que puede ser utilizada para
explicar, prácticamente, cualquier proceso evolutivo, desde el crecimiento de un campo de bacterias hasta el
avance de las tecnologías informáticas.
.
límite de crecimiento
tiempo
El proceso de cambio que representa esta curva 'S' se puede explicar, también, mediante la teoría de
dinámica de sistemas7, donde existe un lazo reforzador tipo 'bola de nieve' que es frenado por un lazo restrictivo
'equilibrador' gobernado por una condición limitativa (léase restricción, eslabón débil, etc.)
Uno de los frenos más comunes en el crecimiento de una organización es la escasa capacidad de
implementación de las decisiones tomadas. Aquí la condición limitativa es el mal manejo de la complejidad de
detalle involucrada en el proceso.
Capacidad de manejar
la complejidad de detalles
Avance de la Consolidación Puesta en marcha
Organización del aprendizaje de las decisiones
5 Basado en 'La Quinta Disciplina' Peter M. Senge
6 Del biologo Von Bertollanfy
7 Dinámica de Sistemas desarrollada por Jay W. Forrester

7
Al comenzar a comprender las leyes subyacentes de los procesos de la realidad, a través de un proceso
de continuo aprendizaje, mejorando nuestros supuestos, comenzamos a encontrarle el sentido a las cosas que
nos pasan y podemos utilizar eficazmente la energía aplicada para actuar sobre ella.
Analicemos por un momento el problema del aprendizaje: podemos asimilar a la organización con un
ser humano, con sus problemas de aprendizaje y crecimiento. En esta analogía la capacidad de manejar
complejidad de detalles del consciente es tan limitada para el ser humano como para la dirección de la
organización.
Los pasos del proceso de aprendizaje son los siguientes:
Estado inicial: donde somos incompetentes en una disciplina o tema y no tenemos siquiera consciencia de
nuestra incompetencia.
Primer escalón: cuando tomamos consciencia de nuestra incompetencia, sólo tenemos el conocimiento
de la existencia de dicha disciplina y una idea sobre ella.
Segundo escalón: poniendo gran esfuerzo y atención en los detalles logramos pasar al nivel en que somos
conscientemente competentes, comprendemos la disciplina y la comenzamos a aplicar con gran dedicación.
Tercer escalón: luego de mucha práctica sobreviene algo maravilloso, el estado de ser competentes desde el
subconsciente. Ya no es necesario aplicar tanta atención, ahora sí podemos decir que hemos aprendido.
Recordar los esfuerzos para aprender a andar en bicicleta, a manejar un automóvil o comenzar a practicar un
nuevo deporte.
E ta p a s d e l a p r e n d iz a je subconciente
competente
conciente
competente
conciente
incompetente
subconciente
incompetente
Durante el aprendizaje el ser humano va internalizando la complejidad de detalles en su subconsciente
(buen manejador de la complejidad de detalles), dejando la faz consciente libre para determinar el rumbo.
Ahora podemos disfrutar de nuestro paseo en bicicleta y elegir a donde vamos.
En la organización ocurre algo parecido. Luego de definir, lenta y penosamente la complejidad de
detalle de sus procesos, que implican cambios culturales profundos, éstos deben ser internalizados en su
'subconciente', sus sistemas informáticos, que pueden manejar muy bien la complejidad de detalles.
La metodología que aquí se presenta es justamente para facilitar el aprendizaje y formación del
subconciente de la organización, sus sistemas operativos, que darán soporte a sistemas de alerta preventiva,
que al igual que nuestro subconciente, en permanente conexión con el conciente, nos devuelve el control a nivel
conciente cuando algo se sale de los carriles normales, alertándonos ante los potenciales peligros y actuando
como un eficaz sistema preventivo.
Hoy, para soportar una empresa competitiva debemos construir un sistema integrado que sea capaz de
brindar los datos e información necesarios, precisos, oportunos, completos y mínimos, evitando redundancias y
duplicidad de procesos.
En muchos de los sistemas actuales, los datos son sobreabundantes. Permiten ver el árbol pero no el
bosque, produciéndose un "apagón" de información, precisamente por exceso de datos 8. Este punto está
directamente relacionado con lo que después veremos como los problemas de la clasificación.
La propuesta es, entonces, utilizar esta metodología para que a partir de sus objetivos la misma
organización pueda definir y aprender el cómo alcanzarlos, produciendo implementaciones robustas
(permanentes) y eficaces en su subconsciente, rompiendo el permanente dilema del directivo, de atender lo
8 'Las Nuevas Realidades' Peter Drucker

8
urgente o lo importante, dejando más tiempo libre a la dirección para seguir avanzando en la definición del
rumbo y no tener que resolver problemas operativos, una y otra vez en forma asistémica.
T e n d e n c ia a E x ito e n e l
to m ar d e c isio n e s Larg o p lazo
fu n d am e n tale s
T ie m p o e n
fijar ru m b o
T ie m p o e n
im p le m e n tar
T e n d e n c ia a E x ito e n e l
to m ar d e c isio n e s C o rto p lazo
sin to m atic as
La consciencia de la organización, (su capacidad de dirección) es un recurso limitado que debe estar
alerta a los cambios de la realidad.
Aquí hay que rescatar la idea de que es la propia organización la que aprende y conscientemente aplica 'el
como hacer las cosas', antes de que pase a su subconsciente. El traslado de sistemas de una organización a
otra genera soluciones sintomáticas pero no fundamentales, por la falta del proceso de aprendizaje que
conforma y transforma la cultura de la organización. Esto no implica que todos los sistemas deban ser a
medida, pero aún usando sistemas estandard, debemos saber qué necesitamos, qué es lo importante en ese tema
para nuestra organización. Por lo tanto, esta etapa de definición y aprendizaje no la podemos obviar.
Ahora si nos preguntamos ¿por qué es tan difícil hacer sistemas que realmente se integren a la
organización? Contestaremos que la complejidad de la realidad tiene tipos de problemas y grados de
complejidad que son erróneamente percibidos, erróneamente simplificados y subestimados y por lo tanto
débilmente atacados, siendo esta una de las principales causas del fracaso de los proyectos de informatización.
Si consideramos que es imprescindible este proceso de aprendizaje , dado el perfil del problema,
debemos buscar métodos y técnicas que permitan resolverlos eficazmente y sin desperdicio de esfuerzo y tiempo,
o sea, empleando la menor cantidad de energía posible.
Pero, como veremos, encontrar el como hacer las cosas eficazmente implica también vencer una serie de
problemas, como la falta de sentido común dentro de la organización; determinar la escala real de las cosas;
hacer sistemas robustos, o sea, capaces de soportar el cambio; decidir entre mil opciones de implementación
que hoy están disponibles; alcanzar un eficaz sincronismo en los procesos y definir esquemas de clasificación
de la información útiles para todos.
Podemos asegurar que sólo con un comportamiento participativo de todos los integrantes de la
organización, únicos poseedores de la experiencia e historia de la misma, se puede asegurar el éxito de un
proyecto integral. Y es aquí donde tallan las técnicas de calidad total que trabajan con el comportamiento
humano, apoyadas desde el campo de sistemas, por las técnicas de Orr, creador del único método de
relevamiento de los procesos lógicos, que hoy por hoy, es independiente de la capacidad del analista y por lo
tanto realmente sistemático. Los enfoques de Warnier, haciendo planteos de forma clara, completa y entendible
por todos, permitiendo así crear estructuras de información que soportan el cambio. Luego, a la hora de la
verdad, los procesos lógicos se combinarán dinámicamente formando el proceso físico con el cual tendrá la
dirección que operar la organización. Aquí Goldratt completa el cuadro con métodos que nos permiten romper
sistemáticamente el dilema de lo urgente y lo importante.
Obtendremos así sistemas de una nueva especie, que nos permitirán transformar mediante la mejora
continua, una organización tradicional en una organización basada en la información.

9
Una visión del resultado
En casi todos los trabajos sobre la problemática de la organización se plantea la visión globalizadora
e integral. Peter Drucker describe la organización basada en la información, haciendo una analogía entre la
dirección de la empresa y el director de una orquesta sinfónica, donde una sola persona es capaz de coordinar
a todos. Pero en una orquesta hay una diferencia: cada cual sabe lo que tiene que hacer. Existe una partitura
que permite manejar esa complejidad de detalle.
Veamos como esta metodología nos ayuda a generar 'la partitura' de la organización, que le permita a
la dirección cumplir con su verdadera misión: dirigir coordinadamente a la organización hacia la meta.
Imaginemos por un momento que creáramos el 'sistema organización', que no sería otra cosa que un
conjunto de procesos sincronizados, que permitan la ejecución de todas las transacciones necesarias para el
funcionamiento de la organización, donde cada uno esté perfectamente acotado y especificado; cada proceso
con sus correspondientes transacciones, parte manual y parte computarizada, con todas las implicancias que
las mismas tienen. Podríamos decir que ya no habría diferencia entre una transacción real y la informática,
porque serían la misma cosa, una no podría existir sin la otra.
Al nivel más alto, los componentes de nuestro sistema serán los procesos. Cada proceso soportará un
lazo cerrado de la organización y su entorno.- A menor nivel (dentro de los procesos), las transacciones que se
podrán colocar en el sistema, cambiar o sacar según las condiciones de la realidad y la dirección de la empresa
lo determinen. Cada transacción será un objeto en nuestro sistema.
Si cada transacción está perfectamente especificada no habría inconveniente alguno en que un
programador la implemente en un ambiente determinado, ajustándose a esos requisitos, que deben reflejar tan
sólo las necesidades de la realidad, definidas por el usuario.
Un programador, para hacer un trabajo de calidad, no necesitaría tener nada más que esto: una buena
especificación a la cual ajustarse.
Pero tanto el directivo de la organización, como el director de la orquesta, deben contar con la
documentación que especifique lo importante de los procesos para ellos:
- Las transacciones que ocurren. ¿Quién hace qué?
- Como se encadenan unas con otras. ¿Por qué lo hacen?
- Cuando ocurren o con que frecuencia. ¿Cuándo lo hacen?
O sea una visión precisa, compartida, pero al mismo tiempo, global, de la organización, sin entrar en
los detalles de cada transacción.
Para los 'ejecutantes' operativos dentro de la organización debemos tener la documentación que especifique el
detalle de las transacciones:
- La forma de ejecutar nuestras transacciones. ¿Cómo se hace?
Pensemos entonces que tenemos una serie de documentos y gráficos que representan, así, a la misma
organización, lo que nos da la partitura o sea los planos de la organización, necesariamente entendibles por
todos, donde la forma de ordenarlos es por los procesos de la organización y en cada proceso podríamos
acceder a las transacciones que lo forman, permitiéndonos conocer sus pasos elementales y todas las
implicancias que tiene su ejecución, desde la eminentemente operativa hasta la contable, de costos,
presupuestaria y financiera.
Sería posible discutir en reuniones cambios operativos sobre estos planos (los fuentes9 del 'sistema
organización'). Con bases firmes podríamos medir el impacto que cada cambio tendría sobre el resto de la
organización con bastante certeza , al observar todas sus implicancias.
Los cambios sólo afectarían a algunos procesos o transacciones y éstas, como antes mencionamos,
deberían ser actualizadas o reemplazadas. Pero lo importante es que el ciclo de vida de este gran sistema
integrado, que no es otra cosa que la organización misma, sería muy largo y sólo tendríamos cambios en puntos
perfectamente acotados.
Veamos ahora el aspecto preventivo. Una de las variables que intervienen en los problemas de
incumplimiento es el manejo de los tiempos, para evitar la incoordinación y por lo tanto, esperas y costos por
incumplimiento. De las técnicas como el Just In Time hemos aprendido que la prevención es bastante sutil y el
9 Estos 'fuentes' son las especificaciones para el programador

10
adelantarse demasiado, acumulando inventario de cualquier tipo por si acaso, tampoco es bueno, nos hace
perder flexibilidad y velocidad de respuesta, "no por mucho madrugar, amanece más temprano". Prevenir justo
a tiempo es la clave.
Teniendo definidos los proceso lógicos, si ahora le sumamos las condiciones operativas y la demanda,
obtendremos los procesos físicos. Imagínese que tenemos un método que nos permita programar dinámicamente
los tiempos en que se debe cumplir cada etapa de un ciclo del proceso. Estos tiempos nos permitirían alcanzar
los acuerdos establecidos y además protegerían el eslabón débil del proceso. Podríamos indicar mediante
franjas de tolerancia de acuerdo a la variabilidad de cada etapa: una banda verde (aceptable, seguir), una
amarilla (tolerable, atención) y una roja (descarte, detenerse). Esto nos permitiría guiar la efectividad global
desde cada etapa. Un verdadero semáforo con onda verde. El proceso sería confiablemente sincronizado. De
esta manera también se cumpliría el principio de calidad total, donde el control se hace en cada etapa.
Así cualquier ocurrencia del proceso tendrá, a partir de su nacimiento, un tiempo estimado a cumplir
en cada etapa y márgenes aceptables, expresado en fecha, horas, minutos, segundos, etc. en función de la
precisión que el proceso requiera.
Si esto es así, podremos monitorear constantemente cada ocurrencia en cada paso del proceso y ver en
que franja se encuentran. Esto permitiría el autocontrol de la persona a cargo de la etapa (el operador). Notar
que un operador puede estar atendiendo distintas etapas de distintos procesos lógicos. Entonces, si
monitoreamos todas sus etapas juntas, obtendremos un gráfico que nos definirá las tareas prioritarias a
desarrollar para minimizar los desvíos globales. Todo esto desde una visión local del operador.
Podemos mostrar una gráfica por proceso lógico, con todas sus etapas, con el estado de las
ocurrencias en cada una de ellas o sea una visión global. Esto tendría dos destinatarios: el coordinador del
proceso, que vería en línea donde están los problemas, las restricciones, los cuellos de botella y podría incluso
determinar tendencias para prevenir su propagación. Para el operador de cada etapa existe también la
facilidad de tomar conciencia de cómo lo afectarán las desviaciones que ahora están ocurriendo en la etapa
anterior y qué impacto producirá su propia acción en función de como se encuentra la carga de la etapa
siguiente.
El coordinador podría realizar simulaciones de las políticas a seguir en función de las condiciones de
demanda. Lo que produciría un plan de trabajos mas eficaz, hasta el horizonte visible.
Estos son los principios preventivos, sobre los que se debe desarrollar los sistemas de toma de
decisiones, que permiten conducir la organización en el corto plazo y generan un caudal de información para
poder operar con las herramientas básicas, de análisis de datos, utilizadas en Calidad Total y por otra parte,
alimentar modelos de simulación de la organización, permitiendo hacer más y más reales los supuestos en el
terreno de los problemas divergentes.
La emergente figura del coordinador de procesos también facilita el tránsito entre la estructuras de
poder tradicional (áreas estancas), a la organización basada en procesos, sin grandes baches ni riesgos
operativos, ya que este pasaje es en sí un proceso.
Podemos decir que si el ciclo de vida de este 'sistema organización' es largo, tan largo como la misma
existencia de la organización, el secreto es no tener que dar marcha atrás, así estaremos siempre avanzando
hacia el ideal de la organización, inalcanzable por cierto, pero guía al fin. Seria como polarizar los esfuerzos
de todos los integrantes haciendo converger las soluciones hacia un ideal común, o sea generar un proceso
sinérgico.
Para hacer esto realidad necesitamos metodologías que busquen justamente esto: sincronizar áreas,
eliminar las zonas grises, conformar un sentido común dentro de la organización, que lo haga viable.
En gran parte esta metodología es una reivindicación de un conjunto de viejos principios y métodos
algo olvidados, tanto del campo de sistemas como de la calidad total, que no sólo han perdurado al paso del
tiempo sino que se han beneficiado con los avances tecnológicos. Esto ocurre quizás, porque todas estas
técnicas trabajan con modelos o conceptos, que parecen haber capturado aspectos esenciales de la realidad.
Todos estos principios tienen un modelo subyacente común que los une y les da continuidad y unidad
conceptual.- Este no es otro que el paradigma cliente-proveedor que, como sabemos, también es utilizado en
las más recientes tecnologías informáticas, como solución flexible y económica para soportar los problemas de
cambio continuo de las organizaciones.
Este es el paradigma que nos permite la permanencia.
En el terreno de la informática existen grandes esperanzas en la concreción del viejo sueño matemático
de poder derivar software a partir de una especificación. Algo que no cabe duda que llegaremos a ver, pero
¿cómo sabremos cuando la especificación es la adecuada?.
Las metodologías orientadas a objetos son también muy prometedoras, pero ¿quien es capaz, hoy, de
definir con certeza los objetos realmente necesarios y esenciales para el sistema?. Debemos contar con
métodos para poder identificarlos.

11
Con TQSD/1 se pretende establecer un lenguaje de comunicación entre usuarios e informáticos, un
lenguaje entre el conciente y el subconciente de la organización, trabajando por lo tanto, primero del lado del
cliente (el usuario), para producir especificaciones correctas desde el principio. Luego, por el lado del
proveedor (el informático), para permitir crear estructuras de información que soporten todos los
requerimientos actuales y estén preparadas para los futuros. Trabajar desde el cliente hacia el proveedor: esta
es la clave.
El desconocimiento por parte del usuario de la existencia de este tipo de metodologías, donde él es
realmente el protagonista y líder de su proceso (aplicación), hace que la única cara visible de la informática
para él sea la computadora. Es quizás ésta una de las causas de que siempre esté primero la máquina y luego se
vea qué hacer con ella, siendo que ésta es sólo un recurso tecnológico para materializar parte del
funcionamiento de la organización.
No debe tomarse esta metodología como la solución mágica a todos estos problemas. Lo que si se
puede asegurar es que trabajando realmente con ella obtendremos sistemas que cumplan los requisitos de la
organización, que se harán bien desde la primera vez y por lo tanto el avance de los sistemas acompañando a la
organización, será un proceso continuo, permanente y positivo.
TQSD/1 es una metodología que permite definir, con el aporte de todos, la especificación necesaria
para crear sistemas que realmente funcionen y si se quiere ir más lejos, configurar sistemas de administración
preventiva de procesos que asistan efectivamente a la dirección, permitiendo hacer realidad el sueño de la
organización sincronizada, pero haciéndolo mediante métodos basados en la mejora continua, único camino
para poder asegurar la permanencia de la organización en el medio

12
La forma de avanzar
El siguiente gráfico muestra una curva 'S' de avance tradicional del ciclo de vida de los sistemas donde
se mezclan los problemas divergentes y convergentes. Esto implica que el desconocimiento de la existencia de
esto dos tipos de problemas hace que el tratamiento de los problemas de complejidad de detalle, que son
convergentes, se transformen en divergentes.
Al distinguir problemas de distinta complejidad, también estamos en condiciones de idear y utilizar
distintas tácticas de resolución para cada tipo, maximizando la eficacia de nuestro esfuerzo.
Por otra parte se muestra una curva convergente, de avance continuo en la implementación de los
procesos convergentes hacia el ideal u óptimo cumplimiento de los objetivos definidos para la organización.
Estado OPTIMO de la Organización
Crecimiento continuo y convergente
TQSD/1
Curva 'S' tradicional del
Ciclo de vida de los Sistemas
Mide cuanto antes se puede
alcanzar un determinado estado
Proporcional a los costos de la No Calidad
que son posibles de ahorrar o eliminar
Tiempo en años
El área entre ambas es proporcional a los costos de la no calidad que es posible eliminar.
Todo nuestro proceso metodológico tiene como objetivo rector y prioritario mantener el recorrido del
avance en esta curva convergente.
Ante cualquier toma de decisión nos debemos preguntar.
¿Nos aleja o acerca esta decisión a nuestra curva ideal?.
Recordar que el problema de implementar sistemas, que nos permitan alcanzar los objetivos definidos en
la organización, es un problema de tipo convergente con una gran complejidad de detalles.
Todas las etapas de esta metodología son parte de un proceso de informatización y sistematización continua. El
pretender todo de golpe, todo junto, sólo demuestra que no se ha entendido la idea central del aprendizaje
organizacional.- Este es un proceso de transformación y cambio permanente.
El costo beneficio de su utilización está implícito en su mecánica de trabajo. Cada proceso que se
implementa (inversión en el sistema organización) minimiza los costos de la no calidad, básicamente, los costos
por incumplimiento, que son difíciles de medir.

13
Pero aquí lo importante es poder comenzar a definir parámetros indicadores de si estamos o no
caminando en dirección a la meta. En este punto Eliyahu Goldratt hace un aporte importante al plantear los
siguientes parámetros de medición
Throughput Dinero que entra, es la velocidad a la que el sistema genera dinero a través de las ventas
Inventario Dinero dentro del sistema, es todo el dinero que el sistema ha invertido en comprar cosas
que pretende vender.
Gasto de Operación Dinero que sale, es todo dinero que el sistema gasta en transformar el inventario en
throughput. Elimina la confusión entre gastos e inversión.
La meta es reducir el gasto de operación y reducir el inventario, mientras que simultáneamente se aumenta el
throughput.
Estos parámetro miden los avances en el control de la complejidad en general . O sea: tanto la complejidad
dinámica como la de detalle.10
10 En 'La Carrera' de E.Goldratt se puede ver la relación de estos parámetros y la Utilidad
Neta, Retorno sobre la inversión y Flujo efectivo.

14
Una visión del sueño informático
Creo que debemos compartir muchos este sueño informático y desde hace bastante tiempo.
Lograr sistemas integrados que permitan:
• La normalización de los procesos de recolección y distribución de la información.
• Integración de todos los procesos de la empresa, tanto manuales como por computadora, en un mismo
marco conceptual.
• Integración de los datos operativos con los datos para la toma de decisiones.
• La integración de los sistemas de las diferentes áreas de la Empresa eliminando las islas informáticas.
Siendo el óptimo que la Información esté disponible en tiempo, lugar y forma (preventivamente), para la
toma de decisiones al menor costo posible y en forma persistente.
Estos objetivos son muy deseados pero escurridizos y son muy pocas las organizaciones que los
alcanzan.
Basta con analizar los trabajos de Richard Nolan en Harvard, donde estableció seis niveles o etapas en las que
se puede encontrar una organización con respecto al desarrollo de sus sistemas de información.
Los primeros tres son:
- Etapa de Iniciación o introducción: aquí el procesamiento de datos se centraliza y opera como una función
cerrada, donde el usuario no interviene y las principales aplicaciones en uso son las contables y otras
administrativas.
- Etapa de Contagio o expansión: comienzan a aparecer los programadores orientados al usuario o los
usuarios programadores, fomentados por el uso intensivo de la tecnología, lo que genera cierto caos
informático. Hay una idea de propiciar el crecimiento.
- Etapa de Control de las funciones computarizadas : En esta etapa se refleja el énfasis en la tecnología y la
administración y control de las computadoras. Hay una reestructuración de las aplicaciones y su
documentación. Subsisten las islas informáticas.
Las tres restantes son:
- Etapa de Integración: Comienza un reajuste de las aplicaciones existentes empleando tecnología de base de
datos. Los usuarios utilizan las aplicaciones en sus puestos de trabajo y se hacen responsables de ciertos costos.
El área de procesamiento de datos se vuelve el custodio de éstos últimos.-
- Etapa de Administración de la Información: Comienzan a aparecer sistemas comunes y datos compartidos.
Se integran las aplicaciones y el usuario está involucrado directamente con el registro y uso de los datos,
respondiendo por su calidad.
El área de procesamiento pasa a administrar la información y se establece un equilibrio entre aplicaciones
centralizadas que comparten datos y las descentralizadas controladas por el usuario.
- Etapa de Madurez donde prevalece el enfoque orientado al usuario, integración total de las aplicaciones
'reflejando los flujos de información' y en el uso de metodologías a nivel de toda la organización.
Aquí lo que se administra y planifica estratégicamente son las fuentes de información.
El usuario final y el área de sistemas son responsables en forma conjunta de la calidad de los datos y del
diseño eficaz de las aplicaciones para generar valor agregado en los procesos de la organización.
De este estudio surgen datos que nos muestran que son pocas las empresas, aún en países del primer
mundo, que han alcanzado el estado seis de madurez, encontrándose la mayoría entre el tercero y cuarto
estado.
Una organización puede tener áreas en distintos estados o etapas . Si bien prevalece en alguna de
ellas, lo importante es ¿En cuál se encuentra el área de sistemas, a cuál tiende?.
Nos volvemos a preguntar ¿por qué es tan difícil?. Quizás una explicación razonable está en una serie de
problemas que se deben sortear para poder alcanzar la etapa de madurez.
En la actualidad las empresas se encuentran inmersas en un contexto dado por cambios permanentes,
escasez de recursos, presiones de la competencia y un bajo nivel de motivación del personal.

15
Esto genera situaciones de desorden que dificultan el crecimiento de las organizaciones y, en
situaciones extremas, su propia existencia.
Para poder cumplir nuestro sueño debemos utilizar alguna metodología que nos permita resolver los
problemas que impiden que el trabajo sea realmente eficaz.
De la experiencia obtenida en la aplicación de TQSD/1 estamos en condiciones de decir que éste
permite saltar de prácticamente cualquier estado al sexto, en las áreas con ella atacadas, produciendo avances
cualitativos y sin necesidad de cambios sustanciales de personal.
TQSD/1 es la herramienta ideal para especificar e implementar sistemas en organizaciones que estén
embarcadas en un proceso de calidad total.
Pero, como dijimos en la introducción, para poder aumentar nuestra capacidad de administrar y
controlar la complejidad de detalles, debemos primero resolver una serie de problemas.

16
Los problemas
La falta de sentido común
Cuántas veces nos quejamos por la falta de sentido común en las decisiones que se toman en una
organización!.
Parece que no es tan fácil saber cual es la mejor opción para un determinado problema, dado que la
forma de valorarla dependerá de quien tome la decisión.- Lo único que queda demostrado es que la realidad es
lo suficientemente compleja como para que sea realmente imposible ver todos los casos, o más aún, los
importantes para nuestro proyecto, ¿cuántas veces estamos plenamente convencidos de alguna decisión y
aparece alguien que con un simple y claro razonamiento nos tira por tierra nuestras más férreas convicciones
?.
Por esto es necesario utilizar métodos que conduzcan y guíen nuestros procesos decisorios, no dejando
lugar a dudas que vamos avanzando en el sentido correcto.- Aquí, distinguir el tipo de complejidad que tenemos
por delante es crítico.
Muchos métodos son creados.- Para sus autores son muy buenos y no tanto para otros.- Mas lo que
realmente ocurre, es que el método se nos entrega sin el manual del "sentido común" utilizado para aplicarlo
correctamente. Lo que en realidad nos falta es la escala de valores del autor o usuario exitoso del método.
Para que un método se precie de tal debe ser posible de aplicar por cualquier persona de nivel normal y no sólo
por genios.
Bajo esta realidad encontramos que gran parte de los valores de ese tal "sentido común" que debemos
tener presentes al aplicar esta metodología, están presentes en los principios conceptuales y filosóficos
utilizados por los procesos de Calidad Total, Teoría de la Restricciones y el proceso de aprendizaje de la
Organización Inteligente.
Quizás una de las reglas más importantes aquí es hacer las cosas bien desde el comienzo.- Siempre
estamos resolviendo en emergencia y no hay tiempo para hacer las cosas como se debiera.- Pero si no hay
tiempo cuando realmente las necesitamos, ¿por qué lo habrá después?.
Tenemos que aprovechar las oportunidades que las necesidades y prioridades nos brindan, los ya
famosos cuellos de botella, para ir armando en forma paulatina y perfectamente coherente nuestros sistemas
integrados.
Y aquí el primer paso es obtener una correcta especificación para cada solución encontrada.
La Escala
Pareciera que el problema de definir los sistemas integrales de una organización, un sueño desde
siempre, tiene un problema de escala que supera normalmente la capacidad de muchos de nosotros. Los
informáticos tenemos fama de no cumplir nunca los plazos que nosotros mismos nos fijamos.
Quizás debemos ser más humildes frente a esa realidad y pedir ayuda, o tal vez ser capaces de
encontrar mecanismos que nos permitan sumar la visión que cada uno tiene de parte de ella.- Aquí la Calidad
total nos enseña la necesaria participación de todos en la solución de los problemas.
La escala de los problemas nos deja muchas veces pagando por la insensatez de su subestimación.
Algunas veces extrapolamos soluciones con demasiada liviandad sin analizar profundamente la escala del
problema.- Otras, somos incapaces de comprender su verdadera magnitud y como todos sabemos, la realidad es
irrefutable y no perdona.
Muchas veces los principios a utilizar son los mismos, pero no así las soluciones obtenidas.- Los
principios ópticos del microscopio son los mismos que los de un telescopio; sin embargo los aparatos no son
intercambiables.
Al problema de la escala le debemos sumar los problemas de percepción y comunicación.
Supongamos por un momento que nos piden que relevemos una ciudad, que dibujemos su plano.- Podríamos
recorrerla, a pie, en auto o sobrevolarla.- Creo que nadie dudaría que la mejor manera de obtener un plano
completo y correcto de ésta sería obtener una grilla de fotos aéreas con cierto grado de superposición, lo que
nos permitiría tener 'la foto' de esta ciudad.

17
Pero en nuestro caso, ¿cuál es el avión para sobrevolar una organización?. Las entrevistas analista-
usuario utilizadas normalmente no son otra cosa que recorrer a pie, parte de la ciudad y, para colmo de males,
de noche y en un día lluvioso.
Pedirle a cada usuario que analice por sí mismo sus problemas tampoco es muy saludable y requeriría
una larga campaña de capacitación y nivelación previa y no nos asegura un buen resultado al corto plazo.
Luego necesitamos un método que trabaje en forma simple y segura.- Volviendo a nuestro ejemplo de
las fotos aéreas, le podríamos dar a cada uno una máquina fotográfica, todas iguales, todas compatibles, todas
obteniendo imágenes parcialmente superpuestas para permitir su perfecto ensamble, sin grandes esfuerzos de
capacitación ni obligando al usuario a realizar nada extraño para él, nada que no le sea enteramente natural e
intuitivo.
Todos sabemos en qué gastamos nuestro tiempo, qué cosas damos y qué cosas recibimos o tal vez
reclamamos. Y por nuestra naturaleza egocéntrica, nos ubicamos en el centro del universo.
Pero también es cierto que cada vez que opinamos sobre lo que ocurre entre otros, no somos
demasiado precisos y nos basamos en suposiciones.
De manera que lo importante es:
- Pedir a cada uno lo que realmente es capaz de dar.
- Cada uno sólo puede hablar de sus temas específicos.
- Cada uno sabe en qué consiste su trabajo, más allá de como lo hace.
Más adelante veremos como utilizar los diagramas de entidad para poder obtener visiones colectivas
completas y correctas de una organización, como suma de la visión individual de cada uno de sus integrantes,
lo que producirá un resultado superior al que puede tener cualquiera de ellos, por más versado que éste sea.
Lo interesante de esto es que el resultado de este tipo de relevamiento no requerirá de grandes esfuerzos
intelectuales ni dependerá mayormente de la capacidad de las personas que lo realicen, pero sí de la
participación de los integrantes de la organización, único camino para obtener una visión compartida por
todos y hecha propia por cada uno.
El Cambio
Como si lo anterior no fuera suficiente fuente de problemas, todo está en constante cambio.
El cambio es parte de la vida de las organizaciones, pero los sistemas tienen que ser cambiados por las
personas.
"La principal razón la debemos buscar en la naturaleza de la mente humana, su contenido está en
un proceso continuo de aprendizaje y cambio.
En los sistemas los contenidos son los datos y los datos nunca cambian excepto cuando son actualizados por
los programas.
Las organizaciones están en cambio permanentemente, la estructura de un sistema cambia sólo si alguien
trabaja para cambiarla. No es suficiente con modificar el contenido de los sistemas (archivos y programas).-
Es más importante la modificación de la estructura del sistema, sólo así podremos obtener una buena
correlación entre la organización y el sistema de información" 11.
Los cambios pueden ser de distinto origen:
Internos a la organización:
Cambios a nivel de Dirección
Aparecerán nuevos enfoques de la dirección , la determinación de nuevos indicadores de gestión.
Debería preocuparnos si alguien utiliza durante mucho tiempo la misma información para tomar sus
decisiones, en los tiempos que corren, porque seguramente no le está siendo muy útil.- Este campo de la
información es el más volátil y cambiante de todos.
La estructura de información debe ser lo suficientemente flexible y representativa de la realidad, como para
permitir responder en tiempo y forma a este tipo de cambios.
11 J.D.Warnier

18
Cambios a nivel de la Organización
Puede ser que se decida la creación de una nueva área o departamento para mejorar la gestión de
determinadas tareas o, lo contrario, la fusión de áreas. En cualquiera de los casos, el proceso que la
organización hace no cambia, sólo sufre una reubicación.- Cambia quién lo hace y tal vez cómo lo hace.
Esto se traducirá como el cambio o reubicación de las transacciones involucradas en los distintos procesos de
los sistemas.
Cambios a nivel Operativo
Puede ser que se cambien métodos o mejoren procesos, que se aumente la calidad o el control, que en
definitiva no será otra cosa que cambiar por una mejor manera de alcanzar un resultado.
Aparecerán nuevas transacciones o se modificarán algunas de las existentes.- Todos estos cambios son
completamente modulares.
Externos a la organización como:
Cambios en la relación con Proveedores y Clientes
La generación de nuevos servicios o productos o eliminación de alguna línea de productos que afecte
la relación con el exterior.
Estos son los cambios más difíciles de predecir y es aquí donde la planificación estratégica de la
organización deberá aportar pautas o tendencias para minimizar sus efectos.
Pero los sistemas deben ser capaces de seguir la realidad externa con gran exactitud porque su objetivo final no
es implementar transacciones internas, controles, etc., sino satisfacer al cliente externo a la organización. Todo
el proceso interno debe estar subordinado al objetivo externo.
Pero ¿cómo hacer para independizarnos de los cambios?, ¿cómo hacer que nuestros sistemas sufran
lo menos posible ante ellos? Es bueno señalar que a nadie se le ocurriría construir su casa donde el terreno es
anegadizo o movedizo.- Todos buscaremos la roca para apoyarnos, o sea puntos más firmes que evitarán las
rajaduras.
Para sobrellevar estos problemas debemos hacer sistemas que tengan la mayor independencia posible
de los cambios que sufre la empresa; o sea apoyarnos en las estructuras menos variables, las que llamaremos
las 'estructuras invariantes' que nos permitan soportar los objetivos 'condicionantes' del sistema.
Por lo tanto debemos trabajar para identificar esas estructuras menos variantes de nuestros sistemas.
Aunque no lo parezca, éstas son las que soportan justamente las transacciones con los clientes y proveedores
externos.
Esto significa que si bien los objetivos de la organización nacen de poder obtener las reales
necesidades de los clientes, que son de carácter evolutivo e innovativo, el mecanismo que las soporta se ha
basado, se basa y se basará en el protocolo del modelo cliente-proveedor. Este modelo de comportamiento es
una constante y por lo tanto un buen punto de apoyo.
Las mil Opciones
Al trabajar en un proyecto informático, otro de los mayores problemas es cómo resolver el abanico de
alternativas que se presentan a nuestro paso en todas las etapas del proceso.
Gastamos gran cantidad de esfuerzo analizando qué camino tomar. Creo que hoy, más que nunca,
vivimos frente a una superabundancia de opciones, pero debemos tener métodos para resolver este problema.
Supongamos que hacemos un experimento que tiene por objetivo encontrar una manera eficaz de armar el
'clone' de un televisor.- Pensemos por un momento que armamos dos grupos de trabajo para poner a prueba
dos métodos opuestos. Un grupo formado por los mejores cinco ingenieros electrónicos, a los que entregamos
los planos de los circuitos y en una caja todos los componentes necesarios para armar un televisor y les
pedimos que encuentren una secuencia de pasos eficaz para armarlo.- En el otro grupo pondremos dos chicos,
uno en edad escolar que sepa escribir y un ayudante de esos que les gusta romper todo lo que se pone en su
camino.- A los chicos les damos un televisor armado y les pedimos el mismo resultado, o sea una secuencia de
pasos eficaz para su armado, pero les damos una ayudita, incitando al ayudante destructor a desarmar el

19
televisor completamente y a su 'jefe' a anotar todo lo que se saca, sin dejar pasar nada por alto, produciendo
una lista de desarme.
Luego de un rato, los chicos tendrán un televisor destruido, pero también un proceso eficaz de armado.
Sólo basta leer la lista de desarme al revés.- En cambio, el grupo de ingenieros estará todavía tratando de
decidir entre las numerosas alternativas que presenta el armado.
Claro, dirán ustedes, así es fácil cuando se sabe el resultado. Pero sí estaremos de acuerdo en que
nuestro problema real no es otro que tener perfectamente definido nuestro objetivo. Aquí, nuestro televisor
serán los requerimientos correctos de nuestro sistema.
Este tipo de ataque a los problemas es muy conocido y utilizado en disciplinas más antiguas que la
informática. A ningún ingeniero se le ocurriría diseñar y calcular un edificio comenzando por las fundaciones,
sino por el tanque de agua, luego las vigas, que descansan en columnas, hasta llegar a definir correctamente y
sin lugar a dudas, las bases de las fundaciones.
Pero claro, no faltará el que diga "hágala de tanto por tanto que siempre es lo mismo", o sea
reutilización de soluciones conocidas. Este último método no siempre da buenos resultados. Todo dependerá de
la complejidad de la obra y la experiencia del proyectista.
Uno de los principios de Calidad total es el que apunta a definir, como primer paso, las necesidades de
nuestro cliente, último eslabón de nuestro proceso, lo que nos obliga a caminar hacia atrás en el proceso de
análisis.
Esta metodología orientada a la salida produce una solución al problema de las mil opciones.
No confundir esto con top-to-down esto es output-to-input, es caminar hacia atrás, desde los objetivos
del cliente, única forma de obtener el sistema mínimo que sea completo.
Es caminar hacia atrás el lazo (proceso) completo establecido con un tercero externo.- Se comienza
indagando las necesidades del cliente y se termina satisfaciendo al cliente.
El Sincronismo
Todo aquél que ha trabajado en una organización sabe que cada área tiene, al menos, una aceptable
capacidad para desarrollar sus tareas.- Cada una conoce su especialidad y, normalmente, la domina, pero aún
así es extremadamente difícil hacer que todo funcione bien.
Una organización es como una orquesta, donde cada cual debe tocar muy bien su instrumento, pero si
no existe un director que consiga la perfecta sincronización de todos, los clientes tendrán, en lugar de
agradables melodías, sólo ruidos molestos.
Por supuesto que esa sincronización debe ser también con los proveedores y clientes externos. De
nada vale que todos toquen muy bien pero se equivoquen de día u hora de actuación, dejando al auditorio
insatisfecho.
Son pocas, o quizás ninguna, las orquestas que puedan hacer bien su trabajo improvisando. En una
orquesta lo que cada uno debe tocar está perfectamente establecido en una partitura. En una organización
debemos fijar las normas de funcionamiento, los sistemas de operación, las frecuencias, para producir el
sincronismo necesario.
Las reglas de juego de la competitividad de hoy no son muy distintas a las de una carrera de autos. Si
tenemos el motor fuera de punto, esto provocará un alto consumo de combustible y poca velocidad, dando un
comportamiento poco eficaz y con alta probabilidad de que perdamos la carrera.
Lo que buscamos son procesos continuos y sincronizados , o sea procesos mínimos y eficaces.- Esto no
implica necesariamente más veloces, porque si son eficaces para satisfacer la demanda del cliente, nuestro
objetivo.- Para qué hacerlos más veloces? Aquí también se esconde el secreto del mínimo.
La Clasificación
Otro gran problema con que se enfrenta un proceso de informatización es el ordenamiento de
entidades, o sea la clasificación o agrupamiento. Existen tantas formas de clasificarlas como áreas participen.
Esto, que quizás parece inofensivo, puede generar graves problemas futuros y es, normalmente, descuidado.
Debemos tener en cuenta que al querer realizar sistemas más y más integrales, se nos presentan graves
problemas de clasificación, para dejar a todos conformes.
La teoría de conjuntos subyacente a todo este proceso es muy útil, pero necesitamos un modelo de
clasificación que sea usado por todos los individuos que participan del proceso.

20
Se puede clasificar por muchos conceptos, pero el que necesitamos es aquél que pueda ser utilizado de
manera simple y que, por otra parte, responda a algún modelo de la realidad.
La estructura de clasificación final deberá ser la misma cualquiera sea el orden en que implementemos
las etapas de los procesos.-
Este modelo debe respetar reglas lo suficientemente claras y generales para sernos útil en,
prácticamente, cualquier clasificación de objetos reales y ser lo más independiente posible de los cambios que
ocurren, lo que lo hará más estable.
Debemos tener la precaución de representar las cosas desde el punto de vista de la realidad y no de la
implementación.
Muchas veces, cuanto más nos esforzamos en los detalles de una transacción y tratamos de hacer
corresponder los datos con ésta, más nos atamos a los cambios que ella puede sufrir. De nuevo aquí tratemos
de clasificar en función de lo menos variable.
La resistencia al cambio
Este problema está directamente ligado a la motivación de las personas. Nadie quiere cambiar, en
principio, al menos que se beneficie en algo. Pero ese beneficio debe ser posible de visualizar antes de tenerlo y
para esto la única forma de trabajar no es sólo la participación, sino un total involucramiento en el proceso de
cambio, donde las personas son artífices de sus propios cambios.
Hasta la fecha la experiencia acumulada al respecto indica que lograr involucrar al usuario en el
proceso de definición de requerimientos, es la mejor manera de vencer la resistencia al cambio.
Cuando éste se involucra y lidera el desarrollo de su aplicación, no sólo será un colaborador del
personal de sistemas, sino que al seguir de cerca el proceso y conocer las reales dificultades encontradas, no
ejercerá presiones innecesarias generadas por la ansiedad y el desconocimiento, que normalmente son las que
impiden hacer los sistemas bien desde un principio.-
Nada es más satisfactorio para un informático que un usuario defendiendo sus sistemas.
Las zonas grises
Entre áreas de la empresa
Las zonas grises no son más que las relaciones clientes-proveedores mal definidas, mal especificadas,
que no hacen más que crear potenciales problemas futuros en las relaciones. Terreno fértil para que se cumpla
inexorablemente la ley de Murphy.
Toda la metodología que veremos ataca directamente estos puntos grises, definiendo precisamente
estas relaciones como paso prioritario e indispensable para poder comenzar con cualquier desarrollo.
Entre informáticos y usuario
Aquí el problema no es muy distinto. La mala especificación de las futuras aplicaciones, los
relevamientos incompletos y la falta de comprensión de lo que será el sistema terminado, por ambas partes,
también es fuente de problemas.
Sólo una clara especificación entendible en su totalidad por todos los usuarios e informáticos puede
asegurar el buen comienzo de un proyecto informático.
En este punto el cambio más grande le corresponde a los informáticos, modificando drásticamente la
forma de encarar los proyectos. No desde el productor al cliente sino desde el cliente al productor. Este es
quizás el escollo más grande a vencer.
No olvidar que las técnicas de especificación son formas de establecer la comunicación entre clientes y
proveedores.

21
Resumen
La meta:
Permanecer, armónicamente, en un medio de complejidad creciente
• Descubriendo, qué cambiar
• Creando, a qué cambiar
• Produciendo los cambios
La complejidad tiene dos perfiles diferentes
• complejidad dinámica, problema divergente
• complejidad de detalle, problema convergente
El consciente de la organización, su dirección, es necesario para controlar la complejidad dinámica,
mediante el aprendizaje continuo, mejorando los supuestos.
El subconciente de la organización, sus sistemas y procesos, son necesarios para administrar la
complejidad de detalles.
Para dominar la complejidad de detalles necesitamos una metodología que nos permita:
• Obtener una visión real y completa de la organización, mostrando 'quién hace qué', tarea en donde el rol
del usuario es crítico.
• Poder descubrir los objetivos condicionantes de la organización, para poder apoyarnos en ellos al
construir sus sistemas integrados.
• A partir de esos objetivos condicionantes, mediante la técnica de desarmado obtener los procesos más
eficaces para la organización.
• Establecer los puntos de sincronización con la realidad para que todo ocurra cuando se espera que
ocurra.
• Soportar la estructura de información sobre conceptos de clasificación que sirvan tanto para las
necesidades actuales como para las futuras

22
TQSD/1 (Total Quality Systems Development /1)
Introducción
La realidad hace necesario que la empresa de hoy se base en estructuras flexibles y de rápida
adaptación a las nuevas exigencias del medio.
Su estructura se mueve en equilibrio sobre dos ruedas fundamentales:
- Personal (comportamiento y cultura de la organización)
- Organización (procesos y sistemas)
Ambos tienen el desafío de adaptarse y acompañar a la cambiante realidad. Pero estos dos
componentes deben trabajar equilibrada y sincronizadamente para que el esfuerzo sea eficaz.
No es difícil notar que lo complejo es hacer que un conjunto de áreas de la empresa trabajen coordinadamente
y no se molesten unas a otras, haciéndole perder rendimiento a toda la organización. Imagínese tan solo andar
en una bicicleta donde las ruedas no quieren ir a la misma velocidad.- Sería como tener una rueda frenada,
donde el esfuerzo no sería para vencer una pendiente del terreno, sino nuestros propios problemas.-
Descubriríamos, así, que somos nuestros propios enemigos.
Los sistemas informáticos no son más que una parte de la organización, su subsconciente y la tecnología
informática utilizada, sólo una herramienta para su implementación.
TQSD/1 es una metodología para el desarrollo de los sistemas integrales de la empresa, que trata de
superar los problemas presentados, trabajando para tener éxito, con y para sus pilares fundamentales, con las
siguientes características:
- Trabaja con las personas involucradas.
- Organizando y optimizando su funcionamiento operativo.
- Reflejando el mismo en los sistemas de información.
Es una metodología que opera con el modelo propuesto por Calidad Total: el modelo Cliente-
Proveedor.
Este modelo Cliente-Proveedor es utilizado y respetado en todas las etapas de proceso de informatización de la
Empresa.
En este contexto, el concepto del Cliente tiene vital importancia. Este cliente puede ser tanto interno
como externo a la organización; él será quien determine la calidad del producto o servicio y es en sus
necesidades donde debe comenzar el proceso de análisis y definición de requerimientos.
Por otra parte existen en la actualidad claras tendencias de la informática a las arquitecturas abiertas, que
también han llegado, con los últimos avances tecnológicos, a la utilización del modelo Cliente -Servidor.
TQSD/1 se ubica, entonces, dentro del marco de referencia que da Calidad Total y las últimas
técnicas de informatización de los procesos en la organización, haciendo esto de manera simple, continua y
convergente hacia la obtención de sistemas integrales.
Está en permanente proceso evolutivo, ya que debe mejorarse continuamente y así responder y
anticiparse con flexibilidad a las demandas de sus clientes, permitiendo que la organización pueda sacar
provecho de los avances tecnológicos, aumentando en definitiva su Calidad.
Emplea en todas las etapas el modelo Cliente -Proveedor.
E ta p a s d e l a p r e n d iz a je y fa s e s d e la m e to d o lo g ía
P u e s ta e n m a r c h a y o p e r a c ió n
subconsciente Im p le m e n ta c ió n
competente
consciente D is e ñ o d e tr a n s a c c io n e s
competente D is e ñ o E s tr u c tu r a d e In fo r m a c ió n
consciente D e fin ic ió n d e r e q u e r im ie n to s
incompetente
inconsciente C o n s c ie n tiz a c ió n d e la o r g a n iz a c ió n
incompetente

23
Concientizacion de la organización:
Crear un sentido común dentro de la organización es el máximo desafío de esta etapa.
Se utilizan aquí muchos de los principios y técnicas de TQ (Total Quality) y 'Organización Inteligente', que
sirven de base a todos los desarrollos posteriores, generando el proceso sinérgico necesario para movilizar las
voluntades a alcanzar los objetivos comunes de la organización.
Este es el primer escalón del aprendizaje, la toma de conciencia por parte de la organización de los
límites de sus procesos.
Definición de requerimientos:
Para este proceso se utilizan técnicas basadas en DSSD (Data Structure System Development) de Ken
Orr, para la definición de los procesos lógicos ,la cual implica máxima participación del usuario (cliente del
sistema) en las etapas de definición de los requisitos, colocándolo como líder del proyecto de su proceso,
guiándolo a satisfacer las necesidades de sus propios clientes internos o externos.
Definición de las estructuras de información:
Se utilizan esquemas estructurados de datos basados en LCS (Logical Construction of Systems) de
J.D.Warnier que representan el modelo cliente proveedor. Aquí el desafío es ser capaz de diseñar estructuras de
información que sirvan para cubrir las necesidades actuales, pero también las futuras, minimizando su
sensibilidad a los cambios.
Esta etapa está en correspondencia con la formación de la estructura del subconciente necesaria para
soportar la complejidad de detalles, tarea para los informáticos, los forjadores del subconciente de la
organización.
Diseño de transacciones:
A partir de estos procesos lógicos se utilizarán técnicas como el matrizado de Calidad Total para
definir los recursos necesarios para que cada etapa del proceso.
Se utilizan luego los principios funcionales del modelo (Client-Server) separando la definición de las
aplicaciones -cliente, de la definición de las bases de datos de las cuales se servirá.
Esta es también una forma económica de permitir la escalabilidad tanto horizontal como vertical de los
sistemas de aplicación.
Se pretende conceptualizar a cada transacción como un objeto de nuestro sistema, que haga solo lo
diferente, dejando lo común a los servidores: Servidores de bases de datos, Servidor de procesos para
administrar los flujos, Servidores contables para realizar los asientos y así siguiendo. Cada función de servicio
dentro de la organización es pasible de ser asistida por un servidor informático.
Esta estrategia nos permite sistematizar rápidamente las operaciones rutinarias. Aquí es fundamental
alcanzar el detalle necesario para que lo esencial de la transacción quede perfectamente definido. Debe
contener la mínima documentación necesaria y suficiente, como para que un programador la pueda codificar en
algún lenguaje o herramienta, sin tener que preguntar nada a nadie.
Otra estrategia importante es la separación de las transacciones operativas y las de toma de
decisiones.
Estas tres fases forman parte del segundo escalón del aprendizaje.- Es el paso más laborioso, pero sin
el no hay real avance.
Implementación
Para la implementación se utilizan las herramientas y estándares de hardware y software definidos por
los sistemas de arquitectura abierta.
De esta manera se minimizan los costos generados por los continuos cambios y se permite la
convivencia de transacciones implementadas en distintas herramientas, haciendo posible aprovechar
desarrollos existentes.

24
Puesta en marcha y operación
Esta es la etapa de la práctica, donde el directivo debe tomarle el tiempo a los procesos físicos y los
operario ver que sus necesidades fueron cubiertas de acuerdo a lo especificado, etapa genera la confianza
necesaria para que la nueva mecánica de trabajo pase a ser un nuevo automatismo implementado en el
subconciente de la organización.
En la operación se utiliza el método DBR12 de la Teoría de Restricciones para considerar las
limitaciones que dinámicamente va presentando nuestra organización ante los cambios de la demanda del
mercado, conformando a cada momento nuevas configuraciones en los procesos físicos, con los cuales tiene que
lidiar la dirección de la organización.
Todas estas técnicas y métodos trabajan con un mismo modelo conceptual que no es otro que el
Cliente-Proveedor.
M o d e l o C L I E N T E - P R O V E E D O R
C L I E N T E P R O V E E D O R
I n te r c a m b i o I n te r c a m b i o
O R G A N I Z A C I O N
Aquí aparece la organización en relación con proveedores y clientes con los que mantiene intercambio de
bienes o servicios (objeto del intercambio), mediante un protocolo de relación o intercambio13.
En este esquema, cada proceso de la organización comienza y termina en un tercero (cliente o proveedor
externo), cerrando un lazo completo con el mismo.
12 Drum-Buffer-Rope E.Goldratt
13 J.D.Warnier

25
Resumen
TQSD/1 Esta formada por la integración y adaptación de las siguientes técnicas:
• TQ (Total Quality)
Para homogeneizar la escala de valores y crear un sentido común en la organización, la toma de
conciencia organizacional.
• DSSD (Data Structure System Development)
Para permitir que el usuario se involucre en la definición de los requerimientos de sus procesos,
permitiendo especificar los procesos lógicos.
• Matrizado (Calidad Total) para a partir de los procesos lógicos definir los recursos necesarios para cada
etapa.
• LCS (Logical Construction of Systems)
Para la normalización y clasificación de la información de las Bases de Datos.
• OA (Open Architecture)
Para soportar físicamente la informática de la organización y acompañar su continuo cambio.
• Teoría de la Restricciones (DBR)
Para administrar preventivamente la operación de los procesos, permitiendo configurar los procesos
físicos que dinámicamente se generan en la realidad
En los capítulos siguientes se describen conceptualmente las técnicas y métodos mencionados haciendo
hincapié en la forma en que TQSD/1 los integra. El lector podrá profundizar en la bibliografía seleccionada los
temas de su interés.

26
Concientización de la Organización
Q (Total Quality)
Las técnicas de Calidad total definen un conjunto de valores, principios y métodos que permiten
implementar sistemáticamente un sentido común dentro de la organización, haciendo converger los esfuerzos
en pos de un objetivo.
Algunos principios básicos de Calidad total:
La Calidad
La calidad se puede definir como "el cumplimiento de los requisitos" y no como lo "bueno" 14.
Esto significa hacer las cosas bien desde un principio.-
La calidad no es otra cosa que cumplir con los objetivos del cliente; por lo tanto la planificación de la
Calidad implica lograr una buena comprensión de los requisitos, una buena comprensión de los recursos y un
buen plan de ataque para lograr un resultado aceptable por el cliente, de manera económica.
Los requisitos son negociables, pero la calidad (ajustarse a los requisitos) no lo es, ésto debemos
tenerlo siempre presente.
Podemos decir que de la buena definición y comprensión de los requisitos depende el éxito del proyecto
y por lo tanto debemos darle a esta etapa la importancia real que tiene.
Debemos ser cuidadosos tanto en la extensión como en la profundidad de las especificaciones. Si
pecamos de falta de detalle, dejaremos muchos puntos librados a la imaginación del productor.- Si nos
excedemos, podemos empañar los objetivos importantes.- El justo equilibrio es lo buscado.
No olvidar que los requisitos son una forma de comunicación entre el cliente y proveedor, entre
usuarios e informáticos.
Debemos recordar siempre que la calidad de un servicio o producto la mide la conformidad del Cliente
y no la opinión del prestador o productor.
Hacer cosas en un sistema de calidad consiste en prevenir, estudiando los procesos e identificando sus
restricciones y minimizando las oportunidades que le damos a la famosa ley de Murphy , El viejo dicho "Más
vale prevenir que curar" se conoce en mas de veinte idiomas. Por algo será.
¿Cómo podemos pretender que un sistema funcione bien, si no somos capaces de definir su especificación en
forma completa?.
Esto implica también una responsabilidad indelegable de la dirección de cada área de la organización.
Esta debe establecer los requisitos, proveer los medios y alentar a cumplirlos.
Cada uno tiene la responsabilidad de no dejar cabos sueltos en las especificaciones; los que dejemos se
convertirán en problemas a mediano o largo plazo15. El usuario líder de su aplicación es el responsable de que
requisitos estén bien definidos.- El administrador de información debe asegurarse de que los nuevos requisitos
ensamblen correctamente con el resto de la estructura de información de la organización. El programador debe
ajustarse a las especificaciones y no inventar mejores soluciones, ya que por buenas que éstas sean, si no están
en armonía con el todo, sólo conseguirán reducir la calidad del software generado.
Circuitos de procesos equilibrados y sincronizados
Toda organización es un conjunto de entidades que tiene por objetivo lograr un producto o servicio, que
algún cliente necesita.
Cada etapa debería agregar valor al producir una transformación de algo, a lo largo de todo el proceso,
hasta llegar a un producto o servicio de interés y por lo tanto, vendible al cliente.
Podemos decir que todo lo que realizamos dentro de la organización, que no agrega valor al producto o
servicio son recursos y esfuerzos mal aprovechados.
Pero podemos ir aún más lejos diciendo que no siempre el valor agregado será de interés para el cliente y
por lo tanto no es vendible. Al tener en cuenta esta componente económica de la calidad, todo lo que no
podemos vender no lo deberíamos hacer.
14 Philip B. Crosby
15 Proceso de demora (arquetipos sistémicos) P.Senge

27
Notar que este punto tiene un comportamiento dinámico y por lo tanto el equilibrio y el sincronismo se
consigue y se pierde constantemente. Esto nos obliga a trabajar siempre en un proceso contínuo de
estabilización.
Debemos minimizar el valor agregado no vendible.
Esto implica maximizar el equilibrio y sincronización de todos los procesos que realiza la
organización.
Esta tarea es prioritaria y tiene mayor importancia que la tecnología utilizada para optimizar los
procesos.- Muchas veces descubriremos que para sincronizar correctamente, hasta debemos disminuir la
velocidad de ciertas etapas de los procesos.
C lie n te P r o v e e d o r
O r g a n iz a c io n
Roles dentro de la organización
Intervención de los integrantes de la organización
La complejidad de la realidad hace imposible la realización de grandes empresas sin la participación
activa y recíproca de todos sus integrantes.
Un elemento clave en el sistema de Calidad es la constante y comprometida actitud de la gente hacia la
Calidad y el rendimiento standard que deberá ser libre de error. Todo aquello que sea de nivel inferior no será
lo suficiente bueno.
En este punto reside el secreto para generar la fuerza necesaria para permitir los cambios en la organización.
Los costos de la No Calidad
Entre las cosas que no podemos vender están los costos de la no calidad.
Podemos decir que si sumamos todo aquello que no hubiera sido necesario repetir, si se hubiera hecho bien
la primera vez, tendremos el precio del incumplimiento o sea de la No calidad.
Una pequeña inversión en costos preventivos redundará en una cantidad varias veces mayor que se
ahorrará en costos por reproceso, deficiencia o rechazo.
Piense por un momento, solo en el campo de sistemas, el enorme costo en recursos y tiempo empleado al
tomar una línea de trabajo con un producto o enfoque determinado. (metodologías, plataformas de software y
hardware), ¿Cuántos años son necesarios para cambiarlo por otro?, ¿cuánto esfuerzo se empleará para tratar

28
de hacer funcionar lo que no anda, antes de desecharlo definitivamente?; Todo esto forma parte de los costos
ocultos que rara vez son analizados, pero que no por ello dejan de existir.
Analizando el funcionamiento global de una organización, estos costos rondan entre el 25 y 35% de la
facturación de empresas de producción y de servicios, respectivamente.
Esto muestra la importancia de hacer las cosas bien desde la primera vez, tratando de atacar la complejidad de
detalle, con principios y técnicas que nos permitan recorrer una curva convergente. Como también trabajar
preventivamente anticipando problemas.

29
Resumen
La Calidad Total es una metodología que:
• Involucra a todos los integrantes de la organización en el proceso de definición de los requisitos,
cubriendo así las reales necesidades.
• Permite equilibrar y sincronizar todas las relaciones cliente-proveedor tanto internas como externas,
teniendo por objetivo minimizar el valor agregado no vendible.
• Permite realizar bien, desde un principio, las partes del sistema integral de la organización, minimizando
la influencia en el resultado final, del orden de las necesidades o prioridades coyunturales .

30
Definición de los requerimientos
Todo aquel que ha incursionado en informática sabe que los problemas más significativos en software
no ocurren a nivel de programación, pero sí a nivel de sistemas. ¿Cómo hacer que todos los módulos y
programas trabajen en conjunto y bien ?. Esto no difiere en nada del problema de hacer funcionar globalmente
a una organización. Aqui debemos separar los aspectos lógicos de procesos y su funcionamiento físico que
implica asignar recursos a sus etapas.
Esta fase esta basada en DSSD, Data Structure System Development, de Ken Orr y se la utiliza para
definir los procesos a un nivel lógico.
Es fundamental comprender aquí que el nivel a partir del cual estamos trabajando en esta etapa está
definido sólo por la relación cliente proveedor. Esto significa que el nivel de flotación a partir del cual vemos
esta limitado por la visión de los resultados externos que producen los seres humanos. Este nivel de flotación es
natural y fácil de comprender, nada de lo que una persona hace internamente en su trabajo para producir un
resultado nos interesa por ahora.
En realidad, como ya hemos visto, nos debemos preguntar ¿Cómo podemos obtener los requerimientos
correctos?. Este es el paso imprescindible para poder alcanzar el éxito en el desarrollo de un sistema y hacer
las cosas bien a la primera vez.
Para esto debemos utilizar una técnicas que cumpla con las siguientes premisas:
- Ser clara y accesible a todos, informáticos y usuarios
- Ser consistente y eficaz por eliminación de redundancias
- Responder a las necesidades de los usuarios
Debe ser simple de entender para los usuarios, los que son involucrados en el proceso de definición de
los requerimientos, usando una estrategia de diseño orientada a los objetivos: las necesidades de sus clientes.
Trabajando desde las salidas requeridas (outputs) para atrás, es posible determinar la mínima base de
datos que soporte el sistema y luego desde ésta a las entradas ideales (inputs).
Una buena estrategia de ataque al problema de la especificación permitirá resolverlo fácil y
eficazmente, si no es así, puede ser por dos causas: la estrategia no es la adecuada para el problema, o no
sabemos aplicarla correctamente.
Pero lo más importante es que el sistema produzca respuestas que estén de acuerdo con el mundo real,
que estén en sincronismo con él. Si los datos son seguros y consistentes, éstos serán frecuentemente usados; de
otra manera, las respuestas que obtendremos serán erróneas. Se puede asegurar que la calidad de los datos
está en directa relación con su uso y no con el control de ingreso, procesamiento o almacenaje.
Solamente un método orientado a la salida puede asegurar que:
- Todos los datos requeridos , y sólo ellos, sean capturados.
- Solamente los procesos necesarios sean usados.
- El alcance del sistema esté claramente delimitado.
En esta etapa de definición de los requerimientos, utilizaremos un conjunto de diagramas, como
herramientas para poder armar una visión colectiva de la organización.
Atacamos su complejidad de detalle desde tres puntos de vista distintos:
• Estático Diagramas de Entidad
• Dinámico Diagramas de Ensamblaje
• Cibernético Diagramas de Frecuencias
La integración de la información que recopilaremos de esta etapa del trabajo nos dará una visión
completa y precisa de los procesos lógicos más eficaces que se deberían llevar a cabo. Tendremos todos los
datos de especificación y diseño necesarios para poder luego administrar los procesos reales, donde ahora sí,
la capacidad limitada de los recursos obligará a realizar programas para la asignación de tareas y su
priorización, única forma de maximizar el resultado global de los procesos de la organización.
Dado que nuestra estrategia se basa en partir de las salidas (Output-oriented) trataremos de responder
a las siguientes preguntas:
• ¿Por dónde y cómo comenzar ?
• ¿Cómo saber cuándo hemos encontrado todas las salidas ?
• ¿Cómo saber si tenemos las salidas correctas ?

31
Comensaremos por determinar ¿Quién hace qué? en la organización y para esto utilizaremos la visión estática
mediante los diagramas de entidad.
Diagramas de entidad
Aquí el objetivo es obtener esa foto de la organización a que hacíamos referencia al hablar del problema de
la escala. Debemos obtener un gráfico de todas los intercambios entre áreas internas de la organización y
proveedores y clientes externos, sobre un determinado tema, como sumatoria de las visiones de cada uno de los
integrantes de la organización involucrados en el mismo. El proceso es eminentemente intuitivo y sistemático
permitiendo utilizar el mayor número de puntos de vista posible.
"Cuatro ojos ven mejor que dos" y un par por cada uno de nosotros, no les cuento, el secreto consiste en
poder integrar todas las visiones en una sola.
Es una visión estática de la realidad que sólo nos dice quien hace qué.
Diagrama de entidad individual a nivel del usuario
El primer paso es que cada usuario se coloque en el centro del universo en un círculo y dibuje
alrededor otros círculos -uno para cada uno de sus clientes y proveedores tanto internos como externos- ,
poniendo como título de la hoja el tema en estudio.
Cada círculo representa entonces una entidad que puede ser un área de la organización, una persona
determinada, un cliente externo, un proveedor externo. Luego deberá trazar flechas desde y hacia su círculo
central indicando sobre ellas, con un nombre claro para él, la transacción o intercambio a que hace referencia.
En este análisis se deben reflejar todas las transacciones del tema (proceso), en estudio, sean éstas
transferencia de productos, servicios, información, tanto manuales como automatizadas.
Se hará que el usuario vea a todas las entidades con las que se relaciona como proveedores y clientes
pensando: ¿Quién depende de mí para tal información y de quién dependo yo a la vez?.
El usuario deberá ser inducido para realizar este trabajo solo, sin la presencia de ningún analista.
¡Esto no es una entrevista!.
Esta inducción debe ser realizada en forma de charlas o seminarios en donde se presenten las tareas a
desarrollar y se remarque la importancia de la participación recíproca de los usuarios. La experiencia indica
que un usuario bien motivado no demora más de dos o tres horas en realizar su diagrama. Este proceso es
eminentemente intuitivo y no genera mayores dudas.
Estos diagramas serán mucho más completos y ricos en información que el obtenido en la mejor de las
entrevistas, que insumiría mayor cantidad de recursos y tiempo.
Notar que con una buena coordinación este proceso puede realizarse en paralelo con todos los usuarios,
acortando enormemente los tiempos del relevamiento.
En este proceso estamos buscando lo que hoy ocurre, o sea mostrar el estado actual de las cosas. Esto
no implica que luego implementemos informáticamente lo mismo.
Esta etapa de análisis tiene dos objetivos fundamentales: uno es el de permitir conocer realmente cual
es la magnitud del problema que estamos atacando y no olvidarnos de nada; el otro, menos visible pero no
menos importante, es conseguir el compromiso del usuario en el proceso, sin grandes dificultades. Ahora cada
uno querra mostrar todo lo que hace en su trabajo.
Los cambios que luego surgirán de la visión compartida serán discutidos entre todos, informáticos y
usuarios. A menudo los cambios serán realmente drásticos para los usuarios. Recordemos la pendiente de la
curva del avance convergente, pero ellos no tendrán dudas que los mismos los beneficiarán y serán ellos los
impulsores, haciendo posible el cambio. En esta etapa, es fundamental el apoyo de la dirección, sobre todo
para que aparezcan los tiempos necesarios para su realización, lo ideal es que la dirección participe en el
proceso, las presiones innecesarias generadas por la ansiedad desaparecen cuando se comprende lo que se esta
haciendo y se ven las reales dificultades encontradas.
Desarrollaremos como ejemplo un sistema de compras para ver todas las etapas de este proceso.
Veremos como obtener la especificación que permita la informatización del sistema de compras para una
empresa de operatoria tradicional. Recordar que estamos trabajando para resolver las necesidades del usuario,
el cliente de la aplicación. Por lo tanto el producto a obtener puede ser totalmente distinto para una
organización que esté trabajando con un sistema de compras Just In Time.

32
Primero se realizará una serie de reuniones con el objeto de inducir a los usuarios a trabajar en el
proceso de definición. De esta primera fase se podrán obtener un conjunto de gráficos que representan el punto
de vista que cada uno tiene sobre el tema en estudio. Por esto lo llamamos diagramas de entidad a nivel de
usuario.
T e m a : C O M P R A S
S e c to r: C O M P R A S
P ro ve e d o re s V a rio s
Pe d id o d e
Co tiza cio ne s Pe d id o
Co tiza ció n d e Co mp ra
Esta d o d e l P.Co mp ra
Ord e n d e Co m p ra
C o m p ra s
Pe d id o D e p ó sito
d e Co m pra
Ord e n d e Co m p ra R e p o rte
Esta d ístico
C ta s a P a g a r G e re n c ia
S e c to r: C U E N T A S A P A G A R
P ro ve e d o re s D e p ó sito
Fa ctura
Fa ctura N o ta d e R e ce p ció n
d e Ma te ria le s
C ta s a P a g a r
Factura
V a rio s
Ord e n
Ord e n d e Co m p ra d e Pa g o
T e so re ria
C o m p ra s

33
S e c to r : V A R IO S
(deptos. usuarios)
C o m p r a s C ta s . a P a g a r
P e d id o d e
Co m p ra
Info rm a ció n d e l Fa c tura
P e d id o d e Co m p ra
V a r io s
S e rvic io s M a te ria le s
M a te ria le s D e v o lucio ne s
Fa c tura
P r o v e e d o r e s D e p ó s ito
S e c to r : G E R E N C IA
D e p ó s ito
R e p o rte s E sta d ís tic o s
G e r e n c ia
R e p o rte s E s ta d ístic o s
C o m p ra s

34
Tema : COMPRAS
Sector : TESORERIA
Proveedores Estado
Adelanto
Impuestos
Pago
Tesoreria
Orden de Pago
Ctas a Pagar
Tema : COMPRAS
Sector: DEPOSITO
Compras
Varios
Proveedores Nota de Pedido de Compra
Recepción de Sol. Información
Materiales Ingreso de materiales
Ent. de
Factura Devoluciones Materiales
Depósito
Factura
Nota Recepción Materiales
Ctas a Pagar
Los diagramas reales deberán ser a mano alzada. No importa tanto la prolijidad, pero sí su contenido.

35
Diagrama de entidad combinado
En este punto tenemos un conjunto de diagramas a nivel del usuario, que no son otra cosa que fotos
individuales desde el punto de vista de cada uno de ellos, pero con cierto grado de superposición.
Notar que todas las relaciones internas a la organización están registradas por partida doble, ya que la entidad
del centro de un diagrama estará en la periferia de otro. Esto nos permite hacer un chequeo completo de las
transacciones internas y detectar la fallas de comunicación en algunos puntos, como así también actividades
que no agregan valor , como reclamos, archivos intermedios, etc.
Este diagrama tiene la virtud de mostrar rápida y cabalmente el estado de deformación funcional, que
normalmente se alcanza en una organización luego del proceso de crecimiento, originado por las dispares
fuerzas de poder entre sus áreas, fundamentalmente basadas en el comportamiento de cada uno de sus
responsables.
El problema para nosotros en este punto es que el número de transacciones para un determinado tema
es normalmente muy elevado para procesar manualmente.
Se volcará la información de los diagramas a nivel de usuario en una tabla como la siguiente:
Tipo | Partida | Llegada | Transacción | Proceso
Donde:
• Tipo : Indica si el cliente o proveedor es interno o externo al tema en estudio.
• Partida : Indica el área desde donde se origina la transacción o rol de partida.
• Llegada: Indica el área que recibe la transacción. Partida y Llegada definen el sentido de la
'flecha', es el rol encargado de su ejecución
• Transacción: El nombre que el usuario le da a la transacción, el cual no debe ser cambiado ,a
menos que genere ambigüedades.
• Proceso: El nombre del proceso o tema en estudio. Notar que se pueden atacar varios temas o
procesos a la vez.
Aquellos que conozcan las técnicas del JIT se sentirán tentados a colocar otra columna para indicar si la
transacción agrega o no valor; pero esto sólo serviría a los efectos documentales, porque muchas de estas
transacciones desaparecerán aún antes de profundizar en sus detalles. Recordar que estamos tratando de
trabajar en el mínimo operable y con el mínimo de recursos.
Luego veremos como obtenemos un proceso eficaz, armándolo directamente con las transacciones que sí
agregan valor y aquéllas que son estrictamente necesarias. Sobre éstas sí haremos un análisis completo.
De los diagramas precedentes se obtiene la siguiente tabla:

36
Tip. Partida LLegada Transacción Proceso
Ext Compras Proveedores Orden de Compra COMPRAS
Ext Proveedores Compras Cotización COMPRAS
Ext Compras Proveedores Pedido de cotización COMPRAS
Varios Compras Pedido de Compra COMPRAS
Compras Varios Estado del Pedido de Compra COMPRAS
Depósito Compras Pedido de Compra COMPRAS
Compras Gerencia Reporte estadístico COMPRAS
Compras Ctas a Pagar Orden de Compra COMPRAS
Ext Proveedores Ctas a Pagar Factura COMPRAS
Depósito Ctas a Pagar Factura COMPRAS
Depósito Ctas a Pagar Nota de Recepción de Materiales COMPRAS
Varios Ctas a Pagar Factura COMPRAS
Ctas a Pagar Tesoreria Orden de Pago COMPRAS
Compras Varios Información del Pedido de Compras COMPRAS
Depósito Varios Materiales COMPRAS
Varios Depósito Devoluciones COMPRAS
Ext Proveedores Varios Facturas COMPRAS
Ext Proveedores Varios Materiales COMPRAS
Depósito Gerencia Reporte estadístico COMPRAS
Ext Proveedores Varios Servicios COMPRAS
Ext Tesoreria Proveedores Pago COMPRAS
Ext Tesoreria Proveedores Adelanto COMPRAS
Ext Tesoreria Estado Impuestos COMPRAS
Ext Proveedores Depósito Materiales COMPRAS
Ext Proveedores Depósito Factura COMPRAS
Depósito Compras Nota de Recepción de Materiales COMPRAS
Varios Depósito Sol. Información Ingreso de materiales COMPRAS
Depósito Varios Ent. de materiales COMPRAS
Si ordenamos la tabla por tipo, partida, llegada y transacción podremos detectar rápidamente las
inconsistencias.
Nos quedarán las transacciones que tienen un único registro primero, por estar relacionadas con
proveedores o clientes externos. Luego aparecerán transacciones duplicadas, lo que implica que están correctas
ya que las dos áreas intervinientes las identifican por igual.

37
ok Compras Ctas a Pagar Orden de Compra COMPRAS
ok Compras Ctas a Pagar Orden de Compra COMPRAS
ok Compras Gerencia Reporte estadístico COMPRAS
ok Compras Gerencia Reporte estadístico COMPRAS
--> Compras Varios Estado del Pedido de Compra COMPRAS
--> Compras Varios Información del Pedido de Compras COMPRAS
ok Ctas a Pagar Tesoreria Orden de Pago COMPRAS
ok Ctas a Pagar Tesoreria Orden de Pago COMPRAS
--> Depósito Compras Nota de Recepción de Materiales COMPRAS
ok Depósito Compras Pedido de Compra COMPRAS
ok Depósito Compras Pedido de Compra COMPRAS
ok Depósito Ctas a Pagar Factura COMPRAS
ok Depósito Ctas a Pagar Factura COMPRAS
ok Depósito Ctas a Pagar Nota de Recepción de Materiales COMPRAS
ok Depósito Ctas a Pagar Nota de Recepción de Materiales COMPRAS
--> Depósito Gerencia Reporte estadístico COMPRAS
--> Depósito Varios Ent. de materiales COMPRAS
--> Depósito Varios Materiales COMPRAS
ok Varios Compras Pedido de Compra COMPRAS
ok Varios Compras Pedido de Compra COMPRAS
ok Varios Ctas a Pagar Factura COMPRAS
ok Varios Ctas a Pagar Factura COMPRAS
ok Varios Depósito Devoluciones COMPRAS
ok Varios Depósito Devoluciones COMPRAS
--> Varios Depósito Sol. Información Ingreso de materiales COMPRAS
El resto habrá que analizarlo. Los errores pueden ser tan simples como un problema de denominación
u olvido, hasta el real desconocimiento de que esa tarea debía hacerse.
Esto nos lleva a ajustar los diagramas con los usuarios correspondientes. Esta fase del proceso ya de
por sí está detectando las inconsistencias de la realidad, produciendo en algunos casos cambios y correcciones
sobre ésta por el sólo hecho de marcarlas y resolviendo algunos de los problemas.

38
Compras Varios Estado del Pedido de Compra COMPRAS
Depósito Compras Nota de Recepción de Materiales COMPRAS
Depósito Gerencia Reporte estadístico COMPRAS
Depósito Varios Ent. de materiales COMPRAS
Varios Depósito Sol. Información Ingreso de materiales COMPRAS
Una vez conseguido el cierre de todos contra todos, el analista podrá volcar toda la información en
diagrama combinado que será la foto de las transacciones reales que utiliza la organización en un determinado
tema.
Es una foto de 'Quien hace que' hoy dentro de la organización para un determinado tema. Es una foto
del estado actual; con ésta podremos luego medir luego los avances realizados al ir aplicando la metodología.
Notar que aquí el resultado no depende mayormente de la capacidad del analista, pero sí es directamente
proporcional a la participación de los usuarios.
Por simplicidad se han omitido tareas de aprobación de los pedidos de compra y la ordenes de
compra, suponiendo en este caso que son realizadas por el rol compras.

39
Diagrama combinado
(muestra el estado actual)
Materiales
Servicios Varios
facturas
Proveedores Pedido
Cotización Compra Estado Sol. inf. Ingreso
Orden Compra P.C. Materiales
P.Cotización Compras Devol.
N. Rec. Facturas
facturas Mat.
Materiales Pedido
de Compra Ent.Mat.
Pagos
Anticipos O. Compra
Depósito
Factura facturas Reporte
Tesoreria Esadistico
Impuesos
Gerencia
Estado Orden de Reporte
Pago N. Rec. Mat. Esadistico
Ctas. Pagar
Si englobamos ahora todo aquello que está dentro de la organización en una sola burbuja y
colocamos todas las transacciones con el exterior, simplificando aquéllas que están duplicadas, obtendremos el
diagrama de entidad a nivel de la aplicación.
Este análisis estático nos permite cambiar de nivel, subir hasta el tope, donde ahora con mayor
capacidad de comprensión que antes podremos encontrar los verdaderos condicionantes de nuestros sistema.
Diagrama de entidad a nivel de aplicación
El diagrama de entidad combinado muestra todo lo que se hace . La idea no es desarrollar un sistema
que haga lo mismo que ocurre hoy en la organización, sólo que automatizado y más rápido. Aquí debemos
determinar lo que es crítico, lo que es necesario porque agrega valor, lo que es menos variable.
En la etapa anterior se realizó un proceso de análisis. Ahora estamos haciendo una síntesis. De la
realidad estamos tratando de ver el bosque sin tener que mirar cada árbol.

40
Diagrama a nivel de aplicación
Pedido cotización
Proveedores
Cotización
Materiales
O.C.
Servicios
Recepción
Factura
Adelanto
Pago Compras
Empresa XX
Estado
Impuestos
Objetivos agrupados por secuencias
Grupo 1 Grupo 2 Grupo 3
1 Pedido Cotización 1 Adelantos 1 Impuestos
2 Cotización
3 Orden de Compra
4 Materiales
5 Servicios
6 Recepción
7 Factura
8 Pago
En este paso lo que definimos son los límites de la aplicación, dejando dentro de ellos todas las
entidades que la representan, implotándolas, dejando visibles los verdaderos objetivos -las transacciones con el
exterior- y ocultando deliberadamente la manera en que hoy se realizan.
Así aparecen los condicionantes, que en definitiva son los objetivos de nuestra aplicación.
Los Objetivos
Analicemos por un momento los objetivos así definidos y veremos que representan las relaciones de los
clientes y proveedores con la organización. Son todos esenciales y son los condicionantes de nuestro sistema.
Ahora debemos agruparlos en función de temas de mayor nivel (formación de embriones de los flujos del
proceso). En el ejemplo de trabajo se han definido tres grupos: uno de la compra normal ,otro de adelantos y un
tercero, de impuestos. Las transacciones así agrupadas se numeran secuencialmente en cada grupo. Este
proceso comienza a inducir así las principales líneas de flujo de nuestro caso de estudio.
Si la organización se encuentra en un proceso de Calidad total, este es el mejor momento para reunirse
con los clientes y proveedores externos para, en conjunto, definir de mutuo acuerdo la mejor manera de
relacionarse.
Notar que de esta relación surgen los objetivos sobre los que se apoyarán todos nuestros futuros desarrollos.
Todos los procesos dentro de la organización tratarán de minimizar el valor agregado no vendible y la mejor
manera de hacer esto es subordinando todos estos procesos a la relación con nuestros clientes externos.

41
Reingeniería de procesos
(El desarme)
Definición de los procesos
La etapa anterior ayuda a determinar las necesidades del cliente (el objetivo de nuestros procesos),
Ayuda porque nos muestra los objetivos actuales, al explicar el estado actual, mostrando su real complejidad.
Luego se utiliza el concepto de desarme, caminando hacia atrás desde las necesidades del cliente , etapa por
etapa, hasta alcanzar la etapa que implicaría la satisfacción del cliente , lo que cierra el lazo completo de
nuestro proceso.
Si bien el aprendizaje global sigue las etapas tradicionales, ya vistas, la estrategia de cada etapa no
lleva a un aprendizaje rápido de como se hacen hoy las cosas.
En esta etapa de desarme se utiliza el diagrama de línea de ensamblaje16, cuyo razonamiento es: ¿qué
necesito para conseguir este objetivo?. Ello permite ir descubriendo sólo las entradas (salidas de otras etapas)
y procesos necesarios. Aquí hay que rescatar que sólo lo necesario será identificado en esta etapa. Otra forma
de preguntar puede ser ¿Por qué hago esto?.
Esta etapa va descubriendo los procesos eficaces que necesitamos implementar para cumplir con las
necesidades de los clientes.
Notar que se produce una automática limpieza de procesos y etapas innecesarias, que se realizan por
condicionamiento de áreas y arrastres históricos y culturales.
Al desarmar comenzamos por la última transacción de cada proceso (última tarea de un lazo) por
ejemplo, el pago ¿Por qué pagamos? ¿Qué salidas debemos esperar y qué procesos debemos realizar para que
podamos concretar un pago?.
Este razonamiento nos permite de manera natural identificar tan sólo las causas y los procesos que
realmente son necesarios, para cumplir con los objetivos externos definidos.
El pensar desde el objetivo para atrás en una estrategia simple, rápida y eficaz. La usan los chicos
cuando naturalmente aprenden preguntando a todo ¿ y por qué ...?
En cada etapa será ejecutada una transacción, para poder hacerlo, el usuario deberá acreditar el rol
correspondiente. Para poder trabajar necesitará las entradas, de datos externos, otras fuentes de información,
como se muestra en este gráfico17.
Otras Fuentes de
Información
S I S T E M A
D atos I N F O R M A T I C O
E xternos
S IS T E M A D E
D E C I S I O N
E n tr a d a s S a l i d a s
T r a n s a c c i o n
Es importante notar que todo dato generado en una etapa anterior del proceso ya estará en el sistema
informático. Éste será una fuente de datos común a todas las áreas de la organización que la necesiten, esto
implica que no será necesario transferir documento de un área a otra para que este pueda continuar sus tareas.
El sistema informático conforma la memoria global de la organización permitiendo el flujo continuo de los
procesos.
16Nombre que deriva de la similitud con definir una linea de ensamblaje industrial
17 De Sintesis de Programación Logica J.D.Warnier

42
Diagrama de línea de Ensamblaje
Para desarrollar estos diagramas solo se debe pensar en entradas, salidas y cajas negras, comenzando
por la ultima salida y caminando hacia atrás hasta llegar a la primera entrada, notar que no estamos
definiendo aún el detalle del como, sólo buscamos los flujos mas eficaces para alcanzar el objetivo final. Esto es
verdadera reingeniería de los procesos de la organización
Veamos ahora los esquemas utilizados para su representación:
Caso de una etapa:
Input
Output +
Transacción
Input Transacción Output
¿Que necesito para conseguir este 'output'?
Caso de una serie de etapas secuenciales (un flujo):
input 1 out-input 2 output 3
Transac. A B
etapa 1
etapa 2 input 1
output 2 +
output 3 + Transaccion A
Transaccion B
Caso de unión de dos o mas flujos
En este caso puede ocurrir que se deban esperar (+) a que todas las entradas estén disponibles para
poder trabajar o que sean casos independientes (o), donde no hay que esperar ya que con cualquiera de las
entradas se puede trabajar.

43
Flujo M
input 1 out-input 2 output 3
Transac. A Transac. B
input a Transac. X out-input b
Flujo N
Flujo M
etapa 2 etapa 1
input 1
output 2 +
Transaccion A
+ / o
input a
output 3 output b +
Transaccion X
+
Transaccion B Flujo N
Si deben estar ambos ' + ' implica espera
Si con uno alcanza ' O' implica no hay espera
Notar que en cada transacción puede haber varias entradas necesarias pero hay una sola salida. Esta es
la diferencia de representación más importante con otras metodologías que muestran los flujos de datos. El ver
solo una salida por vez simplifica el enfoque y responde con certeza al ¿Por qué se hacen las cosas?.
Es así como se pueden visualizar los flujos lógicos de los procesos, de forma clara, correcta y entendible
por todos.
Los flujos son como ríos y afluentes. Lo que buscamos representar son los flujos de los procesos que
sobrepasan el nivel del individuo o persona, esto significa que requiera que se comunique con otros, no nos
importa aquí definir todos los 'procesos' necesarios para llevar adelante cada tarea que en este contexto están
vistos como transacciones.
Este es el punto de quiebre de nivel entre la administración de procesos, del director de orquesta y la
realización de las tareas,. el como de los ejecutantes.
Ahora razonando de izquierda a derecha podemos construir el diagrama de ensamblaje para
especificar los flujos del proceso de compras.

44
D ia g ra m a d e lín e a d e E n s a m b la j e
( fl u j o s d e l p r o c e s o )
F l u j o I m p u e s t o s
1 1
Pedido de
Fecha pago 2 Compra
Impuestos Impuestos F l u j o P A G O Pedido +
Pagados + Cotización
+ C o m p r a s
T e s o r e r i a 3 Cotización Tarea de
Tarea de calculo y Orden de + Pedido de
Pago impuestos Compra C o m p r a s Cotización
+ Tarea de
4 Mercaderia confección y envio
Nota Recep. de Orden Compra
Materiales +
E t a p a D e p ó s i to
5 Tarea de
Ó Recepcion Mat.
Servicio
Orden de Pago Nota Recep. de +
Servicio V a r i o s
Pago a + Tarea de
Proveedores + Recepcion Serv.
Factura del 1
T e s o r e r i a Proveedor F l u j o S E R V I C I O S
Tarea de +
Pago C ta s . a P a g a r
Tarea de R ol encargado
Recepcion y de la ejecucion de la
control de la etapa
factura
F l u j o A d e l a n t o s 1
Solicitud de
anticipo por el
2 proveedor
Orden de Pago +
Anticipo
Pago de + C ta s . a P a g a r
Anticipo Tarea de otorgar
T e s o r e r i a anticipos
Tarea de genera O.Pago
Pago de
Anticipos
D i r e c c i o n d e l r a z o n a m i e n t o
Debemos remarcar que este diagrama presenta el caso ideal al cual debemos tender.
Podemos pensar a cada llave '{' como un filtro que no deja pasar nada más que lo que realmente cumple con
las especificaciones del proceso.
Armaremos dos nuevas tablas para registrar los nuevo logros en nuestra especificación de los
procesos.
La primera será una tabla para representar el proceso, con sus flujos y etapas ordenadas:
Tabla de flujo de procesos
Proceso | Flujo | Transacción | Orden | Rol
Donde:
• Proceso: Es el conjunto de todos los flujos necesarios para desarrollar un producto o servicio.
• Flujo: Secuencia de pasos, etapas o transacciones.
• Transacción: Es una etapa del proceso, que se debe cumplir en forma completa. De lo contrario
será desechada.
• Orden: Indica la secuencia de las transacciones en el flujo.
• Rol: Es la autorización que se necesita para poder ejecutar una transacción determinada.

45
Veamos como queda para nuestro ejemplo. Notemos que las transacciones toman el nombre de su salida.
T a b la d e flu jo s d e p ro c e s o s
P ro c e s o F lu jo T ra n s a c c ió n O rd e n R o l
COMPRAS Pago P e d id o d e C o tiz a c ió n 1 compras
COMPRAS Pago O rd e n d e C o m p ra 2 compras
COMPRAS Pago N o ta R e c e p c io n M a te ria le s 3 deposito
COMPRAS Pago O rd e n d e P a g o 4 Ctas. a Pagar
COMPRAS Pago P a g o 5 tesoreria
COMPRAS Servicio R e c e p c io n S e r v ic io 1 varios
COMPRAS Anticipos O rd e n d e p a g o A n tic ip o s 1 Ctas. a Pagar
COMPRAS Anticipos P a g o d e A n tic ip o s 2 tesoreria
COMPRAS Impuestos P a g o d e Im p u e s to s 1 tesoreria
Esta tabla sólo muestra los tramos de flujo que conforman los procesos lógicos, definidos mediante el
diagrama de ensamblaje.
Las salidas de una etapa o transacción pueden servir como entradas para la siguiente en la cadena.
Para reflejar estas relaciones que son bien visibles en nuestro diagrama de ensamblaje crearemos una
segunda tabla, dependiente de la anterior, que servirá para indicar que entradas necesita cada una de estas
transacciones.
Tabla entradas de la transacción
Proceso | Flujo | Transacción | Entrada | Relación | Dependencia
Donde:
• Proceso: Es el conjunto de todos los flujos necesarios para desarrollar un producto o servicio.
• Flujo: Secuencia de pasos, etapas o transacciones.
• Transacción: Es una etapa del proceso, que se debe cumplir en forma completa. De lo contrario
será desechada.
• Entrada: Indica el nombre de la transacción que produce, como salida, la entrada necesaria.
• Relación: La relación de concurrencia entre los inputs, que pueden ser:
input dependiente (deben estar todos presentes)
imputs alternativos (al menos uno de ellos debe estar presente).
• Dependencia: La relación entre los inputs y algún sujeto que le da continuidad al flujo, los inputs
puede ser:
sujeto dependiente (solo se unen inputs del mismo sujeto)
intercambiables (basta que haya una pieza de cada una).
T a b la e n tra d a s d e la tra n s a c c ió n
P ro c e s o F lu jo T r a n s a c c ió n E n tra d a R e l D e p
COMPRAS Pago Pedido de Cotización P e d id o d e C o m p ra dep libre
COMPRAS Pago Orden de Compra P e d id o d e C o tiz a c ió n dep proveedor
COMPRAS Pago Orden de Compra C o tiz a c ió n dep proveedor
COMPRAS Pago Nota Recepcion Mat. O rd e n d e C o m p ra dep proveedor
COMPRAS Pago Nota Recepcion Mat. M a te r ia le s dep proveed.or
COMPRAS Pago Orden de Pago N o ta R e c e p c io n M a t. indep proveedor
COMPRAS Pago Orden de Pago R e c e p c io n S e r v ic io indep proveedor
COMPRAS Pago Orden de Pago F a c tu ra dep proveedor
COMPRAS Pago Pago O rd e n d e P a g o dep proveedor
COMPRAS Servicio Recepcion Servicio S e rv ic io dep proveedor
COMPRAS Anticipos Orden pago Anticipos S o lic itu d a n tic ip o dep proveedor
COMPRAS Anticipos Pago de Anticipos O rd e n p a g o A n tic ip o sdep proveedor
COMPRAS Impuestos Pago de Impuestos F e c h a s V e n c im ie n to dep acreedor

46
Esta tabla permite el empalme de los tramos, al indicar cuales son las entradas necesarias para poder
continuar con el flujo. Notar que para la transacción Orden de Pago se necesita como entrada Recepción
Servicio que pertenece a otro tramo de flujo.
Al completarse una transacción, entrando con su nombre en la columna "entrada" podemos encontrar
rápidamente cual el la siguiente etapa.
Una forma de ver el avance
Con el solo objetivo de visualizar la mejora obtenida con la técnica de desarme y las ventajas de
utilizar un sistema informático, podemos redefinir nuestro diagrama de entidades, para ver como queda el "
¿quién hace qué? ".
En este nuevo esquema sólo las relaciones necesarias quedarán visibles, En un primer paso hacemos
desaparecer las actividades que estaban duplicadas en más de un sector18, que generan, además del trabajo
redundante, trabajo extra de control.
Haciéndolo en dos etapas nos quedaría primero:
D i a g ra m a c o m b in a d o c o r r e g id o
(primer paso)
Se rvic io s V a r io s
P r o v e e d o r e s Re c e p .Se rvic io Pe d id o
Co tizac ió n Co m p ra
O rd e n Co m p ra Re c e p .
P.Co tizac ió n C o m p r a s Servicio De vo l.
N .Re c . M at.
M ate riale s Pe d id o
d e Co m p ra E n t.M at.
Pag o s
A n tic ip o s O . Co m p ra
D e p ó s ito
F ac tu ra Sol. Ant.
T e s o r e r ia
Im p u e so s
E s ta d o O rd e n d e
Pag o N . Re c e p . M at.
C ta s . P a g a r
Las actividades de pasaje de documentos e informes entre sectores, requisito para poder operar, ahora
serán innecesarios, ya que en el nuevo esquema la información estará directamente disponible a las
transacciones.
Los sectores intervinientes se limitarán a desarrollar sus tareas operativas en línea, de acuerdo a la
demanda, generando así todos los datos necesarios para ellos y para los otros, que continuarán con los
procesos.
Los informes se redefinirán en función de la nueva mecánica. Este punto no lo atacamos por ahora,
pero se puede asegurar que luego de implementar la faz operativa desde todos los puntos de vista no faltarán
datos ni para el control preventivo, ni para los informes periódicos, ni para la toma de decisiones a mediano y
largo plazo. Esto se debe básicamente a que se está trabajando con las relaciones cliente proveedor, relaciones
sobre las cuales se requerirá información y al habernos basado en todos los enfoques, hemos tenido que
utilizar el nivel de detalle necesario para soportar todas las transacciones.
18 Suponiendo que es físicamente posible centralizar esas funciones

47
Si ahora ocultamos todas las transferencias de información que se harán mediante el sistema
informático, prácticamente quedan las relaciones entre áreas de la empresa y los proveedores externos. Este
ocultamiento muestra como la complejidad operativa es transferida a los sistemas informáticos.
Realizando el ocultamiento de las relaciones que implementa el sistema informático, la oficina sin
papeles ya se puede visualizar.
D i a g r a m a c o m b i n a d o c o r r e g i d o
(Lo que operara el conciente de la organización)
S e rvic io s V a r i o s
P r o v e e d o r e s R e c e p .
C o tizac ió n Servicio
O rd e n C o m p ra
P .C o tizac ió n C o m p r a s D e vo l.
N .R e c . M at.
M ate riale s
E n t.M at.
P ag o s
A n tic ip o s
D e p ó s i to
F ac tu ra S o l. A n t.
T e s o r e r i a
Im p u e so s
E s ta d o
C ta s . P a g a r

48
Los problemas y señales de la realidad
Se debe analizar que hacer cuando las cosas no van como lo pensamos. Podríamos utilizar
sistemáticamente la ley de Murphy preguntando ¿Qué pasa si esto sale mal? y ¿Qué pasa si aquello también
falla? tantas veces como se crea necesario19 y crear nuevos flujos para manejar esas situaciones.
Pero es mejor pensar cuales son las causas que pueden producir esos problemas y analizar como
prevenirlas para poder filtrarlas en etapas tempranas. Por otra parte si trabajamos con sistemas que funcionen
con flujos rápidos respondiendo a demanda con buen cumplimiento y no adelantándose a ella, muchos de los
problemas que se deben soportar por trabajar con lotes (alto inventario de ocurrencias), desaparecerán. Es más
económico definir bien los procesos y operarlos preventivamente que crear sistemas que atajen todos los casos
erróneos pero al mismo tiempo permitan que estos sigan ocurriendo.
Básicamente debemos analizar los ciclos de los flujos y tener en cuenta como se retroalimentarán los
mismos ante las señales externas sobre problemas en las salidas producidas.
etapa 1
etapa 2 input 1
output 2 +
output 3 + Transaccion A
Transaccion B
Feedback 1
Feedback 2
los flujos en proceso
Las señales de la realidad retroalimentan y condicionan
19En 'Structures Requirements Definition' de Ken Orr se puede ver como tratar en los flujos de
proceso para los casos de fallas.

49
Diagrama de ciclos o frecuencias
Ya sabemos que hace cada uno y por que lo hace, mostrando la secuencia. Sólo resta ver con que
frecuencia se realizan estos procesos y que rango de tiempos debemos respetar para cumplir con los
compromisos.
La demanda actual o estimada nos permite establecer:
tiempos mínimos LEI (límite de especificación inferior)
tiempos máximos LES (límite de especificación superior)
Esto para cada una de las etapas de los procesos definidos. Estos tiempos deben incluir todas las
componentes como: tiempo de preparación, tiempo de espera, tiempo en cola, tiempo de ejecución.
El tiempo total de un ciclo debe ser compatible con los requerimientos de la demanda.
Para guardar esta información agregamos a la tabla de procesos dos columnas más:
Tabla de flujo de procesos
Proceso | Flujo | Transacción | Orden | Rol | LES | LEI
Donde:
• LES: Límite de especificación superior de tiempo de la etapa.
• LEI: Límite de especificación inferior de tiempo de la etapa.
Esta información es luego usada como referencia al trabajar, permitiendo compararla con los límites de
control superior e inferior, que pueden realmente cumplir los procesos reales.
Debemos agregar en la tabla Entradas de la transacción, para las etapas que lo requieran, la
retroalimentación necesaria (otras entradas de la transacción), para permitir la posible detención a tiempo de
los procesos erróneos o disparar las acciones correctivas. Esta es la forma de implementar las señales externas.
Este mecanismo también se utilizará en el tiempo de ejecución de los procesos reales para ajustar el
sincronismo entre los flujos, recurriendo a señales que marquen el paso cuando y donde sea necesario para
generar una ejecución equilibrada y sincronizada.
Se muestra a continuación el diagrama de los ciclos para describir la frecuencia en que se realizan las
transacciones normales.
P r in c ip io d e M e s I m p u e s t o s
P r in c ip io d e l d ía A n a l i s i s d e c o t i z a c i o n e s
P e d i d o d e C o t i z a c i ó n
L l e g a d a d e M a t e r i a l e s
R e c e p c i ó n d e M a t e r i a l e s
M e s e s D ía s
(M ) (D ) R e c e p c i ó n d e S e r v i c i o s
F a c t u r a s
P a g o s
A d e l a n t o s
F in d e l d ía
F in d e M e s R e p o r t e E s t a d í s t i c o
Recordamos que estamos trabajando en un proceso continuo, donde la mínima unidad a definir,
analizar, desarrollar e implementar es una transacción.
Esto implica que definido el esquema general se podrá implementar transacción por transacción. Lo
ideal es comenzar también por la última y caminar para atrás, así no se generarán pasos innecesarios que
luego habrá que eliminar produciendo pérdidas en el esfuerzo realizado.

50
La documentación obtenida en esta etapa contiene todo lo necesario para que un directivo pueda
administrar la complejidad de detalle.
Notar que en los tres tipos de diagramas se muestra al mismo proceso desde tres ángulos
completamente distintos. En el diagrama Entidad con una visión estática; en el diagrama de Línea de ensamble
con una visión dinámica y en los diagramas de Frecuencias con una visión cibernética. Todo lo que muestran
es como se interrelacionan, en qué secuencia, y con qué frecuencia. Todo lo que se busca aquí es conseguir la
real sincronización de los procesos sin preocuparnos, por el momento, de como se realiza cada una de las
tareas o transacciones que los forman.
La información de los procesos obtenida en esta etapa que se fue volcando a un esquema de tablas,
permitirá luego soportar la administración de todos los procesos reales de la organización ya sea en forma
manual o con soporte computacional, si la complejidad así lo requiere.

51
Resumen
En la definición de los requerimientos se utilizan herramientas de representación gráfica como:
• Diagramas de entidad (entity diagrams) que ayudan para definir el contexto del sistema dando una visión
estática de los eventos o transacciones entre las distintas áreas de la empresa y las entidades externas, o
sea las relaciones cliente-proveedor , tanto internas como externas.
Responden a la pregunta, ¿Quién hace qué?.
• Diagramas de circuitos dinámicos (assembly line diagrams) para definir los flujos de procesos mínimos
que cumplen con los requisitos menos variables o condicionantes, produciendo circuitos eficaces en su
definición. Esta es una visión dinámica del proceso que es recorrida para atrás.
Responden a la pregunta ¿Por qué se hace?.
• Diagramas cíclicos de frecuencias que definen los procedimientos operativos con sus frecuencias
asociadas y que, en conjunto, permiten tener un control del sincronismo de los procesos. Es una visión
cibernética del proceso.
Responden a la pregunta ¿Cuándo se hace?.
De la suma de estas tres fases se obtiene la definición de los requisitos que debe cumplir el sistema para
asegurar la sincronización de todas sus partes componentes.

52
Definición de la estructura de Información
Introducción
El objetivo de esta etapa es definir una estructura de información que permita soportar todas las
transacciones que se realicen en la organización.
Todas las transacciones serán independientes unas de otras teniendo por único vinculo los datos de esta
estructura.
Cada transacción se debería poder poner o sacar, sin afectar al resto y cada una podrá ser implementada
de distintas formas: manual, automatizada, implementada con distintas herramientas o lenguajes, en línea o con
transferencia de información diferida, pero todas perfectamente sincronizada según lo fijen los requerimientos
de la etapa anterior.
Otra característica fundamental es que la estructura de información final resultante de la implementación
de los distintos módulos o sistemas, debería ser la misma, independientemente del orden de implementación de
las transacciones, orden que será fijado por las necesidades prioritarias. Este punto es fundamental para
permitir nuestro seguro transito por curva de avance convergente.
Es como si la organización comprara ficheros para carpetas colgantes, a cada cajón le pusiera el nombre
de los temas sobre los que la organización establece relaciones cliente-proveedor, luego colocaría carpetas en
cada uno de ellos para guardar los datos de sobre ese tema. Entendiendo que una unidad o área de la empresa
puede ser considerada como una empresa distinta, cada una en relación con terceros, proveedores o clientes de
servicios o productos, en este esquema habrá 'carpetas' para guardar datos sobre la empresa, datos de los
terceros con los que se relacionan, su entorno, datos del producto o servicio que brindan y datos de cómo
concretan ese intercambio.
Ante la necesidad de implementar alguna transacción, esta deberá ser desarmada en sus datos
componentes. Luego se colocaran estos datos en las 'carpetas' correspondientes en forma de tablas. Siempre se
encontrará una base para cada tabla y una tabla para cada dato.
Ya que todos los temas de la organización estarán cubiertos, podemos asegurar que habrá:
Un lugar para cada dato y cada dato en su lugar.
Las tablas así obtenidas no diferirán en nada de las tablas normalizadas que resultarían de un proceso
de análisis mediante los diagramas Entidad-Relación, solo cambia la forma de llegar a ellas y en su agrupación
y clasificación.
Podría hacerse una analogía, de esta forma de definir las estructuras de información, con la
programación estructurada y los modelos entidad relación con la programación libre con el famoso 'goto', en el
modelo entidad relación, el razonamiento debe seguir un circuito y flujo, al igual que en la programación libre,
en la estructurada en cambio, el razonamiento es lateral, se observan estructuras que gobiernan el problema y
si se quiere de estas se puede derivar el flujo del proceso también. El punto de vista de una y otra es totalmente
distinto uno es global y el otro local. Lo mismo ocurre con los esquemas de representación de las tablas y sus
relaciones.
Es común que las tablas de un modelo de datos deban ser normalizadas para asegurar consistencia y
evitar redundancias, Este proceso de normalización lo podríamos asimilar a un control de calidad. En esta
metodología no se normaliza, curiosamente, las tablas de las bases de datos surgen desde su concepción como
tablas de bases de datos relacionales normalizadas. Característica distintiva de un proceso de calidad total.
Imagínese teniendo que trabajar y mantener modelos de datos con diagramas entidad relación que soporten
todas las transacciones de la organización con cientos o miles de tablas, tratando de implementar nuevos
procesos sin perder el control, evitando la generación de redundancias. No es tarea fácil.
Por otro lado tenemos estructuras de clasificación estándares que responden al modelo empresa-
cliente o empresa-proveedor.
Se puede asegurar que no existen datos que no puedan ser clasificados con éste modelo. Si no
encuentra la forma de hacerlo es porque no lo ha comprendido acabadamente. Esto es lo mismo que nos
ocurría en nuestros primeros pasos por la programación estructurada; aprecia inevitable tener que usar un
'goto' en algunos casos, pero solo era por falta de entrenamiento y capacidad de ver la solución.
La estabilidad de este modelo de representación de datos, antes los cambios externos de la realidad, sólo
confirman que la estructura que representan permanece constante no importa como funcionen hoy y como
funcionarán mañana las transacciones entre clientes y proveedores.

53
LCS (Logical Construction of Systems)
La forma de realizar lo dicho en la introducción anterior es utilizar técnicas basadas en los principios
definidos por J.D.Warnier en su LCS construcción lógica de sistemas20.
Este enfoque introducido por Warnier tiene las siguientes características distintivas:
• Las tablas son clasificadas por los temas que el usuario ve o maneja, formando bases de datos lógicas. Este
primer gran agrupamiento de tablas que están fuertemente relacionadas. Podemos decir que existe una
base de datos lógica para soportar cada lazo de proceso que la organización mantiene con un tercero, sea
este cliente o proveedor.
• En cada base de datos lógica, las tablas que representan entidades reales se agrupan de acuerdo al rol que
dicha entidad juega en el modelo empresa-cliente o empresa-proveedor.
Datos de: empresa, terceros, objeto-intercambio, intercambio.
• Esta forma de representación elimina las relaciones muchos a muchos que son producto de ver
simultáneamente las relaciones de la empresa con sus cliente y proveedores.
• Las salidas solicitadas por los usuarios se irán desarmando, dato por dato en este esquema de
clasificación, las tablas así definidas casi mecánicamente, surgirán como tablas normalizadas. No será
necesario normalizarlas.
• La estructura de información que se obtiene permite soportar todos los puntos de vista que tienen los
distintos usuarios del proceso, conformando al mismo tiempo un mecanismo para evitar omisiones o
generar redundancias.
Las Bases de Datos Lógicas
Prácticamente se transcribe el planteo que realiza Warnier, por ser fundamental para entender los
principios en que se basa la definición de las bases de datos lógicas que soportan todos los datos de una
organización
Warnier establece dos leyes:
1ra. ley: Todo conjunto de datos debe ser rigurosamente definido por comprensión. Así todo elemento puede,
permanentemente, ser identificado como perteneciente o no al conjunto.
2da. ley: El referencial de todo conjunto de datos sobre el cual se trabaja debe estar definido.
Esta leyes nos ayudan a definir el conjunto de bases lógicas.
Al definir en una organización cada uno de los lazos con su entorno, se hace posible definir el conjunto B
(Bases de datos de la Empresa); esto define el referencial (2da. ley). Recordar que debemos minimizar el valor
agregado no vendible, lo que se puede traducir que trataremos de minimizar las actividades internas que no
tengan como objetivo satisfacer las relaciones externas.
Ahora es necesario definir por comprensión el conjunto B (1ra. ley).
B = { x/x es una base de datos de la empresa E }
Definimos ahora las características del elemento x:
Una base x es un conjunto de datos a tratar que comprende un subconjunto de datos que conciernen a la
empresa, así como los datos que conciernen a un conjunto de terceros que están en relación con la empresa,
sus intercambios con la empresa y el objeto de estos intercambios.
Es importante hacer notar que la definición de la bases de datos lógicas es realizada antes de
comenzar a trabajar con las transacciones. Lo que estamos definiendo aquí son los continentes, luego al
analizar una a una las transacciones iremos definiendo los contenidos.
20 Basado en 'Práctica de la construcción de un conjunto de datos' J.D.Warnier

54
Muchas bases pueden permanecer vacías hasta tanto analicemos alguna transacción que necesite datos
de ella.
Analicemos por un momento un conjunto de áreas o secciones de una empresa { a, b, c, d, e} , las podemos
clasificar como proveedores de productos o servicios y también como clientes de la empresa. Un área
proveedora se corresponde con un área cliente cuando es capaz de proveerla de productos o servicios.
En la siguiente figura se representa estas relaciones. Como podemos ver se trata de un típico caso de
relación muchos contra muchos.
P r o v e e d o r e s C lie n te s
a a
b b
c c
d d
e e
Cuando desarrollamos el sistema de costos de una organización nos encontramos con un problema de
estas características.
Para poder romper esta relación, muchos contra muchos, necesitamos hacer aparecer un nuevo
conjunto que permita generar relaciones muchos a uno o sea aplicación de conjuntos.
Para generar una aplicación entre los conjuntos, hacemos aparecer nuevo conjunto E (la Empresa). O
sea todos son proveedores de la Empresa y todos son clientes de la Empresa.
Estos clientes y proveedores podrán ser clasificados internos o externos a la organización.
Podemos armar un diagrama como el siguiente:
C lie n te s E m p r e s a P r o v e e d o r e s
E x te r n o s E x te r n o s
C 1 P 1
C 2 P 2
C 3 P 3
C 4 P 4
a a
b b
c c
d d
e e
C lie n te s P ro v e e d o r e s
In te r n o s In te r n o s
La subdivisión en clientes y proveedores impide la aparición de la relación muchos contra muchos.
En la realidad los productos o servicios van directamente de un área proveedora a la otra cliente.
En los datos los proveedores registran (facturan) contra la Empresa que es su único cliente y los cliente
registran (son facturados) por la empresa que es su único proveedor.

55
Esto no es otra cosa que una aplicación del principio de la contabilidad de registro por partida doble a
la clasificación de los datos de una organización.
Si rotamos el diagrama anterior obtendremos la definición de por lo menos los dos primeros niveles del
siguiente cuadro.
Este es el conjunto de bases de datos lógicas que necesitamos para soportar toda la información de la
organización:
P e r s o n a l
I n t e r n o s D e p a r t a m e n t o s
S u c u r s a l e s
D a t o s d e
P r o v e e d o r e s
E x t e r n o s M a t . P r i m a s
I n s u m o s
O t r o s
B A S E S
D E
D A T O S
P e r s o n a l
I n t e r n o s D e p a r t a m e n t o s
S u c u r s a l e s
D a t o s d e
C l i e n t e s
E x t e r n o s P r o d u c t o s
S e r v i c i o s
O t r o s
Cada una de las base de datos esta soportando la información del siguiente modelo de relación
T E R C E R O
Pedido
Entrega
Facturación
Liquidación
E M P R E S A
Por lo tanto necesitamos una estructura de 'carpetas' como esta:

56
D a t o s d e l a E m p r e s a
D a t o s d e T e r c e r o s
O b j e t o d e l I n t e r c a m b i o
U n a B a s e
d e D a t o s
P e d i d o
I n t e r c a m b i o E n t r e g a
F a c t u r a c i ó n
L i q u i d a c i ó n
Por ejemplo la base de datos proveedor-interno-personal sería la encargada de registrar toda la
información de un sistema de liquidación de sueldos:
• En la carpeta datos de la empresa figuraran las tablas con los datos legales de la empresa, números de
impuestos, jubilación etc.
• En datos de terceros estará el maestro del personal.
• En Objeto del intercambio estarán los montos básicos por categoría, conceptos adicionales etc.
• El Pedido es muy probable que quede vacío, amenos que tenga un sistema que pague por tareas
cumplidas, que habrá que pedir.
• En Entrega se guardan los datos de la asistencia del personal.
• La Facturación también vacío en este caso.
• En Liquidación se guardan los datos de liquidación de sueldos.
Piense ahora por un momento que sistema actualmente en uso no puede volcar, aún en forma diferida, pero
con la frecuencia que fija la especificación, sus datos en este esquema de tablas para que otras funciones quizás
de costos, quizás de cuadros para toma de decisiones, se alimenten de ella. Si todo esta en línea mejor, pero si
no lo esta igual podemos trabajar sincronizadamente con el modelo.

57
Resumen
La estructura de información debe soportar todas las relaciones cliente proveedor, por lo tanto, para tener
una estructura de información estable, la clasificación de las bases de datos lógicas deben reflejarlas.
Cada base de datos soportará la relación de la organización y un tercero que puede ser: cliente o proveedor,
interno o externo.
Entonces cada base tendrá un conjunto de datos que conciernen a la empresa, un conjunto de datos sobre los
terceros que están en relación con ella, sus intercambios con la empresa y el objeto de estos intercambios.
Esto permite crear un modelo de datos que se va completando en forma continua, a medida que se
implementan nuevas transacciones según las prioridades naturales de la organización.
Este enfoque soporta todos los puntos de vista que pueden tener los distintos usuarios sobre un tema,
independizando la estructura de información del orden en que se implementen las transacciones.

58
Diseño de las transacciones
Matrizado de las etapas
En este punto ya tenemos definidos los procesos lógicos de los temas en estudio, procesos que han sido
depurados y simplificados a partir de los objetivos establecidos, dándonos las etapas mínimas necesarias para
cumplir con los mismos. Hasta ahora no nos preocupamos más que por definir lo que debería tardar cada
etapa.
Haremos un cambio de nivel en el proceso de especificación. En todo lo anterior nos ocupábamos por todo
lo que pasaba afuera de la etapas, mirándolas como cajas negras y tratando de sincronizarlas en un nivel
lógico. Ahora comenzamos a penetrar dentro de la caja negra, para perfilar que hace falta para producir los
acuerdos externos ya fijados.
Utilizamos las técnicas de matrizado de Calidad Total. Esto facilitará luego la definición de las
transacciones informáticas que son realmente necesarias.
En cada llave '{' , ó sea cada etapa de nuestro diagrama de ensamblaje, podemos realizar una matriz.
El razonamiento es también desde el objetivo (satisfacer la necesidad del cliente de la etapa), hacia
atrás preguntándonos:
¿Qué métodos necesito aplicar para conseguir este objetivo?
¿Qué recurso humano necesito para conseguir este objetivo?
¿Qué equipos necesito para conseguir este objetivo?
¿Qué materiales necesito para conseguir este objetivo?
¿Qué información de contexto necesito para conseguir este objetivo?
Esto nos permite comenzar a definir los requerimientos físicos de nuestro proceso. Hasta ahora lo que
definimos fueron los flujos de proceso lógicos donde se supone capacidad de proceso ilimitada.
Puede ocurrir que una etapa requiera utilizar todo lo visto hasta ahora, para encontrar subetapas. En este caso
repetir el proceso.
Luego del matrizado tendremos un perfil muy completo de cada etapa.
El proceso ideal es comenzar el matrizado también por la última etapa. De esta forma estamos
realmente subordinando todos las etapas de nuestro proceso a los requerimientos del cliente. Si hacemos así,
cada matriz dejará perfectamente establecido los requisitos a sus proveedores, ya sean externos o internos de la
etapa anterior. El camino es desde el cliente hacia el proveedor.
Esto también fija las bases de clasificación y cuantificación para poder definir un presupuesto por
proceso y posteriormente utilizar análisis de costos basados en la actividad, donde se reemplazan los
tradicionales centros de costo, que se ajustan al esquema tradicional de áreas, por el costeo de los procesos.
Especificación de la transacción
Entramos ahora a atacar el ¿Cómo se hacen las cosas?. Para este paso, debemos tomar el matrizado
realizado para cada etapa de nuestro proceso y definir que partes es necesario informatizar.
Es claro que el grado de profundidad necesario para especificar una transacción dependerá, en parte,
de cuanto del trabajo común de la misma se encuentre soportado por servidores. Si la transacción esta
soportada por un servidor de bases de datos, con respecto al manejo de datos, sólo se deberá definir el criterio
de pertenencia de los mismos ( por ejemplo en SQL) sin tener que preocuparnos en como se hará para
recuperarlos o guardarlos. Lo mismo ocurre con otras tareas que se pueden descargar en servidores 'ad hoc',
como puede ser un servidor contable.
Por lo tanto, mucho del trabajo común y rutinario que se realizan en las transacciones se traslada a los
servidores. Siendo así, sólo nos resta especificar lo distinto, lo diferente, que caracteriza a la transacción en
estudio y parametrizar el resto para los servidores.
Aquí el usuario vuelve a tener un papel protagónico al definir en detalle la salida que debe producir su
etapa (hasta ahora sólo conocida por su nombre). Esto implica dibujar formularios, pantallas, reportes y
cuadros de decisión. Todo esto, desde el punto de vista de las necesidades operativas del usuario. Este material
es tomado por los informáticos que lo desarman dato por dato y lo ubican en el modelo de bases de datos,
establecido previamente, comenzando a definir así la tablas lógicas que formarán la estructura de información.
Estamos utilizando aquí métodos como el de Warnier, que parte del objetivo de la transacción y a
partir de éste definen el esquema estructurado de control requerido.

59
Este tipo de enfoque tiene varias ventajas como:
• Permitir ver si el planteo es correcto, es decir, si no nos estamos olvidando de algún caso o
alternativa.
• Ser entendible por los usuarios en forma intuitiva.
• Producir especificaciones de programas bien estructurados
Si juntamos ahora estos algoritmos y las tablas definidas para soportarlos, tendremos la especificación
de una de nuestras muchas transacciones. Si está bien hecha un programador debería poder implementarla en
un lenguaje o herramienta determinado, sin mayores consultas a los analistas. El programador deberá cumplir
con las especificaciones y no apartarse de ellas, ni que hablar de inventar mejores soluciones, ya que estas
serían eminentemente locales, Tan sólo con cumplir con la especificación estará haciendo un excelente trabajo.
Notar que las transacciones sólo se comunican mediante la información de las bases de datos. Por lo tanto,
mientras se cumplan las especificaciones, muchos programadores podrán trabajar en paralelo, potencialmente
tantos como transacciones especificadas tengamos. Aquí el cuello de botella es la tarea de especificar y no la
de programar.
En los esquemas de desarrollo tradicional es bastante complejo coordinar un gran número de
programadores, aquí no.
Lo anterior no invalida el utilizar cualquier método y herramienta para desarrollar las transacciones.
Este es el campo más desarrollado de la informática y por lo tanto debemos aprovechar todas las soluciones
existentes.
Notar que mientras cumplamos con los standares de acceso a la información, cualquier módulo, no importa
como ni en que lenguaje este hecho, podrá trabajar en línea en nuestro 'sistema organización'. Si no cumpliera
con el standard, tendremos aún la posibilidad de exportar e importar información desde y hacia nuestra base de
datos con la frecuencia especificada.
Una transacción puede ser tan sofisticada que requiera de un sistema de soft de varios cientos de miles
de dólares, pero para que sus salidas sean realmente efectivas, deben subordinarse sincronizadamente al resto
del proceso.
Esta forma de trabajar permite cambiar radicalmente el desarrollo de los sistemas. Ahora podemos
especificar y programar partes muy pequeñas, como una sola transacción o un grupo de ellas, según las
prioridades del proceso lo requieran. Estas podrán ser implementadas rápidamente y le permitirán a los
informáticos y usuarios ver que tan bien se están comunicando, o sea que grado de calidad tienen las
especificaciones. Esto permitirá, en caso de diferencias, realizar los ajustes necesarios, aún antes de que otras
transacciones sean desarrolladas. Si el sistema hubiera sido desarrollado todo completo, cualquier error de
interpretación estaría propagado por todas sus partes. Esta argumentación suena muy parecida a las ventajas
de trabajar con métodos como el Just In Time donde se produce en función de la demanda y sin generar
inventarios (colas de espera) y con tiempos de entrega más cortos. Quizás esta forma de trabajar pueda también
llamarse Desarrollo de sistemas Just In Time.
En el libro 'Practica de la construcción de un conjunto de datos' de J.D.Warnier podrá encontrar los
pasos necesarios para desarmar una salida en las bases de datos lógicas y las guías necesarias para crear las
bases de datos físicas.

60
El modelo Client-Server
Describamos la lógica del modelo client-server dentro del contexto de esta metodología.
De lo visto podemos concluir que la faz operativa de la empresa se puede bosquejar como un conjunto de
procesos que soportan las transacciones entre clientes y proveedores internos y externos de la organización.
Estas transacciones eminentemente operativas son las que necesitan en principio estar en línea con la
información que las soporta para poder operar.
Por otra parte en el terreno de la toma de decisiones los directivos necesitarán información del entorno
en que se encuentra la empresa e información de todo lo que ocurre dentro de ella, en cada una de las etapas de
los procesos.
Aquí el estar en línea deja de ser crítico; lo importante es cumplir con el sincronismo y frecuencias
establecidos en los requerimientos.
También hemos dicho que es posible crear un esquema de información, sobre una base de datos que
soporten de forma estructurada y completa ese conjunto de transacciones.
Haremos ahora una separación horizontal entre la faz operativa y la de toma de decisiones.
Es fundamental comprender la importancia de esta separación (operativa, toma de decisiones). Es muy
común ver como se desechan sistemas operativamente correctos y eficientes tan sólo porque no pueden
suministrar la información necesaria para la toma de decisiones. ¿Por qué ocurre esto?. El problema radica en
la distinta velocidad de cambio de una parte y de la otra. La faz operativa es bastante estable y predeterminada,
más aún cuando es resuelta mediante esta metodología, ya que rápidamente alcanzamos estados eficaces. En
cambio, la toma de decisiones es totalmente dinámica y cambiante, lo que implica que deba ser resuelta por
separado y con otro tipo de herramientas.
La operativa tiene un perfil repetitivo donde los tiempos de respuesta, frecuencia y volumen definen el
tipo de herramientas necesarios para su desarrollo, como lenguajes de cuarta generación y/o de tercera
generación necesarios para cumplir con las condiciones de 'performance' requeridas. La toma de decisiones de
perfil cambiante y en muchos casos por única vez, necesita de herramientas de consulta 'querys' y hojas de
cálculo encadenadas dinámicamente con las bases de datos, única manera de asegurar la consistencia de la
información, seguridad y calidad de los resultados obtenidos.
En muchos casos si las aplicaciones existentes cumplen con los requisitos operativos no hay que
desecharlas; sólo deberán ser sincronizadas (actualización de las bases de datos según las frecuencias
definidas en los requerimiento), lo que permitirá que la toma de decisiones funcione perfectamente. Esto
también vale para adquirir sistemas que cumpliendo total o parcialmente con los requerimientos no estén
desarrollados en la misma plataforma.
P a rte T o m a d e
O p e r ta tiv a D e c is io n e s
( C lie n te ) ( C lie n te )
S Q L
( S E R V ID O R )
I n t e r m o s D a t o s E m p r e s a
P r o v e e d . D a t o s T e r c e r o s
B a s e e x t e r n o s O b j e t o d e l I n t e r c a m b i o
d e d a t o s B a s e X P e d i d o
i n t e r n o s I n t e r c a m b i E n t r e g a
C l i e n t e s F a c t u r a c i ó n
e x t e r n o s L i q u i d a c i ó n

61
Esta independencia permite también ir integrando en forma paulatina las transacciones y aplicaciones,
las que no necesariamente tendrán que estar todas en línea. Y lo que es más importante, los cambios en una faz
no afectarán a la otra. Todo sirve hasta que se demuestre lo contrario.
Es tan costoso continuar usando un sistema que no sirve porque se lo tiene, como desechar uno, que
puede seguir funcionando, por otro nuevo por cambio de plataforma o herramientas de desarrollo.
De una buena definición de los requerimientos surgirá claramente la respuesta que evitará caer en
alguna de estas costosas trampas.
Nótese que la separación operativa de la toma de decisiones tiene un esquema semejante al del cerebro, una
mitad lógica, calculadora y repetitiva, la otra generadora permanente de nuevas ideas y por ende de
necesidades de información.
La toma de decisiones puede ser verticalmente dividida en sistema preventivo y sistema correctivo. Por
supuesto el preventivo exige estar en línea.
En calidad total se utilizan herramientas de presentación de información que pueden pasar a formar parte
de un standard de presentación, que facilita la interpretación de los datos y evita los "apagones" de información
La "estandarización" a medida
Debemos crear sistemas que permitan la mejora continua y no sean un obstáculo más, con sus propias
limitaciones, permitiendo generar estandarización en lo esencial haciendo posible el crecimiento continuo.
Debemos eliminar los desarrollos paralelos sobre temáticas de características semejantes, pero permitiendo
ajustar las transacciones a cada proceso particular.
La paradoja de la estandarización a medida implica conseguir flexibilidad por estandarización del modelo
de representación que captura la esencia de lo representado. Esto implica producir sistemas a medida, pero a la
vez standards. La diferencia radica en una estandarización modular, que permite crear, versus una
estandarización global, que todo lo deja fijo.
Hoy se pueden hacer sistemas cerrados usando herramientas de hard y soft de arquitectura abierta y
sistemas abiertos con soft y hard de arquitectura propietaria. El problema es más que nada metodológico y de
actitud mental. Pero la elección de las herramientas de software y hardware se debe hacer para cumplir con
las reales necesidades de la organización, tratando de minimizar su complejidad y costo.
"Zapatero a tus zapatos" dice el refrán, el como implementarlo cae en el ámbito de los informáticos; el que
implementar; no!.
Hacer sistemas sin considerar estos principios conduce inevitablemente al fracaso, por más recursos y
estructura con que se cuente. Recordar que la calidad y éxito de un sistema la mide el cliente (el usuario) y no el
informático.
Un ejemplo de este tipo de estandarización lo encontramos en los servidores de Bases de Datos
Relacionales que sistematizan y ocultan la complejidad del servicio de la guarda y manipulación de datos.
Mediante el cumplimiento de ciertos 'estandares', nos permiten solucionar la manipulación de los datos, sin
perder la flexibilidad para ajustarse y solucionar nuestros problemas.
En toda esta metodología los procesos son los objetos de mayor nivel. Es por lo tanto necesario
generar standards que nos permitan su correcta administración. Si pensamos así encontraremos muchos otros
tópicos que son factibles de abordar con los mismos principios.
Lo esencial para un administrador de procesos es poder manejar y operar con ellos. Todos los
procesos tienen reglas de cumplimiento generales que se pueden sistematizar en servidores informáticos.
Podremos así establecer una serie de capas jerárquicas de estos servidores donde los de mayor
profundidad son también más genéricos. En el segundo nivel encontraríamos al servidor de procesos.
1) Servidor de Procesos Específicos
2) Servidor de Administración Preventiva de Procesos
3) Servidor de Bases de Datos
Como ya se mencionó: Cada función rutinaria de servicio, dentro de la organización, es pasible de ser
asistida por un servidor informático

62
Servidor de Procesos Específicos
Veamos un ejemplo de lo que puede ser un servidor de procesos específicos.
Servidor contable
Su función es la generación de todos los asientos contables que sean automatizables en todas las
transacciones de los procesos.
Se deben tipificar los documentos y etapas de los procesos para poder asociarles los modelos de
asientos a realizar en cada caso. Esta especificación conforma un 'manual de contabilidad', que estará definido
por tablas administradas por el área contable de la organización.
Las transacciones no realizarán los asientos contables ya que estos los hará el servidor en dos posibles
esquemas de trabajo
En línea: antes de completar y confirmar la transacción se llama al servidor contable para que haga
los asientos.
En diferido: periódicamente el servidor recorrerá todos los documentos generados por las
transacciones y realizará el asiento a aquellos en que aún esté pendiente.
Servidor de Administración Preventiva de Procesos
Sin duda este es el servidor más importante y a la vez más descuidado de todos. Su función es administrar
todos los procesos reales en tiempo de operación.
Notemos que así como las bases de datos lógicas definidas luego se implementarán físicamente en bases de
datos físicas, tratando de evitar redundancias y considerando las restricciones de la tecnología utilizada,
también a los procesos lógicos definidos le ocurre lo mismo.
A la hora de funcionar los flujos lógicos de los procesos caerán sobre los recursos disponibles en la
organización: personas, materiales y equipos con sus propias restricciones, generando los procesos físicos o
reales con los que la dirección debe operar la organización.
Las características operativas de estos procesos reales son dinámicas, cambian constantemente con la
variación de la demanda y los propios cambios estructurales de la organización.
Por lo tanto la función principal de este servidor preventivo de procesos es asistir a la dirección en la
administración y operación de un complejo proceso real, para poder cumplir con los compromisos acordados
con los clientes, utilizando de la mejor manera posible la estructura y recursos de la organización.
Los procesos que hacen funcionar una organización se administran hoy con gran esfuerzo personal de
empleados y directivos. Se utilizan teorías y métodos de administración que trabajan con definiciones estáticas,
cuando ya podemos ver que el problema es dinámico.
Si la organización es pequeña, la intuición y experiencia de la dirección alcanzarán para manejar los
procesos reales, pero si es una organización mediana o grande, con causas y efectos diferidas no habrá ni
intuición ni experiencia que alcancen para evitar el caos y en el mejor de los casos sólo estaremos haciendo un
muy mal uso de los recursos disponibles. Es aquí donde necesitamos recurrir a un software que nos asista.
Imagínese un software que, configurado con la definición de los procesos lógicos, pueda luego recibir
como datos de entrada: la demanda del mercado y el estado operativo de los recursos de la organización, para
poder entregarnos un programa de tareas ajustado a nivel diario, horario o con reprogramación de tareas
permanente (si la variabilidad de la demanda así lo exige), fijando prioridades, equilibrando las cargas de
trabajo y optimizando el uso de los recursos disponibles para maximizar los logros de la organización,
permitiendo el seguimiento y control de los flujos de los procesos en forma preventiva o sea avisando
anticipadamente sobre la aparición de los problemas.
Podría organizar los requerimientos de materiales en función de la programación realizada para que
estuvieran a tiempo. Podría incluso sugerir incrementos de recursos y su ubicación estratégica, para aumentar
la capacidad global del proceso de la organización.
Se lograrían organizaciones muy dinámicas, donde sus integrantes no recibirían recargos innecesarios
de trabajo y sus directivos podrían dedicarse a observar el contexto, planear el rumbo y, simulación mediante,
poner a prueba sus supuestos antes de utilizarlos en la realidad.
El no contar con este tipo de asistencia hará inevitable el choque de nuestros proyectos y programas
con la irrefutable realidad.
Lo más interesante es que podemos lograr generar la información completa que necesita este
administrador, desde la misma realidad del usuario.

63
Si observa ahora las tablas que se crearon en la etapa de definición de requerimientos, podrá ver que
contienen la información estática necesaria para configurar a nuestro servidor de procesos. Luego al operar
éste generará los datos dinámicos necesarios para poder administrar preventivamente los procesos.
La prevención
Actuar preventivamente es tener la actitud y disposición de prepararse anticipadamente para evitar los
riesgos al ejecutar un proceso y poder así cumplir con los acuerdos efectuados con los clientes, tendiendo a
disminuir progresivamente la variabilidad respecto a los parámetros acordados. Es evidente que necesitamos
conocer los pasos que son necesarios para concretar un producto o servicio, resultado de uno de nuestros
procesos y también qué recursos necesitamos para cada uno de sus pasos. Esto es un buen comienzo, pero
lamentablemente los procesos lógicos que debemos ejecutar son muchos y comparten recursos físicos limitados.
Esto se suma a la variabilidad propia de la demanda del mercado y a la intrínseca de cada una de las etapas de
nuestro proceso. Es así que, fijada una política de operación, el resultado dependerá fundamentalmente de la
interacción de todas estas condiciones cambiantes, lo que normalmente produce resultados distintos a nuestros
supuestos originales.
Por lo tanto debemos operar nuestros sistemas en forma preventiva antes de ejecutarlo, durante la
ejecución y después de su ejecución.
Antes, accediendo a nuevos escenarios, ¿ Que pasaría si ...?
Durante, organizando dinámicamente la forma de hacerlo.
Después, evaluando y criticando lo actuado para mejorar.
Las clases de prevención
• Poner a prueba los supuestos (prevención de 1er orden 'antes')
Implica utilizar la simulación para ver los resultados que se obtendrían de aplicar una determinada
política de operación en los procesos, para afrontar la demanda del mercado, con una estructura operativa
determinada.
Es una optimización estática en base a los pronósticos de la demanda y se la utiliza como
programación de arranque.
• Administrar preventivamente (prevención de 2do orden 'durante')
Es una optimización dinámica basada en la mejora continua.
Es una coordinación de todas las etapas para evitar que se detengan los cuellos de botella,
administrando los amortiguadores delante de ellos y cambiándolos de lugar a medida que lo hacen estas
restricciones.
Cada usuario tendrá un seguimiento local del tiempo empleado, versus el programado para sus tareas
en función del método DBR. Esto le permitirá conocer su situación local respecto a la meta global del
proceso. Por otra parte el administrador del proceso tendrá una visión global del mismo.
El servidor, al detectar desvíos peligrosos, avisará tempranamente sobre los posibles inconvenientes,
indicando los grados de perturbación y las causas de los mismos y si fuera necesario reprogramará el resto
del proceso en función de la nueva realidad, teniendo siempre como meta minimizar los desvíos de los
acuerdos efectuados con los clientes.
• Retroalimentación con señales externas ( prevención 3er orden 'después')
Las señales externas obtenidas, como respuesta al resultado de los procesos, deben ser utilizadas para
ajustar las tareas en curso de realización, minimizando los desvíos respecto a las expectativas del cliente.
Las señales internas, como la variabilidad intrínseca de los tiempos de ejecución de las etapas y la
propia de los recursos, retroalimentan la información que es utilizada para las programación y carga de
trabajo.
Esto permite el ajuste continuo y sistemático de los parámetros del modelo, recalculándolos sobre los
nuevos datos históricos.
En resumen; trabajar con sistemas que asistan efectivamente a la dirección administrando
preventivamente la complejidad de detalles, permitiendo hacer realidad el sueño de la organización
sincronizada, pero haciendo todo esto mediante métodos basados en la mejora continua, único camino para
poder asegurar la permanencia de la organización en el medio.

64
Servidor de Base de Datos
Haremos un breve comentario ya que hoy en día es muy conocido.
Este fue el primer tipo de servidor en aparecer en la informática, básicamente porque por su inmensa
plataforma de aplicación, cualquier transacción que necesite datos lo puede utilizar.
Es como un bibliotecario que nos entrega la información que queremos, evitando el tedioso trabajo de
buscar por nuestros medios, en esto consiste su principal servicio.
El modelo más utilizado es el relacional que fue establecido por Edgar Codd en los años setenta, Este
modelo utiliza la teoría matemática de conjuntos para soportar los principios de la gestión de la base de datos.
Al hablar de base de datos relacionales, debemos mencionar al SQL (structured query languaje), que
es el lenguaje standard que se utiliza para comunicarse con el servidor de base de datos. Mediante el SQL
podremos definir el criterio de pertenencia de los datos que necesitamos para realizar una transacción,
conociendo solamente la estructura lógica, ó sea las bases de datos y tablas lógicas que se obtuvieron en la
etapa Definición de las estructuras de información
Este ocultamiento de la complejidad es una de sus principales características, permitiendo un gran
nivel de abstracción entre la visión externa (lo que el usuario o una transacción perciben) y la forma de
manipular internamente los datos. Esto implica también que la estructura lógica que vemos pueda estar
soportada sobre bases físicamente distribuidas en diferentes ubicaciones geográficas, en equipos de diferentes
marcas, con diferentes sistemas operativos.
Otra aspecto importante es la implementación del concepto de transacción; esto significa que definida
una serie de pasos su acción sobre la información de la base de datos tiene sentido sólo si sé completan todos y
bien. Cuando una transacción no se completa correctamente el servidor de base de datos retrotraerá los datos
al estado inicial.
La seguridad al acceso de los datos es otra característica importante a destacar.
Pero lo más importante es que nuestro modelo lógico podrá ser utilizado prácticamente sobre
cualquier equipamiento, independizándonos de las características físicas imperantes.

65
Resumen
Para la especificación de cada etapa de un proceso utilizamos:
• El matrizado que define los requerimientos de cada etapa en todos sus aspectos: métodos , recursos
humanos, equipos, materiales. Esto permite luego definir con realismo la transacción informática que la
acompañará.
• Los métodos estructurados que parten de los objetivos definidos por el usuario. Se describen las acciones a
cumplir y se determinan los datos necesarios. Estos datos se distribuyen en las bases de datos lógicas.
Los algoritmos, los diagramas de pantallas y las tablas lógicas forman la especificación. Esta se apoya en
el modelo Client-Server.
• El modelo Client-Server que nos permite separar los problemas, minimizando la especificación de las
transacciones. Todo lo que es rutinario e igual va a un servidor; la transacción cliente sólo necesita definir
lo que es distinto de la etapa.
Los servidores se clasifican en:
Servidor de Procesos Específicos
Servidor de Administración Preventiva de Procesos
Servidor de Base de Datos

66
Implementación
Entre las posibles arquitecturas de hardware y software a utilizar en la implementación de los sistemas de
información de una organización está la arquitectura abierta con el esquema de operación Client-Server. Si
bien el uso de TQSD/1 no condiciona la arquitectura de implementación, ésta se ajusta perfectamente a los
objetivos planteados y permitirá acelerar notablemente el proceso.
Arquitectura Abierta
OA (Open Architecture)
Se describe a continuación lo que se entiende en este contexto por arquitectura abierta.
La arquitectura abierta se basa fundamentalmente en el uso de estándares y en su cumplimiento, siendo éste
quizás uno de los ejemplos más notorios a gran escala de un proceso sinérgico.
Revisemos por un momento el punto actual del desarrollo informático y veamos que ha ocurrido. Hace algo más
de una década se hablaba de que solo tres o cuatro marcas de equipos sobrevivirían a la carrera informática.
Había muchos desarrollos distintos e incompatibles, cada uno tratando de capturar a sus clientes en
arquitecturas 'propietarias', las minicomputadoras eran muchas y muy distintas, pero un día el gigante azul
creó una computadora que se llamó PC, no era nada genial, nada extraordinaria, pero fijo un standard de facto
por el peso que I.B.M tenía en el mercado.
Esto generó un proceso sinérgico entre todos los fabricantes y desarrolladores independientes que
polarizaron todos sus esfuerzos hacia ese standard. Y a pesar de que esa PC no es nada especial, produjo un
fenómeno extraordinario y único en el desarrollo tecnológico fijando standard tras standard.
Hoy prácticamente todo se puede desarrollar en equipos de arquitectura abierta, existen 'piezas' de
hardware y software para solucionar casi cualquier necesidad.
Luego la idea de crear productos aptos para prácticamente todas las plataformas de hardware o software se
perfiló como característica ampliamente buscada en el mercado. Aparecen así sistemas operativos que corren
en administran cualquier equipo, bases de datos que corren en cualquier sistema operativo, herramientas de
desarrollo que acceden a cualquier base de datos.
Estos productos forman una serie de capas que independizan a los sistemas de los cambios que cada
capa sufra, protegiendo la inversión hecha en los desarrollos, alargando en definitiva la vida útil de los
sistemas, pero no perdiendo las ventajas que los cambios tecnológicos nos ofrecen y ofrecerán.
Las piezas estándares necesarias para nuestros desarrollos podrán ser muchas veces superadas por
opciones no standard, pero nunca olvidemos que tenemos que caminar nuestra curva de crecimiento continuo y
aquí ésta es nuestra prioridad y no la de tener el último "chiche" de la tecnología informática. Normalmente con
el tiempo los standards siguen evolucionando y afianzándose, llegando a superar a las versiones propietarias
que avanzan rompiendo standards.
Las principales características que interesan de la arquitectura abierta son:
La Inter-operabilidad de diferentes computadoras y sistemas de software.
Las máquinas se interconectan formando LANs (Local Area Network) que luego se integran a otras
LANs, que la empresa tenga en otras regiones geográficas formando WANs (Wide Area Network).
Esta conectividad se basa en los protocolos de comunicación standard del mercado, permitiendo que
cualquiera sea el medio físico sobre el cual se realiza la comunicación (satélite, teléfono, líneas punto a punto
etc.) no se afectará en modo alguno la funcionalidad o las prestaciones de las aplicaciones.
Esta arquitectura posibilita el acceso del usuario, en forma transparente, a aplicaciones , datos y
archivos distribuidos por la red.
Las aplicaciones pueden correr en cualquiera de los equipos que conforman la red. Esto es posible
por la operación Client-Server que es un mecanismo de procesamiento que permite que un programa (el
cliente) obtenga servicios de otro programa (el servidor), lo que facilita la optimización de recursos
compartidos en aplicaciones de procesamiento distribuido.
Los datos residen en la fuente y pueden ser compartidos eficientemente con el modelo client-server, aún
con vínculos de baja velocidad.
Otro de los beneficios de la arquitectura abierta es la de permitir trabajar en un ambiente multimarca
que integra equipos que son incompatibles entre ellos.
Este esquema integra las islas informáticas en una red que engloba a toda la empresa, soportando así
los sistemas integrales.

67
La Escalabilidad, tanto de los clientes como de los servidores en capacidad de procesamiento o en cantidad.
Este crecimiento modular permite algo así como ir armando la 'main-frame' de la empresa, totalmente a medida
de sus necesidades evolutivas en el tiempo y no antes, justo a tiempo sin desperdicios.
La Portabilidad, dado que el conocimiento y organización de una empresa se vuelca sobre sus sistemas; dicha
inversión debe ser preservada ante los cambios por hardware de mayor potencia o herramientas de software
más poderosas.
Para permitir esto se definen capas funcionales que se comunican mediante mecanismos standards.
Esto permite, en teoría, el cambio del contenido de una capa por otra de mayor prestación o marca, afectando
mínimamente los desarrollos de las otras.
Estos son los aspectos que justamente permiten realizar un avance continuo y permanente.
Pero la decisión de que es lo que realmente necesitamos puede ser extremadamente complicada si no existe una
especificación de los procesos y las transacciones que se deben ejecutar. Cuando las etapas son realizadas en la
secuencia correcta, muchos de estos problemas de toma de decisión desaparecen.
La arquitectura abierta permite aplicar los conceptos de Just In Time al ir armando la configuración
que necesitamos. Pero si seguimos esperando a tener toda la instalación para empezar a ver que hacemos con
el soft o queremos comprar todas las máquinas juntas porque después quien sabe, estaremos haciendo las cosas
muy mal. Es probable que para cuando realmente utilicemos alguno de esos puestos de trabajo, ya existan
computadoras más potentes y más baratas, que rompen todos los descuentos por cantidad logrados o puede
ocurrir que nos demos cuenta que necesitamos otro tipo de herramienta. Cuando hay resultados, cuando lo que
tenemos funciona, nadie se opone a comprar lo que realmente necesita en el momento justo.
Pero lo que ocurre en la realidad, es que nos seguimos poniendo los zapatos antes que las medias, sino:
¿Por qué está generalmente primero el hardware y luego el software?
¿Por qué se compran sistemas sin conocer las reales necesidades?
¿Por qué se programa sobre débiles especificaciones cuasi verbales?
Quizás al usuario se le ha vendido la ilusión de que el informático es un vidente que tiene la respuesta
a las preguntas que aún el mismo no se ha realizado.
Lo cierto es que mientras no nos pongamos a trabajar todos en conjunto: los informáticos manejando
la tecnología y los usuarios especificando que hacen en su trabajo y como lo hacen, sólo tendremos pobres
sistemas informáticos a pesar de utilizar las últimas sofisticaciones tecnológicas.

68
Puesta en marcha y operación
Los procesos reales
Con la arquitectura abierta estamos solucionando parte del problema de la puesta en marcha, ya que en la
operación como ya mencionamos aparecerán los complejos procesos reales que habrá que controlar y
administrar.
Muchas técnicas de organización se han ideado y se utilizan, pero casi todas pecan de tratar de solucionar
estáticamente un problema eminentemente dinámico y las que bien lo tratan, como el Just In Time, requieren de
una confiabilidad de todas las etapas del proceso que muchas veces es difícil de conseguir.
Hasta ahora hemos hablado de procesos lógicos, donde supuestamente hay capacidad ilimitada para que
operen normalmente. Pero en el territorio de la realidad, un proceso físico es como una cadena, que tiene
capacidad de soportar carga hasta que se rompe por el eslabón más débil. Entonces, hay que identificar ese
eslabón débil para en principio protegerlo, porque su rotura implica la rotura de la cadena y luego reforzarlo,
porque al hacerlo se aumenta la capacidad de carga de todo el proceso.
Al ser capaces de identificar el eslabón débil de nuestro proceso real ocurre algo curioso, el protegerlo es
lo más urgente, el reforzarlo lo más importante. Es como que sobre el eslabón débil se alinea la mira de lo
urgente y lo importante, ¿Se terminará así con el eterno dilema de la dirección?.
Nos podemos preguntar: ¿qué hacemos con el resto de las tareas que debemos realizar?, ¿qué tratamiento
le damos?, Es lógico pensar que si el eslabón débil es lo más urgente y a la vez lo más importante, todo lo
demás se debe subordinar a éste y por lo tanto colaborar para protegerlo y para permitir reforzar su acción.
Pero ¡cuidado! ahora, al aumentar su capacidad, y aumentar la capacidad de la cadena toda, otro eslabón
puede empezar a sufrir los efectos del mayor esfuerzo y pasar a ser el más débil. Nuevamente estamos como al
principio, claro que ahora nuestra cadena tiene mayor capacidad de carga. En esta situación no tenemos más
remedio que comenzar nuestro proceso de nuevo.
El orden en que se nos van presentando los eslabones débiles o restricciones, serán nuestras prioridades
naturales y así dadas las cosas sólo podemos aceptarlas y rogar por que nuestro personal de dirección sea
capaz de verlas tal cual son, porque allí están, son reales, aún cuando nos distraigamos resolviendo otros
problemas que no son ni urgentes ni importantes. Esto da sentido a la famosa frase 'No hay nada más
ineficiente que hacer eficientemente algo innecesario'.
Parece muy tétrico el hecho de que las prioridades naturales van a condicionar permanentemente nuestro
accionar y no tenemos escapatoria. Pero en realidad siempre hay una salida y se llama prevención. Con ella
podemos cambiar el orden de nuestras prioridades naturales y su propia ocurrencia, influyendo sobre el medio.
Esta mecánica no es otra cosa que el proceso de mejora continua.
Proceso de mejora continua:21
1• Identificar las restricciones del sistema, los cuellos de botella.
2• Decidir como explotar las restricciones del sistema.
3• Sincronizar al ritmo de las restricciones, ó sea subordinar todo lo demás a la decisión del paso
anterior.
4• Elevar la capacidad de las restricciones del sistema.
!!advertencia!!
5• Si en los pasos anteriores se ha eliminado alguna restricción, regresar al paso uno, pero no
permitir que la falta de previsión, sea la causa de restricciones en el sistema.
Notar que a veces las restricciones son físicas, como la capacidad de un equipo en una linea de producción,
pero otras son políticas de trabajo u operación. En el primer caso tratamos de explotarla al máximo, en el
segundo debemos necesariamente cambiarla.
21 Basado eb 'La Meta' de E.Goldratt

69
Características de los procesos
Los procesos reales están formados por series de eventos o etapas, dependientes unas de otras, donde
cada una de ellas requiere de un tiempo para ser ejecutada. Este tiempo requerido tiene una fluctuación o
variabilidad intrínseca para cada etapa. Por lo tanto, todos los procesos están formados por eventos
dependientes con fluctuaciones estadísticas2
Cuando hablamos de eventos o transacciones dependientes, significa que el comienzo de una depende
de la terminación de la otra. Esto hace que sus fluctuaciones no se promedian, sino que se acumulan, porque la
dependencia limita la posibilidad de que aparezcan las fluctuaciones más altas. Es por esto que los programas
de tareas que utilizan los tiempos medios nunca se cumplen.
Si clasificamos a las etapas por la atención que les debemos prestar, las podemos separar en etapas,
tipo cuello de botella o no cuello de botella
Una etapa tipo cuello de botella será aquella cuya capacidad es igual o menor a la demanda que hay
de su producto.
Una etapa no tipo cuello de botella es cualquiera cuya capacidad sea mayor a la demanda que hay de
su producto.
El método Drum Buffer Rope
(Tambor - Amortiguador - Cuerda)22
Para explicar la estructura intrínseca de estos procesos E. Goldratt utiliza una analogía insuperable
que es la de una tropa, que debe marchar hacia un objetivo. La capacidad de marcha de cada soldado es la
capacidad de nuestras etapas reales. El ''input'' de este modelo, el camino a recorrer, el troughput es el camino
recorrido, el inventario es la distancia entre el primero y el último de ellos y la energía empleada en avanzar es
el gasto de operación.
L a tr o p a energia consumida = gasto de operación
Input = Throughput =
camino camino recorrido
inventario = distacia
En su libro 'La Meta' Goldratt nos enseña como la única manera de avanzar hacia la meta es tener
siempre presente que tenemos que maximizar nuestro troughput, minimizando al mismo tiempo nuestro
inventario y nuestros gastos de operación.
Continuando con su analogía, el soldado más lento, el cuello de botella, determina el troughput de todo
el sistema. Por lo tanto, el de la tropa como conjunto, no puede ir más rápido que él, por eso lo dejamos
marcar el paso del proceso tocando el tambor.
Si pudiéramos colocar a este soldado al comienzo de la fila y el resto en capacidad creciente hacia
atrás, tendríamos un proceso que tiende a minimizar el inventario, la distancia entre los soldados, dado que
todos tienen capacidad suficiente para cerrar el paso, un proceso autoregulado. Pero en la realidad, no siempre
podemos poner al comienzo de nuestro proceso la etapa más lenta. Esto produce una dispersión en la tropa que
se traduce en acumulación de inventario entre las etapas. Aquí Goldratt introduce un nuevo elemento, una
cuerda para atar al primer soldado con el soldado que marca el paso (nuestra restricción); los que están por
detrás del lento quedan libres y por su mayor capacidad tratarán de cerrar el paso. Si el soldado lento evita
mediante la cuerda que el primero de mayor capacidad se aleje, ahora sólo queda ser previsores y armar la
tropa de manera que nuestro lento soldado nunca se deba parar, ya que cada vez que lo hace, toda la tropa se
retrasa. Aquí es donde se introduce el tercer elemento del método, que es el amortiguador. Tenemos que dejar
un trecho de camino por delante del lento, para que aunque los soldados que están entre el primero y él se
detengan a atarse los cordones, tengan tiempo de hacerlo sin estorbar el avance de nuestro lento soldado.
22 De 'La Carrera' E. Goldratt

70
Así con un mínimo inventario estratégicamente ubicado podemos avanzar como en el Just in Time pero
con mayor seguridad ante las perturbaciones que puedan sufrir las etapas. En el Just In Time cualquier
perturbación en cualquier etapa producirá la detención del proceso.
J u s t In T im e
cuerda
En DBR el proceso es más natural y distendido y todos colaboran con el eslabón débil.
D ru m B u ffe r R o p e tambor (marca el paso de todo el proceso)
cuerda mortiguador
Todo esto viene a colación de nuestro problema de administrar los procesos físicos, nuestro servidor de
procesos utiliza el método Drum Buffer Rope como forma de alcanzar la sincronización de los procesos reales.
Volvamos a mirar nuestra organización, en ella encontramos personas, equipos, materiales, con los cuales
debemos realizar los productos o servicios. Si suponemos completadas las etapas de definición de
requerimientos, sabemos que hace cada uno de ellos, como se encadenan sus tareas y cuando deben ser
realizadas si queremos que el producto esté listo en determinado momento.
Entonces si trabajamos en función de la demanda y las condiciones operativas de nuestros recursos,
podemos realizar una buena programación para, sincronizadamente, maximizar nuestro troughput.
Si pensamos en los sistemas informáticos de administración, el proceso físico es el resultado de la
sumatoria de todos los procesos lógicos que deben realizarse concurrentemente. Pasar de la visión lógica a la
física es como ir descargando las tareas, temporalmente ubicadas, sobre los recursos. Es muy probable que
nuestro eslabón débil estará ahora por aquí, luego por allá, dependiendo esto de la múltiple interacción de los
requerimientos de las etapas sobre los recursos.
Para colmo de males la demanda no es constante, generando fluctuaciones, que se deben sumar a los
problemas que sufra la estructura propia de la organización (hoy justo se enfermó Pérez). . Quizás esto pueda
explicar en parte la complejidad del problema que tiene la dirección al tratar de coordinar los recursos.
El trabajar a ciegas, sólo apoyados en los supuestos que deja la experiencia, no es suficiente. Para
administrar eficazmente los recursos en una organización mediana o grande, necesitamos herramientas mejores
y más precisas. Bien sabemos que las buenas reglas del arte indican una cantidad máxima de personas por
empresa o unidad de negocio para hacer las cosas manejables.
Las dificultades encontradas en sistematizar la administración de procesos se debe fundamentalmente
a utilizar métodos de programación estáticos o métodos dinámicos que no contemplan los problemas intrínsecos
de la variabilidad.
Si bien el método DBR es conceptualmente sencillo e intuitivo, para poder aplicarlo en gran escala
requiere necesariamente de la asistencia de un computador.
Lo que hay que rescatar es que: este método nos permite programar en qué tiempos deben se
ejecutadas las tareas para sincronizar las etapas de los procesos, en las condiciones actuales de operatividad y
demanda. Si alguna de estas condiciones cambia, también cambiará la tarea y el momento de realizarla.
Por lo general siempre alguna persona estará operando temporalmente en una etapa crítica. Entonces
es fundamental que lo sepa, ya que durante ese período de tiempo debe esforzarse por disminuir su
variabilidad, porque todo lo que no realiza en tiempo, aunque tan sólo sea apretar un botón, estará afectando
al troughput de todo el proceso. Los que están en las etapas anteriores deben terminar su trabajo un tiempo
antes de que empiece la tarea crítica para generar así el amortiguador necesario para soportar la acumulación

71
de las fluctuaciones perjudiciales de los mismos . El operador de la primera etapa debe seguir a ritmo no
haciendo más que lo que le indica la etapa crítica, mediante una señal o cuerda.
Todos estos tiempos permiten implementar un sistema de semáforos o diagramas de control que le van
indicando a cada uno como esta respondiendo respecto al óptimo global.
Goldratt muestra como monitoreando los amortiguadores podemos descubrir las perturbaciones que se
están presentando, cuantificarlas según el grado de perturbación. Esto nos permite priorizar el esfuerzo de
resolución e identificar las posibles causas.
Pero en nuestro sistema informático, algún semáforo estará advirtiendo del peligro aún antes de que el
problema se haga visible en el amortiguador. Esta es la clase de prevención que ataca los problemas cuando
aún están por nacer.
Si Ud. tiene, o proyecta tener, un sistema informático que soporte 'circuitos electrónicos', donde los
usuarios realicen sus tareas directamente en la computadora, notará que esta mecánica no le exigirá mayor
trabajo operativo a las personas y sólo requerirá que cada transacción informe al servidor de procesos cuando
completó su tarea.
Esto implica que con un gasto operativo prácticamente despreciable, el servidor realizará la
programación que sincronizaría las tareas de la administración y controlará su cumplimiento comunicándose
mediante los diagramas de control con el usuario, indicando en todo momento quien es el cuello de botella,
para que él tome conciencia de su responsabilidad, para que los otros lo ayuden en lugar de distraerlo.
Piense en las colas que hay que hacer en los bancos cuando, a pesar se existir muchas cajas, sólo
atienden unas pocas, aunque todos los empleados estén trabajando ¿cual será la sensación de los clientes?.
Imagine ahora que a cada persona se le asigna un rol principal y una serie de roles alternativos de menor
prioridad y seguramente menor rendimiento. Es probable así que existan cajeros temporarios que, con cajas
asignadas, puedan atender cuando la demanda lo requiera. Pero claro, la cola es una demanda visible, en un
banco hay muchas otras y todas deben ser atendidas, lo importante es poder posicionarse frente a ellas de la
manera más conveniente posible para mejorar el throughput.
Seguramente algunos pensarán que con este esquema de trabajo se puede explotar muy bien a las
personas. Esa sería una buena forma de fundir el motor y por ende de perder toda posibilidad de avanzar hacia
la meta. Creo que esto es otra cosa, es poner el motor del auto a punto. El criterio con que presionemos el
acelerador nos dará la exigencia que le impongamos a sus componentes y si somos concientes que estamos
trabajando con personas y que muchos de todos estos sincronismos dependen de su actitud, estado de ánimo e
integridad como seres humanos, sabremos como alcanzar el equilibrio, cuidando que la presión sea justa. Pero
¿cuál es la otra alternativa?, usar un motor fuera de punto que nos lleva a los tirones y donde cualquier
exigencia, por poca que sea se traduce en situaciones de extrema tensión, como la que viven a diario la
mayoría de las organizaciones y donde el gasto de energía para avanzar el mismo trecho será pagado
seguramente por la calidad de vida de sus integrantes. Si nosotros no lo hacemos, otro lo hará y nos ganará.

72
Conclusiones:
Después de leer este libro muchos pensarán que hacer todo esto lleva mucho tiempo y es muy costoso,
sin embargo no hay camino más corto y económico, porque el objetivo está en avanzar lo más rápidamente
posible y con lo mínimo indispensable.
Analicemos los riesgos de que no complete el proceso. No importa hasta donde llegue, siempre habrá
ganado algo:
Si sólo logra concientizar a la organización
• Comenzará a obtener cada día más participación de todos en la resolución de los problemas
complejos.
• Empezarán a surgir nuevas ideas de como afrontar el cambio.
Si realiza sólo los diagramas de entidad:
• Tendrá una visión global de lo que hace la gente en su empresa para los temas más importantes que
maneja.
• Posiblemente pueda empalmar algunos vínculos que hoy están cortados, lo que ya de por sí, producirá
mejoras.
Si realiza también los diagramas de ensamblaje:
• Notará como se reducen los pasos de sus procesos y por ende el trabajo.
• Estará seguro de porque se deben hacer cosas de una determinada manera, lo que dará más
confianza a la relación del personal y la dirección.
Si realiza también los diagramas cíclicos:
• Podrá manejar también los tiempos de respuesta y en función de las condiciones de mercado
• Es probable que pueda obtener ventajas competitivas
Hasta aquí podrá seguir trabajando manualmente o con sus actuales sistemas, pero al conseguir un
mejor grado de sincronización, los resultados serán seguramente superiores.
Si establece una estructura de información cliente proveedor:
• Esta estructura será común para todas los sistemas. Estos en principio transferirán información fuera
de línea, pero a medida que sus prioridades naturales lo requieran, su sistema organización se ira
integrando y creciendo consistentemente.
• Esto hará que simplemente sus sistemas desaparecerán como tales y comenzará a trabajar y pensar
sólo en procesos.
Hasta aquí estará muy contento porque sus sistemas funcionan, la información es consistente y confiable pero....
Si implementa el concepto de servidor preventivo de procesos:
• Comprenderá lo que significa poder operar confiablemente una organización basada en la
información. Esto último paso será tan importante como pasar de andar en bicicleta a un auto
deportivo.
Los conceptos aquí vertidos son muy simples, obvios y hasta le parecerá que ya los sabia, quizás
porque son muy intuitivos, pero ¡cuidado! El secreto no está a la vista. Se dice que hay una huella entre Estados
Unidos y Japón, dejada por todos los norteamericanos que van y vienen tratando de descubrir el secreto del
éxito que no surge de la mecánica aplicación de recetas.
Para aplicarlos eficazmente requieren ante todo una actitud mental consistente con ellos. Todas estas
técnicas y métodos fracasan si no se tienen internalizados conceptos como: el partir de las necesidades del
cliente, el buscar el beneficio recíproco, el cuidar el entorno, tratando de que cada persona pueda dar lo mejor
de sí misma.
Este es un proceso de mejora continua: Ud. decide si lo transita y hasta donde.

73
Bibliografia
lecturas recomendadas
concientización de la organización
• Senge, Peter M. La Quinta Disciplina
Granica, Barcelona
• Drucker, Peter F. Las Nuevas Realidades
Editorial Sudamericana, Buenos Aires
• Crosby, Philip B. Hablemos de Calidad
Ediciones McGraw Hill.
• Crosby, Philip B. Calidad sin lagrimas
Crosby Associates International, Inc
• Hay, Edward J. Justo a Tiempo
Editorial Norma, Bogota
• O'Neal Charles Marketing Justo a Tiempo
Editorial Norma, Barcelona
definición de los requerimientos
• Orr, Kenneth T. Structured Systems Development
Yourdon Press, New York
• Orr, Kenneth T. Structured Requirements Definition
Ken Orr and Associates,Inc ,Topeka, Kansas
definición de la estructura de información
• Warnier, Jean D. Practica de la construcción de un conjunto de datos
Editores técnicos asociados, S.A., Barcelona
diseño de las transacciones
• Warnier, Jean D. Los tratamientos y sus datos
Editores técnicos asociados, S.A., Barcelona
puesta en marcha y operación
• Goldratt, Eliyahu M. La Meta
Ediciones Castillo, Monterrey
• Goldratt, Eliyahu M. La Carrera
Ediciones Castillo, Monterrey

Metodo TQSD/1 1993

Más contenido relacionado

La actualidad más candente (11)

Similar a Metodo TQSD/1 1993 (20)

Más de Gustavo Giorgetti (20)

Último (20)

Metodo TQSD/1 1993