Innovación en Procesos Empresariales

Contener la Situación e Innovar el Proceso

El interés en este material de apoyo se centra en el uso de lenguajes de sistemas de cualquier tipo en la innovación en el
mundo real, esto es, en la metodología. La palabra innovación ha sido descrita anteriormente en términos de su relación a
los extremos de un espectro que varía desde lo “duro” hasta lo “suave”, donde las situaciones duras son aquellas que
tienen que ver únicamente con preguntas de “como” y los problemas suaves son mezclas complejas tanto de preguntas
del tipo “que” como preguntas del tipo “como”. Esa distinción es todavía útil, pero al hacer referencia a alguna metodología,
usaremos una definición más general. Considere “una situación” como cualquier expresión de preocupación. En este
contexto una metodología representa un conjunto estructurado de guías que permiten a un interventor derivar formas de
aliviar tal preocupación por medio de la innovación.

Una metodología no es un método o técnica. Necesita ser más flexible que cualquiera de estos en términos de su estructura
y su aplicación si ha de ser apropiada a la variedad que existe en las situaciones del mundo real. Una técnica está
caracterizada por lineamientos los cuales están definidos precisamente, de tal manera que, si su asunto es, digamos,
cómo resolver una ecuación diferencial, hay técnicas disponibles que conducirán a una solución que cualquier interventor
competente estará de acuerdo en que sea la correcta. Tal situación, sin embargo, se relaciona únicamente con un muy
pequeño conjunto de las situaciones del mundo real en general. La aplicación de una metodología puede involucrar el uso
de técnicas, pero es la metodología la que determina si una técnica particular es apropiada o no. El proceso de innovación
puede ser visto en los términos descritos por la figura 1:

Figura 1. Una Visión de la Actividad de Innovación.

En esta figura, se hace una distinción entre la actividad que está en el mundo real, la situación y la actividad que tiene que
ver con pensar acerca del mundo real. Esta última actividad tiene que ver con reaccionar a la preocupación expresada por
algún dueño de un problema en el mundo real y es actividad llevada a cabo por un interventor.

El cliente puede ser definido como el poseedor del rol que causa que el estudio se realice. El cliente puede, o no, ser el
dueño del problema. Estas son distinciones útiles de hacer, ya que el cliente autoriza un estudio particular y tendrá algunas
razones para hacerlo. El dueño del problema puede cambiar conforme el estudio avance y la naturaleza de la situación
cambie. Así la identificación del dueño del problema provee algún aprendizaje sobre si las “soluciones” propuestas serán
aceptables o no, y por lo tanto factibles. El interventor puede ser un solo individuo o un grupo de individuos.

La distinción hecha en la figura 1 nos permite visualizar la actividad intelectual de solucionar problemas como un sistema
de actividad humana en sí misma. Es un sistema para transformar una entrada: una preocupación acerca de alguna
situación; en una salida: recomendaciones para aliviar tal preocupación. Basados en una visión particular del valor de la
intervención, puede derivarse una definición esencial como sigue:

Un sistema de innovación, con orientación a una situación, para transformar un estatuto de preocupación acerca de alguna situación en
recomendaciones para aliviar esa preocupación que sean aceptables para el dueño del problema.

1
Innovación en Procesos Empresariales

En esta definición, el dueño y los actores no están especificados. La transformación está claramente establecida y el
cliente se considera sea el dueño del problema. La W implicada por la definición es que, si permanece orientada al
problema, la actividad de innovación o intervención, conducirá a recomendaciones que sean aceptables para el dueño del
problema. Este es un W orientado al cliente, implicado por la frase “aceptables para el dueño del problema” y está implicado
que tal actividad vale la pena.

Se incluyen restricciones ambientales en el sentido de que las recomendaciones no pueden ser inaceptables y la actividad
de solución de problemas debe permanecer orientada al problema. Un modelo de este sistema está representado en la
Figura 2.

En este modelo han sido incluidos dos sistemas de control. Uno es

responsable de asegurar que el proceso de innovación es
adaptable y es, por lo tanto, capaz de permanecer orientado a la
situación, conforme la apreciación de la situación sea más
profunda; el segundo es responsable del control del sistema como
un todo. Aunque cada actividad debe ser llevada a cabo
efectivamente para poder derivar recomendaciones relevantes, la
actividad “ensamblar el conjunto apropiado de conceptos” es la
más importante en relación a la presente discusión acerca de
metodología.

Estamos interesados en el uso de conceptos de sistemas y cómo

Figura 2. Un sistema para la Innovación de Procesos.
es que estos son ensamblados representa la metodología
particular que se considera como apropiada a la naturaleza de la
situación. Así es que, si la situación de interés refiere a la
optimización de procesos o diseño de plantas, los conceptos
pueden estar expresados en el lenguaje de matemáticas y la forma
particular de integrarlos puede estar relacionada a una
metodología de ingeniería de sistemas “duros”. Por otro lado, si la
situación de interés está orientada hacia el polo más “suave” del
espectro de problemas, nuestros conceptos serán los de sistemas
de actividad humana y la forma particular de integrarlos será una
metodología de sistemas “suaves”.

Como lo indica la actividad arriba citada, y como resultado del deseo general de permanecer orientado a la situación actual
bajo investigación, la metodología usada en un estudio necesita ser configurada a la medida. Sin embargo, el trabajo en
el Departamento de Sistemas de la Universidad de Lancaster condujo a una metodología general de sistemas suaves, la
metodología de Checkland, la cual será descrita.

Antes que nada, revisemos brevemente las metodologías de ingeniería de sistemas que condujeron a la formulación inicial
de las metodologías de sistemas “duros” que fueron utilizadas como el punto de partida de nuestro programa de acción
investigación.

