Sunteți pe pagina 1din 24

MODELADO DE PROCESOS DIAGRAMA DE

FLUJO DE DATOS ESPECIFICACIÓN DE


PROCESOS
Modelado de procesos

Tradicionalmente el modelado de procesos ha estado enfocado en el análisis del flujo y


transformación de datos. La utilización de las computadoras en tecnología de
información no había sido usada más allá del procesamiento de transacciones, como en
la comunicación y control. Para hacer una integración satisfactoria de estos sistemas
dentro de la empresa, se requiere de modelar desde los procesos organizacionales
manuales en los que intervienen estos sistemas.

Algunos ejemplos de esto, son:

 La reingeniería de procesos de negocios, la cual se encarga del rediseño de los


procesos de negocios de las organizaciones con el fin de hacerlos más eficientes.

 Tecnología de coordinación, que ayuda en el manejo de las dependencias entre los


agentes de un proceso de negocios, y provee soporte automatizado para los
componentes más rutinarios del proceso.

 Ambientes de desarrollo de software dirigidos por el proceso, que es un sistema


automatizado que integra el trabajo de toda la administración y personal relacionado
con el software.

El modelado de procesos se distingue de otros tipos de modelado en las áreas de la


computación, porque los fenómenos modelados son realizados más por humanos que
por máquinas. También porque se centra en las interacciones entre los agentes,
independientemente de si una computadora está envuelta en las transacciones.

Usos para los modelos de procesos

Frecuentemente la gran cantidad de descripciones del ciclo de vida del software que
almacenan las organizaciones, no corresponde con el proceso actualmente llevado a
cabo en el desarrollo o mantenimiento del software. Esta falta de fidelidad es causada
por factores como:

 Prescripciones del proceso de alto nivel que no están relacionadas con las actividades
actuales del proyecto.
 Descripciones no utilizadas, imprecisas, ambiguas, incomprensibles, del proceso a
ser representado en el proyecto, y
 Fallas en la actualización de la documentación cuando ocurren cambios en el
proceso.

Tradicionalmente las descripciones del ciclo de vida son vistas como modelos del
proceso, pero estas normalmente se centran en una abstracción de la ingeniería del
producto, y fallan al mostrar muchos bloques de construcción del proceso elementales,
necesarios para manejar y coordinar el proyecto.

Cinco usos básicos de los modelos de procesos son:


1. Facilitar el entendimiento y comunicación humanos, requiere que un grupo pueda
compartir representaciones de formatos comunes.

2. El soporte para la mejora de procesos requiere una base para definir y analizar los
procesos.

3. El soporte para la administración de procesos requiere un proceso definido, contra el


cual el comportamiento del proyecto pueda ser comparado.

4. La conducción automática del proceso requiere herramientas automatizadas para


manipular descripciones de procesos.

5. El soporte para ejecución automática requiere bases computacionales para controlar


el comportamiento de un ambiente automatizado.

Estructura conceptual

Un proceso es una secuencia de pasos o actividades ordenadas necesarias para el


logro de un objetivo.
Un elemento del proceso es cualquier componente del proceso.
Un paso o actividad es una acción atómica de un proceso, que no tiene una estructura
externamente visible.
Un agente es un actor que desempeña algún elemento del proceso.
Un rol es un conjunto coherente de elementos del proceso que son asignados a un
agente como una unidad de responsabilidad funcional.
Un artefacto es un producto creado o modificado por la ejecución de un elemento del
proceso.
Un script del proceso, es un modelo del proceso que será desempeñado por un
humano.
Un programa del proceso, es un modelo del proceso que será ejecutado por una
máquina.

Perspectivas en la representación de procesos

Cuatro de las más comunes perspectivas representadas son:

Funcional.- Representa que elementos del proceso están siendo ejecutados y que
entidades de información son relevantes a estos elementos del proceso.

De conducta.- Representa cuando los elementos del proceso son ejecutados, asi
como aspectos de cómo son ejecutados a través ciclos, iteraciones, toma de decisiones
complejas, criterios de entrada y salida, etc.

Organizacional.- Representa donde y por quién en la organización, se ejecutarán los


elementos del proceso, los mecanismos físicos de comunicación usados en las
transferencias de entidades, y el medio y localización físico, usado para el
almacenamiento de entidades.

De Información.- Representa las entidades de información producidas o manipuladas


por un proceso. Esta representación incluye la estructura de las entidades de
información y sus relaciones entre ellas.
Estas representaciones presentan distintas ventajas desde el punto en que cada una
puede ver y observar el proceso. Podemos asumir que combinando estas perspectivas
produciremos un modelo integrado, consistente y completo del proceso analizado.

Paradigmas del modelado de procesos

Los lenguajes y representaciones para modelado de procesos pueden ser evaluadas en


la medida de que tantas construcciones útiles proveen para representar y razonar
acerca de varios aspectos de un proceso.
Osterweil presentó el siguiente problema : “para encontrar que características de un
lenguaje necesitamos, debemos escribir programas de procesos: para escribir
programas de procesos, necesitamos características adecuadas de algún lenguaje”.

Cinco aproximaciones para representar procesos son:

Modelos de programación.- Esta aproximación parte de la observación de que la


especificación de un proceso es una forma de programación, por lo tanto un proceso
puede ser modelado con todas las técnicas y herramientas de los programadores.

Modelos funcionales.- Un proceso es representado como una colección de elementos


con atributos de entrada y de salida. Específicamente, un proceso se define como un
conjunto de funciones matemáticas que representan relaciones entre entradas y
salidas. Además, cada una de estas funciones puede ser descompuesta
jerárquicamente en sub-elementos del proceso donde los atributos de entrada y salida
de un elemento padre deben ser satisfechos por los atributos de sus hijos.

Modelos basados en plan.- Este paradigma provee mecanismos donde los


operadores representan posibles acciones que son seleccionadas con base en sus
precondiciones. Estos operadores son aplicados al estado actual del domino en el que
el proceso opera, con el fin de acercar más ese estado al objetivo deseado.

Modelos redes de Petri.- Esta técnica modela la estructura de interacción de roles de


un proyecto usando un lenguaje y una representación basados en redes de Petri. Las
redes de interacción de roles ayudan a la representación y ejecución de tareas
estructuradas, que son aquellas que pueden ser planeadas por dependencias
conocidas.

Modelos cuantitativos.- Sistemas dinámicos es una de las pocas técnicas de


modelado que involucra representaciones cuantitativas, y aplica retroalimentación y
técnicas de sistemas de control a fenómenos sociales e industriales. Los modelos
construidos de esta manera intentan definir un conjunto de relaciones cuantitativas
entre variables de interés que simulan el comportamiento observado del sistema
social.

Formalidad del modelado de procesos

El nivel de matemática formal requerida en un lenguaje de modelado de procesos,


puede depender del propósito para el cual sirve el modelo del proceso y el agente
responsable de la ejecución del proceso especificado. Un lenguaje formal es mas fácil
de manejar para una máquina que para un humano. Desafortunadamente, el interés
en el entendimiento y la comunicación humana, ha recibido menos atención que las
máquinas, y las definiciones y modelos de procesos no pueden ser de utilidad si no son
entendibles.
Granularidad y precisión

La granularidad envuelve el tamaño de los elementos del proceso representados en el


modelo. La necesidad de una mayor granularidad, es conducida por la necesidad de
asegurar la precisión en el proceso.

Adaptabilidad y Scriptiveness

Los modeladores de procesos difieren en como las prescripciones que ellos pretenden
que sus modelos sean del actual comportamiento a ser desempeñado. Un modelo
prescriptivo implica que el proceso se debe llevar a cabo de una manera particular.