Metodologías de Ingeniería de Sistemas

En el material de apoyo se presentó un sumario de la historia reciente en aquellas áreas de la ingeniería y la biología que
condujeron al conjunto de conceptos utilizados ahora en nuestro lenguaje de sistemas. La motivación para llevar a cabo
el desarrollo de metodologías de diseño de sistemas surgió debido a cuatro características que afectaron la industria de
la postguerra:

1. Los sistemas técnicos se volvían cada vez más complejos.

2. Los ambientes de mercado se volvían altamente competitivos.
3. Los nuevos proyectos eran crecientemente más caros.
4. Los desarrollos en computación hacían factibles cálculos complejos.

Estos factores dieron origen a la necesidad de tener metodologías de diseño integradas que fueran capaces de producir
diseños “optimizados” y la necesidad de ver al diseño como una parte de la planeación del desarrollo del negocio.

2
Innovación en Procesos Empresariales

Así, se llegó a la conclusión de que el diseño de sistemas técnicos era parte de un ambiente más amplio el cual tenía que
ser considerado en el proceso de diseño. Las interacciones se ilustran en la figura 3 en la cual una nueva planta es
mostrada teniendo relaciones significativas con tres aspectos de su ambiente, esto es, el mercado a ser servido, los otros
procesos de producción con los cuales pueda interactuar en términos de flujos materiales: materias primas y productos; y
el ambiente del negocio, en el cual la interacción será en términos financieros.

Figura 3. Diseño de una Planta y su Ambiente.

Las metodologías de diseño de plantas industriales, las cuales son relevantes para sistemas físicos diseñados, han sido
creadas considerando que la frontera del sistema sea el hardware: la planta junto con su sistema de control. Estas
metodologías, sin embargo, han reconocido que el sistema así definido reside dentro de sistemas mayores: suprasistemas
y ambientes representados por el mercado, el negocio y áreas de producción. También reconocen que una planta en
operación rara vez sea estática y han, por lo mismo, incorporado consideraciones dinámicas como una parte integral del
proceso de diseño.

La Ingeniería de sistemas como una disciplina lo mismo ha estado relacionada con el diseño que dirigida hacia el desarrollo
de metodologías para la solución de problemas en general. Notables ejemplos de éstas, son las metodologías descritas
por Arthur Hall en 1962, desarrollada como resultado de la experiencia dentro de los Laboratorios Telefónicos Bell y la de
análisis de sistemas de la Corporación RAND.

Hall visualiza al proceso de ingeniería de sistemas como consistente de cinco etapas principales, las cuales pueden ser
resumidas como sigue: planeación del programa, en el cual la salida es el foco de atención en un proyecto específico o
un área problemática; planeación exploratoria, conduce a la decisión de que un proyecto de desarrollo será llevado a cabo.
Esto a su vez puede conducir a varios proyectos de planeación de desarrollo; planeación de desarrollo, lo cual produce
una especificación más detallada y un plan de acción para el sistema a ser desarrollado; desarrollo del sistema, las
especificaciones producidas son comunicadas a la fábrica y al campo; mejoras al sistema, reaccionar a información que
regresa de la fábrica y el campo la cual puede conducir a especificaciones o re-diseño.

El enfoque jerárquico a la investigación está nuevamente construido en este proceso de análisis, y las primeras tres etapas
de las arriba citadas involucran iteración, a varios niveles de detalle, de los siguientes seis pasos:

1. Definición del Problema. 3. Síntesis del Sistema.

a. Definir las necesidades (“investigación de necesidades”). a. Colectar alternativas.
b. Identificar el ambiente (“investigación de ambiente”). b. Listar las funciones del sistema.
c. Listar las entradas y salidas del sistema y sus relaciones. c. Delinear subsistemas.
d. Definir la frontera del sistema y sus restricciones. d. Usar la creatividad.

2. Selección de Objetivos. 4. Análisis de Sistemas.

a. Listar los objetivos. a. Decidir qué se va a analizar.
b. Optimizar el sistema de valores. b. Seleccionar herramientas de análisis y analizar.
c. Deducir consecuencias inciertas.
d. Comparar el desempeño del sistema con objetivos.

3
Innovación en Procesos Empresariales

5. Seleccionar el Sistema “Óptimo”. 6. Planear la Acción.

a. Definir criterios de decisión. a. Escribir los reportes.
b. Evaluar consecuencias - clasificar sistemas. b. Promocionar el plan del sistema.
c. Documentar alternativas rechazadas.

La Metodología RAND de Análisis de Sistemas similarmente se describe como una serie de etapas, resumidas como se
muestra a continuación:

1. Formulación (Fase Conceptual). 3. Evaluación (Fase Analítica).

1.1. Claramente formular y limitar el problema.
1.2. Clasificar y seleccionar los objetivos que se espera
lograr con el sistema – y actualizarlos cuando sea
necesario.
1.3. Seleccionar criterios para medir el logro de objetivos -
y actualizarlos continuamente.
1.4. Establecer hipótesis (o posibles soluciones) a la luz del
establecimiento del problema.
2. Investigación (Fase de Investigación).
2.1. Establecer hechos y recolectar datos sobre los cuales
se puedan basar el análisis, asignar probabilidades a
aquellos hechos sujetos a incertidumbre.
2.2. Evaluar el costo de la recolección de datos.
2.3. Generar formas alternativas de lograr los objetivos.
3.1. Llevar a cabo la construcción del modelo (conceptual o
matemático) para predecir las consecuencias de varias
alternativas - establecer aproximaciones y supuestos sobre
los cuales se basa tal modelación.
3.2. Llevar a cabo los cálculos para explorar las consecuencias
del modelo.
3.3. Evaluar alternativas ponderando el costo contra
efectividad.
3.4. Examinar resultados de 3.3 desde el punto de vista de
sensibilidad a cambios en los parámetros y cambios en los
supuestos.
4. Interpretación (Fase de Juicio).
4.1. Tomar en cuenta los factores no cuantificables, no
medibles.
4.2. Tomar en cuenta la incertidumbre “real” en contraposición
a la incertidumbre “estadística”.
4.3. Presentar conclusiones distinguiendo entre lo que el
análisis muestra y lo que resulta de los juicios.