El modelado descriptivo intenta determinar el proceso actualmente utilizado en una


organización para realizar el trabajo, es decir un proceso de la organización que sirva
de línea base.

Una tercera perspectiva es ofrecida por los modelos proscriptivos, que delinean los
comportamientos no permitidos.

Direcciones futuras

Se han estado realizando trabajos y estudios para acelerar el crecimiento del modelado
de procesos, tales como los esfuerzos por realizar un ejemplo que involucre la mayor
parte de los aspectos del modelado de procesos de software, a fin de que provea bases
importantes para el entendimiento, comparación y evaluación de distintas
aproximaciones de modelado.

Representaciones multiparadigma.- La aplicabilidad de un acercamiento de modelado


dependerá de los objetivos del modelo resultante. Un tipo de lenguaje dado será mejor
aplicable para algunos objetivos del modelado que otros. Para un modelado de
procesos de software efectivo, se considera necesario la integración de múltiples
paradigmas de representación, sin embargo esto genera nuevos retos y problemas.
Uso en el mejoramiento de procesos.- Cuando se elimina el ruido creado por una pobre
definición o mal manejo de un proceso, el impacto de la tecnología es mas fácilmente
observado en los proyectos. Por lo tanto algunas compañías de software se han
enfocado a definir los procesos del negocio de software, y solo una ves hecho esto, se
seleccionan las herramientas y métodos que soporten estos procesos.

Esto provee el fundamento para una productividad y calidad en crecimiento.


Uso en la administración de proyectos de software.- Un grupo creciente de trabajo se
ha enfocado a usar el modelado de procesos para soportar la administración del
desarrollo y evolución de software. Este soporte permite a los administradores realizar
planes de tareas, costos y recursos mientras varia el requerimiento de recursos y se
adecua un modelado determinista o estocástico.

Ambientes de desarrollo de software basados en el proceso.- Se trata de desarrollar


ambientes dirigidos por el proceso. Debido a la ausencia de un proceso de software
definido, es difícil identificar:

 La suite completa de herramientas necesarias para soportar el proceso entero.

 Como pueden ser integradas estas herramientas para soportar el trabajo actual
y

 Como diseñar un ambiente de desarrollo de software que coordine el trabajo de


muchos ingenieros de software.

DIAGRAMAS DE FLUJO DE DATOS

OBJETIVOS
Construir un modelo lógico del sistema que facilite la comprensión del mismo, tanto
por parte de los usuarios como del equipo de desarrollo.

Para ello se dividirá el sistema en distintos niveles de detalle. Esta división permitirá:
 Simplificar la complejidad del sistema, representando los diferentes procesos
sencillos de que consta un sistema complejo.
 Repartir el trabajo entre los diferentes miembros del equipo de
desarrollo. Facilitar el mantenimiento del sistema.
Los fundamentos de la técnica del Diagrama de Flujo de Datos (DFD) son los
siguientes:
 Representar gráficamente los límites del sistema en estudio.
 Mostrar el movimiento de los datos y la transformación de los mismos a través
del sistema.
 Diferenciar las restricciones físicas de las lógicas.

Para conseguir estos objetivos el resultado del análisis debe ser:


 GRÁFICO.
 LÓGICO, nunca referido a entornos físicos.
 PRECISO Y BREVE.
 COMPRENSIBLE.
 DEBIDAMENTE PARTICIONADO.
 BIEN DOCUMENTADO.
 NUNCA REDUNDANTE.
 ESTABLECERÁ "QUÉ" FUNCIONES SE DEBEN DESARROLLAR, SIN IMPLICAR
"CÓMO".
 NO AMBIGUO.

Como resultado se obtendrá un modelo del sistema completamente independiente de


las restricciones físicas del entorno, lo que facilitará su mantenimiento y portabilidad.
En los Diagramas de Flujo de Datos, no se deberán modelizar:
 PROCEDIMIENTOS.
 PUNTO DE INICIO Y DE TERMINACIÓN DEL DFD.
 CONDICIONES.
 TRATAMIENTOS DE ERRORES POCO RELEVANTES.

ELEMENTOS BÁSICOS DE LOS DIAGRAMAS DE FLUJO DE DATOS

En cualquier Diagrama de Flujos de Datos, aparecerán los objetos siguientes:


 ENTIDAD EXTERNA.
 PROCESO.
 ALMACÉN DE DATOS.
 FLUJO DE DATOS.

Algunos de ellos podrán tener alguna restricción con respecto únicamente al nivel en el
cual pueden o deben aparecer. Esto ya se detallará más adelante.

La técnica de representación dará lugar a un DFD (Diagrama de Flujo de Datos) en


el que se irán detallando los principales procesos o acciones a desarrollar y que se irán
detallando en mayor medida según se vaya bajando de nivel (EXPLOSIONANDO) cada
uno de esos procesos.
La comunicación existente entre esas actividades se representa entre el resto de los
elementos.

DIAGRAMA DE FLUJO DE DATOS

El DIAGRAMA DE FLUJO DE DATOS (DFD) proporciona una representación del


sistema a nivel lógico y conceptual. Utiliza una notación y unas reglas
predeterminadas.

ENTIDAD EXTERNA
Las Entidades Externas representan entes ajenos a nuestra aplicación, pero que
aportan o reciben información de la misma. Se representa mediante una elipse o un
rectángulo con un nombre significativo dentro.
Reglas de construcción:
1. Representa personas, organizaciones o sistemas que no pertenecen al sistema.
2. En el caso de que las entidades externas se comunicasen entre sí, esto no se
contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema.
3. Puede aparecer en los distintos niveles de DFD.
4. Puede aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos
de líneas.
5. Suministra información acerca de la conexión del sistema con el mundo exterior.

PROCESO
Es una actividad que transforma o manipula datos. Se representa mediante un
rectángulo, de la siguiente manera:

En la parte de PROCESO se expresa el nombre del proceso correspondiente.


Dependiendo del nivel de detalle en que nos encontremos dentro de un DFD, el
nombre del proceso simbolizará bien el sistema concreto (nivel sistema), bien el
subsistema de que se trate (nivel subsistema), o bien acciones concretas y detalladas
en niveles inferiores.

En la parte superior izquierda se coloca un número identificativo del proceso. Este


número permitirá además indicar el nivel del DFD en que nos encontramos; esto se
explicará más en detalle cuando se hable de la descomposición por niveles.

Es importante hacer énfasis en que este número no indica secuencia de realización del
proceso, dado que los DFD no representan una secuencialidad en el tratamiento de los
datos.

La parte de localización expresa la Unidad o área dentro de la organización donde se


realiza este proceso.

Reglas de construcción:

1. Cuando un Flujo de datos entra en un proceso sufre una transformación. Un proceso


no es ni origen ni final de los datos, sólo lugar de transformación de los mismos. Por
ello, cualquier flujo de datos que entre en un proceso ha de transformarse (ver Figura
DFD3).
2. Un proceso puede transformar un dato en varios.
3. Es necesario un proceso como intermediario entre una Entidad Externa y un
Almacén de Datos.

ALMACÉN DE DATOS
Un almacén de datos representa un depósito de información dentro del sistema.

Se representa dentro del DFD con la siguiente Figura:

En la parte derecha se indica el nombre del almacén de datos. En la parte izquierda se


representa la identificación de dicho almacén dentro del DFD.

En el caso de que dentro de un DFD aparezca repetido el mismo almacén de datos, se


puede representar de la siguiente forma:

Es conveniente distinguir las diferentes utilidades que presentan los almacenes de