5. Verificación (Fase Científica).

5.1. Si es posible, probar las conclusiones conduciendo
experimentos.

Ambas metodologías enfatizan un enfoque sistemático a la investigación de problemas, aunque ninguna de ellas considera
la definición básica de un sistema más allá de la definición general, i.e. un conjunto interconectado de entidades. Ambas
hacen considerable énfasis en la definición del problema y en la necesidad de obtener consenso acerca de los objetivos.

Las metodologías resumidas brevemente arriba, relacionadas con diseño de plantas y solución de problemas en general,
representan el área de la ingeniería de sistemas en la cual empezó a operar el Departamento en Lancaster. El primer
profesor de Ingeniería de Sistemas en Lancaster fue Gwylim Jenkins. El estableció que se probara un enfoque particular
para la solución de problemas, a través de la participación en situaciones del mundo real, mediante la participación de
estudiantes de postgrado en asociación con personal del Departamento y los gerentes particulares en las organizaciones
estudiadas.

De esta manera, el ciclo de acción investigación, descrito anteriormente, inició usando una metodología particular de
ingeniería de sistemas “duros”. No es sorprendente, dado el antecedente del personal en esa época, Gwylim Jenkins, un
estadístico con experiencia en las industrias química y del papel; David Rippin, un ingeniero químico con experiencia en
el diseño de plantas y Brian Wilson, ingeniero en control con experiencia en las industrias nuclear y de generación de
energía eléctrica; que los proyectos que se llevaron a cabo fueran “duros” en naturaleza y relacionados con la operación
y diseño de plantas.

La metodología de Jenkins consiste de las siguientes cuatro etapas principales y sus sub-etapas asociadas:

1. Análisis de Sistemas. 2. Diseño de Sistemas.

1.1. Formulación del problema. 2.1. Pronósticos.
1.2. Organización del proyecto. 2.2. Construcción del modelo y simulación.
1.3. Definición del sistema. 2.3. Optimización.
1.4. Definición del supra-sistema. 2.4. Control.
1.5. Objetivos del supra-sistema. 2.5. Confiabilidad.
1.6. Organización del sistema.
1.7. Definición de un criterio económico global.
1.8. Información y recolección de datos.

4
Innovación en Procesos Empresariales

3. Implementación. 4. Operación.
3.1. Documentación y aprobación. 4.1. Operación inicial.
3.2. Construcción. 4.2. Evaluación retrospectiva.
4.3. Operación mejorada.

En resumen, la Metodología de Jenkins intenta ser tanto sistemática como sistémica, aunque los conceptos de sistemas
son únicamente un pequeño subconjunto de lo que ahora se conoce como el modelo formal de sistemas. Todavía hacía
el supuesto de que los sistemas existen en el mundo real; i.e. no se había hecho la distinción entre sistemas físicos
diseñados y sistemas de actividad humana. La medida de “desempeño” está expresada únicamente en términos
económicos. Esto se deriva de la preocupación de que los sistemas deberían funcionar eficientemente. Finalmente, la
metodología está basada en la idea de que el ingeniar el sistema dentro del cual residía el problema, solucionaría dicho
problema.

Los comentarios en el resumen anterior no han sido con la intención de hacer una crítica ya que ellos emergieron de
aprendizajes subsecuentes los cuales han sido derivados de la aplicación de la metodología misma, sino que es útil
reflexionar en lo que se consideraba como dado en esa época. La metodología es igualmente aplicable tanto en el diseño
de una nueva planta o proceso como a la mejora en la operación de una ya existente.

Conforme el tipo de problemas encontrados se volvía más “suave”, se encontró necesario hacer modificaciones a la
metodología. Por ejemplo, se encontró útil derivar medidas de desempeño que no fueran económicas y considerar
fronteras de sistemas que no fueran coincidentes con las fronteras organizacionales. Sin embargo, las dificultades reales
se encontraron cuando se hizo notorio, en general, que los objetivos no podrían ser considerados como algo dado.
Usualmente no hay base para asumir, a cualquier nivel en una organización, que los objetivos publicados realmente
representen lo que se está buscando lograr, o de que haya cualquier cosa parecida a un consenso alrededor de ellos.
Como un ejemplo particular, "¿cuáles son los objetivos de la actividad de servicios administrativos dentro de una
compañía?" representa el tipo de pregunta para la cual es extremadamente difícil obtener una respuesta satisfactoria.

De esta manera, lo que se necesita es una metodología dentro de la cual se pueda hacer una exploración del significado
o implicaciones de adoptar una instancia particular en relación a la situación problemática. Ninguna de las metodologías
de ingeniería de sistemas contiene esta opción, y fue el reconocimiento de esta necesidad lo que produjo el principal
desarrollo a partir de la metodología de Jenkins.

Refiriéndose nuevamente a la Figura 2 y, en particular, a la actividad "Ensamblar un conjunto Apropiado de Conceptos", la

respuesta más general a la pregunta “¿cuál es este ensamble?” la provee lo que ahora se conoce como la Metodología de
Checkland o Metodología de Sistemas Suaves.

Metodología de Checkland

La Metodología de Checkland fue derivada a partir de experiencias y representa la conjugación del aprendizaje logrado
en un gran número de proyectos de “acción-investigación”. Representa un desarrollo de gran magnitud en la historia del
departamento dado que, en retrospectiva, puede ser vista como que representa un cambio de paradigma. Las
metodologías de ingeniería de sistemas están basadas en el paradigma de “optimización” mientras que la metodología de
Checkland considera como paradigma al “aprendizaje”. Este cambio ha sido necesario dada la creciente preocupación por
investigar procesos mal estructurados o suaves, en los cuales no existe tal cosa como respuestas “óptimas” o correctas.

En esencia la metodología puede ser descrita como un proceso de siete etapas de análisis las cuales usan el concepto
de sistema de actividad humana como un medio de pasar de la “investigación” acerca de la situación hacia el “tomar
acción” para mejorar la situación. La Figura 4 ilustra este proceso.

La secuencia lógica ilustrada por esta figura es una manera útil de describir la metodología, pero no representa
necesariamente la secuencia en la cual es usada. La línea punteada representa la frontera entre la actividad que está en
el mundo real y la actividad relacionada con el uso de conceptos de sistemas para estructurar el pensamiento acerca del
mundo real. Sobre la línea el lenguaje de descripción será el lenguaje de todos los días empleado en la situación particular
mientras que debajo de la línea será el lenguaje de sistemas.

5
Innovación en Procesos Empresariales

Figura 4. Metodología de Checkland.

Investigación
Etapas 1 y 2

Las primeras dos etapas tienen que ver con investigar acerca de la situación. La primera es usualmente algún estatuto
acerca de lo que torna a la situación en problemática y algunos hechos básicos acerca de ella. esta habrá, desde luego,
de ser provista por algún individuo o grupo de individuos en la situación misma y será vista como importante para el
interventor (o no importante) de acuerdo a algunos Ws. Parte de la etapa de investigación será tratar de identificar lo que
estos Ws podrían ser y generar preguntas acerca de qué otros Ws podrían también ser relevantes.

Esta etapa es particularmente difícil en la práctica y el interventor debe ser cuidadoso de no imponer su propio W a la
situación. Es el intentar permanecer neutral lo que es difícil y el evitar configurar el análisis subsecuente para que se ajuste
a “soluciones” derivadas previo a la búsqueda y hallazgos de la “investigación” inicial. En su libro, Pensamiento de
Sistemas, Práctica de Sistemas, Checkland (pp. 163-164) tiene lo siguiente que comentar acerca de estas etapas:

Las Etapas 1 y 2 son una fase de “expresión” durante las cuales se hace un intento por construir la imagen o cuadro más
enriquecida posible, no de “el problema” sino de la situación en la cual se percibe que hay que intervenir. La guía más útil aquí
- con todo el interés de ensamblar una imagen sin, tanto como sea posible, imponer una estructura particular sobre ella - es que
este análisis debería ser hecho registrando elementos de lento cambio (estructura) dentro de la situación y elementos de cambio
continuo (proceso), y conformar una visión de cómo las estructuras y los procesos se relacionan unos con otros dentro de la
situación que se está investigando.

A estas relaciones él les llama clima. Los elementos de estructura se definen como aquellos factores relacionados con la
distribución física, jerarquía de poder, estructura de reportar y la manera en cómo se realizan las comunicaciones formales
e informales. Los elementos de proceso están relacionados con las actividades que constantemente se están realizando
como la conversión de materias primas en productos, monitoreo, toma de decisiones y control.

En esta etapa de investigación resulta particularmente útil emplear un Modelo de Diagnóstico. Estos modelos proporcionan
la base para integrar un conjunto de entrevistas estructuradas y coherentes. Este es un uso mucho más eficiente, tanto
del tiempo del interventor como el de los individuos a quienes se entrevista, que un proceso de búsqueda de información
basado únicamente en la generación aleatoria de preguntas. En la práctica los administradores son gente muy ocupada y
tienen su tiempo disponible muy limitado.

Un conjunto de entrevistas bien planeadas ayuda a hacer el mejor uso de este tiempo y a establecer la credibilidad del
interventor y la concordancia en la relación entre el interventor y los administradores. Esto es esencial para las etapas
posteriores en un proyecto si se ha de cultivar la disposición al cambio para que sean aceptadas las recomendaciones.

6
Innovación en Procesos Empresariales

Una de las preguntas que más frecuentemente hacen los estudiantes en relación a esta etapa y una de las más difíciles
de responder es: “¿cómo saber cuándo ya se ha investigado lo suficiente como para proceder a la siguiente etapa, i.e. a
seleccionar un sistema relevante?”. La única respuesta realista, la cual no parece ser de mucha utilidad, es que eso no se
sabe. Uno nunca deja de investigar a lo largo de toda la duración de un proyecto. La metodología en sí misma es un
sistema de aprendizaje y por lo mismo el aprendizaje continúa dándose. Es cuestión de juicio el decidir cuándo seleccionar
sistemas relevantes para el análisis, pero debido a que esta no es una selección única, el interventor aprenderá de la
propia selección hecha y será capaz de modificar la selección basado en el aprendizaje posterior que se haya dado.

De esta forma, en cierto sentido no importa cuándo se haga el paso de la Etapa 2 a la Etapa 3, sino que un buen interventor
de sistemas es aquel cuyos sistemas seleccionados resultan ser relevantes. Por lo general los estudiantes gastan mucho
tiempo en la etapa de búsqueda inicial más que en llevar a cabo el pensamiento de sistemas acerca de lo que se haya
encontrado y utilizar esto para definir lo que aún haga falta de encontrar. Es demasiado fácil el convencerse a sí mismo
de que conforme se estén realizando entrevistas se va progresando, pero esto no es necesariamente el caso.