datos. En primer lugar, el almacenamiento permanente de datos, donde se guardan los
datos que sirven de referencia de uso del sistema, es decir, los datos permanentes,
sobre los que el sistema necesita guardar información (ALMACENES PRINCIPALES).

Por otra parte, el almacenamiento transitorio de los datos antes de ser usados por un
proceso. Para entender el significado de estos almacenes transitorios, se puede
imaginar la situación del ejemplo de la Figura DFD5.

En este ejemplo el proceso RECOGER SOLICITUDES, que se ejecuta continuamente a


lo largo de la jornada, genera los datos de salida representados por el flujo de datos
SOLICITUDES. Estos datos constituyen los datos de entrada al proceso VALIDAR
SOLICITUD, que se ejecuta al final de la jornada, en el intervalo esos datos de solicitud
"reposarían" en el almacén SOLIC-PROV, cuya utilidad básica es establecer una
sincronización en el funcionamiento de ambos procesos.

Los almacenes transitorios suelen representar restricciones físicas del sistema y por
tanto en un DFD, que expresa la lógica de los tratamientos realizados por el sistema,
en muchos casos no será necesario representarlos. Sin embargo hay ocasiones en que
estos almacenes simbolizan "ficheros de movimientos", donde se guardan los datos
porque el proceso siguiente necesita manejarlos todos al mismo tiempo (por ejemplo,
en un proceso que compara un conjunto de registros, será necesario mantenerlos
guardados en un almacén transitorio, para que dicho proceso los lea todos al mismo
tiempo). En este caso sí será conveniente representarlos.

Por último, para asegurar la consistencia entre todas las técnicas utilizadas en la Fase
de Análisis, se establecerá una relación precisa entre los almacenes de datos
"principales" de un DFD y las entidades de los Diagramas de Estructura de Datos
(DED): cada almacén principal de un DFD representa un conjunto completo de
entidades del DED (una o varias entidades), y cada entidad de un DED pertenece a un
único almacén principal de un DFD; esto facilitará las validaciones cruzadas entre los
dos diagramas.

Reglas de construcción:
1. Representa la información en reposo.
2. No puede crear, destruir ni transformar datos.
3. No puede estar comunicado directamente con otro Almacén o Entidad Externa.
4. El flujo de datos (Entrada o Salida) no lleva nombre cuando incide sobre su
contenido completo.
5. El almacén de datos aparecerá por vez primera en aquel nivel en que sea accedido
por dos o más procesos y en modo lectura y/o escritura.
6. No debe estar referido al entorno físico y por tanto, no se diferencian los ficheros
convencionales de las Bases de Datos.
7. No se representa la clave de acceso a ese almacén sino sólo la operación que se
realiza (lectura, escritura, actualización)

FLUJO DE DATOS

Los Flujos de Datos establecen la comunicación entre procesos, almacenes y entidades


externas, y llevan información necesaria para esos objetos.
Reglas de construcción:
1. El concepto de flujo de datos es similar al de una "tubería" a través de la cual fluye
una información de estructura conocida.
2. Los datos no pueden ser creados ni destruidos por un flujo de datos.
3. Sirve para conectar el resto de los componentes del DFD.
4. No es un activador de procesos.
5. Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la
dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el
almacén.

Conclusiones:

Existen diversas perspectivas para representar un proceso, así como diferentes


maneras o paradigmas para modelarlos desde las distintas perspectivas. Debido a la
variabilidad de los procesos que pueden presentarse en una organización, resulta difícil
estandarizar una manera de representarlos.

Ya que cada representación se centra en distintos aspectos del proceso. Puede


ayudarnos el mezclar varias de estas perspectivas y paradigmas a fin de capturar
todos los aspectos del proceso. Aunque en el artículo se menciona que se están
haciendo esfuerzos por desarrollar herramientas que manejen un paradigma que
envuelva todos las representaciones del modelado de procesos, a mi forma de ver,
esto resultaría poco factible para su utilización en la mayor parte de las
organizaciones, ya que el sistema resultante sería demasiado robusto y costoso, y con
características que quizá no fueran de utilidad en la mayor parte de los procesos a ser
modelados. Una solución a esto podría ser desarrollar distintos sistemas más pequeños
enfocados al modelado de ciertos tipos de procesos, y de esta manera elegir la que
mejor se adecue a la forma de llevar a cabo los procesos manejados en nuestra
organización.
Técnicas para el Modelado de Procesos de Negocio en
Cadenas de Suministro

Business Process Modelling Techniques in Supply Chains

Raquel Sanchis, Raúl Poler y Ángel Ortiz


Universidad Politécnica de Valencia. Centro de Investigación Gestión e Ingeniería de
Producción (CIGIP), Plaza Ferrándiz y Carbonell, 2,
03801 Alcoy (Alicante)-España (e-mail: rsanchis@cigip.upv.es, rpoler@cigip.upv.es,
aortiz@cigip.upv.es)

Resumen

El presente artículo muestra una revisión y evaluación de las técnicas y metodologías


genéricas de modelado de procesos de negocio más populares y utilizadas en la
literatura. El principal objetivo del estudio es la propuesta de una taxonomía de
clasificación de las técnicas de modelado aplicadas a las características propias de las
cadenas de suministro, para facilitar la selección de las más apropiadas. Para verificar
la clasificación, se describe un caso real de estudio en cadenas de suministro, en el que
se relaciona una cadena de suministro del sector cerámico y una del sector del mueble.
Del estudio realizado, se propone un método que incluye cuatro técnicas para la
representación de las diferentes perspectivas de modelado en una cadena de
suministro.

Palabras clave: cadena de suministro, procesos de negocio, técnicas de modelado,


gestión

Abstract

The article shows a review and evaluation of the most popular and meaningful
business process modelling techniques and generic methodologies treated in the
literature. The main objective is the proposal of a new taxonomy of classification
oriented to supply chains, with the aim of facilitating the selection of the most
appropriate ones. To verify the classification, a real study case of supply chains is
described. In this study, a supply chain from the ceramic sector is related with one
from the furniture sector and a method consisting of four modelling techniques to
present the different aspects to be considered for representing the different
perspectives of the supply chains is proposed.

Keywords: supply chain, business process, modelling techniques, management


INTRODUCCION

En la actualidad, las empresas han admitido que disponer de productos con una
adecuada calidad no es suficiente ventaja competitiva. Persiguiendo el objetivo de
ofrecer el máximo valor añadido a sus clientes, las empresas requieren una gestión
flexible con el fin de reaccionar de manera eficaz y eficiente a los continuos cambios
del entorno. En el paradigma preponderante en las pasadas décadas, la organización
era vista como un conjunto jerárquico de áreas funcionales que respondían a los
requerimientos del entorno con unas tareas, funciones y objetivos, bien definidos y
acotados, pero actualmente se exige una nueva estructura, con el objetivo de superar
las expectativas de los clientes así como ser ágiles para poder reconfigurar
rápidamente los procesos de negocio con el fin de satisfacer las nuevas necesidades.
Pires y Machado (2005), afirman que la fuga desde los modelos jerárquicos funcionales
tradicionales continua siendo más enunciada que deseada y mucho menos conseguida.
Por ello, es de vital importancia centrarse en aquellos procesos críticos que influyen
directamente en el éxito del negocio, siendo independientes de las áreas funcionales a
las que abarca. Por este motivo, se ha producido una evolución de una visión
jerárquica a una perspectiva de integración donde la gestión de los procesos de
negocio atraviesa los límites funcionales de las organizaciones.

En primer lugar, cabe definir el concepto de proceso de negocio para poder entender
dicha perspectiva de integración. Smith et al. (2002), tienen la concepción de que un
proceso de negocio es una compleja y coordinada secuencia de actividades, las cuales
son necesarias para proporcionar valor al cliente. Harmon (2003), los considera como
un sistema de actividades de negocio que son llevadas a cabo a razón de un
acontecimiento, transformando la información y los materiales, en la producción de un
producto. Las cadenas de valor y los procesos de negocio producen salidas (productos
o servicios) que son valoradas por los clientes. Del mismo modo, otros procesos
generan las salidas que son requeridas por otros procesos. Mili et al. (2004), en su
definición introducen el concepto de rol y consideran los procesos de negocio como
actividades desarrolladas por dichos actores representando diferentes papeles,
consumiendo unos recursos y produciendo otros. Las actividades pueden ser
desencadenadas por hechos y pueden del mismo modo, producir hechos por ellas
mismas.

Las actividades de un proceso se relacionan con otras mediante dependencias de


recursos (necesidades entre consumidor y productor) y dependencias de control (una
actividad no se puede iniciar si su predecesora no ha finalizado). Los actores operan
dentro de los límites de la organización. García-Molina et al. (2007), introducen los
conceptos de flujo de trabajo y reglas de negocio en su definición, ya que caracterizan
a los procesos de negocio como una colección de datos que son producidos y
manipulados mediante un conjunto de tareas, en las que ciertos agentes participan de
acuerdo a un flujo de trabajo determinado. Además, estos procesos se hallan sujetos a
un conjunto de reglas de negocio, que determinan las políticas y la estructura de la
información de las organizaciones.

O´Leary (2004), explica que en 1996, la American Productivity and Quality Center´s
(APQC) junto con el apoyo de diversas corporaciones internacionales, desarrolló y
publicó el esquema que se puede observar en la Fig. 1 para la clasificación de los
procesos de negocio, distinguiendo procesos operativos y de apoyo o gestión, que
abarcan más de 1.500 actividades asociadas. Su principal objetivo era que las
organizaciones utilizaran la misma terminología y entendieran por tanto el mismo
significado para un proceso de negocio determinado, lo cual es esencial en el modelado
de cadenas de suministro. La amplitud y la gran cantidad de relaciones entre las
diferentes entidades que configuran una cadena de suministro, dota al proceso de
modelado de una gran complejidad.

El presente artículo muestra una revisión de las técnicas y metodologías genéricas de


modelado de procesos de negocio más populares y utilizadas en la literatura, así como
una evaluación de las mismas. El principal objetivo del estudio es la propuesta de una
taxonomía de clasificación de las técnicas de modelado aplicadas a las características
propias de las cadenas de suministro, para facilitar la selección de las más apropiadas
en la representación de cada una de las vistas de la cadena. Para verificar la
clasificación, se describe un caso de estudio real de cadenas de suministro.

Fig. 1: Esquema de los procesos operativos y de gestión, Fuente; O´Leary (2004).

GESTIÓN Y MODELADO DE LOS PROCESOS DE NEGOCIO

La gestión de los procesos de negocio, se entiende como la aplicación de técnicas para


modelar, gestionar y optimizar los procesos de negocio de la organización. Partiendo
de que el proceso es la forma natural de organización, el modelado de los procesos
permite establecer un flujo de trabajo dentro y entre funciones, para tratar de
conseguir que, con la suma de los esfuerzos funcionales, se capturen los
requerimientos del negocio para obtener un mejor entendimiento y facilitar la
comunicación así como identificar las mejoras en los procesos con el objetivo de
conseguir los objetivos de la organización y las expectativas y requerimientos de los
clientes, de una forma eficaz y eficiente (Markovic y Pereira, 2007).

La mejora de procesos puede venir por dos vías complementarias: cambios en ciertos
aspectos del proceso existente, o un cambio radical del proceso (reingeniería).
En el primer caso se trata de eliminar aquellas tareas que no están aportando valor al
proceso desde el punto de vista del cliente, o bien modificar algunas de dichas
actividades de forma que aporten un mayor valor. La metodología PDCA (plan, do,
check, act), proporciona una sistemática en la resolución de problemas o en la mejora
de procesos, ya que asegura que se atacan las causas de raíz, proporcionando en
definitiva, el camino más corto y seguro para la resolución del problema o la
consecución de la mejora pretendida. El proyecto de mejora PDCA, consta de 7 etapas:
equipo de trabajo, selección de proyecto, comprensión de la situación inicial, análisis,
acciones correctivas, resultados, estandarización y control, y oportunidades de mejora
y planes futuros (Roure et al., 1997).

En la creación o cambio radical del proceso se trata de cuestionar de nuevo y de raíz el


diseño global del proceso de forma que se consigan alcanzar los nuevos objetivos o
generar considerablemente más valor con él. Según, Hammer y Champy, (1993) y Hall
et al., (1993), "reingeniería es la revisión fundamental y el rediseño radical de
procesos para alcanzar mejoras espectaculares en medidas críticas y contemporáneas
de rendimiento, tales como costes, calidad, servicio y rapidez". Su metodología se
divide en las siguientes fases: definir equipo de trabajo, análisis de los requerimientos
de los clientes y del negocio, comprensión del funcionamiento del proceso actual,
análisis y generación de ideas creativas e innovadoras para el rediseño del proceso,
diseño e implantación del nuevo proceso y seguimiento de los resultados.

Modelado de Procesos de Negocio

Los sistemas organizativos son difíciles de comprender sin un método apropiado de


análisis debido a su amplitud y complejidad. Una organización puede estar formada por
un buen número de áreas funcionales, departamentos y puestos, con múltiples puntos
de contacto entre sí. Un modelo proporciona la oportunidad de organizar y documentar
la información sobre un sistema (Vernadat, 1996). Por lo tanto, la finalidad del
modelado del negocio es describir cada proceso, especificando sus datos, actividades
(o tareas), roles (o agentes) y reglas de negocio (García-Molina, 2007). Kosanke
(2003), resume los objetivos del modelado en: (1) la adquisición de conocimiento
explícito sobre los procesos de negocio en la operativa del negocio, (2) la explotación
de dicho conocimiento en proyectos de reingeniería o mejora, (3) la ayuda a la toma
de decisiones y (4) la facilidad de interoperabilidad entre los procesos de negocio.

Curtis et al. (1992), afirman que existen cuatro puntos de vista en cuanto al modelado
de los procesos de negocio: vista funcional (qué), la cual representa la dependencia
funcional entre los elementos del proceso; vista dinámica (cuándo, cómo), que
proporciona una secuenciación y control de la información sobre el proceso; vista
informacional, que incluye la descripción y relación entre las entidades que son
producidas, consumidas o incluso manipuladas por los procesos, y la vista
organizacional (quién, dónde) que describe quién desarrolla cada tarea o función y
dónde se desarrolla dentro de la organización.

Debido a la naturaleza compleja y dinámica de las organizaciones, los modelos son


necesarios para entender el comportamiento de las mismas y diseñar los nuevos
sistemas así como mejorar el funcionamiento de los existentes. Las siguientes técnicas
se han desarrollado para facilitar la comunicación y la captura de información. A
continuación se enumeran y explican brevemente algunas de las técnicas más
significativas en el modelado de procesos de negocio.
Diagrama de flujo - Flow Chart: Los diagramas de flujo, que datan de los años 60
(Schriber, 1969), se definen como una representación gráfica de una secuencia lógica
de procesos de trabajo (Lankin et al., 1996). Mediante la utilización de diferente
simbología, representa operaciones, datos, direcciones de flujo y recursos; para la
definición, análisis o solución de un problema. Este formalismo es muy flexible, el
estándar ofrece la nomenclatura, pero será quien diseñe el proceso, quien estructure
los diferentes bloques del diagrama según el conocimiento que posea de éste. Se
caracteriza por su gran facilidad de uso y aporta gran cantidad de información ya que
muestra la totalidad del sistema, aunque presenta la problemática de su extensión, lo
que dificulta la visión global de todo el sistema así como que los límites del proceso no
suelen estar muy claros (Aguilar-Savén, 2004).