Selección
Etapa 3

En esta etapa el interventor escoge visualizar a la situación de maneras que él considera que le permitirán obtener un
conocimiento profundo acerca de ésta. Se encuentra ahora en posibilidad de hacer uso del lenguaje de modelación como
un medio para explorar las implicaciones de los puntos de vista seleccionados.

No trata de definir un sistema que debería existir porque, como ya se discutió con anterioridad, “lo que debe de existir”
será visto de manera diferente por los diferentes individuos involucrados. El producir varias definiciones esenciales
ayudará a evitar cualquier análisis utópico que se haga en esta etapa. El consultor está buscando definiciones esenciales
de sistemas que sean relevantes, donde esto significa, relevantes para permitirle obtener un conocimiento profundo acerca
de la situación. En este sentido es legítimo y pudiera resultar de utilidad el considerar a un departamento universitario
como un sistema para suprimir la iniciativa intelectual como una de varias visualizaciones posibles. Muy probablemente
no sean muchos los miembros de la facultad los que estén de acuerdo con este punto de vista, pero puede resultar
fructífera.

Al hacer la selección de sistemas el interventor solo puede utilizar su juicio de que la selección en verdad resulte útil. En
el ejemplo de British Airways presentado anteriormente, se hizo aparente durante las etapas iniciales que existían
considerables diferencias culturales entre aquellos administradores que habían trabajado, antes de la fusión, para British
Overseas Airways Corporation (BOAC) y aquellos que habían trabajado para British European Airways (BEA). Esta
diferencia parecía ser significativa en todos los departamentos entrevistados. de esta forma hubiera sido legítimo, y podría
haber sido muy útil, para British Airways como un todo el haber tomado como un sistema relevante a un sistema
relacionado con la integración cultural dentro de la línea aérea. Sin embargo, el interés expresado era acerca del desarrollo
de sistemas de información para apoyar a la función de mantenimiento de aeronaves y se consideró que se tendría muy
poco avance (en términos de disposición, de parte de los gerentes particulares, para tomar parte en el debate resultante)
si se continuara con el análisis basado en la selección antes citada.

La selección de sistemas relevantes se facilita considerando un rango de posibles procesos de transformación del tipo
entrada/salida y los posibles puntos de vista (Ws) a partir de los cuales puedan ser descritos esos procesos. Pueden
entonces seleccionarse los principales candidatos para el desarrollo de modelos y construirse las definiciones esenciales
utilizando la prueba de CATWDA como se describió en otras lecturas.

Construcción del Modelo

Etapa 4

La definición esencial es un estatuto de lo que el sistema es. La etapa 4 tiene que ver con la expansión lógica de esa
definición en las actividades que el sistema debe hacer para poder ser el mismo sistema que quedó definido. Además de
éstas, están las actividades mínimas y necesarias a un nivel de resolución particular y que, como tales, constituyen el
modelo conceptual. Debe haber un modelo por cada definición esencial. Nuevamente debe incluirse el juicio en esta etapa
en términos del grado de detalle contenido en el modelo conceptual. El modelo de primer nivel de detalle de una definición
esencial no debe contener más de aproximadamente 12 actividades, de otra manera se vuelve muy difícil el poderlas
defender como componentes de un conjunto mínimo y necesario.

7
Innovación en Procesos Empresariales

Frecuentemente se establece que la mente sólo es capaz de retener entre cinco y nueve entidades en un momento dado,
y por lo mismo la expansión del modelo en una sola etapa debe ser únicamente de este orden. Esto es probablemente
cierto si las entidades son independientes, pero dado que un modelo conceptual contiene entidades interdependientes
(i.e. actividades y sus conectividades) probablemente sea factible tener un número ligeramente mayor. Un modelo de
primer nivel de detalle con esta restricción en la cantidad de actividades contenidas puede estar a un nivel demasiado
general como para permitir hacer una comparación que sea de utilidad.

Puede incrementarse el detalle redefiniendo cada actividad (o un conjunto seleccionado de actividades) como el sistema
y, a través del mecanismo de la definición esencial, producir un modelo de segundo nivel de detalle. Aun aceptando la
menor de las restricciones mencionadas con anterioridad, el modelo de segundo nivel puede llegar a ser del orden de las
80 actividades. Creo que es útil hacer una comparación en cada etapa de la construcción del modelo. Se ha hecho una
comparación intuitiva al nivel de las definiciones esenciales y es sobre esta base que se dice que los sistemas sean
relevantes. Vale la pena hacer una comparación superficial al primer nivel de detalle para apoyar esa creencia. Si la
comparación a este nivel sugiere que puedan hacerse selecciones alternativas o que pudieran resultar útiles algunas
modificaciones a las definiciones esenciales originales, entonces el interventor no habrá desperdiciado su tiempo
elaborando los modelos originales. Vale la pena repetir el mensaje de que los modelos no son un fin en sí mismos. Se
desarrollan para servir a un propósito y, aunque el interventor puede encontrarse cómodo al estar temporalmente aislado
del mundo real mientras realiza esta actividad intelectual, es necesaria la continua inmersión en el mundo real si es que
el análisis ha de retener el contacto con él.

Debido a que estos modelos son conceptuales, y debido también a que se derivan a partir de definiciones esenciales en
las cuales se ha hecho un compromiso al 100% con un solo W, no pueden ser validados en el sentido que lo es un modelo
de investigación de operaciones de un proceso de producción. Sin embargo, dado que son modelos de sistemas de
actividad humana, pueden verificarse contra el modelo formal de sistemas.