Diagramas de flujo de datos- Data Flow Diagram (DFD): Los DFD, son
representaciones de información a través de entidades externas, pasos internos de
procesado y elementos de almacenamiento de datos de un proceso de negocio
(Kettinger et al., 1995). Estos diagramas permiten ver cómo fluyen los datos a través
de la organización, los procesos así como las transformaciones que sufren dichos datos
y los diferentes tipos de salidas, aunque no modela representaciones de flujos de
materiales, recursos humanos, y otros elementos relacionados con los procesos de
negocio (Yourdon, 1989).

Diagrama entidad-relación - Entity-Relationship (ER) Diagram: El diagrama ER es un


modelo de red, que describe con un alto nivel de abstracción, la distribución de datos
almacenados en un sistema. Los diagramas ER se centran en los datos y en sus
interrelaciones y por ello, no representan la estructura para el modelado de otros
elementos del proceso. Dichos diagramas son representaciones completamente
estáticas y no proporcionan la información en el tiempo para poder analizarla y medirla
(Giaglis, 2001).

Diagrama estado-transición - State Transition (ST) Diagram: Los diagramas ST, se


originan para la descripción de la perspectiva dinámica de sistemas dependientes en el
tiempo y consiste en círculos que representan los estados, definidos como el modo
perceptible de comportamiento de un sistema, y flechas, que representan las
transiciones entre estados. Son muy útiles ya que proporcionan información explícita
acerca de la secuencia de tiempo relacionado con los diferentes eventos dentro del
sistema. Las limitaciones las presenta en la descripción de la colaboración entre los
objetos que causan dichas transiciones.

IDEF - Integrated Definition for Function Modelling: IDEF es una familia de técnicas de
modelado, que ofrecen una perspectiva integrada para representar y modelar procesos
y estructuras de datos. Sus inicios se remontan a la necesidad de las Fuerzas Armadas
Estadounidenses por mejorar sus operaciones de producción, iniciándose así el
programa ICAM (Integrated Computer-Aided Manufacturing). La familia IDEF, consiste
en un gran número de técnicas, entre las cuales se destaca IDEF0 e IDEF3, que son
aquellas relacionadas con los procesos de negocio, aunque existen otras versiones
como IDEF1, IDEF1X, IDEF2, IDEF4 e IDEF5.

La técnica IDEF0, está diseñada para modelar las decisiones, acciones y actividades de
una organización u otro sistema, y representa la perspectiva funcional de modelado, es
decir, el qué (Mayer et al., 1995). Es considerada una técnica sencilla pero poderosa,
ampliamente usada en la industria durante la etapa de análisis en la reingeniería de
procesos. Permite identificar apropiadamente los procesos y sus interfases así como
elaborar los documentos que permitan su control en cualquiera de sus etapas de
desarrollo. IDEF0 utiliza solo un tipo de anotación en sus representaciones gráficas
conocido como ICOM (Input-Control-Output-Mechanism). La representación estática de
sus diagramas no permite visualizar las perspectivas de modelado de comportamiento
o informacional. Para vencer dichas limitaciones, se desarrolló IDEF3 (Process
Description Capture), que describe a los procesos como secuencias ordenadas de
hechos o actividades, representando el cómo, y mostrando la visión dinámica o de
comportamiento.

Diagramas de actividad de roles - Role Activity Diagram (RAD): Los RAD son utilizados
para esquematizar las actividades bajo la responsabilidad de cada rol así como la
interacción entre ellos y con sucesos externos, entendiendo por rol, el comportamiento
deseado de los individuos dentro de la organización (Huckvale y Ould, 1995). Los
diagramas RAD centran su atención en el concepto de rol, por ello su idoneidad en
aquellos contextos en los que la perspectiva organizacional, es un factor clave que
debe ser modelado.

Diagrama de interacción de roles - Role Interaction Diagram (RID): Los RID, son
gráficos que representan los roles de los procesos de negocio. Las actividades están
conectadas a los roles en una matriz. Aunque dichos diagramas son más complejos
que los de flujo, son muy intuitivos y aportan facilidad en su lectura, a pesar que
tienden al desorden debido a la gran cantidad de flechas relacionando diferentes
puntos. Los RID, no son tan flexibles como los de flujo, aunque lo son más que muchas
otras técnicas. Su mejor uso se centra en el diseño del flujo de trabajo y suelen ser
utilizados para procesos que implican la coordinación de actividades interrelacionadas
(Aguilar-Savén, 2004).

Redes Petri - Petri Nets (PN): Las PN fueron creadas por el alemán Carl Adam Petri en
1962. En su tesis doctoral "kommunikation mit automaten" (Comunicación con
autómatas), establece los fundamentos para el desarrollo teórico de los conceptos
básicos de las PN que representan una alternativa para modelar el comportamiento y
la estructura de un sistema (Adam, 1962). La manipulación de los datos, tiene que ser
representada directamente en la estructura de la red y esto le confiere un tamaño
excesivamente grande. Además, no tiene en cuenta la estructura jerárquica, y no
permite construir un modelo global mediante la separación de submodelos con
interrelaciones bien definidas.

Técnica Orientada a Objetos - Object-Oriented (OO) Technique: La técnica OO, se


utiliza para modelar y programar procesos caracterizados como objetos, que son
desarrollados y transformados por actividades. Utiliza los objetos como bloque esencial
de construcción y combina la estructura de datos (atributos) y funciones (operaciones)
en una sola entidad. Existen diversidad de técnicas basadas en la programación
orientada a objetos, pero de todas ellas, la más importante es UML (Unified Modelling
Language), lenguaje gráfico para visualizar, especificar y documentar cada una de las
partes que comprende el desarrollo de software. UML ofrece una forma de modelar
entes conceptuales como son los procesos de negocio y funciones de sistema, además
de entes concretos como son escribir clases en un lenguaje determinado, esquemas de
base de datos y componentes de software reusables. UML consiste en nueve
diagramas diferentes, cada uno de los cuales muestra el aspecto estático o dinámico
del sistema: diagrama de clases, de objetos, de estados, de actividad, de secuencia,
de colaboración, de casos de uso, de componentes y de despliegue.
Metodologías Genéricas

Normalmente cuando se realiza una búsqueda sobre las técnicas de modelado, se


obtienen resultados que representan a más de una técnica. Dichos resultados son
metodologías generales con facultades para el modelado de procesos.
Desafortunadamente, existe una gran confusión de conceptos, ya que las metodologías
son utilizadas tanto para indicar la propia metodología como las técnicas asociadas a la
misma.

Análisis y diseño estructurado - Structured Systems Analysis and Design Method


(SSADM): Metodología que engloba un sistema de procedimientos, técnicas y
documentación de estándares para el análisis y diseño de las diferentes fases del
desarrollo de sistemas. Se caracteriza por una estructura en cascada, donde cada fase
precedente tiene que estar terminada para poder iniciar la siguiente. Su estructura
consiste en cinco módulos principales, los cuales se dividen en fases, pasos y tareas:
estudio de fiabilidad, análisis de requerimientos, especificación de las necesidades,
especificación del sistema lógico y diseño físico. SSADM utiliza tres técnicas clave para
el estudio de sistemas, denominadas modelado lógico de datos, diagramas de flujos de
datos y modelado entidad/evento (Hutchings, 1996).

Metodología de los sistemas blandos - Soft Systems Methodology (SSM): La


metodología trata con situaciones problemáticas en las cuales existe un alto
componente social, político y humano. El enfoque sistémico atiende al estudio de las
relaciones que conforman numerosos factores de un sistema, tomando muy en cuenta
la intensidad con que dichos elementos se comunican, al integrar una estructura
organizacional determinada. Dicha metodología plantea una visión inter, multi y
transdisciplinaria que ayuda a analizar la empresa de manera integral. Se divide en las
siguientes etapas; reconocer y expresar la situación problemática, producir
"definiciones básicas" de sistemas relevantes, desarrollar modelos conceptuales de los
sistemas relevantes, comparar modelos conceptuales con la situación percibida,
identificar cambios deseables y factibles, y tomar acción para mejorar la situación.
Presenta problemas en el análisis estructurado o para informar sobre una descripción
(Checkland y Scholes, 1999).

Metodología GRAI - Graph with Results and Activities Interrelated: La metodología


GRAI fue desarrollada como análisis del sistema decisional de la empresa. El modelo
GRAI consiste en un macro-modelo de referencia conceptual para los sistemas de
fabricación y un micro-modelo conceptual para los centros de decisión, que son
representados mediante la Rejilla y la Red GRAI respectivamente. La Rejilla GRAI
permite modelar el sistema de decisión, mientras que las Redes permiten modelar las
actividades de decisión de cada centro de decisión identificado en la Rejilla
(Doumeingts, 1984). Utiliza cuatro vistas: funcional, física, decisional e informacional,
para proveer al analista de una descripción genérica de los procesos de fabricación.
Estas vistas permiten generar modelos parciales de la empresa.

EVALUACIÓN DE LAS TÉCNICAS DE MODELADO DE PROCESOS DE


NEGOCIO

Las diferentes técnicas y metodologías difieren unas de otras, en el sentido en que


proporcionan la habilidad para modelar diferentes perspectivas de los sistemas de
negocio. Muchas técnicas se centran principalmente en funciones, otras lo hacen en
datos e incluso existen aquellas basadas en los diferentes roles. El caso ideal, sería
aquel, en el que se desarrollase una única técnica que pudiera representar de manera
eficiente todas las perspectivas de forma concisa y rigurosa, para de este modo, poder
ser aplicada a todas las situaciones de modelado. En la Tabla 1, se muestra una
clasificación de las diferentes técnicas vistas anteriormente, junto con una valoración
de su idoneidad para la representación de las diferentes perspectivas de modelado. La
evaluación y selección de una técnica, depende de las características del proyecto en
cuestión, así como de la capacidad y el conocimiento que el diseñador posea de cada
una.

Tabla 1: Representación de las diferentes técnicas de gestión de los procesos de


negocio mediante
las perspectivas de modelado. Tomado de Giaglis (2001).

Técnicas PERSPECTIVAS DE MODELADO


Funcional Dinámica Organizacional Informacional
Diagrama Sí No No Limitada
de flujo
IDEF0 Sí No Limitada No
IDEF3 Limitada Limitada No Limitada
Redes de Sí Sí No No
Petri
Diagrama No Limitada Sí No
RAD
Diagrama Sí No Limitada Sí
de flujo de
datos
Diagrama No No No Sí
entidad-
relación
Diagrama No Limitada No Limitada
estado-
transición
Técnica Sí Limitada Limitada Sí
Orientada
a Objetos

CADENA DE SUMINISTRO

La gestión efectiva de la Cadena de Suministro (CS) permite una mejor prestación de


servicio al cliente y de la cadena de valor, a través de la gestión de los flujos de
información, de productos y monetario. Dicha gestión, permite competir con éxito en
los mercados actuales, gracias al resultado que produce la conjunción de los objetivos
de la CS y la implantación de mejores prácticas en sus diferentes áreas. Actualmente,
es un elemento clave para la competitividad de las empresas debido a la importancia
que tiene en los resultados empresariales, a través del margen de beneficio, calidad de
productos y servicios, satisfacción del cliente y plazos de entrega. La CS engloba los
procesos de negocio, las personas, la organización, la tecnología y la infraestructura
física que permite la transformación de materias primas en productos y servicios
intermedios y/o terminados que son ofrecidos y distribuidos al consumidor para
satisfacer su demanda (Stadtler, 2005).
Existen numerosos modelos y metodologías para analizar y entender los procesos de
negocio desde la perspectiva de la CS, las cuales precisan de técnicas de modelado
para poder configurar y desarrollar dichos modelos. El Modelo de Capacidad de
Maduración (Harmon, 2003), es un modelo de referencia que engloba diferentes
etapas mediante las cuales una CS pasa de un contexto inmaduro a uno maduro en
cuanto a la comprensión y gestión de sus procesos. Se trata de definir y representar
mediante alguna de las técnicas explicadas en la sección anterior, las diferentes etapas
para conocer la situación de la CS en todo momento y, de esta forma, tomar las
decisiones oportunas para mejorar la gestión de la misma. Las diferentes etapas del
modelo se resumen en la Figura 2.

Fig. 2: Etapas de Maduración de GCS.

La elección de las técnicas más apropiadas, es una ardua tarea que incrementa su
dificultad, si el ámbito de aplicación y representación son los procesos de negocio en
CS. Mediante la revisión bibliográfica se han identificado casos de aplicación real de las
técnicas anteriormente mencionadas para el modelado de los procesos de negocio en
CS.

Hull (2002), define una estructura para la representación de los flujos de información y
su aplicación real en una CS de petróleo en Alaska mediante la utilización del diagrama
de flujo de datos. Al-Hakim (2005) en su estudio, se centra en el modelado de las
interdependencias de las CS que utilizan las Tecnologías de la Información y
Comunicación (TIC), como internet y otras tecnologías e-negocio, para su gestión.
Dicho estudio se basa en el modelo SCOR para la estandarización de los procesos y
emplea la técnica IDEF0 para la representación de los mismos. La técnica IDEF3 es
considerada como excelente mecanismo para la representación efectiva de la
recopilación y documentación de datos e información asociados a los procesos,
aplicados en una CS de acero (Danso-Amoako et al., 2004).

Murdoch y McDermid (2000), utilizan el diagrama RAD, para la representación de la


secuencia de tiempo de las tareas y las interacciones que ocurren entre los diferentes
roles, en un marco que indica el nivel de descomposición del sistema de la CS.

Pelletier et al. (2005), utilizan el nuevo lenguaje de modelado denominado TALMOD


(The Agent Lab Modelling Language), aplicado en la representación de numerosas
empresas así como en una CS de transporte de gas holandesa. Dicho lenguaje utiliza
cuatro tipos de diagramas, entre los cuales cabe destacar, el diagrama de interacción
de roles que identifica los diferentes roles de un proceso así como los procesos locales
específicos que forman parte del conjunto global de la actividad de negocio de la CS
vista desde la perspectiva de dichos roles.

Por ello y tomando como base la clasificación realizada por Giaglis (2001), se propone
una nueva taxonomia orientada al modelado de los procesos de negocio en la CS.
Algunas de las técnicas propuestas por Giaglis (2001) han sido eliminadas en esta
nueva taxonomia debido a la baja capacidad o a la alta dificultad que presentan
cuando son aplicadas al contexto global de una CS. Por ello, existen menos
alternativas pero de este modo se asegura que la técnica elegida, se ajusta
adecuadamente a las nuevas condiciones, tal y como se puede observar en la Tabla 2.