Esta es la razón de incluir la etapa 4a en la figura 4. La etapa 4b se incluye para poder obtener ayuda de otras formas de
pensamiento de sistemas si así se considera apropiado. Debido a la naturaleza tentativa de las selecciones de sistemas
relevantes hechas en la etapa 3, vale la pena hacer las etapas 3 y 4 rápidamente y continuar a la etapa 5, la etapa de
comparación, para poder regresar los modelos al mundo real para probar su grado de relevancia.

Comparación
Etapa 5

Aunque esta etapa se denomina comparación, estrictamente hablando esto no es correcto dado que no se está
comparando algo de igual a igual. Los modelos conceptuales están en términos de actividades y por lo mismo describen
un conjunto de "que". Definen lo que debe suceder en un sistema descrito mediante una definición esencial particular. En
el mundo real el interventor observará un conjunto de "como". La distinción entre “que” y “como” es muy importante; sin
embargo, también puede provocar confusión. Vale la pena discutir esto en más detalle previo a una discusión de las formas
en las que puede llevarse a cabo una comparación.

La Distinción “Que” y “Como”

Un “que” no puede ser implementado sin antes y, primero que nada, decidir “como” hacerlo. Esto implica la
selección de un conjunto de “como” alternativos. Por ejemplo, si lo “que” usted desea es "invertir su dinero
disponible", no puede hacerlo sin seleccionar uno, o más, “como” del siguiente conjunto: depositarlo en una cuenta
bancaria; comprar certificados de ahorro; comprar un terreno, etc. En principio no es posible revertir este proceso
y decidir, con toda certeza, la naturaleza del “que” que se encuentra detrás de un “como” observado.

Por ejemplo, si usted observa a alguien comprando una pintura, usted no puede saber si el “que” es "invertir el
dinero disponible", "agregar a una colección", o el "tenerla en posesión para una posible reventa", es este aspecto
de la relación lo que complica la etapa de comparación. Lo que se observa en una situación de innovación es la
combinación resultante de muchos “como” seleccionados.

La comparación se complica todavía más debido a la característica de que no tiene que haber una correspondencia
de uno a uno entre los “que” y los “como”: esto se ilustró con el ejemplo de la planta química, donde las actividades
“mezclar” y “reaccionar” se hacían ambas en una sola unidad, el reactor.

8
Innovación en Procesos Empresariales

Estos dos aspectos de la relación dan pauta a que se

presenten complicaciones, pero el aspecto que causa
confusión es el hecho de que un “como” es también un “que”.
De tal manera que "comprar una pintura" (un “como” de
"invertir el dinero disponible") es también un “que” para el
cual puede haber una variedad de posibles “como”, tales
como "visitar una galería de arte", "asistir a una subasta", etc.
La clave para entender, y hacer uso de, la distinción es a
través del concepto de nivel de detalle o de resolución.

Tanto la selección de un “como” alternativo y la expansión de

una actividad hacia un nivel de resolución más detallado, se
logran respondiendo a la pregunta "¿cómo?". La Figura 5
ilustra las dos posibilidades.

El lado derecho de la figura representa el proceso de

selección. De esta forma, si la respuesta a la pregunta
“¿cómo?” es A o B o C o D, la respuesta representa el “como”
se ha de hacer la actividad al mismo nivel de resolución.

Si, como en el lado izquierdo de la figura, la respuesta es A

Figura 5. Respuestas a la Pregunta ¿Cómo?
y B y C y D y E, entonces esto representa el conjunto de
“que” al siguiente nivel de resolución, i.e. una expansión más
detallada de la actividad original. de esta manera, el
relacionar una actividad con el nivel de resolución alrededor
del cual esté centrada la discusión evitará la confusión y
permitirá aplicaciones útiles de la distinción “que” / “como”.

En general, un modelo conceptual consistirá de un conjunto interconectado de “que” al nivel de resolución particular que
sea utilizado para la comparación. Los “como” específicos solo podrán aparecer al mismo nivel de detalle si se introducen
como restricción a través de la definición esencial. De tal manera que, si nuestro interés consistiera en desarrollar un
modelo operativo para una de las principales empresas fabricantes de automóviles, nuestra definición esencial podría
contener la siguiente transformación: “Ensamblar componentes para integrar vehículos terminados utilizando la tecnología
de producción en masa”. Esta transformación contiene el “que” (ensamblar componentes para integrar vehículos
terminados) pero también le restringe a un “como” particular (utilizando la tecnología de producción en masa). Habiendo
introducido esta restricción a la definición esencial (i.e. como uno de los elementos de Ambiente (segunda A) en CATWDA),
el modelo conceptual debe contener actividades que también estén restringidas por este “como” particular. No es legítimo
introducir “como” particulares al modelo conceptual sin, antes que nada, hacerlos explícitos en la definición esencial tal
como se hizo en el ejemplo arriba citado.

Las restricciones de este tipo no deben de incluirse a menos que, de acuerdo al juicio del consultor, sean necesarias. El
propósito de los modelos es iniciar un debate acerca de lo que existe y acerca de cómo es que existe, para poder introducir
cambios. La introducción de restricciones reduce las opciones disponibles. Puede, por supuesto, argumentarse que en el
ejemplo anterior este fabricante de automóviles en particular no va a abandonar la producción en masa como método de
ensamble y, por lo mismo, la restricción tiene que incluirse si ha de decirse que la selección del sistema resulte relevante.
En el otro extremo, si todos los “como” existentes se incorporan a las definiciones esenciales, los modelos terminarán
describiendo lo que existe y no se tendrá la base para un debate acerca del cambio.