Tabla 2: Taxonomia de las técnicas de modelado de procesos de negocio en CS.


Tomado y adaptado de Giaglis (2001).

Entendimiento Mejora Gestión Desarrollo Ejecución


del del del del
Comunicación proceso proceso proceso proceso
DFD
DFD DFD DFD DFD
Diagrama de
Diagrama Diagrama Diagrama Diagrama
flujo
Informacional ER ER ER ER
IDEF3
(datos) Diagrama Diagrama Diagrama Diagrama
Diagrama ER
ST ST ST ST
Diagrama ST
UML UML UML UML
UML
Organizacional
IDEF0 IDEF0 IDEF0 UML
(dónde, _
RAD RAD RAD RAD
quién)
Dinámico
IDEF3 IDEF3 IDEF3 Redes Redes
(cuándo,
RAD RAD RAD Petri Petri
cómo)
Diagrama
Diagrama de Redes
de flujo Diagrama
flujo de datos Petri Redes
de datos de flujo
Petri
Funcional de datos
IDEF0 IDEF3
(qué) IDEF0
IDEF3 IDEF0 DFD
IDEF3 IDEF0
DFD DFD UML
DFD IDEF3
UML UML
UML

En la Tabla 3, se muestran las técnicas más apropiadas para la representación de cada


uno de los subsistemas de las diferentes perspectivas de modelado. Cabe destacar que
esta clasificación es orientativa, puesto que sirve de base para la selección de las
técnicas más adecuadas dependiendo de las características de la CS. Se trata de
suministrar una categorización que sirva de ayuda a las personas envueltas en
proyectos de modelado de procesos de negocio en CS para facilitarles la elección de las
técnicas más convenientes.
Tabla 3: Clasificación de las técnicas más apropiadas para modelar las cuatro
perspectivas de las CS.

Vista Técnica Puntos fuertes Puntos débiles


Descripción de los flujos de
información de forma clara y
Informacional Descripción lógica
DFD sencilla
(datos) reducida
Proporciona una notación para el
almacenamiento de datos
Organizacional
RAD Sencilla e intuitiva Diferente notación
(dónde, quién)
Dinámico Intuitiva
No posee una sintaxis
IDEF3 Fácil de entender y crear
estricta
(cuándo, cómo) Buena descripción secuencial
Sintaxis estricta
Diagramas estáticos
Funcional Simplicidad
IDEF0 Descripción lógica
(qué) Modelado rápido
reducida
Descomposición jerárquica

Los diagramas de flujo de datos ofrecen una estructura general para la representación
de la perspectiva de datos que engloba todas las etapas desde la comprensión y
comunicación hasta la ejecución del proceso. Se pueden desarrollar métricas para
ayudar en la reducción de distorsiones. Dichos diagramas proporcionan para la
estructura de flujo de información, el componente básico y primordial de una cadena,
por ello su conocimiento es básico en la disminución de desviaciones. Los diagramas
de flujo de datos, son también una opción en la ejecución de procesos para
representar la vista funcional, debido a los conocimientos adquiridos de la técnica
durante el modelado informacional y no supondría enfrentarse de nuevo a la curva de
aprendizaje con la utilización de otra técnica.

Los diagramas RAD son una técnica muy popular y ampliamente utilizada para
capturar la perspectiva organizacional de la CS. La justificación de la elección de esta
notación es debida a la razonable simplicidad, así como la posibilidad de ser utilizada
en diferentes etapas como la comprensión y comunicación, mejora, gestión y
desarrollo de procesos. Se puede decidir el nivel de representación así como
determinar las limitaciones de cada rol. Es muy fácil aprender el diseño y
representación de los diagramas, con lo cual, no supondrá un gran esfuerzo para el
personal implicado en el proyecto de modelado. Su sencillez hace que sea fácilmente
interpretable por los usuarios finales que no tienen por qué estar familiarizados con la
técnica, propiedad muy importante cuando se representan CS con una grado de
complejidad elevado.

IDEF3, representa el "cómo" y "cuando" en una CS; aunque también cabe considerar
los diagramas RAD, como opción para representar la vista dinámica. En este sentido,
será decisión de los responsables de modelado, la designación de una técnica u otra,
dependiendo de las particularidades del proyecto y de la tipología de la CS. La
utilización de los diagramas RAD, puede resultar muy sencilla debido a que su notación
será bien conocida si se ha utilizado en la representación de la vista organizacional. Por
el contrario IDEF3, presenta la ventaja de que se obtendrá una visión más integrada
de la taxonomia, ya que pertenece a la famita de formalismos IDEF, que será utilizado
para representar la vista funcional, con lo cual la curva de aprendizaje será menor para
crear y analizar los modelos de los procesos de negocio. IDEF0, será la responsable del
modelado de la vista funcional. Es la técnica más ampliamente utilizada para el
modelado de CS y en la literatura, dicha técnica es usada en numerosas aplicaciones
reales debido a su simplicidad y comprensibilidad, que la dota de una gran capacidad
para representar las diferentes perspectivas en CS.

ANÁLISIS DE UN CASO DE ESTUDIO

Descripción del caso de estudio

Con la finalidad de validar que la taxonomia expuesta cumple con los requisitos de
modelado de las diferentes perspectivas inter-firmas y con las características de
interdependencia entre los diferentes actores involucrados en la cadena, se aplicó a un
caso de estudio en el que se interrelacionaban una CS del sector cerámico y una CS del
sector del mueble.

Los procesos de negocio que se consideraron fueron los de planificación, programación


y monitorización de pedidos. El objetivo final de dichos procesos fue el de completar
una petición de oferta en tiempo real solicitada por un cliente en un punto de venta. En
la CS de estudio, el pedido del cliente está compuesto por un paquete, que es un
conjunto de productos (cerámicos y mobiliarios) que es vendido conjuntamente como
un solo elemento. Por lo tanto, se debían coordinar ambas CS con estrategias de
producción muy diferentes y con diferentes lógicas de sincronización de las entregas.

Estudio de la taxonomía propuesta

Tras el estudio y revisión de las técnicas de modelado de procesos de negocio, se


utilizó la taxonomía anteriormente expuesta, ya que cumplía con los requerimientos y
las necesidades de modelado de las CS involucradas en el estudio. En la Tabla 4 se
muestra un resumen de los diferentes aspectos que se modelaron con cada una de las
técnicas.

Tabla 4: Aspectos modelados mediante la taxonomia propuesta.

Vista Técnica Aspecto modelado


Identificación y representación de los datos de la
Informacional DFD configuración, características y condiciones específicas del
pedido y del cliente.
Modelado de los roles identificados en el estudio que
abarcan a clientes, que configuran un pedido, los puntos de
venta, que reciben los requerimientos de los clientes, los
operadores logísticos, que mueven los productos desde los
Organizacional RAD almacenes a las instalaciones de los clientes, la CS, que
proporciona una interfaz para crear pedidos sobre algún
producto específico y el mediador, que facilita las tareas de
negociación, programación, reglas de soporte a la toma de
decisiones, y mecanismos de monitorización
Calendario y secuenciación de todas las tareas necesarias
Dinámico IDEF3 para la planificación, programación y monitorización de los
pedidos.
Representación de la disponibilidad, capacidad, recursos,
Funcional IDEF0
restricciones e inventario disponible.
Mediante la aplicación de la taxonomía se consiguió una visión completa y conjunta de
los procesos, lo que llevó a una adecuada identificación de los problemas a resolver y
una integrada implantación de las soluciones adoptadas.

CONCLUSIONES