Métodos de Comparación

Reflexionando sobre la variedad de proyectos que han sido llevados a cabo, han surgido cuatro métodos de
comparación como los más frecuentemente utilizados. Estos son: una discusión general; generación de preguntas;
una reconstrucción histórica; sobreposición de modelos.

Independientemente del método utilizado, el interventor necesita, antes que nada, decidir en qué lenguaje se va a
llevar a cabo la comparación.

9
Innovación en Procesos Empresariales

Es en este punto en esta metodología en particular que se lleva a cabo la transición entre el hacer el análisis en
un lenguaje de sistemas y debatir el resultado de ese análisis en el lenguaje del mundo real. Por ello, a menos
que los administradores que tomen parte en ese debate también estén familiarizados con el lenguaje de sistemas,
el interventor debe traducir la comparación a su lenguaje. En general, el intentar discutir las definiciones esenciales
y los modelos conceptuales es la manera más rápida de acabar con el debate. Esto no es exagerado, ni es una
característica de este tipo de análisis.

El primer método de comparación se relaciona con una discusión general acerca de la naturaleza de los modelos,
y cualquier organización que ellos impliquen, cuando se relacionan con la naturaleza de lo que se cree que existe.
De esta manera, tienden a surgir durante este tipo de discusión los aspectos estratégicos en relación al rol y a la
existencia de ciertas actividades más que con aspectos a un nivel de detalle muy operativo. La discusión más útil
de este tipo se da cuando todos los participantes están familiarizados con el lenguaje de sistemas.

El segundo método de comparación, la generación de preguntas, es el más comúnmente utilizado. Este método
ya ha sido descrito con anterioridad en este material de apoyo en los comentarios relacionados con la etapa de
búsqueda inicial. Sin embargo, en esta etapa, cuando los resultados de la comparación van un paso más allá a
través de un conjunto de recomendaciones para el cambio, en lo personal realizo la comparación de una manera
más formal a través de un arreglo. La figura 6 muestra un ejemplo.

Las columnas 1, 2, y 3 representan los resultados del proceso de investigación mediante un conjunto de preguntas
al que se hizo referencia con anterioridad. dado que no es posible identificar con certeza los “que” que están detrás
de los “como” del mundo real, las preguntas se realizan en el sentido opuesto, como en la columna 2, basadas a
partir de un conjunto de “que” de un modelo coherente. Un método para identificar los “como” es determinar, antes
que nada, cuál sería el resultado del “que” y preguntar si es que ese resultado existe o no. Por ejemplo, si el “que”
es "programar la producción", el resultado sería un documento con un programa de producción. Si se cuenta con
tal documento, entonces puede decirse que la actividad existe, independientemente de si se hace bien o no.

Figura 6. Elementos para Realizar una Comparación.

Las columnas 4, 5 y 6 representan los resultados de la evaluación de lo que existe y la base sobre la cual se
realiza tal evaluación. Todo esto se encuentra en el lenguaje de la situación y consiste de los cambios propuestos
junto con la evidencia en el mundo real que apoye a las recomendaciones.

Es en esta etapa que se lleva a cabo la traducción del lenguaje, (a la cual se hizo referencia con anterioridad) y
es el contenido de estas columnas lo que se comunica a las personas en la situación problemática.

El tercer método de comparación, la reconstrucción histórica consiste esencialmente en reconstruir una secuencia
de eventos de acuerdo a un modelo conceptual y luego comparar esta secuencia con lo que en realidad haya
sucedido.

10
Innovación en Procesos Empresariales

Si se ve como un medio de recriminación acerca del desempeño pasado, más que como una forma de obtener
algún aprendizaje de él, puede producir el antagonismo de los participantes.

El método final de comparación, la sobreposición de modelos, consiste en la estructuración del modelo conceptual
de manera que refleje tan cercanamente como sea posible la situación problemática existente y, literalmente,
sobreponer una imagen sobre otra (siendo una de estas dibujada en papel transparente). Las diferencias entre las
dos se vuelven aparentes inmediatamente. He utilizado este método con mucho éxito en proyectos relacionados
con estructura organizacional donde uno está comparando fronteras de toma de decisiones en un modelo de
sistemas con las áreas de autoridad de una organización existente.

Recomendaciones para el Cambio y Acción para Implementación

Etapas 6 y 7

Las comparaciones de la Etapa 5 habrán generado un conjunto de recomendaciones para el cambio sobre las cuales
puede decirse que se consideran deseables, y se habrán obtenido evidencias acerca de las áreas relevantes que apoyen
esa visión.

Estaría fuera de la realidad, sin embargo, esperar que el conjunto completo se considere aceptable. Un cambio particular
puede parecer racional para el interventor, pero para un administrador quien ha vivido una historia muy particular, quien
tiene que hacer frente a las relaciones particulares y a las políticas internas (todo lo cual ayuda a moldear su W), puede
parecer cualquier cosa excepto racional. Para poder derivar cambios que puedan ser implementados necesitan cumplirse
dos criterios. Deben ser deseables en base al análisis de sistemas y deben ser también culturalmente factibles dadas las
características de los administradores particulares en su muy particular situación.

Aunque es intelectualmente una actividad separada de la comparación, una evaluación de la factibilidad puede llevarse a
cabo de manera simultánea mientras estén participando los administradores relevantes. Los comentarios acerca de ella
pueden integrarse como una columna adicional en la tabla de la Figura 6.

Una vez que se ha conformado el conjunto de cambios aceptables se vuelve necesario definir cómo es que han de ser
implementados, i.e. determinar aquellas acciones necesarias para la innovación de los procesos. Durante la evaluación
de la aceptabilidad y de la factibilidad tendrá que hacerse una revisión de los “como” alternativos.