Debido a la naturaleza compleja y dinámica de las CS, los modelos son necesarios para
entender el comportamiento de las mismas y diseñar los nuevos sistemas así como
mejorar el funcionamiento de los existentes. Por todo ello, se hace necesario un
estudio y clasificación de las técnicas de modelado de procesos de negocio más
apropiadas, para llevar a cabo proyectos en CS. La clasificación realizada es una guía
orientativa de ayuda, que ha sido aplicada a un caso de estudio en el que se
interrelacionaban una CS del sector cerámico y una CS del sector del mueble.

Del estudio anterior, se deriva la elección de las cuatro técnicas para la representación
de las diferentes perspectivas de modelado en CS. En la vista informacional, los
diagramas de flujo de datos, poseen las características más adecuadas para la
descripción de la circulación de información. Los diagramas RAD, son utilizados en la
perspectiva organizacional, mientras que en la vista dinámica la técnica IDEF3
proporciona un método estructurado para expresar "cómo" la CS opera. Dicha técnica
necesita ser complementada por IDEF0, para capturar los detalles conjuntos de los
procesos, como entradas, salidas y requerimientos de recursos de las actividades.
Dependiendo de la tipología del proyecto, existe la posibilidad de unificar la vista
organizacional y dinámica, mediante su modelado con la técnica IDEF3.

REFERENCIAS

Adam, C.; "Kommunikation mit Automaten" Petri, C.A., Bonn: Institut für
Instrumentelle Mathematik, Schriften des IIM Nr. 2, Bonn, Alemania
(1962). [ Links ]

Aguilar-Savén, R.S.; Business process modelling: Review and framework, Int. J.


Production Economics: 90(2), 129-149 (2004). [ Links ]

Al-Hakim, L.; Modelling Interdependencies for Electronic Supply Chain Management,


Conferencia Internacional IRMA, California, USA, 15 al 18 de Mayo
(2005). [ Links ]

Checkland, P. y J. Scholes; Soft Systems Methodology in Action, John Wiley and Sons
West Sussex, Inglaterra (1999). [ Links ]

Curtis, B., M.I. Kellner y J. Over; Process modeling, Communications ACM: 35(9), 75-
90 (1992). [ Links ]

Danso-Amoako, M. O., W.J. O´Brien y R.A. Issa; A Case Study of IFC and CIS/2
Support for Steel Supply Chain Processes, 10º Conferencia Internacional en
Computación en Ingeniería Civil y de Construcción (ICCCBE-10), Weimar, Alemania 2
al 4 de Junio (2004). [ Links ]
Doumeningts G.; Méthode GRAI: Méthode de conception des systémes en productique.
Tesis de Automoción. Universidad de Bordeaux, Francia (1984). [ Links ]

García-Molina, J., Ortín, M.J., Moros, B. y J. Nicolás; De los Procesos del Negocio a los
Casos de Uso, Técnica Administrativa, ISSN: 1666-1680 (en línea), 6(4) (2007).
http://www.cyta.com.ar/ta0604/v6n4a1.htm. Acceso: 6 de junio de 2008. [ Links ]

Giaglis G.M.; A Taxonomy of Business Process Modeling and Information Systems


Modeling Techniques, The International Journal of Flexible Manufacturing Systems: 13,
209-228 (2001). [ Links ]

Hall G., J. Rosenthal y J. Wade; How to make reengineering really work, Harvard
Business Review: 71(6), 119-131 (1993). [ Links ]

Hammer M. y J. Champy; Re-engineering the Corporation; A Manifesto for Business


Revolution, Harper Business, New York, USA (1993). [ Links ]

Harmon, P.; Business Process Change: A Manager's Guide to Improving, Redesigning,


and Automating Processes. Morgan Kaufmann, San Francisco, USA
(2003). [ Links ]

Huckvale, T. y M. Ould; Process Modeling - Who, What and How: Role Activity
Diagrammin", Business Process Change: Reengineering, Concepts, Methods and
Technologies, Idea Group Publishing, 330-349, Hershey, USA (1995). [ Links ]

Hull, B.; A structure for supply-chain information flows and its application to the
Alaskan crude oil supply chain, Logistics Information Management: 15 (1), 8-23
(2002). [ Links ]

Hutchings, T.; Introduction to Methodologies & SSADM, (1996),


http://www.comp.glam.ac.uk/pages/ staff/tdhutchings/Default.htm, Acceso: 2 de
Junio de 2005. [ Links ]

Kettinger, W.J., J.T.C. Teng y S. Guha; The Process Reengineering Life Cycle
Methodology: A case Study, Business Process Change: Reengineering, Concepts,
Methods and Technologies, Idea Group Publishing, 211-244, Hershey, USA
(1995). [ Links ]

Kosanke, K.; Business Process Modelling and Standardisation (2003),


http://www.cimosa.de/Standards/BPM_and_Standardisation.pdf, Acceso: 10 de junio
de 2008. [ Links ]

Lakin, R., N. Capon y N. Botten; BPR enabling software for the financial services
industry, Management Services: 40(3), 18-20 (1996). [ Links ]

Markovic, I. y A.C. Pereira; Towards a formal framework for reuse in business process
modelling, Actas de 5th International Conference on Business Process Management,
484-495, Brisbane, Australia, 24 al 28 Septiembre (2007). [ Links ]
Mayer, R.J., P.C. Benjamin, B.E. Caraway y M.K. Painter; A Framework and a Suite of
Methods for Business Process Reengineering, Business Process Change: Reengineering,
Concepts, Methods and Technologies, Idea Group Publishing, Idea Group Publishing,
Hershey, USA, 245-290 (1995). [ Links ]

Mili H., G. bou Jaoude, E., Lefebvre y G., Tremblay, Going beyond MDA: Business
Process Modeling for Software Reuse, Workshop on Legacy Transformation: Capturing
Business Knowledge from Legacy Systems - OOPSLA'2004, Vancouver, Canadá, 24 al
28 Octubre (2004). [ Links ]

Murdoch, J. y J.A. McDermid; Modelling Engineering Design Processes with Role


Activity Diagrams, Society for Design and Process Science: 4 (2), 45-65
(2000). [ Links ]

O´Leary, D.E.; Change in a Best Practices Ontology, Actas de Decision Support in an


Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference, 618-
627, Toscana, Italia, 1 al 3 Julio (2004). [ Links ]

Pelletier, C.M.P, C. de Snoo y L. Maruster; Modelling the Gas Transport Supply Chain
with an Agent-Based Approach, Workshop SCM-ICT, Groningen - Paises Bajos,
Noviembre 21-22 (2005). [ Links ]

Pires, A.M. y V.C. Machado; Gestión por Procesos en el Diseño de las Organizaciones.
Información Tecnológica: 17(1), 35-44 (2005). [ Links ]

Roure J., M. Moñino y M.A. Rodríguez-Badal; La Gestión Estratégica por Procesos,


Ediciones Folio, Barcelona, España (1997). [ Links ]

Smith, S., D. Neal, L. Ferrara y E. Hauden; The Emergence of Business Process


Management, CSC's Research Services (2002). [ Links ]

Schriber, T.J.; Fundamentals of Flowcharting Wiley, New York, USA


(1969). [ Links ]

Stadtler, H.; Supply Chain Management and Advanced Planning - Basics, Overview and
Challenges. European Journal of Operational Research: 163(3), 575-588
(2005) [ Links ]

Vernadat, F: Enterprise Modeling and Integration. Principles and applications,


Chapman&Hall, Londres (1996). [ Links ]

Yourdon, E; Modern Structured Analysis, Yourdon Press Upper Saddle River, NJ, USA
(1989). [ Links ]

S-ar putea să vă placă și