El cambio puede involucrar tanto el moverse de un “como” a otro, como la implementación de un nuevo “que” a través de
la selección de un “como”. La acción para introducir el cambio debe estar relacionada con aquellas modificaciones
estructurales y de procedimientos que sean necesarias para ajustar las recomendaciones. Los cambios en actitudes
pueden considerarse también como benéficos, pero yo no creo que, en relación a los cambios de este tipo, que puedan
definirse acciones específicas las cuales produzcan un resultado esperado. Es este aspecto lo que diferencia a los seres
humanos de los autómatas y, por lo mismo, los cambios deberían definirse como factibles dentro del contexto de las
actitudes prevalecientes. La necesidad de implementar los cambios puede ser vista como otra situación dentro de la misma
situación, para lo cual puede aplicarse la metodología como una herramienta de diseño. En esta etapa pueden
desarrollarse una definición esencial y un modelo conceptual de un sistema temporal de implementación el cual habrá de
existir hasta el momento en que se reconozca que los cambios han sido implementados. Dado que tal sistema no existe,
la comparación sólo puede ser llevada a cabo contra las expectativas que se tengan en mente. cada uno de los “que” en
el modelo tendrá que ser convertido a un “como” deseable y factible antes de proceder con la implementación. La
factibilidad y la deseabilidad estarán basadas en estas expectativas.

Aunque tendrá que derivarse cada definición esencial y su correspondiente modelo para situaciones específicas, puede
desarrollarse un modelo general a partir de la siguiente definición:

Un sistema propiedad de, y administrado por la organización para la efectiva implementación (en términos económicos)
de un conjunto de cambios acordados a las estructuras y los procesos existentes de forma que resulte aceptable para
la organización y a los sindicatos apropiados y la cual minimice el rompimiento no intencionado de la situación social.

Un modelo resultante de esta definición esencial se presenta en la figura 7. Debe enfatizarse que éste sólo se incluye como
una guía y no como un estatuto definitivo de lo que es un sistema de implementación.

11
Innovación en Procesos Empresariales

Figura 7. Un Sistema de Implementación.

Se señaló con anterioridad que la metodología de Checkland sería descrita como un proceso paso a paso, recorriendo las
Etapas de la 1 a la 7. También puede ser utilizada en esta forma; sin embargo, es más útil considerarla como un modelo
de ejemplo de actividades que puede ser usado en cualquier orden y partiendo de cualquier punto. El interventor que la
emplee necesitará tener muy claro en todo momento que lo que él está haciendo es indagar acerca del mundo real, o
pensar en términos de sistemas, o debatir acerca del cambio por medio de una comparación. En la práctica todas estas
actividades pueden combinarse, pero, intelectualmente, es necesario hacer explícita la distinción para que el análisis
resultante pueda ser coherente.

Independientemente del punto de partida, usualmente ocurre un importante proceso de iteración durante el transcurso de
las Etapas 2, 3, 4, y 5 y, para que pueda hacerse de manera efectiva, el interventor necesita estar pensando en lo que
habrá de acontecer posteriormente. De tal manera que mientras se esté formulando una definición esencial, él puede estar
pensando acerca de la clase de actividades que aparecerán en el modelo y los posibles resultados de una comparación.
Esto ayuda a la generación de definiciones esenciales que sean relevantes; no para coincidir con el mundo real sino para
conducir a un debate útil acerca del mundo real.

Haciendo referencia a la Figura 2, lo que se ha descrito aquí es la conformación más general del conjunto de conceptos
de sistemas que ha surgido del programa de acción-investigación. En cualquier proyecto vale la pena, formalmente, crear
una imagen de la situación, el “sistema que contiene la situación a innovar” y del “sistema que proporcione la innovación
al proceso” que está relacionado con tal situación. De esta manera el (los) interventor (es) puede(n) hacer la pregunta:
"¿cuál es el conjunto apropiado de conceptos de sistemas, dentro de este sistema que innova en la situación, para la
naturaleza de la investigación que se está llevando a cabo?"

De esta forma, el interventor puede conformar el conjunto de sistemas que, para él, resulten razonables, dada su propia
experiencia y la de aquellos que conforman el resto del conjunto de recursos humanos para la solución del problema, y el
tipo de situación a la cual estos conceptos habrán de ser aplicados. El lenguaje de sistema es un lenguaje muy poderoso
cuando uno confronta a una situación que es “suave”. Para poder ser efectivo en su uso y en el uso de otros lenguajes de
sistemas, el interventor debe permanecer orientado hacia la situación y tomar muy seriamente la operación de los dos
sistemas de control en el modelo de la figura 2. Esto demanda flexibilidad tanto en la integración como en el uso de los
conceptos de sistemas en general, sobre el rango que va de los “duro” a lo “suave”.

12
Innovación en Procesos Empresariales

Se ha presentado una investigación de algunas de las metodologías de ingeniería de sistemas para el diseño y
mejoramiento de procesos, así como algunas de las primeras metodologías generales para la innovación. Estas
representaron el punto de partida para el desarrollo de la metodología de sistemas “suaves” la cual ha sido descrita en
mayor detalle en este material de apoyo.

En conclusión, deseo enfatizar la necesidad de ser flexible en el uso e integración de conceptos. Esto es esencial si uno
desea permanecer orientado a la innovación debido a la diversidad que existe en el mundo real.

Para Saber Más:

Wilson, Brian (1990), Systems: Concepts, Methodologies and Applications, Second Edition, John Wiley
& Sons, Chichester, England.

Ing. Pedro A. Nolasco G. MC | MA | CPIM | CLTD | CSCP

13