resumen - Universidad de Alcalá

RESUMEN
El propósito de esta tesis es proponer una arquitectura para la construcción de
sistemas que sean una síntesis de los actuales módulos de parametrización de los
sistemas ERP (Enterprise Resource Planning) y de los Sistemas Basados en el
Conocimiento, en particular de los Sistemas Inteligentes de Tutorización y de los
Sistemas de Ayuda Inteligentes, así como una metodología de creación de
contenidos procedimentales soportados por dicha arquitectura.
La utilidad de tal sistema se justifica en la necesidad de dotar a los sistemas ERP
actuales, utilizados en el amplio espectro empresarial, de cierta inteligencia, y de
ciertos mecanismos de formalización, estructuración y modelización de los
procedimientos de parametrización, dado que este proceso es uno de los principales
factores de éxito en la implantación y uso de un sistema ERP.
Vamos, primeramente, a analizar el estado actual de los sistemas de gestión
empresariales, en concreto los sistemas ERP (Enterprise Resource Planning), y sus
necesidades en el contexto de la nueva economía, sus avances y sobre todo sus
limitaciones. Haremos lo mismo con algunos sistemas clásicos de Inteligencia
Artificial y de Gestión del Conocimiento, en particular con los Sistemas de Ayuda
Inteligente y los Sistemas Inteligentes de Tutorización. A partir de dichos estudios
trataremos de señalar su posible aplicación en el ámbito de la estrategia empresarial
aplicada a la parametrización de sistemas ERP.
Para empezar propondremos una arquitectura modular del sistema que incluya
una serie de funciones y características fundamentales, a continuación se definirán
los componentes necesarios, las relaciones entre ellos y el flujo de información
interno y con agentes externos, como los usuarios del sistema propuesto y el propio
sistema ERP a implementar.
Definiremos una metodología para crear unas bases interactivas de conocimientos
que incluyan por un lado reglas sobre conocimientos propios del dominio que
tratemos (parámetros y funcionamiento del sistema ERP), y por otro reglas de
gestión empresarial (estrategias e índices de calidad) basadas en la realización previa
de una taxonomía empresarial. De esa forma transformaremos los conocimientos de
expertos y manuales (lenguaje natural) en conocimientos formalizados que sean
fácilmente interpretables por un sistema informático y fácilmente comprensible por
consultores ERP y trabajadores y directivos de empresas de todo tipo de sectores.
Como ilustración de la arquitectura y metodología propuestas mostraremos un
prototipo aplicado a un sistema ERP real y muy extendido y a un tipo de empresa
representativa de un importante sector, en el que se han utilizado técnicas y
herramientas presentadas y analizadas en esta tesis.
Expondremos a continuación las conclusiones y trabajos futuros relacionados con
los temas tratados, resaltando entre ellas la importancia y novedad de la aplicación
de sistemas inteligentes en el entorno de definición de la gestión empresarial y de la
construcción del conocimiento estratégico de manera formalizada, verificable,
interactiva y poco costosa. Entre los trabajos futuros y líneas de investigación
abiertas destacaremos la necesidad de creación de diversas taxonomías empresariales
y diversos criterios de calidad que guíen al asistente propuesto de forma
personalizada y la ampliación del marco metodológico a otras áreas y actividades.
Incluiremos finalmente las fuentes documentales (referencias bibliográficas y
sitios web) en las que se inspira este trabajo, sin propósito alguno de exhaustividad,
ya que nos movemos en un marco referencial sometido a cambios continuos.
1 INTRODUCCIÓN
1.1. JUSTIFICACIÓN DE LA INVESTIGACIÓN
En estos momentos de constantes cambios y ante una creciente competitividad en
el ámbito empresarial, la capacidad de adaptarse al entorno se está convirtiendo en
un factor determinante del éxito de las organizaciones. Las empresas han de ser más
ágiles y flexibles con capacidad de innovar para poder reaccionar rápidamente a los
cambios en el mercado y la competencia. Esta dinámica ha llevado a muchas
empresas a revisar sus estrategias, algo que resulta complejo al enfrentarse a
múltiples procesos de negocio y sistemas de información heterogéneos y carentes de
agilidad y capacidad de respuesta. Analizando esta situación parece que integrar los
sistemas de información y alinearlos con la estrategia empresarial es necesario para
mantenerse en este nuevo entorno.
Por otro lado, se demuestra como fundamental en el éxito empresarial el acceso
eficiente a la información sobre el negocio. En la toma de decisiones los
responsables de las empresas necesitan acceder y analizar diferentes tipos de
información. Pero en la práctica no siempre los sistemas que deben ofrecer esos
datos son los más adecuados. Los motivos son varios: información básica e
inadecuada, ineficacia de los sistemas, cuellos de botella en la generación de
información o ineficiencias en cuanto al soporte del programa de gestión
informática. Se trata no sólo de que en la empresa se compartan ciertas
informaciones, sino también que, con su uso eficiente, se ayude a la toma de
decisiones en cualquier área en cada momento. Por ejemplo [Coughlin, 2005]
determina que entre el 15% y el 30% del tiempo de los empleados que trabajan en
puestos de decisión se pierde en buscar información y, finalmente, esta solo se
encuentra el 50% de las veces. También [Davenport y Prusak, 1997] exponen que las
personas que trabajan en puestos de dirección pasan el 17% de su tiempo (seis
semanas al año) buscando información.
-1-
1. Introducción
Finalmente, la utilización de sistemas informáticos en la empresa debe
proporcionar, no solo flexibilidad e información, sino hacerlo disminuyendo la
necesidad de recursos y el coste. En este entorno surgen los sistemas ERP
(Enterprise Resource Planning) que ofrecen un enorme potencial de ahorro tangible e
intangible. Entre los primeros destaca la reducción de recursos humanos necesarios y
de inventario (en torno al 35%). Por otra parte, los ERP aportan un incremento a la
cantidad y la calidad de información de los consumidores (65%), lo que representa
un beneficio intangible muy valorado [Davenport, 2000]. Estos sistemas permiten
ver y gestionar la red extendida de la empresa, sus proveedores, alianzas, y clientes
como un todo integral y, entre otros beneficios, esto repercute en una mejora de la
cadena de procesos, una mayor estandarización y mayor eficacia en la respuesta a los
clientes. [Ross y Vitale, 2000] han estudiado más de 15 empresas que han
implantado sistemas ERP y describen así los beneficios de su uso:
? Plataforma común e integrada;
? Mejora de los procesos de negocio
? Mayor calidad en los datos y mejora de su uso como soporte a la toma de
decisiones;
? Reducción de los costes de operación;
? Incremento de la satisfacción de los clientes;
? Mejora de los procesos de toma de decisiones.
El número de compañías que decide implementar un ERP se está incrementando
rápidamente [Granlund y Malmi, 2002]. En España, según un estudio elaborado por
el grupo Penteo a finales del 2003, entre más de 300 empresas españolas con una
facturación superior a 20 millones de euros, el 70% de ellas cuenta con algún sistema
de ERP, y un 8% espera hacerlo en breve.
En los proyectos de implantación de sistemas ERP la definición de los procesos
de negocio y las actividades de parametrización involucradas en el proceso de
implementación del software son las mayores razones de insatisfacción [Berg et alt.,
1997]. Empresas como Baan, Peoplesoft y SAP calculan que los clientes gastan entre
3 y 7 veces más dinero en la implementación del ERP y los servicios asociados,
comparados con la compra de la licencia del software. Bajo sus propias experiencias,
validan que la proporción entre los esfuerzos de implementación del ERP y la
compra del software es aproximadamente de 5 a 1. Con los costos del hardware y
software que decrecen rápidamente, la proporción será peor. Esta alta proporción es
debida al hecho de que los sistemas ERP son más ó menos fáciles de instalar, sin
embargo los usuarios deben determinar que objetivos (estrategias) desean alcanzar
con el sistema, como su funcionalidad puede lograrlo y como adecuar, configurar e
-2-
1. Introducción
implementar funcional y técnicamente el sistema. Particularmente las empresas
pequeñas y medianas no tienen la capacidad para contratar los consultores necesarios
para una implementación eficiente de sistemas ERP. Por lo tanto, métodos, modelos,
arquitecturas y herramientas apropiadas para ayudar en esta tarea se han convertido
en fundamentales, ya que el éxito del uso de estos sistemas depende, en gran medida,
de la fase de implantación.
La parametrización del sistema (o customizing) es la característica de los sistemas
ERP que contribuye en modo determinante a la flexibilidad, utilidad y éxito de un
ERP porque representa la posibilidad del usuario final de definir las características
funcionales de los módulos activos, de acuerdo con la estructura de los procesos
operativos y estratégicos de la empresa. Uno de los principales problemas que
encontramos frente a este reto es redefinir y organizar la política estratégica de la
empresa [Mucelli, 2000]. Para ello es necesaria la concurrencia de expertos de la
propia empresa, en general niveles directivos, y expertos en la reingeniería de
procesos de negocio y en el propio sistema ERP a implantar. Este proceso es largo y
costoso ya que se debe adaptar el sistema a las reglas, lenguaje y flujos informativos
empresariales. Se presenta como una necesidad la facilitación de este proceso
mediante mecanismos automáticos que guíen en la parametrización utilizando como
base de conocimiento la experiencia de empleados de la empresa y consultores del
sistema ERP. Principalmente se aprecia esta necesidad en las pequeñas y medianas
empresas que disponen de menos recursos humanos y materiales para esta larga
tarea, y que, por otro lado, no necesitan estrategias especiales si no que estas pueden
ser definidas conociendo el entorno y la actividad del negocio. De ahí la
conveniencia de realizar un trabajo previo de clasificación empresarial, estableciendo
una taxonomía que ayude a definir los parámetros de parametrización básicos para
cada clase.
Por otro lado, [Markus et alt., 2001] destacan como factores fundamentales en el
fracaso del uso de los sistemas ERP la falta de conocimiento estructurado sobre los
procesos de negocio y sobre las decisiones de parametrización tomadas en fase de
implantación, la dificultad de optimizar el sistemas y la dificultad de innovación y
flexibilidad en los procesos de negocio derivada del desconocimiento de las razones
de la parametrización actual, de las posibilidades de su modificación y de sus
consecuencias. Para paliar estas dificultades nuestra propuesta debe favorecer el
conocimiento de las decisiones de parametrización realizadas y establecer la relación
entre estas y las métricas de calidad establecidas para valorar el uso del sistema. Es
decir, debe proponer un control de calidad continúo, de forma que se realice una
revisión constante de la parametrización inicial del sistema para adecuarse a los
cambios y tender siempre a la excelencia.
-3-
1. Introducción
En este mundo empresarial, cada vez más complejo, es necesario utilizar los
recursos humanos, materiales e informáticos de forma eficiente. Los sistemas
basados en la inteligencia artificial se muestran como una ayuda incomparable en
este sentido, ya que los humanos y los sistemas inteligentes tienen habilidades que se
complementan, pueden apoyarse y ejecutar acciones conjuntas. De ahí que la
propuesta de esta tesis implique el uso de un sistema inteligente que ayuda al
humano en su tarea, sin prescindir de la capacidad de este para percibir, razonar y
actuar. En el entorno empresarial el uso de la inteligencia artificial no está muy
extendido y, en concreto, aunque hay algunos trabajos sobre el uso de los sistemas
ERP, no se ha utilizado en el proceso de su parametrización.
De entre los diferentes tipos de sistemas inteligentes nuestra propuesta, por sus
características, debe basarse en aquellos cuya principal propiedad es el potente
cuerpo de conocimientos que acumulan y como diferencian entre los conocimientos
sobre el problema y los conocimientos sobre como resolver el problema. Para que se
comporten inteligentemente, además de poseer conocimientos fieles a la realidad
deben ser capaces de utilizarlos eficientemente al realizar inferencias. Los sistemas
basados en reglas son los más comúnmente utilizados para realizar estas inferencias.
Su simplicidad y similitud con el razonamiento humano, han contribuido a su
popularidad en diferentes dominios. Estas características y su arquitectura básica
deben ser tenidas en cuenta para la construcción de un sistema con capacidad de
asistencia inteligente para la parametrización en el marco de los sistemas ERP. Este
marco cumple con las características que deben tener los dominios apropiados para
los sistemas de producción, que son las siguientes:
? La tarea que se intenta resolver puede verse como un conjunto de transiciones
de un estado a otro;
? Conocimiento amplio, incompleto o no muy bien definido;
? Los procesos pueden representarse como un conjunto de acciones
independientes;
? Razonamiento basado en reglas que necesitan heurísticas para lidiar con
información compleja y/o incompleta;
? Eficiencia en dominios limitados en su campo de aplicación.
Estas características concuerdan con el dominio de parametrización de un sistema
ERP aplicado a la consecución de objetivos estratégicos empresariales, en el que:
? Intervienen personas diversas con conocimientos incompletos sobre el
dominio;
? El dominio está restringido a su ámbito de aplicación;
? Las tareas a realizar por los expertos pueden representarse utilizando
procedimientos formales basados en condiciones/acciones;
-4-
1. Introducción
? El resultado final puede representarse como la evolución desde el estado
inicial del sistema ERP impersonal hasta la obtención de un sistema ERP
personalizado, pasando por diferentes etapas.
Resumiendo lo anterior, los sistemas empresariales ERP proporcionan una
plataforma de tecnología en la que las organizaciones pueden integrar y coordinar
sus principales procesos internos de negocios. Lo básico es entender que cada
organización tiene unas necesidades distintas y que el ERP y su parametrización
dependerán de estas necesidades. Por ello, como un ERP no es una solución tipo, las
soluciones válidas para unas organizaciones pueden no ser válidas para otras, siendo
fundamental para el éxito de la empresa la parametrización adecuada. Actualmente el
proceso de parametrización de un ERP requiere dedicación total por parte de un
equipo de trabajo que deberá estar integrado por los líderes empresariales y por
expertos consultores ERP. En la práctica está tarea resulta lenta y con alta
probabilidad de error , ya que en grandes sistemas los parámetros a considerar
pueden ser muchos, en algunos casos repetitivos y dependientes de parámetros
anteriores y en otros resultado de un extenso conocimiento tanto de la realidad
particular de cada empresa, como del funcionamiento procedural del ERP elegido.
Dicho conocimiento es difícil de conjugar en el mismo equipo. Se hace necesario
encontrar un sistema que guíe la realización de esta tarea de forma inteligente,
evitando la probabilidad de errores y diminuyendo el tiempo de implantación.
Por otro lado, desde el punto de vista de ingeniería, la mayor parte del trabajo
requerido para construir sistemas inteligentes, está basado en el desarrollo de
adecuadas representaciones de conocimiento y sus correspondientes estrategias de
manipulación. No se puede manipular conocimiento a menos que esté
adecuadamente representado. Es parte fundamental en la obtención de un sistema
inteligente de ayuda en la tarea de parametrización de sistemas ERP utilizar una
metodología de creación, almacenamiento y utilización de conocimiento
procedimental, que es aquel conocimiento compilado que se refiere a la forma de
realizar una cierta tarea (el saber como hacerlo).
Por último es necesario encontrar un sistema que guíe de forma inteligente, a
través de los conocimientos procedimentales, el proceso de parametrización de los
sistemas ERP. En el entorno de la formación se han desarrollado los llamados
Sistemas Inteligentes de Tutorización, que pretenden guiar a través de un
conocimiento modelado ofreciendo a cada usuario la posibilidad de un proceso de
enseñanza individual y particularizado, y, los Sistemas de Ayuda Inteligentes, que
dan soporte a la ejecución y el uso de aplicaciones informáticas. Estos sistemas
funcionan para dominios muy restringidos, pero podemos utilizar su arquitectura
aplicándola a un área totalmente distinta, la parametrización de sistemas ERP
particularizada para cada organización y su propia estrategia empresarial.
-5-
1. Introducción
Así pues, estamos en condiciones de determinar, como punto de partida que
justifique el desarrollo de este trabajo, la siguiente proposición:
La investigación objeto de esta tesis se justifica en la
creciente necesidad de dotar de inteligencia a los procesos
que parametrizan los sistemas ERP, y en la inexistencia de
metodologías que permitan generar con cierta facilidad
procesos de negocio, con un nivel aceptable de formalización
y estructuración en la representación de los conocimientos.
El sistema resultante de la arquitectura que vamos a proponer, y que podríamos
denominar Asistente Inteligente para la Parametrización de Sistemas ERP, se
propone dotar a los procesos tradicionales de parametrización de estos sistemas de la
flexibilidad y capacidad de orientación a cada estrategia empresarial de la que
carecen, añadiendo de este modo una dimensión dinámica y flexible a la gestión
individual.
Podemos esperar los siguientes beneficios:
?
Dotar de cierta inteligencia el proceso de parametrización de los sistemas
ERP, evitando la probabilidad de errores y diminuyendo el tiempo de
implantación.
?
Guiar y proporcionar información sobre las decisiones estratégicas
empresariales que influyen en la parametrización del sistema y sobre las
preferencias y la situación actual de cada empresa implementadora.
?
Mejorar el rendimiento del sistema ERP, cuyos resultados están
íntimamente ligados a su parametrización, mediante un proceso de calidad
que mida los resultados y retroalimente al sistema para guiar al usuario en
la modificación de la parametrización.
?
Obtener una estructura de parámetrización que permita una carga
automática directa sobre el sistema ERP, de forma que no sea necesario
esperar a que el sistema está instalado para realizar la parametrización,
sino que estas dos fases pueden realizarse en paralelo y así disminuir el
tiempo total de implantación.
-6-
1. Introducción
1.2. DESARROLLO DE LA INVESTIGACIÓN
El propósito primordial de este trabajo es el que sigue:
Crear un asistente de parametrización de sistemas ERP que
aúne las funcionalidades de los sistemas de parametrización
actuales con funcionalidades dotadas de cierta inteligencia en
la ayuda y tutorización de procedimientos, estableciendo así
mismo el marco metodológico adecuado para la creación de
contenidos procedimentales, estructurados y formalizados,
soportados por dicho sistema.
La consecución de este objetivo principal se lleva a cabo a través de otros
objetivos que podríamos considerar como subordinados a este. Proponemos, pues,
los siguientes como objetivos concretos:
?
Proponer una arquitectura para la construcción de un módulo con capacidad
de asistencia o tutorización para la parametrización en el marco de los
sistemas ERP. Dicha arquitectura, basada en los Sistemas de Ayuda
Inteligente y en los Sistemas Inteligentes de Tutorización, debe responder a la
problemática de la parametrización de los sistemas ERP y mitigar las
carencias encontradas en el uso de sistemas inteligentes en el ámbito de esta
tesis. Finalmente, asegurar el cumplimiento de las propiedades de una
arquitectura efectiva: reutilizable y exportable; compacta y flexible;
abstracta; bien documentada.
?
Articular el proceso de creación de contenidos procedurales mediante la
utilización de un método de trabajo explícito. Detallar las bases teóricas y
prácticas con las que trabaja el método definido y la justificación de su uso,
así como asegurar la utilización de herramientas y estándares extendidos en
el ámbito empresarial e ingenieril. Establecer las fases de trabajo para la
obtención, formalización y validación del conocimiento que utiliza el
asistente inteligente, basado en el modelado de reglas y redes semánticas.
Especificar una nomenclatura para nombrar e identificar las diferentes
entidades participativas en todo el proceso, así como sus relaciones.
?
Estudiar las taxonomías de estrategias empresariales existentes y analizar
las diferencias más significativas entre los tipos de estrategia identificados.
Como consecuencia de este estudio, proponer una taxonomía propia para esta
tesis cuyo objetivo es agrupar las diferentes empresas, posibles utilizadoras
-7-
1. Introducción
de sistemas ERP, según la estrategia empresarial que guíe el uso de dicho
sistema y, por tanto, su parametrización.
?
Realizar un control de calidad continúo, de forma que el asistente
inteligente proponga la revisión constante de la parametrización inicial del
sistema para adecuarse a los cambios y tienda siempre a la excelencia. De
este modo la gestión de la calidad permanente propuesta en esta tesis formará
parte de un proceso de mejora continua en un ámbito de la actual gestión
empresarial flexible.
Hemos descrito los objetivos del asistente inteligente propuesto en esta tesis, a
continuación expondremos las bases teóricas con las que trabaja:
?
El uso de una taxonomía empresarial que ayude al asistente a definir de
forma inteligente parámetros y condiciones de las reglas de producción del
dominio que faciliten la consecución de la estrategia empresarial.
?
La aplicación de una técnica para el modelado de procesos de entre las varias
existentes, que formalice los procesos de parametrización del sistema ERP y
que ayude la construcción de las redes semánticas;
?
La utilización de reglas de producción del tipo condición/acción/condición
que se relacionen entre sí formando redes semánticas y su representación,
utilizando una adaptación de la misma técnica para el modelado de procesos
anterior;
?
El uso de un conjunto de criterios e indicadores de calidad que formen una
métrica de calidad a utilizar en la evaluación del uso y los resultados del
sistema ERP implantado y que ayuden al asistente inteligente en su
retroalimentación.
Los objetivos, tanto arquitecturales como metodológicos, que nos proponemos
alcanzar se encuentran en línea con las actuales investigaciones y trabajos sobre la
utilización de los ordenadores como ayuda al conocimiento procedimental y a la
gestión de los procesos de negocio en todas sus fases. Nuestra propuesta contribuye a
la definición de un marco avanzado de dicha utilización y para ello el desarrollo de
la investigación se ha determinado mediante distintas fases y técnicas que se
exponen a continuación.
En primer lugar, se ha establecido la situación actual de los dos pilares básicos de
este trabajo: el desarrollo y evolución de los Sistemas Basados en el Conocimiento
en el ámbito empresarial, en concreto, los Sistema de Ayuda Inteligente y los
-8-
1. Introducción
Sistemas Inteligentes de Tutorización, y los sistemas ERP como gestión de
estrategias empresariales y, en concreto, el proceso de su parametrización. Se han
analizado las deficiencias y necesidades en el ámbito de los objetivos de esta tesis y
se ha desarrollado una arquitectura que completa las de los sistemas inteligentes
estudiados, adaptándola al escenario de los procesos de parametrización existentes
en los sistemas ERP. Para ello se han seguido los siguientes pasos:
?
Dar una visión global del sistema y de sus relaciones con agentes externos al
mismo.
?
Definir un estilo de representación basado en estándares ya existentes que
facilite su interpretación y proporcione uniformidad en su presentación.
?
Definir los componentes del mismo, la función de cada uno de ellos y sus
interconexiones.
?
Explotar los módulos del sistema en otros diseños arquitecturales que
contengan submódulos con sus funciones y sus relaciones.
?
Identificar de forma separada las funciones propias de cada componente de
cada submódulo y la información que recibe y que envía a otros componentes
o agentes externos.
?
Adaptar las nomenclaturas existentes hasta conseguir una propia que permita
una identificación clara de todos los elementos.
A continuación, se establecen las bases metodológicas, las herramientas y las
técnicas en las que se basa el asistente para cumplir sus objetivos y se detalla su
aplicación para la construcción (obtención, formalización y validación) del
conocimiento de los módulos definidos en la arquitectura. Las fases metodológicas
que se han definido son:
?
Análisis lingüístico. Se parte del conocimiento de los expertos en diversos
formatos y se modela en forma de diagramas EPC (Event-driven Process
Chains). Estos diagramas deben representar el proceso de parametrización del
sistema ERP mediante eventos y funciones, además añadiremos a las
funciones que realizan directamente parametrizaciones del sistema los
parámetros a definir en cada una extraídos del modelo de datos del sistema
ERP representado mediante una herramienta CASE (Computer Aided
Software Engineering). También se modela la posible información
explicativa adicional de cada elemento creado.
-9-
1. Introducción
?
Adaptación y validación. Los diagramas EPC que forman el modelo EPC se
implementan en la herramienta ARIS. Para ello debemos adaptar el modelo
obtenido a las normas de esta herramienta y definir el control de errores a
realizar. Este paso es importante, no solo por la utilización de un soporte
informático para la representación, sino también por el aseguramiento de la
calidad de los modelos que nos proporciona.
?
Formalización. Se exporta la información útil de la herramienta ARIS y se
formaliza cada modelo y cada diagrama mediante el lenguaje estándar
descriptivo XML. De esta forma pasaremos de un soporte gráfico
difícilmente procesable a través de herramientas informáticas a un lenguaje
estándar de definición.
?
Transformación. Se transforma la información obtenida en lenguaje XML a
reglas de conocimiento relacionadas entre sí formando una red semántica y se
asocia a las funciones o conclusiones de las reglas la información sobre los
parámetros y la información explicativa adicional.
?
Análisis estratégico. A través de los procesos, funciones y estrategias de cada
clasificación de la taxonomía desarrollada, e, incluso, de cada usuario
individual o colectivo, se establecerán a priori condiciones de las reglas y
valores de ciertos parámetros que obligarán a seguir un camino de la red
semántica.
?
Métricas de calidad. Mediante el conocimiento experto se formalizarán
criterios de calidad y sus valores aceptables y óptimos para cada clasificación
de la taxonomía desarrollada e, incluso, para cada usuario colectivo. Se
asociara cada criterio con una función, una regla de conocimiento y la parte
de la red semántica o subdominio a la que pertenece.
Finalmente, para validar y demostrar la aplicación real del trabajo desarrollado en
esta tesis, se aplicarán la arquitectura y metodología diseñadas a un prototipo que
genere los contenidos procedimentales necesarios y guíe en el proceso de
parametrización del sistema R/3 de SAP. El sistema elegido, R/3 de SAP, es uno de
los sistemas mundiales líderes en implantaciones ERP. El ámbito funcional del
prototipo se establecerá en uno de los procesos más utilizados en cualquier sistema
ERP, la gestión de la cadena de suministro, o supply chain, y, en concreto, en la
parametrización de la planificación de necesidades de material. Para completar el
prototipo se estudiará este subproceso para un tipo importante de estrategia
empresarial, dentro de la taxonomía creada para esta tesis, las empresas de
producción y venta del sector de telecomunicaciones.
- 10 -
1. Introducción
1.3. ESTRUCTURA DEL DOCUMENTO
Este documento, en el que se recoge el trabajo desarrollado, consta de seis
capítulos y tres anexos, cuya estructura y contenido se resume a continuación.
El Capítulo 1 incluye la motivación y justificación de la investigación que se ha
realizado, los objetivos a conseguir y los medios utilizados para alcanzarlos y
finaliza con la descripción de la estructura del trabajo.
El Capítulo 2 establece la situación actual de los dos pilares de este trabajo: los
sistemas de gestión empresarial y los sistemas inteligentes. Primero define el marco
funcional del trabajo, es decir, la gestión empresarial junto con una taxonomía de
estrategias empresariales que ayuda a clasificarlas según su finalidad y sus
necesidades de gestión y conocimiento. A continuación presenta una aproximación
histórica de los diferentes tipos de sistemas de información para la gestión
empresarial, detallando uno de ellos: los Enterprise Resource Planning o ERP,
estudiando su funcionamiento, arquitectura, objetivos, el valor añadido que aporta
tras su implantación en una empresa y el problema de su parametrización, cuya
solución establece el punto de partida de esta tesis. Por otro lado, da una visión
general de la Inteligencia Artificial y los Sistemas Basados en el Conocimiento y
analiza dos tipos especiales de SBC, los Sistemas de Ayuda inteligente (IHS o
Intelligent Help System) y los Sistemas de Inteligentes de Tutorización (ITS o
Intelligent Tutoring System), sistemas ambos que comparten objetivos con el
planteado en esta tesis. En concreto destaca, entre los IHS aquellos dirigidos a
aplicaciones informáticas y entre los ITS aquellos orientados al conocimiento
procedimental. Continua repasando el uso de los sistemas inteligentes en el ámbito
empresarial y, finalmente, como conclusión, relaciona la situación actual expuesta
con el sistema propuesto en esta tesis y las ventajas que este puede aportar.
El Capítulo 3 plantea, en el ámbito de la parametrización de los sistemas ERP,
una solución basada en un sistema inteligente que mitiga las carencias encontradas
en el uso de dichos sistemas en el ámbito de este trabajo. En primer lugar realiza una
propuesta arquitectural que presenta los distintos módulos que componen el sistema,
sus funciones, las relaciones entre ellos y la información que contienen y que
intercambian. A continuación establece una propuesta metodológica que detalla las
bases teóricas y prácticas con las que trabaja el sistema y la justificación de su uso:
desarrolla una taxonomía empresarial en el ámbito de las estudiadas en el Capítulo 2,
describe la técnica elegida para el modelado de procesos comparándola con las
existentes, define la utilización de las reglas de producción en redes semánticas y su
representación y estudia las métricas de calidad utilizadas en la implantación de
- 11 -
1. Introducción
sistemas ERP que ayudan a retroalimentar el asistente. En concreto, define la
formalización de la información y su validación utilizando herramientas y estándares
muy extendidos, como la técnica EPC, el lenguaje XML y las herramientas CASE y
ARIS. Finalmente detalla las fases metodológicas desarrolladas para dotar de
contenido a los distintos módulos que forman la arquitectura, es decir, realizar la
obtención y formalización de la base de conocimientos del dominio, de métricas de
calidad y de usuarios.
El Capítulo 4 desarrolla un prototipo basado en el asistente inteligente propuesto
en esta tesis, aplicado al sistema ERP SAP R/3. En primer lugar encuadra el ámbito
del prototipo: el sistema SAP R/3, el proceso de la cadena de suministro o supply
chain y el subproceso de parametrización de la planificación de necesidades de
material. A continuación establece las características particulares de este subproceso
para un tipo de empresa de telecomunicaciones, elegida dentro de la taxonomía
creada en esta tesis. Una vez seleccionado el entorno de aplicación del prototipo
realiza su análisis completo siguiendo la arquitectura propuesta: modelo de datos a
nivel conceptual y físico y modelo de procesos que define las funciones e interfaces
del asistente. Finalmente aplica la metodología propuesta para la creación de
contenidos en el desarrollo de las reglas y objetos de información necesarios para
implementar el subproceso elegido.
El Capítulo 5 contiene las conclusiones de la investigación llevada a cabo junto
con la exposición de algunos posibles trabajos futuros relacionados con el tema, que
podrían abordarse para continuar, completar, mejorar o aplicar el trabajo
desarrollado en esta tesis.
El Capítulo 6 contiene las referencias bibliográficas citadas a lo largo de la tesis.
Finalmente, el Anexo I presenta algunos ejemplos de elementos obtenidos
durante la obtención del conocimiento del dominio del prototipo construido en el
Capítulo 4, el Anexo II lista los diferentes datos que configuran el conocimiento del
dominio de este prototipo y el Anexo III muestra un pequeño diccionario de
términos relativos a la planificación de materiales, subdominio elegido para el
prototipo.
- 12 -
2 SITUACION ACTUAL Y PLANTEAMIENTO DEL
PROBLEMA
En este capítulo comenzaremos estableciendo el marco de nuestra propuesta, la
gestión empresarial, su problemática y objetivos, definiremos una taxonomía de
estrategias empresariales que ayuda a clasificar a las empresas según su finalidad y sus
necesidades de gestión y conocimiento. Repasaremos los diferentes tipos de sistemas de
información para la gestión empresarial y su función, comenzando por una
aproximación histórica. Presentaremos, con detalle, uno de estos sistemas: los
Enterprise Resource Planning o ERP, en concreto estudiaremos su funcionamiento,
arquitectura, objetivos y el valor añadido que aporta tras su implantación en una
empresa. Para finalizar este apartado plantearemos uno de los principales factores de
éxito en la implantación y uso de un ERP: el problema de la parametrización, cuya
solución establece el punto de partida de nuestra propuesta. A continuación daremos
una visión general de la Inteligencia Artificial y los Sistemas Basados en el
Conocimiento, estudiando su arquitectura y algunas clasificaciones de estos últimos.
Nos detendremos en dos tipos especiales de SBC, los Sistemas de Ayuda inteligente
(IHS o Intelligent Help System) y los Sistemas de Inteligentes de Tutorización (ITS o
Intelligent Tutoring System), sistemas ambos que comparten objetivos con el sistema
que plantea este trabajo. Nos centraremos en el estudio de sus fundamentos,
aplicaciones, difusión y arquitectura, presentando algunos ejemplos. Entre los IHS
destacaremos aquellos dirigidos a aplicaciones informáticas y entre los ITS aquellos
orientados al conocimiento procedimental. Repasaremos el uso de los sistemas
inteligentes en el ámbito empresarial, en concreto en los campos de gestión del
conocimiento, Gestión de las Relaciones con el Cliente o (CRM o Customer
Relationship Management), control financiero y producción. Finalmente, como
conclusión, expondremos la novedad que supone el uso de los sistemas inteligentes en
el contexto de la gestión empresarial que implica nuestra propuesta y las ventajas que
pueden aportar en su desarrollo.
- 13 -
2. Situación actual y planteamiento del problema
2.1. LA GESTIÓN EMPRESARIAL. INTEGRACIÓN Y
FLEXIBILIDAD
Como introducción al problema vamos a describir los cambios y los desafíos a los
cuales están sometidas las organizaciones empresariales en los últimos años, cambios y
desafíos que han revolucionado su gestión, causados, sobre todo, por la elevada
velocidad con la que la Tecnología de la Información y las Comunicaciones ha puesto a
disposición nuevos instrumentos capaces de cambiar los hábitos del consumidor y de
soportar la gestión y la organización empresarial.
La empresa puede ser estudiada en el marco de la teoría de sistemas, ya que
internamente es un sistema que existe dentro de otro más amplio (el ambiente). Por
tanto, como todo sistema, estará formada por un conjunto de partes (funciones) y las
relaciones entre ellas, orientado a un fin. La gestión empresarial consiste en organizar
las partes y sus relaciones de forma eficiente para la obtención del fin propuesto en la
planificación estratégica de la empresa. Las principales funciones objeto de la gestión
empresarial son [Dezi, 2000]:
?
La producción, se refiere al desarrollo de las actividades de compra y
fabricación, en general la transformación de inputs en outputs (bienes o
servicios) destinados al consumo final o a su utilización en otros procesos
productivos.
?
La logística, se ocupa de la gestión de los flujos físicos e informativos necesarios
a la producción y la distribución de bienes o servicios y de las relaciones dentro
del conjunto de la llamada cadena de suministro (supply chain)
?
La investigación y el desarrollo (I+D), se encarga de la investigación científica y
su aplicación en el entorno de la empresa y de la puesta a punto de los productos
y procesos de transformación.
?
El financiero, decide dos aspectos fundamentales: en que actividades específicas
y cuanto capital se debe invertir y el modo de conseguir los recursos necesarios
(financiación).
?
El marketing, a través del cual la empresa estudia el mercado, analiza las
tendencias de la demanda, la situación de la oferta, individualiza oportunidades
de negocio, orienta los procesos hacia el cliente y realiza actividades de
publicidad y difusión.
- 14 -
2. Situación actual y planteamiento del problema
?
La organización del personal, define la estructura organizativa, se ocupa de los
recursos humanos (selección, formación, desarrollo) y de las relaciones
sindicales y legales con el personal.
?
La organización y el control, responsable de coordinar las decisiones estratégicas
y las actuaciones operativas, en concreto es responsable de definir el buget (plan
anual de reparto de funciones y objetivos entre las partes de la empresa con el
fin de conseguir los objetivos estratégicos).
La globalización de la economía que afecta a todas las empresas, de todos los
sectores y dimensiones, conlleva una mayor competitividad y nuevos estímulos que
provocan la evolución, cada vez más rápida, de los mercados y la revisión constante de
fines y medios de los modelos económicos, operativos y organizativos, es decir de la
gestión empresarial. Este cambio se dirige hacia dos conceptos:
?
?
la integración, que implica extender la propia organización más allá, a los
suministradores y a los clientes y se interpreta como el primer paso de
organización en el entorno de la nueva sociedad de la información, propuesta en
todos los ámbitos;
la flexibilidad, que implica una actitud de alerta frente a los cambios y una
respuesta constante a situaciones imprevistas y nuevos problemas.
Estos dos conceptos unidos conducen al objetivo fijado por el Consejo Europeo en su
reunión celebrada en Lisboa los días 23 y 24 de marzo de 2000. En ella tras constatar
que “la Unión Europea se enfrenta a un enorme cambio fruto de la mundialización y de
los desafíos que plantea una nueva economía basada en el conocimiento”, fijó a la
Unión un objetivo estratégico esencial: “convertirse en la economía basada en el
conocimiento más competitiva y dinámica del mundo” [CCE, 2000].
El nuevo sistema de gestión empresarial integrada debe ser un sistema de gestión
abierto y flexible, capaz de adaptarse a los cambios continuos y capaz de manejar la
complejidad de estímulos, a veces confusos, que se reciben del exterior. Como expone
[Rifkin, 2000] “en un mundo de necesidades personalizadas, de continua innovación y
de actualización constante de productos con un ciclo de vida cada vez más breve, todo
envejece rápidamente: en un entorno en el que la única constante es el cambio, tener,
poseer, acumular deja de tener sentido”. Algunos cambios deben ser particularmente
remarcados, no solo porque aumenta la complejidad de la gestión y crea nuevos
desafíos, sino porque meten en discusión, tanto en el campo académico como
empresarial, la eficacia de los sistemas, procedimientos e instrumentos consolidados
([Chalmeta, 1999], [MICROSOFT, 2001], [Giachetti et alt, 2004]). Podemos citar entre
estos cambios:
- 15 -
2. Situación actual y planteamiento del problema
?
?
?
?
?
la progresiva globalización del mercado;
la oferta cada vez mayor de servicios frente a productos;
la calidad y el nivel de servicio como ventajas competitivas crecientes;
la descentralización productiva y organizativa;
la evolución tecnológica y el uso de las Tecnologías de la Información y
Comunicaciones.
En este contexto nace la necesidad de una visión integrada de la gestión que permita
perseguir un único objetivo de eficacia y eficiencia en todos los procesos de negocio. El
proceso se puede definir como la ordenación de las actividades en el tiempo y el
espacio, con un principio y un fin y unas entradas y salidas claramente identificadas. El
primer paso para conseguir este objetivo es el conocimiento profundo de los procesos de
negocio de los distintos departamentos de la empresa, el siguiente es la definición de
objetivos globales, medios y formas de conseguirlos, por último es necesario un cambio
en las personas que deben llevar a cabo el proceso, olvidándose de los objetivos
específicos de su área. El concepto de integración se encuentra en el centro de varias
posibilidades integradoras como muestra la figura 2.1.
Gestión empresarial
Sistemas financieros
Integración organizativa
Integración financiera
Procesos
de negocio
Integración tecnológica
Tecnología informática
Figura 2.1 Lógicas de integración
La lógica organizativa se basa en el control integrado de los procesos de negocio:
?
?
?
?
simplificación de estructuras;
innovación y anticipación al mercado;
objetivos globales frente a objetivos de área;
comunicación horizontal continua entre participantes;
- 16 -
2. Situación actual y planteamiento del problema
?
?
?
?
formación integral de responsables;
sistema de gestión del personal coherente con los objetivos estratégicos;
calidad en los resultados con costes y tiempo de ejecución mínimos;
rápida respuesta a los cambios.
La lógica financiera se basa en la adopción de un sistema financiero, contable y
administrativo integrado que permita responder a las necesidades de información de los
procesos de decisión, cada vez más complejos, y al contexto de internacionalización de
la nueva economía.
La lógica tecnológica es la que hace posible las dos lógicas de integración anteriores
gracias a la evolución de la tecnología informática y de comunicaciones. Se basa en una
arquitectura unitaria que permite la gestión integrada de los distintos procesos
empresariales partiendo de unos datos únicos y accesibles a todos los participantes y
generando información útil a todos los niveles de decisión (figura 2.2). La introducción
de nuevas tecnologías debe reforzar la capacidad competitiva de la empresa, aumentar
su eficiencia operativa y mejorar en nivel de servicio al cliente, pero el impacto deriva
no solo de las características tecnológicas adoptadas sino, también, de la adaptación de
la organización empresarial a las mismas. Una tecnología informática muy sofisticada
tiene un impacto limitado sobre los resultados empresariales si no se utiliza para
mejorar sus mecanismos de decisión y operativos. El problema crucial no es la
tecnología sino su utilización como soporte a la gestión integrada de la empresa, a las
lógicas de integración organizativas y financieras.
Alta
dirección
ord
en
es,
pla
ne
s, e
act
uac
tc.
ion
es
Comprimir y resumir
Información resumida y
abstracta, de ámbito general
Dirección
estratégica
Dirección táctica
Dirección operativa
Información
detallada y
específica
Largo plazo
>3-5 años
Medio plazo
1 año
Corto plazo
Sistema de Información
Figura 2.2 Intercambio de información empresarial
Cuanto mayor sea la flexibilidad introducida en estas relaciones, más fuertes las
presiones por calidad y mayores las necesidades de cumplimiento en tiempo, será mayor
la importancia de una buena definición de las necesidades del entorno y como cubrirlas.
Se haría mucho para resolver esta situación con la introducción de sistemas que logren
mejores niveles de autonomía, más compromiso y mayor conocimiento de lo que se
- 17 -
2. Situación actual y planteamiento del problema
hace. Los nuevos sistemas que soportan la gestión flexible deben estar en capacidad de
analizar lo que ocurre con una utilización constante de la información, guiados por la
experiencia y previendo los resultados que sus acciones pueden provocar antes de
realizarlas, para luego comparar lo que obtuvo con el resultado buscado. De esta forma
se reducirá el tiempo que se invierte en el proceso de analizar datos, de inferir resultados
y de monitorizar el proceso.
2.1.1. Taxonomía de estrategias empresariales
La estrategia empresarial es la respuesta de la empresa al ambiente en el que opera,
teniendo en cuenta las amenazas y oportunidad que el ambiente presenta así como las
capacidades y las competencias (puntos fuertes y débiles) que la empresa posee. [Coda,
1988] representa esta idea en la figura 2.3.
Identificación de
oportunidades y
amenazas
ambientales
Valoración de
puntos
fuertes/débiles de
la empresa
Que se
podría hacer
Análisis
situación
externa
Que se
puede hacer
Análisis
situación
interna
Estrategia
Que se
debería hacer
Que se
quiere hacer
Reconocimiento de
responsabilidades
sociales de la
empresa
Determinación de
valores y
aspiraciones de
la empresa
Figura 2.3 Proceso cognitivo de formulación de la estrategia
[Chandler, 1962] dice que la estrategia empresarial asegura la salud de una empresa
y que sus decisiones tanto tácticas, de las actividades cotidianas para una gestión
eficiente, como estratégicas, necesitan de una implementación a través de la ubicación
dinámica de los recursos, ya sean materiales o humanos, es decir, de su organización.
- 18 -
2. Situación actual y planteamiento del problema
La organización empresariales y, por consiguiente, su estrategia a sufrido una
evolución exponencial desde los comienzos de la era industrial hasta nuestros días. En
general un modelo organizativo se basa en la división y la coordinación: mayor
descomposición de tareas implica mayor nivel de coordinación necesario. El modelo
organizativo histórico de tipo Taylor-Ford, como analiza [Dubois et alt, 1995], se funda
en una fuerte división del trabajo (y del conocimiento necesario para realizarlo)
acompañada de una coordinación jerárquico-funcional. En esta organización los
individuos pierden su creatividad para ser unos meros repetidores mecánicos de reglas y
procedimientos, su presupuesto es la estabilidad. Evidentemente es coherente con el
entorno de su tiempo: producción en masa, calidad media, largo ciclo de vida del
producto y, por tanto, es simple y estandarizado. En la situación actual, expuesta en el
punto precedente, el modelo ha quedado obsoleto, es rígido en su ejecución y en su
capacidad de adaptarse a cambios externos, por lo que es necesario superarlo
incorporando mayor capacidad de evolución y dotando a los individuos de mayor
capacidad de decisión en base a un mayor conocimiento. La clave es la producción de
valor que implica una visión de la estrategia y de los comportamientos operativos de
tipo interdependiente, integrada, coherente con la mayor complejidad de las relaciones y
la globalización. En la tabla siguiente (figura 2.4) se expone un resumen de los tres
modelos históricos de estrategia empresarial.
Modelo artesanal (sentido histórico)
Volumen de mercado : bajo
Incertidumbre : bajo
Necesidad de conocimiento : medio
Conocimiento protegido y reservado, tácito (corporaciones)
Proceso de aprendizaje en el contexto (aprender haciendo)
Jerarquia de conocimiento. Centrado en individuo/grupo
La clave está en la velocidad de aumento de la capacidad productiva
Modelo Taylor-Ford
Volumen de mercado : alto
Incertibumbre : medio-bajo
Necesidad de conocimiento : bajo
Conocimiento explícito, alta división y especialización
Voluntad de asumir el saber tácito de cada función
Proceso de aprendizaje no contextual (formación, adiestramiento
profesional) y contextual (en el trabajo)
Jerarquia de posición / Centrado en las normas
La clave está en la velocidad de gestionar los cambios
Modelo Posterior Taylor-Ford
Volumen de mercado : alto y variable
Incertidumbre : alto
Necesidad de conocimiento : alto
Conocimiento tácito y explícito, especialización e integración
Voluntad de equilibrio dinámico entre conocimiento tácito y explícito
Proceso de aprendizaje no contextual (formación, adiestramiento
profesional) y contextual (en el trabajo)
Jerarquia de rol y posición / Centrado en la organización
La clave está en la velocidad de innovación
Figura 2.4 Comparación de los tres modelos históricos de estrategia empresarial
La tendencia actual es superar el modelo Taylor-Ford incorporando a las
organizaciones mayor capacidad de gestión del cambio interviniendo tres tipos de
elementos interrelacionados [Ruffino et alt, 2003]:
- 19 -
2. Situación actual y planteamiento del problema
?
?
?
Elementos físicos o capital invertido, como bienes inmobiliarios, máquinas,
herramientas, materias primas, semielaborado, etc.
Elementos de relación con el entorno, como relaciones con proveedores,
competencia, clientes, asociados, etc. Desarrollar relaciones que produzcan
disminución de costes, innovación tecnológica, fidelidad en los clientes,
acuerdos de calidad con proveedores, supone un valor hoy considerado mayor
que la mera posesión de capital.
Elementos de conocimiento, entendidos como el conjunto de competencias e
información del que dispone la empresa de un modo específico y que utiliza para
gestionar sus procesos de negocio. En los modelos estratégicos actuales es
considerado el elemento de mayor valor.
La interrelación de estos tres elementos se representa en la figura 2.5. En ella
podemos ver que una buena organización de los elementos físicos facilita la formación
contextual (en el trabajo, aprender haciendo), permitiendo tiempo de reflexión y
experimentación, lo que conduce a la innovación del proceso. Por otro lado la eficiente
planificación de los elementos de relación conlleva un mayor conocimiento del entorno
cambiante del negocio que asociándolo a los elementos de conocimiento produce la
innovación del producto adecuada. Finalmente la conexión entre los elementos físicos y
de relación permite una política de make-to-order orientada al cliente, que sustituye a la
política make-to-forecast basada en las previsiones. Igualmente la integración con
proveedores y asociados conlleva la mejora de la cadena de suministro con
descentramientos parciales de procesos que permiten respuestas flexibles a las
necesidades de la demanda.
Recursos humanos
Formación
Elementos de conocimiento
In
ón
Fo
de nov
i to
c
r
c
co m
a
pr aci
oc ó
nte ac
ov rodu
n
i
es n
xtu ó
In p
o
e
n
al
d
Integración de la
cadena de suministro
Elementos de relación
Elementos físicos
Make to order (en vez
Tecnología
Clientes
de make-to-forecast)
Existencias
Proveedores
Bienes
Asociados
de ia
no tenc
r
to e
En mp
co
Figura 2.5 Interrelación de elementos estratégicos
Adaptarse al modelo estratégico actual implica trabajar en tres direcciones:
1. Pasar de una organización por funciones a una organización por procesos. Hace
posible conocer la contribución de cada actividad al aumento del valor de los
elementos físicos, de relación y de conocimiento. Implica un cambio profundo
- 20 -
2. Situación actual y planteamiento del problema
de la organización del personal, de las competencias y de los hábitos de trabajo.
Cambio que se puede desarrollar realizando las siguientes actividades:
?
?
?
?
Reducción niveles jerárquicos intermedios;
Minimización de la división vertical del trabajo;
Aumento de responsabilidad de niveles directos;
Creación de formas organizativas transversales: por proyecto, por
problema;
? Introducción de medidas de trabajo por objetivos.
2. Redefinir los confines tradicionales de la empresa hacia un modelo en red,
flexibilizando las bases de la producción, disminuyendo costes transaccionales y
aumentando la capacidad de acceso a mercados y relaciones. Según [Castells,
1998] una empresa en red es “aquella forma específica de empresa cuyo sistema
de medios está constituido por la intersección de segmentos autónomos de
sistemas de fines. Por lo tanto, los componentes de la red son tanto autónomos
como dependientes frente a ella y pueden ser partes de otras redes y, por ello, de
otros sistemas de recursos dirigidos a otros objetivos... la empresa red
materializa la cultura de la economía informacional: transforma señales en
bienes mediante el procesamiento del conocimiento”. [Ernst,1992] define cinco
tipos de redes:
? Las redes de proveedores, que incluyen acuerdos de subcontratación,
manufactura de equipo original y manufactura de diseño original entre
un cliente (la “compañía central”) y sus proveedores de materiales
intermedios de producción.
? Las redes de productores, donde encontramos todos los acuerdos de
coproducción que permiten a los productores en competencia, unir sus
capacidades de producción y sus recursos humanos y financieros para
ampliar su cartera de productos y cobertura geográfica.
? Las redes de clientes, definidas como la previsión de vínculos entre las
compañías fabricantes y los distribuidores, los canales de mercado, los
revendedores de valor añadido y los usuarios finales, ya sean en los
principales mercados de exportación o en los internos.
? Las coaliciones de normalización, iniciadas por los fijadores potenciales
de las normas globales, con el propósito explícito de encerrar cuantas
más firmas sea posible, en su producto patentado o normas de interfaz.
? Las redes de cooperación tecnológica, que facilitan la adquisición del
diseño de un producto y la tecnología de producción, permiten una
producción y proceso de desarrollo conjuntos, y que se comparta el
conocimiento científico genérico y el I+D.
- 21 -
2. Situación actual y planteamiento del problema
3. Utilizar la gestión del conocimiento como centro integrador de la estrategia
empresarial. Esto se consigue reforzando los procesos formativos y los sistemas
de gestión de ayuda a la decisión. El problema de fondo es como pasar de los
dispositivos productivos a dispositivos cognitivos. Hay tres líneas de desarrollo:
? Pasar de la información al conocimiento a través de una revisión de los
sistemas informativos para la gestión empresarial en términos de
arquitectura, interfaces hombre/máquina y formas de representación del
conocimiento (pasar del analógico/tácito al digital/codificado).
? Enriquecer las relaciones ente los miembros de la organización y su
capacidad de aprendizaje y memoria organizativa.
? Soportar las decisiones de la dirección haciendo participes a los sujetos
directamente interesados y utilizando mecanismos automáticos que
controlen los factores y los procesos que intervienen en la decisión.
Una vez analizado el concepto de estrategia empresarial y su situación actual y
resumidas las líneas estratégicas históricas, es importante definir las taxonomías de
estrategias empresariales que podemos encontrar para clasificarlas. La razón de precisar
tipos (de empresa, de producto, de procesos etc.) en un estudio de la empresa se
encuentra en la misma estructura de una teoría o estudio de la realidad empresarial
necesaria para aplicar una perspectiva práctico-teórica partiendo de los problemas
reales.
Taxonomía (del griego,'tassis' = orden, 'nomos'= ley, norma) es la teoría de la
ordenación o clasificación. Incluye un sistema de clasificación, la teoría en la que se
basa dicho sistema y los métodos utilizados para construirlo. Expondremos los
conceptos teóricos básicos para realizar una buena clasificación antes de pasar a analizar
varias taxonomías existentes en el escenario empresarial.
Considerando el trabajo realizado por [Rodríguez de Rivera, 2000] podemos afirmar
que para resolver un problema hay que estructurarlo previamente, es decir: llegar a
definir sus parámetros, el contexto en que se da, los intereses propios etc. El
planteamiento del problema requiere tanto un trabajo mental de estructuración
imaginativa como un trabajo mental de codificación lingüístico-lógica. Estas dos
dimensiones, la visual-analógica y la lógico-verbal son pues básicas.
Ahora bien, la dimensión lógico-verbal requiere el empleo de categorías o conceptos
bien definidos, lo cual se consigue teniendo en cuenta tanto las similitudes del concepto
como las diferencias respecto a otros conceptos. Para poder delimitar conceptualmente
estas categorías dentro de un dominio real utilizamos los tipos, que nos permiten
describir ordenadamente objetos reales o mentales agrupándolos según características
- 22 -
2. Situación actual y planteamiento del problema
relevantes en el dominio donde los queremos aplicar. El proceso de creación de una
tipología depende del fenómeno que queremos clasificar, la finalidad de la clasificación
y las características y su grado de cumplimiento que elegimos para describir el
fenómeno.
Dado que nuestro trabajo pretende clasificar distintas estrategias empresariales, las
tipologías que podemos considerar deben referirse a modelos de explicación, pronóstico
y decisión unidos a métodos de planificación, dirección y control aplicables a distintas
situaciones. Es decir la finalidad de una clasificación de estrategias empresariales como
base a nuestra propuesta es, primero, preparar un buen fundamento para el trabajo de
elaboración de afirmaciones científicas que constituyen la base teórica de todo el trabajo
en la empresa y, después, posibilitar el desarrollo de soluciones a los problemas
prácticos de la empresa en procedimientos adaptados a los distintos tipos de procesos y
problemas.
Analizaremos las distintas taxonomías empleadas más comúnmente, las cuales
hemos agrupado por el criterio principal de clasificación. En algunos casos, se emplean
otros criterios adicionales que permiten estructuras jerárquicas o tabulares. Los criterios
de partida más empleados son: sectores, dimensión y estructura organizativa.
Taxonomía por sectores
Una de las taxonomías más básicas que utilizan el criterio sectorial la presento el
Gobierno Federal de los Estados Unidos, introduciendo una clasificación basada en el
sistema de clasificación de especies organizacionales definido por [McKelvey, 1982]. El
sistema de McKelvey establece cuatro criterios para desarrollar una clasificación:
?
?
?
?
Discontinuidades bruscas entre las formas organizativas.
Elevado nivel de homogeneidad interna en las clases obtenidas.
Estabilidad en los grupos a corto plazo.
Agrupaciones que muestren cambios evolutivos a largo plazo.
La Standard Industrial Classification (SIC) fue definida por la U.S. Office of
Management and the Budget en 1987, está centrada en el censo de los sectores
productivo y administrativo. Las informaciones de este censo se refieren a las compras,
ventas y/o fabricación de servicios, materiales o energía. El sistema de clasificación se
ordena jerárquicamente en varios niveles a los que se asignan diversos códigos
numéricos. A mayor número de dígitos se da más detalle en la clasificación: Así con
dos dígitos se designa el sector de productos alimentarios, con tres las industrias
cárnicas, con cuatro, las factorías de envase de carne, etc. Desde 1997 está clasificación
ha sido archivada y se utiliza una nueva clasificación, aunque basada en los mismos
- 23 -
2. Situación actual y planteamiento del problema
criterios, llamada la North American Industry Classification System (NAICS).
Actualmente, la versión en vigor es de 2002 [NAICS, 2002]. En ella los primeros dos
dígitos señalan el sector más grande del negocio, el tercer dígito señala el subsector, el
cuarto dígito señala el grupo de la industria, y el quinto dígito señala industrias
particulares. Los sectores principales se representan en la siguiente tabla (figura 2.6):
11
21
22
23
31-33
42
44-45
48-49
51
52
53
54
55
56
61
62
71
72
81
92
Agricultura, actividad forestal, pesca y caza
Explotación minera
Utilidades
Construcción
Fabricación
Comercio al por mayor
Comercio al por menor
Transporte y almacenamiento
Información
Finanzas y seguros
Propiedades inmobiliarias, alquiler y alquiler con opción a compra
Profesional, científico, y servicios técnicos
Gerencia de compañías y de empresas
Servicios administrativos, de soporte y de la gestión de desechos
Servicios de la educación
Cuidado médico y ayuda social
Artes y reconstrucción
Servicios del bienestar y de alimentos
Otros servicios (excepto la administración pública)
Administración Pública
Figura 2.6 Códigos principales de clasificación sectorial en NAICS 2002
Aplicando los cuatro criterios de McKelvey al entorno empresarial es más fácil
constatar las discontinuidades o diferencias, detallando hasta seis dígitos discriminando
tecnologías, dimensión de plantilla, entorno etc. que determinar la homogeneidad
interna, principalmente por falta de información reservada sobre la propia empresa,
como el plan estratégico, los procesos de negocio, etc.
Otras clasificaciones, dentro de las taxonomías por sectores, incluyen más de un
criterio, principalmente aquellos relacionados con la innovación. [Mahdjoubi, 1997]
introduce cuatro niveles de desarrollo tecnológico aplicables a cualquier sector. De esta
forma además de una clasificación sectorial, se puede determinar, dentro de cada sector,
el nivel de innovación alcanzado:
- 24 -
2. Situación actual y planteamiento del problema
?
?
?
?
Producción. Proceso básico de transformación de materias primas.
Diseño y Desarrollo. Circulación detallada de información entre procesos que
mejoran la producción.
Investigación industrial y Desarrollo. Un paso más allá del anterior, incluyendo
el uso de estándares, mejora continua, análisis de nuevos métodos, desarrollo de
procesos de calidad, etc.
Investigación básica o fundamental. Generación de información científica
genérica, más allá de un mero campo de aplicación.
Esta orientación hacia el proceso de innovación y desarrollo empresarial induce otras
clasificaciones, como la clasificación por áreas temáticas y horizontales de los Planes
Nacionales de I+D+I. En concreto, la clasificación del año 2003 contempla los
siguientes tipos:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Ciencias de la Vida.
Ciencias y tecnologías agroalimentarias y medioambientales.
Ciencias del espacio, matemáticas y física.
Energía.
Química, materiales y diseño y producción industrial.
Seguridad y Defensa.
Tecnologías de la Sociedad de la Información.
Transporte y construcción.
Humanidades, ciencias sociales y económicas.
Dentro de estos sectores se aplican patrones de innovación para determinar el grado
innovativo de cada empresa. Se consideran los elementos característicos, particulares de
cada sector, del proceso de innovación, como el tipo de recurso empleado, el tipo de
resultado obtenido o el impacto económico de la innovación, y elementos relativos a su
posición con respecto al mercado donde actúa. Las especificidades de los procesos de
innovación en la empresa pueden ser agregadas en un nivel sectorial puesto que las
industrias están formadas por empresas que generan productos que son
tecnológicamente similares [Scherer y Ross, 1990]. Sobre estas consideraciones, los
sectores pueden clasificarse a partir de elementos seleccionados sobre la aplicación del
nuevo conocimiento: grado de propiedad del mismo, su carácter acumulativo,
diversidad en términos de conocimiento base, etc.
Los primeros trabajos sobre patrones sectoriales de innovación se iniciaron en
contextos dinámicos donde cada patrón venía dado por la situación de las industrias,
dentro de una determinada estructura industrial, frente al ciclo de vida tecnológico de
los productos [Utterback, 1982]. Posteriormente surgió una línea de trabajos, de carácter
más estructural, más desligada de los productos, que considera que la similitud de los
- 25 -
2. Situación actual y planteamiento del problema
modos de innovación provenía de las características de los regímenes tecnológicos
sectoriales [Malerba y Orsenigo, 1995]. En éstos la clasificación surge de las
combinaciones entre dos tipos de características, las genéricas industriales y las
particulares de la propia empresa. Estas combinaciones llevan al desarrollo de formas
específicas de solución de problemas, convirtiendo el progreso técnico general en
trayectorias particulares que son desarrolladas sobre un cierto patrón de
comportamiento. Las características industrias se basan en el tipo de conocimiento que
utiliza cada industria. Son las que desarrollan y comparten las empresas que
desempeñan la misma actividad productiva e innovadora, y que son específicas de cada
sector, ya que en cada uno hay diferentes grados de codificación, de accesibilidad, de
apropiación y de difusión. Las características particulares de las empresas se basan en
como realizan estas sus procesos de innovación combinando las oportunidades
tecnológicas que ofrece el sector, con su propia capacitación específica definida por sus
competencias internas.
Esta última línea de trabajos que agrupa a los sectores según las similitudes de los
procesos de innovación, tuvo su punto de partida en la obra de Pavitt [Pavitt, 1984]. En
la taxonomía de Pavitt se incluyen, además de elementos relativos a la situación
tecnológica sectorial, como el grado de apropiación o de difusión, otros relativos a las
trayectorias tecnológicas seguidas por las industrias en base a cómo se desarrolla su
actividad productiva. Esto implica considerar que tareas productivas e innovadoras
están relacionadas hasta el punto de que las primeras condicionan a las segundas.
El patrón sectorial de Pavitt se realizó con el propósito de explicar las semejanzas y
diferencias entre sectores en el origen, de las que dependen la naturaleza e impacto de
las innovaciones. Estas se definen por el origen de las materias primas y procedimientos
empleados para su producción, por el tamaño y actividad de la empresa innovadora y
por el sector de producción y uso. La tabla de la figura 2.7 sintetiza la taxonomía de
Pavitt, en donde se identifican las trayectorias tecnológicas de las empresas como una
función de su principal actividad. Cada trayectoria sectorial viene definida, como hemos
visto desde los primeros estudios, por el origen del proceso de innovación, las
necesidades del usuario receptor y los niveles de codificación, accesibilidad,
apropiación y difusión.
Sectores de actividad típicos
DOMINADOS
POR LOS
PROVEEDORES
Textil, mueble,
madera, papel,
cuero y
calzado, artes
gráficas y
edición
INTENSIVOS
DE
ECONOMÍAS
DE ESCALA
Alimentarias,
vehículos
motor,
minerales no
metálicos
- 26 -
SUMINISTRADORES
ESPECIALIZADOS
Mecánicas,
instrumentos
BASADOS
EN LA
CIENCIA
Químico y
farmacéutico,
maquinaria
eléctrica,
eléctrico y
electrónico
2. Situación actual y planteamiento del problema
Suministradores (externo)
Tipo de
usuario
Sensible a los
precios
Principales
métodos de
protección
No técnicos:
marketing,
marcas
comerciales,
alto diseño
Secreto, diseño
y know-how
operacional,
gaps
tecnológicos
Principal foco de actividad
económica
Balance productos y procesos
Diversificación tecnológica
Reducción de
costes
Procesos
Baja-vertical
Mixto
Mejora de
productos
Procesos
Alta-vertical
Productos
Bajaconcéntrica
Principal
fuente de
aprendizaje
Producción y
servicios de
consulta
Producción,
suministradores y diseño
Usuarios
Principal
dirección de la
acumulación
tecnológica
Canales de
imitación y de
transferencia
tecnológica
Tecnología de
proceso y
equipo (hacia
arriba)
Compra de
equipo y
servicios
asociados
Tecnología de
proceso y
equipo (hacia
arriba)
Mejora de
productos
(concéntricas)
Compra de
equipo, knowhow, licencias
e ingeniería
inversa
Ingeniería
inversa,
aprendizaje de
usuarios
avanzados
Tamaño medio
de la empresa
innovadora
Pequeño
Grande
Pequeño
Determinantes
de las
trayectorias
tecnológicas
Otros
elementos
relativos a los
regímenes
tecnológicos
Otros aspectos
Suministradores,
departamentos
de ingeniería y
producción y
departamentos
de I+D.
(Interno)
Sensible a los
precios
Interacción
con usuarios y
clientes.
Diseño y
desarrollo.
(Interno).
Origen de la
tecnología y de
la acumulación
tecnológica
- 27 -
Sensible a los
resultados
obtenidos
Know-how
sobre diseño,
patentes y
conocimiento
de las
necesidades de
los usuarios
Departamentos
de ingeniería
de producción
e I+D de la
corporación.
Conocimiento
público
(Interno)
Combinación
entre ambas
Know-now
sobre I+D,
patentes,
secreto, knownow
operacional,
economías de
aprendizaje
dinámicas
Mixto
Mixto
Baja-vertical,
altaconcéntrica
I+D básica,
producción,
ingeniería y
diseño
Relación
productostecnologías
(concéntrica)
Ingeniería
inversa, I+D,
subcontratación de
científicos e
ingenieros
Grande
2. Situación actual y planteamiento del problema
Principales
tareas de
gestión
Uso de
tecnología
generada
externamente
para reforzar
las ventajas
competitivas
Integración
incremental de
nuevas
tecnologías en
sistemas
complejos.
Mejora y
difusión de la
mejor práctica.
Explotación de
ventajas en las
tecnologías de
proceso
Observar las
necesidades de
los usuarios
avanzados.
Integrar
nuevas
tecnologías en
productos
Desarrollo de
productos
relativos a sus
tecnologías,
explotar
ciencias
básicas,
obtener activos
complementarios.
Reconfigurar
las
responsabilidades
divisionales
Figura 2.7 Características sectoriales de los procesos de innovación según la
taxonomía de Pavitt
De acuerdo con estos elementos, y teniendo presente el diferente comportamiento
sectorial, las industrias pueden ser agrupadas en cuatro categorías:
?
Dominados por los proveedores. Son básicamente sectores tradicionales. Se
caracterizan por una escasa aportación a sus propios procesos de innovación
dado que la mayor parte de sus innovaciones proceden de los suministradores de
bienes de capital y de bienes intermedios. Las formas de apropiación son
habitualmente la ventaja tecnológica, el uso de marcas y la publicidad, las
técnicas profesionales y diseños muy específicos y sofisticados. La característica
principal de este tipo de industrias es la dependencia de otros sectores para llevar
a cabo su actividad innovadora, la cual pasa en muy escasa medida por procesos
de I+D internos. El trabajo de Pavitt prevé la posibilidad de que algunos sectores
dominados por los proveedores se lleguen a comportar como de producción
intensiva en economías de escala, si existen fuertes alteraciones de la demanda
por el acceso a mercados más amplios o si se producen importantes mejoras en
los procesos de producción.
?
Intensivos de economías de escala. Se encuadran dentro de una categoría más
genérica de producción intensiva. Los sectores de producción intensiva, son
aquéllos que, por la naturaleza y dimensión de su demanda, se caracterizan por
una fuerte división del trabajo y por una gran posibilidad de aprovechar rebajas
de costes de producción debido a una mayor facilidad, con respecto a otros
sectores, de sustituir capital por trabajo. Dentro de este grupo, los intensivos de
economía de escala son los de producción de bienes de consumo duradero. Los
procesos de producción son continuos, existen fuertes interdependencias entre
flujos de producción y técnicas operativas y los costes de error son altos, por lo
que es necesaria una constante observación del equipo. El origen de la
- 28 -
2. Situación actual y planteamiento del problema
innovación es interno y se localiza en departamentos de ingeniería de
producción. Si las tecnologías de proceso y los mercados finales alcanzan un
alto grado de madurez pueden llegar a comportarse como dominados por los
proveedores, especialmente en los casos del automóvil, alimentación, minería y
metales.
?
Suministradores especializados: Se encuadran, como los anteriores, dentro de
una categoría más genérica de producción intensiva. Dentro de este grupo, los
suministradores especializados son los de de producción estandarizada de
productos intermedios. Son aquéllos cuyas empresas suministran una producción
especializada en equipo e instrumentos a grandes empresas con las cuales
mantienen una estrecha relación usuario-proveedor. Las empresas grandes
proveen de experiencia operativa comprobando, diseñando y desarrollando
recursos para sus suministradores. Éstos, a su vez, proporcionan conocimiento
especializado y experiencia, que es el resultado de diseñar y construir equipos
para una gran variedad de usuarios que, con frecuencia, corresponden a
diferentes industrias. El origen del cambio técnico no se localiza en
departamentos internos de ingeniería o de I+D, sino que parte de las relaciones
entre usuario y proveedor dentro un proceso continuo de innovación basado en
la acumulación de conocimiento tácito a través del aprendizaje y la experiencia.
?
Basados en la ciencia. Se caracterizan por aprovechar en gran medida los
avances en la ciencia básica desarrollada en universidades y centros públicos de
investigación. La mayor parte de los avances registrados en los campos
científicos relacionados con el conocimiento base de estos sectores se traduce en
el desarrollo de tecnologías fuertemente permeables, es decir, con un amplio
rango de aplicaciones, que permiten a su vez el desarrollo de actividades
generalmente sometidas a fuertes cambios. Sin embargo, las dificultades de
explotación de todas las posibilidades que ofrece un campo tecnológico que se
desprende directamente del avance científico, puede llegar a limitar los
incentivos de las empresas a buscar oportunidades de innovación fuera de su
principal sector de actividad. El origen del cambio técnico es básicamente
interno, ya que las empresas suelen crear laboratorios internos de I+D a través
de los cuales desarrollan los procesos de aprendizaje necesarios para absorber y
adaptar los avances científicos que son realizados externamente.
Taxonomía por dimensión
Analizar el tamaño de las empresas como factor que condiciona su comportamiento
es la forma más utilizada en los estudios estadísticos, estratégicos y de comportamiento.
El tamaño es una variable que condiciona multitud de decisiones empresariales. Sin
- 29 -
2. Situación actual y planteamiento del problema
ánimo de exhaustividad, las empresas de dimensión pequeña y media tienden a ser
gestionadas directamente por sus propietarios en una proporción mayor que las
empresas grandes; presentan grados de integración vertical y de diversificación de su
producción menores que las empresas grandes, y operan en mercados cuyo ámbito
geográfico es más reducido [Segura et alt., 1992]. Cabe añadir a lo señalado que la
relación entre tamaño y variables de decisión es distinta según se distinga entre adoptar
o no la decisión y la magnitud con que se manifiesta dicha decisión. Como ejemplo
Julio Segura argumenta que la decisión de exportar exige una cierta dimensión para que
se observe como hecho probable (sólo el 18,1 por ciento de las empresas con empleo
entre 10 y 20 trabajadores exporta, y en las de más de 500 el porcentaje es del 87,4 por
ciento), pero, una vez tomada la decisión, el tamaño no es relevante respecto a la
intensidad con que se manifiesta, que es mayor en empresas de tamaño medio.
Para determinar el tamaño de una empresa, hay diversos criterios de clasificación. El
número de empleados es el más habitual, aunque no debe ser el único a utilizar, por
ejemplo la Comisión Europea y el Banco Central Europeo proponen utilizar también
datos económicos como el balance final, beneficios, total de ventas, etc. Otros estudios,
como el de [Panati y Golinelli, 1994], van más allá integrando factores organizativos y
de mercado como muestra la tabla de la figura 2.8.
ASPECTOS CUANTITATIVOS
DIMENSIÓN
PRODUCCIÓN
Artesanal
Modalidad
artesana
Mediana-grande
ORGANIZACIÓN
Escasamente
estructurada
Pequeña
Medianapequeña
ASPECTOS CUALITATIVOS
Modalidad
industrial
PODER DE
MERCADO
PODER
FINANCIERO
Ninguno
Ninguno
Escaso
Bien estructurada
Grande
Bueno
Elevado
Figura 2.8 Matriz de las fronteras dimensionales
La frontera entre las empresas artesanales y pequeñas no está en el número de
empleados sino en la modalidad del proceso productivo. El paso de pequeña a mediana,
cuando ambas presentan una producción industrial, está en la forma de estructura
organizativa. Finalmente para distinguir entre mediana y grande la medida viene
realizada por el poder sobre el mercado y el poder financiero que representan.
Utilizando la clasificación anterior [Pivato y Gilardoni, 2000] define más
concretamente los parámetros cualitativos:
- 30 -
2. Situación actual y planteamiento del problema
?
?
?
?
El capital invertido. Su uso está muy extendido, aunque cuenta con limitaciones
como el uso del leasing que desvirtúa la clasificación.
El número de empleados. Es el más sencillo de utilizar, aunque debe venir
acompañado del grado de automatización para facilitar la clasificación.
El facturado. Su uso debe estar condicionado a factores de inflación y valor del
producto unitario (por ejemplo metales preciosos frente a consumibles de bajo
precio).
El valor añadido. Es el más válido pero también el más difícil de medir. Resulta
de la combinación de las variables anteriores. En una única cifra debe dar idea
de la eficiencia empresarial, la productividad, la innovación, etc.
La figura 2.9 muestra la taxonomía presentada por Pivato y Gilardoni utilizando los
parámetros básicos.
EMPLEADOS
CAPITAL
INVERTIDO (€)
FACTURADO (€)
Pequeña
Hasta 50
Hasta 5 millones
Hasta 2 millones
Mediana
Hasta 250
Hasta 20.millones
Hasta 10 millones
Grande
Más de 250
Más de 20.millones
Más de 10 millones
Figura 2.9 Perfiles de dimensión empresarial
En España, [Benavente, 1992] ha realizado una taxonomía sobre empresas pequeñas
y medianas mediante técnicas de agrupación (cluster) multivariante obteniendo dos
clasificaciones. Una de ellas atiende al dinamismo de sus estrategias innovadora,
exportadora y comercial como criterio de clasificación, la segunda al sistema de
comercialización utilizado por la empresa.
?
Tipología I: innovación, exportación y estrategia comercial. Se considerarán en
este apartado tres variables de decisión para la empresa: su carácter innovador en
el ámbito tecnológico (gastos de I+D sobre ventas), la venta de sus productos en
el mercado exterior (exportaciones sobre ventas) y la realización de actividades
de promoción comercial (gastos de publicidad sobre ventas). La idea de agrupar
las empresas en función de la intensidad con que se manifiestan las tres
decisiones citadas parte de la hipótesis de que permitirá construir agrupaciones
muy correlacionadas con el tamaño. Se han identificado cinco grupos de
empresas: Empresas muy pequeñas que no realizan actividades de I+D, de
promoción comercial y de exportación; Empresas pequeñas orientadas hacia el
mercado interior con una actividad significativa de promoción comercial;
Empresas pequeñas, innovadoras y orientadas hacia la exportación; Empresas de
- 31 -
2. Situación actual y planteamiento del problema
tamaño medio orientadas hacia el mercado interior; Empresas de tamaño medio,
innovadoras, con fuerte participación de capital extranjero y muy exportadoras
?
Tipología II: estrategia comercial. En este apartado se ofrece una segunda
tipología que trata de caracterizar la naturaleza de las relaciones comerciales
entre las empresas y sus clientes. Se trata de establecer una taxonomía de las
empresas en función de los sistemas de comercialización que utilizan. Uno de
los criterios de segmentación empresarial más relevantes para conocer la
funcionalidad de las tecnologías de la información consiste en evaluar las
necesidades derivadas del sistema de comercialización utilizado por la empresa.
Complementando la tipología presentada en el anterior apartado, en este se
recoge una clasificación ajustada al criterio señalado: Empresas con integración
alta, media y baja de su distribución comercial.
Para finalizar destacar la tendencia actual en la Unión Europea, e incluso mayor en
España, del peso relativo en la economía de pequeñas y medianas empresas. Para
[Fariñas et alt., 1992] el examen de la distribución de tamaños de las empresas
proporciona el primer argumento que justifica la importancia económica de las
pequeñas y medianas empresas: son la forma más habitual de organización de la
actividad productiva. Las empresas situadas por debajo del umbral de empleo de 100
trabajadores representan en torno al 95 por ciento del total. Su importancia económica
queda, además, reflejada en el hecho de que dan empleo a algo menos de la mitad de los
efectivos laborales y generan la tercera parte del valor añadido industrial. La
interpretación de la actual disminución del tamaño medio de las empresas tiene todavía
un marcado carácter especulativo. Se apuntan, en este sentido, dos tipos de hipótesis
[Acs y Audretsch, 1990]. En primer lugar, las alteraciones asociadas con la mayor
incertidumbre en que operan las empresas en el mercado así como la inestabilidad
creciente de la demanda, junto a una mayor diversificación de los gustos de los
consumidores, habrían modificado los parámetros de la ecuación de eficiencia a favor
de las empresas de menor dimensión. En segundo lugar, la aparición y difusión de las
nuevas tecnologías flexibles habría reducido las diferencias de eficiencia entre las
empresas grandes y pequeñas. En este sentido, el mayor dinamismo del empleo de las
pequeñas y medianas puede provenir tanto de su mayor capacidad de adaptación a las
nuevas circunstancias como de la reducción del tamaño de los establecimientos
propiedad de grandes empresas por razones tecnológicas.
Taxonomía por estructura organizativa
Las organizaciones existen en la medida que permiten a un grupo de personas
coordinar eficientemente sus esfuerzos para obtener resultados deseables. La estructura
de una organización se forma por el tipo de roles o papeles a desempeñar por las
- 32 -
2. Situación actual y planteamiento del problema
personas del grupo, las relaciones entre ellas y, consecuentemente, los procedimientos
definidos que permiten estos roles y relaciones. Estructurar una organización es algo
más complejo que diseñar un organigrama con líneas y bloques, debe concebirse
considerando aspectos como la división del trabajo, las técnicas de coordinación, la
distribución de la capacidad de decisión, los límites y relaciones con el exterior, la
estructura social, la estructura política y la escala de poder y autoridad.
Desde los trabajos de 1910 del sociólogo alemán Max Weber sobre la burocracia
como forma ideal de organización hasta los años 50, los estudios sobre la estructura
organizativa contemplan solamente aspectos de productividad, incentivos y autoridad.
Es a partir de [Woodward, 1958] y [Burns y Stalker, 1961] que se comienza a relacionar
la organización con la estrategia empresarial. Woodward concluye que la definición de
la estructura organizativa depende de la tecnología utilizada. Burns y Stalker pensaron
que la estructura organizativa debe ser diferente según su uso en ambientes estables o en
ambientes dinámicos e innovativos. Llegaron a la conclusión que en el primer caso una
organización de autoridad y por funciones era la apropiada, pero en el segundo,
convenía utilizar modelos nuevos más flexibles. Todo esto llevo, en los años 60, a
asumir que no existe una única forma válida de concebir una estructura de organización.
Una estructura organizativa eficiente se basa en la adaptación o alineamiento con varios
aspectos del ambiente externo e interno: objetivos a conseguir, clientes, mercado,
contexto institucional y cultural, etc. que se enmarcan dentro de lo definido como
estrategia empresarial. Esta teoría es conocida como teoría contingente y su mejor
expresión se encuentra en los trabajos de [Lowrence y Lorsch, 1967] y [Gailbraith,
1973]. Durante los años 70 y 80 surge un debate entre aquellos que creen que la
estructura de la organización puede cambiar por acciones de la dirección y los que creen
que la estructura de la organización está totalmente condicionada a las circunstancias
ambientales. Dentro del primer campo se destacan los trabajos de [Nelson y Winter,
1982] y [Arrow, 1974] y en el segundo [Pfeffer y Salancik, 1978]. Al entrar en los años
90 la capacidad de organización se convierte en un factor crucial en el éxito
empresarial. Los estudios sobre la estructura organizativa tienden a ampliar sus factores
condicionantes: conocimiento, información, redes de comunicación, etc. Esta tendencia
sigue estando vigente en la actualidad, disminuye la certeza sobre el concepto de
estructura organizativa, hasta los 90 era sinónimo de orden y sistema, pero está
cambiando hacia la capacidad de comprender y dar sentido a la evolución de los
sistemas económicos y sociales. [Mintzberg, 1995] avanza en esta línea centrando su
aportación en lo que denomina configuraciones. La estructura organizativa se define a
partir de un conjunto de atributos a los que denomina configuraciones, entendiéndolos
como sistemas en los que tiene más sentido hablar de redes de interrrelaciones que
hablar de variables dominantes. Estas nuevas ideas provocan nuevas formas
estructurales híbridas o formas de organización flexibles, organizaciones planas, donde
se disminuyen los niveles jerárquicos y se tiende hacia la estructura por procesos y el
trabajo en grupo, donde la importancia del producto y del mercado da paso al
- 33 -
2. Situación actual y planteamiento del problema
protagonismo de lo intangible, tecnología de la información, relaciones de motivación
frente a relaciones de poder, valor añadido, orientación al cliente, servicio global, etc.
[Calamandrei, 1998]. Podemos resumir esta evolución histórica en la clasificación
representada en la tabla de la figura 2.10.
ÉPOCA
MERCADO
ORGANIZACIÓN
ESTUCTURA
PUNTOS DE
ATENCION
50-70
Ordenado y estable
Interna, con fuerte
jerarquía
Estructura, sistemas de
planificación y budget
70-90
Cambiante, aumento de
la competencia
Servicio al cliente, más
niveles de dirección y
gestión que productivos
Estrategia empresarial y
gestión de los recursos
humanos
90-
Turbulento, complejo y
altamente competitivo
Aprende, orientada a
procesos, grupos de
trabajo y mejora continua
Innovación, flexibilidad,
orientada al
conocimiento
Figura 2.10 Evolución histórica de estructuras organizativas
En teoría, dado el número de variables a considerar, debería existir un gran número
de estructuras organizativas. En la práctica, solo se siguen unos pocos modelos. Existen
tres formas fundamentales: funcional, por divisiones y por matrices, y algunos híbridos
o combinaciones de estas. Además existen las nuevas estructuras emergentes orientadas
a procesos y a la gestión de la información, denominadas estructuras en red. La mayor
parte las organizaciones adopta en sus primeros tiempos la estructura funcional, con el
crecimiento de productos o servicios o la ampliación de mercados o clientes pasa a la
estructura por divisiones. Por necesidades del mercado, pueden modificarse estas
estructuras si influyen notablemente varios parámetros, por ejemplo productos y
funciones o productos y localizaciones geográficas, creándose, así estructuras por
matrices. Finalmente veremos como los cambios de la actual sociedad de la información
conducen a las estructuras en red.
?
Estructura funcional. En una estructura funcional las actividades se agrupan en
funciones comunes, de la base al vértice de la organización. Las actividades se
coordinan verticalmente dentro de la función mediante supervisión jerárquica,
reglas y planes. Los empleados deben alcanzar los objetivos asignados a su
departamento funcional, adoptando valores definidos y una orientación común.
La semejanza aumenta la colaboración, eficiencia y calidad al interno de cada
función, pero hace complicada la coordinación y cooperación con otros
departamentos funcionales. Ya que estos son valores fundamentales para el éxito
de una organización, esta estructura necesita procesar una gran cantidad de
información entre funciones. La estructura funcional resulta la mejor cuando el
objetivo principal es la competencia, eficiencia y calidad en entornos estables,
- 34 -
2. Situación actual y planteamiento del problema
además favorece la formación de personal cualificado y especializado en sus
propias competencias. La debilidad de esta estructura es su incapacidad de
respuesta a los cambios ambientales que requieren colaboración entre
departamentos y funciones nuevas. También tiene la desventaja de que cada
empleado tiene una visión limitada de la organización y no conoce los objetivos
estratégicos, limitándole su campo de maniobra y responsabilidad.
?
Estructura por división. Esta estructura se diferencia de la funcional en que las
diversas funciones se agrupan en divisiones. Cada uno de los recursos existentes,
maquinaria, personal, investigación, etc. se asocia a una única división. Cada
división puede ser responsable de una familia de productos, de una zona
geográfica o de un tipo de cliente. Los empleados se identifican con su división
más que con su función y las estrategias, controles, budget y resultados se dan
por división. La coordinación entre divisiones se garantiza con la existencia de
un grupo de dirección que trabaja a nivel corporativo y define la estrategia
corporativa y la distribución de recursos. Uno de los problemas que aparecen es
el grado de autonomía en la toma de decisiones de cada división frente a la
dirección estratégica. Esta estructura es óptima cuando la incertidumbre
ambiental es moderada y el aspecto competitivo y los objetivos principales se
relacionan con la satisfacción del cliente o el mantenimiento de un segmento de
mercado. Cada división puede adaptarse a sus propios retos y ser responsable de
sus resultados. La desventaja está en la perdida de optimización de los recursos,
el potencial de una división de I+D se reduce exponencialmente al fragmentarse
en divisiones y las actividades comunes se multiplican por el número de
divisiones. La colaboración entre divisiones puede ser dificultosa, e incluso,
llegar a la competencia entre ellas. Este tipo de estructura funciona mejor en
organizaciones medianas o grandes que operan en ambientes heterogéneos y con
estrategias diferenciadas por producto o mercado o cliente.
?
Estructura por matrices. La característica de esta estructura es que implementa
simultáneamente la estructura funcional y la estructura por divisiones. Los
directivos funcionales y divisionales tienen la misma autoridad dentro de la
organización y los empleados deben responder a ambos. Hay una doble
autoridad, la funcional según el puesto en la organización y la divisional según
la actividad o proyecto que se pueda estar realizando en ese momento. La
asignación de recursos se plasma en forma de tabla, ya que las presiones
ambientales pueden venir de más de una dimensión crítica, como función y
producto o función y área geográfica. El ambiente interno también es complejo e
incierto, cambio de tarea o entre departamentos, interdependencias en la gestión
de recursos y eficiencia en dos direcciones. La ventaja de la organización por
matrices es la flexibilidad y la adaptación a los cambios, mientras que como
desventajas encontramos las relaciones de autoridad, el posible conflicto de
- 35 -
2. Situación actual y planteamiento del problema
intereses y el tiempo perdido dedicado a resolverlos y la falta de sentimiento de
grupo en los empleados. Emplear una estructura por matrices no es fácil, es
necesario compartir información y autoridad, balancear el dominio de una
estructura frente a la otra y trabajar de manera colaborativa.
?
Estructura híbrida. Las organizaciones más grandes no tienen una estructura
única, normalmente recurren a estructuras híbridas. En una estructura híbrida,
grupos de proyectos o de productos pueden trabajar con una estructura funcional
optimizando sus resultados, mientras que en otros algunas funciones clave
pueden centralizarse a niveles más altos, creándose una estructura parcialmente
funcional y multidivisional entre estos grupos de proyectos o productos. Las
ventajas e inconvenientes derivan de la combinación de estructuras elegidas y
del grado de independencia y de colaboración entre ellas.
?
Estructura en red. La estructura en red se diferencia de las tradicionales en los
aspectos que muestra la tabla de la figura 2.11.
FUNCIONAL
POR DIVISION
POR MATRICES
EN RED
División del
trabajo
En función de las
entradas
En función de las
salidas
En función de las
entradas y las
salidas
En función del
conocimiento
Técnicas de
coordinación
Supervisión
jerárquica, planos
y procedimientos
Director de la
división y staff
corporativo
Doble relación
Equipo
interfuncional
Poder de
decisión
Muy centralizado
Separación entre
estrategia y
ejecución
Distribuido
Altamente
descentralizado
Confines
Funciones
Mercados internos
/ externos
Interfaces
múltiples
Borroso y
cambiante
Importancia de
la estructura
informal
Baja
Media
Considerable
Alta
Política
Inter-funcional
Corporacióndivisión e
interdivisional
Entre los lados de
la matriz
Relaciones
inestables
Base de
autoridad
Competencia por
puesto y función
Dirección general,
responsabilidad y
recursos
Habilidad en las
negociaciones y
recursos
Conocimiento y
recursos
Figura 2.11 Comparación entre diferentes estructuras organizativas
La división del trabajo se basa en un conjunto de empleados expertos que
contribuyen individualmente o en grupos de competencias. Estos equipos no son
- 36 -
2. Situación actual y planteamiento del problema
siempre estables, pueden variar sus miembros y la estructura resultante es muy
flexible. Su trabajo se realiza bajo una mínima supervisión formal. Algunos
equipos se forman para resolver problemas específicos y desaparecen con el
problema. La alta dirección está formada también por un equipo no siempre
estable y se ocupa de decisiones de alto nivel, ya que se pretende que el poder de
decisión se distribuya a todos los niveles. La estructura se aplana, desaparecen
los niveles intermedios con responsabilidad de supervisión y transmisión de
órdenes e información. El uso de nuevas tecnologías de la información se hace
imprescindible para su eliminación, partiendo de la idea de información
compartida y disponible. Se difumina la barrera entre organización y ambiente,
intentando que clientes y proveedores participen en la estrategia, se firman
acuerdos marcos con proveedores, alianzas estratégicas con competidores y
programas específicos de seguimiento y contacto permanente con clientes
futuros o posibles, finalmente, se personalizan los productos y servicios para
clientes específicos. Estas relaciones se muestran en la figura 2.12.
Socio
desarrollo
Innovación
Gestión cadena
suministro
Cliente
Gestión de
relaciones
Empresa
red
Infraestructura
Proveedores
Filial
Estándares
Servicios
básicos
Servicios de
soporte
Servicios de
proceso
Figura 2.12 Relaciones en el funcionamiento de una estructura en red
La estructura informal predomina sobre la formal, es variable y depende de
acciones y relaciones personales. Su principal ventaja es su adaptabilidad y
rápida respuesta a estímulos ambientales, en contrapartida, pueden duplicarse
recursos y la responsabilidad es difícilmente atribuible y escasamente definida.
Es la mejor opción en contextos donde la innovación es la principal ventaja
estratégica. En condiciones estables puede resultar menos eficiente que otras
estructuras.
Como resumen podemos presentar el cuadro de la figura 2.13 que muestra las
principales ventajas y desventajas de cada estructura.
- 37 -
2. Situación actual y planteamiento del problema
FUNCIONAL
POR DIVISION
POR MATRICES
EN RED
Uso eficiente de
los recursos
Óptimo
Escaso
Medio
Bueno
Uso eficiente del
tiempo
Escaso
Bueno
Medio
Óptimo
Sensibilidad
Escaso
Medio
Bueno
Óptimo
Adaptabilidad
Escaso
Bueno
Medio
Óptimo
Responsabilidad
Bueno
Óptimo
Escaso
Medio
Ambiente idóneo
Estable
Heterogéneo
Complejo, con
demanda múltiple
Cambiante
Estrategia idónea
Focalizada / bajo
coste
Diversificada
Basada en la
sensibilidad al
ambiente
Innovativa
Figura 2.13 Ventajas y desventajas entre diferentes estructuras organizativas
2.1.2. Sistema de información para la gestión empresarial
Para [Andreu y Ciborra, 1996] un sistema de información empresarial es el sistema
encargado de coordinar los flujos y registros de información necesarios para llevar a
cabo las funciones de una empresa de acuerdo con su planteamiento o estrategia de
negocio. Los sistemas de información es uno de los instrumentos más importantes de
los que dispone una organización para alcanzar sus objetivos. La información que
contiene y distribuye puede ser contable o extracontable (mejoras en los resultados de la
producción), interna o externa a la organización, indicativa o necesaria, de valoración o
de control. En cualquier caso, es un soporte esencial en la toma de decisiones y el rápido
desarrollo de las tecnologías no hace más que incrementar este papel.
Los sistemas de información para la gestión empresarial se forman con el conjunto
de la información necesaria, su flujo a través de la organización y los recursos humanos
y materiales utilizados. Realmente tan importante es la construcción inicial de estos
sistemas, adecuada a las necesidades de la organización, como su posterior
mantenimiento en función de las nuevas necesidades y de la evolución de la oferta
tecnológica. Desde esta perspectiva es imprescindible la formación continua e investigar
la aplicación de las tecnologías emergentes a encontrar nuevas soluciones dentro del
Plan Estratégico de la organización.
El principal objetivo de un sistema de información consiste en la individualización,
recogida y difusión en el ámbito apropiado de la información pertinente. Para esto,
actualmente, las organizaciones utilizan ampliamente la tecnología informática y
- 38 -
2. Situación actual y planteamiento del problema
telemática emergente en cuanto hardware, software de base y aplicativos (programas de
planificación del proceso, aprovisionamiento, facturación, etc.) El sistema debe estar
integrado para poder asegurar que la información sea única, veraz y accesible para todos
los interesados, permitiendo un flujo informativo automático entre las actividades
funcionales (primarias y de soporte) y la dirección. La elección del sistema informativo
es, por tanto, muy importante y se debe prestar la máxima atención en el diseño e
implementación del sistema.
El uso de los sistemas de información (manuales o automáticos) en la mejora de la
gestión empresarial nace con la revolución industrial. Veamos a continuación los
diferentes sistemas desarrollados, que nacieron junto a la historia industrial.
Antes de 1770 se puede considerar que la industria existente era solamente
doméstica. Fue a partir de ese año y hasta principios de 1800 cuando se desarrolla la
Revolución Industrial en Inglaterra que alcanza después al resto de Europa, América y,
finalmente, a Asia. Es en esta época cuando la producción se organiza en fábricas con
gran número de mano de obra donde el único objetivo era producir la mayor cantidad
posible. Comienza el desarrollo de maquinaria, sobre todo textil, y el auge del
capitalismo al crecer la demanda de productos.
Durante la mayor parte del siglo XIX la organización de las fábricas era casi de tipo
militar: un grupo de obreros recibía órdenes de un capataz y el grupo de capataces las
recibía del supervisor. Era el supervisor el que definía los objetivos de producción
(cantidad a producir en un periodo de tiempo, que podía ser diario) y los capataces
decían que se tenía que hacer: reparar las máquinas, producir más rápido, controlar la
calidad, etc. Se suponía que los trabajadores encontrarían el material en el almacén. El
resultado de todo esto era una gran cantidad de fallos en la producción e ineficiencia.
No fue hasta 1878-1890 que Frederick W.Taylor comenzó, en Estados Unidos, a
teorizar sobre la organización de la producción y a experimentar en una fábrica de
Philadelphia. Las innovaciones de Taylor incluían un estudio de los tiempos y métodos
de producción, tarjetas con instrucciones para los trabajadores, estandarización de
herramientas y máquinas y mucho más. Pero sin duda, su idea más importante fue
separar la planificación de la ejecución, desarrollando en la fábrica un grupo de
especialistas independientes de la producción encargados de decidir. Esta idea ha sido
muy importante en el posterior desarrollo de los sistemas de producción.
En 1915 Ford W.Harris desarrolló una fórmula para calcular lo que hoy llamamos
lote mínimo de producción, que es la cantidad que se debe producir por orden que
minimiza el coste de producción y de movimientos de almacén. Fue la primera vez que
se utilizaron métodos analíticos para resolver problemas de inventario. Esta idea tuvo
- 39 -
2. Situación actual y planteamiento del problema
gran impacto en el mundo industrial y se desarrollaron dispositivos mecánicos que
calculaban el lote mínimo.
En 1928 T.C.Fry propuso el uso de estadísticas de los niveles de inventario para
obtener el nivel ideal de inventario en función del servicio al cliente que se deseaba dar,
describiendo el modo de calcular el 'punto de ordenación'.
En los años cuarenta el desarrollo de la industria, sobre todo militar, modernizó los
métodos de producción, se empezaron a utilizar máquinas de cálculo y tarjetas
perforadas, así como teletipos y tubos neumáticos para establecer una comunicación
más veloz entre el departamento de planificación y control y la línea de producción. Se
comenzó a utilizar una estructura de producto codificada que se explotaba en función de
las órdenes futuras de los clientes (típicamente tres meses) para calcular que había que
producir y que componentes había que comprar creándose así los primeros planes de
producción y de compras. Paralelamente se formularon modelos matemáticos
relacionados con la utilización de variables para optimizar la efectividad. Después de la
guerra se empezó a centrar la atención en problemas comerciales y de gestión de alto
nivel, como los métodos de obtención de la demanda previsional a largo y medio plazo,
el control del inventario y la programación de las líneas de producción.
En los años cincuenta las exigencias de los clientes se hicieron cada vez más
apremiantes, siendo el tiempo de respuesta exigido mayor. Las consecuencias fueron el
cambio de método en la mayoría de las industrias, pasando de una producción 'make to
order' a 'make to stock' y el desarrollo de sistemas de 'master scheduling', es decir, de
gestión completa de la orden cliente.
En esta nueva situación se utilizó la política de producción 'a punto de ordenación',
que consiste en que tan pronto baje el nivel de inventario de un punto definido, el
llamado 'punto de ordenación', se genera una orden con la cantidad del lote económico.
Estos dos parámetros se definían según los estudios teóricos ya existentes (como vimos
anteriormente) y después de varios años de experiencia y ensayo.
Respecto a la gestión del 'master scheduling' a finales de los años cincuenta se
desarrollaron nuevas técnicas de gestión de proyectos, como la conocida PERT
(Program Evaluation and Review Technique) utilizada, por ejemplo, en la planificación
del desarrollo y la producción de los sistemas de misiles Polaris.
Otro hecho importante ocurrió en los años cincuenta y fue la fundación en 1957 del
grupo APICS (American Production and Inventory Control Society) Su número de
socios creció rápidamente y continúa así actualmente. Sus actividades docentes, la
distribución de documentación y publicaciones especializadas en el campo de la
planificación y el control industrial son fundamentales. El diccionario APICS ha sido y
- 40 -
2. Situación actual y planteamiento del problema
es utilizado en la estandarización de la terminología de esta área, así como en el
desarrollo de esta tesis.
En los años cuarenta se empezaron a desarrollar computadores electrónicos en
universidades y centros de investigación. Sin embargo, hasta los cincuenta no aparecen
los primeros computadores comerciales: 1951 UNIVAC I; 1953 IBM 701; 1954 IBM
650.
Las primeras aplicaciones informáticas en el área industrial fueron procesadores de
estructura de materiales llamados BOMP (Bill Of Material Processors) y planificadores
de necesidades de material o MRP (Material Requirements Planning). El BOMP
cargaba y mantenía los datos referentes a la estructura del material. El MRP utilizaba
los ficheros anteriores para explotar los niveles altos de productos que aparecían en las
órdenes cliente y desarrollar un plan de producción o compra de los componentes.
Durante los años sesenta las empresas comerciales de software comenzaron a
comercializar paquetes MRP estándar. El más extendido fue el COPICS para IBM.
En 1971 APICS decide iniciar una campaña de difusión del MRP automático en
contra de los sistemas manuales. Cada vez más compañías introducen el MRP y pronto
empieza a ser obvio que el MRP es solo parte de un sistema y que sus resultados son
limitados. Por ejemplo, el MRP determina los planes de producción y de compras
basándose en el resultado de la función 'master scheduling', si esta entrada es
equivocada o poco fiable lo serán también los planos obtenidos. Por tanto en los años 80
todos los esfuerzos han estado dirigidos a desarrollar sistemas MRP II (Manufacturing
Resource Planning), añadiendo al MRP módulos para la gestión de las órdenes cliente,
de los recursos y de la fábrica en el nivel de programación de la producción.
Desarrollada la idea MRP II se empieza a pensar que los datos que necesita son los
mismos que los utilizados para el plan del budget haciendo una sencilla conversión de
unidades físicas a moneda, cerrándose así todo el ciclo.
A la vez que el sistema empieza a ser más amplio y a cubrir más campos las
empresas empiezan a dejar de hacer sus propios sistemas software y a comprar paquetes
estándar. Actualmente la industria de comercialización, instalación y consultoría de
paquetes MRP II está muy extendida y cada vez se desarrollan más paquetes y con más
posibilidades, haciéndolos más flexibles, para evitar las personalizaciones.
A partir de 1975 empezaron a comercializarse los primeros microcomputadores y,
desde entonces, se han desarrollado aplicaciones MRP II para ellos.
En los años ochenta las compañías americanas y europeas empiezan a imitar la
técnica japonesa del JIT (Just In Time) cuyos principales objetivos son la disminución
- 41 -
2. Situación actual y planteamiento del problema
de personal, materiales y recursos. En el área de producción implica disminuir los
costes, mejorar el control de calidad y el diseño físico de la fábrica. En el área de
compras significa aumentar la fiabilidad del producto comprado y mejorar las relaciones
con los proveedores, estableciendo contratos cuadro que dentro de unas cantidades y
tiempo predefinidos que consientan cierta flexibilidad en los pedidos.
En los años noventa y en el principio del nuevo milenio el desarrollo informático en
este campo es muy grande, intentando cubrir las necesidades industriales con la misma
velocidad con la que aparecen. En este sentido podemos hablar del nacimiento de los
sistemas CIM (Computer Integrated Manufacturing) de ayuda a la fabricación, en
funciones tales como transporte y almacenamiento de piezas, gestión de stocks y de
puestos de trabajo basados en robots industriales. Posteriormente aparece un concepto
más amplio: SCM (Supply Chain Management), sistemas que son capaces de gestionar
todas las relaciones existentes en un proceso industrial y de integración con clientes y
suministradores. La máxima de ‘orientación al mercado’ de los últimos años ha
cambiado el modo de actuar en las organizaciones. El centro de la actividad no es ya
saber producir bien sino saber producir aquello que potencialmente quieren los clientes.
El nacimiento de los sistemas CRM (Customer Relationship Management) intenta
cubrir esta necesidad dando la posibilidad, mediante tecnología de última generación, de
analizar, segmentar y clasificar la relación particular con el cliente. CIM, SCM, CRM
deben ser, por tanto, integrados en los sistemas denominados ERP (Enterprise Resource
Planning) verdaderos gestores de la información de la organización. El mundo había
cambiado y estas soluciones nacidas en los ambientes de manufactura ya eran
insuficientes para un mercado donde había organizaciones de todo tipo: de servicios,
financieras, comerciales, entre otras, que también necesitaban una solución para
controlar sus procesos y, en consecuencia, ser más competitivas. Así nace el concepto
ERP integrado, con él se inició el control de áreas como contabilidad, finanzas,
administración de órdenes de venta y logística, entre otras, bajo un solo y transparente
sistema de información. En este escenario surgen empresas que no sólo desarrollan, sino
venden e implantan estas soluciones que, al tener tanto éxito, logran expandirse de
manera rápida por el mundo empresarial. La figura 2.14 muestra las áreas de influencia
de un sistema ERP integrado.
- 42 -
2. Situación actual y planteamiento del problema
Análisis de
datos
Recursos
humanos
Ventas
SISTEMA
ERP
Fabricación
Servicios
Finanzas
Gestión de
la cadena de
valor
Figura 2.14 Áreas de influencia de un sistema ERP integrado
Situándonos el en estado del arte actual, el uso de las nuevas tecnologías en los
sistemas de información representa un factor clave en el actual mundo empresarial
competitivo:
?
?
?
Permiten tratar todo tipo de información (audio, video, texto, etc.) de forma
integrada, haciéndola disponible y manipulable a costes extremadamente
reducidos.
Permiten representar en modo virtual el mundo real, disminuyendo tiempos de
investigación, desarrollo y de proyecto y aumentando la eficacia de los procesos
de aprendizaje.
Son la base de los nuevos modelos de economía basada en el conocimiento, en
los cuales la clave se encuentra en la representación del conocimiento y en la
capacidad de aprendizaje, en vez de en los recursos materiales.
Su evolución es ya un hecho y se desarrolla por tres vías fundamentales: EDI
(Intercambio Electrónico de Datos), internet y aplicación de sistemas inteligentes.
2.1.3. Sistemas Enterprise Resource Planning (ERP)
Término que designa soluciones o procedimientos configurados como sistemas de
información orientados a la planificación de todos los recursos de una empresa. Estas
soluciones cubren de forma total o parcial todas las áreas de actividad de una empresa.
Son soluciones a los problemas o necesidades de los usuarios del sistema considerado
(empresa o red) en las distintas áreas operativas: económico-financiera; logísticocomercial, producción y recursos humanos.
- 43 -
2. Situación actual y planteamiento del problema
Optimizar los recursos de una empresa pasa por una planificación seria, pero con un
punto de flexibilidad. Una buena organización es clave para lograr que los planes
empresariales se cumplan. Con este objetivo, nacieron los llamados ERP (Enterprise
Resources Planning) hace ya más de dos décadas.
Los ERP pueden ser vistos desde distintas perspectivas, simplemente como
productos software o, utilizando una visión organizativa empresarial, como el creador
de una estructura integrada de procesos y datos en una organización. Podemos encontrar
varios estudios que utilizan esta definición. [Klaus et alt., 2000] define ERP como ‘una
solución software que busca integrar el rango completo de procesos y funciones de
negocio para presentar una visión holística de los negocios desde la arquitectura de los
Sistemas de Información’. [Yen y Chou, 2001] se refieren a los ERP como ‘software
que puede ser usado para integrar información a través de todas las funciones de una
organización para automatizar los procesos de negocio corporativos’. Claramente, de
ambas definiciones, se extrae la idea de información compartida e integración de
funciones. De forma más precisa [Hedman y Kalling, 2002] destacan la utilización de
una única base de datos que permita a los distintos departamentos de una organización
compartir de forma efectiva la información y comunicarse entre ellos. [Yen et alt.,
2002] destacan la eliminación de información redundante de la base de datos y de
distintas versiones de ella, en beneficio de la calidad de los datos y de su mejora como
soporte a las decisiones.
En un principio, los ERP- sistemas integrados de planificación y gestión- emergieron
en el mundo de las fábricas para optimizar sus recursos. Se trataba de unos ERP menos
sofisticados que los actuales, pero bastaron entonces para revolucionar las empresas con
una lógica muy simple: se fija el momento en que una de las etapas de la fábrica toca a
su fin y, a partir de ahí, se emprende una segunda etapa. Este sistema permite establecer
de antemano cuándo se inicia una fase y cuándo concluye, para pasar a lanzar la
siguiente. Al mismo tiempo, se resta automáticamente el material empleado del total de
stock disponible, para que los responsables sepan qué cantidad exacta hay que reponer
tras un proceso. Esta forma de optimizar el control de los materiales fue, ya en los 70,
un enfoque de futuro para las empresas. Los sistemas de gestión utilizados hasta
entonces cubrían aspectos muy básicos, poco a poco se fueron añadiendo programas y
aplicaciones individuales que realizaban tareas muy concretas y que no se integran con
el resto. Con los años las organizaciones contaban con sistemas parcheados que
proporcionaban información duplicada, a veces inconsistente entre sí. Los problemas
que se generaron no fueron solo técnicos: actualizaciones, duplicaciones, sino, también
estructurales y organizativos. El coste global de mantenimiento de estos sistemas y el
añadido por la falta de datos de calidad como soporte a las decisiones creció
rápidamente. En este contexto la introducción de sistemas ERP, con su promesa de
integración y calidad, fue como el cumplimiento de un sueño [Markus y Tanis, 2000].
- 44 -
2. Situación actual y planteamiento del problema
Hoy en día, los Enterprise Resources Planning se han vuelto más complejos
pudiendo alcanzar, no sólo el área de operaciones, sino también otros departamentos de
la empresas, como el de Finanzas o el de Recursos Humanos: ya estamos en la era de
los sistemas llamados MRP II (Manufacturing Resources Planning). Ahora las
necesidades de flexibilidad e integración obligan a llevar a cabo la gestión de toda la
empresa como si fuera una sola unidad. [Markus y Tanis, 2000] describen este hecho
como ‘una compañía, un sistema’. Todo ello ha permitido, durante los últimos años,
generar valor e incrementar los beneficios a través de una cultura orientada a la eficiente
gestión de los recursos internos. La figura 2.15 muestra la estructura de un ERP
estándar.
Área
Administrativa
Área
Logística
Área
Comercial
Área
Producción/
Técnica
Figura 2.15 Estructura por áreas de un ERP estándar
El Área Administrativa cubre las funciones de Contabilidad general, Control de
gestión, Tesorería, Gestión financiera, Gestión económica de las relaciones con clientes
y proveedores y de los créditos y Gestión del personal.
El Área Comercial cubre las funciones de Gestión de las relaciones con los clientes,
Marketing, Políticas comerciales y de precios, Gestión de agentes, vendedores y
representantes, E-commerce, Generación de órdenes cliente y Emisión de Ofertas.
El Área de Producción/Técnica cubre las funciones de Definición y gestión técnica
del producto, Generación de órdenes de producción a distintos niveles, Gestión de la
subcontratación, Planificación y control de la actividad productiva, Gestión de la
calidad del producto, Sistemas CAD/CAM y Asistencia técnica postventa.
El Área Logística cubre las funciones de Integración de los distintos procesos de
negocio, Organización lógica y física de productos y materias primas, Gestión de la
existencia física de materiales y su aprovisionamiento, Almacenamiento y distribución
de los productos y Clasificación de los materiales en recepción.
Los sistemas ERP, como el resto de la tecnología de la información, han
evolucionado muy rápidamente. Durante la década de los ochenta se diseñaban para
sistemas mainframe, en los noventa esta estructura dejo paso a la arquitectura cliente- 45 -
2. Situación actual y planteamiento del problema
servidor y, en nuestros días, se están creando nuevas versiones que utilicen las ventajas
de la web.
El funcionamiento de un sistema ERP estándar se basa en la existencia de una base
de datos común y unas funciones integradas, de esta forma se evita el problema de la
fragmentación de la información en las grandes empresas y se obtiene una cultura
empresarial compartida con funciones, datos, procedimientos y lenguaje común. Esta
ventaja se muestra en la figura 2.16, en ella se ve como antes del uso de un sistema ERP
cada función se soporta mediante múltiples aplicaciones e interfaces, cada una con su
propia base de datos. En el modelo posterior cada aplicación se soporta mediante un
único módulo del sistema y las interfaces entre módulos y todas las aplicaciones utilizan
una única y central base de datos. Además, el sistema es escalable, es decir, se pueden
añadir módulos con nuevas funciones cuando se necesiten.
R.H.
Finanzas
Operaciones
ERP
R.H.
Finanzas
Operaciones
Figura 2.16 Antes y después del uso de un sistema ERP
Además de la integración de la información los sistemas ERP proporcionan un
conjunto de procesos de negocio basados en las buenas prácticas [Davenport, 1998].
Normalmente es un modelo predefinido para empresas de un sector o de un tipo de
negocio y de un tamaño. La flexibilidad necesaria para cada empresa individual la
proporciona un conjunto de parámetros integrados en la base de datos que permiten, a
niveles muy detallados, aplicar distintas estrategias empresariales. Los datos contenidos
en el sistema podemos dividirlos en tres grandes grupos: anagráficos (clientes,
productos), documentos (facturas, órdenes de producción) y configuración (parámetros
y preferencias). En cuanto a las funciones del sistema podemos clasificarlas en entrada
de datos, elaboración y transformación y reporting o generación de informes, tanto
operativos (detalle de datos de control, impresión de documentos) como de dirección
(estadísticas, análisis). El sistema gestiona la actividad por procesos, no por funciones.
Además de la visión global presentada se pueden estudiar más en detalle las
características de un sistema ERP [O´Leary, 2000]. Podemos destacar las siguientes
características de este tipo de sistemas desde un punto de vista técnico:
- 46 -
2. Situación actual y planteamiento del problema
?
Modularidad. El sistema se divide jerárquicamente en módulos y submódulos
que pueden instalarse de forma independiente, pero que trabajan siempre
integrados. Esto permite cambios demasiado radicales en una organización,
instalando primero un núcleo de módulos esenciales y añadiendo otros módulos
cuando se necesiten.
?
Integración. Tanto interna, entre los módulos, como externa, ya que contiene
soluciones técnicas de comunicación con otras arquitecturas informáticas y
bases de datos.
?
Parametrización. Proporciona un conjunto bastante amplio de variables que
activan o desactivan funciones o procedimientos generales o personalizan la
forma de realización de estas funciones o procedimientos, de manera que
permiten adaptar el funcionamiento del sistema a las distintas estrategias
empresariales y procesos de negocio.
?
Flexibilidad estratégica. Permite medir el alcance de objetivos estratégicos bien
definidos y adaptarse a eventuales cambios en estos objetivos, todo ello en
tiempo real.
?
Flexibilidad de arquitectura. Permite la elección de la plataforma de soporte
hardward y software.
?
Accesibilidad. Proporciona interfaces fáciles de entender y personalizar. Los
datos se expresan en la forma más sencilla y útil a diferentes exigencias.
?
Reporting o generación de informes. Garantiza la flexibilidad en la forma de
obtener información y en la forma de interrogar al sistema. Es posible crear
consultas personalizadas de forma fácil y rápida, sin necesidad de conocimientos
informáticos.
?
Workflow o flujos de trabajo. Permite definir y utilizar de forma coherente con
el sistema instrumentos de modelización de procesos. Gestiona el uso de la
información según las reglas de trabajo establecidas en los procesos de negocio,
aunque es posible definir y tratar excepciones.
?
Seguridad. Utiliza sistemas técnicos de seguridad que permiten las conexiones a
través de redes interna y externas sin peligro de la integridad y la
confidencialidad de los datos. Gestiona distintos niveles de usuarios y claves
personales asociadas a procesos y datos.
- 47 -
2. Situación actual y planteamiento del problema
?
Referencias. Al ser un sistema estándar normalmente está ya instalados en otras
empresas, lo cual implica que ha sido ya probados y corregido.
?
Universalidad. Disponibilidad en lenguas distintas y soporte a distintas
legislaciones, monedas o culturas.
?
Transparencia. Si el sistema es transparente las decisiones que toma o las
recomendaciones que da son fácilmente entendidas por el usuario. Las personas
que utilizan el sistema deben ser capaces de entender claramente lo que este
hace y decidir si seguir adelante con los planes obtenidos o modificarlos. Este
sistema debe ser totalmente contrario al concepto de caja negra.
?
Usabilidad. El sistema proporciona una interfaz de usuario única, con el mismo
diseño gráfico, iconos y menú en todos los módulos.
La determinación de adquirir un sistema ERP debe ser sumamente estudiada, ya que
no solo implica el hecho de adquirir el software, implica mas que nada un cambio en la
cultura, en la forma de realizar las operaciones, implica la trasformación de los
procesos, todo con el fin de lograr el avance y liderazgo de la compañía. Se pueden
detallar alguno de los beneficios que proporciona la implantación de un sistema ERP.
Entre los beneficios intangibles se pueden destacar:
?
?
?
?
?
?
?
?
?
?
?
?
?
Mejora de la calidad y visibilidad de la información.
Mejora del proceso de negocio.
Integración.
Mejora de la respuesta a los clientes.
Estandarización.
Reducción de costes o mejora de la productividad.
Mejora en la cadena de procesos.
Estandarización de los procesos de negocio.
Mejora de la flexibilidad.
Mejora del coste de la estructura.
Globalización.
Funcionamiento del negocio.
Nuevo modelo de negocio.
Entre los beneficios tangibles se pueden destacar:
?
?
Reducción de personal.
Reducción de inventario.
- 48 -
2. Situación actual y planteamiento del problema
?
?
?
?
?
?
?
?
Reducción de los costes de Sistemas de Información.
Mejora de la productividad.
Mejora de los beneficios.
Mejora del control de pedidos y de la duración del ciclo del pedido.
Control eficaz de la tesorería.
Reducción de los costes de adquisición.
Rebaja de los ciclos financieros.
Reducción de los costes de mantenimiento.
[Ross y Vitale, 2000] resumen en la figura 2.17 los beneficios que se deben obtener
con la implantación de un sistema ERP y sus conexiones:
Mejora de
los procesos
Mejora del
proceso de toma
de decisiones
Plataforma
común
Visibilidad de
los datos
INFRAESTRUCTURA
Reducción
de costes
CAPACIDAD
Satisfacción
del cliente
EJECUCION
Figura 2.17 Beneficios interrelacionados de un sistema ERP
El número de compañías que decide implementar un ERP se está incrementando
rápidamente [Granlund y Malmi, 2002]. Las ventas del suministrador más importante de
sistemas ERP, el alemán SAP, han pasado de algo menos de 500 millones de dólares de
1992 a, aproximadamente, 7,5 billones de dólares en 2002 [SAP, 2002]. El resto de
suministradores del sector han tenido también un importante crecimiento. En estos
últimos años el beneficio no ha crecido de forma exponencial, aunque la tendencia sigue
al alza. Según el Gartner Group en el año 2004 los beneficios de ventas de licencias
ERP se han incrementado un 9,4%. A nivel mundial existen seis fabricantes principales
de ERP, que se reparten el 64% del total de este mercado: SAP, Oracle, PeopleSoft, JD
Edwards, Baan y Siebel. Estos fabricantes marcan la pauta del mercado ERP. Todos
ofrecen soluciones en las principales funciones del producto y cada uno aporta algo
distinto. Todos tiene integradas sus soluciones en el concepto e-business, con soporte
total del uso de sus aplicaciones con Internet.
- 49 -
2. Situación actual y planteamiento del problema
En España, según un estudio elaborado por el grupo Penteo a finales del 2003, entre
más de 300 empresas españolas con una facturación superior a 20 millones de euros, el
70% de ellas cuenta con algún sistema de ERP, y un 8% espera hacerlo en breve. Las
áreas en las que se encuentran más implantados estos sistemas son las de finanzas
(68%), compras (64%), logística (61%) y producción (51%), mientras que donde menos
se utilizan son en los departamentos de Comercial y Recursos Humanos. La figura 2.18
muestra el mercado español de los ERP en los últimos años, según un estudio realizado
por IDC España.
400
300
200
100
0
2001
2002
2003
2004
Figura 2.18 Ventas de sistemas ERP en España (millones de dólares)
La investigación del grupo Penteo señala, como muestra la figura 2.19 que SAP es el
proveedor de ERP con mayor penetración entre las grandes empresas españolas, con
una cuota de casi dos tercios del mercado, muy por delante de sus otros competidores.
Movex
7%
Baan
5%
Ross Oracle
3%
4%
JD Edwars
8%
SAP
62%
Otros
11%
Figura 2.19 Proveedores ERP en el mercado español
A continuación se describe brevemente cada uno de ellos.
- 50 -
2. Situación actual y planteamiento del problema
SAP (www.sap.com)
SAP es el líder mundial en el suministro de soluciones e-business colaborativas. Con
36.000 instalaciones que prestan servicio a 10 millones de usuarios de 13.500 empresas
en 120 países de todo el mundo, SAP se ha convertido en el tercer proveedor
independiente de software más importante del mundo. Lleva 33 años en el negocio del
e-business y fue fundada en 1972 por cinco antiguos ingenieros de sistemas de IBM. La
sede de la empresa está en Walldorf, Alemania.
SAP fue fundada el 1 de Abril 1972 por cinco personas: Wellenreuther, Hopp,
Hector, Plattner y Tschira. Mientras que estaban empleados en la IBM, habían
desarrollado un paquete de contabilidad financiera que funcionaba en bloques para un
cliente de IBM (Naturin). SAP compró los derechos a Naturin y empezó con el diseño y
aplicación de un sistema financiero a tiempo real como un paquete básico sobre las
experiencias que se tenía en el programa. Vendieron la primera copia del sistema básico
a ICI por el mismo precio que a los últimos clientes. Simultáneamente, desarrollaron un
sistema de administración de materiales, como software a medida para ICI, pero se
reservaron los derechos de propiedad para SAP. Con el dinero obtenido financiaron el
desarrollo del sistema financiero contable. Posteriormente el sistema de administración
de materiales se convirtió en un paquete estándar, que se financió con los beneficios del
sistema financiero contable. Los dos sistemas desarrollados fueron los primeros
módulos de los que se llamo el sistema R, que solo más tarde, póstumamente se
renombró R/1 para distinguirlo mejor de sus sucesores R/2 y R/3. SAP R/3, es el actual
ERP de SAP, ofrece soluciones estándares para las necesidades completas de
información de una compañía en el área del software de negocios.
mySAP Business Suite es una familia de soluciones que ofrece aplicaciones de
negocio abiertas (a través de internet) que maximizan la rentabilidad de las relaciones
integrando personas, información y procesos. Está compuesto de las siguientes
soluciones:
?
mySAP ERP, proporciona funcionalidades completas para el análisis de negocio,
las finanzas, la gestión del capital humano, las operaciones y los servicios
corporativos. Además, proporciona también soporte para cuestiones referentes a
la gestión de sistemas como, por ejemplo, la administración de usuarios, la
gestión de configuración, la gestión de datos centralizada y la gestión de
servicios web.
?
mySAP CRM, esta solución ofrece funcionalidad a través de todo el ciclo de
compromiso con los clientes, proporcionando todas las características y
funciones necesarias para la planificación de marketing, gestión de campañas,
telemarketing y segmentación de clientes.
- 51 -
2. Situación actual y planteamiento del problema
?
mySAP SCM, ofrece potentes funcionalidades de coordinación que realizan un
seguimiento de los procesos financieros, de información y de materiales e
identifican las excepciones de procesamiento. Además de la coordinación,
nySAP SCM cubre la planificación, ejecución y colaboración en la cadena de
suministro.
?
Soluciones para la PYME, soluciones diseñadas especialmente para la pequeña y
mediana empresa. En la actualidad, SAP ha lanzado dos nuevas iniciativas para
la PYME:
o mySAP All-in-One, son soluciones preconfiguradas para satisfacer las
necesidades de una Pyme y pueden ajustarse para que funcionen en un
sector determinado. Están diseñadas para empresas que requieren un alto
grado de funcionalidad específica para su sector.
o SAP Business One, solución más sencilla que permite satisfacer las
necesidades de negocio más comunes, como contabilidad, elaboración de
informes, logística, automatización de la fuerza de ventas, etc. Está
diseñado para pequeñas empresas que requieren soluciones de TI con una
funcionalidad específica para su sector menos compleja.
?
Soluciones industriales, soluciones adaptadas y diseñadas para sectores
concretos, reflejando los procesos de negocio y las características propias de
cada sector. SAP dispone de 23 soluciones industriales o también denominadas
soluciones verticales. Por ejemplo, la solución industrial SAP for Automotive
está diseñada para satisfacer las necesidades específicas del sector
automovilístico vinculando procesos de negocio complejos dentro de un flujo
lógico. SAP Soluciones Industriales permite una integración y una colaboración
homogéneas de las distintas organizaciones internas, además de ofrecer soporte
para los procesos de negocio que abarcan a múltiples empresas. Además, ofrece
un único punto de acceso fácil de utilizar tanto a la información como a las
aplicaciones, todo ello basado en una tecnología web avanzada.
Las principales características de SAP R/3 son:
?
?
?
Información on-line. Esta característica significa que la información se
encuentra disponible al momento, sin necesidad de esperar largos procesos de
actualización y procesamiento habituales en otros sistemas.
Jerarquía de la información. Esta forma de organizar la información permite
obtener informes desde diferentes vistas.
Integración. Esta es la característica más destacable de SAP R/3 y significa que
la información se comparte entre todos los módulos de SAP R/3 que la
- 52 -
2. Situación actual y planteamiento del problema
necesiten, así como entre todas las áreas. La integración en SAP R/3 se logra a
través de la puesta en común de la información de cada uno de los módulos y
por la alimentación de una base de datos común. Por lo tanto, hay tener en
cuenta que toda la información que se introduce en SAP R/3 repercutirá, en
tiempo real, a todos los demás usuarios con acceso a la misma. Este hecho
implica que la información siempre debe estar actualizada, debe ser completa y
debe ser correcta.
El sistema SAP R/3 está formado por distintas funciones que trabajan de forma
integrada. Además SAP R/3 dispone de su propio lenguaje de programación de cuarta
generación, denominado ABAP/4. A continuación se muestra una breve descripción
cada uno de estas funciones:
1. Herramientas de análisis.
? Proporcionan análisis y evaluaciones para planificar y controlar
actividades de la empresa para mejorar el rendimiento.
? Soporta la toma de decisiones con simulaciones para mejorar la respuesta
ante los cambios.
? Ayuda a la dirección a reconocer y capitalizar las oportunidades para
crear valor en las operaciones diarias y aumentar de este modo el valor
de una organización.
2. Finanzas.
? Le ayuda a monitorizar todas las transacciones financieras en tiempo real
para obtener una información más precisa y oportuna.
? Ofrece un amplio soporte a las obligaciones de dirección de las
corporaciones, incluyendo el cumplimiento de normas internacionales y
también la gestión de informes financieros transparente, reduciendo el
riesgo de incumplimiento.
? Simplifica el procesamiento de los pagos entrantes y salientes,
garantizado la mejora del flujo de caja.
? Combina la planificación, la gestión de informes y el análisis de medidas
competitivas en un proceso para proporcionar un análisis más
fundamentado del negocio.
? Proporciona herramientas para medir y optimizar el rendimiento de tareas
importantes para aumentar la productividad.
3. Gestión del capital humano.
? Proporciona una amplia variedad de servicios y procesos para la gestión
efectiva de recursos humanos, incluyendo la gestión de transacciones con
los empleados, gestión del ciclo de vida de los empleados, contratación,
- 53 -
2. Situación actual y planteamiento del problema
formación y gestión de las relaciones con los empleados, lo cual tiene
como resultado una mejor productividad y retención del personal.
4. Operaciones.
? Refuerza la capacidad logística en aprovisionamiento, producción,
almacenamiento, transporte, ventas y distribución, y mantenimiento para
crear una empresa más eficiente y optimizada.
? Sienta la base para la mejora en toda la organización de los procesos de
negocio y de la colaboración con proveedores, clientes y otros partners,
mejorando la utilización de los activos.
5. Servicios corporativos.
? Soporta los servicios organizativos centralizados y descentralizados en
áreas tales como la gestión de bienes inmuebles, gestión de viajes,
tesorería, gestión de incentivos y comisiones, medio ambiente, salud y
seguridad, minimizando los costes y optimizando el rendimiento de las
ventas.
6. Self-services.
? Ofrece a los directores y empleados un acceso inmediato y personalizado
a los servicios corporativos, ahorrando tiempo y esfuerzo.
7. SAP NetWeaver.
? Consigue una arquitectura técnica uniforme y una plataforma de solución
con una flexibilidad mejorada para satisfacer necesidades futuras.
? Integra a usuarios, información, procesos y aplicaciones, lo cual da como
resultado una mayor productividad.
? Soporta la tecnología de portal, business intelligence y tecnologías
portátiles que ahorran tiempo y reducen costes.
? Permite el mejor uso posible de las inversiones de IT existentes para
minimizar el coste total de propiedad.
JD Edwards (www.jdedwards.com)
J.D. Edwards, que lleva en el mercado desde los años 70, empezó en Denver,
Colorado, y hoy en día está implantado en todo el mundo. Recientemente ha sido
absorbida por la empresa PeopleSoft, a la cual nos referiremos a partir de ahora.
Peoplesoft por su parte empezó su andadura en el año 1987, diseñando aplicaciones de
gestión empresarial basándose siempre en la tecnología más innovadora. PeopleSoft es
la segunda empresa de software de gestión empresarial más grande del mundo, con
- 54 -
2. Situación actual y planteamiento del problema
12.200 clientes en más de 25 sectores y 150 países. Tanto PeopleSoft como J.D.
Edwards aportan a la empresa características exclusivas y complementarias en las áreas
respectivas de productos, mercados y sectores.
El conjunto de productos empresariales de PeopleSoft (que incluyen Gestión del
Capital Humano, Finanzas, Gestión de Relaciones con el Cliente (CRM), Gestión de
Relaciones con Proveedores y Gestión de Producción) está considerado como uno de
los mejores del mercado, mientras que las aplicaciones de J.D. Edwards de Fabricación
y Distribución, Gestión de Activos y Gestión de Bienes Inmuebles se encuentran entre
las más avanzadas del sector.
Históricamente, las dos empresas se han concentrado en mercados diferentes.
PeopleSoft es un líder reconocido en sectores de Servicios: Finanzas,
Telecomunicaciones, Asistencia Sanitaria, Selección de Personal, Enseñanza Superior y
Administración Pública. Por su parte, J.D. Edwards figuraba como líder reputado en los
sectores de Fabricación y Distribución, así como en organizaciones con gran número de
activos, incluidas empresas constructoras, papeleras, inmobiliarias, así como compañías
de explotación minera, biomedicina y productos de consumo. La presencia conjunta de
la nueva PeopleSoft se traduce en una posición de liderazgo y en grandes oportunidades
de mercado en más de 25 sectores.
Tienen una filial para España, llamada PeopleSoft Iberica, la cual se constituyó en
1996 para comercializar los productos PeopleSoft en España y Portugal. Hoy en día ha
sufrido un crecimiento notable con más de 380 clientes de diferentes ámbitos
comerciales. Su objetivo principal es poner al alcance de sus usuarios las mejores
herramientas y soluciones de gestión empresarial con un meticuloso servicio de
atención al cliente y soporte, colaborando para ello con las principales empresas de
servicios y tecnología. En concreto, en el mercado español PeopleSoft se ha ubicado,
por una parte dentro del mundo de las grandes empresas en los sectores de banca,
servicios y telecomunicaciones, y por otra en el de la mediana empresa, en los sectores
de productos de consumo, fabricación y distribución.
Existen tres grandes soluciones las que presenta PeopleSoft juntamente con JD
Edwards. Con estos tres productos se brinda a cada sector empresarial una solución
específica a sus necesidades, ya sea productos generales, productos específicos de la
industria o soluciones completas:
1. PeopleSoft Enterprise. Son un conjunto de aplicaciones basadas en el
concepto de Internet, con una configuración flexible y una integración abierta
con los diversos proveedores. Es la opción ideal para las áreas de Finanzas,
Gobierno, Educación, Salud y demás segmentos de Servicios. Por otra parte
también es una excelente opción para funciones principales de las Empresas,
- 55 -
2. Situación actual y planteamiento del problema
tales como Recursos Humanos, Finanzas, Tecnología de la Información,
Compras, Marketing, Servicios y Ventas.
2. PeopleSoft EnterpriseOne. Es la opción adecuada para organizaciones que
fabrican, construyen, distribuyen, brindan servicios o administran productos o
activos físicos. Es decir una serie de aplicaciones diseñadas para una
instalación rápida y una administración simple en una arquitectura totalmente
basada en Internet.
3. PeopleSoft World. Son un conjunto de aplicaciones para la plataforma IBM
iSeries. Las aplicaciones están estrechamente integradas y predefinidas en
una única base de datos y cuentan con una arquitectura basada en Internet.
Movex (www.movex.net)
Intentia Consulting S.A. es la empresa subsidiaria de Intentia en España responsable
de la comercialización e implantación de Movex en el mercado español. Fundada en
Suecia en 1984, Intentia es uno de los principales proveedores mundiales de
aplicaciones e-business y de soluciones integradas de gestión. La compañía desarrolla,
distribuye e implanta Movex, única solución del mercado multiplataforma y
enteramente programada en Java. Movex gestiona simultáneamente los procesos
internos de cualquier empresa y las relaciones con sus clientes, proveedores y partners.
Intentia ofrece, además, productos y servicios especialmente diseñados para los sectores
de la distribución, alimentación y bebidas, moda y textil o mantenimiento, entre otros.
El grupo, que cotiza en la Bolsa de Estocolmo, emplea a más de 3.500 personas en 40
países y cuenta con más de 3.500 clientes en todo el mundo.
La tecnología de Intentia basada en Java, proporciona a los usuarios bajo coste de la
propiedad, alta escalabilidad e independencia de plataforma. Movex Java está creado
para el cambio y proporciona escalabilidad prácticamente ilimitada haciendo que se
pueda gestionar la expansión sin problemas.
Intentia cubre prioritariamente las necesidades del sector de la distribución y para
ello ofrece el producto, la tecnología y la organización del proyecto, para asegurar que
su solución sea:
?
?
?
La aplicación de distribución funcionalmente más completa.
Creada a partir de la tecnología más avanzada.
Capaz de proporcionar el menor tiempo de implantación.
- 56 -
2. Situación actual y planteamiento del problema
Esta solución se llama Movex Distribución. Es un software abierto, que puede
comunicarse con Oracle, SQL Server y Centura SQLBase y bajo ambientes Win NT.
Orientado hacia el usuario final, con una ayuda especial que permite al usuario crear
consultas no previstas de toda la información del sistema. Se pueden almacenar esas
consultas especiales y quedarse como consultas estándar. También permite diseñar y
obtener informes según las necesidades de análisis de cada momento, y da facilidades
de correo, etiquetas o exportación a herramientas de escritorio. Así mismo permite
exportar e importar cuentas y contactos de la empresa mediante un lenguaje descriptivo
que también permite importar y exportar plantillas para una importación/exportación
más avanzada.
En lo que respecta a la seguridad da la facilidad de habilitar/deshabilitar las
funciones por usuario y los niveles de acceso restringido para grupos de usuario:
lectura, cambios, agregar o borrar. Está integrado con otros programas de ofimática
como Word, Excel, Project y SQL Server. Los principales movimientos del sistema
quedan históricamente registrados, lo cual es una gran herramienta de auditorias.
Las ventajas especificas de este ERP es que trabaja en ambiente Windows, la
generación de listados e informes según necesidades y conversión de listados a formato
Excel, el acceso fácil y flexible a toda la información, el hecho de que todos los usuarios
pueden tener acceso a los datos de manera simultánea, los avisos claros de error en
introducción de datos, y la facilidades para añadir nuevas funciones.
Es un ERP sólido, del cual los implantadores dicen que se puede comparar con los
ERP más grandes del mercado, aunque tiene una muy fuerte orientación hacia la
producción, por lo que si una empresa se dedica principalmente a la fabricación, puede
ser un candidato muy interesante. El único defecto, si es que se puede juzgar de esa
manera, es que sólo trabaja, hasta ahora, en equipos AS/400, lo que puede reducir su
mercado.
Baan (www.baan.com)
Baan se convierte en una compañía subsidiaria de SSA Global Technologies, Inc.TM
en el año 2003, por ello haremos referencia a SSA Global. SSA Global es uno de los
mayores proveedores mundiales de soluciones ERP y sus extensiones. Proporciona tres
soluciones diferentes:
1. SSA ERP. Es una solución modular construida para la empresa industrial.
Dispone de las funciones de finanzas, ventas, compras, logística y servicio
entre otras, siendo su fortaleza principal los módulos de producción que
- 57 -
2. Situación actual y planteamiento del problema
ofrecen importantes beneficios. Está especialmente enfocado para empresas
de fabricación.
2. Soluciones industriales. SSA dispone de una solución especifica para la
industria de la Automoción, que permite controlar las siguientes facetas:
? La cadena de suministros y las operaciones de facturación.
? Implantación de procesos de entrega JIT, rastreando materiales desde la
recepción de su ingreso y su manufactura, hasta el momento de la
entrega a los clientes.
? Gestionar el inventario y costes, incluso hasta el nivel de materiales
reutilizables de empaquetado.
? Coordinar su programación de producción a nivel de celdas con los
requerimientos de los clientes.
? Por último, brindar una mejora en el flujo y gestión de la documentación
EDI.
3. SSA Extensiones de soluciones. Ayudan a aumentar la productividad,
logrando un trabajo más eficiente con los elementos constituyentes clave,
como vendedores, proveedores, partners y clientes. Las extensiones ofrecidas
son:
?
?
?
?
?
La cadena de suministros (SCM)
La gestión de la función corporativa (CPM)
La gestión de relaciones con los clientes (CRM)
La gestión de la relación con proveedores (SRM)
La gestión de los ciclos de vida de los productos (PLM).
Ross (www.rossinc.com)
Ross System es una empresa líder en la distribución de sistemas empresariales de
gestión y soluciones eBusiness especializada en los sectores de industria de proceso,
alimentación y bebidas, servicios y sector sanitario. Dispone de una familia completa de
soluciones integradas de gestión empresarial. La compañía está presente en España
desde 1988 y tiene su sede central en Barcelona. Más de 150 empresas españolas han
implantado soluciones de Ross Systems.
El actual producto comercial se denomina iRenaissance. Es una gama de soluciones
que proporciona un entorno totalmente Web en todas y cada una de sus áreas de gestión:
- 58 -
2. Situación actual y planteamiento del problema
?
iRenaissance ERP es una solución global de gestión empresarial que integra las
siguientes áreas: Gestión Financiera, Logística y Producción/Planificación.
?
iRenaissance Reporting engloba un conjunto de soluciones integradas con
iRenaissance ERP que abarca cualquier tipo de informe de gestión, así como
formatos de impresión de salida, con el objetivo de minimizar el tiempo de los
profesionales en la obtención y captura de datos y ponerlos a disposición de
todos los demás usuarios de la compañía.
?
Soluciones verticales. Ofrecen funcionalidades diseñadas especificamente para
los siguientes sectores: Alimentación y bebidas, Químico farmacéutico,
Cerámicas, Cárnicas, Sanidad, Puertos, Productos naturales y Metales.
?
Soluciones eBusiness: integración con sistemas que permiten la circulación de
información en los dos sentidos, desde el servidor central a la web y desde la
web al servidor central.
Oracle (www.oracle.com)
La empresa Oracle es la principal suministradora de Bases de Datos, herramientas
informáticas y soluciones globales de gestión empresarial (ERP) para las grandes y
medianas compañías a nivel mundial. La empresa ofrece su base de datos, herramientas
y productos de aplicación, junto con servicios relacionados de consultoría, educación y
soporte. Con sede en Redwood Shores, California, Oracle es la primera compañía de
software que desarrolla e implementa software para empresas completamente activado
por Internet a través de toda su línea de productos: base de datos, servidor, aplicaciones
comerciales para empresas y herramientas de desarrollo de aplicaciones y soporte de
decisiones. Presenta tres tipos de soluciones:
1. Soluciones basadas en el Sector (ingeniería y construcción, viajes y
transporte, sector químico, comunicaciones, etc.).
2. Soluciones basadas en los Negocios (medianas empresas, gobierno,
administración de la cadena de abastecimiento, etc.).
3. Oracle e-Business Suite Special Edition, conjunto completo de aplicaciones
comerciales para la administración y automatización de procesos de una
organización. Es una solución completa e integrada que incluye aplicaciones
de finanzas, marketing, ventas, servicios, contratos, cadena de
abastecimiento, logística (compras, pedidos, inventario), I+D, planificación,
- 59 -
2. Situación actual y planteamiento del problema
producción (discreta, por proceso, por proyectos), mantenimiento de planta y
recursos humanos.
2.1.4. El problema de la parametrización en implantaciones ERP
Los sistemas ERP son caros, complejos y notoriamente difíciles de implantar. Para
instalar y parametrizar correctamente el sistema, se suele requerir de la ayuda de
integradores expertos. Según un estudio del grupo Penteo elaborado a finales de 2003,
el coste total de implantación, que incluye software, hardware, consultoría y personal
interno, puede llegar a representar el 2% o el 3% de la facturación anual de una gran
empresa. Sin embargo, más de la mitad de las empresas españolas que cuentan con un
sistema ERP considera que está insuficientemente explotado. El gráfico que muestra la
figura 2.20 detalla el estudio realizado por este grupo en empresas españolas que
utilizan sistemas ERP.
Totalmente
explotado
13%
Nada
explotado
17%
Poco
explotado
37%
Bastante
explotado
33%
Figura 2.20 Grado de explotación del potencial de un sistema ERP
Una vez que se ha decidido implementar un ERP, es importante saber cuáles son los
parámetros necesarios para escoger el correcto, por lo que a continuación se presenta
una lista de característica que según [Sprott, 2000] deben verificarse:
?
?
?
?
Aplicabilidad. Debe de encajar con las necesidades del negocio.
Integración. Debe integrarse con otros componentes y paquetes.
Adaptabilidad. Ya que es muy difícil que las empresas sean estáticas.
Escalabilidad. Debe de poder cambiarse por nuevas versiones.
Como se desprende de la lista de parámetros anteriores la flexibilidad a las
necesidades del negocio, a los cambios del entorno y al escenario empresarial son la
base fundamental para una buena elección. En los sistemas ERP está flexibilidad se
consigue gracias a la capacidad de parametrización que el sistema posea.
- 60 -
2. Situación actual y planteamiento del problema
Tradicionalmente cuando se pretendía implantar un sistema ERP nos enfrentábamos
a tres posibilidades: comprar un paquete software, desarrollar los programas que
implementen el sistema o comprar un paquete estándar y modificarlo según las
necesidades de la organización. Las empresas pequeñas no tenían mucha elección ya
que no cuentan con los medios para desarrollar o modificar un sistema tan complejo.
Las empresas más grandes debían decidir entre las ventajas que tienen las tres
posibilidades.
Las principales ventajas de comprar un paquete software son las siguientes:
1. Un sistema ERP es muy complejo y vasto por lo que el coste de desarrollarlo
internamente excede al de la compra
2. Desarrollar el software internamente probablemente llevará años de trabajo,
mientras instalar un paquete ya comprado puede hacerse en,
aproximadamente, un año, dependiendo del entorno.
3. Los analistas y programadores que trabajan en las empresas que
comercializan estos paquetes poseen una experiencia probada en los temas
específicos a implementar.
4. Los paquetes a la venta normalmente están ya instalados en otras empresas, lo
cual implica que han sido ya probados y corregidos.
Una vez decidida la compra de un producto ya desarrollado es muy importante elegir
cual, para ello es aconsejable seguir los siguientes pasos:
1. Determinar que funcionalidad se quiere que cubra el paquete. Es conveniente
establecer dos listas: funciones fundamentales y deseables.
2. Estudiar los paquetes existentes en el mercado. Es conveniente acudir a
consultores especialistas. Es importante tener en cuenta estos puntos:
? La empresa que distribuye el paquete tenga solvencia, esté establecida en
la zona donde se quiere implementar y tenga los recursos necesarios para
dar soporte.
? El paquete sea compatible con el hardware existente en la empresa.
? Esté ya instalado en otras empresas. En este caso sería conveniente entrar
en contacto con los responsables del paquete en alguna de estas
empresas.
- 61 -
2. Situación actual y planteamiento del problema
3. Ponerse en contacto con los representantes de los paquetes seleccionados
dándoles información sobre el entorno donde se quiere implementar. Será
necesario incluir lo siguiente:
? Lista de la funcionalidad deseada.
? Información sobre la cantidad y tipo de datos a tratar
? Información sobre la estructura del hardware existente y la posibilidad de
ampliarlo con vistas a la nueva instalación.
? Información sobre los sistemas de información y comunicaciones
existentes con los que el paquete tendrá que convivir y relacionarse.
4. Estudiar las propuestas recibidas. Aquellas que no puedan satisfacer las
funciones fundamentales deberán ser descartadas inmediatamente. Se
estudiarán los restantes teniendo en cuenta los siguientes factores de decisión:
? Presencia de funciones deseadas
? La calidad del soporte a la instalación: cursos, manuales, disponibilidad
de personal experto, etc.
? Características del paquete frente al usuario.
? Facilidad de modificación y mantenimiento de los programas.
? Coste.
5. Basándose en estos puntos el grupo de paquetes seleccionado debe quedar
reducido a un número entre dos y cuatro. Se hará un estudio más profundo de
estos, con contacto directo con los vendedores del paquete que incluirá
presentaciones y demostraciones de funcionamiento. Al final se hará un
informe detallado de cada uno de ellos.
6. La alta dirección decidirá el paquete a instalar con los datos aportados en el
punto precedente.
En cambio, el principal argumento para desarrollar un paquete en casa es que la
organización no encuentre ninguno entre los existentes que cubra mínimamente sus
necesidades. A veces es factible una solución intermedia que incluye ventajas de las dos
anteriores. Esta solución consiste en comprar un paquete y personalizarlo adaptándolo
de forma más precisa a nuestras necesidades. Al adoptar esta solución hay que elegir
cuidadosamente el paquete a comprar ya hemos visto, debiendo el paquete elegido
realizar todas las funciones fundamentales. Además es conveniente tener en cuenta lo
siguiente:
- 62 -
2. Situación actual y planteamiento del problema
?
Establecer claramente antes de empezar las modificaciones el límite donde se
quiere llegar. Es fácil caer en la tentación de aumentar sin medida las funciones
que se quiere que realice el paquete hasta llegar a desarrollar prácticamente un
software a medida. Esto supone no obtener ninguna de las ventajas de las dos
soluciones anteriores.
?
Crear un grupo de trabajo utilizando personal interno y de la sociedad vendedora
o distribuidora del paquete para realizar las modificaciones a los programas. De
esta forma el personal interno responsable en un futuro del software del paquete
adquiere conocimientos fundamentales sobre la estructura de este que le serán
necesarios cuando se quiera prescindir de los consultores externos.
Esta última solución planteaba muchos problemas reales y consumía muchos
recursos por lo que su coste resultaba excesivo. Actualmente, esta última solución ha
desaparecido ya que los sistemas ERP intentan desarrollar su software de manera
flexible incluyendo funciones opcionales particulares para adaptarse a todo tipo de
exigencias sin necesidad de modificar el software. Esta funcionalidad la conocemos
como capacidad de parametrización y ayuda a encontrar el equilibrio entre la compra
sin adaptación y la construcción personalizada como muestra la figura 2.21.
Flexibilidad
Coste
% Compra sin adaptación
Figura 2.21 Espectro entre ‘make-all’ y ‘buy-all’
Todas las actividades relacionadas con la parametrización constituyen el núcleo
central de la implantación de un sistema ERP. Si agrupamos los pasos normales para
implementar un EPR en fases podríamos dividirlo así: Diseño y parametrización,
Implementación y Producción. Esto engloba la planificación del proyecto, el análisis del
negocio y de las operaciones; la reingeniería de los procesos del negocio; instalación y
configuración; entrenamiento del equipo del proyecto; definición de parámetros;
conversión de los datos; la documentación; el entrenamiento del usuario final, la
aceptación de las pruebas y la auditoria. La primera fase Diseño y parametrización
- 63 -
2. Situación actual y planteamiento del problema
incluye las actividades relativas a la definición de procesos de negocio y la adaptación
de las funciones del sistema a esos procesos. En este contexto la parametrización
incluye la elección de los módulos del sistema que van a ser implantados y utilizados y
la definición de los valores que van a tomar los parámetros de esos módulos, tales como
productos, tiempo de respuesta al cliente, política de inventario, etc. Los resultados de la
parametrización van a comprometer los resultados del sistema, es más [Markus y Tanis,
2000] apuntan que las propia integración del sistema y sus beneficios pueden perderse
según como se realice la parametrización. Este proceso es mucho más difícil y delicado
en organizaciones grandes y complejas. De hecho, errores en la parametrización son la
causa de incrementos en los costes de implantación y uso del sistema, incrementos en la
cantidad de tiempo necesaria para la implementación y en la cantidad de cambios en los
requisitos durante la implantación y mantenimientos y actualizaciones más caras y
difíciles. Según un estudio realizado por [Al-Mashari, 2001] los sistemas ERP
comerciales cubren alrededor de un 70% de las necesidades de las organizaciones que
los implantan. En este caso las organizaciones pueden adaptar el paquete a su
organización (parametrizar) o adaptarse ellas mismas al funcionamiento del sistema
perdiendo ese 30% de funcionalidades que no les proporciona el paquete estándar. La
dificultad de la parametrización lleva a muchas empresas a adoptar esta última solución
asumiendo una perdida de funcionalidad del 30%.
El problema es más crítico, pues la parametrización de un ERP incluye la integración
de los diferentes módulos, definición de los datos, adoptar el modelo de negocios que
responda al plan estratégico, agenda de implementación limitada, y la participación de
un gran número de personas. La causa fundamental de este problema la plantean [Soh et
alt., 2000] ya que, a todo esto se añade que el pobre conocimiento que posee el personal
de la organización sobre la funcionalidad del sistema ERP no les permite apreciar las
implicaciones de adopción de decisiones durante la parametrización. Similarmente,
pocos consultores de ERP entienden los procesos de negocio de sus clientes lo
suficiente para detectar las áreas críticas que no cuadran con el paquete. En referencia a
[Scheer y Habermann, 2000], los sistemas ERP estandarizados tienen ciertas
desventajas.
Para poder configurar y parametrizar el sistema según el plan estratégico de la
organización es necesario que el personal del proyecto cuente con la capacitación
debida en el manejo y administración del mismo, para lo cual debe existir un plan de
capacitación constante del personal involucrando ayudado por los expertos del sistema
ERP elegido. Debe además existir una comunicación entre la parte financiera,
administrativa, operativa e informática para hablar el mismo idioma a la hora de
parametrizar y establecer las reglas de negocio que regirán el flujo de procesos y
operaciones de la empresa. El proceso de parametrización de un ERP requiere
dedicación total por parte de un equipo de trabajo que deberá estar integrado por los
líderes empresariales y por expertos consultores ERP. En la práctica está tarea resulta
- 64 -
2. Situación actual y planteamiento del problema
lenta y con alta probabilidad de error , ya que en grandes sistemas los parámetros a
considerar pueden ser muchos, en algunos casos repetitivos y dependientes de
parámetros anteriores y en otros resultado de un extenso conocimiento tanto de la
realidad particular de cada empresa, como del funcionamiento procedural del ERP
elegido. Dicho conocimiento es difícil de conjugar en el mismo equipo, por la existencia
de cientos de tablas con sus correspondientes parámetros de los que hay que conocer su
utilidad y significado, conocimiento típico de los consultores ERP. A la vez, las
características particulares de cada organización, su forma de trabajo y sus procesos
particulares no son conocidos por estos consultores, sino por los miembros de la
organización. Toda esta información, sobre el sistema ERP y sobre la organización, está
fragmentada, dado su extensión, entre distintas personas, ya que hay consultores
expertos por módulos y personal experto en distintas áreas de negocio. Por lo tanto, se
hacen necesarios métodos, modelos, arquitecturas y herramientas que ayuden en esta
tarea ya que ellas pueden ayudar a reducir los costes y a la vez incrementar la
aceptación del ERP por parte de los usuarios y el éxito de su implantación. Una óptima
solución a este problema pasaría por encontrar un sistema que guíe la realización de esta
tarea de forma inteligente, evitando la probabilidad de errores y diminuyendo el tiempo
de implantación.
- 65 -
2. Situación actual y planteamiento del problema
2.2. SISTEMAS INTELIGENTES
2.2.1 INTELIGENCIA
CONOCIMIENTO
ARTIFICIAL
Y
SISTEMAS
BASADOS
EN
EL
La definición de Inteligencia Artificial es considerada labor compleja, partiendo de
que la propia definición de inteligencia es difícil. La Enciclopedia Británica define
inteligencia como:
“Habilidad para adaptarse de forma efectiva al ambiente, tanto realizando cambios
en uno mismo como cambiando el entorno o encontrando uno nuevo.”
El diccionario de la Real Academia Española de la Lengua la define como:
“Capacidad de entender o comprender. Capacidad de resolver problemas.
Conocimiento, comprensión, acto de entender. Habilidad, destreza y experiencia.”
Así mismo podemos presentar varias definiciones de Inteligencia Artificial:
?
Diseño de sistemas inteligentes, es decir, que exhiben características que
asociamos con la inteligencia humana como entender lenguaje natural,
aprendizaje, razonamiento, etc. [Barr y Feigenbaum, 1981].
?
Hacer computadoras más útiles y entender los principios que hacen posible la
inteligencia [Winston, 1992].
?
Programar computadoras para que hagan tareas que actualmente son hechas
mejor por los seres humanos debido a sus características propias como el
aprendizaje perceptivo, la organización de la memoria y el razonamiento
[Jackson, 1990].
?
Campo de la ciencia y de la ingeniería que se ocupa de la comprensión a través
de la computadora de lo que comúnmente llamamos comportamiento inteligente
y de la creación de herramientas que exhiben tal comportamiento [Shapiro,
1992].
Todas ellas nos conducen a definir dos aspectos básicos de la Inteligencia Artificial:
entender y modelar sistemas inteligentes y construir máquinas inteligentes. El primero
de ellos nos da una visión científica de la IA y el segundo ingenieril. Para José Cuena
- 66 -
2. Situación actual y planteamiento del problema
?Cuena, 1997] la IA puede verse desde dos perspectivas, como Ciencia, entendiendo la
naturaleza de la inteligencia, y como Ingeniería, construyendo artefactos que presentan
una conducta inteligente. Juan Pazos [Pazos et alt., 1997] afirma que la IA como
Ciencia trata del estudio del comportamiento inteligente, siendo su fin conseguir una
teoría de la inteligencia que explique la conducta que observa en seres de naturaleza
inteligente y que guíe la creación de entes artificiales capaces de alcanzar dicho
proceder inteligente. Por otra parte como Ingeniería la IA se ocupa de los conceptos, la
teoría y la práctica para la construcción de máquinas inteligentes. En [Nilsson, 1971] se
integra el concepto de Ciencia e Ingeniería, considerando que la IA tiene como objeto el
estudio del comportamiento inteligente en las máquinas. A su vez, el comportamiento
inteligente supone percibir, razonar, aprender, comunicarse y actuar en entornos
complejos.
El concepto de IA se considera tan amplio que usualmente se divide en dos clases,
que [Kremer, 2001] explica con definiciones simples y concretas:
?
?
IA débil. Maquinas que pueden actuar como si fueran inteligentes.
IA fuerte. Máquinas que actúan inteligentemente con mentes reales y
conscientes.
Pensar que la IA pueda igualar o superar la inteligencia humana es difícil, hay
capacidades como el arte y las emociones que no podemos imaginar en máquinas (IA
fuerte). Tal vez IA no debería ser comparada a la mente humana. El objetivo, sin
embargo, es conseguir una IA tan provechosa como sea posible y no simplemente
copiar el cerebro humano (AI Débil). [Rich y Knight, 1991] utiliza la definición de IA
débil y su uso en computadoras para determinar que el objetivo de la IA es estudiar
como hacer posible que los ordenadores realicen tareas que, por el momento, hacen
mejor los humanos. Este concepto guía el propósito de esta tesis, ya que queremos
construir un sistema inteligente que, cooperando con los humanos y basándose en sus
conocimiento, optimice los resultados de una tarea crítica que actualmente realizan
usando solo su inteligencia.
Para llevar a cabo el objetivo global de la IA, esta se ha dividido en una serie de
áreas de investigación, cada una con unos propósitos específicos que permiten aportar
conocimientos y métodos particulares que ayudan al cumplimento de la meta general.
Entre estas están las redes neuronales artificiales, el procesamiento del lenguaje natural,
la visión artificial, el reconocimiento de formas, la robótica inteligente y los sistemas
basados en el conocimiento. Uno de los ejemplos más claros de IA débil serían los
sistemas basados en el conocimiento, entre los que se encuentran los sistemas expertos
y los sistemas de tutorización inteligentes. La figura 2.22 muestra la relación entre estos
distintos tipos de sistemas dentro de la IA.
- 67 -
2. Situación actual y planteamiento del problema
INTELIGENCIA
ARTIFICIAL
SISTEMAS
BASADOS
EN EL
CONOCIMIENTO
SISTEMAS
DE
TUTORIZACION
INTELIGENTES
Visión
simbólica
Visión
cognoscitiva
Visión
constructivista
SISTEMAS
EXPERTOS
Visión
conductista
Figura 2.22 Entorno de los Sistema Basado en el Conocimiento
La figura 2.22 presenta de una forma esquemática la relación jerárquica de estos
sistemas dentro de la IA y sus planteamientos. La IA utiliza una visión simbólica de la
realidad, manipulación de símbolos frente a computación algorítmica, que se ha visto
ampliada por métodos conexionistas y heurísticos. Los Sistemas Basados en el
Conocimiento basan su arquitectura y funcionamiento en la visión cognoscitiva, es
decir, de estructuración del conocimiento. Dentro de esta estructura podemos distinguir
la visión constructivista de los Sistemas de Tutorización Inteligentes que pretenden que
el utilizador, en general estudiante o aprendiz, guíe su propio proceso de aprendizaje,
mientras que los Sistemas Expertos tienen una visión conductista dando una respuesta
razonada a estímulos o factores externos.
Centrándonos en el ámbito concreto de la IA que nos ocupa, los Sistemas Basados en
el Conocimiento tratan problemas complejos en un dominio determinado y necesitan un
elevado conocimiento sobre el mismo. Sus principios fundamentales son:
?
?
?
Emulación de la capacidad de resolución del ser humano;
Utilización de las mismas fuentes del conocimiento que utiliza el experto
humano;
Aplicación a un dominio específico.
De forma más detallada [Giarretano, 1989] les asigna un gran número de
características atractivas:
- 68 -
2. Situación actual y planteamiento del problema
?
Maneja el conocimiento de un dominio, es decir, maneja los hechos, y las
relaciones que permiten encontrar soluciones a problemas planteados en el
dominio.
?
Permite acceder fácilmente al conocimiento de ese dominio, ya que el
conocimiento reflejado en el sistema debe estar disponible mediante medios
informáticos accesibles.
?
Simula el proceso que realizaría un experto humano resolviendo un problema.
?
Es permanente, es decir, el conocimiento que posee es persistente, frente a la
muchas causas de no disponibilidad de la presencia humana. Sirve como
repositorio de conocimientos dentro de la organización, manteniendo y
facilitando que el conocimiento perdure.
?
Puede englobar el conocimiento de varias personas, sumando conocimiento
específicos de expertos en una única base. El nivel de experiencia combinada de
varios expertos puede exceder el de un solo experto humano, además de que
puede estar disponible para trabajar simultánea y continuamente sobre un
problema.
?
Puede servir para evitar peligros a las personas, ya que puede utilizarse en
ambiente de riesgo o insalubres.
?
Explica explícitamente el camino que siguió su razonamiento y que le llevó a la
solución presentada, lo que incrementa la confianza de la decisión tomada.
?
La utilización de tecnologías de la formación permite al sistema basado en el
conocimiento emitir una respuesta rápida, mayor a la del ser humano. Esta
característica es vital en algunas situaciones de emergencia.
?
Ofrece respuestas de una forma uniforme, impersonal, sin prejuicios y completa
en cualquier situación, evitando las debilidades propias e inherentes al ser
humano, sobre todo en situaciones de fatiga o peligrosas.
?
Puede servir como asistente personal, tanto en el ámbito educativo como
productivo, en el uso de herramientas, en la toma de decisiones, etc.
?
La forma del razonamiento (Motor de Inferencia) y el conocimiento (Base de
Conocimientos) son independientes, lo que implica que los cambios que se
realicen en uno de ellos pueden ser independientes de los cambios en el otro.
- 69 -
2. Situación actual y planteamiento del problema
?
Puede actuar como una base de datos inteligente permitiéndonos acceder a su
conocimiento de forma guiada.
Como podemos inferir de lo anteriormente expuesto, la principal característica de un
Sistema Basado en el Conocimiento es el potente cuerpo de conocimientos que acumula
durante la construcción del sistema. Estos conocimientos son explícitos y están
organizados para simplificar la toma de decisiones. El primer problema que se plantea
es definir la representación del conocimiento. Para [Davis et alt., 1993] la
representación del conocimiento puede utilizarse como:
1. Un substituto de lo que existe en el mundo real o imaginario;
2. Un conjunto de cometidos ontológicos: ¿En qué términos hay que pensar acerca
del mundo?;
3. Una teoría fragmentaria del razonamiento inteligente: ¿Qué es la inteligencia?,
¿Qué se puede inferir de lo que se conoce?, ¿Qué se debería inferir de lo que se
conoce?;
4. Un medio para la computación eficiente: ¿Cómo se debería organizar la
información para facilitar la manera de pensar y razonar?;
5. Un medio de expresión humana: un lenguaje que los humanos usan para hablar
con las máquinas.
Los cinco roles tienen importancia, caracterizan el núcleo de la representación y hay
que tenerlos en cuenta cuando se diseña el modelo de representación. Este debe ser
pragmático, efectivo y rico en abstracciones ya que representa el mundo natural.
Debemos considerar la representación de dos tipos de conocimiento: el propio de los
objetos que forman parte del dominio y las relaciones entre ellos.
En su definición el Grupo Especialista en Sistemas Expertos de la Sociedad Británica
de Ordenadores determina el estilo más adecuado para estos sistemas:
“La incorporación dentro de un sistema de ordenador de un componente basado en
el conocimiento, correspondiente a una habilidad experta, de tal forma que el sistema
pueda ofrecer asesoramiento inteligente o tomar una decisión inteligente sobre una
función del proceso. Una característica adicional deseable, que muchos consideran
fundamental, es la capacidad del sistema, si se le solicita, de justificar su propia línea
de razonamiento de un modo directamente inteligible para el interrogador. El estilo
adoptado para alcanzar estas características es la programación basada en reglas.”
- 70 -
2. Situación actual y planteamiento del problema
Además del sistema basado en reglas de producción la ingeniería cognoscitiva ha
adaptado diversos sistemas de representación del conocimiento. Entre los principales se
tienen aquellos que parten de la lógica simbólica, como la lógica proposicional y de
predicados y las reglas de producción, y los que parten de formas estructuradas, como
redes asociativas, marcos o representación orientada a objetos.
Los sistemas basados en reglas son los más comúnmente utilizados. Su simplicidad y
similitud con el razonamiento humano, han contribuido para su popularidad en
diferentes dominios. Las reglas son un importante paradigma de representación del
conocimiento y lo representan utilizando un formato SI-ENTONCES (IF-THEN), es
decir tienen 2 partes:
?
?
La parte SI (IF), es el antecedente, premisa, condición o situación;
La parte ENTONCES (THEN), es el consecuente, conclusión, acción o respuesta.
Sobre esta estructura básica se pueden buscar variantes combinando diferentes
premisas mediante operadores lógicos (y/o). El proceso de razonamiento en un sistema
basado en reglas es una progresión desde un conjunto inicial de afirmaciones y reglas
hacia una solución, respuesta o conclusión. Las reglas de producción pueden estar
enlazadas cuando la conclusión de una regla puede ser considerada premisa de otra, de
esta forma se produce un encadenamiento de reglas que guía el proceso de
razonamiento.
La forma de estructurar los conocimientos va a ser fundamental en la propuesta tanto
arquitectural como metodológica que planteamos en este trabajo y nos referiremos a ella
más adelante cuando propongamos nuestra propia estructuración de contenidos.
La otra parte importante a definir para la comprensión estos sistemas es su
arquitectura. La arquitectura se refiere a los componentes o módulos que constituyen el
sistema, independiente del dominio. Como señalan diversos autores, por ejemplo
[Harmon y King, 1988], dada la gran diversidad de Sistemas Basados en el
Conocimiento no se puede hablar de una estructura única. Sin embargo identifican los
componentes que en general forman parte de todo sistema de este tipo y son la base de
conocimientos y el motor de inferencia. La figura 2.23 muestra una arquitectura básica
y a continuación se detallan sus componentes.
- 71 -
2. Situación actual y planteamiento del problema
MODELO
SITUACIONAL
Figura 2.23 Arquitectura básica de un Sistema Basado en el Conocimiento
Base de Conocimientos.
Contiene la información sobre el dominio de conocimientos que debe poseer el
sistema para realizar sus deducciones dentro de su competencia. Se construye a partir de
la fuente del conocimiento. Esta fuente puede ser de tipo estático o dinámico,
considerando en el primer grupo libros, manuales, videos, etc., mientras que el segundo
se refiere al conocimiento introducido directamente por el experto en la materia. Implica
la representación formal de la estructura del conocimiento del sistema.
Es importante determinar que algunos autores dividen este único módulo en dos:
?
Base de datos. Corresponde al conocimiento declarativo (hechos). Contiene los
hechos, los datos y las heurísticas, o datos deducidos a través de la experiencia,
puntuales del dominio. Estos son obtenidos de las fuentes estáticas del
conocimiento, con la revisión del experto en el dominio.
?
Base de relaciones. Corresponde al conocimiento procedimental (relaciones).
Contiene las relaciones que se establecen entre los hechos del dominio.
Normalmente se establecen por medio de reglas del tipo ‘Si una condición,
entonces una acción o conclusión’. Estas relaciones se ejecutan de acuerdo con
el razonamiento que siga el motor de inferencia.
Modelo situacional.
También llamado memoria de trabajo, ya que es una memoria auxiliar que contiene
información sobre el problema a resolver y el estado del sistema a lo largo del proceso
de inferencia. Durante una consulta con el sistema experto, el usuario introduce la
- 72 -
2. Situación actual y planteamiento del problema
información del problema actual en la base de hechos. El sistema empareja esta
información con el conocimiento disponible en la base de conocimientos para deducir
nuevos hechos. La ejecución de reglas modifica el modelo situacional añadiendo o
eliminando hechos en ella. Finalmente contendrá la representación de los hechos para el
caso o consulta concreta que se ha ejecutado.
Motor de inferencia.
El motor de inferencia es una colección integrada de algoritmos de resolución de
problemas (algoritmos de búsqueda). Se ocupa de determinar que reglas son aplicables,
seleccionar una y aplicarla, hasta alcanzar el objetivo. Refleja el razonamiento del
experto en el dominio. Su objetivo es derivar nueva información. Está formado por los
algoritmos o programas que reflejan algún tipo de inferencia, manejan (seleccionan,
deciden, interpretan y aplican) los conocimientos de la base de conocimientos a partir de
los datos de entrada del modelo situacional, actualizando este según se desarrolla la
inferencia, y coordinan las acciones que el sistema, como un todo, debe realizar.
Unidades de entrada/salida.
Es el medio por el que el usuario, el experto y otros sistemas se comunican con el
Sistema Basado en el Conocimiento. La comunicación se establece directamente con el
control del sistema (Motor de Inferencia) o con las bases de datos, tanto de
conocimiento como el modelo situacional. Este módulo puede considerar divido en
varias funciones:
?
Módulo explicativo. También llamado módulo o subsistema de justificación. Es
la parte del sistema que explica los pasos realizados por el motor de inferencias
para llegar a las conclusiones.
?
Módulo de adquisición del conocimiento. A través de este componente el
ingeniero del conocimiento o el experto del dominio puede construir
inicialmente el conocimiento (hechos y reglas) o actualizarlo en la base de
conocimientos. Existen algunas herramientas que permiten hacer esta
adquisición de forma automática, tal como TOPKAT (The Open Practical
Knowledge Acquisition Toolkit) que integra técnicas de extracción del
conocimiento con el enfoque de modelado de CommonKADS [Kingston, 1994].
?
Interfaz usuario/sistema. También llamado subsistema de consulta, es la parte
del sistema que posibilita la comunicación entre el usuario y el motor de
inferencia. Permite introducir la información del modelo situacional y la que
necesita el sistema, así como recibirla desde el motor de inferencia. Lo
importante en el diseño y construcción de la interfaz es que esta deber estar de
acuerdo con las necesidades del usuario, el conocimiento que él tiene sobre el
dominio y las características del problema y de su solución.
- 73 -
2. Situación actual y planteamiento del problema
Esta arquitectura básica será tenida en cuenta en esta tesis para proponer una
arquitectura para la construcción de un módulo con capacidad de asistencia inteligente
para la parametrización en el marco de los sistemas ERP.
2.2.2. Clasificación de los sistemas basados en el conocimiento
Diversos autores utilizan clasificaciones distintas de los Sistema Basados en el
Conocimiento, por su funcionalidad o propósito, por el papel que realiza en el entorno y
por su estado de evolución.
[Sheel, 1990] y [Hickman et alt. 1989] realizan una clasificación de acuerdo con la
función que el sistema realiza o su propósito. A continuación se muestra esta
clasificación y se menciona algún ejemplo de sistema construido:
?
Descubrimiento: Sistemas que a partir de un conocimiento inicial generan
conceptos nuevos y relaciones entre ellos. Por ejemplo META-DENDRAL
sobre la conducta de algunos compuestos en el espectrómetro de masas.
?
Diagnóstico: Sistemas que detectan las causa de errores o malfuncionamiento.
Por ejemplo MYCIN para diagnosticar las causas de enfermedades infecciosas
en un paciente.
?
Monitorización: Sistemas que controlan el estado de un proceso en ejecución y
lo comparan con el estado esperado detectando las desviaciones y sugiriendo
correcciones. Por ejemplo REACTOR para procesos de un reactor nuclear.
?
Interprete: Sistemas que analizan datos y partir de ellos determinan una
situación. Por ejemplo PROSPECTOR sobre las muestras de minerales para
detectar yacimientos.
?
Predicción: Sistemas que infieren las consecuencias probables de una situación
utilizando modelos de simulación. Por ejemplo PTRANS que estima
necesidades en la producción.
?
Diseño: Sistemas que configuran nuevas estructuras a partir de unas condiciones
iniciales. Por ejemplo SECS que genera compuestos químicos.
?
Planificación: Sistemas que determinan las acciones a tomar para alcanzar un
objetivo. Por ejemplo KNOBS para la planificación táctica de ataques aéreos.
- 74 -
2. Situación actual y planteamiento del problema
[Guida y Tasso, 1994] clasifica los Sistemas Basados en el Conocimiento según el
papel que realiza en el entorno en términos de responsabilidades y tareas. Esta
clasificación es la siguiente:
?
Sistema soporte: Sistema que ayuda al usuario en su toma de decisiones pero no
lo reemplaza. La responsabilidad última es del usuario, el sistema actúa como
asesor o consultor ofreciendo conocimientos y competencias.
?
Sistema prescriptivo: Sistemas que dirigen al usuario en la ejecución de una
tarea o en la toma de decisiones. Necesita la participación del usuario, aunque el
sistema puede dirigir y controlar. La responsabilidad, en consecuencia, es
compartida. Mejoran la calidad del trabajo y reducen el tiempo de ejecución.
?
Sistema autónomo: Sistemas que no interactúan con el usuario, sino que lo
reemplazan, son autónomos en sus decisiones, por tanto la responsabilidad final
es del sistema.
[Waterman, 1986], por su parte, incide en el grado de evolución del sistema, es decir,
en el estado en que se encuentra respecto a su posible uso o aplicación. Su clasificación
es la siguiente:
?
Prototipo de demostración: Sistema reducido que se utiliza para presentaciones y
demostraciones y hace referencia a un sistema más completo que está sin
desarrollar, aunque si especificado. Muestra que el futuro sistema será viable
solucionando una porción del problema.
?
Prototipo de investigación: Sistema mediano que funciona de manera aceptable
pero que debe ser revisado y probado. Es una versión inicial del futuro sistema.
?
Prototipo de campo: Sistema mediano o grande que está siendo probado en un
entorno real y responde a las expectativas.
?
Modelo de producción: Sistema de gran tamaño ya probado en un entorno real
de usuario y que ha conseguido buenos resultados y responde a las necesidades
de eficiencia y calidad requeridas.
?
Sistema comercial: Sistemas con las mismas características del modelo de
producción y que están siendo utilizados regularmente.
- 75 -
2. Situación actual y planteamiento del problema
2.2.3. Sistemas de Ayuda Inteligente
Para [Brusilovsky, 2004] los Sistemas de Ayuda Inteligente (IHS o Intelligent Help
Systems), también llamados Sistemas Adaptativos Inteligente (AHS o Adaptative Help
Systems) son una clase específica de sistemas de ayuda resultado del cruce de líneas de
investigación en IA y en Interacción Persona Ordenador (HCI o Human-Computer
Interaction). El objetivo de estos sistemas (IHS) es proporciona ayuda personalizada a
usuarios que trabajen con interfases complejas. A diferencia de los tradicionales
sistemas de ayuda estáticos que proporcionan la misma información ante un hecho
concreto a usuarios diferentes, los IHS se adaptan al conocimiento y los objetivos de
cada usuario, ofreciendo información relevante en su confronto y en la manera más
adecuada.
[Jones y Virnou,1991] destaca que los IHS utilizan una inferencia explícita del
conocimiento que proporciona el soporte al resto de módulos del sistema, por tanto los
IHS se encuadran, como los Sistemas Inteligentes de Tutorización, dentro de los
Sistemas Basados en el Conocimiento.
Los IHS nacen principalmente como ayuda a aplicaciones informáticas, aunque hay
sistemas que ayudan a la navegación aérea, a la producción e instalación de productos
complejos o a la toma de decisiones de negocio. Dado el marco de aplicación de este
trabajo vamos a centrarnos en los sistemas de ayuda a aplicaciones informáticas. La
complejidad y variedad de aplicaciones informáticas ha crecido de forma exponencial
en los últimos años. Al mismo tiempo crece la exigencia de optimización del uso de
estos sistemas entre todo tipo de usuarios. Muchos de ellos, por sus conocimientos,
experiencia o motivación, no tienen tiempo o posibilidad de estudiar los manuales de las
aplicaciones y practicar en entornos formativos o de prueba. Nace, así, la necesidad de
los IHS para cubrir las deficiencias de los manuales escritos o las ayudas on-line o los
soportes telefónicos [Erlandsen y Holm, 1987]. La figura 2.24 presenta el modelo de
[Fischer, 1999] que explica la utilización por parte de los usuarios de una aplicación
compleja, del que se deduce cual puede ser el papel de los IHS. Este modelo es
generalizable a la mayoría de los sistemas informáticos.
En la figura se representan los siguientes conjuntos de funcionalidades:
?
?
?
?
D1. Representa los conceptos y órdenes que el usuarios es capaz de realizar sin
necesidad de ayuda;
D2. Son las acciones que el usuario realiza en el sistema de forma ocasional;
D3. Es la representación de la visión que el usuario tiene del sistema, la
funcionalidad que él cree que el sistema es capaz de proporcionar;
D4. Es la representación del sistema real de una forma objetiva. Las funciones y
acciones que proporciona y que están disponibles para el usuario;
- 76 -
2. Situación actual y planteamiento del problema
?
D4´. Representa la evolución de la situación. Al aumentar las capacidades y
funciones de los sistemas, hacerse más complejos, el sistema se representa con
D4´, incrementándose la porción del sistema que es desconocida para el usuario.
Figura 2.24 Modelo de niveles de utilización de un sistema informático complejo
En los formatos tradicionales es posible incluir gran cantidad de información pero su
utilidad y utilización es cuestionable. El uso de manuales en papel tienen desventajas
tales como incomodidad, espacio físico de almacenamiento, dificultad para compartirlos
entre varios usuarios, etc. Evidentemente son imposibles de actualizar a medida que la
aplicación evoluciona, si no es con la sustitución de la información proporcionada y la
manera de proporcionarla es la misma para todos los usuarios. Nace así como
complemento el soporte telefónico que ayuda a los usuarios a encontrar la información
buscada pero no aporta nada a los propios manuales escritos. La ayuda on-line, otra
aplicación dentro de la inicial, suprime algunas desventajas como la incomodidad, el
espacio físico, la actualización y distribución, pero el contenido suele ser la copia
electrónica de la versión en papel. Tradicionalmente son estáticos y proporcionan
solamente ayuda textual (no imagen, video, gráficos o sonido) Cuando estos sistemas se
complican, incrementando los contenidos y sus relaciones e intentan mostrar los
contenidos de forma sensible al contexto, se convierten, a su vez, en sistemas que
necesitan ayuda para ser utilizados y los usuarios tienen dificultades para explicar lo que
quieren saber o sobre lo que necesitan ayuda.
Los IHS deben ser capaces de responder a los usuarios como individuos, teniendo en
consideración su experiencia y la forma preferida y más comprensible de representación
de la ayuda para cada usuario. Para ello, según [Zissos y Witten, 1985], deben mantener
un modelo de usuario que represente sus conocimientos actuales y preferencias. Además
deben adaptar su comunicación a la situación particular y el contexto, para ello debe
poseer una cierta capacidad de reconocimiento de planes y objetivos. En el modelo de
- 77 -
2. Situación actual y planteamiento del problema
usuario deben incluirse, además de conocimientos actuales y preferencias, planes y
objetivos, competencias que el usuario debe o quiere alcanzar.
De forma tradicional se dividen estos sistemas en activos y pasivos [Fischer et alt.,
1985]. Los pasivos dejan al usuario el control, no realizan ninguna acción hasta que el
usuario les pide ayuda y formula de forma correcta su petición. Los sistemas activos
pueden tomar la iniciativa y ofrecer ayuda cuando creen que el usuario la necesita. Se
estima que los usuarios utilizan solamente el 40% de las capacidades de las aplicaciones
informáticas y no creen que necesiten ayuda, a menudo conoce una manera de realizar
los procesos y siempre utilizan esa aunque no sea la mejor. Los sistemas activos
proporcionan la ayuda en el momento adecuado, ofreciendo al usuario diversas
alternativas y enseñándole formas más óptimas de realizar sus acciones.
Como describe [Brusilovsky y Schwartz, 1997] hay dos corrientes principales en la
investigación de IHS. La primera de ellas está centrada en UNIX y aplicaciones
relacionadas como herramientas de correo electrónico y editores de texto. La segunda
corriente se centra en proporcionar ayuda a sistemas de aplicaciones como aplicaciones
médicas o de gestión. Así mismo, [Brusilovsky y Schwartz, 1997] predicen una tercera
corriente de investigación centrada en IHS para los sistemas web, que debería mejorar
las anteriores dada la complejidad de interfaz de estas últimas aplicaciones. Podemos
atestiguar la confirmación de esta previsión con trabajos como [Aberg y Shahmehri,
2001] y [Carmona et alt., 2002], inspirados en la extensión exponencial del uso de
aplicaciones web, su necesidad de acceso por distintos medios (PC, móvil, agenda
electrónica, etc.) y la cantidad de información diferente que manejan y de tipos ámbitos
diferentes de aplicación.
La figura 2.25 muestra una arquitectura típica seguida en los sistemas IHS.
Usuario
Módulo del
dominio
B.D.
Documentación
Módulo de
usuario
B.D.
Planes
Interfaz
Figura 2.25 Arquitectura básica de un sistema IHS
- 78 -
2. Situación actual y planteamiento del problema
Un sistema IHS consta de 5 funciones principales (dos módulos, dos bases de datos y
un interfaz):
?
Interfaz. Realiza la comunicación con el usuario, puede incorporar funciones de
interpretación del lenguaje natural, presentación de la ayuda según las
preferencias y el formato elegido y recogida de información sobre la situación
actual de comunicación con el usuario.
?
Módulo del dominio. Contiene una representación explícita del conocimiento
sobre el sistema para el que se proporciona la ayuda. Recoge la información de
la B.D. de documentación en función de las peticiones del usuario y de la
situación del entorno.
?
Módulo del usuario. Contiene la información necesaria sobre cada usuario
particular, sus preferencias y su situación actual. Recoge información de la B.D.
de planes para conocer las competencias deseadas del usuario y sus objetivos.
?
B.D. Documentación. Contiene la documentación electrónica asociada al sistema
para el que se proporciona la ayuda. La documentación debe provenir de los
manuales y conocimiento experto sobre el sistema que se trata y estar
almacenada en diferentes formatos.
?
B.D. Planes. Contiene las distintas tipologías de competencias y habilidades que
puede llegar a alcanzar un usuario, los objetivos de conocimiento sobre el
sistema para el que se proporciona la ayuda y los distintos planes o itinerarios de
ayuda para conseguirlos.
Como hemos dicho el campo de aplicación de los IHS es muy amplio, incluso dentro
del ámbito de las aplicaciones informáticas. Veamos algunos ejemplos de IHS en este
ámbito.
Unix Consultant
Unix Consultant es un asistente inteligente cuyo objetivo es proporcionar ayuda
básica sobre el sistema UNIX a usuarios sin conocimientos previos, utilizando un
interfaz inteligente en lenguaje natural [Wilensky et alt., 1989]. Los puntos más
interesantes de este sistema son el procesamiento del lenguaje natural, la representación
del conocimiento y el razonamiento automático. Para la representación del
conocimiento se ha utilizado un lenguaje, KODIAK, con el que se representan los
conceptos como objetos y las relaciones entre ellos, que proporcionan el conocimiento.
Esta concebido para trabajar de forma incremental, pudiéndose introducir fácilmente
- 79 -
2. Situación actual y planteamiento del problema
mayor conocimiento sobre las funciones del sistema UNIX. Para representar el modelo
de usuario utiliza un componente, KNOME, que considera clases de usuarios y
categorías de funciones UNIX.
PAL
PAL es un IHS aplicado a un paquete software llamado MATERIA que se utiliza
para el diseño molecular [Silber, 1990]. Se basa en una gestión detallada de planes y su
relación con cada usuario, distinguiendo entre planes activos y planes completados. Se
encuadra dentro de los IHS activos, de forma que puede avisar al usuario para que
cambie su estrategia de uso y aprendizaje del sistema, por ejemplo cuando sus acciones
no concuerden con su plan. Para realizar estas funciones mantiene activo, durante cada
sesión de usuario, un módulo (Memoria de trabajo) que contiene todas las acciones
realizadas por el usuario y el sistema. El grupo creador de PAL ha diseñado una
arquitectura modular que permite fácilmente utilizar este sistema en otras aplicaciones
informáticas, modificando los contenidos de dos de sus módulos: Ayuda y Planes.
Sinix Consultant
Sinix Consultant es un IHS cuyo objetivo es proporcionar ayuda a los usuarios del
sistema operativo SINIX [Hecking et alt., 1988]. Trabaja en las dos vertientes de los
IHS: como sistema pasivo y activo, ya que responde a las preguntas de los usuarios en
lenguaje natural (en concreto en idioma alemán) sobre terminología y acciones de
SINIX y analiza las acciones que el usuario realiza sobre el sistema operativo
enviándole instrucciones y consejos si determina que no las realiza de forma óptima.
Mantiene una extensa base de conocimientos sobre SINIX, relacionando términos y
manteniendo dependencias entre conocimientos previos y siguientes, además del uso
que hace del SIINIX cada usuario. Contiene un modelo de cada usuario y modelos
prefijados en cuatro niveles: novato, principiante, intermedio y experto.
Eurohelp
Eurohelp es un proyecto financiado por la Unión Europea con el objetivo de realizar
sistemas de ayuda inteligentes para aplicaciones informáticas [Winkels y Breuker,
1992]. El objetivo principal del proyecto era la creación de una metodología general de
desarrollo de este tipo de sistemas. Para conseguirlo se creo un módulo independiente
para contener el conocimiento sobre la aplicación y se probó utilizándolo en
aplicaciones como el sistema de correo electrónico del sistema operativo UNIX. Se trata
de un sistema de ayuda activo y para ello se mantiene información sobre el objetivo de
- 80 -
2. Situación actual y planteamiento del problema
los usuarios y los planes propios de cada usuario y los planes genéricos de distintos
niveles de experiencia, pudiendo comparar toda esta información y generar indicaciones
si hay discrepancias. Su actuación inteligente se basa en la interpretación y generación
de lenguaje natural y la información contextual del estado de la aplicación y del
conocimiento del usuario sobre la aplicación.
ARAN
ARAN es un IHS para el sistema operativo UNIX [Fernandez-Manjon, 2001]. En
cualquier momento, mientras el usuario esta trabajando en UNIX, puede activar la
ayuda de ARAN y expresar su necesidad. El sistema tiene un interfaz gráfico muy
elaborado que facilita la comprensión de la información que se presenta y de la que se
solicita. El usuario puede elegir su comunicación con el sistema en tres modos:
inspección del dominio, mediante menús y uso del ratón; interacción en lenguaje
natural, mediante pregunta directa; selección de descriptores, mediante el uso de listas
que proporciona el sistema con los descriptores posibles y los documentos en los que
aparece cada descriptor. ARAN utiliza técnicas de hipertexto y de recuperación de
información estadística. Los principales objetivos del proyecto que ha realizado este
sistema son demostrar la posibilidad de utilización de los IHS en entornos complejos y
crear una estructura general de representación de la información y modelado de
usuarios.
2.2.4. Sistemas Inteligentes de Tutorización
La enseñanza asistida por computadora (CAI o Computer Assisted Instruction) surge
a finales de los años 50 con la idea de programar la enseñanza, de alguna forma,
sustituir al profesor por un ordenador. El tiempo transcurrido desde entonces ha
modificado bastante esta idea inicial, el objetivo actual de los sistemas de educación por
medios informáticos no es la supresión del profesor sino su conversión a un papel
diferente, dejar de ser transmisor de contenidos para convertirse en guía y facilitador del
proceso educativo. Con esta premisa nace el concepto de tutor virtual y de
teleformación.
Por otro lado diferentes autores a lo largo de las décadas de los 80 y 90 (por ejemplo
[Ford, 1987] y [Kahn, 1991]) han venido propugnando que la tecnología sea un soporte
a la enseñanza que permita seleccionar diferente estrategias pedagógicas entre las cuales
el alumno-profesor elija cual es la que mejor se adapta a cada estilo y capacidad.
Actualmente estamos viviendo un momento en el que “se trata de pasar de una
- 81 -
2. Situación actual y planteamiento del problema
enseñanza centralizada, característica del modelo en cascada del docente al discente, a
un modelo en el cual cada vez más responsabilidad sobre el aprendizaje viene atribuida
a quién aprende” [Resnick, 1998]. Partiendo de esta base se puede definir dos objetivos
básicos en un buen sistema de aprendizaje: Instrucción centrada en el alumno e
Interactividad. Para obtenerlos todo el proyecto se debe llevar a cabo conociendo muy
bien las necesidades, conocimientos y motivaciones del alumno y proporcionando
medios de comunicación para obtener en todo momento retro-información del alumno.
En general, analizando los actuales sistemas comerciales de teleformación podemos
deducir que:
?
?
?
?
Prestan poca atención a la adaptación y guía en los procesos de aprendizaje.
Realizan una formalización y estructuración del conocimiento muy superficial y
poco eficaz a efectos docentes.
Están orientadas hacia contenidos demasiado expositivos (libros con diferente
formato).
Ignoran de manera sistemática la enseñanza de habilidades y destrezas.
Por otro lado, se ha venido intentando utilizar la Inteligencia Artificial para conseguir
suplantar al profesor mediante un ordenador considerado como “tutor”. Con esta idea
nacen los Sistemas Inteligentes de Tutorización (ITS o Intelligent Tutoring Systems)
que tratan de ofrecer a cada alumno la posibilidad de un proceso de enseñanza
individual y particularizado, procurando establecer estrategias de enseñanza sobre la
base del seguimiento del aprendizaje y de los resultados que alcanza cada alumno,
intentando emular a los tutores humanos en su habilidad para determinar en cada caso
que enseñar, cuando enseñarlo y como enseñarlo.
La idea de proporcionar inteligencia a los entornos de teleformación no es nueva.
Desde el principio de la década de los 90 diversos autores, principalmente Brusilovsky
[Brusilovsky, 1993] han desarrollado sistemas ILE (Intelligent Learning Enviroment)
para distintas materias. El propio [Brusilovsky, 1997], a finales de la década, amplia el
concepto para cubrir una necesidad formativa más general: integrar ITS, hipermedia y
entornos de teleformación. Su objetivo es soportar distintos estilos de aprendizaje y
adaptarlos a cada alumno. Estos sistemas se basan en estructuras jerárquicas clásicas del
modelo del dominio, que son controladas y recorridas según los parámetros establecidos
en el modelo del estudiante. Estos sistemas han desarrollado la interactividad y
adaptabilidad de los sistemas de teleformación mediante técnicas relacionadas con la
interacción sistema-alumno, tales como las agrupadas bajo el término AH (Adaptative
Hypermedia) [Brusilovsky, 2003].
Aunque hasta ahora la mayoría de los ITS está siendo utilizada en pequeña escala y
no muchos de ellos se han analizado ampliamente, varios autores han identificado
- 82 -
2. Situación actual y planteamiento del problema
diversas razones del éxito obtenido por alguno de ellos. [Schofield et alt., 1990] indican
que la razón de su éxito es el hecho de permitir al profesor pasar más tiempo con
estudiantes retrasados o incrementar la motivación de la clase, dando menos
importancia a la guía que realiza el ITS sobre el alumno. Para [McArthur et alt., 1990]
los ITS seleccionan las tareas o problemas a realizar, deciden que soporte necesita el
estudiante, la respuesta y la naturaleza de la información que deben recibir. Esto
significa que aunque el estudiante tiene cierto control la mayor parte de las decisiones
las toma el ITS basándose en las experiencias e informaciones que el propio estudiante
le ha proporcionado antes. [Ohlsson, 1991] argumenta que la verdadera importancia de
un ITS está en función de los principios de aprendizaje que lo iluminan. Estos principios
apoyados en el conocimiento del aprendizaje y la enseñanza son la guía de construcción
de nuevas generaciones de sistemas. Por otro lado, [Anderson et alt., 1987] considera
que los alumnos necesitan una respuesta rica y variable. Esto es fundamental en
procesos de generación de la respuesta paso a paso, en donde al estudiante le resulta
más difícil localizar el error entre todas las acciones realizadas, es decir, los ITS tienen
una capacidad de generar una respuesta altamente detallada en la resolución de
problemas
Los ITS, además, se basan en la utilización del aprendizaje colaborativo, cuyo
desarrollo es muy importante en el aprendizaje mediante clases no presenciales. En
[Soller, 2001] se presenta un modelo de aprendizaje colaborativo diseñado para ayudar
a los sistemas de aprendizaje inteligentes a identificar y alcanzar las áreas con
problemas de interacción de grupos. El modelo describe potenciales indicadores de
aprendizaje colaborativo efectivo y, para cada indicador, recomienda estrategias para
potenciar la interacción. Este modelo de aprendizaje colaborativo conduce al diseño y el
desarrollo de herramientas que automatizan la codificación y ayudan al análisis de la
actividad del aprendizaje colaborativo.
Si atendemos a las investigaciones de McArthur y su grupo ?McArthur et alt., 1990]
tanto los CAI como los ITS se caracterizan por una filosofía común: alto control del
tutor, presentando las tareas o problemas para dejar que el alumno conteste y
devolviendo después un resultado al estudiante. Pero la diferencia estriba en que los ITS
presentan razonamientos y conocimientos parecidos a los de un tutor humano (sistemas
basados en el conocimiento) ya que pueden actuar paso por paso, no corrigiendo solo el
resultado final, sino haciendo razonamientos intermedios. Esta condición resulta
fundamental para el desarrollo posterior de este trabajo, que no pretende obtener una
parametrización final y global del sistema sino guiar al usuario paso a paso en esta tarea,
obteniendo resultados parciales comprensibles que conduzcan hacia otros caminos en la
parametrización.
El desarrollo de los ITS ha sufrido algunos problemas, principalmente por la
dificultad de conseguir sistemas válidos en diversos ambientes. Tal y como señala
- 83 -
2. Situación actual y planteamiento del problema
[Rodríguez, 2000]: “estos sistemas han resultado ser complejos de construir, funcionan
para dominios muy restringidos, y las soluciones, salvo excepciones, no son escalables
o presentan gran dificultad para adaptarse a otros contenidos”. Realmente estos sistemas
tienen unas exigencias muy amplias, en este sentido, podemos considerar los IHS como
ITS más sencillos, con los que es posible lograr parte de los objetivos pedagógicos
perseguidos por un tutor, teniendo unas características menos exigentes. En la línea de
autores como [Marchionini, 1995] podemos considerar la ayuda y la enseñanza como
dos partes de un mismo proceso, siendo la ayuda una enseñanza con un objetivo muy
claro de resolución de un problema concreto.
Respecto a su arquitectura, según [Nezami, 1997] un ITS tiene cuatro componentes
básicos, que se representan con sus relaciones en la figura 2.26.
Módulo del
dominio
Contenidos
Estudiante
Interfaz
Módulo del
tutor
Situación
Módulo del
alumno
Figura 2.26 Arquitectura básica de un sistema ITS
La función de cada uno de estos componentes es la siguiente:
?
Módulo del tutor. Simula la acción real del tutor. Toma los contenidos del
Dominio que deben presentarse al usuario y decide en que forma gráfica
exponerlos. Debe usar un criterio dinámico en función de la información
almacenada en el modelo de estudiante sobre el estilo de aprendizaje y el estado
actual del mismo de cada estudiante. Realiza las funciones de evaluación y
supervisión.
?
Interfaz. Permite una interactividad real entre el estudiante y el sistema
(hipertexto, multimedia, realidad virtual, etc.), seleccionando, en cada caso, la
herramienta adecuada.
?
Módulo del dominio. Mantiene organizada la información sobre los conceptos y
el conocimiento que se va a enseñar, en función del área específica del
conocimiento.
- 84 -
2. Situación actual y planteamiento del problema
?
Módulo del alumno. Registra la situación de los alumnos. Usando actividades de
diagnóstico y evaluación contiene el estilo de aprendizaje del alumno y el estado
actual de su aprendizaje.
Así, los ITS se caracterizan por representar separadamente la materia que se enseña
(módulo del dominio) y las estrategias para enseñarla (módulo del tutor). Un punto
clave en los ITS, ya que determinará en gran medida la forma de trabajar del módulo del
tutor, es la forma de representación del conocimiento del dominio. Básicamente hay dos
corrientes, la representación mediante reglas de producción y las basadas en modelos
asociativos como redes semánticas. Por otro lado, caracterizan al alumno (a través de un
módulo del alumno) para procurar una enseñanza individualizada. El sistema debe
mantener información sobre los que el alumno sabe, lo que el alumno cree que sabe y
sobre lo que sabe pero es incorrecto. Este modulo es fundamental para poder realizar
una verdadera tutorización similar a la humana, por esto hay autores que consideran que
el modelado dinámico del alumno es la contribución fundamental que diferencia a los
ITS de los sistemas clásicos de teleformación [Self, 1994].
Los primeros ITS se orientaron al área de las matemáticas más sencillas y fueron
extendiéndose a otras áreas cercanas: temas matemáticos más complejos, ciencias y
electrónica. Posteriormente ampliaron su campo de aplicación al lenguaje y las ciencias
sociales. Actualmente podemos encontrar ITS sobre materias muy variadas como la
programación y el análisis de programas, el diagnóstico médico, la geografía y el
entrenamiento industrial. En [Brusilovsky, 1999] se recoge un estudio realizado de los
ITS existentes, en base al cual es posible clasificar los ITS en tres categorías
tecnológicas: basados en la secuencia curricular, basados en el análisis de las respuestas
del alumno y basados en el soporte interactivo a la resolución de problemas. La mayoría
de los primeros ITS desarrollados se basaban en las dos primeras técnicas.
?
Sistemas ITS basados en la secuencia curricular. El objetivo de estos ITS es
proporcionar al estudiante la más efectiva secuencia de instrucciones y tareas de
aprendizaje (ejemplos, preguntas, problemas, lecturas, etc.) para trabajar con
ella. Esta secuencia se definía individualmente para cada alumno y se denomina
secuencia curricular. Hay varios ejemplos de ITS que siguen esta tecnología,
aunque implementada de maneras diversas: ELM-ART [Brusilovsky et alt.,
1996], CALAT [Nakabayashi et alt., 1997] e InterBook [Brusilovsky y Schwarz,
1997].
?
Sistemas ITS basados en el análisis de las respuestas del alumno. Trabajan con
las respuestas finales que el alumno da a los problemas educativos que se le
plantean. El sistema proporciona al estudiante información adecuada según la
respuesta de este, siguientes tarea a realizar en caso de respuestas correctas o
- 85 -
2. Situación actual y planteamiento del problema
actividades a repetir o realizar o respuesta correcta y explicaciones en caso de
respuesta incorrecta. Además actualiza la información sobre el alumno con sus
resultados. En estos sistemas es muy importante la interfaz y el grado de
interacción alumno/tutor. Ejemplos de ITS que trabajan de esta forma son: LISP
Tutor, un ITS para programar en LISP [Anderson y Reiser, 1985] y WITS, un
ITS para el cálculo diferencial [Okazaki et alt., 1997].
?
Sistemas basados en el soporte interactivo a la resolución de problemas. El
objetivo de estos ITS es ayudar interactivamente al estudiante en la resolución
de problemas planteados durante su aprendizaje proporcionándole ayuda
inteligente en cada paso que deba realizar para alcanzar la solución. El sistema
debe recoger las acciones que realiza el estudiante, entenderlas y utilizarlas para
ayudarle y actualizar el modelo del estudiante. Podemos encontrar ejemplos de
este tipo de ITS en: Belvedere [Suthers y Jones, 1997], ADIS [Warendorf y Tan,
1997], que usa la tecnología de Java para soportar la interactividad, y PATOnline [Ritter, 1997].
Veamos a continuación algunos de los ITS referenciados y otros ITS particulares por
su dominio de aplicación o su modelado del conocimiento.
Interbook
InterBook [Brusilovsky y Schwarz, 1997] es un sistema para autorizar y entregar
libros de texto electrónicos en entornos adaptativos o inteligentes en la web. Todos los
libros electrónicos generan una tabla de contenidos, un glosario y una interfaz de
búsqueda. En Interbook la estructura del glosario contiene la estructura pedagógica del
dominio de conocimiento y cada nodo de la red del dominio se representa como una
entrada en el glosario. Todas las secciones del libro electrónico están indexadas según el
modelo del conocimiento, proporcionando referencias del glosario. Además establece
prerrequisitos entre los conceptos. El modelo de usuario de Interbook se crea a través
del registro del alumno con un modelo predefinido y se actualiza cada vez que el
alumno se mueve por el sistema tutor. Ayudándose de este modelo Interbook
proporciona al alumno guía, soporte a la navegación y ayuda personalizada. Para
realizarlo crea referencias entre el glosario y el libro electrónico según el conocimiento
del dominio que el alumno posee en cada momento, de esta forma, puede sugerir al
alumno la siguiente sección a visitar o cuando tiene dificultades en un tema indicarle el
concepto o los conceptos previos que debería repasar basándose en los prerrequisitos.
- 86 -
2. Situación actual y planteamiento del problema
LISP Tutor
LISP Tutor [Anderson y Reiser, 1985] es un ITS desarrollado para enseñar los
principios básicos del lenguaje de programación LISP. Contiene dos modelo
principales, el modelo experto que se creó como una serie de reglas de producción
correctas y el modelo del alumno que se construyó como un subconjunto de estas reglas
de producción correctas junto con reglas de producción comunes incorrectas, es decir
verdadero conocimiento y errores comunes o conocimiento falso que se da
frecuentemente. LISP Tutor está basado en el principio "aprender haciendo" donde el
alumno aprende trabajando por problemas. El tutor actúa como un guía en la resolución
de problemas pero nunca define el conocimiento que el alumno debe adquirir.
LISP Tutor emplea otro modelo conocido como modelo de traza que mantiene
distintos modelos de soluciones de problemas y los sigue a medida que el alumno
resuelve un problema. De esta forma devuelve información detallada, de una forma muy
simple, al alumno según sus acciones. Cuando el alumno comienza a resolver un
problema el sistema tutor recoge información sobre su solución y sobre las soluciones
erróneas. A medida que el estudiante escribe la solución el sistema tutor la analiza. Si la
información escrita es coherente con una solución correcta el sistema tutor permite que
el estudiante continúe, si es coherente con una solución incorrecta impide que el alumno
continúe y le da información sobre su error y el paso correcto a seguir. Si la solución no
coincide con ninguna almacenada el sistema tutor pide que se repita la solución. Este
método tiene las ventajas del diagnóstico temprano de errores y de la interactividad
permanente. El alumno nunca se aparta de una solución correcta. Tiene la desventaja de
ser un sistema muy restrictivo y nunca permite al estudiante explorar el comportamiento
incorrecto.
Belvedere
Belvedere [Suthers y Jones, 1997] es un sistema colaborativo que guía a los
estudiantes en el desarrollo de discusiones acerca de problemas científicos y da soporte
al desarrollo del razonamiento mediante la argumentación científica. Es un sistema
basado en el conocimiento que permiten trabajar a grupos pequeños de estudiantes.
Belvedere asiste a los estudiantes cuando trabajan sugiriéndoles formas de extender o
mejorar los diagramas argumentativos. Ofrecen un repertorio de mecanismos de
representación especializados que se usan para representar ideas y conceptos, y las
relaciones entre ellos. Tipifica cada idea que se aporta y la representa mediante un
gráfico. Utiliza un conjunto fijo de primitivas para representar hipótesis, evidencias, ect.
En base a la semántica de este lenguaje, el sistema puede chequear la consistencia de la
argumentación, e indicar posibles acciones al usuario. Tiene como modelo de
- 87 -
2. Situación actual y planteamiento del problema
representación una red semántica, con nodos y relaciones etiquetadas en términos del
conjunto de primitivas.
La interfaz de usuario ofrece un menú de formas gráficas a las que se puede añadir
texto, para construir representaciones de ideas o evidencias, que se relacionan con otras,
por tanto las aportaciones del grupo se representan en la interfaz del sistema en forma
de esquemas gráficos a los que se puede añadir texto. Para incorporar argumentaciones
se indica el tipo de nodo, se escribe el texto y se señala con qué otras ideas/nodos está
relacionado eligiendo también el tipo de relación. El sistema analiza la consistencia y
completitud del trabajo (grafo) creado por los estudiantes e incluye mecanismos de
aviso destacando aquellos elementos que están incompletos o incorrectos. También
ofrece pistas para mejorarlos. Existe una versión de este sistema que funciona a través
de Internet, que guarda la información en una base de datos que está en el servidor y que
intercambia los datos con los clientes.
TOTS, STEVE, PAT y PACO
Actualmente, hay otras líneas de investigación en el marco de los ITS que intentan
combinar las características generales de estos con sistemas interactivos orientados a las
tareas y se aplican a la enseñanza de tareas procedimentales. En esta línea está el
desarrollo secuencial de los prototipos TOTS, STEVE, PAT y PACO [Brusilovsky,
2003], que han perfeccionado progresivamente la idea inicial presentada con TOTS.
Van dirigidos a entornos de aprendizaje virtual, priorizando el dialogo colaborativo
entre el sistema y el estudiante y las animaciones gráficas. Estos sistemas modelizan el
conocimiento procedimental basándose en la representación declarativa de este, técnica
ampliamente explicada en [Rickel et alt., 2000], utilizada habitualmente por los ITS.
Hay cuatro módulos claves en estos prototipos de tutores inteligentes:
?
El módulo experto incorpora el conocimiento y las capacidades que deberían
enseñarse al estudiante; sabe solucionar los problemas que se le presentan.
Como ya hemos dicho, la representación típica del conocimiento en los ITS
puede ser como reglas de producción, y en este caso se ejecutarían las tareas del
dominio ejecutando directamente las reglas de producción, o como redes de
conocimiento, especificando los pasos del procedimiento y su orden y, en este
caso, las tareas del dominio se ejecutarían mediante un interprete independiente.
Los cuatro prototipos utilizan el mismo modo de representación: cada tarea
consiste en un conjunto de pasos y cada paso es una acción o un conjunto de
acciones con estructura jerárquica. Por último se programan condiciones entre
las tareas que son las que guían la ejecución a través de la red.
- 88 -
2. Situación actual y planteamiento del problema
?
El módulo de diálogo mantiene el estado del diálogo entre el tutor y el alumno,
es básicamente, la interfaz de comunicación y una estructura de datos que
almacena todo el proceso y que puede ser consultada por el resto de los
módulos.
?
El módulo de reconocimiento del plan usa la salida del módulo experto y del
modulo de dialogo para interpretar las acciones del estudiante y decidir lo que el
estudiante trata de hacer. Ajusta las acciones del estudiante al plan educativo
determinado si se sigue el plan inicial o no y las desviaciones en este último
caso.
?
El modulo ejecutivo pedagógico utiliza la salida de los otros tres módulos para
decidir que decir o hacer a continuación. Determinar el plan que sigue el
estudiante y compararlo con el plan inicial o teórico, conocer su situación real de
conocimiento, sus errores y aciertos y tener presente la materia a enseñar (en
este caso las acciones por las que tiene que ser guiado) permiten al sistema tutor
moverse por la estructura del conocimiento y presentar las acciones formativas
adecuadas.
SITA
SITA (Sistema Inteligente de Tutorización Avanzada) es un ITS desarrollado en la
Universidad de Alcalá [Pagés et alt., 2004]. Su existencia se justifica en la creciente
necesidad de dotar de inteligencia a los sistemas que ayudan al aprendizaje
descentralizado a través de internet y en la inexistencia de metodologías que permitan
generar con cierta facilidad contenidos docentes tutorizados, manteniendo un gran nivel
de formalización y estructuración en la representación de los conocimientos. SITA
combina la robustez y la amigabilidad de la multimedia en los actuales sistemas de
teleformación con la sofisticación y complejidad de los ITS. Al alumno este sistema le
ofrece la ventaja de una enseñanza altamente individualizada, donde los conocimientos
se adquieren de forma interactiva y de acuerdo a la filosofía ‘aprender haciendo’. Al
desarrollador y utilizador de contenidos se ofrece una importante novedad en la forma
de modelización de estos a través de un sistema universalmente reconocido de
representación de procesos como es EPC (Event Driven Processing Chains) y su
posterior implementación como reglas semánticas en una base de datos. Este método
formal permite la representación del conocimiento procedural obtenido del lenguaje
natural para almacenarlo y ejecutarlo, proponiendo al estudiante o aprendiz distintos
caminos a través de ese conocimiento mediante una aproximación top-down guiada a
través del conocimiento almacenado en el sistema.
- 89 -
2. Situación actual y planteamiento del problema
La metodología de creación de los contenidos docentes se basa en la Ingeniería
Lingüística del Conocimiento que guía la creación de las bases interactivas de
conocimientos que incluyen reglas sobre conocimientos propios del dominio que se
trata (que enseñar) e información multimedia sobre los objetos didácticos del dominio.
Se utiliza dicho método para transformar los conocimientos expresados en el lenguaje
natural de un texto en conocimientos con representaciones más formalizadas, actuando
como un puente entre los discursos explicativos de un texto y las reglas ejecutables que
todo sistema experto tiene para permitir sesiones de docencia guiadas. Después se
analizan las reglas semánticas obtenidas convirtiéndolas en diagramas del tipo EPC. El
conjunto de diagramas asociados a reglas obtenido forma el modelo de EPC o red
semántica. El proceso se simplifica, a partir de la representación de las reglas, gracias al
uso de la herramienta ARIS que permite, de forma automática, la validación del modelo
obtenido y la transformación de las reglas en ficheros de datos con los que cargar la
base de conocimientos del sistema.
SITA se puede conectar con una plataforma de teleformación existente en el
mercado, proporcionando la ventaja de aprovechar sus capacidades, ya probadas y
consolidadas, tradicionales en los Learning Management Systems comerciales, relativas
a la gestión y distribución de cursos y alumnos. También permite recibir información
contenida en la plataforma sobre las preferencias pedagógicas del alumno basadas en los
conocimientos de cada uno, las preferencias previas, etc., de manera que el sistema
tutorizado pueda proporciona una experiencia de aprendizaje individualizada para cada
estudiante. Además la arquitectura del sistema, basada en los actuales estándares en la
materia, permite que la integración con cualquier plataforma de teleformación comercial
sea fácil de desarrollar
A modo de validación y ejemplificación de la arquitectura y metodología de SITA se
ha desarrollado un prototipo de un caso real de aplicación en el que se han utilizado las
técnicas presentadas dentro de un sistema creado a partir de los principios
arquitecturales considerados como fundamentales, e interactuando con un sistema de
gestión del aprendizaje de tipo comercial. El objetivo de este caso práctico es el
desarrollo e implementación de un ITS conectado a un sistema de teleformación
avanzado para la formación de operadores de las máquinas punzonadoras de la empresa
de Máquinas-Herramientas GEKA. El sistema de teleformación elegido es LUVIT
(www.luvit.com), con el que la Universidad de Alcalá colabora desde hace tiempo.
LUVIT proporciona una plataforma educativa basada en la web con herramientas que
facilitan la producción de cursos on-line y que hacen posible obtener lecciones
dinámicas e interactivas utilizando diversos métodos pedagógicos seleccionados por los
profesores.
- 90 -
2. Situación actual y planteamiento del problema
2.2.5. Inteligencia artificial en el ámbito empresarial
Hace unos años al pensar en Inteligencia Artificial las situábamos en un ambiente de
investigación y de tecnologías asociadas a la experimentación, nunca destinada a
aplicaciones empresariales y de negocio. A partir de los años 80 algunos campos
concretos de la IA empiezan a utilizarse ampliamente en el control de maquinaría
eléctrica o mecánica. Aspectos relacionados con la robótica y la lógica fuzzy se usan
con éxito en el diagnóstico y control industrial. Hay que esperar a finales de los años 90
para ver como, en solitario o combinadas con aplicaciones software convencionales, las
técnicas de inteligencia artificial se utilizan en las áreas de gestión empresarial
[Buchanan, 2002]. Desde entonces podemos encontrar muchos ejemplos de IA en las
empresas e industrias: Software de planificación para, automáticamente y rápidamente,
crear la planificación optimizada de proyectos, sistemas de teleformación que trabajan
como el tutor humano en la formación del personal, programas de reconocimiento de
voz y reconocimiento de formas, lavadoras que automáticamente se adaptan a
condiciones diferentes de lavado, simuladores de hipotecas, sistemas automáticos de
decisión de inversiones, software predictivo de resultados financieros y necesidades de
personal en un negocio, sistemas de ayuda a la detección de fraude en créditos, sistemas
de consejos y noticias que personalizan sus respuestas y muchos más. Actualmente
todos estos ejemplos se encuadran en el término Inteligencia de Negocio (BI o Business
Intelligence). En general se refiere a la aplicación de cualquier sistema inteligente al
mundo de los negocios y las empresas, es decir, la gestión inteligente de procesos y
datos que ayuda a la toma de decisiones tácticas, optimizando los procesos de negocio,
y estratégicas, analizando los factores clave de los procesos de forma integrada.
Cuando se controla una realidad variada y compleja es necesario instalar una serie de
sensores (puntos de recogida de datos) que oportunamente monitorizados den una visión
del conjunto del sistema. También es necesario definir las reglas de operación,
establecer los parámetros a controlar, los valores límite, crear las estructuras lógicas que
generen los eventos y predisponer mecanismos que ejecuten las acciones necesarias en
cada caso. Para hacer todo esto nos ayuda la IA. Muchos sistemas que utilizamos
trabajan con IA sin saberlo, por ejemplo, el asistente de Microsoft Office [Waltz, 1997]
que manejan diariamente muchas personas en todo el mundo. Al menos, esto demuestra
que software que utiliza métodos de IA ya ha salida del ámbito investigador y
universitario.
Un gran problema para la toma de decisiones es la cantidad aplastante de
información que hay que manejar. La clave para las personas que tienen que decidir está
en ser capaz de examinar y aislar la información esencial para basar sus decisiones en
los parámetros vitales y hacerlas efectivas en el negocio. El mercado de hoy es tan
competitivo que las empresas deben considerar todas las posibilidades y utilizar todas
las ventajas que suponen los métodos de IA. Estos pueden ser usados satisfactoriamente
- 91 -
2. Situación actual y planteamiento del problema
como un instrumento para seleccionar, extraer y analizar las cantidades enormes de
información en nuestra sociedad, aprendiendo más sobre el entorno y los clientes y
conociendo los problemas antes de que ocurran.
Se finaliza esta introducción mostrando algunos ejemplo de aplicaciones de IA en el
entorno empresarial, en la tabla de la figura 2.27 basada en [Nordlander, 2001].
CAMPO
Producción
TIPO
Redes neuronales
Producción
Sistemas expertos
Producción
Algoritmos genéticos
Marketing
Redes neuronales
Negocios y
finanzas
Redes neuronales
FUNCIONES
Control de procesos
Aseguramiento de la calidad
Visión computacional
Previsiones de productos
Series temporales de las previsiones
Optimización de problemas
Simulación
Diagnóstico en ingeniería
Planificación de la capacidad
Diseño de sistemas
Control de calidad de los productos
Programación
Control de procesos
Rutinas de detección de defectos
Diagnóstico de causas de defectos
Pronósticos de calidad
Selección de materiales
Control de calidad
Estructuración del conocimiento
Optimización del diseño
Hardware evolutivo
Diseño de filtros digitales
Fusión de información desde múltiples sensores
Diseño aerodinámico
Pronóstico de moda
Planificación de distribución
Estrategias de promociones de venta
Demanda de productos de alimentación
Pronóstico de cuotas de mercado
Distribución de mercado
Distribución de correo
Simulación, predicción y evaluación de quiebras
Porcentajes de interés bancario
Porcentajes de cambio de moneda
Riesgos de hipotecas
Aplicación de créditos
Análisis de créditos
Optimización de problemas
Análisis de existencias de mercado
Pronósticos de existencias de mercado
- 92 -
2. Situación actual y planteamiento del problema
Negocios y
finanzas
Sistemas expertos
Negocios y
finanzas
Algoritmos genéticos
Consejero de carteras de acciones
Técnicas de negociación
Pronósticos de valores, monedas, etc.
Evaluación de créditos
Análisis de compañías
Avisos de inversión
Estructura de reglas fiscales
Políticas de precios
Análisis de competidores
Análisis de suministradores
Simulación de mercados de electricidad
Planificación detallada de problemas
Horarios
Modelos de crecimiento económico
Figura 2.27 Tabla de aplicaciones de IA en el ámbito empresarial
Gestión del conocimiento
La gestión del conocimiento se convierte en un argumento importante en las
empresas a partir de los años 90. La idea de fondo es que cada organización,
internamente, produce un saber original y distintivo que oportunamente utilizado puede
contribuir a su competitividad. De hecho, cualquier idea que surge en un área puede ser
factible en otra o serlo en un momento diferente. La importancia de reutilizar el saber de
la organización es tanto más importante en cuanto el ambiente en el que se mueve es
mudable y dinámico. Reutilizando y combinando soluciones existentes se puede dar
respuestas rápidas a los cambios. En este sentido los sistemas de gestión del
conocimiento intentan responder a tres necesidades fundamentales:
?
?
?
Convertir el saber en un recurso controlable;
Convertir el saber en un recurso reutilizable con el fin de maximizar las
oportunidades de su revalorización con el uso;
Convertir el saber en un recurso que pueda ser distribuido entre las personas con
el fin de maximizar las oportunidades de aprendizaje.
En general, estos sistemas centran su atención en la estandarización del saber que
puede convertirlo en controlable, reutilizable y compartido, es decir, en el desarrollo de
bases de datos de conocimiento. Desde esta perspectiva es posible comprender el modo
en que los modelos teóricos y tecnológicos de la IA se utilizan en los sistemas de
gestión del conocimiento [Fowler, 2000]:
?
Ontologías y, en general, tecnologías de ingeniería del conocimiento para la
representación y organización de grandes cantidades de información. La
- 93 -
2. Situación actual y planteamiento del problema
orientación de los sistemas de gestión del conocimiento basados en ontologías
son diversos. En el campo de los negocios, encontramos sistemas como
WebCADET [Caldwell y Clarkson, 2000] que es un sistema basado en la Web
para el soporte de decisiones aplicando un motor de inferencia a bases de datos
estructuradas ontológicamente que permite entender e integrar diversas fuentes
de información. El énfasis de WebCADET consiste en manejar un gran número
de parámetros (entradas y relaciones de la base de conocimientos) implicados en
el desarrollo de nuevos producto, en particular durante la fase de diseño
conceptual cuando errores tempranos pueden conducir a fracasos o desviaciones
sustanciales en el proceso posterior. Otro ejemplo puede ser Planet-Onto
[Domingue y Motta, 2000], que es un sistema desarrollado como administrador
inteligente de noticias en grupos de trabajo inter-institucionales. Esta
herramienta permite la formalización de documentos bajo una ontología y el
aumento de búsquedas estándar y de facilidades de búsqueda a través de una
recuperación deductiva del conocimiento. Además, la arquitectura PlanetOnto
incluye agentes inteligentes que proporcionan la inclusión personalizada de
noticias y alarmas y la identificación de noticias potencialmente interesantes
según las preferencias de los usuarios.
?
Instrumentos de Data Mining para la búsqueda clasificada y automática de
información y la extracción de la información relevante, el análisis sistemático y
periódico, que transforma los datos en información útil y manejable para la toma
de decisiones. Un ejemplo de utilización de estos sistemas es la compañía Dallas
Teachers Credit Union (DTCU) que usa el sistema IBM DB2 Intelligent Miner
que aplica técnicas de redes neuronales y técnicas estadísticas [Nicolussi y
Grontzki, 2005]. Este sistema utiliza datos demográficos y personales para
localizar cliente que deseen abrir cuentas corrientes y que cumplan las
condiciones que impone DTCU para convertirse en clientes. La compañía
considera que un 10% de los resultados obtenidos son consecuencia del uso de
este sistema.
Gestión de las relaciones con el cliente o CRM (Customer Relationship
Management)
CRM es básicamente la respuesta de la tecnología a la creciente necesidad de las
empresas de fortalecer las relaciones con sus clientes. Las herramientas de gestión de
relaciones con los clientes o CRM son las soluciones tecnológicas para conseguir
desarrollar la teoría del marketing relacional, que se define como la estrategia de
negocio centrada en anticipar, conocer y satisfacer las necesidades y los deseos
presentes y previsibles de los clientes.
- 94 -
2. Situación actual y planteamiento del problema
Habitualmente estos sistemas utilizan técnicas híbridas de inteligencia artificial,
fundamentalmente técnicas de minería de datos, redes neuronales y sistemas expertos.
Veamos algunos ejemplos:
?
El sistema VIRDIX de Trajecta combina técnicas de simulación y redes
neuronales para la realización de análisis de comportamiento de los clientes
[Nordlander, 2001]. Se ha aplicado con éxito en la Federal Express Corporation,
importante compañía de transporte, utilizando una gran base de conocimiento
sobre los clientes y un modelo predictivo que los clasificaba en segmentos según
su previsible comportamiento frente a cambios en su relación con la empresa.
?
En [Lozano y Fuentes, 2004] encontramos la aplicación de una metodología
basada en distintas técnicas de Inteligencia Artificial (redes neuronales, lógica
difusa, así como técnicas bio-inspiradas basadas en el comportamiento de las
hormigas) al proceso de toma de decisiones de la empresa en red. Primero se
consideran dos conjuntos referenciales en los que se incluye la muestra de
consumidores considerada de la que se obtendrá información y sus opiniones
acerca de una serie de cualidades deseables en el diseño de la página web de la
empresa. A continuación se desarrolla un modelo de simulación de visitas de los
clientes a la página web diseñada, observando el impacto en los indicadores
relevantes de decisiones, políticas, cambios de escenarios, etc. Después, con los
datos reales de acceso y su procesamiento en una red neuronal, el sistema puede
analizar las visitas que recibe en su página y entender en cierto modo, el
comportamiento y los requerimientos de los navegantes, para de ésta forma,
conseguir una personalización del estilo o contenido de su página web.
Finalmente se plantea una toma de decisiones a partir del empleo de
metodología difusa, conducente a la búsqueda de una óptima calidad en el
diseño de la página web a partir de los criterios de usabilidad, accesibilidad,
interactividad, importancia en los contenidos, y actualización de la página.
?
El sistema INTELEC de Quantrax Corp. es un sistema experto que ayuda a
determinar las condiciones particulares de cada cliente para la elección de la
tarjeta de crédito más conveniente y sus parámetros [Panczyk, 1999]. Se basa en
un motor de inferencia y una base de datos de reglas que aplica lógica fuzzy. En
[Kay, 2001] se presentan otros ejemplos de utilización de IA en la detección de
fraudes en tarjetas de crédito basándose en las desviaciones en los hábitos
comerciales de los clientes.
?
El sistema eServicePerformer de Firepond es un agente inteligente que utiliza
lógica fuzzy y técnicas de procesamiento de lenguaje natural [Nordlander,
2001]. Su objetivo es ayudar a responder a las preguntas de los clientes de una
manera más eficiente, ya sea a través del correo electrónico o la web, incluso en
- 95 -
2. Situación actual y planteamiento del problema
chats on-line. Aplica las técnicas ya mencionadas de IA para determinar el
responsable comercial adecuado a cada cliente según la zona y la disponibilidad,
la clase del mensaje por su contenido y urgencia y las respuestas exactas y
contextuales a las preguntas. En [Sloman y Logan, 1999] ya se considero la
utilidad de la aplicación de agentes inteligentes a la comunicación vía correo
electrónico.
?
El sistema Habitat-Pro, creado por la spin off Agents Inspired de un grupo de
investigación de la Universidad de Gerona (www.agentsinspired.com), que actúa
como un sistema experto en la personalización a partir de los gustos subjetivos
de los clientes. Se basa en agentes inteligentes para asociar indicadores o
atributos subjetivos a los productos y servicios que ofrecen, utilizando la IA para
crear modelos de los clientes y conocer sus preferencias. [Peña et alt., 2002]
define Habitat-Pro como una herramienta de personalización de contenidos y
prospección de mercados que utiliza técnicas de Razonamiento Basado en Casos
y Reglas de Lógica Difusa. La analiza y utiliza su arquitectura como base para el
desarrollo del sistema multiagente MAS-PLANG, realizado para transformar el
entorno educativo virtual de las USD (Unidades de Soporte a la Docencia) de la
Universidad de Gerona, en un sistema hipermedia adaptativo teniendo en cuenta
estilos de aprendizaje.
Control financiero
Las aplicaciones de control financiero siempre han sido las pioneras en los sistemas
de información empresarial y el centro informativo de los sistemas empresariales en el
que convergen datos del resto de aplicaciones. Consideramos aplicaciones financieras
aquellas relativas al control del capital, la inversión y los beneficios, por ejemplo las
asignaciones de créditos y la evaluación de préstamos e hipotecas en la banca, el cálculo
de primas en el mundo de los seguros y, en general, la detección de operaciones
financieras ilegales, el manejo de inversiones, la predicción de los valores de la cartera
bursátil, etc. A través de los años, se han utilizado diversas técnicas de IA para emular
la intervención humana en esta gestión y la gama de aplicaciones financieras donde
incide es cada vez más amplia [Coello y Castillo, 1999]. Las técnicas de IA más
utilizadas en este campo son las redes neuronales, los sistemas expertos, los algoritmos
genéticos y la lógica difusa. Una de las tendencias más marcadas en la actualidad es
mezclar diferentes técnicas en una misma aplicación, aprovechando las ventajas de cada
una, obteniendo sistemas híbridos. Analizaremos brevemente el uso de cada una de
ellas:
?
Redes neuronales. [Dutta y Secar, 1988] describen el uso de una red neuronal
para predecir la clasificación de los bonos de una empresa en base a sus riesgos
- 96 -
2. Situación actual y planteamiento del problema
posibles. Esta clasificación estima la capacidad de una compañía de poder pagar
estos bonos en el tiempo convenido, con la tasa de interés acordada.
Tradicionalmente, se han utilizado métodos de regresión estadística para tratar
de realizar estas predicciones, produciéndose resultados con una precisión del
60% en promedio. Esta red neuronal fue capaz de efectuar predicciones con una
precisión del 82%. Otro ejemplo es el sistema Cardholder Risk Identification
Service (CHRIS) utilizado por Visa Internacional como un sistema de detección
de fraudes que usa redes neuronales [Goonatilake, 1996]. La red neuronal
detecta actividades fraudulentas, comparando transacciones legales con casos
previos de fraude. En el campo de la determinación del precio de carteras de
valores tenemos dos ejemplos: los sistemas EAGLE12 y Neural Fair Value 20
Portfolio, ambos utilizan técnicas de redes neuronales y reconocimiento de
formas. El primero clasifica los valores en cinco categorías según el beneficio
que prevé en los casos de venta o compra [Williams, 2001]. El segundo
determina valores infravalorados y predice el momento de su máxima cotización
[STANDARD AND POOR, 2004].
?
Sistemas expertos. La empresa californiana Countrywide Funding usa un
sistema experto para evaluar sus hipotecas llamado CLUES. El sistema es capaz
de evaluar de una forma más eficiente que la utilizada tradicionalmente
[INTERTEK GROUP, 1995]. Tradicionalmente, el proceso de evaluación de
hipotecas manual tarda unos 50 minutos, el sistema CLUES entre 1 y 2 minutos.
Aunque inicialmente se evaluaron otras técnicas tales como las redes neuronales,
se optó por los sistemas expertos debido a su capacidad de explicar la forma en
que se llega a una cierta decisión. Si el sistema recomienda que se rechace una
cierta aplicación, la decisión final la debe tomar un evaluador humano, quien
verifica el proceso que siguió el programa para tomar esa decisión. Otro ejemplo
lo tenemos en el sistema iHex Discovery de Future Route que utiliza métodos
inductivos aplicados a una base de datos de reglas [Parson, 2004]. El sistema
puede traducir las reglas a lenguaje natural de forma que pueden ser fácilmente
consultables por los utilizadores del sistema. Se ha aplicado a la detección de
fraudes en el uso de tarjetas de crédito, aunque, también, se extiende a otros
ámbitos no financieros como medicina, biología y satélites.
?
Lógica difusa. [Cox, 1996] presenta un sistema de detección de fraudes en el
suministro de servicios de salud que usa lógica difusa. Este sistema se basa en la
detección de patrones anómalos de comportamiento usando reglas derivadas de
expertos humanos a las que la lógica difusa proporciona la flexibilidad
necesaria. Su objetivo es disminuir las pérdidas millonarias que se producen por
concepto de fraudes en el sector salud en los Estados Unidos. Según [McNeil y
Freiberger, 1993] el Fuji Bank, en Tokio, usaba un sistema que maneja lógica
difusa para efectuar transacciones con bonos a corto plazo, con, alrededor de 200
- 97 -
2. Situación actual y planteamiento del problema
reglas difusas que se basan en estrategias financieras de uso común que son
actualizadas regularmente por expertos humanos.
?
Sistemas híbridos. El sistema MonITARS (Monitoring Insider Trading and
Regulatory Surveillance) del London Stock Exchange de detección de fraudes,
que son sumamente difíciles de descubrir por medios manuales, usa una
combinación de algoritmos genéticos, lógica difusa y redes neuronales para
detectar transacciones sospechosas [Holder, 1994]. Un módulo usa una
combinación de técnicas estadísticas y redes neuronales para identificar
conductas inusuales en el mercado, en base a los perfiles de los individuos y
empresas que efectúan transacciones regularmente. Otro módulo, que utiliza
algoritmos genéticos y lógica difusa, se encarga de buscar patrones específicos
que puedan ser calificados como conductas sospechosas. Otro ejemplo lo
encontramos en el sistema SONAR (Securities Observation, News Analysis and
Regulation System), que monitorea el indicador bursátil NASDAQ, para ello
utiliza varias técnicas de IA como minería de datos, procesamiento del lenguaje
natural, arquitectura de agentes, inferencia a través de reglas y representación
del conocimiento [Goldberg et alt., 2003].
Gestión de la producción
La incorporación de agentes de decisión inteligente, redes neuronales, sistemas
expertos, algoritmos genéticos y autómatas programables para la optimización de
sistemas de producción es una tendencia activa en el ambiente industrial de países con
alto desarrollo tecnológico y con una gran inversión en investigación y desarrollo.
Dichos componentes de la IA tienen como función principal controlar de manera
independiente, y en coordinación con otros agentes, componentes industriales tales
como celdas de producción o ensamblaje, y operaciones de mantenimiento, entre otras.
Veamos algunos campos concretos de aplicación [Llata et alt., 2000]:
?
Sistemas de producción/ensamblaje más autónomos e inteligentes. Son
necesarios debido a las exigencias del mercado por obtener productos con
niveles muy altos de calidad, lo cual con operaciones manuales se hace
complicada. Su objetivo es coordinar las actividades de supervisión,
planificación, secuenciación, cooperación y ejecución de las tareas de operación
en centros de trabajo, agregando el control de los niveles de inventario y las
características de calidad necesarias.
?
Modelos de simulación para la optimización de sistemas de producción. Su
objetivo es obtener los parámetros óptimos para maximizar o minimizar cierta
función objetivo. Debido al auge de los algoritmos de búsqueda meta- 98 -
2. Situación actual y planteamiento del problema
heurísticos, se ha abierto un nuevo campo en el área de optimización con
simulación. Nuevos paquetes de software, tales como OptQuest (Optimal
Technologies), SIMRUNNER (Promodel Corporation) y Evolver (Palisade
Software), han salido al mercado brindando soluciones amigables de
optimización de sistemas que no requieren control interno sobre el modelo
construido, sino sobre los resultados que dicho modelo arroja bajo diferentes
condiciones.
?
Sistemas de diseño para el soporte a las decisiones basados en la optimización de
los parámetros de operación del sistema. Estos sistemas tienen una gran
incidencia directa en los procesos productivos. Un ejemplo de ellos son los
sistemas de aprendizaje por iteración (Reinforcement Learning) que son un
conjunto de técnicas diseñadas para dar solución a problemas cuya base son los
procesos de decisión markovianos. Los procesos markovianos son procesos
estocásticos de decisión que se basan en el concepto de que la acción a tomar en
un estado determinado, en un instante determinado, depende sólo del estado en
que se encuentre el sistema en el momento de tomar la decisión.
Sin embargo, la mayoría de las arquitecturas propuestas hasta el momento carecen de
un factor de integración fundamental. La comunicación entre los diversos niveles
jerárquicos de una planta de producción es muy poca, ya que cada función se limita a
conseguir su objetivo sin buscar una integración de toda la planta productiva.
Si estudiamos el uso de la IA por áreas dentro del proceso industrial de producción
encontramos como la IA puede ser aplicada a cada fase de la producción:
?
Fase de diseño. Dada la naturaleza creativa y abstracta de la disciplina de IA
puede tener un gran impacto en esta área. Todavía no es fácil sustituir
diseñadores humanos por máquinas, aunque ya hay algunas casos como el de la
máquina de la creatividad [IMAGINATION ENGINES, 2002], pero si es
habitual utilizar herramientas de IA que ayuden en el diseño, su redefinición y
sugieran modificaciones.
?
Fase de planificación. Continuación de la fase de diseño, esta fase realiza las
siguientes funciones: selección de materia prima o stock; selección de procesos
y secuencia de las máquinas de operación; selección de la máquina de operación;
funciones auxiliares (especificaciones, mediciones, etc.); selección de
parámetros de producción; generación de informes; salidas del proceso de
planificación. Un sistema experto ayuda en esta fase a la selección de todas las
posibles variantes, tales como el tipo de producción, la máquina operadora, la
materia prima, etc. optimizando el conjunto de todas ellas en función de
resultados y tiempos óptimos.
- 99 -
2. Situación actual y planteamiento del problema
?
Fase de fabricación. El uso de la IA permite simulaciones, reprogramación y
aprendizaje de las máquinas en base a experiencias pasadas. En esta fase los
sistemas expertos ayudan a resolver tres tipos de problemas:
1. Planificación de la capacidad para proporcionar los recursos necesarios.
2. Seguimiento de las fechas de entrega.
3. Optimización en la secuencia de los procedimientos de producción.
?
Control de calidad. Ayudan a controlar la calidad de forma más eficiente en las
áreas de test, evaluación e interpretación de datos.
?
Diagnosis. En esta área ha sido utilizada con éxito la IA, jugando un papel
importante en la supervisión de equipos complejos de producción y en la
localización de problemas con rapidez, reduciendo el tiempo total de producción
al encontrar y resolver errores y problemas rápidamente.
Sistemas ERP
La utilización sistemas inteligentes no está muy difundida en el entorno de los
sistemas ERP. Hemos podido encontrar trabajos de aplicación de procesos de decisión
lingüística [Herrera et alt., 2003] y lógica difusa [Sanchez et alt., 2005] para la
evaluación de la implantación de sistemas ERP, pero no aplicados al propio proceso de
implantación ni al uso funcional del sistema.
En estos trabajos se presentan modelos para evaluar la posibilidad de obtener unos
buenos resultados en la instalación de un sistema ERP en una compañía. Proponen un
esquema basado en la toma de decisiones que maneja información heterogénea, que
alimenta un modelo de evaluación de lógica difusa. Se utiliza un proceso de decisión
lingüística para manejar la información heterogénea transformándola en vectores
numéricos y lingüísticos. El proceso evalúa varios parámetros sobre las condiciones de
la compañía en ese momento, estos pueden ser de diferente naturaleza, cuantitativos y
cualitativos y el conocimiento sobre ellos puede ser vago o impreciso. Dichos
parámetros se han establecido de acuerdo a la opinión de los expertos y se han agrupado
en diferentes dominios de información. El modelo que proponen combina la
información heterogénea (numérica y lingüística) proporcionada por los expertos para
obtener una medida de la posibilidad de éxito de un proyecto de implantación de un
sistema ERP en la compañía. Este sistema proporciona una buena base de decisión
argumental, que se añade a las opiniones de expertos, para la acometida de un proyecto
tan importante, decisivo y costoso.
- 100 -
2. Situación actual y planteamiento del problema
Los parámetros utilizados son del tipo: inversión necesaria en tecnologías de la
información, precio de la implantación, urgencia de la implantación, interrelación con
otros subsistemas, capacidades del usuario para definir requisitos y especificar
necesidades, respuesta a los cambios del personal, competencia del proveedor
seleccionado y capacidad de influencia de la compañía en el proveedor. Al finalizar el
proceso a cada uno de ellos se le calcula un valor y se le asigna un peso que debe
determinar la compañía, combinándose ambos hasta obtener una puntuación final. La
puntuación se compara con una tabla preestablecida de posibles valores asociados a
previsiones en el resultado del proyecto de implantación.
- 101 -
2. Situación actual y planteamiento del problema
2.3. CONCLUSIONES
Las empresas se encuentran ante la necesidad de adoptar un modelo productivo y
organizativo que les permita adaptarse a las oscilaciones, cada vez más frecuentes, de la
demanda de los mercados y a la agilidad y flexibilidad requeridas. Paralelamente a la
evolución de los mercados se perfila una explosión de la cantidad de información que se
debe manejar y su rápida mutación y difusión a través de sistemas informáticos y redes.
Nace, por tanto, la exigencia de gestionar la información en un modo racional y
orgánico, rediseñando los flujos informativos que interesan a toda la organización y
definiendo nuevos modelos de negocio. Consecuencia directa de estos cambios es la
difusión de los ERP (Enterprise Resource Planning), sistemas informáticos que integran
la planificación estratégica y operativa, gestionando el flujo de trabajo empresarial.
La necesaria flexibilidad y adaptabilidad empresarial conduce a la posible definición
y uso de distintas estrategias empresariales, distintos modelos de explicación,
pronóstico y decisión unidos a métodos de planificación, dirección y control, aplicables
a distintas situaciones. Esta situación conduce a la clasificación de las empresas en base
a distintos factores que pueden influir en su estrategia empresarial y determinar su flujo
de trabajo. Es decir, la elección de una taxonomía empresarial que ayude a definir sus
procesos adaptados a los distintos tipos de problemas y situaciones, será condición
necesaria para el éxito.
La personalización de los flujos de trabajo se impone en cualquier sistema de gestión
empresarial. Los ERP no se quedan al margen y proporcionan la posibilidad de
configuración o personalización del sistema. Esta permite obtener una mayor eficiencia
del sistema, garantizando la coherencia de los datos y permitiendo un crecimiento
continuo del mismo mediante la publicación de sucesivas versiones totalmente
compatibles con las precedentes. Los sistemas ERP proporcionan así una vasta gama de
elecciones estratégicas y de posibilidad de personalización superando la rigidez de
sistemas precedentes y garantizando, además, mejores resultados de negocio y menores
costes de mantenimiento y actualización.
Nos encontramos con que los sistemas ERP son caros, complejos y notoriamente
difíciles de implantar. Para instalar y parametrizar correctamente el sistema, se suele
requerir de la ayuda de integradores expertos, tanto del sistema como del
funcionamiento y estrategia de la empresa utilizadora del mismo. Todas las actividades
relacionadas con la parametrización constituyen el núcleo central de la implantación de
un sistema ERP y de ella depende que la propia integración del sistema y sus beneficios
puedan perderse. Toda la información necesaria para llevar a buen puerto este proceso
- 102 -
2. Situación actual y planteamiento del problema
se encuentra fragmentada, dado su extensión y atomización, entre distintos expertos.
Por lo tanto, se hacen necesarios métodos, modelos, arquitecturas y herramientas que
ayuden en esta tarea ya que ellos pueden conducir a reducir los costes y a la vez
incrementar la aceptación del ERP por parte de los usuarios y el éxito de su
implantación.
Una óptima solución al problema planteado pasaría por diseñar un sistema que guiara
la parametrización de los ERP de forma inteligente, evitando la probabilidad de errores
y diminuyendo el tiempo de implantación. Para poder cumplir este objetivo hemos
estudiado diferentes sistemas inteligentes que se utilizan o se dirigen al ámbito
empresarial, en el que se encuadran los sistemas ERP.
Los primeros usos de la IA en las empresas se centran en la robótica y su uso
industrial. Hay que esperar a finales de los años 90 para ver como, en solitario o
combinadas con aplicaciones software convencionales, las técnicas de inteligencia
artificial se utilizan en las áreas de gestión empresarial en lo que se denomina
Inteligencia de Negocio (BI o Business Intelligence). Las técnicas de IA más
ampliamente utilizadas en este campo son las redes neuronales, los sistemas expertos,
los instrumentos de Data Mining, las ontologías y la lógica difusa. Una de las
tendencias más marcadas en la actualidad es el mezclar diferentes técnicas en una
misma aplicación, aprovechando las ventajas de cada una, obteniendo sistemas híbridos.
Hemos analizados diferentes sistemas y entornos de aplicación pero no hemos
encontrado ninguno que se utilice en el ámbito de los ERP ni, en general, en la
parametrización de sistemas informáticos. Solo hemos detectado estudios de aplicación
de procesos de decisión lingüística y de lógica difusa para la evaluación de las
posibilidades de éxito en implantaciones de sistemas ERP, pero no aplicados al propio
proceso de implantación ni a la utilización funcional del sistema.
De entre los diferentes tipos de sistemas inteligentes nos hemos acercado a los
Sistema Basado en el Conocimiento por sus fundamentos. Su principal característica es
el potente cuerpo de conocimientos que acumulan y como diferencian entre los
conocimientos sobre el problema y los conocimientos sobre como resolver el problema.
Para que se comporten inteligentemente, además de poseer conocimientos fieles a la
realidad deben ser capaces de utilizarlos eficientemente al realizar inferencias. Los
sistemas basados en reglas son los más comúnmente utilizados para realizar estas
inferencias. Su simplicidad y similitud con el razonamiento humano, han contribuido a
su popularidad en diferentes dominios. Estas características y su arquitectura básica
serán tenidas en cuenta para la construcción de un módulo con capacidad de asistencia
inteligente para la parametrización en el marco de los sistemas ERP.
Dentro de los Sistemas Basados en el Conocimiento hemos analizados los IHS o
Sistemas de Ayuda Inteligente y los ITS o Sistemas Inteligentes de Tutorización. Los
- 103 -
2. Situación actual y planteamiento del problema
primeros son sistemas que se utilizan para proporcionar ayuda a los usuarios en sus
tareas, en concreto hemos estudiado los sistemas dedicados a la ayuda de aplicaciones
informáticas debido a que nuestro trabajo se enmarca en un tipo especial de aplicaciones
informáticas, los ERP y su objetivo último es ayudar a los usuarios y consultores en una
de sus funciones, la parametrización del sistema. Los segundos, ITS, son sistemas que
se encuadran dentro de los sistemas inteligentes para la educación cuyo objetivo es
guiar y facilitar al alumno el proceso formativo. Son interesantes, y así lo hemos
destacado, algunos aspectos de estos sistemas, como la utilización de reglas y redes
semánticas para almacenar el conocimiento, la existencia de ITS orientados al
conocimiento procedimental y al uso del principio educativo ‘enseñar haciendo’ y su
función de tutor virtual, es decir, de guía durante todo un proceso, seleccionando, en
función de las preferencias y objetivos del alumno los caminos por los que debe
moverse dentro del proceso educativo. Estas características dan un valor añadido a los
ITS y resultan útiles en el desarrollo y los requisitos de nuestro trabajo, que va más allá
de una simple ayuda, sino que pretende guiar durante todo el proceso de
parametrización del ERP, aconsejando y eligiendo opciones según las preferencias de
los usuarios y consultores del ERP. Realmente los ITS tienen unas exigencias muy
amplias, en este sentido, podemos considerar los IHS como ITS más sencillos, con los
que es posible lograr parte de los objetivos pedagógicos perseguidos por un tutor,
teniendo unas características menos exigentes. Después de analizar estos dos tipos de
SBC se puede concluir que la ayuda y la enseñanza son dos partes de un mismo
proceso, siendo la ayuda una enseñanza con un objetivo muy claro de resolución de un
problema concreto.
Los dos sistemas estudiados, IHS e ITS, presentan otras semejanzas y diferencias.
Comparando su arquitectura (figuras 2.25 y 2.26) vemos que los ITS se refieren al
estudiante o el alumno como utilizador, que podría considerarse una especialización del
término usuario utilizado por los IHS. La conexión con los utilizadores en sentido
amplio se realiza en ambos sistemas a través de un interfaz, que debe ser interactivo y
proporcionar facilidad de uso. Además encontramos dos módulos idénticos o
asimilables, el del dominio (conocimientos) y el del utilizador (estudiante o usuario) que
permiten ayudar o guiar de forma personalizada a través del conocimiento almacenado.
La diferencia surge en el módulo del tutor de los ITS, que no tiene correspondencia en
los IHS. Este módulo proporciona el valor añadido.
El sistema objeto de este trabajo debería tener una arquitectura parecida a los
sistemas estudiados: una interfaz interactiva y amigable con el usuario, un módulo
estructurado de conocimientos procedimentales, un módulo del usuario que permita
tratamientos personalizados y un modulo similar al del tutor, en los ITS, que guíe de
forma inteligente a través de los conocimientos procedimentales, el proceso de
parametrización de los sistemas ERP. Por otro lado la mayor parte del trabajo requerido
para construir sistemas inteligentes, está basado en el desarrollo de adecuadas
- 104 -
2. Situación actual y planteamiento del problema
representaciones de conocimiento y sus correspondientes estrategias de manipulación.
No se puede manipular conocimiento a menos que esté adecuadamente representado. Es
parte fundamental de este trabajo utilizar una metodología de creación, almacenamiento
y utilización de conocimiento procedimental, que es aquel conocimiento compilado que
se refiere a la forma de realizar una cierta tarea (el saber como hacerlo). Hemos visto
como distintos ITS utilizan metodologías y formas de representación del conocimiento
que pueden servir de base a esta tarea: reglas de producción y redes semánticas en los
prototipos TOTS, STEVE, PAT y PACO y en el sistema SITA.
Respecto a las clasificaciones estudiadas de los SBC, para los tipos de sistemas
analizados podemos determinar que:
?
Según la clasificación de [Sheel, 1990] y [Hickman et alt. 1989] que se basa en
la función que el sistema realiza o su propósito, mientras que los IHS se pueden
encuadran en sistemas de diagnóstico y de monitorización, es decir, sistemas que
detectan las causa de errores o malfuncionamiento (diagnóstico) o sistemas que
controlan el estado de un proceso en ejecución y lo comparan con el estado
esperado detectando las desviaciones y sugiriendo correcciones
(monitorización), los ITS pueden ser considerados sistemas de monitorización,
al igual que los IHS, y de planificación, es decir, sistemas que determinan las
acciones a tomar para alcanzar un objetivo. En el caso objeto de este trabajo, el
sistema resultante de parametrización será de tipo planificación, al igual que los
ITS, ya que determinará acciones que deben ejecutarse para conseguir la
parametrización del ERP según las particularidades de la organización concreta
indicadas por usuarios y consultores.
?
Según la clasificación de [Guida y Tasso, 1994] que se basa en el papel que
realiza el sistemas en el entorno en términos de responsabilidades y tareas,
mientras que los IHS pueden definirse como sistemas de soporte, es decir, que
ayudan al usuario en su toma de decisiones pero no lo reemplaza, los ITS son
sistemas prescriptivos o, lo que es lo mismo, sistemas que dirigen al usuario en
la ejecución de una tarea o en la toma de decisiones. Debemos considerar que el
sistema resultante de este trabajo debe compartir responsabilidad con el usuario
y consultor del ERP en su tarea de parametrización, como los ITS, y no
solamente ayudarle, como los IHS, el sistema dirigirá y controlara con la
participación del utilizador del ERP.
Para concluir, hemos visto como nuestra propuesta tiene muchas similitudes con los
ITS, más que con los IHS, sistemas que parecían encajar por su objetivo (ayuda en el
uso de aplicaciones informáticas). Por otro lado los sistemas ITS tiene algunas carencias
en confronto con el objetivo de este trabajo: se encuadran solamente en el ámbito de la
educación, que no corresponde al de este trabajo; el conocimiento se refiere a conceptos
- 105 -
2. Situación actual y planteamiento del problema
de un área específica, no a acciones, sus consecuencias, sus implicaciones y relaciones y
sus prerrequisitos; el modulo tutor realiza funciones de supervisión y evaluación, esta
última no necesaria en nuestro sistemas, en cambio si es necesaria una función de
ayuda, como la proporcionada por los IHS, durante la toma de decisiones y de dirección
o preselección de posibilidades por parte del sistema. Por lo tanto, podemos deducir que
estos sistemas funcionan para dominios muy restringidos, pero podemos utilizar su
arquitectura aplicándola a un área totalmente distinta, la parametrización de sistemas
ERP particularizada para cada organización y su propia estrategia empresarial.
- 106 -
3 PROPUESTA ARQUITECTURAL Y
METODOLÓGICA
En el capítulo anterior hemos descrito el entorno de los sistemas ERP y la
problemática de la parametrización de dichos sistemas, en concreto la importancia de la
estrategia empresarial en este contexto. También analizamos la situación actual relativa
a los sistemas inteligentes aplicados a la gestión empresarial y en concreto los Sistemas
Basados en el Conocimiento, los Sistemas de Ayuda inteligente y los Sistemas de
Inteligentes de Tutorización. Como respuesta a la problemática de la parametrización de
los sistemas ERP vamos a plantear una solución basada en un sistemas inteligente que
mitigue las carencias encontradas en el uso de dichos sistemas en el ámbito de este
trabajo.
En primer lugar desarrollaremos la estructura del sistema propuesto, realizando una
propuesta arquitectural que presente los distintos módulos que componen el sistema, sus
funciones, las relaciones y conexiones entre ellos y la información que contienen y que
intercambian. En resumen, explicaremos que hace el sistema inteligente propuesto.
A continuación expondremos como el sistema realiza sus objetivos estableciendo una
propuesta metodológica que detalle las bases teóricas y prácticas con las que trabaja el
sistema y la justificación de su uso. En concreto desarrollaremos una taxonomía
empresarial utilizando una de las analizadas en el capítulo anterior, describiremos la
técnica elegida para el modelado de procesos comparándola con las existentes, la
utilización de las reglas de producción en redes semánticas y su representación y las
métricas de calidad utilizadas en la implantación de sistemas ERP que puedan
ayudarnos a retroalimentar el sistema.
Finalmente detallaremos las fases metodológicas a desarrollar para dotar de
contenido a los distintos módulos que forman la arquitectura: la obtención y
- 107 -
3. Propuesta arquitectural y metodológica
formalización de la base de conocimientos del dominio, de métricas de calidad y de
usuarios, sus planes y estrategias. En concreto definiremos la formalización de la
información y su validación utilizando herramientas y estándares muy extendidos, como
la técnica EPC, el lenguaje XML y las herramientas CASE y ARIS.
- 108 -
3. Propuesta arquitectural y metodológica
3.1. PROPUESTA ARQUITECTURAL
Como introducción a la propuesta arquitectural vamos a describir la definición,
características y objetivos que debe cumplir una arquitectura de sistemas software. No
existe una definición exacta de este concepto, pero entre las aceptadas por los expertos
podemos destacar la siguiente por su simplicidad y exactitud: “una arquitectura es la
abstracción de la especificación de un sistema consistente en la descripción de sus
componentes funcionales en términos de comportamiento e interconexiones entre ellos”
?Hayes-Roth, 1994]. Esta definición será la base utilizada para la propuesta arquitectural
de este trabajo, es decir nuestra arquitectura debe describir de forma abstracta las partes
de un todo hasta llegar a comprender sus principios o elementos, detallando las
condiciones o capacidades que debe cumplir o poseer un sistema y cada uno de sus
elementos y describiendo el funcionamiento del sistema y de cada componente en
términos de comportamiento propio y relaciones con otros componentes.
Esta definición, además, nos obliga a determinar muy claramente los módulos que
componen el sistema, su propia función, y como esta contribuye a la funcionalidad
global, y sus relaciones con otros módulos. Para ello será necesario describir los
módulos como dos partes diferenciadas:
? La interfaz, que es la parte del elemento que es visible a los otros elementos.
Especifica precisamente las características del elemento que los otros elementos
necesitan conocer y se expresa como información recibida y enviada y el
elemento origen y destino de esta.
? El cuerpo del elemento, que no es visible a los otros. Todas las decisiones sobre
como conseguir el propósito del elemento, están ocultas al resto en esta parte. El
cuerpo de un elemento se puede cambiar libremente siempre y cuando se
mantenga consistente con su interfaz.
Podemos comprobar como otras definiciones clásicas comparten el significado de
arquitectura utilizado en este trabajo. Por ejemplo para Booch, Rumbaugh, y Jacobson
[Booch et alt., 1999] la arquitectura es el conjunto de decisiones significativas acerca de
la organización de un sistema, la selección de sus elementos estructurales y las
interfaces que componen el sistema, junto con la colaboración entre los elementos
estructurales y la descomposición en subsistemas según el funcionamiento de estos
elementos. En concreto para los sistemas software [Shaw et alt., 1996] establece
distintos puntos de vistas que deben quedar reflejados en su arquitectura:
- 109 -
3. Propuesta arquitectural y metodológica
? Modelo estructural, todos los sistemas software están compuestos de
componentes y relaciones entre los componentes, más algunos otros aspectos
que incluyen: configuración, estilo, requisitos, semántica, análisis y propiedades.
? Modelo de entorno de trabajo, es similar al modelo estructural pero enfatiza la
coherencia del sistema completo en oposición a la definición de los
componentes singulares.
? Modelo dinámico, que se refiere a la calidad del sistema, entendiendo por
dinámico la posibilidad de cambios en la configuración del sistema.
? Modelo de procesos, centra la atención en la construcción de la arquitectura y
los pasos o procesos involucrados en esa construcción.
Una vez vista la definición de una arquitectura veamos las características que debe
cumplir para garantizar su calidad. Según Joe Batman del Software Engineering
Institute en [Batman, 1999] las características que debe cumplir una arquitectura
efectiva son los siguientes:
? Debe ser reutilizable y exportable, para lo cual debe cubrir los requerimientos
del entero dominio.
? Debe ser compacta, es decir debe ser lo suficientemente flexible para adaptarse
sin comprometer la integridad conceptual.
? Debe tener un alto nivel de abstracción.
? Debe estar bien documentada, de forma clara y no ambigua.
Analizando una a una estas características podemos deducir las propiedades que debe
cumplir nuestra arquitectura:
? Reutilizable y exportable. Debe dar la posibilidad de utilización con distintas
tecnologías y ser portable a través de múltiples plataformas Debe representar
todos los posibles casos de uso. Esto garantiza que la estructura representada por
la arquitectura responda a todos los requerimientos funcionales.
? Compacta y flexible. Debe tener facilidad de mantenimiento, es decir, capacidad
de evolución según el cambio en las necesidades y requisitos. Debe poder
utilizarse para la construcción de sistemas de distinto tamaño y complejidad.
- 110 -
3. Propuesta arquitectural y metodológica
Debe reflejar las relaciones del sistema con otros sistemas, con personas o con
cualquier interlocutor externo y los componentes del sistema que se encargan de
las relaciones externas al mismo.
? Abstracta. Debe representar un punto de vista elevado de los sistemas que revele
su estructura, pero esconder todos los detalles de implementación. Su
modularidad o descomposición jerárquica debe permitir describir los sistemas
según diferentes niveles de detalle, por ejemplo poder representar estructuras
complejas como un único componente del sistema. No debe incorporar
procedimientos de realización de la arquitectura: algoritmos ni estructuras de
datos.
? Bien documentada. Debe poseer unas especificaciones comprensibles que
puedan ser utilizadas por los distintos componentes de los proyectos a que de
lugar y en distintos niveles de abstracción. Debe poder proporcionar información
sobre la gestión de la configuración, control de cambios y versiones.
Finalmente, conociendo la definición y características que debe cumplir nuestra
arquitectura, detallaremos los objetivos que queremos conseguir con su diseño:
? En primer lugar la arquitectura debe proporcionar una visión global del sistema
y de sus relaciones con agentes externos al mismo.
? Proporcionar información clara y comprensible sobre los que hace el sistema, los
componentes del mismo, la función de cada uno de ellos y sus interconexiones.
? Posibilitar distintos niveles de abstracción explotando los módulos del sistema
en otros diseños arquitecturales que contengan submódulos con sus funciones y
sus relaciones, proporcionando una estructura jerárquica si es necesario.
? Proporcionar información sobre la forma de obtención del diseño arquitectónico,
sus fundamentos y sus relaciones con otras arquitecturas estándar.
? Definir una nomenclatura propia o adaptada que permita una identificación clara
de sus componentes y establecer un estilo de diseño que proporcione
uniformidad en su presentación.
? Identificar de forma separada las funciones propias de cada componente y la
información que recibe y que envía a otros componentes o agentes externos.
- 111 -
3. Propuesta arquitectural y metodológica
Esta información debe estar relacionada indicando las necesidades externas de
información de cada función.
? Proporcionar un plan prescriptivo que guíe en el establecimiento de los objetivos
de las fases metodológicas y en la selección de las bases teóricas y las
herramientas necesarias para su desarrollo.
Una vez establecidos los objetivos de nuestra arquitectura, cumpliremos el primero
de ellos proporcionando una visión global del sistema y sus relaciones con agentes
externos al mismo. La figura 3.1 muestra este primer nivel arquitectural.
Usuario
Asistente inteligente
para la parametrización
de sistemas ERP
ERP
Figura 3.1 Nivel 1 de la arquitectura del Asistente Inteligente
Esta arquitectura debe proporcionar las guías para la construcción de sistemas que
sean una síntesis de los actuales módulos de parametrización de los sistemas ERP y de
los Sistemas Basados en el Conocimientos, en particular de los Asistentes inteligentes y
de los Sistemas de Ayuda Inteligentes, así como una base para la definición de una
metodología de creación de contenidos procedimentales soportados por dicha
arquitectura. En este nivel arquitectural debemos primero definir las funciones globales
del Asistente Inteligente.
Su función principal es dotar de cierta inteligencia el proceso de parametrización de
los sistemas ERP, evitando la probabilidad de errores y diminuyendo el tiempo de
implantación. Para ello debe disponer de un interfaz de comunicación con los
utilizadores del sistema, un motor de inferencia que coordine, como un todo, las
acciones que el sistema debe realizar, y que se comunique con el propio sistema ERP,
con el conocimiento sobre el dominio, es decir, sobre los procesos a parametrizar y la
forma de hacerlo y con el perfil del usuario o utilizador del sistema ERP, que debe
proporcionar información sobre las decisiones estratégicas empresariales que influyan
- 112 -
3. Propuesta arquitectural y metodológica
en la parametrización del sistema y sobre las preferencias y la situación actual del
usuario. Finalmente debe ser capaz de ayudar a mejorar el rendimiento del sistema ERP,
ya hemos visto en el capítulo 2 que sus resultados están íntimamente ligados a su
parametrización. Para realizar esto necesita un proceso de calidad que mida la situación
actual y retroalimente al sistema para guiar al usuario en la modificación de la
parametrización.
El Asistente Inteligente tiene relaciones con dos agentes externos al mismo, el
usuario y el sistema ERP que va a parametrizar. El proceso de parametrización de un
ERP requiere dedicación de un equipo de trabajo que deberá estar integrado por los
líderes empresariales y por expertos consultores ERP, estos serán los potenciales
usuarios finales del sistema, pero con la ayuda del asistente todo el conocimiento
fragmentado que debe poseer el grupo de trabajo está representado en el conocimiento
sobre el dominio y sobre el usuario y la función de parametrización mediante el
asistente resulta más sencilla ya que este comparte la responsabilidad con el usuario y
consultor del ERP en su tarea de parametrización y no solamente lo ayuda. El asistente
dirigirá y controlara con la participación del utilizador del ERP, por tanto la
comunicación entre ambos será bidireccional.
El otro agente externo con el que el asistente se comunica es el propio sistema ERP a
parametrizar. En este caso la relación también es bidireccional, ya que el asistente
proporciona al ERP sus parámetros y el ERP debe enviar información sobre su situación
actual en cuanto a rendimiento y resultados empresariales para ayudar al asistente en su
tarea de retroalimentación y mejora continua.
Una vez presentado el primer nivel arquitectural descompondremos este en un
segundo nivel en el que se representan sus componentes y sus relaciones. La figura 3.2
muestra el segundo nivel arquitectural. Con esto cumplimos otro de los objetivos de
nuestra arquitectura: posibilitar distintos niveles de abstracción.
- 113 -
3. Propuesta arquitectural y metodológica
Módulo de
parametrización
Usuario
Módulo del
dominio
Interfaz
Módulo de
calidad
Módulo de
usuario
ERP
Figura 3.2 Nivel 2 de la arquitectura del Asistente Inteligente
Con este diseño arquitectónico hemos establecido los componentes del sistema y sus
interconexiones, posteriormente detallaremos las funciones de cada uno de ellos.
Además hemos definido una nomenclatura, basada en los sistemas inteligentes
analizados, IHS o Sistemas de Ayuda Inteligente e ITS o Sistemas Inteligentes de
Tutorización, que permite una identificación clara de sus componentes y un estilo de
diseño que proporciona uniformidad en la representación. Antes de pasar a detallar cada
componente vamos a determinar la forma de obtención del diseño arquitectónico, sus
fundamentos y sus relaciones con otras arquitecturas estándar.
Inicialmente nuestra arquitectura parte la arquitectura general de los Sistemas
Basados en el Conocimiento (vista en el capitulo 2, figura 2.23). En dicha arquitectura
se presentan los siguientes componentes:
?
Base del conocimiento que contiene la información sobre el dominio de
conocimientos que debe poseer el sistema para realizar sus deducciones dentro
de su competencia. Implica la representación formal de la estructura del
conocimiento del sistema. Puede contener conocimiento declarativo (hechos) y
procedimental (relaciones). En la arquitectura propuesta este componente
corresponde al módulo del dominio.
?
Modelo situacional que contiene información sobre el problema a resolver y el
estado del sistema a lo largo del proceso de inferencia. Finalmente contendrá la
representación de los hechos para el caso o consulta concreta que se ha
ejecutado. Corresponde en la arquitectura propuesta con el módulo de usuario
- 114 -
3. Propuesta arquitectural y metodológica
que mantiene información sobre el usuario utilizador del sistema ERP, sus
preferencias y su situación actual de parametrización respecto a diferentes
procesos de negocio. Dentro de este modelo podría incluirse, también el módulo
de calidad, aunque los SBC no presentan esta característica, que es una novedad
de este trabajo de investigación. Su inclusión en este modelo responde a su
significado, ya que contiene información sobre la situación real del usuario y los
parámetros del ERP y procesos de negocio susceptibles de mejora.
?
Motor de inferencia que refleja el razonamiento del experto en el dominio,
maneja los conocimientos de la base de conocimientos y del modelo situacional,
actualizando este según se desarrolla la inferencia, y coordinan las acciones que
el sistema debe realizar. En nuestra arquitectura este modelo corresponde con el
módulo de parametrización que es el que realiza todas estas funciones, además
es el encargado de dirigir al usuario en el proceso de mejora de la calidad.
?
Unidad de entrada/salida que es el medio por el que el usuario, y otros sistemas
se comunican con el SBC. La comunicación se puede establecer con el motor de
inferencia o con las bases de datos, tanto de conocimiento como el modelo
situacional. Este módulo realiza varias funciones: explica los pasos realizados
para llegar a las conclusiones, actualiza la base de conocimiento a través del
experto y permite al usuario introducir información sobre su problema y obtener
la solución. En la arquitectura propuesta este componente correspondería con la
interfaz pero con algunas diferencias. La comunicación con el usuario para el
intercambio de información sobre el problema y la solución y para la
justificación de la solución se realiza siempre a través del interfaz pero con el
procedimiento indicado por el módulo de parametrización, similar a la
arquitectura de los ITS con la que nos compararemos más adelante. Esto
significa que no hay comunicación directa entre el usuario y los módulos de
calidad, de usuario y del dominio. Por tanto, la interfaz de comunicación
relaciona al usuario con el módulo de parametrización de manera bidireccional.
Veremos como esta arquitectura se soporta metodológicamente con la creación
del proceso de adquisición del conocimiento que incluye técnicas de extracción
del conocimiento y de modelado. Además se incluye una nueva comunicación
con el sistema ERP en la que se relaciona este sistema con el módulo de
parametrización directamente lo que permite su parametrización automática.
Existe, en nuestra arquitectura una comunicación directa entre el sistema ERP y
el módulo de calidad que debe proporcionar a este la situación actual del sistema
respecto a las métricas de calidad establecidas, este proceso no forma parte del
habitual en los SBC y es una novedad en la arquitectura, se justifica su exclusión
de la vía de comunicación a través del interfaz por su direccionamiento, hacia el
módulo de calidad no al de parametrización, y por su frecuencia diferente al de
resto de interacciones.
- 115 -
3. Propuesta arquitectural y metodológica
Respecto a los SBC específicos estudiados en el capítulo 2 por su semejanza en
cuanto a entorno y objetivos con nuestra propuesta de trabajo, comparando su
arquitectura (figuras 2.25 y 2.26 del capítulo 2) vemos que los ITS se refieren al
estudiante o el alumno como utilizador, que podría considerarse una especialización del
término usuario utilizado por los IHS y corresponder exactamente con el agente externo
usuario de nuestra arquitectura. La conexión con los utilizadores en sentido amplio se
realiza en ambos sistemas a través de un interfaz, que debe ser interactivo y
proporcionar facilidad de uso, condición presenta también en nuestra arquitectura.
Además encontramos dos módulos idénticos o asimilables, el del dominio
(conocimientos) y el del utilizador (estudiante o usuario) que permiten ayudar o guiar de
forma personalizada a través del conocimiento almacenado. Ambos componentes
también son asimilables con los propuestos en este trabajo como módulo de usuario y
módulo del dominio. La diferencia surge en el módulo del tutor de los ITS, que no tiene
correspondencia en los IHS. Este módulo proporciona el valor añadido y es el
correspondiente al módulo de parametrización de nuestra arquitectura.
También vimos en el capítulo 2 como utilizando dos de las clasificaciones estudiadas
de los SBC según la función o el propósito y el papel del sistema en términos de
responsabilidades y tareas, nuestra propuesta de investigación se acercaba más a los
ITS, ya que se puede definir, al igual que los ITS, como de planificación (sistemas que
determinan las acciones a tomar para alcanzar un objetivo) y prescriptivos (sistemas que
dirigen al usuario en la ejecución de una tarea o en la toma de decisiones). Por tanto
compararemos la arquitectura general de los ITS presentada en la figura 2.26 del
capítulo 2. Esta arquitectura se compone de los siguientes elementos:
?
Módulo del tutor que simula la acción real de un tutor humano decidiendo los
contenidos que debe presentar y la forma de hacerlo. Es asimilable al módulo de
parametrización que realiza la función de guía del usuario a través de la
parametrización del sistema, igualmente decide la parte a parametrizar y como
presentarla al usuario. En cuanto a las funciones de evaluación y supervisión del
ITS no están directamente reflejadas en nuestra arquitectura, ya que son
específicas del proceso de aprendizaje, ámbito de los ITS. Además se incluye
una nueva relación no presente en los ITS, esta relación conecta directamente el
módulo de parametrización con el sistema ERP lo que permite su
parametrización automática.
?
Interfaz que permite una interactividad real entre el estudiante y el sistema, en
concreto entre el estudiante y el módulo del tutor. En nuestra arquitectura esta
estructura se repite asimilando el modulo del tutor de los ITS con el de
parametrización de nuestra propuesta.
- 116 -
3. Propuesta arquitectural y metodológica
?
Módulo del dominio que mantiene organizada la información sobre los
conceptos y el conocimiento que se va a enseñar. En nuestra arquitectura tiene
una correspondencia directa, aunque los contenidos representados y su
formalización no se refieren a conceptos de un área específica, como en los ITS,
sino a acciones, sus consecuencias, sus implicaciones y relaciones y sus
prerrequisitos.
?
Módulo del alumno que registra la situación de los alumnos. Es asimilable con el
módulo del usuario en nuestra arquitectura. Igualmente mantiene información
sobre el usuario del sistema ERP, su situación actual de parametrización e,
incluso, sus deseos futuros, dentro de la función de calidad para la mejora
continua. En nuestro trabajo la relación de este módulo con el de
parametrización es bidireccional ya que la situación del usuario puede cambiar
durante el proceso del asistente, que es guiado por el módulo de
parametrización.
Además nuestra arquitectura presenta la novedad de la retroalimentación para la
mejora continua que no es asimilable a ninguno de estos componentes, aunque está muy
relacionada con el módulo del alumno en cuanto a estilo de aprendizaje del alumno, en
nuestro caso, estrategia empresarial del usuario y con la B.D. de Planes de los IHS en
cuanto que esta contiene los deseos, planes de parametrización y habilidades que
pretende alcanzar el usuario y la nuestra los beneficios de negocio esperados medidos
en parámetros del ERP. Esta funcionalidad se representa a través del módulo de calidad
y sus relaciones, que no tiene equivalente en las arquitecturas estándar estudiadas.
Veremos a continuación cada uno de los módulos propuestos, sus funciones y sus
relaciones con otros módulos lo que nos permitirá cumplir con el resto de los objetivos
planteados para el desarrollo de esta arquitectura: identificar de forma separada las
funciones propias de cada componente y la información que recibe y que envía a otros
componentes o agentes externos y proporcionar un plan prescriptivo que guíe en el
establecimiento de los objetivos de las fases metodológicas y en la selección de las
bases teóricas y las herramientas necesarias para su desarrollo.
Para realizar esta tarea vamos a utilizar la metodología establecida por IEEE en el
estándar para el desarrollo de arquitecturas de sistemas de educación, enseñanza y
entrenamiento [IEEE, 2001]. El propósito de este estándar es describir y entender los
componentes identificando funciones generales. Las implementaciones reales de los
sistemas descritos pueden no corresponder componente a componente con este estándar,
pero conceptualmente deben realizar las mismas funciones. Utiliza tres tipos de
componentes:
?
Procesos (círculos). Representan las funciones del módulo.
- 117 -
3. Propuesta arquitectural y metodológica
?
?
Almacenamientos (rectángulos). Representan bases de datos o, en general,
repositorios de información asociados al módulo.
Flujos (flechas). Representan el intercambio de información entre módulos o las
ordenes de inicio, fin o modificación de un proceso.
3.1.1. Módulo del dominio
Este módulo contendrá el conjunto de conocimientos de un dominio determinado que
nuestro asistente inteligente mostrará al usuario del sistema ERP encargado de su
parametrización. La construcción de este componente requiere el uso de técnicas de
Ingeniería del Conocimiento como bases de la representación del dominio. El modelo
resultante contendrá hechos, procedimientos, conceptos, etc. que serán utilizados a lo
largo de todo el proceso de guía para la parametrización. El modelo que conseguimos en
este módulo constituye la principal diferencia con los procesos de parametrización
clásicos dentro de los sistemas ERP. Mientras que en estos el dominio de conocimientos
viene representado simplemente en forma de texto o pantallas de ayuda on-line que
definen los parámetros pero no sus implicaciones, relaciones y consecuencias para una
estrategia empresarial determinada, nuestro módulo lo representará, además de en esta
forma clásica, como un conjunto formal de reglas de producción. Esto significa que el
proceso de parametrización vendrá guiado por dos tipos de modelos:
?
Ayudas clásicas de tipo texto, a las que es posible añadir otro tipo de ayudas
como gráficos, videos, explicaciones en formato audio, etc y que además se
presentan al usuario según sus preferencias, por ejemplo en el idioma o en el
tipo de representación (eligiendo entre gráfica o textual, por ejemplo);
?
Base de conocimientos que representa las posibles acciones a tomar y sus
consecuencias, las decisiones ya tomadas en función de la taxonomía
empresarial definida, los posibles valores de los parámetros, presentando por
defecto aquellos acordes con las soluciones más rentables tomadas en empresas
de la misma taxonomía, etc.
La figura 3.3 representa el detalle del nivel 2 de la arquitectura para este módulo.
Módulo de
parametrización
Módulo del
dominio
Figura 3.3 Detalle de la arquitectura de nivel 2 para el módulo del dominio
- 118 -
3. Propuesta arquitectural y metodológica
Utilizando el estándar ya referenciado de IEEE, la figura 3.4 muestra la
descomposición a nivel inferior de la arquitectura de este módulo.
Reglas y parámetros
Módulo de
parametrización
Ayudas
Dominio
Figura 3.4 Arquitectura de nivel 3 para el módulo del dominio
Dentro del módulo del dominio distinguimos tres elementos: uno de tipo
almacenamiento y dos de tipo flujo.
Almacenamiento Dominio.
Contiene la base de conocimientos representada en forma de redes semánticas que
unen, a través de la relación acción-condición, reglas de producción, los parámetros y
sus valores relativos a las acciones que lo requieran y las ayudas asociadas a los
parámetros y las acciones.
Para cada dominio concreto o subdominio contendrá el conocimiento de los expertos
sobre él. Un subdominio corresponde a un proceso de negocio, ya sea en sentido
amplio, como Ventas, Logística, etc. o en sentido detallado, como Generación de una
orden de producción o Expedición de un albarán. La dificultad que entraña la obtención
del conocimiento sobre el dominio completo deriva de la imposibilidad de encontrar
expertos en las funciones del paquete y expertos en los procesos de negocio de la
empresa que lo va a implantar, además expertos en todas las áreas de negocio
implicadas; administración, logística, financiero, etc. A todo esto se añade que el pobre
conocimiento que posee el personal de la organizase sobre la funcionalidad del sistema
ERP no les permite apreciar las implicaciones de adopción de decisiones durante la
parametrización. De forma similar, pocos consultores de ERP entienden los procesos de
negocio de sus clientes lo suficiente para detectar las áreas críticas que no cuadran con
el paquete. Por tanto, además del conocimiento de los expertos, es necesario utilizar y
procesar cualquier otra información asociada al ERP o las funciones empresariales
como manuales del sistema ERP, definición de los procesos de negocio empresariales,
taxonomía empresarial, modelo de datos del sistema ERP, etc.
De todas las fuentes citadas anteriormente debemos también obtener y formalizar
ayudas que clarifiquen la actuación propuesta por el asistente o justifiquen las
decisiones tomadas por el usuario. Estas ayudas deben asociarse a cada una de las reglas
de producción y a los parámetros relativos. Por ejemplo asociado a la regla de
producción que guíe la elección de la política de planificación, podrá aparecer un texto
- 119 -
3. Propuesta arquitectural y metodológica
o un video o una grabación audio que explique el significado y las consecuencias de
cada una de las políticas. También se podrá asociar información a los parámetros, no
solo a las reglas, por ejemplo si se decide utilizar la política punto de pedido se debe
definir un valor temporal, se podrá asociar a dicho valor un gráfico que compare los
resultados con distintos valores.
Por tanto el conocimiento del dominio comprende no solo los parámetros y sus
posibles valores sino también reglas de actuación para llevar a cabo determinados
procedimientos y conseguir ciertas estrategias empresariales. Dicho conocimiento, que
se modelizará en el apartado metodológico de este trabajo, será la secuencia de
instrucciones que el asistente utiliza para llevar a cabo las tareas de parametrización.
Para obtener un conocimiento modelizado nos encontramos con varios problemas,
que se resolverán en el apartado metodológico, según su origen:
?
Conocimiento del experto. Es necesario establecer entrevistas que conviertan
este conocimiento en texto, gráficos, audio o cualquier otro formato que pueda
ser utilizado, además para dar ayudas personalizadas al usuario. Una vez
obtenido este conocimiento en forma textual pasará a formar parte de la
categoría siguiente.
?
Conocimiento en lenguaje natural (texto). Puede proceder del experto, de
manuales del sistema ERP o de descripciones de procesos de negocio. Es
necesario transformar el lenguaje natural en un conjunto de reglas de
conocimiento unidas entre sí formando una red semántica o de inferencia. De
esta forma se convierte el conocimiento de un texto expresado en lenguaje
natural en conocimiento expresado mediante reglas unidas entre sí, que cumple
tres condiciones que no tiene el lenguaje natural: está formalizado, es ejecutable
en un sistema informático y su contenido no tiene posibilidad de interpretaciones
diversas.
?
Conocimiento en forma de procesos de negocio. Hay distintos métodos de
representación de los procesos de negocio y es necesario estudiar su posible
transformación en reglas de producción conectadas entre sí, de esta manera su
formalización sería compatible con la definida para el lenguaje natural y podrían
unirse en la misma red semántica.
?
Modelo de datos del sistema ERP. Cualquier sistema ERP de calidad tiene como
soporte alguna herramienta CASE (Computer Aided Software Engineering),
utilizada para el desarrollo y mantenimiento del producto software. Una parte
fundamental de estas herramientas constituye el modelo de datos. Este modelo
contiene todos los parámetros, su definición, formato y posibles valores.
- 120 -
3. Propuesta arquitectural y metodológica
Además los datos están agrupados en tablas, que es fácil identificar con
subdominios. Hay que establecer, por tanto, la conversión de esta información
en una estructura formal que represente los parámetros a utilizar en cada
subdominio.
Flujo Reglas y parámetros.
Este flujo envía información al módulo de parametrización. La información a enviar
puede ser del tipo siguiente:
?
Elenco de los subdominios de conocimiento, es decir de aquellos procesos de
negocio que es posible parametrizar con ayuda del asistente. El módulo de
parametrización decidirá en función de la taxonomía empresarial cuales de estos
subdominios deben ser presentados al usuario
?
Siguiente acción a ejecutar dentro de la red semántica según el valor de las
condiciones obtenidas hasta el momento.
?
Parámetros a definir, según la acción en la que se encuentre el proceso de
parametrización. Posteriormente el modulo de parametrización decidirá si sus
valores deben ser elegidos por el usuario libremente, elegidos por el usuario con
valores propuestos por el asistente o elegidos por el asistente.
Flujo Ayudas.
Este flujo envía información al módulo de parametrización en forma de ayudas
asociadas a las acciones, condiciones o parámetros del subdominio que se está tratando.
El módulo del dominio puede contener distintos tipos de ayuda para cada objeto y será
el módulo de parametrización el que decida cuantas de estas ayudas presentar y el orden
de presentación.
3.1.2. Módulo de usuario
El módulo de usuario es una representación abstracta de la persona que está
utilizando el sistema para parametrizar el ERP. El asistente debe conocer lo que el
usuario quiere hacer, lo que ha hecho hasta el momento y sus preferencias, lo que hará
que el entorno del asistente sea adaptable a los específicos rasgos de cada uno.
Este modulo se relacionará con los módulos de parametrización, para guiarle durante
su tarea, y calidad, para gestionar las modificaciones a la parametrización necesarias
según los resultados de calidad obtenidos y deseados por cada empresa u organismo.
- 121 -
3. Propuesta arquitectural y metodológica
El modelo del usuario almacenará dos niveles de información, aquella relativa al
usuario como persona individual que está realizando una tarea y aquella relativa al
usuario como empresa u organismo que va a utilizar el ERP. Los usuarios individuales
pertenecerán, por tanto, a empresas u organismos. El conocimiento del asistente acerca
del usuario será de dos tipos:
?
Relativo al dominio (tanto conceptual como procedimental), sobre lo parte ya
parametrizada y sus valores, así como la parte a parametrizar de cada usuario
individual y, por tanto, esa misma información totalizada para cada usuario
colectivo (empresa u organismo), sobre la situación de los procesos de negocio
ya parametrizados y en uso respecto a los parámetros de calidad de cada
empresa u organismo y sobre la política de planificación de cada empresa u
organismo deducida de su taxonomía empresarial;
?
Relativo al propio usuario, tanto individual como colectivo, que contendrá su
modelo en cuanto a identificación, necesidades y preferencias, tanto definidas
por él mismo como obtenidas de un “mecanismo histórico” de registro de ciertos
rasgos, actuaciones y características del usuario que han sido inferidas de
pasadas actuaciones, por ejemplo la preferencia por un cierto valor de un
parámetro. Evidentemente los usuarios individuales formaran parte de algún
usuario colectivo y heredaran sus preferencias y características que podrán
modificar y adaptar a sus propios gustos e intereses.
La información sobre preferencias de usuario y estrategias de parametrización la
obtiene el asistente mediante un proceso de herencia por niveles que muestra la figura
3.5.
Nivel de taxonomía empresarial
-
Nivel de empresa u organismo
Nivel de usuario individual
+
Predominio
Figura 3.5 Herencia por niveles utilizada en el proceso de información personalizada
- 122 -
3. Propuesta arquitectural y metodológica
En primer lugar utilizará la información sobre preferencias de usuario, parámetros y
subdominios definidas para la taxonomía empresarial a la que pertenezca la empresa u
organismo a la que esté asociado el usuario individual. A continuación la información
definida para cada empresa u organismo particular que puede modificar la anterior. Por
último la información propia de cada usuario que es siempre la que predomina sobre las
anteriores.
La figura 3.6 representa el detalle del nivel 2 de la arquitectura para este módulo.
Módulo de
parametrización
Módulo de
calidad
Módulo de
usuario
Figura 3.6 Detalle de la arquitectura de nivel 2 para el módulo de usuario
Utilizando el estándar ya referenciado de IEEE, la figura 3.7 muestra la
descomposición a nivel inferior de la arquitectura de este módulo.
ci ón
etriza
m
a
r
a
de p
tegia
Estra
Módulo de
parametrización
Ident
ificac
i ón y
prefe
rencia
s
Sit
ua
ci
ón
de
pa
ram
etr
iza
ci
Módulo de
calidad
ón
Planes
Usuarios
Estado de
parametrización
Situac
i ón d
e cali
dad
Resu
ltado
s de
calida
d
Métricas de
calidad
Figura 3.7 Arquitectura de nivel 3 para el módulo de usuario
- 123 -
3. Propuesta arquitectural y metodológica
Dentro del módulo de usuario distinguimos nueve elementos: cuatro de tipo
almacenamiento y cinco de tipo flujo.
Almacenamiento Planes.
Contiene la información relativa a los deseos y preferencias en cuanto a la
parametrización. Esta información puede estar asociada a cada uno de los dos niveles de
usuario:
?
Colectivo (empresa u organismo). La información se obtiene de la taxonomía
empresarial en la que se encuentra el usuario colectivo. La taxonomía
empresarial determinará, como se verá en este capítulo en las bases
metodológicas, algunas decisiones estratégicas que deben ir reflejadas en la
actuación del ERP, y, por tanto, en la parametrización, que es su guía de
actuación. Según su taxonomía habrá algunas decisiones que el asistente pueda
tomar, tanto en el camino que debe seguir la parametrización como en el valor
que se deben dar a los parámetros necesario, por ejemplo para una empresa de
construcción de barcos no se debe establecer una política de gestión de las
previsiones y por tanto el asistente no conducirá por ese camino la
parametrización, en cambio una empresa de fabricación de yogures si debe
utilizar dicha política y el asistente le guiará por ese camino, e incluso,
dependiendo de otros factores estratégicos podrá dar un valor determinado a
algunos parámetros de ese proceso, como la barrera de la demanda a aplicar, sin
necesidad de preguntárselo al usuario;
?
Individual (utilizador del sistema ERP). La información se obtiene de las propias
preferencias del individuo respecto a la parametrización del ERP. Esas
preferencias se heredarán del usuario colectivo al que pertenezca el individual,
pero podrán ser modificadas, particularizadas, para cada usuario individual, en
función de su propia decisión o de las acciones que históricamente haya
realizado en la parametrización del sistema, por ejemplo dando un valor
diferente a un parámetro del que el asistente propone como valor ideal según la
taxonomía empresarial. Es decir el asistente personalizará las preferencias
individuales, directamente de las indicaciones del usuario o indirectamente
deduciéndolas de las acciones que ha realizado durante la parametrización.
Almacenamiento Usuarios.
Contiene la información relativa a la identificación de los usuarios, tanto individuales
como colectivos, la relación entre ellos, es decir la pertenencia de los individuales a
colectivos y sus preferencias en cuanto a la presentación de la información.
- 124 -
3. Propuesta arquitectural y metodológica
Los usuarios colectivos se crearán directamente en el asistente y serán aquellas
empresas que están implantando o usando el sistema ERP. Los usuarios individuales se
tomarán directamente de cada sistema ERP que se está implantando de manera que
automáticamente el asistente sabrá el usuario colectivo al que asociarlo y sus claves
personales necesarias para la posterior parametrización automática del ERP. Además
tomarán, por defecto las preferencias de uso del usuario colectivo al que pertenecen, por
ejemplo el idioma que usará el asistente en el interfaz. Existe la posibilidad que el
usuario individual modifique sus preferencias directamente y que el sistema las
modifique automáticamente en función de acciones reiteradas del usuario, por ejemplo
cambio del idioma que aparece en el interfaz cuando está trabajando con el asistente.
Un usuario individual puede pertenecer a la vez a varios usuarios colectivos en el
caso de representar a un consultor que trabaja en varias implantaciones ERP a la vez, de
diversas empresas. En estos casos el nivel de obtención de la información será, primero,
sus preferencias individuales y después las preferencias del usuario colectivo con el que
trabaje en cada momento.
Mediante el análisis de la información contenida en este módulo será posible
construir informes de progreso individualizados por usuario personal y por empresa u
organización sobre el trabajo de parametrización realizado, sus avances en el tiempo e,
incluso, comparaciones con actividades de parametrización de proyectos de
implantación similares.
Almacenamiento Estado de parametrización.
Contendrá la información de la parametrización realizada hasta el momento por cada
usuario individual en su propio subdominio de la implantación ERP que este realizando
y, por lo tanto, la situación de parametrización total de cada implantación ERP, como el
conjunto de parametrizaciones de subdominios.
Esta información se obtendrá mientras el usuario recorre todos los caminos de la red
semántica del subdominio, que podemos comparar con un hipotético grafo formado por
las conexiones entre el conjunto de las reglas de conocimiento del módulo del dominio.
El conjunto de todas las reglas y su grado de ejecución (respuesta del usuario a las
condiciones de las mismas y valores de los parámetros necesarios) será almacenado por
el modulo del usuario y presentado en cualquier momento al usuario para su
continuación o consulta. Con objeto de dar la mayor flexibilidad posible al proceso de
parametrización, este siempre tendrá presente el estado de parametrización o camino de
la red semántica por el que ha pasado, y podrá, si lo necesita, volver atrás y repetir la
parametrización de cualquier dominio o subdominio.
- 125 -
3. Propuesta arquitectural y metodológica
Las respuestas del usuario, tanto como condiciones de una regla de producción como
valores de los parámetros, pueden ser comparadas con aquellas predefinidas por la
taxonomía empresarial, sería una comparación de la parametrización real personalizada
con un modelo ideal implementado por el asistente según la estrategia empresarial del
usuario. Podría obtenerse un informe sobre desviaciones del modelo y responsable de
las mismas.
Almacenamiento Métricas de calidad.
Contiene la información relativa a cada uno de los subdominios a parametrizar sobre
las mediciones de calidad efectuadas durante la utilización del sistema ERP ya
implantado y parametrizado. También contendrá los valores de calidad aceptables y
óptimos de cada subdominio, que serán definidos para cada usuario colectivo, ya que
dependen de la estrategia empresarial de cada empresa u organismo.
La información de contenida en este almacenamiento es, por tanto, útil durante la
vida y utilización del sistema ERP, no durante su implantación. En la fase de
implantación está información no existirá. Posteriormente, cuando el asistente haya
parametrizado el sistema y esté implantado y en uso se definirán métricas de calidad y
recogidas de datos del funcionamiento del sistemas ERP que el asistente analizará y
valorará según los datos aceptables y óptimos de cada subdominio. Según el resultado
propondrá la modificación de la parametrización realizada. La forma de obtención de
valores, índices y criterios de calidad se definirá en las bases metodológicas de este
capítulo y está muy relacionada con la estrategia empresarial. El asistente asociará a las
reglas de producción del dominio los índices de calidad de forma que la baja medición
de cada uno de ellos, según los valores aceptables y óptimos, proponga
automáticamente al usuario la modificación de la parametrización correspondiente y el
asistente guiará al usuario por la parte de la red semántica relativa.
Flujo Estrategia de parametrización.
Este flujo contiene información que se envía al módulo de parametrización sobre las
decisiones de parametrización predefinidas, bien a nivel de usuario colectivo o
individual, en función de la taxonomía empresarial y la decisión directa del usuario. Es
decir, se enviará al módulo de parametrización las condiciones predefinidas por el
asistente de la regla de producción que se esté ejecutando en ese momento, si las hay, y
los valores predefinidos por el asistente asociados a esa regla, si los hay.
Flujos Identificación y preferencias.
Este flujo es bidireccional. Por una parte se envía información al módulo de
parametrización para que utilice la identificación y preferencias de cada usuario en el
- 126 -
3. Propuesta arquitectural y metodológica
interfaz. Contiene datos como usuario colectivo al que pertenece, idioma preferente y
posibles problemas de accesibilidad que decidan el formato del interfaz y de las ayudas,
eligiendo, por ejemplo aquellas auditivas frente a las gráficas o textuales o a la inversa.
Por otro lado el módulo de parametrización envía la identificación del usuario para ser
validada y los posibles cambios en cuanto a las preferencias conocidas por el asistente.
Flujo Situación de parametrización.
Este flujo es enviado por el módulo de parametrización y contiene el camino de la
red semántica perteneciente a un subdominio que ha recorrido un usuario hasta el
momento, además incluye el valor de los parámetros que ha definido. El camino se
formalizará como reglas de producción, el valor de sus condiciones y las acciones
resultantes.
Flujo Resultados de calidad.
Este flujo contiene la información que proviene del módulo de calidad sobre la
recogida y análisis de datos realizados durante el funcionamiento del sistema ERP.
Indicará para cada uno de los subdominios analizados los valores de calidad obtenidos,
es decir, los resultados de calidad del proceso de negocio de ese subdominio. Cada
subdominio estará asociado a una parte de la red semántica que se debe volver a
recorrer.
Flujo Situación de calidad.
Este flujo contiene la información que se envía al modulo de calidad relativa a las
diferencias entre los valores de los índices de calidad obtenidos y los esperados. El
modulo del usuario tendrá definido para cada subdominio los valores aceptables y
óptimos de calidad, que estarán definidos para cada usuario colectivo, ya que depende
de cada estrategia empresarial.
3.1.3. Módulo de parametrización
El módulo de parametrización de nuestro asistente inteligente representa como
parametrizar el sistema ERP y finalmente obtendrá la parametrización automática del
sistema, además regula las interacciones entre el sistema informático y el alumno.
Vendría a encarnar el papel del consultor o del usuario experto con parecidas
competencias en cuanto a guía, responsabilidad y ayuda que puede proporcionar un
experto humano. La función de asistencia inteligente a la parametrización consiste en:
- 127 -
3. Propuesta arquitectural y metodológica
?
Guiar al usuario a través de las reglas de conocimiento del proceso de negocio
que esté parametrizando contenidas en la red semántica del subdominio
correspondiente y permitirle avanzar y retroceder a través de un flujo con
memoria en este proceso. Sugerir al usuario caminos a recorrer en la red
semántica y posibles valores de los parámetros correspondientes según el
usuario colectivo al que pertenezca y la taxonomía empresarial en la que este
esté incluido.
?
Proporcionar al usuario los conocimientos y explicaciones necesarias para
comprender y definir la parametrización del sistema ERP. Presentarle
información multimedia sobre el objeto (parámetro, condición, acción, etc.) a
procesar o sobre cualquier otro objeto relacionado con él a través de las reglas de
conocimiento y sobre las actuaciones que propone el asistente o las actuaciones
ya realizadas. Para esta presentación de contenidos asociados a un conocimiento,
se tendrá en cuenta actuaciones pasadas del propio usuario y preferencias, tanto
desde el punto de vista de la información a presentar como el formato y
estructura de dicha presentación.
?
Gestionar la interacción con el usuario sobre la información relativa a la
identificación del mismo, datos anagráficos y preferencias. Gestionar, también,
la interacción con el modelo del usuario para la actualización de la situación de
parametrización de los diferentes subdominios y las acciones realizadas para su
consecución.
?
Proporcionar, en formato compatible con las herramientas de carga de los
sistemas ERP, los datos necesarios para la parametrización automática del
sistema, es decir ejecutar, de forma batch y sin intervención humana, las
transacciones que el grupo de implantación, consultores y usuario expertos,
hubieran debido completar una a una y de forma on-line.
?
Ayudar al usuario a conseguir una mejora continua en el uso del sistema ERP,
sugiriéndole modificaciones a la parametrización realizada que puedan corregir
bajos resultados en las métricas de calidad, interactuando para ello con el
módulo de calidad.
La figura 3.8 representa el detalle del nivel 2 de la arquitectura para este módulo.
- 128 -
3. Propuesta arquitectural y metodológica
Módulo de
parametrización
Módulo del
dominio
Interfaz
Módulo de
calidad
Módulo de
usuario
ERP
Figura 3.8 Detalle de la arquitectura de nivel 2 para el módulo de parametrización
Utilizando el estándar ya referenciado de IEEE, la figura 3.9 muestra la
descomposición a nivel inferior de la arquitectura de este módulo.
Preferencias
Ayudas y soporte
a
ud
Ay
I
n
t
e
r
f
a
z
Proc
eso
a
a
ad
liz
a
on
rs
pe
Módulo de
calidad
Procesos
a mejorar
n
para
met
riza
r
Reglas y parámetros
rio
e usua
esta d
Respu
Parametrización
ón
ci
iza
r
t
e
ram ERP
Pa
Ide
nt
ific
ac
i ó
ny
ERP
pr
efe
re
nc
ias
sy
gla
e
R
r
pa
Módulo del
dominio
os
etr
m
á
Estrategia de
parametriza
ci ón
Re
sp
u
us est
ua a d
rio e
Identificación y preferencias
ió
tic
Pe
Ay
ud
as
da
yu
a
de
de
ci ón
Situa rizaci ón
t
me
para
Memoria de
trabajo
n
ió
ac
c
i
f
i
nt
Ide
ió
cac
tifi
n
Ide
ny
Módulo de
usuario
as
nci
ere
f
e
pr
Modelo de usuario
Figura 3.9 Arquitectura de nivel 3 para el módulo de parametrización
- 129 -
3. Propuesta arquitectural y metodológica
Dentro del módulo de parametrización distinguimos diecisiete elementos: uno de tipo
almacenamiento, tres de tipo proceso y trece de tipo flujo.
Almacenamiento Memoria de trabajo.
Contendrá la información sobre el usuario y su actividad durante cada sesión del
asistente inteligente. La memoria de trabajo recibirá la identificación y las respuestas
del usuario y conformará la situación de parametrización resultado de las acciones del
usuario y que en cada momento será diferente. Cuando el usuario o el asistente den por
terminada la sesión la situación de parametrización final será enviada por el módulo de
parametrización al módulo de usuario utilizando el contenido de la memoria de trabajo.
El formato de la información que contiene la memoria de trabajo será similar al
formato del módulo del dominio, es decir reglas de producción conectadas en redes
semánticas correspondientes a subdominio y los valores de los parámetros asociados a
las reglas de producción. La diferencia con el contenido del módulo del dominio es que
este presenta todas las posibilidades de parametrización y todos los subdominio, en
cambio la memoria de trabajo contiene esa información particularizada para la
actuación de un usuario, es decir no estarán todos los subdominios, solo aquellos que ha
considerado el usuario, tampoco estará la red semántica completa de cada uno sino
solamente la parte por la que ha pasado el usuario guiado por el asistente. Finalmente
los parámetros asociados no tendrán todos sus posibles valores sino solo el determinado
por el asistente o el usuario durante su actividad.
Proceso Ayudas y soporte.
Este proceso es el encargado de gestionar la ayuda y el soporte que se proporciona al
usuario. Recibirá las peticiones de este en cuanto a necesidades de ayuda y presentará al
interfaz de forma personalizada para cada usuario la respuesta del módulo de
parametrización. El proceso seleccionará el adecuado nivel así como el método de
presentación de cada contenido explicativo aplicando la herencia por niveles, mostrada
anteriormente en la figura 3.5, es decir:
1. Los valores predefinidos para la taxonomía empresarial a la que pertenezca la
empresa u organismo a la que esté asociado el usuario individual;
2. A continuación la información definida para cada empresa u organismo
particular que puede modificar la anterior;
3. Por último la información propia de cada usuario que es siempre la que
predomina sobre las anteriores.
El usuario podrá pedir y obtener dos tipos de ayuda diferentes:
- 130 -
3. Propuesta arquitectural y metodológica
?
Ayuda relacionada con objetos (acciones, condiciones, parámetros) de la red
semántica del subdominio. La configuración de esta respuesta se basa en ayudas
de tipo texto, gráficos, videos, explicaciones en formato audio, etc. presentes en
el módulo del dominio relacionadas con parámetros, acciones y condiciones de
las reglas de producción;
?
Ayuda relativa a explicaciones sobre las decisiones propuestas o tomadas por el
asistente inteligente durante el proceso de parametrización del subdominio. La
configuración de esta respuesta parte de la base de conocimientos del módulo
del dominio que representa las posibles acciones a tomar y sus consecuencias,
los posibles valores de los parámetros y las decisiones más rentables tomadas en
función de la taxonomía empresarial definida.
Proceso Modelo de usuario.
Este proceso es el encargado de gestionar la identificación y las preferencias del
usuario dentro del módulo de parametrización.
Su primera función es recibir del usuario a través de la interfaz su identificación y
sus preferencias. La identificación será validada en el módulo de usuario y utilizada por
otros componentes del módulo de parametrización, como la memoria de trabajo. Las
preferencias pueden ser introducidas por el usuario y, en ese caso, serán las que utilice
el asistente y serán enviadas al módulo de usuario para modificar las existentes hasta ese
momento.
Su segunda función consiste en obtener a través del módulo de usuario las
preferencias que el usuario tiene en ese momento utilizando la herencia por niveles,
mostrada anteriormente en la figura 3.5. De esta forma ayudará al proceso de
parametrización en la presentación de reglas y parámetros en el interfaz
proporcionándole la información necesaria para el tratamiento personalizado de cada
usuario.
Proceso Parametrización.
Este proceso realiza las funciones centrales del módulo de parametrización. En
primer lugar se comunica con el usuario proponiendo, a cada usuario particular, los
posibles subdominios a parametrizar, según el estado de parametrización de cada
subdominio, obtenido del módulo de usuario, y según las propuestas que le envía el
módulo de calidad. Recibe la respuesta del usuario y presenta la situación de
parametrización del elegido de forma que al presentar una nueva regla de la red
semántica asociada, esta se relacionará con las anteriores ya ejecutadas por el usuario.
- 131 -
3. Propuesta arquitectural y metodológica
El proceso de guía a través de la red semántica personalizada del usuario, similar en
parte al proceso de tutorización de los Sistema Inteligentes de Tutorización estudiados,
se desarrolla presentando las condiciones y los parámetros de la regla de producción
todavía no ejecutada o incompleta. A continuación el módulo de parametrización puede
definir una respuesta según los datos que sobre el usuario posea o puede preguntarle al
usuario proponiéndole valores o dejándole responder libremente. Con estas respuestas
se actualizará el estado de parametrización del dominio y se ejecutará la regla de
producción cuya consecuencia será la entrada o condición de otra de las reglas, que será
la que el proceso de parametrización presente al usuario a continuación, guiándole así a
través de la red semántica por el camino particular que cada usuario elija.
La comunicación con el usuario se realiza a través de un interfaz que es al que el
módulo de parametrización envía sus mensajes de forma personalizada, teniendo en
cuenta las preferencias de cada usuario que obtiene del módulo de usuario. En función
de esas preferencias y de la estrategia de parametrización que viene dada por la
taxonomía empresarial que se utiliza, realiza funciones de predicción determinando las
probables respuestas del usuario a las condiciones y parámetros de las reglas de
producción y fijando otras que se tomarán de forma inteligente sin la participación del
usuario.
Flujos Identificación y preferencias.
El primero de estos flujos se envía desde la interfaz del asistente con el usuario hacia
el proceso modelo de usuario. Contiene los datos de identificación y preferencias que el
usuario introduce en el asistente. Por una parte la propia identificación y por otra la
modificación o la creación de preferencias personales como idioma preferente y
posibles problemas o preferencias de accesibilidad que decidan el formato del interfaz y
de las ayudas. El asistente obtendrá los datos de preferencias de usuario desde distintos
niveles: primero taxonomía empresarial, después usuario colectivo al que pertenece y,
finalmente, usuario individual, que puede modificar los valores heredados de los niveles
anteriores.
El segundo de estos flujos es bidireccional ya que, por un lado, se envía desde el
proceso modelo de usuario al módulo de usuario y contiene los datos de identificación y
preferencias que deben ser creados o actualizados en el módulo de usuario según los
valores decididos por él mismo. Por otro lado el módulo de usuario envía al modelo de
usuario la confirmación de la identificación y sus datos asociados (nombre, usuario
colectivo al que está asociado, etc.) y las preferencias del mismo obtenidas utilizando la
herencia por niveles.
- 132 -
3. Propuesta arquitectural y metodológica
El tercero de estos flujos es interno al módulo y se envía desde el proceso modelo de
usuario al proceso de parametrización. Contiene los datos de identificación del usuario y
sus preferencias, datos que el proceso de parametrización utilizará para personalizar su
interacción con el usuario. En función de la identificación se seleccionará la estrategia
empresarial y, por tanto, los valores adecuados de los parámetros y del camino a
recorrer por la red semántica, las propuestas que el sistema hace al usuario frente a la
mejora de la calidad y los subdominios de conocimiento que pueden ser parametrizados
por el usuario en función de su taxonomía empresarial, distinguiendo el estado de
parametrización de cada uno (completo, en progreso o sin iniciar). Las preferencias
ayudan al proceso de parametrización a presentar reglas y parámetros en la interfaz de la
manera más acorde con cada usuario particular.
Flujo Preferencias.
Este flujo recibe información del modulo de usuario y contiene las preferencias de
cada usuario relativas a la presentación y el tipo de información en el interfaz. Contiene
datos como usuario colectivo al que pertenece, idioma preferente y posibles problemas
o preferencias de accesibilidad que decidan el formato del interfaz y la presentación de
las ayudas, eligiendo, por ejemplo aquellas auditivas frente a las gráficas o textuales o a
la inversa.
Flujo Identificación.
Este flujo es interno al módulo y se envía desde el proceso modelo de usuario al
almacenamiento memoria de trabajo. Contiene los datos de identificación del usuario
necesarios para que la memoria de trabajo pueda almacenar correctamente la situación
de cada usuario en cuanto al uso del sistema y sus actividades y después pueda
actualizar con toda esta información el módulo de usuario.
Flujo Petición de ayuda.
Este flujo se envía desde el interfaz y se recibe en el proceso ayudas y soporte.
Contiene la solicitud de ayuda que hace el usuario, a través del interfaz, tanto sobre el
propio proceso de parametrización como sobre algunos de sus conceptos o parámetros.
La petición de ayuda también puede referirse a explicaciones sobre la situación de
parametrización de cada subdominio, sobre las propuestas de revisión de la
parametrización para mejorar la calidad que hace el asistente y sobre la estrategia de
parametrización que propone.
- 133 -
3. Propuesta arquitectural y metodológica
Flujo Ayuda personalizada.
Este flujo envía información al usuario a través de la interfaz en forma de ayudas
asociadas a las acciones, condiciones o parámetros del subdominio que se está tratando
y que ha sido solicitada por el usuario. Las ayudas provienen del módulo del dominio y
puede haber varias y de distinto tipo para cada objeto. Será el módulo de
parametrización el que decida cuantas de estas ayudas presentar y el orden de
presentación en función de las preferencias del usuario que conoce a través del módulo
de usuario. La ayuda puede referirse a explicaciones sobre el proceso del asistente,
como hemos visto en el flujo anterior. Esta información está contenida en los módulos
del dominio, de calidad y de usuario y, al estar formalizada como reglas de producción
como veremos en las bases metodológicas de este capítulo, es fácilmente mostrable y
comprensible al usuario.
Flujo Ayudas.
Este flujo recibe información del módulo del dominio en forma de ayudas asociadas
a las acciones, condiciones o parámetros del subdominio que se está tratando y que ha
sido solicitada por el usuario a través del interfaz. El módulo del dominio puede
contener distintos tipos de ayuda para cada objeto y en formatos diferentes y será el
módulo de parametrización el que decida cuantas de estas ayudas presentar y el orden
de presentación.
Flujo Procesos a mejorar.
Este flujo recibe información del módulo de calidad sobre los procesos de negocio
(subdominios) a mejorar y su prioridad, determinados por el análisis realizado sobre los
datos de calidad en dicho módulo. Esta información la utiliza el módulo de
parametrización para proponer al usuario correspondiente los subdominios a los que
debe acceder y en que orden para revisar la parametrización e, incluso, proponerle
posibles caminos de parametrización y valores de parámetros que corrijan las
desviaciones de calidad.
Flujo Proceso a parametrizar.
Este flujo recibe información del usuario a través del interfaz y contiene el
subdominio que el usuario ha decidido parametrizar. El usuario toma está decisión
guiado por el asistente que le propondrá aquellos que es posible parametrizar con ayuda
del asistente y que corresponden a la taxonomía empresarial propia del usuario, aquellos
que ya han sido pararmetrizados y los que se encuentran en progreso pero no han
finalizado. También le podrá proponer mediante información recibida del módulo de
- 134 -
3. Propuesta arquitectural y metodológica
calidad la revisión de la parametrización de aquellos subdominios cuyos resultados
puedan ser mejorados y sus prioridades.
Flujos Reglas y parámetros.
El primero de estos flujos se recibe desde el módulo de dominio y es utilizado por el
módulo de parametrización para guiar al usuario a través de la red semántica del
dominio. La información recibida puede ser del tipo siguiente:
?
Elenco de los subdominios de conocimiento, es decir de aquellos procesos de
negocio que es posible parametrizar con ayuda del asistente. El módulo de
parametrización decidirá en función de la taxonomía empresarial cuales de estos
subdominios deben ser presentados al usuario.
?
Siguiente acción a ejecutar dentro de la red semántica según el valor de las
condiciones obtenidas hasta el momento.
?
Parámetros a definir, según la acción en la que se encuentre el proceso de
parametrización. El modulo de parametrización decidirá si sus valores deben ser
elegidos por el usuario libremente, elegidos por el usuario con valores
propuestos por el asistente o elegidos por el asistente, según la estrategia de
parametrización del usuario.
El segundo de estos flujos se envía a la interfaz de comunicación con el usuario y la
información a enviar será la misma citada anteriormente pero personalizada por el
módulo de parametrización:
?
Subdominios de conocimiento que pueden ser parametrizados por el usuario en
función de su taxonomía empresarial, distinguiendo el estado de parametrización
de cada uno (completo, en progreso o sin iniciar). Cuando el sistema esté ya en
funcionamiento se presentarán, además de todos los subdominios
parametrizados, aquellos que el asistente propone para su revisión en función de
los resultados enviados por el módulo de calidad.
?
Siguiente acción a ejecutar dentro de la red semántica según el valor de las
condiciones obtenidas hasta el momento.
?
Parámetros a definir, según la acción en la que se encuentre el proceso de
parametrización. El modulo de parametrización presentará solo aquellos cuyos
valores deban ser elegidos por el usuario libremente y aquellos que serán
elegidos por el usuario pero con valores propuestos por el módulo de
parametrización. Los valores decididos por el módulo de parametrización según
- 135 -
3. Propuesta arquitectural y metodológica
la estrategia de parametrización del usuario se cargarán automáticamente sin
presentárselos al usuario. La propuesta de valores por parte del módulo de
parametrización tendrá en cuenta la del módulo de calidad en caso de revisión de
la parametrización con el sistema ERP en funcionamiento.
Flujos Respuesta de usuario.
El primero de estos flujos es enviado por el usuario a través de la interfaz. Contiene
el valor que da el usuario a las condiciones de la regla de producción que se le presenta
en ese momento. También, si la regla de producción lleva asociados parámetros,
contiene el valor que da el usuario a cada uno de ellos. Los valores dados pueden ser
definidos libremente por el usuario o pueden ser resultado de la aceptación a la
propuesta de condiciones y valores que propone el asistente. Con objeto de dar la mayor
flexibilidad posible al usuario, este siempre tendrá presente la cadena de la red
semántica por la que ha pasado y los valores atribuidos a los parámetros y podrá, si lo
necesita, volver atrás y repetir la parametrización de un subdominio o de una parte la
red semántica y, por tanto, repetir la asignación de valor a un parámetro.
El segundo de estos flujos es interno al módulo ya que es enviado por el proceso de
parametrización al almacenamiento memoria de trabajo. Este flujo es necesario para que
la memoria de trabajo vaya, paso a paso, configurando la situación de parametrización
del subdominio, de forma que esta pueda ser consultada por el usuario en cualquier
momento y almacenada para posteriores actuaciones del usuario y para su posterior
carga en el sistema ERP.
Flujo Situación de parametrización.
Este flujo es enviado al modulo de usuario y contiene el conjunto de acciones
realizadas por el usuario durante la sesión de trabajo con el asistente. El asistente guiará
al alumno por el conjunto de reglas que forman el conocimiento del subdominio a
parametrizar y que están conectadas por las condiciones/conclusiones de las mismas
formando una red semántica. El camino que seguirá el usuario por esas reglas le hará
retornar a las reglas incompletas anteriores (reglas cuyas condiciones no se han
cumplido completamente) cuando haya completado todas las reglas siguientes por las
que ha ido pasando desde la incompleta. De esta forma el usuario recorrerá todos los
caminos de la red semántica, que podemos comparar con un hipotético grafo formado
por las conexiones entre el conjunto de las reglas de conocimiento. El conjunto de todas
las reglas y su grado de ejecución (respuesta del usuario a las condiciones de las mismas
y a los valores asociados de los parámetros) será el enviado en este flujo y almacenado
en el módulo de usuario.
- 136 -
3. Propuesta arquitectural y metodológica
Flujo Estrategia de parametrización.
Este flujo contiene información que se recibe del módulo de usuario sobre las
decisiones de parametrización predefinidas, bien a nivel de usuario colectivo o
individual, en función de la taxonomía empresarial y la decisión directa del usuario. Es
decir, se reciben del módulo de usuario las condiciones predefinidas por el asistente de
la regla de producción que se esté ejecutando en ese momento, si las hay, y los valores
predefinidos por el asistente asociados a esa regla, si los hay. Es posible que esas
condiciones y valores sean fijos y en ese caso el módulo de parametrización actualiza
con ellos la situación de parametrización o sean preferentes pero deban ser sometidos a
la decisión final del usuario en cuyo caso se presentan a este a través del interfaz.
Flujo Parametrización ERP.
Este flujo es enviado directamente al sistema ERP y contiene la parametrización
terminada y aceptada de un subdominio o del dominio completo. Las decisiones del
asistente y del usuario han determinado la parametrización de los procesos de negocio
correspondientes al dominio o subdominio y han sido formalizadas mediante reglas de
producción ejecutadas de una cierta forma, lo que ha dado lugar a una cadena concreta
dentro de la red semántica asociada. Además algunas reglas de producción han
determinado valores de ciertos parámetros. Todos estos datos se transforman en
información que el sistema ERP puede procesar automáticamente a través de sus
herramientas de carga automática, como ya veremos en las fases metodológicas de este
capítulo y en el capítulo siguiente que explica la creación de un prototipo. Por tanto el
resultado del trabajo del asistente inteligente es la parámetrización automática del
sistema ERP.
3.1.4. Módulo de calidad
Este módulo representa una novedad en nuestra arquitectura respecto a las utilizadas
como referencia, las del los ITS e IHS. Sus funciones de retroalimentación para la
mejora continua no son asimilables a ninguno de los componentes de las arquitecturas
analizadas. Sus objetivos son: mostrar los beneficios de negocio esperados medidos en
parámetros del ERP según la taxonomía empresarial definida; formalizar criterios e
indicadores de calidad para definir la métrica a utilizar; asociar estos criterios a caminos
y parámetros de la red semántica del dominio; comparar resultados obtenidos y
esperados; proponer al usuario los subdominio priorizados cuya parametrización se debe
revisar según el análisis de resultados y aconsejar correcciones que puedan resolver los
problemas de calidad. Este módulo se relaciona con el módulo del usuario en cuanto a
taxonomía empresarial y valores de calidad deseados, con el módulo de parametrización
- 137 -
3. Propuesta arquitectural y metodológica
en cuanto a guía del usuario en las modificaciones a la parametrización y con el sistema
ERP en cuanto a resultados de calidad reales.
Resumiendo, este módulo deberá realizar las funciones de:
?
Elaboración, proporcionando explicaciones al usuario sobre las actuaciones y
parámetros a modificar;
?
Estrategia, seleccionando el subdominio a ser parametrizado de nuevo;
?
Diagnóstico, analizando diferencias entre los resultados de calidad obtenidos y
los aceptables y óptimos;
?
Informe, obteniendo informes de calidad, acciones tomadas, usuarios
involucrados y resultados conseguidos;
?
Monitorización, sugiriendo correcciones a las desviaciones detectadas
analizando el historial de calidad de la propia empresa o de empresas incluidas
en la misma taxonomía;
?
Evaluación, evaluando la efectividad de la parametrización realizada según
indicadores, valores y criterios de calidad establecidos.
La figura 3.10 representa el detalle del nivel 2 de la arquitectura para este módulo.
Módulo de
parametrización
Módulo de
calidad
Módulo de
usuario
ERP
Figura 3.10 Detalle de la arquitectura de nivel 2 para el módulo de calidad
- 138 -
3. Propuesta arquitectural y metodológica
Utilizando el estándar ya referenciado de IEEE, la figura 3.11 muestra la
descomposición a nivel inferior de la arquitectura de este módulo.
Módulo de
parametrización
Procesos a mejorar
Mejora continua
Situ
aci
ón
de
cali
dad
Módulo de
usuario
ERP
Informes de calidad
dad
cali
e
d
Valoración de procesos
dos
ulta
s
de negocio
e
R
Figura 3.11 Arquitectura de nivel 3 para el módulo de calidad
Dentro del módulo de calidad distinguimos seis elementos: dos de tipo proceso y
cuatro de tipo flujo.
Proceso Mejora continua.
La principal función de este proceso es aconsejar al usuario la parte del dominio cuya
parametrización debe revisar en función de los resultados de calidad obtenidos en el
sistema ERP implantado y en funcionamiento. Además de indicar la parte de la red
semántica a revisar debe aconsejar sobre los posibles cambios a realizar en la
parametrización según el criterio de calidad considerado, analizando el historial de
calidad de la propia empresa o de otras similares incluidas en la misma taxonomía, los
valores y las condiciones ya utilizadas y sus resultados.
Para determinar el conjunto de subdominios a revisar y la prioridad de cada uno se
establece primero un criterio de mínimos, es decir aquellos subdominio asociados a
indicadores que no alcancen los valores aceptables definidos en el módulo de usuario. A
continuación se calcula, para el resto de indicadores, la diferencia entre los valores
obtenidos y los óptimos definidos, también, en el módulo de usuario y se obtiene los
subdominios asociados a cada uno de ellos. En este caso la prioridad a los subdominios
se obtiene considerando dos variables: la diferencia entre valores óptimos y reales y la
cantidad de indicadores que afectan a cada subdominio.
Este proceso se encarga, además, de obtener informes de calidad: valores aceptables
y óptimos comparados con los resultados obtenidos, los cambios de parametrización a
- 139 -
3. Propuesta arquitectural y metodológica
los que han dado lugar las diferencias entre ellos y los nuevos valores obtenidos
evaluando la efectividad de la revisión de la parametrización realizada.
Proceso Valoración de procesos de negocio.
Este proceso debe determinar los criterios e indicadores de calidad que deben ser
medidos y recoger los datos que le envía el sistema ERP, que contienen los valores
reales de cada indicador medido. Por tanto, este proceso debe asociar cada indicador de
calidad con un subdominio cuya parametrización es responsable de los resultados de
calidad, sabiendo que cada subdominio corresponde con una parte de la red semántica
de conocimientos del asistente. Por ejemplo el tiempo de aceptación de un pedido de
proveedores será un indicador de calidad perteneciente al criterio de calidad de
recepción de pedidos y estará ligado a la parametrización del subdominio de recepción,
en concreto a la parte de la red semántica que define los acuerdos marcos sobre calidad
concertada con el proveedor y sobre normas internas de recepción de pedidos y control
de calidad en recepción. Los criterios e indicadores dependerán de la estrategia
empresarial, es decir de la taxonomía en la que la empresa se incluya y su determinación
será analizada en las bases metodológicas de este capítulo.
Flujo Informes de calidad.
Este flujo proviene del sistema ERP que envía los valores reales de los indicadores
de calidad definidos por el módulo de calidad. Esta recogida de datos se realizará con
una periodicidad definida para cada empresa u organismo y formará parte de sus
preferencias en el módulo de usuario. Debe ser posible adaptar la periodicidad a los
resultados empresariales y tener distintas periodicidades para cada subdominio en
función de sus resultados.
Flujo Resultados de calidad.
Este flujo contiene la información que se envía al módulo de usuario sobre la
recogida y análisis de datos realizados durante el funcionamiento del sistema ERP.
Indicará para cada uno de los subdominios analizados los valores de calidad obtenidos,
es decir, los resultados de calidad del proceso de negocio de ese subdominio. Cada
subdominio estará asociado a una parte de la red semántica que se debe volver a
recorrer.
Flujo Situación de calidad.
Este flujo contiene la información que proviene del modulo de usuario relativa a las
diferencias entre los valores de los índices de calidad obtenidos y los aceptados y
óptimos que posee el modulo del usuario para cada subdominio y para cada usuario
- 140 -
3. Propuesta arquitectural y metodológica
colectivo, ya que depende de cada estrategia empresarial. Estos datos sirven al modulo
de calidad para determinar aquellos procesos que no llegan a la calidad necesaria y se
alejan más de la calidad óptima, seleccionando y priorizando los que necesitan una
revisión de la planificación.
Flujo Procesos a mejorar.
Este flujo envía información al módulo de parametrización sobre los procesos de
negocio a mejorar y su prioridad, determinados por el análisis realizado sobre los datos
de calidad. Esta información la utiliza el módulo de parametrización para proponer al
usuario correspondiente los subdominios a los que debe acceder y en que orden, para
revisar la parametrización.
- 141 -
3. Propuesta arquitectural y metodológica
3.2. BASES METODOLÓGICAS
Hemos descrito los objetivos y las funciones necesarias para cumplirlos del asistente
inteligente propuesto en este trabajo, a continuación expondremos como el sistema
cumple sus objetivos, estableciendo una propuesta metodológica que detalle las bases
teóricas y prácticas con las que trabaja y la justificación de su uso. Estas bases que
fundamentarán la propuesta metodológica son:
?
El uso de una taxonomía empresarial que, utilizando las analizadas en el capítulo
anterior, ayude al asistente a definir de forma inteligente parámetros y
condiciones de las reglas de producción del dominio que faciliten la consecución
de la estrategia empresarial;
?
La aplicación de una técnica para el modelado de procesos de entre las varias
existentes, que formalice los procesos de parametrización del sistema ERP y que
ayude la construcción de las redes semánticas;
?
La utilización de reglas de producción del tipo condición/acción/condición que
se relacionen entre si formando redes semánticas y su representación utilizando
una adaptación de la misma técnica para el modelado de procesos anterior;
?
El uso de un conjunto de criterios e indicadores de calidad que forma una
métrica de calidad a utilizar en la evaluación del uso y los resultados del sistema
ERP implantado y que ayuden al asistente inteligente en su retroalimentación.
3.2.1. Taxonomía empresarial para la parametrización ERP
Cuando nos enfrentamos a estructuras complejas que debemos clasificar utilizamos
una taxonomía que agrupa estas estructuras en categorías jerárquicas y asocia la
información necesaria en cada contexto a estas categorías. El objetivo de la taxonomía
que vamos a llevar a cabo en este trabajo es agrupar las diferentes empresas posibles
utilizadoras de sistemas ERP según la estrategia empresarial que guíe el uso de dicho
sistema y, por tanto, su parametrización. El resultado ayudará al asistente objeto de
nuestro trabajo a definir de forma inteligente parámetros y condiciones de las reglas de
producción del dominio que conformarán la parametrización del sistema ERP para
facilitar la consecución de la estrategia empresarial.
- 142 -
3. Propuesta arquitectural y metodológica
En el capítulo segundo de este trabajo analizamos las distintas taxonomías
empresariales empleadas más comúnmente agrupándolas por el criterio principal de
clasificación. Los criterios de partida más empleados son:
?
Sectores. Clasifica por el tipo de actividad desarrollada. Cada trayectoria
sectorial viene definida por el origen del proceso de innovación, las necesidades
del usuario receptor y los niveles de codificación, accesibilidad, apropiación y
difusión. Se consideran elementos característicos, como el tipo de recurso
empleado, el tipo de resultado obtenido, el impacto económico de la innovación,
el mercado donde actúa y la tecnología utilizada.
?
Dimensión. Clasifica por el tamaño de las empresas. Este factor condiciona el
comportamiento de una empresa y es la forma más utilizada en los estudios
estadísticos. El tamaño es una variable que condiciona multitud de decisiones
empresariales, sobre todo aquellas relacionadas con la gestión del personal y el
tipo de dirección, el ámbito geográfico y el volumen de facturación y
producción.
?
Estructura organizativa. Clasifica según la estructura organizativa de la empresa,
estructura que permite a un grupo de personas coordinar eficientemente sus
esfuerzos para obtener resultados deseables. La estructura de una organización
se forma por el tipo de roles o papeles a desempeñar por las personas del grupo,
las relaciones entre ellas y, consecuentemente, los procedimientos definidos que
permiten estos roles y relaciones, la distribución de la capacidad de decisión y
los límites y relaciones con el exterior.
Considerando el objetivo de la taxonomía elegida, que es definir modelos de proceso
de negocio, en los que intervienen factores productivos, organizativos, de mercado,
comerciales y de innovación, hemos elegido utilizar una taxonomía de tipo sectorial
orientada al grupo de procesos que intervienen en un sistema ERP. La taxonomía
agrupará diversas estrategias empresariales por áreas temáticas muy diferenciadas y
dentro de cada área por sectores. En algún sector se ha considerado una división
posterior por tipo de negocio o producto, que supone un tercer nivel de clasificación.
La taxonomía desarrollada se presenta inicialmente en forma jerárquica, detallándose
posteriormente para cada sector sus características principales y sus procesos de
negocio. Este criterio, que ha sido el elegido para la clasificación realizada, es el que
determina una estrategia empresarial específica y se ha basado en el utilizado en las
implantaciones de las soluciones sectoriales de SAP. Durante el desarrollo de la
taxonomía se han obtenido las siguientes ventajas:
- 143 -
3. Propuesta arquitectural y metodológica
?
?
?
?
Soluciones diseñadas a medida de los estándares o mejores prácticas, procesos y
retos específicos de cada sector.
Visión de las necesidades y características de procesos sectoriales específicos.
Integración de procesos de negocio con información para facilitar la toma de
decisiones.
Optimización de estrategias y procesos de negocio con estructuras de soporte
efectivas que garantizan el intercambio y la disponibilidad de la información.
La tabla de la figura 3.12 representa la estructura jerárquica básica de la taxonomía
desarrollada que se utilizará en la definición de parámetros y reglas en el módulo de
usuario del asistente inteligente.
ÁREA TEMÁTICA
Industrias productivas
SECTOR
Defensa e Industria aeroespacial
Automoción
Maquinaria industrial y Componentes
Ingeniería, Construcción y Operaciones
Alta tecnología
Industria química
Metal, Papel y Madera
Minería
Petrolíferas y Gas
Sector farmacéutico
Productos de consumo
Industrias de servicios
Operadores logísticos
Medios de comunicación
Servicios profesionales
Distribución comercial
Telecomunicaciones
Servicios públicos
Distribución mayorista
Sector público y financiero
Entidades financieras
Entidades aseguradoras
Sanidad
Educación superior e Investigación
Sector público
Figura 3.12 Clasificación por áreas temáticas y sectores
- 144 -
3. Propuesta arquitectural y metodológica
La primera división representa áreas muy claramente diferenciadas. Las industrias
productivas tienen como misión principal la producción, es decir la transformación de
materias primas en productos elaborados. El objetivo primario de las industrias de
servicio no es la producción, si no la distribución de productos o la prestación de
servicios. Finalmente, la última área agrupa al sector público y las financias, en cuanto
su característica principal es la gestión y sus resultados son menos tangibles que los de
las industrias de servicios.
Veamos detalladamente las características y posibles subdivisiones del segundo nivel
o sector.
Defensa e Industria aeroespacial.
El sector aeroespacial y de defensa está cambiando de forma radical y veloz,
intentando cubrir nuevas necesidades, controlar los costes y el servicio. Entre las
funciones principales están:
? Fabricación orientada a proyectos, complejos cálculos de coste y gestión de
series del producto.
? Análisis de rentabilidad de rutas y contabilidad asociada.
? Mantenimiento, reparación y revisión, gestión de configuración y de
modificaciones
? Planificación estratégica y seguridad.
? Sistema integrado de información, mejorando el soporte para el despliegue
táctico de suministros, equipamiento y personal
Este sector lo hemos dividido en tres tipos de negocios muy diferentes en cuanto a
entorno y necesidades de procesos de negocio:
?
Mantenimiento, reparación y revisión. Servicios eficientes y eficaces que
consiguen que los productos estén disponibles rápidamente sin peder la calidad
del control. La figura 3.13 muestra el modelo de procesos de este negocio.
- 145 -
3. Propuesta arquitectural y metodológica
Clientes
Ventas
Ingeniería
Planificación
Ejecución
Aprovisionamiento
Proveedores
Ventas y
Marketing
Ingeniería de mantenimiento
Planificación del mantenimiento
Documentación, configuración y ciclo de vida de equipos
Seguridad
Planificación avanzada de
mantenimiento y servicios
Clasificación del mantenimiento
Programación del mantenimiento
Preparación de componentes
Ejecución del mantenimiento
Inspecciones y control de calidad
Facturación
Garantía
Gestión de inventario
Figura 3.13 Modelo de procesos del negocio ‘Mantenimiento, reparación y revisión’
?
Operaciones de líneas aéreas. Gestión del tráfico creciente y de la desregulación.
Integración homogénea de procesos, conocimiento y las estructuras de empresas
adquiridas o asociadas. La figura 3.14 muestra el modelo de procesos de este
negocio.
Clientes
Dirección
estratégica
Marketing
Planificación y
aprovisionamiento
Ventas
Operaciones
Proveedores
Marketing
Planificación y programación de vuelos
Compras
Control financiero
Contabilidad
Análisis de rentabilidad de rutas
Gestión de reservas y billetes
Gestión de contratos
Servicio al cliente
Control de tráfico
Control de equipajes
Seguridad
Gestión de servicios
en vuelo
Figura 3.14 Modelo de procesos del negocio ‘Operaciones de líneas aéreas’
?
Defensa. Visibilidad de activos, control de costes y presupuesto. Seguridad,
privacidad y rastreo de materias primas y de destino de productos terminados.
- 146 -
3. Propuesta arquitectural y metodológica
Gestión de contratos de y programas desde el contacto inicial hasta la entrega
del producto. La figura 3.15 muestra el modelo de procesos de este negocio.
Clientes
Diseño
Ventas
Ingeniería
Aprovisio- Producción
namiento
Gestión de
materiales
Servicios
Proveedores
Gestión de contratos
Introducción y desarrollo de nuevos productos
Gestión de ciclo de vida del producto
Marketing
Configuración de productos
Planificación de la demanda y el suministro
Producción por proyecto
Producción por ordenes
Producción a stock
Gestión de almacenes
Gestión de compras
Logística
Servicio postventa
Garantía y devoluciones
Planificación de recambios
Figura 3.15 Modelo de procesos del negocio ‘Defensa’
Automoción.
Es el sector creador del modelo de la fabricación moderna. Hoy en día, los
fabricantes compiten globalmente y se tiende a la fabricación bajo demanda
adaptándose a los requisitos de cada cliente en lugar de fabricaciones masivas a stock.
La rapidez aparece como nuevo factor en el desarrollo de nuevos productos, montaje y
entrega. La colaboración entre todos los participantes del sector (proveedores,
fabricantes de equipos originales para automoción, distribuidores y clientes) es esencial.
La gestión de las fábricas en tiempo real es un punto crucial, así como el uso y la
integración con máquinas y robots.
Este sector lo hemos dividido en tres tipos de negocios que se complementan y
utilizan, cada uno, procesos particulares:
?
Fabricantes de automoción. Funciones de ingeniería, planificación y ejecución,
que necesitan optimizar los procesos y, al mismo tiempo, reaccionar
rápidamente ante los cambios del mercado y la fluctuación de la cadena de
suministro. La figura 3.16 muestra el modelo de procesos de este negocio.
- 147 -
3. Propuesta arquitectural y metodológica
Clientes
Ingeniería
Fabricación
Aprovisionamiento
Ventas y
distribución
Servicio al
cliente
Proveedores
Desarrollo e introducción de nuevos productos
Gestión del ciclo de vida del producto
Gestión de aprovisionamiento estratégico y
operacional
Suministro a línea
Logística
Producción
Gestión del ciclo de vida del vehículo
Planificación y previsiones de
vehículos
Fabricación a montaje
Garantía
Central de servicios
Gestión de recambios y repuestos
Figura 3.16 Modelo de procesos del negocio ‘Fabricantes de automoción’
?
Proveedores de automoción. Necesidad de integración dentro del proceso de
producción de los fabricantes de equipos originales. Funciones de logística de
embalaje, planificación de calendarios de previsiones de entrega, de seguimiento
de fabricación just-in-time, de intercambio electrónico de datos, optimización y
seguimiento del transporte y procedimientos de autofacturación. La figura 3.17
muestra el modelo de procesos de este negocio.
Clientes
Ingeniería
Fabricación
Aprovisionamiento
Ventas y
distribución
Servicio al
cliente
Proveedores
Gestión colaborativa
Desarrollo e introducción de nuevos
productos
Gestión del ciclo de vida del producto
Gestión de aprovisionamiento estratégico y
operacional
Suministro a línea
Logística
Producción a stock
Producción a orden
Planificación de demandas y órdenes
Gestión de envíos
Garantía
Gestión de recambios y repuestos
Figura 3.17 Modelo de procesos del negocio ‘Proveedores de automoción’
- 148 -
3. Propuesta arquitectural y metodológica
?
Ventas y servicio de atención al cliente. Flexibilidad, gestión de centros de
soporte al cliente y servicio postventa y mejoras en la entrega: cumplimientos,
calendarios, menor tiempo, información al cliente, transporte, etc. La figura 3.18
muestra el modelo de procesos de este negocio.
Clientes
Aprovisionamiento
Ventas y distribución
Servicios
Proveedores
Gestión de clientes
Gestión de ciclo de vida del vehículo
Canales de venta
Leasing
Planificación y previsiones de vehículos
Fabricación a montaje
Gestión de recambios y repuestos
Central de servicios
Garantía
Operaciones de importación
Gestión de flotas y alquiler
Análisis clientes
Administración
Servicio a vehículos
Gestión de almacenes
Figura 3.18 Modelo de procesos del negocio ‘Ventas y servicio de atención al cliente’
Maquinaria industrial y Componentes.
Las empresas del sector de maquinaria y equipos se enfrentan a retos cada vez
mayores: productos cada vez más diversificados, especificaciones más exigentes y
clientes que esperan una respuesta más rápida y flexible a sus necesidades. Sus procesos
de negocio abarcan varias líneas: desde la estimación y entrada de pedidos hasta la
gestión de proyectos y planificación de la producción y desde el mantenimiento y los
servicios hasta la facturación y a los análisis de rentabilidad. Dentro de sus objetivos se
encuentra la mejora de las relaciones con clientes, proveedores y contratistas, detectar
cuellos de botella, piezas perdidas y excedentes de abastecimiento antes de que sucedan,
garantizar la calidad de la ingeniería, la fabricación y el montaje, perfeccionar la entrega
puntual de productos configurados por el cliente, crear hojas de ruta y de materiales
específicas por pedido, mejorar la entrega de piezas de recambio y mejorar los servicios
de posventa. La figura 3.19 muestra el modelo de procesos de este sector.
- 149 -
3. Propuesta arquitectural y metodológica
Clientes
Diseño
Ventas
Ingeniería
Aprovisio- Producción
namiento
Almacenes
Servicios
Proveedores
Introducción y desarrollo de nuevos productos
Gestión de ciclo de vida del producto
Marketing
Gestión de canales
Planificación de la demanda y el suministro
Producción por proyectos de ingeniería
Producción a orden
Producción a stock
Relaciones con proveedores
Compras estratégicas y logísticas
Gestión de almacenes
Gestión de transportes
Garantía y devoluciones
Planificación de recambios
Figura 3.19 Modelo de procesos del sector ‘Maquinaría industrial y Componentes’
Ingeniería, Construcción y Operaciones.
Las empresas de este sector pueden ser contratistas y empresas de ingeniería,
empresas de construcción residencial y comercial y empresas de equipamiento. Este tipo
de sector basa su actividad, principalmente, en la gestión y coordinación de proyectos
complejos y de personal desplazado. Entre sus objetivos se encuentra la aplicación de
nuevas tecnologías y la integración de distintos procesos (ingeniería, construcción,
operaciones) desde distintos orígenes (proveedores, subcontrata). Entre sus funciones
destacamos:
? Gestionar la cadena de suministro. Colaborar con otros participantes en la
planificación y previsión de la oferta y la demanda, el aprovisionamiento
directo, la subcontratación de la fabricación, el cumplimiento de pedidos y la
gestión de los subcontratistas.
? Reunir e interpretar datos de negocio. Obtener informes sobre las evaluaciones
de rendimiento, los presupuestos de finalización y el cambio de las condiciones
económicas.
? Colaborar a través de organizaciones y sistemas. Utilizar los portales
empresariales que proporcionan a todos los empleados y colaboradores acceso a
toda la gama de información, aplicaciones y servicios que necesitan para
trabajar.
? Controlar los costes. Permite realizar un seguimiento de las inversiones de
capital, monitorizar proyectos y contratos y mantener un control exhaustivo de
los gastos con información financiera en tiempo real.
- 150 -
3. Propuesta arquitectural y metodológica
?
Gestión de compras. Racionalizar la compra de productos y servicios y gestionar
todo el ciclo de compra.
La figura 3.20 muestra el modelo de procesos de este sector.
Clientes
Dirección
estratégica
Diseño e
ingeniería
Aprovisionamiento
Construcción
Operaciones
Proveedores
Planificación, ejecución y control de proyectos
Gestión de contratos
Desarrollo de proyectos
Gestión de oportunidades
Diseño base
Diseño detallado e ingeniería
Planificación de necesidades de compra
Gestión de compras
Recepción y seguimiento
Gestión de equipos
Gestión de flujos de trabajo y
Herramientas
Prefabricación y montaje
Marketing y ventas
Gestión de servicios
Gestión de alquileres
Figura 3.20 Modelo de procesos del sector ‘Ingeniería, Construcción y Operaciones’
Alta tecnología.
Las empresas de alta tecnología se caracterizan por una rápida innovación, gestión
del riesgo e investigación, aunque también gestionan los procesos típicos productivos,
desde el diseño y la planificación hasta el aprovisionamiento, fabricación, venta,
distribución y prestación de servicios. Su complejidad y alto coste obliga a asociaciones
y alianzas de todo tipo, entre competidores, fusiones, con proveedores, etc. Entre sus
funcionalidades clave encontramos:
? Gestionar productos a través de todo el ciclo de vida de los mismos, rastrear y
controlar toda la información de un producto a través de la cadena de suministro
extendida, tanto desde el desarrollo de productos (diseñadores, ingenieros) como
desde la fabricación (operarios, responsables de mantenimiento y almacenes).
? Gestión de la cadena de suministro. Coordinar la planificación, previsión y
producción.
? Análisis de mercados y clientes. Visión global que ayude a comprender
necesidades y a diseñar de una forma más efectiva los productos y servicios
futuros.
? Entorno colaborativo y asociativo. Intercambios de información particulares y
sectoriales para trabajar de forma fluida y eficaz en alianzas estratégicas, así
- 151 -
3. Propuesta arquitectural y metodológica
como con proveedores, subcontratas y clientes. Control de calidad de asociados
y suministradores.
Este sector, complejo, lo hemos dividido en tres tipos de negocios con características
y procesos particulares:
?
Fabricantes de equipos. Existe una amplia gama de productos y servicios, desde
equipamiento para monitorización y pruebas, hasta teléfonos móviles, equipos
médicos, ordenadores y equipos de conmutación. Se caracteriza por el diseño de
productos complejos y altamente configurables, la necesidad de previsión de la
demanda, distintos tipos de fabricación (stock, fabricación bajo pedido y
montaje bajo pedido) y la gestión de contratos de producción o de los servicios
de fabricación electrónica ampliando las competencias principales de fabricación
tradicionales. La figura 3.21 muestra el modelo de procesos de este negocio.
Clientes
Diseño
de producto
Ventas y
Marketing
Gestión de
orden
Gestión
suministro
Producción Distribución
Servicios
Proveedores
Introducción y desarrollo
de nuevos productos
Gestión de ciclo de vida
del producto
Ventas
Gestión de contratos
Programas clientes
Planificación de demanda y suministro
Producción distribuida
Logística
Calidad
Recepción
Compras estratégicas
y logísticas
Servicio postventa
Planificación de repuestos
Figura 3.21 Modelo de procesos del negocio ‘Fabricantes de equipos’
?
Fabricantes de semiconductores. El sector de los semiconductores es el motor
que hay detrás de las telecomunicaciones y la informática. Se caracteriza por
complejos procesos de fabricación, mercados altamente competitivos y clientes
exigentes. La figura 3.22 muestra el modelo de procesos de este negocio.
- 152 -
3. Propuesta arquitectural y metodológica
Clientes
Diseño
de producto
Ventas y
Marketing
Gestión
suministro
Producción
Distribución
Gestión de
orden
Proveedores
Innovación
Desarrollo de productos
Gestión de ciclo de vida
del producto
Planificación y gestión de ventas
Canales de venta
Marketing
Planificación de demanda y suministro
Producción distribuida
Logística
Calidad
Garantías y devoluciones
Gestión de órdenes y cuotas
Figura 3.22 Modelo de procesos del negocio ‘Fabricantes de semiconductores’
?
Proveedores de software. El software es un importante segmento dentro del
sector de la alta tecnología y, en un entorno en constante cambio que incluye
tecnologías emergentes, un rápido crecimiento y clientes exigentes. Su
característica más diferenciada es la gestión de un producto intangible y sus
dificultades añadidas, el control del ciclo de vida del producto y el control de
cambios y versiones. La figura 3.23 muestra el modelo de procesos de este
negocio.
Clientes
Diseño
de producto
Ventas y
Marketing
Gestión
de orden
Logística y
Distribución
Gestión de
licencias
Servicios
Proveedores
Concepto, especificación y
diseño
Gestión de programas
Gestión de calidad colaborativa
Planificación de ventas y previsiones
Gestión de oportunidades
Marketing
Canales de venta
Gestión de asociados
Facturación y rentabilidad
Gestión de precios y contratos
Gestión de órdenes
Servicio postventa
Gestión de licencias
Figura 3.23 Modelo de procesos del negocio ‘Proveedores de software’
- 153 -
3. Propuesta arquitectural y metodológica
Industria química.
Este sector tiene unos retos particulares, principalmente, la gestión de complejos
requisitos de fabricación, la gestión de precios para cumplir con las normativas de cada
país, las regulaciones gubernamentales, el manejo de mercancía peligrosa, previsión de
nuevos productos, grandes inversiones en investigación, gestión de recetas,
planificación de campañas y seguimiento y control de todo el ciclo de vida del producto,
desde el diseño hasta la distribución, contando con una compleja gestión del
almacenamiento y transporte. La figura 3.24 muestra el modelo de procesos de este
sector.
Clientes
Desarrollo
Planificaci ón
Suministro
Producci ón
Entrega
Venta y
Servicios
Proveedores
Desarrollo de productos
Investigaci ónc
Investigación
Compras estrat égicas
Gesti ón de pagos asociadas
Planificaci ón de la demanda y el suministro
Distribuci ón y transporte
Gesti ón de inventario
Log ística
Fabricaci ón
Planificaci ón de ventas
Gesti ón de órdenes
Gesti ón de oportunidades
Documentaci ón de producto
Gesti ón de reclamaciones
Gesti ón de calidad
Figura 3.24 Modelo de procesos del sector ‘Industria química’
Metal, Papel y Madera.
Este sector integra la gestión, bastante similar, de estos tres productos. Hoy día, las
compañías productoras, se mueven más allá de servicios y productos tradicionales,
incluyendo el uso de las nuevas tecnologías para mejorar la ejecución de negocios e
intensificar el servicio de atención al cliente. Comprende segmentos tales como:
materiales de construcción, papel y derivados forestales, muebles, fabricación de
productos de metal, metales primarios y textil. Entre sus principales objetivos se
encuentra maximizar la ejecución de su plan de producción, desarrollar la capacidad de
ventas online, personalizar productos y programas complejos, lanzar productos en el
- 154 -
3. Propuesta arquitectural y metodológica
mercado de forma más rápida, conseguir pedidos rentables y atraer y mantener clientes.
La figura 3.25 muestra el modelo de procesos de este sector.
Clientes
Diseño
de producto
Ventas y Planificación Aprovisio- Gestión de
Marketing
namiento
órdenes
Producción Distribución Proveedores
Introducción y desarrollo
de nuevos productos
Gestión del ciclo de vida
del producto
Planificación de demanda y suministro
Gestión del transporte
Aprovisionamiento estratégico y operacional
Gestión de almacenes
Gestión de órdenes de venta
Programación y ejecución de la producción
Envío directo
Servicio al cliente
Gestión de reclamaciones
Gestión de calidad
Figura 3.25 Modelo de procesos del sector ‘Metal, Papel y Madera’
Minería.
La minería se compone de múltiples procesos. Cada proceso presenta su propio
conjunto de retos. Hoy en día, es necesario hacer frente a estos retos en un contexto de
creciente regulación gubernamental, precios de consumo decrecientes y asuntos
relacionados con el medio ambiente, la sanidad y la seguridad. Cada vez más, las
operaciones de minería están recurriendo a la tecnología de la información para mejorar
su efectividad de gestión y aumentar su rentabilidad. Entre sus funcionalidades clave se
incluyen:
? Medio ambiente, salud y seguridad. Abarca la seguridad de los productos,
gestión de bienes peligrosos, higiene y seguridad en la industria y gestión de
residuos. Le permite integrar actividades de mantenimiento programadas,
preventivas y basadas en condiciones.
? Minería y distribución primaria. Mantiene, optimiza y recoge datos de
operaciones y calendarios de producción entregados.
? Ventas y distribución. Permite realizar un cálculo de precios exacto de
materiales a granel, muestras y ensayos múltiples, así como facturas múltiples.
La figura 3.26 muestra el modelo de procesos de este sector.
- 155 -
3. Propuesta arquitectural y metodológica
Clientes
Proyecto
Extracción
Procesado
Transporte
Marketing
Proveedores
Budget y previsiones
Gestión de riesgos
Planificación de la demanda
Gestión del transporte
Gestión de asociados
Gestión de contratos
Facturación
Planificación de la extracción
Planificación, ejecución y control
de la producción
Calidad
Gestión de almacenaje
Gestión de seguridad y medio ambiente
Mantenimiento preventivo
Gestión de la inversión
Logística remota
Aprovisionamiento estratégico
Figura 3.26 Modelo de procesos del sector ‘Minería’
Petrolíferas y Gas.
Este sector se dedica a la localización, extracción, transporte, refinamiento y
comercialización de hidrocarburos (petróleo y gas). Es un sector complejo y con
muchas implicaciones políticas y económicas externas, que debe mirar al futuro para
controlar gastos y planificar unos beneficios económicos sostenibles, a la vez que
aprovecha las situaciones. Entre las principales funciones se encuentran:
? Exploración y producción. Control de inversiones y gestión de plantas de
extracción situadas en lugares remotos.
? Refinado y marketing. Seguimiento de la información implicada en la
producción de combustibles, gas y lubricantes, así como el mezclado, las
actividades petroquímicas y el envasado.
? Distribución. Planificación de oferta y demanda, planificación de interconexión
y transporte, programación, planificación operacional y comunicación con los
transportistas.
? Estaciones de servicio. Red de comunicación y control de estaciones de servicio
con las oficinas centrales.
La figura 3.27 muestra el modelo de procesos de este sector.
- 156 -
3. Propuesta arquitectural y metodológica
Clientes Exploración
Desarrollo
Extracción
Refinado Distribución Gestión en Distribución
primaria
el terminal secundaria
Ventas
Proveedores
Exploración y sondeo
Gestión de contratos
Extracción
Sedimentación
Planificación y optimización
Programación de operaciones
Ejecución
Análisis e informes
Gestión de riesgos
Refinado
Monitorización y
control
Marketing
Gestión de ventas
Servicio al clientes
Gestión del transporte
Mantenimiento de planta
Aprovisionamiento
Gestión de la inversión
Logística
Figura 3.27 Modelo de procesos del sector ‘Petrolíferas y gas’
Sector farmacéutico.
El sector farmacéutico es cada vez más complejo y se ve afectado por factores
externos y gubernamentales. Incluye un importante control de inversión y gestión de la
investigación como factores diferenciales. Sus procesos principales son:
? Gestión de clientes. Estudio de clientes potenciales y de cuota de mercado.
Planificación y ejecución de campañas de ventas y marketing.
? Cadena de suministro. Fabricación ininterrumpida, planificación de suministro y
producción, manejo de mercancías peligrosas, registro de lotes, gestión de
unidades y de recetas y control de versiones.
? Gestión de contratos, presupuestos y devoluciones. Rapidez, cálculo de precios,
firma electrónica y registros de control, centros integrados para sistemas de
control de procesos y procesos automatizados para controlar la aprobación de
datos.
? Administración de I+D. Gestión del lanzamiento al mercado con planificación
global de proyectos, programación y seguimiento de hitos. Optimización de la
inversión con la gestión de cartera y colaboración e intercambio de información.
La figura 3.28 muestra el modelo de procesos de este sector.
- 157 -
3. Propuesta arquitectural y metodológica
Clientes
I+D
Operaciones
Distribución
Marketing
y Ventas
Servicios
Proveedores
Gestión de la investigación
Gestión de laboratorios
Pruebas clínicas
Gestión del suministro de pruebas
Actuaciones legales
Calidad de proveedores
Mantenimiento de equipos
Fabricación controlada
Planificación del suministro
Gestión de contratos
Gestión de demanda y previsiones
Marketing
Canales de venta
Estudios médicos
Gestión de calidad
Trazabilidad
Gestión de incidencias e informes
Figura 3.28 Modelo de procesos del sector ‘Farmacéutico’
Productos de consumo.
Es un sector cambiante y cada vez más exigente. Los compradores esperan mejores
productos, mayor variedad y un servicio más rápido y personalizado. En un instante
pueden surgir nuevos mercados (con cambios de estrategia y recursos) y a continuación
desaparecer. El mayor reto ir por delante en el mercado y responder a los exigentes y
cambiantes requisitos de los clientes de una forma rápida y rentable. Entre sus
principales procesos se incluyen:
? Ventas. Inclusión de nuevas tecnologías (móviles e internet). Buen acceso a la
información para clientes y empleados remotos. Canales de venta y perfiles de
cliente. Rapidez en la conversión de previsiones a pedidos. Facturación y
comisiones.
? Gestión de Promociones Comerciales. Planificar, ejecutar y analizar
promociones comerciales que maximicen resultados y minimicen costes.
? Gestión de categorías. Gestión rentable de todas las mercancías y selección de
todas sus categorías. Gestión de marcas. Marketing y análisis del rendimiento
por marcas y categorías. Configuración de precios y estrategias.
Dentro de este sector se encuentran negocios como: Alimenticio y Ropa y calzado;
Cuidado personal y del hogar; Electrónica de consumo. Todos ellos tienen unos
procesos bastante similares y se caracterizan por la rapidez, el cambio en los gustos del
- 158 -
3. Propuesta arquitectural y metodológica
consumidor, la necesidad de distribución, el control de calidad y la necesidad de
explotar nuevas tendencias. La figura 3.29 muestra el modelo de procesos de este sector.
Clientes
Estrategia
Producción
Mercado
Ventas
Servicios
Proveedores
Planificación
estratégica
Introducción y desarrollo de nuevos productos
Planificación de la demanda y del
suministro
Programación de la producción
Aprovisionamiento estratégico y
operativo
Pago a suministradores
Gestión de cuentas
Gestión de ventas
Estudios de mercado
Gestión de calidad
Logística
Figura 3.29 Modelo de procesos del sector ‘Productos de consumo’
Operadores logísticos.
Este sector se centra en la competencia en mercados globales. Gestiona procesos de
negocio como aprovisionamiento, almacenamiento, abastecimiento, devoluciones,
logística de valor añadido, facturación y atención al cliente, siendo los principales la
gestión de almacenes y de transportes. Cada vez integra servicios propios de sus
clientes, que le son subcontratados por lo que debe adaptarse a las necesidades
específicas de cada uno de ellos. Las funciones principales son:
? Gestión de clientes. Seguimiento de toda la información sobre socios y clientes,
gestionar su cartera de servicios y analizar su rentabilidad para poder centrarse
en los más rentables. Facilidades de obtención de información al cliente.
? Operaciones logísticas. Gestión del almacenamiento, el movimiento de las
mercancías desde el pedido hasta la facturación al cliente. Visibilidad sobre los
envíos y el inventario. Respuesta rápida a excepciones. Rendimiento de los
transportistas.
? Servicios de comercio global. Asegurar el cumplimiento de la normativa y de los
procesos de importación y exportación. Gestión del riesgo.
La figura 3.30 muestra el modelo de procesos de este sector.
- 159 -
3. Propuesta arquitectural y metodológica
Clientes
Estrategia
Aprovisionamiento
Planificación
y Ejecución
Ventas
Servicios
Proveedores
Aprovisionamiento de elementos de carga
Gestión de transporte
Gestión de almacenes
Estrategia de carga y de rutas
Gestión de repuestos
Análisis de oportunidades
Gestión de contratos
Seguimiento de clientes
Gestión de reclamaciones
Gestión de exportación/importación
Monitorización y control
Figura 3.30 Modelo de procesos del sector ‘Operadores logísticos’
Medios de comunicación.
El sector de los medios de comunicación está experimentando un cambio rápido y
radical impulsado en gran parte por Internet, la publicación online y la emisión digital.
Es importante sacar el máximo partido de cada una de las oportunidades que ofrecen las
tecnologías de comunicación existentes y emergentes. Las funcionalidades clave de este
sector son:
? Ventas y Distribución. Clasificación de productos por canales de distribución.
Orientarse a nichos de mercado.
? Gestión de publicidad. Venta, reserva y facturación de anuncios en cualquier
medio.
? Desarrollo de productos. Desarrollo de contenidos y productos específicos para
cada medio de comunicación coordinando todo el ciclo de vida del producto.
Ofrecer productos y servicios personalizados.
? Gestión de la propiedad intelectual. Gestión exhaustiva, integrada e
interempresarial de la propiedad intelectual. Contabilidad y auditoria precisas
para el cobro de derechos de autor. Gestión de contratos de adquisición y venta
de la propiedad intelectual disponible.
Dentro de este sector distinguimos dos negocios con procesos diferentes:
?
Comunicación. Incluye radio y televisión, periódicos y revistas y
entretenimiento (principalmente cine y espectáculos). La figura 3.31 muestra el
modelo de procesos de este negocio.
- 160 -
3. Propuesta arquitectural y metodológica
Clientes
Estrategia
Creación
Planificación
Ventas
Entrega
Proveedores
Gestión de canales
Gestión de programas
Gestión de derechos
Adquisición de contenidos
Gestión de la producción
Gestión de los recursos
Adquisición de servicios
Ventas por canales
Gestión de audiencias
Emisión
Licencias y productos asociados
Figura 3.31 Modelo de procesos del negocio ‘Comunicación’
?
Publicidad. La figura 3.32 muestra el modelo de procesos de este negocio.
Clientes
Desarrollo
Producción
Distribución
Proveedores
Gestión editorial
Gestión de autores
Planificación y control financiero de nuevo producto
Fabricación y gestión de planta
Gestión de inventario
Gestión de cuentas y contratos
Gestión de campañas
Gestión de suscripciones
Gestión de licencias
Seguimiento de clientes
Control de anuncios
Figura 3.32 Modelo de procesos del negocio ‘Publicidad’
Servicios profesionales.
Este sector es muy variado pero se caracteriza por la gestión de empresas de muy
diversos tamaños, a veces muy pequeñas, que proporcionan servicios muy
determinados. En este sector se incluyen despachos de abogados y de consultoría de
todo tipo. Sus funciones incluyen la definición de tarifas, gestión de contratos, búsqueda
y relaciones con consultores adecuados y con el personal y gestión de costes y facturas.
Entre los procesos de negocio que utiliza destacamos:
? Ventas y marketing. Definición de objetivos y gestión de oportunidades.
- 161 -
3. Propuesta arquitectural y metodológica
?
?
?
?
Gestión de recursos. Asignación de las personas correctas al proyecto adecuado
y en el momento oportuno.
Determinación de precios y contratos. Tarifas, ofertas y licitaciones. Gestión de
contratos y su flujo de ingresos.
Ejecución y gestión de proyectos. Planificación, ejecución, gestión y análisis de
proyectos. Costes por proyecto.
Gestión de proyectos. Con acceso a historiales de clientes y proyectos, a la vez
que fomenta la colaboración efectiva y la transferencia de conocimientos.
La figura 3.33 muestra el modelo de procesos de este sector.
Clientes
Estrategia
Desarrollo
Infraestructura
Entrega
Gestión
Gestión
asociados
Proveedores
Estrategia y planificación
Adquisición de clientes
Gestión de clientes
Gestión de proyectos
Gestión de recursos por proyecto
Contratos
Soporte a clientes
Facturación
Formación
Gestión de documentos
Gestión de órdenes
Seguimiento de proyectos
Contabilidad
Gestión de la subcontrata
Figura 3.33 Modelo de procesos del sector ‘Servicios profesionales’
Distribución comercial.
Servicio más flexible y de calidad, mayor exigencia del cliente, gestión de
inventarios, distribución y reposición, gestión de múltiple canales de venta y de mano
de obra. Estas son algunas características que deben cumplir varios segmentos de
mercado que se encuadra en este sector y que destacamos, no por tener procesos
diferentes, si no por su importancia y extensión: las empresas de alimentación, deben
centrarse en la distribución rápida y adecuada, la disminución de stocks y el análisis de
previsiones y carga de trabajo; las empresas de bienes de consumo duraderos, se centran
más en un servicio al cliente personalizado y la gestión de precios; las empresas textiles
- 162 -
3. Propuesta arquitectural y metodológica
incluyen la gestión por temporadas y la distribución multicanal. La figura 3.34 muestra
el modelo de procesos de este sector.
Clientes
Planificación
Productos
asociados
Compras
Distribución
Ventas
Proveedores
Modelado de demanda y
previsiones
Gestión de productos asociados
Planificación y optimización de
precios y promociones
Gestión de órdenes de venta
Gestión de compras
Importación/Exportación
Inventario
Gestión de almacenes
Gestión de transportes
Canales de distribución
Trazabilidad
Catálogos
Soporte a clientes
Facturación
Gestión de puntos de venta
Contabilidad
Figura 3.34 Modelo de procesos del sector ‘Distribución comercial’
Telecomunicaciones.
Sector en constante evolución: desregulación, banda ancha, comunicaciones móviles,
e-business, etc. Las funcionalidades clave incluyen:
? Gestión de relaciones con clientes. Actividades que van desde el marketing hasta
los servicios, pasando por las ventas. Su objetivo principal es aumentar la lealtad
de los clientes y los ingresos por cliente mediante la oferta de productos y
servicios personalizados, sin olvidar captar nuevos clientes desde otros
segmentos.
? Contabilidad de contratos. Función compleja en este sector por la variedad de
posibilidades y tarifas.
? Facturación convergente. Igualmente, proceso complejo y personalizado.
Facturación de múltiples productos y descuento entre productos.
La figura 3.35 muestra el modelo de procesos de este sector.
- 163 -
3. Propuesta arquitectural y metodológica
Clientes
Diseño de
Operación de
infraestructura infraestructura
Desarrollo
Venta
Facturación
Servicios
Proveedores
Planificación, inversión,
mantenimiento y operación
de infraestructuras
Marketing
Planificación,
gestión y
desarrollo de
productos
Gestión de órdenes y ventas
Logística
Facturación
Previsiones
Distribución
Auditoria
Contabilidad
Atención al
clientes
Reclamaciones
Figura 3.35 Modelo de procesos del sector ‘Telecomunicaciones’
Servicios públicos.
Las empresas tradicionales de servicio público se están adaptando a las nuevas
tecnologías, la liberalización y las preocupaciones medioambientales lo que se traducen
en proyectos más complejos y en clientes que eligen lo más rápido, lo más barato y la
mayor flexibilidad en las relaciones con los proveedores. Abarca procesos diferentes,
desde la generación hasta la transmisión y distribución, instalación y gestión de
ingresos. Sus retos principales son mejorar la atención al cliente, perfeccionar la
seguridad, aumentar la amortización de las inversiones y salvaguardar la rentabilidad.
Entre sus funciones destacamos:
? Gestión de relaciones con los clientes, centros de soporte y ayuda, comunicación
rápida y por nuevos medios (internet, móvil, etc.).
? Planificación y mejora de la utilización de recursos humanos, como revisiones,
reparaciones, lectura de contadores, etc. Uso de nuevas tecnologías de apoyo al
personal, como ordenadores portátiles, de mano y dispositivos WAP.
? Facturación flexible. Personalización de los procesos de facturación para
adaptarse a las necesidades de cada cliente. Facturación separada y consolidada
de acuerdo con los requisitos locales de liberalización.
? Gestión de datos de energía. Creación de perfiles de carga y datos de consumo.
? Generación de informes y estudios legales según el entorno local y nacional.
- 164 -
3. Propuesta arquitectural y metodológica
Hemos subdividido este sector en varios negocios lo suficientemente importantes
para considerarlos de forma separada:
?
Electricidad, agua y gas. La figura 3.36 muestra el modelo de procesos de este
negocio.
Clientes
Explotación
Distribución
Servicios
Proveedores
Ingeniería y construcción
de planta
Operaciones y
mantenimiento de planta
Ingeniería y construcción
de red
Operaciones y
mantenimiento de red
Gestión de conexiones
Gestión de recursos
Gestión de inventario
Suministro
Gestión de contadores
Ventas industriales y
residenciales
Análisis de ventas
Facturación industrial y
residencial
Soporte al cliente
Gestión de reclamaciones
Auditoria
Figura 3.36 Modelo de procesos del negocio ‘Agua y gas’
?
Reciclaje y gestión de residuos. La figura 3.37 muestra el modelo de procesos de
este negocio.
- 165 -
3. Propuesta arquitectural y metodológica
Clientes
Estrategia
Órdenes
Plantas
Servicios
Proveedores
Análisis de mercado
Planificación de
actividad
Gestión de cuentas
Análisis de ventas
Gestión de contratos
Planificación de servicios
Gestión de flotas y contenedores
Compras estratégicas y operativas
Ingeniería, construcción, mantenimiento y
operaciones de planta
Facturación
Auditoria
Gestión financiera
Atención al clientes
Gestión de reclamaciones
Figura 3.37 Modelo de procesos del negocio ‘Reciclaje y gestión de residuos’
?
Servicios postales. La figura 3.36 muestra el modelo de procesos de este
negocio.
Clientes
Planificación
Entrega
Operaciones
Gestión de cuentas
Atención al cliente
Campañas
Gestión de reclamaciones
Planificación y gestión de promociones
Inventario
Gestión de almacenes
Gestión de precios y beneficios
Compras estratégicas y operativas
Gestión de contadores
Trazabilidad
Planificación de redes de distribución
Distribución
Gestión del transporte
Figura 3.38 Modelo de procesos del negocio ‘Servicios postales’
- 166 -
Proveedores
3. Propuesta arquitectural y metodológica
?
Ferrocarriles. La figura 3.39 muestra el modelo de procesos de este negocio.
Clientes
Estrategia
Aprovisionamiento
y Ventas
Operaciones
Servicios
Proveedores
Análisis de mercado
Planificación de
actividad
Gestión de subcontratas
Compras estratégicas y operativas
Movimiento de mercancías
Gestión de órdenes
Gestión de almacenamiento
Reserva y venta de billetes
Administración y control de estaciones
Contabilidad
Desarrollo y utilización de infraestructura
Gestión de rutas
Campañas
Marketing
Soporte al clientes
Gestión de reclamaciones
Figura 3.39 Modelo de procesos del negocio ‘Ferrocarriles’
Distribución mayorista.
En este entorno encontramos tanto empresas medianas como grandes distribuidores
mayoristas de una amplia gama de sectores industriales, entre los que se encuentran
alimentación, industrial o la asistencia sanitaria. Las funcionalidades clave para dar
soporte a este sector son:
? Planificación estratégica, planificación de marketing y de las ventas y los
servicios que consigan la fidelización de los clientes a través de varios canales
de ventas y servicios.
? Planificación de la cadena de suministro a medio plazo. Es posible realizar una
planificación de la demanda y del suministro para mantener o mejorar los
niveles de servicio, reducir la inversión en stock e identificar las tendencias a
corto y a medio plazo. Las previsiones de capacidad contribuyen a la utilización
óptima y rentable de las flotas de transporte.
? Gestión con los proveedores desde el aprovisionamiento al pago.
? Gestión de almacenes, complejos procesos de entrada y de salida de mercancías.
La figura 3.40 muestra el modelo de procesos de este sector.
- 167 -
3. Propuesta arquitectural y metodológica
Clientes
Marketing
Planificación
Suministro
Logística
Ventas
Proveedores
Planificación de asociados
Marketing
Planificación de la demanda y
el suministro
Planificación del transporte
Gestión de proveedores
Compras
Inventario
Gestión de almacenes
Gestión de transportes
Gestión y soporte a clientes
Proceso de órdenes
Facturación
Servicios generales
Servicios de valor añadido logísticos y financieros
Figura 3.40 Modelo de procesos del sector ‘Distribución mayorista’
Entidades financieras.
El sector bancario, genéricamente, se enfrenta a una economía global, cada vez más
competitiva, clientes cada vez más exigente y volátiles, cambios en la legislación,
fusiones, extensión de las operaciones bancarias a Internet, etc. Podemos distinguir tres
grandes grupos de funciones: la gestión bancaria orientada al cliente, el núcleo de la
gestión bancaria y la gestión empresarial:
? Gestión de las relaciones con el cliente. Marketing dirigido a grupos específicos
de clientes con el soporte de amplias herramientas analíticas. Gestión rápida y
eficaz de la información sobre cada cliente. Flexibilidad, adaptación y rapidez de
respuesta. Integración de gestión por Internet.
? Actividades principales del sector bancario. Procesamiento de transacciones
orientado al cliente, en tiempo real y de una forma más rápida y rentable. Mayor
rapidez en el desarrollo y la introducción de nuevos productos y servicios
mediante una amplia gama de canales de distribución. Infraestructura escalable y
flexible. Adaptación a normativas, control y auditorias.
? Gestión empresarial. Aumento de la rentabilidad mediante toma de decisiones
empresariales basadas en información consistente. Identificar, medir y gestionar
los riesgos del mercado y de demora en toda la entidad. Simulaciones de
pérdidas y ganancias, liquidez, posicionamiento global de activos y cálculo del
valor actual neto en cualquier período de tiempo y en cualquier tipo de
escenario.
- 168 -
3. Propuesta arquitectural y metodológica
La figura 3.41 muestra el modelo de procesos de este sector.
Clientes
Ventas y Mercado
Productos
Negocio
Asociados
Definición de nuevos productos
Monitorización de productos
Análisis de mercado
Campañas de atracción de clientes
Gestión y servicio al cliente
Gestión de operaciones
financieras
Gestión de depósitos y cuentas
Contabilidad
Previsión y análisis de riesgos
Gestión de carteras
Informes legales
Estrategia corporativa
Contabilidad interna
Auditoria
Figura 3.41 Modelo de procesos del sector ‘Entidades financieras’
Entidades aseguradoras.
Este sector agrupa a compañías de seguros de diversos tamaños y entornos. Los
consumidores exigen cada vez más productos personalizados, adaptados a sus
necesidades individuales y un alto nivel de servicio. Su objetivo principal, por tanto, es
el cliente: desde el primer contacto hasta la gestión de pólizas y productos, las
recaudaciones y desembolsos y la gestión de reclamaciones. Todo esto sin olvidar el
control de costes y rendimiento. Incluye las siguientes funciones:
? Gestión de cobros y pagos. Varias modalidades de pagos y cobros. Gestión de
procedimientos de reclamaciones. Calculo de intereses de planes de
reclamaciones y pagos fraccionados. Soporte a cobros realizados por
intermediarios.
? Gestión de incentivos y comisiones. Múltiples formas de remuneración de las
ventas, incluyendo comisiones, honorarios de corretaje, participación en los
beneficios y bonificaciones. Cálculo de comisiones e incentivos mediante
objetos (por ejemplo, pólizas de seguros), actividades (ventas, renovaciones o
cancelaciones) o atributos (por ejemplo tipo de cobertura del seguro, duración de
la póliza o importe de la prima).
? Gestión de reclamaciones: Gestión rápida e integrada de reclamaciones con
procesos de cobros y pagos. Comunicación con peritos.
? Gestión de pólizas y productos. Gestión de la información sobre pólizas y
productos relacionada con tarifas, comisiones, cancelaciones, etc.
- 169 -
3. Propuesta arquitectural y metodológica
?
?
Gestión de Reaseguros. Coordinación con asociados. Gestión de todo tipo de
reaseguros (internos y externos; proporcionales y no proporcionales; facultativos
y obligatorios; pasivos y activos). Cálculo y liquidación de primas y resolución
de reclamaciones según estándares internacionales.
Gestión de las relaciones con los clientes. Entorno colaborativo de intercambio
de datos sobre clientes entre compañías asociadas. Facilitar al cliente el acceso a
información propia o sobre la compañía a través de nuevos canales de
comunicación.
La figura 3.42 muestra el modelo de procesos de este sector.
Clientes
Definición
Desarrollo
Aseguración
Gestión
Beneficios
Riesgos
Asociados
Estudios de mercado
Desarrollo de productos
Gestión del ciclo de vida
del producto
Gestión de vendedores
Análisis de clientes
Planificación y control de
ventas
Definición y gestión de
políticas de seguros
Análisis e informes
Gestión y recuperación
de reclamaciones
Gestión de reaseguros
Auditoria
Contabilidad
Gestión
financiera
Manejo de
cuentas
Figura 3.42 Modelo de procesos del sector ‘Entidades aseguradoras’
Sanidad.
La asistencia sanitaria es un sector complejo y delicado, en el que el control de
calidad y las inversiones son cruciales. Entre los procesos clínicos y administrativos
destacamos:
? Gestión de pacientes. Gestionar y coordinar la asistencia al paciente, desde la
preinscripción y la asignación de camas hasta el alta del paciente, pasando por
diagnósticos y terapias. Gestión de documentación privada. Gestión de donantes.
Facturación.
? Gestión de personal. Formación, turnos, intercambios con médicos externos y
expertos, planificación de recursos. Compartir recursos y procesos con otros
organismos.
- 170 -
3. Propuesta arquitectural y metodológica
?
Logística de hospitales. Gestión de almacenes. Control de materiales peligrosos.
Gestión de compras, administrativa y de contabilidad. Mantenimiento de
instalaciones. Gestión de costes. Simplificar sus procesos administrativos,
financieros y de aprovisionamiento Reducir costes gracias a un bajo coste total
de propiedad, ciclos de facturación y cobro más rápidos y gestión eficaz de
RRHH
Teniendo en cuenta sus procesos vamos a dividir este sector en dos negocios con
funciones diferentes:
?
Redes de salud colaborativas. Incluye relaciones entre hospitales, sector
farmacéutico, salud pública, fundaciones, laboratorios y asistencia social. La
figura 3.43 muestra el modelo de procesos de este negocio.
Clientes
Regulación
Planificación
Prevención
Tratamiento
Control
Proveedores
Investigación y desarrollo
Planificación del staff médico
Relación entre las instituciones
Budget
Planificación y puesta en marcha de programas de
prevención de salud pública
Planificación de servicios
Información y servicio al
ciudadano y pacientes
Gestión colaborativa de pacientes
Gestión integrada de diagnostico,
tratamiento y cuidados
Gestión de calidad colaborativa
Adquisición de medicamentos
Monitorización de los resultados
médicos
Análisis e informes
Figura 3.43 Modelo de procesos del negocio ‘Redes de salud colaborativas’
?
Hospitales. Incluye funciones logísticas, gestión de ambulancias y pacientes. La
figura 3.44 muestra el modelo de procesos de este negocio.
- 171 -
3. Propuesta arquitectural y metodológica
Clientes
Estrategia
Recursos
Tratamiento
Gestión
Proveedores
Análisis e informes sobre necesidades
médicas
Gestión de relaciones con asociados
Budget
Gestión de recursos humanos
Logística
Control de costes
Actividades médicas
Documentación
Coordinación de diagnóstico, tratamiento y cuidados
Planificación de la prevención y del seguimiento
Servicio y gestión de pacientes
Facturación
Programación de recursos
Control de precios
Figura 3.44 Modelo de procesos del negocio ‘Hospitales’
Educación superior e Investigación.
Las instituciones de enseñanza superior y de investigación deben realizar sus
actividades sin abandonar la racionalización de los procesos, la mejora del desarrollo
académico y la gestión de los presupuestos y de las subvenciones. Las instituciones de
enseñanza superior se encuentran bajo una presión sin precedentes: Responder a las
necesidades de estudiantes y empleados, hacerse cargo de las demandas de una reforma
educativa, ajustar los presupuestos sin perder adaptabilidad y aprovechar las
oportunidades de ingresos por subvenciones. Sus funciones principales se refieren a:
? Gestión del Campus, que incluye enseñanza, planificación de eventos, alumnos,
administración, gestión del personal, de la organización y de los puestos de
trabajo.
? Investigación. Incluye necesidades diferentes de la gestión de la enseñanza:
grupos de investigación, patentes, publicaciones, intercambios de personal y de
información entre centros, etc.
? Gestión de compras y gestión de materiales, verificación de facturas y gestión
del almacén.
? Enlaces directos con funcionalidades de gestión de fondos, contabilidad
financiera y contabilidad gerencial. Gestión presupuestaria y financiera completa
de toda la institución. Control de costes y análisis de retorno de la inversión.
? Gestión del conocimiento que abarca el acceso, creación y edición Web,
evaluación del rendimiento, gestión documental, herramientas de flujos de
trabajo y trabajo en grupo.
- 172 -
3. Propuesta arquitectural y metodológica
?
Inclusión de técnicas, herramientas y métodos de e-learning, posibilitando
enseñanza, seguimiento y evaluación personalizada, así como acceso a alumnos
geográficamente alejados o aislados.
Como se desprende de la lista de funciones anteriores vamos a dividir este sector en
dos negocios con procesos y características diferentes:
?
Educación superior. La figura 3.45 muestra el modelo de procesos de este
negocio.
Clientes
Estrategia
Recursos
Operación
Estudios
Financiación
Proveedores
Análisis de mercado
Desarrollo y comunicación institucional
Gestión de alumnos
Gestión de asociados
Planificación estratégica de recursos y estudios
Gestión de alumnos
Financiación externa y de alumnos
Procesos de admisión y expansión
Servicios académicos
e-Learning
Programación de clases
Gestión de recursos humanos
Servicios de campus
Gestión de bibliotecas y recursos multimedia
Servicios de tecnologías de la información
Figura 3.45 Modelo de procesos del negocio ‘Educación superior’
?
Investigación. La figura 3.46 muestra el modelo de procesos de este negocio.
- 173 -
3. Propuesta arquitectural y metodológica
Centros
Estrategia
Patentes
Evaluación
Proyectos
Comunicación Patrocinadores
Análisis de mercado
Planificación estratégica de recursos
Gestión de grupos de investigación
Política y comunicación institucional
Análisis de oportunidades
Desarrollo de propuestas
Gestión de fondos
Evaluación institucional
Administración y gestión de proyectos
Desarrollo de la investigación
Servicios y soporte a la investigación
Compras
Programas de seguridad y salud
Gestión de la propiedad intelectual
Comunicación y apoyo social
Gestión de conferencias, jornadas y seminarios
Figura 3.46 Modelo de procesos del negocio ‘Investigación’
Sector público.
Es un sector en el que el servicio al ciudadano es la clave. Desde la gestión de
impuestos e ingresos hasta los servicios electorales o la gestión de peticiones y recursos.
Es un sector que abarca múltiples tareas. Adaptarse a las nuevas tecnologías,
comunicación entre administraciones y con el ciudadano y los proveedores. Funciones y
características clave:
? Gestión del ciudadano. Servicios de intercambio de información. Gestión de
registros.
? Gestión de impuestos e ingresos. Contabilidad, pagos y facturación.
? Finanzas y administración. Gestión integrada de fondos, gestión de subvenciones
y gestión de recursos humanos. Gestión de costes. Gestión de proveedores.
? Gestión de bibliotecas y archivos.
? Gestión de recursos. Mantenimiento de instalaciones y equipos y también la
administración de propiedades.
La figura 3.47 muestra el modelo de procesos de este sector.
- 174 -
3. Propuesta arquitectural y metodológica
Ciudadanos
Estrategia
Operación
Servicios
Administración
Previsión y planificación de operaciones
Gestión de recursos humanos
Ofertas y concursos públicos
Administración y gestión de contratos
Compras estratégicas y operativas
Formulación, preparación y ejecución del budget
Administración, financiación y gestión de la seguridad
social y los servicios sociales
Gestión de subvenciones y concesiones
Preparación y difusión de programas de gobierno
Auditoria
Gestión financiera
Gestión de tasas e impuestos
Figura 3.47 Modelo de procesos del sector ‘Sector público’
Después de haber detallado la clasificación jerárquica y para finalizar, controlaremos
como la taxonomía creada cumple con unas características que garantizan su fiabilidad,
precisión y continuidad:
? Debe poseer características clave. En general, deben considerarse al clasificar,
las características más útiles, aquellas que miden las similitudes relevantes
teórica y prácticamente entre estrategias de empresa. Dado que la taxonomía
integra grandes grupos de empresas, algunas características se han considerado
prioritarias para su selección: describen objetivos principales de una empresa,
diferencian según tecnología desarrollada y según segmentos de mercado
objetivo y tipo de competencia.
? Debe permitir clasificar generalmente. A pesar de que la clasificación es
efectuada en referencia a una finalidad muy concreta, el horizonte es muy
amplio, como hemos visto al detallar los objetivos de un sistema ERP y la
clasificación abarca muchas situaciones y entornos. Además, el estudio permite
realizar predicciones sobre comportamientos de entidades en distintas
situaciones y almacenar y recuperar fácilmente los datos elaborados.
? Debe ser parca, escueta. Se utiliza el número de tipos necesarios. A menor
número de tipos se logrará mayor reducción de complejidad, claridad y
precisión. Por otro lado puede llevar a simplificar datos y unirlos en un mismo
grupo, cuando sería posible diferenciarlos al identificarlos con tipos distintos. Se
- 175 -
3. Propuesta arquitectural y metodológica
ha buscado un equilibrio entre simplificación y diferenciación, teniendo en
cuenta que una jerarquía excesiva sería inútil para nuestros fines, ya que
empresas concretas no se verían reflejas en la totalidad.
? Debe ser jerárquica. Se denomina clasificación jerárquica si contiene dos o más
niveles de tipos. Cada nivel se constituye agrupando entidades según diversos
tipos que se caracterizan por atributos similares. Nuestra taxonomía incluye
como mínimo dos niveles jerárquicos para cada tipo.
? Debe ser atemporal. No es posible buscar clasificaciones que vayan más allá de
situaciones y períodos históricos, pero esta taxonomía garantiza que la tipología
es estable a lo largo de un periodo. Taxonomías sectoriales similares llevan
realizándose desde los años 80 y continúan en la actualidad.
3.2.2. Modelización de procesos
La modelización de procesos de negocio se ha convertido en uno de los focos
principales de atención de la Ingeniería de Sistemas Informáticos para crear eficiencia,
calidad y satisfacción en el cliente. El modelado de procesos se utiliza para planificar,
diseñar, simular y ejecutar automáticamente los procesos de negocio. Este creciente
interés se ha concretado en la aparición de varios lenguajes y técnicas de modelado de
procesos, cada uno de ellos define y usa conceptos de manera diferente e, incluso,
ambigua, por lo que compararlos e integrarlos resulta difícil. Antes de entrar en el
estudio de estos modelos, repasaremos algunos conceptos básicos relacionados.
Un proceso de negocios es una cadena de actividades individuales cuya suma
produce resultados valiosos para el cliente, que puede ser externo o interno. La suma de
todos los procesos de negocio o cadena de valor agregado (value-added chain)
representa la globalidad de los procesos operacionales. La estructuración de tareas
orientada a procesos, a través de la cadena de valor agregado, cambia la división del
trabajo, así como la visión de empleados y organización como un todo, en los aspectos
de integración de tareas y localización de la toma de decisiones, redistribución de la
división del trabajo y minimización de interfaces. Solo el registro de todas las
operaciones relevantes en un sistema, usando tecnología de procesamiento de datos y
permitiendo el acceso general a esta información, permite procesos de negocio
uniformes. Solo un sistema que incluye todas las funciones operativas y reproduce esta
información utilizando una base de datos única y agregada es capaz de manejar la
gestión de procesos integrados.
- 176 -
3. Propuesta arquitectural y metodológica
El modelo de referencia es una estructura de datos que contiene la descripción de un
sistema y los procesos y funciones contenidos en él. Usando un modelo de referencia es
posible simular los procesos dentro de un sistema. En el caso de los sistemas ERP el
modelo de referencia contiene las estructuras de los procesos de negocio comunes. Por
ejemplo para el ERP SAP R/3 esta estructura viene dada por la jerarquía que representa
la figura 3.48
Modelo de referencia
Área
Escenarios
Procesos
Funciones
Figura 3.48 Jerarquía del modelo de referencia en SAP R/3
El modelado de procesos, en este caso, implica:
? Organizar la compañía en una jerarquía de negocios, incluyendo todas las
funciones de la compañía de acuerdo a las estructuras de negocios de SAP R/3;
? Identificar donde encaja cada proceso dentro de la jerarquía e incluirlos en el
mapa;
? Definir el alcance de las tareas incluyendo frecuencia y uso de recursos.
La mayoría de los lenguajes y técnicas de modelado de procesos incluyen cuatro
conceptos básicos: actividad, estado, evento y tiempo. Una actividad es la ejecución de
una acción corta que cambia el estado del objeto de la acción. Un estado es un conjunto
de propiedades de un objeto. Un evento es el resultado de una acción. Finalmente, el
tiempo se refiere a un instante temporal. Estos elementos están relacionados ya que la
actividad se realiza en un tiempo y tiene como consecuencia un evento que produce un
cambio de estado. Igualmente un evento puede inducir la ejecución de una actividad en
un tiempo. Las relaciones entre estos conceptos marcan, a menudo, diferencias entre las
técnicas de modelado. La relación más intuitiva es considerar un evento como un
conector que conecta estados y actividades en un tiempo dado. La figura 3.49 ilustra
esta relación.
- 177 -
3. Propuesta arquitectural y metodológica
Actividad
Estado
Evento
Tiempo
Figura 3.49 Relación intuitiva entre los principales conceptos del modelado de
procesos
Con relación al resto de elementos, actividades, estado y tiempo, los eventos pueden
ser de varios tipos:
? Eventos que ocurren en un instante de tiempo o entre dos instantes de tiempo.
Por ejemplo un evento instantáneo será la aprobación de una orden de
producción y un evento de duración, la obtención del paquete de expedición de
un albarán, que pasará de vacío a lleno en un período de tiempo.
? Eventos que registran el principio de una actividad (precondiciones) o el final de
una actividad (poscondiciones). Por ejemplo una precondición será la
autorización para la emisión de un pedido de compras y una poscondición la
obtención de un material resultado de una ruta de producción.
? Eventos que tienen como consecuencia un cambio de estado o no. Por ejemplo la
aprobación de una orden de producción tiene como consecuencia un cambio de
estado en la orden de producción, pero la modificación del lead-time de un
producto (o tiempo necesario desde su inicio de producción o compra hasta su
entrega en el almacén) no comporta ningún cambio de estado.
Además de estos conceptos principales en el modelado de procesos existen otros
secundarios, como son:
? Recursos, son los utilizados y necesarios por ciertas actividades para su
realización.
? Roles, son un tipo especial de recurso ya que se refieren a la persona responsable
de la ejecución de una actividad.
? Dependencias lógicas, son las que forman la cadena de valor agregado de
procesos, relacionando las actividades entre sí.
- 178 -
3. Propuesta arquitectural y metodológica
? Actores, son entes externos a la actividad que se relacionan con ella de alguna
manera, reciben sus resultados o contribuyen a su realización.
Finalmente la información semántica asociada a los procesos debe poder ser también
representada en su modelado. Esta se refiere a los pronombres interrogativos:
?
?
?
?
?
?
Qué, los datos importantes del proceso.
Cómo, las principales acciones del proceso.
Dónde, los lugares donde se desarrolla el proceso (sedes, áreas, plantas, etc.).
Quién, personas u organizaciones involucradas en el proceso.
Cuándo, momento o intervalo temporal durante el que se desarrolla el proceso.
Porqué, motivación del proceso, asociada con los objetivos y la estrategia del
negocio.
Antes de pasar a analizar las técnicas de modelado, veamos que características tienen
que cumplir para ser una buena herramienta según [Davenport, 1993]:
? Debe ser fácil y rápido de utilizar en un alto nivel de abstracción y por no
expertos, incluyendo posibilidades gráficas;
? Debe ser posible y sencillo establecer comparaciones entre procesos diferentes y
entre versiones del mismo proceso, que permitan la toma de decisiones;
? Debe proporcionar facilidades descriptivas y analíticas, incluyendo información
sobre recursos, tiempos, roles, motivaciones, etc.;
? Debe soportar sucesivos niveles de detalle permitiendo modelos paso a paso que
puedan ser utilizados en simulaciones y prototipos.
Veamos ahora algunas de las principales técnicas de modelado existentes, las
compararemos y detallaremos la elegida para nuestra propuesta. Event-driven Process
Chains (EPC), Diagramas de estado de Unified Modelling Language (UML) y Business
Modelling Language (BML) son diferentes técnicas de modelado de procesos que
corresponden con otras tantas tendencias en la materia: orientación a actividades,
orientación a estados y orientación a comunicación, es decir, a las relaciones entre
personas y sistemas o entre sistemas. Cada una de las técnicas seleccionadas se
considera representativa de su respectiva categoría.
Event-driven Process Chains (EPC) es una representación gráfica con información
adicional. Utiliza nodos activos llamados funciones y pasivos llamados eventos. Los
- 179 -
3. Propuesta arquitectural y metodológica
eventos describen la situación antes y después de la ejecución de cada función. No
representa de forma explícita el concepto de estado. Las dependencias lógicas entre
funciones y eventos se describen utilizando los conectores lógicos AND, OR y XOR y
las flechas de control. Las funciones pueden llevar asociada información adicional
desde diferentes puntos de vista: datos asociados, actividades, organización y salidas.
La figura 3.50 muestra un ejemplo de representación en el que los eventos ‘orden
recibida’ y ‘fecha de producción alcanzada deben ocurrir antes de ejecutar la función
‘fabricación’. Una vez que esta ha concluido se producen dos eventos: ‘orden ejecutada’
y ‘producto en almacén’.
Fecha de
producción
alcanzada
Orden recibida
AND
Fabricación
AND
Producto en
el almacén
Orden
ejecutada
Figura 3.50 Ejemplo de representación de procesos mediante EPC
Diagrama de estado de Unified Modelling Language (UML) es un tipo de diagrama
del estándar UML mantenido por el Object Management Group (www.omg.org). Estos
diagramas son una representación gráfica de una máquina de estados y visualiza bajo
que circunstancias un elemento del sistema, clase o proceso, cambia de estado. Incluyen
estados, transiciones entre estados, un estado inicial, uno o más estados finales y
eventos y actividades como textos asociados. Los estados pueden tener tres
componentes: nombre, variables o datos asociados y actividades. Las actividades
pueden ocurrir al entrar en el estado, durante el estado o al salir del estado. Los estados
que no tienen actividades son estados de espera. Las transiciones entre estados son
pasos de un estado a otro y ocurren cuando se cumplen ciertos eventos. La figura 3.51
muestra el mismo proceso de la figura 3.50 representado como un diagrama de estado
de UML.
- 180 -
3. Propuesta arquitectural y metodológica
Orden recibida y fecha de
producción alcanzada
Fabricar
Producto en almacén y
orden ejecutada
Figura 3.51 Ejemplo de representación de procesos mediante diagramas de estado de
UML
Business Modelling Language (BML) describe la interacción entre sistemas a través
del envío y recepción de mensajes. Además de usarse para la ejecución de sistemas se
puede utilizar para especificar y diseñar procesos de negocio. BML describe la
estructura y conocimiento de un sistema con dos tipos de diagramas: Business Process
Integracion o BPI que muestra la estructura del sistema en cuanto a componentes y la
comunicación entre el sistema y elementos externos y agentes humanos; Business
Integration Application o BIA que describe el conocimiento dinámico del sistema,
visualizando los mensajes que envía y recibe, las reglas para manejarlos y las
actividades a ejecutar dependiendo del contenido de los mismos. Los diagramas de tipo
BIA pueden representar mensajes recibidos, mensajes enviados, estados y actividades.
La figura 3.52 muestra el mismo proceso de la figura 3.50 representado como un
diagrama tipo BIA de BML. Los estados se representan mediante círculos, los mensajes
recibidos mediante dos trapecios unidos por su base menor con las bases verticales, los
mensajes enviados mediante la misma figura pero con sus bases horizontales y los
hexágonos muestran las actividades. Las flechas representan los pasos entre estados y
actividades a través de los mensajes.
Esperar
por
evento
Orden
recibida
Esperar
por
evento
Fecha de
producción
alcanzada
Orden
ejecutada
Enviado a
fabricación
Producto en
almacén
Fin
Figura 3.52 Ejemplo de representación de procesos mediante BML
La tabla de la figura 3.53 muestra, según [Söderström et alt., 2002], una comparación
entre estas tres técnicas relativa a los conceptos de modelado de procesos antes
expuestos.
- 181 -
3. Propuesta arquitectural y metodológica
CONCEPTO
Evento
EPC
Dos tipos: precondición
y poscondición
Estado
Actividad
Corresponde al
concepto ‘función’
Proceso
Conjunto ordenado y
relacionado lógicamente
de funciones
Conjunto de
precondiciones y
poscondiciones que
pueden cumplirse antes
y después de una
función
Corresponde al
concepto ‘recurso’
Reglas
Recurso
Actor
BML
Dos tipos: tiempos +
actividad + cambio de
estado y tiempos +
cambio de estado
Corresponde al
concepto ‘esperando un
evento’
Corresponde a los
conceptos ‘enviar
mensaje’, ‘actividad’ e
‘inicio temporal’
Conjunto ordenado y
relacionado lógicamente
de actividades
Corresponde al
concepto ‘decisiones
automáticas’
Corresponde al conjunto
de elementos que
forman un diagrama
BIA
Corresponde a los
conceptos ‘aplicación’ y
‘agente humano’,
capaces de enviar
mensajes
UML (D.E.)
Siete tipos, entre
simples y combinados,
que utilizan cambios de
estado, tiempos y
precondiciones y
poscondiciones
Corresponde a los
conceptos ‘estado’ y
‘estado en espera’
Corresponde a los
conceptos ‘actividad en
entrada’, ‘actividad en
salida’ y ‘actividad
durante estado’
Conjunto ordenado y
relacionado lógicamente
de actividades
Conjunto de
condiciones de las
transiciones entre
estados
Corresponde al
concepto ‘clase’
Corresponde al
concepto ‘objeto’, capaz
de enviar mensajes
Figura 3.53 Comparación de las principales técnicas de modelado de procesos
La técnica elegida para nuestra propuesta es Event-driven Process Chains o EPC,
principalmente porque es la más representativa del grupo orientado a actividades,
indicado para el tipo de proceso a modelizar, es decir, la realización de acciones para la
parametrización de sistemas ERP. Consideramos menos adecuados aquellos modelos
orientados a los estados o a la comunicación. Por otra parte se entiende muy fácilmente,
tiene una representación gráfica sencilla y completa y es el más utilizado en sistemas de
información. Sus principales elementos son los eventos y las funciones, estas son
lanzadas por eventos y, a la vez, generan eventos, lo que facilita el encadenamiento de
- 182 -
3. Propuesta arquitectural y metodológica
tareas necesario para nuestra propuesta cuyo objetivo es guiar a través de un sistema,
centrándose, como los modelos de EPC, en la ejecución/acción y la coordinación. Otras
ventajas por la que ha sido seleccionado es su facilidad para mostrar diferentes niveles
de detalle y la existencia de una herramienta ampliamente difundida y utilizada,
Architecture of Integrated Information System o ARIS Toolset que utiliza los modelos
de EPC para la representación de secuencias lógico-temporales. Finalmente es la técnica
utilizada para representar el modelo de negocio en el sistema ERP SAP, uno de los más
importantes en el sector. También ha sido utilizada con éxito en la generación de
contenidos en el Sistema Inteligente de Tutorización SITA para la enseñanza del
conocimiento procedimental [Pagés et alt., 2005], un buen precedente para su uso en
otros sistemas inteligentes, como es nuestra propuesta.
Event-driven Process Chains (EPC)
Event-driven process chains (EPC) es una técnica gráfica con una base muy sencilla
orientada a la ejecución de actividades. Ha sido ampliamente utilizada ya que permite
describir procesos en un sentido muy general: definición y reingeniería de procesos de
negocio, definición y control de flujos de trabajo, reglas de actuación y
responsabilidades de unidades organizativas, configuración y desarrollo de software,
documentación asociada a cálculo de costes y calidad, etc. Esta forma de representación
fue introducida por [Kéller et alt., 1992] y desde entonces se ha difundido muy
rápidamente, sobre todo desde que fue la técnica elegida como soporte en la
Architecture of Integrated Information System (ARIS) y en el sistema SAP. Sus
principales característica son sencillez de lectura y diseño, generalidad, posibilidad de
adaptación e inclusión de información y facilidad de representación a distintos niveles
de especificación.
Su metodología se basa en diseñar diagramas que muestran la estructura del flujo de
control de una actividad como la secuencia de eventos o condiciones y funciones o
acciones. Mediante un diagrama EPC se comprende como uno o más eventos
relacionados lógicamente desencadenan una o más acciones y como cada una de estas
acciones o varias de ellas agrupadas producen eventos, resultado de la ejecución de las
mismas. Por tanto los elementos básicos de un diagrama EPC son:
? Evento. Describe un cambio de situación o de estado, por tanto se relaciona con
la ejecución de una acción que es la que produce el cambio o la que se debe
realizar si se ha producido el cambio. Por tanto tenemos dos tipos de eventos, los
que inducen la ejecución de una acción o precondiciones y los que son
consecuencia de la ejecución de una acción o poscondiciones. También se
denominan condiciones. Un diagrama EPC contendrá:
- 183 -
3. Propuesta arquitectural y metodológica
o Un conjunto no vacío de eventos iniciales, que dan la señal de inicio de
la ejecución de actividades contenidas en el EPC;
o Un conjunto no vacío de eventos finales, que son la consecuencia de la
ejecución de las actividades contenidas en el EPC;
o Un conjunto, puede ser vacío, de eventos internos que son los eventos
iniciales y finales de las acciones intermedias que conforman la
ejecución de las actividades contenidas en el EPC.
? Función. Describe una actividad o tarea, indica un cambio de situación entre el
antes y el después de su realización. Las funciones representan los bloques
básicos de los diagramas, a los que proporcionan significado. También se
denominan acciones. Dependiendo del nivel de detalle de los EPC, estas
funciones pueden representar unidades básicas operativas no descomponibles o
actividades complejas, que ha su vez podrían estar representadas por otros
diagramas EPC, como conjuntos de eventos y funciones. Obligatoriamente todo
diagrama EPC debe tener al menos un nodo de tipo función y toda función debe
estar precedida, al menos, por un evento de tipo precondición y seguida, al
menos, por un evento de tipo poscondición.
? Conectores lógicos. Establecen las rutas posibles en el proceso mostrado por el
diagrama EPC. Describen las relaciones lógicas y de dependencia entre eventos
y funciones. Los conectores unen una o más condiciones, ejecutan su función
lógica y pasan el control a la función correspondiente según el resultado de la
función lógica. Los conectores lógicos se dividen en dos categorías:
o Tipo “D”: Divisores o distribuidores, que dividen un flujo de proceso.
Poseen un flujo de control de entrada y dos o más flujos de control de
salida.
o Tipo “J”: Uniones o conectores, que sincronizan flujos de proceso
paralelos. Poseen un flujo de control de salida y dos o más flujos de
control de entrada.
Tanto los conectores “D” como los “J” incluyen las siguientes categorías
lógicas:
o AND. Todos los eventos de entrada del operador AND deben ocurrir
para que el flujo de ejecución continúe a la salida del operador y se pase
el control al evento o eventos o a la función o funciones siguientes.
- 184 -
3. Propuesta arquitectural y metodológica
o OR. Al menos uno de los eventos de entrada del operador OR debe
ocurrir para que el flujo de ejecución continúe a la salida del operador y
se pase el control al evento o eventos o a la función o funciones
siguientes. Pueden ocurrir uno o más de uno de los eventos de entrada.
o XOR. Uno y solo uno de los eventos de entrada del operador XOR debe
ocurrir para que el flujo de ejecución continúe a la salida del operador y
se pase el control al evento o eventos o a la función o funciones
siguientes.
? Flujo de control. Describe la dirección de la ejecución de las actividades
mediante las líneas que conectan los nodos del diagrama EPC. Representa el
paso de un elemento a otro. Pueden unir los siguientes tipos de nodos:
o Funciones con eventos para representar su poscondición.
o Eventos con conectores para actuar como precondición.
o Conectores con funciones para indicar la dirección de ejecución de las
actividades.
La figura 3.54 muestra la representación gráfica de cada uno de estos elementos
básicos.
Orden recibida
Evento
Función
Fabricación
AND
OR
Conectores Lógicos
XOR
Flujo de control
Figura 3.54 Representación gráfica de los elementos básicos de un diagrama EPC
Este modelado de procesos como secuencia lógica temporal de funciones deriva de
las redes de Petri, que proporcionan descripciones gráficas y definiciones formales de
los procesos. De hecho se vienen realizando estudios comparativos entre la utilización
de modelos de EPC o de redes de Petri para la formalización del conocimiento, como
- 185 -
3. Propuesta arquitectural y metodológica
por ejemplo [Aalst y Hofstede, 2002] y [Jorgensen, 2003]. El uso de la técnica EPC
como derivada de las redes de Petri en nuestra propuesta, en vez de utilizar directamente
estas últimas se debe a su mayor sencillez de representación de cara a su uso en el área
de negocios y empresarial y a la posibilidad de añadir información, como veremos a
continuación, más allá de los nodos y transiciones presentes en las clásicas redes de
Petri.
Los elementos necesarios para completar nuestra propuesta deben ser capaces de
asociar, si es el caso, a cada acción a ejecutar o paso de la parametrización del sistema
ERP la información sobre los parámetros a definir y sus posibles valores. Esta
información debe constituir un nuevo elemento en los diagramas EPC, ya que no se
corresponde con ninguno de los existentes y la denominaremos objeto de información.
Si consideramos cada paso de parametrización como una función del modelo EPC
necesitaremos crear un nuevo tipo de interconexión que no se refiere al flujo de control
de actividades sino a la asociación entre el nuevo elemento de datos u objeto de
información y su función correspondiente, a esta interconexión la llamaremos flujo de
información. La figura 3.55 muestra la representación gráfica asociada a estos dos
nuevos elementos de los diagramas EPC.
Datos de
fabricación
Objeto de Información
Flujo de información
Figura 3.55 Representación gráfica de los nuevos elementos básicos añadidos a los
diagrama EPC
Una vez presentados los elementos a utilizar, un modelo EPC puede describirse
formalmente si se conceptualiza como grafo conectado, dirigido y que posee atributos
en nodos y arcos. En consecuencia definimos formalmente un modelo EPC por medio
de una tupla de elementos:
Modelo EPC = (ID, ?, ?, t , t?), donde:
ID: identificador
?: Conjunto finito no vacío de nodos. 2 = | ? | < ?
?: Conexiones o relaciones entre nodos ? ? ? x ?
- 186 -
3. Propuesta arquitectural y metodológica
t : Asigna un tipo a cada nodo. t : ? ? {Función, evento, conector u objeto de
información}
t?: Asigna un tipo a cada conexión. t ? : ?? ?
información}
{Flujo de control o flujo de
Puntualizaremos el uso de la técnica EPC adaptado a nuestra propuesta, ya que,
además de las normas generales de un EPC, hemos añadido las siguientes indicaciones
particulares y las siguientes normas de representación y de diseño, con el objetivo de
mejorar la compresión del modelo y facilitar su posterior paso a reglas de producción
que formarán la red semántica de nuestro módulo del dominio:
? Como se desprende de las definiciones iniciales de los componentes básicos de
los diagramas EPC, hemos obligado a que todas las funciones concluyan con un
evento, es decir, debemos representar siempre la condición o condiciones
resultantes de la ejecución de una función. Ahora bien, las funciones pueden
iniciarse con un evento cuando no surjan de manera espontánea o iniciarse
directamente cuando impliquen un conocimiento procedimental, es decir,
reflejen la ejecución de acciones.
? Utilización de eventos negados para indicar el no cumplimiento de una
condición. De esta forma las dos salidas de la condición (positiva y negativa)
pueden quedar representadas en el mismo EPC si es necesario. El control de
flujo habitual en un EPC consiste en el paso a la siguiente actividad unida al
conector cuando el resultado de la función lógica aplicada a las condiciones del
conector sea afirmativo. Puede ocurrir que si el resultado es negativo se deba
realizar una actividad alternativa y volver después a la siguiente actividad del
EPC. La figura 3.56 representa un ejemplo de uso de este conector.
- 187 -
3. Propuesta arquitectural y metodológica
Control de
calidad no
concertado
Realizar
inspecci ón
Control de
calidad
concertado
XOR
Inspecci ón
positiva
XOR
Inspecci ón
negativa
Reparar
material
Almacenar
material
Material
reparado
Material en
almacén
XOR
Cerrar
recepción
rececpión
Material
recepcionado
Figura 3.56 Representación del uso de eventos negados en un diagrama EPC
El diagrama anterior muestra la actividad de recepción en un almacén. Para
poder realizar el almacenamiento de un material recepcionado se debe cumplir la
condición de existencia de un control de calidad concertado con el proveedor o,
si no es así, realizar una inspección con resultado positivo.
? Hemos añadido una nueva posibilidad en los flujos de control. Permitiremos
flujos mediante líneas que unan conectores con conectores para representar
dependencias lógicas complejas. La figura 3.57 muestra un ejemplo de utilidad
de este nuevo flujo.
- 188 -
3. Propuesta arquitectural y metodológica
Apertura
manual de la
orden
Fecha de
apertura
alcanzada
OR
Faltantes
en la orden
AND
AND
Lanzar
orden
Orden en
producción
Informar al
planificador
Alerta del
planificador
Figura 3.57 Representación del uso flujos de control entre conectores en un diagrama
EPC
En el diagrama se muestra como hay una conexión directa entre el conector OR
y el AND. En este caso la salida del conector OR es una entrada o precondición
del conector AND. En este diagrama si se cumple uno de los eventos, o los dos,
‘apertura manual de la orden’ y ‘fecha de apertura alcanzada’ se ejecutará la
función ‘lanzar orden’ que producirá el evento ‘orden en producción’. Además si
se cumplen una o dos de las precondiciones del conector OR y también ocurre el
evento ‘faltantes en la orden’ se ejecutará la función ‘informar al planificador’
cuya consecuencia será el estado de alarma del planificador o lo que es lo mismo
el evento ‘alerta del planificador’.
? Con objeto de simplificar el diseño, hemos creado un nuevo elemento que
represente acciones complejas que agrupan acciones simples siempre que se crea
conveniente para facilitar la comprensión del diagrama y siempre que aparezcan
más de ocho acciones relacionadas en el mismo EPC. A estas acciones
complejas las llamaremos Procesos y, de esta forma, añadimos un elemento
posible más al EPC. Un proceso es una abstracción necesaria para entender
acciones complejas. Un proceso es abstracto porque no es ejecutable por sí
mismo y debe descomponerse en otros procesos, acciones, condiciones y
conectores para poder ser ejecutado. Todas las funciones que realizan las
- 189 -
3. Propuesta arquitectural y metodológica
condiciones, los conectores lógicos y las interconexiones con acciones son
igualmente aplicables a los procesos y se realizarán de la misma forma. Dentro
de un diagrama EPC un proceso debe terminar obligatoriamente con una
condición que refleje el cumplimiento de todas sus actividades. La figura 3.58
muestra la representación del nuevo elemento proceso.
Parametrización
de la política
de planificación
Proceso
Figura 3.58 Nuevo elemento proceso en un diagrama EPC
? Es posible realizar construcciones jerárquicas en un EPC. Un modelo de EPC
estará formado por un conjunto de diagramas EPC interconectados, de manera
que los procesos que aparecen en un EPC se desarrollen en otro,
descomponiéndose en procesos, acciones, condiciones y conectores a otro nivel.
Al final un modelo de EPC estará compuesto por varios EPC encadenados
formando distintos niveles de detalle en la ejecución de las funciones. La figura
3.59 representa un diagrama EPC en el que las funciones y sus relaciones son
tan complejas que varias de ellas se han agrupado en procesos.
- 190 -
3. Propuesta arquitectural y metodológica
Parametrización
de la política
de demanda
Política de
demanda ya
parametrizada
Política de
demanda
parametrizada
XOR
Parametrización
de la política
de planificación
Política de
planificación ya
parametrizada
Política de
planificación
parametrizada
Parametrización
de la política
de inventario
Política de
inventario ya
parametrizada
XOR
Política de
inventario
parametrizada
XOR
AND
Cerrar
parametrización
módulo MRP
Módulo MRP
parametrizado
Figura 3.59 Procesos utilizados en un diagrama EPC
En la figura 3.60 se muestra un nivel inferior de detalle de uno de los procesos
anteriores, en concreto, el proceso ‘parametrización de la política de
planificación’.
- 191 -
3. Propuesta arquitectural y metodológica
Tipo de
política
sin asignar
Asignar
tipo de política
Tipo de
política
definido
Tipo de
política
asignado
Política =
punto de pedido
Nivel sin
asignar
Política =
agrupación
Periodo sin
asignar
AND
AND
Asignar nivel
Asignar periodo
Nivel asignado
Período asignado
XOR
XOR
AND
Cerrar
parametrización
política de
planificación
Política de
planificación
parametrizada
Figura 3.60 Diagrama EPC correspondiente al nivel detallado del proceso
‘parametrización de la política de planificación’
En la figura 3.59 se indica como para realizar la parametrización completa del
módulo MRP es necesario completar las parametrizaciones relativas a la política
de la demanda, la política de planificación y la política de inventario. Estas
acciones complejas están representadas mediante procesos. Debemos destacar
que los procesos no presentan precondiciones en el diagrama de mayor nivel,
pero si poscondiciones para integrarse en el proceso lógico, esto se explica
revisando la figura 3.60 que muestra el nivel detallado de uno de ellos. En este
caso el diagrama comienza y termina con eventos. Los eventos iniciales serán
las precondiciones del proceso, mientras que solo existe un evento final que es la
poscondición del proceso. Las funciones representadas ejecutadas según los
flujos de control completarán el proceso del que dependen. En concreto para
realizar la parametrización de la política de planificación es necesario establecer,
primero, el tipo de política, si es que no está ya definido (por ejemplo por
valores por defecto según la taxonomía empresarial) y a continuación elegir
algunos parámetros en función del tipo de política elegida. Si el tipo es por
punto de pedido habrá que definir el nivel del punto de pedido, en cambio si el
tipo es agregación habrá que definir el periodo temporal de agregación de las
órdenes. En cualquiera de estos casos se tiene en cuenta si estos parámetros
- 192 -
3. Propuesta arquitectural y metodológica
están ya definidos para no llevar a la persona que parametriza a realizar de
nuevo esta función.
La relación jerárquica de niveles entre un proceso y su diagrama EPC
correspondiente se ve fácilmente de forma gráfica, ya a que podríamos sustituir
en el diagrama de la figura 3.59 la representación gráfica del proceso
‘parametrización de la política de planificación’ por el diagrama de la figura
3.60, obteniendo un diagrama EPC perfectamente consistente y completo,
aunque mas complejo y difícil de entender.
? Incluir una forma de representación de la secuencia u orden de ejecución de las
actividades o procesos presentes en un EPC. El problema de la sincronización en
los EPC ha sido ya analizado y debatido en muchos foros, por ejemplo en [Aalst
y Hofstede, 2002] se recuerda que el problema de la sincronización del flujo de
eventos que representa un EPC no es trivial. En nuestra propuesta la
representación gráfica se soluciona dibujando las actividades o procesos
alineados de dos formas:
o
En horizontal cuando se quiere indicar una secuencia temporal, es decir,
no se puede realizar la acción o proceso de la derecha si no se han
completado las acciones o procesos a su izquierda.
o
En vertical cuando se quiere indicar que no importa el orden de
ejecución, es decir las acciones o procesos que se dibujan uno debajo de
otro pueden realizarse entre ellas en cualquier orden.
La figura 3.61 muestra un ejemplo de diagrama EPC en el que no importa el
orden de ejecución de las funciones. En él las funciones ‘crear planificadores’ y
‘fijar calendario’ se deben ejecutar para poder terminar la parametrización de los
datos base de planificación, pero es independiente en el orden que se hagan, ya
que aparecen en vertical, una encima de la otra.
- 193 -
3. Propuesta arquitectural y metodológica
Planificadores
inexistentes
Crear
planificadores
Planificadores
creados
Calendario
inexistente
Fijar
calendario
Calendario
fijado
AND
Cerrar
datos base
planificación
Datos base
Planificación
creados
Figura 3.61 Representación de un diagrama EPC sin secuencia temporal de ejecución
La figura 3.62 muestra un ejemplo de secuencia temporal. En él la función
‘recepcionar material’ se debe ejecutar siempre antes que la función ‘generar
factura’.
Material en
recepción
Pedido normal
Recepcionar
material
Generar
factura
Material
recepcionado
Factura
generada
AND
Cerrar pedido
Pedido cerrado
Figura 3.62 Representación de secuencia temporal de ejecución en un diagrama EPC
- 194 -
3. Propuesta arquitectural y metodológica
Finalmente la figura 3.63 representa un ejemplo completo de diagrama EPC,
explicaremos como seguir el flujo que representa utilizando las convenciones definidas.
Pedido abierto
en vigor
XOR
Pedido normal
pendiente
Servicio
aceptado
XOR
Proceso de
recepción del
material
Material
recepcionado
AND
Generar
factura
Factura
generada
Figura 3.63 Ejemplo de diagrama EPC
Verificamos que este diagrama corresponde a un conjunto de actividades
encaminadas a obtener una ‘factura generada’, poscondición final. En primer lugar
comprobamos que existen dos conectores XOR que están ordenados verticalmente por
lo que su orden de ejecución es indiferente. Elegimos un orden cualquiera, en este caso
el mismo del dibujo:
1. Ejecutamos el conector XOR de más arriba. Tiene dos eventos de entrada
colocados de forma vertical por lo que su orden de evaluación es indiferente.
Evaluamos primero el de más arriba ‘pedido abierto en vigor’:
? Si el resultado es positivo tenemos definida de forma afirmativa la
primera entrada del primer conector XOR. Evaluamos el otro evento
‘pedido normal pendiente’. Si el resultado es positivo la salida del
primer conector XOR será negativa, en cambio si el resultado es
negativo, será positiva. Es decir, la salida será positiva si hay un
- 195 -
3. Propuesta arquitectural y metodológica
?
pedido abierto en vigor y no hay pedido normal pendiente y negativa
si existen los dos tipos de pedido, lo que supondrá un error a revisar
antes de generar la factura.
Si el resultado es negativo tenemos definida de forma negativa la
primera entrada del primer conector XOR. Evaluamos el otro evento
‘pedido normal pendiente’. Si el resultado es positivo la salida del
primer conector XOR será positiva, en cambio si el resultado es
negativo, la salida será negativa. Es decir, la salida será positiva si no
hay un pedido abierto en vigor y hay pedido normal pendiente y
negativa si no existen ninguno de los dos tipos de pedido lo que
supone la imposibilidad de generar una factura.
2. Ejecutamos el segundo conector XOR. Tiene dos entradas colocadas
verticalmente por lo que su orden de ejecución es indiferente. Evaluamos
primero el de más arriba ‘servicio aceptado’:
? Si el resultado es positivo tenemos definida de forma afirmativa la
primera entrada del primer conector XOR. Evaluamos la otra entrada,
en este caso el proceso ‘proceso de recepción del material’. Este
proceso corresponde con el diagrama EPC representado en la figura
3.56. Nos remitimos a esa figura para continuar con la ejecución:
Existe un conector XOR con dos entradas colocadas horizontalmente
por lo que debemos empezar por la situada más a la izquierda. El
primer evento es ‘Control de calidad concertado’, lo evaluamos:
o Si el resultado es positivo tenemos definida de forma
afirmativa la primera entrada del primer conector XOR.
Ejecutamos el segundo evento ‘control de calidad no
concertado’, que es el evento contrario, por tanto su
resultado será negativo y no debemos continuar con la
función ’realizar inspección’, por lo que sus poscondiciones
‘inspección positiva’ y ‘material reparado’ no se cumplirán.
o Si el resultado es negativo debemos ejecutar el siguiente
evento ‘control de calidad no concertado’, que es el evento
contrario, por tanto su resultado será positivo y ejecutaremos
la función ‘realizar inspección’. Una vez finalizada la
ejecución su cumplirán una de sus dos poscondiciones
‘inspección positiva’ o ‘inspección negativa’. Si se cumple
la primera se ejecutará la función ‘almacenar material’ y su
poscondición ‘material almacenado’. Si se cumple la
segunda se ejecutará la función ‘reparar material’ y su
poscondición ‘material reparado’. En cualquiera de los dos
casos una de las dos entradas al último XOR será positiva
- 196 -
3. Propuesta arquitectural y metodológica
?
por lo que se ejecutará la función ‘cerrar recepción’ y se
considerará el material como recepcionado (poscondición).
Si el resultado es positivo la salida del segundo conector XOR será
negativa, en cambio si el resultado es negativo, será positiva. Es decir,
la salida será positiva si hay un servicio aceptado y no se ha
almacenado material y negativa si se ha aceptado un servicio y
almacenado material para el mismo pedido, lo que supondrá un error a
revisar antes de generar la factura.
Si el resultado es negativo tenemos definida de forma negativa la
primera entrada del primer conector XOR. Evaluamos la otra entrada,
el proceso ‘proceso de almacenamiento del material’ igual que en el
caso anterior. Si el resultado es positivo la salida del segundo conector
XOR será positiva, en cambio si el resultado es negativo, la salida
será negativa. Es decir, la salida será positiva si no se ha aceptado un
servicio pero si hay material en almacén y negativa si no se ha
aceptado ni servicio ni se ha almacenado material para un pedido, lo
que supone no tener que generar factura.
3. Evaluamos el conector AND, cuyas precondiciones son la salida de los dos
conectores XOR, ya evaluados. Las dos precondiciones deben ser afirmativas
para poder obtener un resultado afirmativo.
4. Por último, si la salida del conector AND es afirmativa, ejecutamos la
función ‘generar factura’. Una vez ejecutada el evento asociado a su salida, o
poscondición, ‘factura generada’ nos indica el resultado de la ejecución de las
actividades representadas en el EPC de la figura 3.63.
3.2.2. Redes semánticas
El objetivo del asistente inteligente aquí propuesto es la parametrización de un
sistema ERP según el plan estratégico de la organización. Para esta tarea es necesario
definir un módulo de conocimiento del dominio que incluya información sobre el
funcionamiento procedural del ERP y sobre la realidad particular de la empresa que lo
parametriza. Dicho conocimiento es difícil de conjugar, por la existencia de cientos de
tablas con sus correspondientes parámetros de los que hay que conocer su utilidad y
significado, conocimiento típico de los consultores ERP, a la vez que por la existencia
de características particulares de cada organización, su forma de trabajo y sus procesos
conocidos por los miembros de la organización. Toda esta información, sobre el sistema
ERP y sobre la organización, está fragmentada, dado su extensión, entre distintas
personas y documentos.
- 197 -
3. Propuesta arquitectural y metodológica
Para obtener un conocimiento modelizado nos encontramos con varias fuentes de
información cada una de las cuales habrá que traducir a reglas de producción
encadenadas:
?
Conocimiento del experto en forma textual. Puede proceder directamente del
experto, de manuales del sistema ERP o de descripciones de procesos de
negocio de la empresa. Es necesario transformar el lenguaje natural en un
conjunto de reglas de conocimiento unidas entre sí que sea ejecutable y no tenga
posibilidad de interpretaciones erróneas como el lenguaje natural.
?
Conocimiento en forma de procesos de negocio. Hemos visto como es posible
representa formalmente de forma gráfica, mediante diagramas EPC, los procesos
de negocio. El objetivo metodológico es transformar estos diagramas en reglas
de producción conectadas entre sí.
?
Modelo de datos del sistema ERP. Es necesario formalizar en reglas de
producción el modelo de datos del sistema ERP procedente de su documentación
mediante herramienta CASE.
El conocimiento del dominio comprende no solo los parámetros y sus posibles
valores sino también reglas de actuación para llevar a cabo determinados
procedimientos y conseguir ciertas estrategias empresariales. En la arquitectura de
nuestro asistente hemos definido la base de conocimientos en forma de redes semánticas
que unen a través de la relación acción-condición reglas de producción, los parámetros y
sus valores relativos a las acciones que lo requieran y las ayudas asociadas a los
parámetros y las acciones. Dicho conocimiento conformara un encadenamiento de
reglas orientado a un objetivo que el asistente utiliza para llevar a cabo las tareas de
parametrización.
Una red semántica está formada por reglas de conocimiento relacionadas entre sí y
puede ser representada en forma de diagrama compuesto de arcos y nodos etiquetados,
ambos, con expresiones esquemáticas tomadas de las fuentes antes citadas (lenguaje
natural, diagramas EPC y herramientas CASE). La red semántica representa ‘que hay
que parametrizar’ mientras que las etiquetas de arcos y nodos representan los pasos
guiados por ese proceso: ‘como hay que parametrizar’. A través del conocimiento
abstracto se reflejan las especificaciones o requisitos del sistema descrito mediante
distintos tipos de documentación, normalmente en formato texto. Las descripciones
abstractas se dividen en significados concretos, cada vez más detallados, casi en piezas
ejecutables.
- 198 -
3. Propuesta arquitectural y metodológica
Mediante la red semántica podemos obtener una visión general del sistema y, a la
vez, profundizar en los detalles hasta el nivel operativo más concreto. Es decir, para
guiar al usuario en la realización de una parametrización determinada, por ejemplo
‘parametrización del módulo MRP’, descompondremos está en otras más básicas y estas
en otras más detalladas hasta el nivel deseado, por ejemplo ‘asignar tipo de política’,
‘asignar nivel’ y ‘asignar periodo’.
La red semántica estará formada por reglas ejecutables obtenidas cuando las
descripciones, datos y eventos procedentes de varias fuentes de conocimiento se
traducen en causas, razones y efectos. El conocimiento ejecutable se centra en
condiciones, acciones y alternativas representadas mediante construcciones
implementables (reglas). Un ejemplo genérico de regla puede ser: ‘Si A y B entonces
C’, donde A y B son condiciones que según su partícula de conexión (‘y’) no son
alternativas y C es una condición deducible de las anteriores. Si en vez de la partícula de
conexión ‘y’ se hubiese utilizado un ‘o exclusivo’ las condiciones, además, serían
alternativas. Por tanto, por regla se entiende una proposición lógica que relaciona dos o
más objetos e incluye dos partes, la premisa y la conclusión. Cada una de estas partes
consiste en una expresión lógica con una o más afirmaciones objeto-valor conectadas
mediante los operadores lógicos ‘y’, ‘o’ u ‘o exclusivo’.
Vamos a definir formalmente cada uno de los conceptos que forman una red
semántica:
Nodo.
Los nodos representan procesos o acciones, entendiendo como procesos un conjunto
de acciones y como acciones las tareas sencillas no descomponibles. La etiqueta
asociada a un nodo consiste en un texto esquematizado del lenguaje natural que debe
explicar de forma comprensible la acción representada. Las etiquetas no deben incluir
explicaciones sobre la acción representada, deben ser cortas y significativas. Toda
explicación necesaria se debe obtener asociada al nodo pero sin formar parte
directamente de la red semántica. Cuando el nodo represente un conjunto de acciones o
proceso se debe etiquetar de la misma forma, un texto corto que describa el conjunto de
acciones. Por ejemplo las acciones agrupadas ‘asignar tipo de política’, ‘asignar nivel’ y
‘asignar periodo’ podrían formar un proceso denominado ‘asignar datos de política de
planificación’.
Arco.
Los arcos representan las condiciones resultado de los nodos asociados a acciones o
procesos. Los arcos están orientados y muestran los caminos de dependencia entre
nodos. Los arcos que unen los nodos lógicos con nodos asociados a acciones no llevan
- 199 -
3. Propuesta arquitectural y metodológica
etiquetas porque, su valor será ‘verdadero’ o ‘falso’ dependiendo del resultado de la
aplicación del conector o nodo lógico. Los arcos que unen nodos acción con nodos
lógicos tendrán como etiqueta un texto cuya expresión se refiere al resultado de la
acción asociada al nodo del que parten. El texto, igual que para los nodos, debe ser corto
y significativo, por ejemplo, en el caso de un arco que parte del nodo ‘asignar tipo de
política’ el texto adecuado sería ‘tipo de política asignada’, es decir el resultado de la
acción realizada. Los arcos muestran caminos en la red, la dependencia conceptual entre
procesos conectados por arcos orientados identifica el flujo de control: de nodos
(acciones) a través de arcos (condiciones) hasta otros nodos (acciones). Esta idea
simboliza el concepto de ‘acciones encadenadas’.
Nodo lógico.
Los nodos lógicos representan la forma de evaluar los arcos (condiciones) que entran
en ellos. La evaluación indicará si las condiciones de entrada son obligatorias y/o
alternativas, para ello utilizamos los siguientes tipos de conexión:
?
?
?
AND. Las condiciones de entrada son obligatorias;
OR. Las condiciones de entrada pueden ser, o bien alternativas, o bien ejecutarse
ambas sin exclusión;
XOR. Las condiciones de entrada son alternativas.
Las etiquetas asociadas a estos nodos solo pueden ser los textos anteriores (AND,
OR o XOR) que representan el tipo de conexión. Los arcos que entran en un nodo
lógico son condiciones, derivadas de acciones, que pueden ser verdaderas o falsas, las
acciones se habrán realizado o no. El arco que sale de un nodo lógico representa la
evaluación del cumplimiento o no de estas condiciones y, por tanto, igualmente, solo
puede ser verdadera o falsa.
Mediante los conectores indicamos como se relacionan las conclusiones entre sí,
pero el orden de evaluación no está indicado. En una red semántica no sabemos si el
orden de evaluación es o no importante y si lo es, no sabemos cual es el orden
adecuado, cual evaluar primero. Con la representación en redes semánticas este
problema no está resuelto y se tendrá en cuenta en el diseño metodológico global que se
expone en el punto fases metodológicas. En el caso de nuestro asistente este problema
debe ser tratado ya que el orden de ejecución es importante para la parametrización
ERP, y en general en la realización de procesos y acciones. Por ejemplo la regla ‘Si se
ha recepcionado el material y se ha generado la factura entonces se ha cerrado el
pedido’ debe ser evaluada en un orden preciso mediante el operador AND, primero
‘recepcionar el material’ y después ‘generar la factura’. Pero la regla ‘si se han
parametrizado los datos de inventario y se han parametrizado los datos de demanda y se
han parametrizado los datos de planificación entonces se ha parametrizado el módulo
- 200 -
3. Propuesta arquitectural y metodológica
MRP’ no implica un orden de evaluación de las condiciones, es indiferente parametrizar
antes los datos de demanda, de inventario o de planificación.
Para recorrer la red semántica podemos utilizar una estrategia de encadenamiento de
reglas ya que las premisas de ciertas reglas coinciden con las conclusiones de otras.
Cuando se encadenan las reglas, los predicados lógicos pueden utilizarse para dar lugar
a nuevos predicados. Es decir a partir de hechos conocidos podemos deducir nuevos
hechos hasta que llegamos a una o varias conclusiones. Para recorrer así la red
semántica debemos empezar por las reglas con premisas conocidas, concluimos esas
reglas y obtenemos nuevas premisas para otras reglas y así hasta que no pueden
obtenerse más conclusiones, bien porque no hay más reglas sin ejecutar, bien porque no
hay más premisas conocidas. Podemos ilustrar este proceso con la figura 3.64.
Regla 5
G
F
Regla 6
E
D
J
Regla 3
B
C
I
L
H
K
M
A
Regla 4
Regla 2
Regla 1
Figura 3.64 Ejemplo de encadenamiento de reglas
En la figura vemos que las regla1 tiene como premisa las conclusiones de las reglas 2
y 3, la regla 2 tiene como premisas las conclusiones de las reglas 4 y 5 y la regla 3 tiene
como premisas las conclusiones de las reglas 5 y 6. Si conocemos los hechos que
aparecen como premisas a las reglas 4, 5 y 6, podemos deducir las conclusiones de las
reglas 2 y 3 y, a continuación la conclusión de la regla 3. Si alguna de las premisas
iniciales no fueran conocidas, por ejemplo las de la regla 6, podríamos deducir la regla 2
pero no las reglas 3 y 1.
En los ejemplos de reglas y de encadenamiento de reglas estudiados utilizamos las
reglas en su sentido clásico, condiciones lógicas que conducen a condiciones lógicas, es
decir, una regla se escribe normalmente como ‘si premisa, entonces conclusión’. En
nuestra propuesta de asistente inteligente incluimos un concepto más: el conocimiento
- 201 -
3. Propuesta arquitectural y metodológica
procedimental necesario para poder guiar al usuario en la parametrización del sistema
en la que el usuario debe actuar durante el proceso de ejecución de las reglas y en la que
los resultados de su actuación serán premisas para otras reglas que le hagan navegar por
la red semántica. En nuestro escenario una regla estará siempre formada por dos reglas
relacionadas, como veremos a continuación.
Una regla típica, en la que A, B y C son predicados lógicos, es decir, pueden tomar
los valores verdadero o falso:
Si A y B entonces C
se transformará en las siguientes
Si A y B entonces ejecutar D
Si se ha ejecutado D entonces C
en las que A, B y C son predicados lógicos y D es una acción ejecutable cuya
consecuencia es el predicado lógico C.
Veamos un ejemplo de aplicación de las reglas genéricas anteriores:
Si el tipo de política de planificación es punto de pedido y el nivel no
está asignado entonces ejecutar la asignación de nivel
Si se ha ejecutado la asignación de nivel entonces el nivel está
asignado
En estas reglas los valores de las premisas y las conclusiones son:
A = ‘el tipo de política de planificación es punto de pedido’
B = ‘el nivel no está asignado’
C = ‘el nivel está asignado’
D = ‘asignación de nivel’
Como podemos comprobar A, B y C son predicados lógicos pero D es una acción
ejecutable que conduce a una conclusión C, formalización necesaria para mostrar el
conocimiento procedimental.
La figura 3.65 representa gráficamente la regla clásica ‘si A y B entonces C’
- 202 -
3. Propuesta arquitectural y metodológica
A
B
C
Figura 3.65 Representación de una regla clásica
En la figura anterior los nodos oscuros representan las conexiones lógicas mientras
que los nodos etiquetados representan los predicados lógicos. En la figura siguiente
(figura 3.66) podemos ver una regla combinada que formaliza el conocimiento
procedimental.
A
B
D
C
Figura 3.66 Representación de una regla de conocimiento procedimental
En la figura anterior se ha representado mediante un rectángulo un nodo especial que
representa la ejecución de una acción que produce una consecuencia.
Una vez visto como nos podemos mover por una red semántica resumiremos las
relaciones entre conceptos básicos de esta estructura. La estructura de la red semántica
consiste en unir mediante conexiones lógicas los arcos y nodos etiquetados, como en el
ejemplo de la figura 3.67. Cada regla contendrá una serie de condiciones (arcos) que se
agrupan mediante conexiones (nodos lógicos) y cuya conclusión será una acción (nodo).
Cada acción (nodo) producirá un resultado que se muestra en la condición de esa acción
(arco). La condición da la acción final de una regla puede, a su vez, ser acción inicial en
otra o más reglas, uniéndose las reglas entre sí de esta forma, obteniendo finalmente una
red semántica. La figura 3.67 muestra como en una estructura de red semántica
podemos distinguir distintas reglas de conocimiento encadenadas.
- 203 -
Regla de conocimiento
3. Propuesta arquitectural y metodológica
Regla de conocimiento
Figura 3.67 Estructura de una red semántica formada por reglas de producción
Utilizando las reglas de conocimiento procedimental unidas en una red semántica
podríamos alcanzar un objetivo o conclusión realizando diversa acciones por el camino,
pero el asistente inteligente diseñado en nuestra propuesta debe guiar al usuario en la
consecución de un objetivo determinado por este, es decir, el usuario no parte de unas
premisas conocidas sino que parte de un objetivo que pretende alcanzar, por ejemplo la
parametrización de un módulo del sistema sin conocer las premisas que se deben
cumplir ni las acciones que se deben realizar para llegar a él. Este es el objetivo de
nuestro asistente guiar al usuario por la red semántica hasta alcanzar el objetivo
marcado por él.
Para cumplir esta función nuestro asistente debe utilizar un algoritmo de
encadenamiento de reglas orientado a un objetivo. Este algoritmo requiere del usuario
seleccionar, en primer lugar, una conclusión o nodo objetivo; entonces el algoritmo
navega a través de las reglas en búsqueda de una cuya conclusión sea el nodo objetivo.
Una vez encontrada se evalúan sus premisas. Se dan valores a aquellas conocidas y se
buscan reglas cuyas conclusiones sean algunas de las premisas que tenemos sin valorar,
para verificar si las podemos obtener automáticamente evaluando las premisas de estas
otras reglas. Si es así el algoritmo ejecutará las reglas en sentido inverso hasta que
encuentre premisas sin valorar que no se puedan obtener a partir de reglas de la red
- 204 -
3. Propuesta arquitectural y metodológica
semántica. En este caso, si no se obtiene ninguna conclusión con la información
existente, el algoritmo fuerza a preguntar al usuario en busca de nueva información
sobre las premisas que son necesarias para obtener información sobre el objetivo.
Veamos un ejemplo de este algoritmo, adaptado a las reglas de conocimiento
procedimental, utilizando la red semántica que muestra la figura 3.68.
A
B
D
E
G
H
C
F
I
C’
F’
I’
J
J’
K
K’
Figura 3.68 Estructura de una red semántica formada por reglas de conocimiento
procedimental
La figura anterior representa las siguientes reglas:
Regla 1:
Premisa A = ‘si tipo de política está predefinido’
Premisa B = ‘tipo de política asignada’
Conclusión-acción C = ‘terminar definición tipo de política’
Conclusión C’ = ‘tipo de política definido’
Conector = OR
- 205 -
3. Propuesta arquitectural y metodológica
Regla 2:
Premisa D = ‘si tipo de política es punto de pedido’
Premisa E = ‘nivel sin asignar’
Conclusión-acción F = ‘asignar nivel’
Conclusión F’ = ‘nivel asignado’
Conector = AND
Regla 3:
Premisa G = ‘si tipo de política es agrupación’
Premisa H = ‘periodo sin asignar’
Conclusión-acción I = ‘asignar periodo’
Conclusión I’ = ‘periodo asignado’
Conector = AND
Regla 4:
Premisa F’ = ‘si nivel asignado’
Premisa I’ = ‘si periodo asignado’
Conclusión-acción J = ‘terminar definición datos política’
Conclusión J’ = ‘datos política definidos’
Conector = XOR
Regla 5:
Premisa C’ = ‘si tipo de política definido’
Premisa J’ = ‘si datos política definidos’
Conclusión-acción
planificación’
K
=
‘terminar
parametrización
política
de
Conclusión K’ = ‘política de planificación parametrizada’
Conector = AND
Si el usuario define como objetivo K’, es decir, tener en el sistema ERP
parametrizada la política de planificación, el algoritmo de encadenamiento orientado a
un objetivo funcionaría de la siguiente manera:
- 206 -
3. Propuesta arquitectural y metodológica
1. Se designa la conclusión K’ como objetivo en curso y se añade a la lista de
objetivos.
Lista de objetivos = {K’}
2. Se busca una regla que contenga a K’ como conclusión.
3. La regla 5 cumple la condición. Añadimos la regla 5 a la lista de reglas activas.
Reglas activas = {regla5}
4. Se evalúa la premisa C’ de la regla 5. Su valor es desconocido, por lo que se marca
C’ como objetivo en curso y se añade a la lista de objetivos.
Lista de objetivos = {K’, C’}
5. Se busca una regla que contenga a C’ como conclusión.
6. La regla 1 cumple la condición. Añadimos la regla 1 a la lista de reglas activas.
Reglas activas = {regla5, regla1}
7. Se evalúa la premisa A de la regla 1. Suponemos en este ejemplo que su valor es
verdadero, es decir, que el tipo de política está predefinido.
8. Como el conector de la regla 1 es OR no es necesario evaluar la otra premisa, la
regla ya se cumple. Por lo que se obtiene la conclusión- acción C.
9. Se pide al usuario que ejecute la conclusión-acción C o ‘terminar definición tipo de
política’. Una vez realizada la acción se cumple la condición C’. Hemos terminado
la regla 1 por lo que la quitamos de la lista de reglas activas.
Reglas activas = {regla5}
10. Hemos obtenido C’ con valor verdadero, luego quitamos C’ de la lista de objetivos y
tomamos el elemento anterior de la lista como objetivo en curso, es decir K’.
Lista de objetivos = {K’}
11. Tenemos la regla 5 como regla activa, en la que falta evaluar la premisa J,. por lo
que se marca J’ como objetivo en curso y se añade a la lista de objetivos.
Lista de objetivos = {K’, J’}
12. Se busca una regla que contenga a J’ como conclusión.
13. La regla 4 cumple la condición. Añadimos la regla 4 a la lista de reglas activas.
- 207 -
3. Propuesta arquitectural y metodológica
Reglas activas = {regla5, regla4}
14. Se evalúa la premisa F’ de la regla 4. Su valor es indefinido por lo que se marca F’
como objetivo en curso y se añade a la lista de objetivos.
Lista de objetivos = {K’, J’, F’}
15. Se busca una regla que contenga a F’ como conclusión.
16. La regla 2 cumple la condición. Añadimos la regla 2 a la lista de reglas activas.
Reglas activas = {regla5, regla4, regla2}
17. Se evalúa la premisa D de la regla 2. Suponemos en este ejemplo que su valor es
verdadero, es decir, que el tipo de política es punto de pedido.
18. Como el conector de la regla 2 es AND se evalúa la otra premisa.
19. Se evalúa la premisa E de la regla 2. Suponemos en este ejemplo que su valor es
verdadero, es decir, que el nivel está sin asignar.
20. La regla 2 ya se cumple. Por lo que se obtiene la conclusión- acción F.
21. Se pide al usuario que ejecute la conclusión-acción F o ‘asignar nivel’. Una vez
realizada la acción se cumple la condición F’. Hemos terminado la regla 2 por lo que
la quitamos de la lista de reglas activas.
Reglas activas = {regla5, regla4}
22. Hemos obtenido F’ con valor verdadero, luego quitamos F’ de la lista de objetivos y
tomamos el elemento anterior de la lista como objetivo en curso, es decir K’.
Lista de objetivos = {K’, J’}
23. Tenemos la regla 4 como regla activa, en la que falta evaluar la premisa I’
24. Se evalúa la premisa I’ de la regla 4. Su valor es indefinido por lo que se marca I’
como objetivo en curso y se añade a la lista de objetivos.
Lista de objetivos = {K’, J’, I’}
25. Se busca una regla que contenga a I’ como conclusión.
26. La regla 3 cumple la condición. Añadimos la regla 3 a la lista de reglas activas.
Reglas activas = {regla5, regla4, regla3}
- 208 -
3. Propuesta arquitectural y metodológica
27. Se evalúa la premisa G de la regla 3. Suponemos en este ejemplo que su valor es
falso, es decir, que el tipo de política no es agrupación, como ya habíamos supuesto
antes, es punto de pedido.
28. Como el conector de la regla 3 es AND no es necesario evaluar la otra premisa, la
regla no se cumple. Por lo que se obtiene como falso el valor de I’, es decir el
periodo no está asignado.
29. Hemos terminado la regla 3 por lo que la quitamos de la lista de reglas activas.
Reglas activas = {regla5, regla4}
30. Hemos obtenido I’ con valor falso, luego quitamos I’ de la lista de objetivos y
tomamos el elemento anterior de la lista como objetivo en curso, es decir J’.
Lista de objetivos = {K’, J’}
31. Tenemos la regla 4 como regla activa, en la que tenemos los valores de las premisas
F’ (verdadero) e I’ (falso).
32. Como el conector de la regla 4 es un XOR el resultado es verdadero y hemos
terminado la regla 4 por lo que la quitamos de la lista de reglas activas.
Reglas activas = {regla5}
33. Hemos obtenido un valor de J’ verdadero y lo quitamos de la lista de objetivos y
tomamos el elemento anterior de la lista como objetivo en curso, es decir K’.
Lista de objetivos = {K’}
34. Tenemos la regla 5 como regla activa, en la que tenemos los valores de las premisas
C’ (verdadero) e J’ (verdadero). Como el conector de la regla 5 es AND, obtenemos
un valor verdadero.
35. La regla 5 se cumple. Por lo que se obtiene la conclusión- acción K.
36. Se pide al usuario que ejecute la conclusión-acción K o ‘terminar parametrización
política de planificación’. Una vez realizada la acción se cumple la condición K’, es
decir ‘política de planificación parametrizada’.
37. Hemos terminado la regla 5 por lo que la quitamos de la lista de reglas activas.
Reglas activas = {}
38. Hemos obtenido el valor verdadero de la conclusión objetivo K’, luego la quitamos
de la lista de objetivos y damos por terminado el algoritmo de encadenamiento.
Lista de objetivos = {}
- 209 -
3. Propuesta arquitectural y metodológica
3.2.2. Métricas de calidad en la implantación de un ERP
La calidad de los sistemas ERP en uso no es un hecho puntual sino que fluctúa con el
tiempo y los cambios en el entorno del negocio, los sistemas de información y la propia
empresa (política de personal, gestión del cambio, estrategia empresarial, etc.), más aún
en el ámbito de la actual gestión empresarial flexible. Esta flexibilidad se puede definir
como la aptitud de una organización a combinar en el tiempo y en el espacio los
elementos que la constituyen y redefinir sus características para poder mantener o
aumentar su propio nivel de prestaciones, frente a los cambios del ambiente y del
entorno.
De este modo es necesario realizar una gestión de la calidad permanente, para
alcanzarla y mantenerla, como parte de un proceso de mejora continua. De ahí que
nuestro trabajo incluya un control de calidad continúo, de forma que el asistente
inteligente proponga la revisión constante de la parametrización inicial del sistema para
adecuarse a los cambios y tienda siempre a la excelencia introduciendo los conceptos
secuenciales de:
? Medición, aplicando las métricas de calidad establecidas;
? Control, comparando los resultados obtenidos con los deseados;
? Diagnostico, determinando las funciones y estrategias de negocio a revisar según
la comparación realizada;
? Actuación, modificando la parametrización del sistema ERP para que se adapte a
las nuevas funciones y estrategias;
? Consolidación, capturando y reutilizando los cambios realizados y sus
consecuencias.
Por tanto, nuestro asistente no solo será útil durante el desarrollo del proyecto de
implantación del sistema ERP, sino que deberá ser utilizado a lo largo de todo su ciclo
de vida, proporcionando una evolución continúa en la optimización del ERP. Para
realizar este objetivo definimos tres fases de trabajo: primero identificar el ámbito de
evaluación de la calidad, segundo definir criterios e índices de calidad a aplicar y
tercero relacionar estos con la parametrización realizada en el sistema.
- 210 -
3. Propuesta arquitectural y metodológica
Identificación del ámbito de evaluación de la calidad.
Para realizar la primera fase sabemos que la gestión de la calidad pasa por establecer
primero los niveles a analizar, en nuestro caso determinamos los siguientes:
? Nivel institucional que se refiere a decisiones estratégicas como el sistema ERP
a utilizar, interfaces con otros sistemas, inversión monetaria y recursos, etc.
? Nivel de gestión que comprende la gestión técnica desde Servicios Informáticos,
la administración de recursos, los planes formativos, los grupos de soporte y
resolución de problemas, permisos de acceso a módulos y transacciones, etc.
? Nivel de sistema que incluye aspectos técnicos y de funcionamiento.
? Nivel de participante que comprende clientes, suministradores, personal técnico,
personal usuario y dirección.
Para cada uno de estos niveles se pueden analizar criterios de calidad referidos al
propio proceso y al producto o resultado del proceso. El primero indica la bondad de
métodos y procedimientos y el segundo la bondad de los resultados conseguidos.
Además se deben distinguir para cada criterio indicadores cualitativos y cuantitativos,
por ejemplo grado de satisfacción de los clientes o número de usuarios autorizados a
acceder al sistema ERP.
La presente propuesta se centra en aspectos funcionales del sistema ERP que guían
su parametrización, ya que decisiones de tipo técnico, de gestión o institucional, como
módulos del sistema ERP a implantar, tipo de base de datos y de entorno de
programación, recursos humanos dedicados al mantenimiento del sistema ERP, etc., se
toman independientemente del proceso de parametrización del propio sistema. Por tanto
la función de calidad del asistente propuesto debe ceñirse a los niveles de sistema y de
participante y a los resultados del proceso, es decir beneficios y debilidades de su uso,
analizando, en consecuencia, el producto o resultado conseguido. También es
importante que al establecer las métricas de calidad se tenga en cuenta el entorno de la
implantación, es decir, el tamaño de la empresa, su cultura empresarial y la taxonomía
empresarial en la que está incluida, así como sus propios planes estratégicos.
Definición de criterios e índices de calidad a aplicar.
Los proyectos de implantación de un sistema ERP prácticamente solo tienen
desventajas: son costosos, requieren largos tiempos de realización, minan la fiabilidad
- 211 -
3. Propuesta arquitectural y metodológica
del sistema, pues inciden sobre procesos ya probados, y convierten la actualización del
software a través de versiones sucesivas en una actividad difícil y costosa, ya que la
empresa productora del ERP lo actualiza periódicamente para corregir errores y para
añadir nuevas funcionalidades fruto, en general, de incorporaciones al sistema de
personalizaciones solicitadas por los clientes.
Para dar una idea de la complejidad de los proyectos de adopción de un ERP basta
recordar el gran número de proyectos fallidos, con realizaciones parciales o
abandonados completamente. Su finalización con éxito está ligada a una serie de
factores encontrados en los casos positivos.
Para Cisco System INc., empresa operante en el sector para dar apoyo técnico o
consultoría en muchos de estos proyectos, los elementos de éxito, en orden de
importancia, son los siguientes:
? Apoyo constante de la dirección empresarial al proyecto, no debe ser
considerado un proyecto informático sino un proyecto empresarial estratégico
desde el primer momento.
? Creación de un equipo de proyecto que incluya los recursos más importantes de
la empresa, sin caer, como es habitual, en el uso del personal no importante en
su área. Las personas implicadas deben ser capaces de tomar decisiones
importantes y de resolver los problemas que se planteen. El equipo debe incluir,
además, personas de las empresas proveedoras del software/hardware y
consultores. Es importante definir un plan de formación de este equipo previo a
la implantación del ERP largo y costoso.
? Dedicación de un gran esfuerzo inicial a la definición de la configuración del
sistema y la planificación de los recursos necesarios, humanos y materiales, para
llevarla a buen término.
? Parametrización del sistema consecuente con las necesidades estratégicas
empresariales, que permita a la empresa trabajar como definían sus planes,
utilizando los parámetros del sistema sin modificar el software. Esta
parametrización debe responder a las exigencias fundamentales de la empresa.
? Gestión del proyecto a través de una metodología precisa que guíe las
actividades del mismo.
? Evitar pérdidas de tiempo y tiempos muertos durante el proceso.
- 212 -
3. Propuesta arquitectural y metodológica
? Sustituir todas las aplicaciones actuales que sea posible, disminuyendo la
necesidad de interfaces.
Esta lista puede completarse con otras procedentes de diversos autores, pero
establece los principios fundamentales que deben guiar la implantación ERP, que,
resumiendo, se refieren a una buena metodología y planificación del proyectos, unos
sólidos conocimientos del equipo de proyectos y una adecuada correspondencia entre
las decisiones de configuración y parametrización con la estrategia empresarial.
Otros autores han realizado estudios formales sobre las condiciones que debe
evaluarse para tomar una decisión tan importante como implantar un sistema ERP.
[Sanchez et alt., 2005] destaca los siguientes factores, que completan los expuestos
anteriormente:
? Inversión necesaria en tecnologías de la información;
? Precio de la implantación, que incluye la compra del sistema, los costes internos
y las empresas consultoras;
? Urgencia en la implantación, es decir, plazo previsto del proyecto y
dependencias de su cumplimiento;
? Grado de diferencias entre el funcionamiento actual de la empresa y los proceso
estándar que propone el sistema ERP;
? Interrelación con otros subsistemas o necesidad de desarrollo de interfaces;
? Capacidades del usuario para definir requisitos y especificar necesidades;
? Respuesta a los cambios del personal, es decir, aplicación de una buena política
de gestión del cambio en la empresa y resultados esperados según el tipo de
plantilla;
? Competencia del proveedor seleccionado, experiencias de éxito en otras
empresas, capacidad de soporte, implantación internacional, etc.;
? Capacidad de influencia de la compañía en el proveedor y en las empresas
suministradoras de tecnología y consultoras.
- 213 -
3. Propuesta arquitectural y metodológica
Finalmente [Allen et alt., 2002] estudian implantaciones en entornos universitarios y
destacan los siguientes factores: cultura organizacional, política estructural,
comunicación, tecnología y gestión del conocimiento.
Los factores vistos hasta ahora responden a la calidad antes y durante el proceso de
implantación del ERP. Nuestro asistente debe medir la calidad de los resultados de la
implantación y asociar estos resultados de calidad con las acciones realizadas durante la
parametrización del sistema, que pasa de ser una actividad casi exclusiva de la
implantación a tener significado e importancia durante todo el ciclo de vida del sistema
ERP. Los estudios sobre este tipo de factores son menos y de mayor dificultad. [Markus
et alt., 2001] los analiza y los agrupa en los siguientes:
? Facilidad en la toma de decisiones teniendo a disposición información más
segura y elaborada.
? Mejora en los resultados cuantificables del negocio, como disminución del
inventario y reducción de costes de operación.
? Disminución del tiempo de proceso y de la introducción de errores por parte de
los usuarios.
? Aumento de la satisfacción de clientes y proveedores en cuanto a tiempos de
respuesta, entregas y pagos.
? Facilidad en conseguir flexibilidad empresarial adaptando el sistema a nuevos
procesos y estrategias.
? Aumento del conocimiento de los usuarios finales sobre el sistema, su
utilización en los procesos de negocio y sus consecuencias.
? Mejora de las relaciones y comunicación entre los participantes: dirección,
empleados, clientes y proveedores.
De entre los parámetros anteriores la mayoría de ellos se consiguen con la ayuda del
asistente, tales como el conocimiento sobre los procesos de negocio, el uso del ERP
para llevarlos a cabo, obtener información sobre ellos y facilitar la comunicación y la
facilidad de adaptar la empresa a nuevas estrategias modificando la parametrización del
ERP. El otro grupo de factores se refiere a los resultados del proceso, por lo que entra
dentro del estudio de calidad que proponemos, y afecta a los resultados cuantificables
del negocio y la satisfacción de los clientes y proveedores en sus relaciones con la
empresa.
- 214 -
3. Propuesta arquitectural y metodológica
Dentro de la función de calidad del asistente propuesto se han realizado estudios
relativos a los dos niveles por nosotros definidos: sistema y participante. Estos estudios
son bastante genéricos y se refieren a criterios muy generales y poco detallados. En el
caso de nivel se participante no es necesaria una mayor precisión, ya que se trata de
criterios igualmente válidos para distintas taxonomías empresariales y, dentro de cada
una, para cualquier módulo, submódulo, proceso y función. Por tanto nos basaremos
para establecer nuestra propuesta en los criterios definidos por [Bagchi et alt., 2003]
para el nivel de participante. En este nivel los criterios son muy generales e
independientes de la parametrización concreta realizada, aunque si dependen de la
calidad del sistema ERP seleccionado. En este contexto no serán utilizados por el
asistente en el proceso de retroalimentación de la parametrización, sino que pueden ser
utilizados para la mejora global de la calidad del sistema ERP, sirviendo como entrada a
personalizaciones y mejoras o a peticiones de nuevas versiones a la empresa
constructora o distribuidora, independientemente de las funciones del asistente. Los
criterios definidos son:
? Control sobre el sistema, es decir, los usuarios se siente plenamente seguros de
que las acciones que quieren realizar las han podido realizar tal como querían.
? Actitud hacia el sistema, que indica la aversión o simpatía que produce en los
usuarios la actividad sobre el sistema.
? Intención de uso del sistema, es decir, la intención del usuario de utilizar el
sistema para resolver problemas o realizar actividades relacionadas con su
trabajo.
? Usabilidad del sistema, se refiere a si es fácil y rápido utilizar el sistema después
de haber recibido la formación básica sobre el mismo.
? Personalización del sistema, es decir la capacidad de este de ser modificado en
su comunicación con el usuario según las necesidades del mismo, por ejemplo,
poder crear menús personalizados, definir teclas de función, cambiar la
apariencia de las barras de control, etc.
? Adaptabilidad del sistema, que indica la posibilidad de adaptación a distintos
tipos de usuarios, como usuarios con distintos niveles auditivos o visuales o
distintas capacidades manuales.
? Influencia sobre la productividad, es decir, la opinión del usuario sobre la
influencia que tiene el uso del sistema sobre su productividad.
- 215 -
3. Propuesta arquitectural y metodológica
Todos estos criterios llevan asociados unos índices de tipo cualitativo, es decir, no
pueden ser cuantificados sino que la respuesta del usuario debe ser definida
textualmente con valores del tipo ‘Muy Alto’, ‘Alto’, ‘Medio’, ‘Bajo’ y ‘Muy Bajo’.
Vamos a considerar, para el otro nivel definido, es decir, el nivel de sistema, un
estudio realizado por [Hitt, 1999]. Como ya hemos dicho es muy general y se refiere a
factores relacionados con aspectos financieros. Estos factores son:
? Productividad. Relaciona las ventas valoradas con el número de empleados.
? ROA. Relaciona el beneficio antes de impuestos con el número de códigos
gestionados.
?
?
?
?
?
?
Inventario. Relaciona el beneficio antes de impuestos con el inventario valorado.
ROE. Relaciona el beneficio antes de impuestos con el dividendo.
Margen. Relaciona el beneficio antes de impuestos con las ventas valoradas.
Códigos. Relaciona las ventas valoradas con el número de códigos gestionados.
Cobros. Relaciona las ventas valoradas con el valor de las cuentas a cobrar.
Deuda. Relaciona la deuda total con el dividendo.
La tabla de la figura 3.69 muestra los criterios definidos y los valores obtenidos para
cada uno de ellos antes y después de la implantación de un sistema ERP. Este estudio se
basa en las encuestas realizadas a, aproximadamente, el 70% de las compañías que han
comprado licencias del sistema ERP SAP R/3 entre los años 1986 y 1998. Los
resultados se han medido antes y después de la implantación del ERP, con un intervalo
de dos años.
CRITERIO
VALOR ANTERIOR VALOR POSTERIOR
Productividad
0,0460
0,0478
ROA
0,0695
0,0722
Inventario
0,0580
0,0605
ROE
0,0591
0,0607
Margen
0,0713
0,0731
Códigos
0,0320
0,0329
Cobros
0,0421
0,0432
Deuda
0,0888
0,0867
Figura 3.69 Tabla de resultados de calidad aplicados a implantaciones reales del
sistema SAP R/3
- 216 -
3. Propuesta arquitectural y metodológica
Basándonos en los ejemplos estudiados debemos establecer criterios asociados a los
diferentes procesos que se realicen en la empresa, teniendo en cuenta que los procesos
de negocio van asociados a las clasificaciones establecidas en la taxonomía elegida,
como hemos visto en el punto 3.2.1 (Taxonomía empresarial para la parametrización
ERP). Dentro de cada proceso se definirán criterios que se categorizarán según su
importancia estratégica para el entorno empresarial. Por tanto, cada criterio vendrá
definido por seis atributos:
? Prioridad. Indica la importancia que tiene el criterio en el entorno empresarial.
Sus valores pueden ser: ‘Crítica’, ‘Muy importante’, ‘Importante’, ‘Aceptable’,
‘Poco importante’ e ‘Innecesaria’.
? Requerimientos mínimos. Indica el nivel de soporte que debe proporcionar el
proceso de negocio para poder obtener los valores más positivos del criterio. Sus
valores pueden ser: ‘Soporte básico’, ‘Soporte medio’ y ‘Soporte total’.
? Importancia relativa. Indica la importancia del criterio en relación al resto de
criterios del mismo proceso. Para definirla se aplica un porcentaje. La suma de
la importancia relativa de todos los criterios del mismo proceso debe ser 100.
? Índice. Indica los posibles valores del criterio. Estos pueden definirse con un
rango de valores continuo, por ejemplo, número natural de 0 a 1;un rango de
valores discreto, por ejemplo, número real de 1 a 100; un conjunto de valores
ordenados, por ejemplo, ‘alto’, ‘medio’ y ‘bajo’;
? Valor mínimo. Valor, dentro del índice del criterio, que debe alcanzarse para
considerar el criterio cumplido, aunque con un valor mínimo, es decir, valores
inferiores al mínimo no son aceptables en el entorno empresarial.
? Valor optimo. Valor, dentro del índice del criterio, que debe alcanzarse para
considerar el criterio cumplido positivamente, es decir, valores superiores al
valor óptimo se consideran un cumplimiento excelente y valores comprendidos
entre el valor mínimo y el óptimo se consideran aceptables, aunque mejorables.
El nivel de detalle de los criterios debe establecerse según las necesidades
empresariales. En un primer momento no debería ser demasiado exhaustivo y debería
cuantificar los parámetros más significativos del negocio. Dentro del proceso financiero,
los criterios establecidos por [Hitt, 1999], que ya hemos visto, serían válidos. Una vez
que se tienen bajo control estos criterios básicos, deberían ampliarse para alcanzar
mayor precisión y darnos indicaciones más precisas de las acciones a realizar para
- 217 -
3. Propuesta arquitectural y metodológica
mejorarlos, como hará el asistente aquí diseñado. Presentamos algunos ejemplos de
posibles criterios:
?
?
?
?
?
?
?
?
?
?
?
?
Coste de la emisión de un pedido de compra;
Tiempo medio de almacenaje;
Número de nuevos clientes en el último año;
Tiempo medio de recepción de un material;
Número de correcciones de inventario en recuentos;
Cantidad de productos rechazados en el control de calidad de fin de línea;
Número de códigos faltantes en una orden de montaje final;
Valoración media de la encuesta de satisfacción al cliente;
Número máximo de días de retraso en la entrega de un pedido cliente;
Coste medio de producción de los códigos de clase A;
Coste medio de transporte de un pedido cliente;
Número de facturas erróneas devueltas.
Relación de la métrica de calidad elegida con la parametrización realizada en el
sistema.
Una vez establecido el ámbito, caracterización y tipo de índices y criterios de calidad
a considerar, nos falta por completar el último paso en el proceso de definición de una
métrica de calidad para los resultados de implantaciones ERP. Este paso es necesario
para que el asistente realice su función de retroalimentación, es decir, seleccionar los
criterios más necesarios o importantes, comparar los resultados obtenidos de estos
criterios con los esperados, determinar los criterios incumplidos o mejorables y
proponer al usuario los subdominio priorizados cuya parametrización se debe revisar
según este análisis de resultados y aconsejar correcciones que puedan resolver los
problemas de calidad. Para poder guiar al usuario en esta tarea se deben asociar los
criterios a caminos y parámetros de la red semántica del dominio. Para ello habrá que
clasificar cada parámetro del dominio y cada criterio dentro del ERP. La clasificación se
realizará a tres niveles: módulo, submódulo y categoría. Cada criterio y cada parámetro
se incluirán en esta jerarquía.
Vamos a establecer esta clasificación para un sistema ERP estándar:
1. Módulo Financiero.
1.1. Submódulo Libro mayor.
1.1.1. Categoría Estructura.
1.1.2. Categoría Plan contable.
- 218 -
3. Propuesta arquitectural y metodológica
1.1.3. Categoría Controles.
1.2. Submódulo Contabilidad financiera.
1.2.1. Categoría Flujo de tesorería.
1.2.2. Categoría Cuentas a cobrar.
1.2.3. Categoría Cuentas a pagar.
1.2.4. Categoría Contabilidad de productos.
1.2.5. Categoría Contabilidad bancaria.
1.2.6. Categoría Contabilidad diaria de caja.
1.2.7. Categoría Contabilidad de inventario.
1.2.8. Categoría Contabilidad de impuestos.
1.3. Submódulo de Control de Gestión.
1.3.1. Categoría Contabilidad de centros de coste.
1.3.2. Categoría Contabilidad de órdenes internas.
1.3.3. Categoría Contabilidad de proyectos.
1.3.4. Categoría Costes por producto.
1.3.5. Categoría Control de rentabilidad.
2. Módulo de Recursos Humanos.
2.1. Submódulo Organización.
2.1.1. Categoría Gestión de la contratación.
2.1.2. Categoría Perfil de puestos y salarios.
2.1.3. Categoría Prestaciones.
2.2. Submódulo Gestión del personal.
2.2.1. Categoría Nómina.
2.2.2. Categoría Perfil de los empleados.
2.2.3. Categoría Desarrollo personal y formación.
2.2.4. Categoría Control de presencia.
3. Módulo Logístico.
3.1. Submódulo Aprovisionamiento.
3.1.1. Categoría Proveedores.
3.1.2. Categoría Compradores.
3.1.3. Categoría Órdenes de compra.
3.1.4. Categoría Contratos marco.
3.1.5. Categoría Compras por proyectos.
3.2. Submódulo Inventario y almacenes.
3.2.1. Categoría Inventario físico y recuentos.
3.2.2. Categoría Distribución del almacén.
3.2.3. Categoría Recepción.
3.2.4. Categoría Retirada de material.
3.2.5. Categoría Embalaje y expedición.
3.2.6. Categoría Reservas y asignaciones.
3.2.7. Categoría Control de lotes.
3.3. Submódulo Planificación.
- 219 -
3. Propuesta arquitectural y metodológica
3.3.1. Categoría Previsiones y consumo.
3.3.2. Categoría Políticas de planificación.
3.3.3. Categoría Control de proyectos.
3.3.4. Categoría Estructuras de configuración.
3.3.5. Categoría Seguimiento de las necesidades de material.
4. Módulo de Producción.
4.1. Submódulo Datos técnicos.
4.1.1. Categoría Datos de códigos.
4.1.2. Categoría Clasificación.
4.1.3. Categoría Estructura de materiales.
4.1.4. Categoría Rutas de trabajo.
4.1.5. Categoría Investigación de nuevos productos.
4.2. Submódulo Fabricación.
4.2.1. Categoría Control de lotes.
4.2.2. Categoría Tratamiento del faltante.
4.2.3. Categoría Recogida de datos en planta.
4.2.4. Categoría Aprovisionamiento de líneas.
4.2.5. Categoría Control de calidad.
4.2.6. Categoría Montaje final.
4.3. Submódulo Recursos.
4.3.1. Categoría Centros de trabajo.
4.3.2. Categoría Máquinas y herramientas.
4.3.3. Categoría Control de la capacidad.
5. Módulo de Ventas.
5.1. Submódulo Órdenes de venta.
5.1.1. Categoría Vendedores y áreas de venta.
5.1.2. Categoría Precios y descuentos.
5.1.3. Categoría Configuración de producto.
5.1.4. Categoría Seguimiento de órdenes.
5.1.5. Categoría Facturación.
5.1.6. Categoría Control de proyectos.
5.2. Submódulo Servicio postventa.
5.2.1. Categoría Reparaciones.
5.2.2. Categoría Documentación y soporte a clientes.
5.2.3. Categoría Reclamaciones y devoluciones.
5.2.4. Categoría Control de calidad.
5.3. Submódulo Marketing.
5.3.1. Categoría Estudios de mercado.
5.3.2. Categoría Análisis de competidores.
Como hemos dicho tanto los parámetros que irán asociados al dominio del asistente
como los criterios de calidad convergerán en el mismo grupo ‘Módulo-submódulo-
- 220 -
3. Propuesta arquitectural y metodológica
categoría’. En el caso de los parámetros su clasificación viene dada por la propia
estructura del sistema ERP y por el uso de los parámetros en ciertos módulos y
procesos. Veamos algunos ejemplos de clasificación de parámetros:
? Los parámetros que definen la estructura física del almacén, es decir, la
numeración de plantas, almacenes, secciones, estanterías y ubicaciones
pertenecen al grupo ‘Logístico-Inventario y almacenes-Distribución del
almacén’.
? Los parámetros que definen el tipo de clasificación de los materiales y
productos, como clase A, B o C pertenecen al grupo ‘Producción-Datos
técnicos-Clasificación’.
? El parámetro que define la barrera de la demanda para el consumo de
previsiones pertenece al grupo ‘Logístico-Planificación-Previsiones y consumo’.
? La definición del calendario fiscal y los periodos de ajuste e irregulares
pertenece al grupo ‘Financiero-Libro mayor-Estructura’.
? La definición de la estructura de las áreas de venta pertenece al grupo ‘VentasÓrdenes de venta-Vendedores y áreas de venta’.
En el caso de los criterios de calidad la clasificación es algo más compleja ya que el
origen del no cumplimiento de calidad de un criterio puede ser debido a varias causas,
por tanto, algunos criterios pueden estar asociados a varios grupos de clasificación.
Veremos algunos ejemplos de clasificación de criterios de calidad. Para ello usaremos
alguno de los ejemplos de criterios ya presentados:
? Coste de la emisión de un pedido de compra. Pertenece al grupo ‘LogísticoAprovisionamiento-Órdenes de compra’.
? Tiempo medio de almacenaje. Pertenece a los grupos ‘Logístico-Inventario y
almacenes-Inventario físico y recuentos’ y ‘Logístico-Inventario y almacenesRetirada de material’ y ‘Logístico-Planificación-Políticas de planificación’.
? Número de nuevos clientes en el último año. Pertenece a los grupos ‘VentasMarketing-Estudios
competidores’.
de
mercado’
- 221 -
y
‘Ventas-Marketing-Análisis
de
3. Propuesta arquitectural y metodológica
? Tiempo medio de recepción de un material. Pertenece al grupo ‘LogísticoInventario y almacenes-Recepción’.
? Número de códigos faltantes en una orden de montaje final. Pertenece al grupo
Logístico-Planificación-Seguimiento de las necesidades de material’.
? Número máximo de días de retraso en la entrega de un pedido cliente. Pertenece
a los grupos ‘Ventas-Órdenes de venta-Seguimiento de órdenes’ y ‘LogísticoInventario y almacenes-Embalaje y expedición’.
? Coste medio de producción de los códigos de clase A. Pertenece a los grupos
‘Producción-Datos técnicos-Rutas de trabajo’ y ‘Producción-Recursos-Control
de capacidad’.
- 222 -
3. Propuesta arquitectural y metodológica
3.3. FASES METODOLÓGICAS
Una vez detalladas las bases teóricas y prácticas con las que trabaja el sistema y la
justificación de su uso, en concreto, la taxonomía empresarial, la técnica EPC para el
modelado, las reglas de producción asociadas en redes semánticas y las métricas de
calidad, vamos a detallar las fases metodológicas a desarrollar para dotar de contenido a
los distintos módulos que forman la arquitectura, es decir, poder realizar la obtención y
formalización de la base de conocimientos del dominio, de métricas de calidad y de
usuarios.
En primer lugar estableceremos la obtención del conocimiento contenido en el
módulo del dominio, que forma la parte más compleja de todo el conocimiento
contenido en el asistente. Primero daremos una visión general de las dos fases
principales que lo componen: la obtención de la red semántica y la asociación de
información adicional. La primera fase, por su dificultad y extensión, se ha dividido en
varios pasos: obtención del modelo EPC, transformación y validación mediante la
herramienta ARIS, formalización con el lenguaje XML y generación de la red
semántica. Para cada uno de estos pasos se diseñará una metodología que será explicada
detalladamente.
En segundo lugar estableceremos la forma de obtención del conocimiento contenido
en el módulo del usuario. Dicho contenido se refiere a las preferencias del usuario y su
propia estrategia empresarial relacionada con el dominio. Para construirlo se han
establecido varios pasos que permitirán, partiendo del propio usuario, los expertos y la
taxonomía empresarial creada, determinar valores personalizados de reglas y
parámetros.
Finalmente detallaremos la obtención del conocimiento contenido en el módulo de
calidad. Consiste en partir del conocimiento experto y del conocimiento del dominio
para determinar la relación entre los criterios de calidad genéricos que será posible que
utilice cada organismo o empresa con las reglas de la red semántica que están
implicadas en cada criterio.
3.3.1. Módulo del dominio
El módulo del dominio completo está formado por un conjunto de subdominios.
Cada uno de ellos corresponde a un proceso de negocio, ya sea en sentido amplio, como
Ventas, Logística, etc. o en sentido detallado, como Generación de una orden de
producción o Expedición de un albarán. El conocimiento del dominio comprende no
- 223 -
3. Propuesta arquitectural y metodológica
solo los parámetros y sus posibles valores sino también reglas de actuación para llevar a
cabo determinados procedimientos y conseguir ciertas estrategias empresariales, así
como ayudas que clarifiquen la actuación propuesta por el asistente o justifiquen las
decisiones tomadas por el usuario. Estas ayudas deben asociarse a cada una de las reglas
de producción y a los parámetros relativos. Por ejemplo, asociado a la regla de
producción que guíe la elección de la política de planificación, podrá aparecer un texto
o un video o una grabación audio que explique el significado y las consecuencias de
cada una de las políticas. También se podrá asociar información a los parámetros, no
solo a las reglas, por ejemplo si se decide utilizar la política punto de pedido se debe
definir un valor temporal y se podrá asociar a dicho valor un gráfico que compare los
resultados con distintos valores. Concluyendo, debemos obtener tres tipos de
conocimiento normalizado:
1. Reglas de producción que guíen al usuario a realizar la parametrización del
sistema ERP unidas entre sí formando redes semánticas. El asistente guiará al
usuario por esta red según las preferencias de este, su estrategia empresarial, los
resultados de calidad del uso del sistema, etc.
2. Los parámetros a definir en cada paso y sus posibles valores. Estos datos deberán
estar asociados a los nodos correspondientes de la red semántica y serán
presentados durante el recorrido que realice por ella el usuario.
3. Información asociada a los distintos nodos de la red semántica o a los
parámetros. Esta información servirá de ayuda al usuario en sus decisiones y
como soporte explicativo de la actuación del asistente.
Vamos a presentar de forma gráfica el proceso metodológico dividido en dos fases.
A continuación explicaremos brevemente cada uno de los pasos de cada fase y su
integración. Finalmente detallaremos los pasos más importantes, su metodología y las
herramientas utilizadas: obtención del modelo EPC, representación del modelo EPC
mediante la herramienta ARIS, formalización del modelo EPC en lenguaje XML,
transformación del lenguaje XML en reglas de conocimiento y obtención de parámetros.
La primera fase es la más importante y compleja. Consiste en pasar del conocimiento
del experto en el sistema ERP a un conjunto de reglas de producción unidas entre sí
formando una red semántica, que representa el conocimiento procedimental. La segunda
fase consiste en asociar información adicional, en forma de datos sobre los parámetros
del sistema ERP o en forma de documentos de cualquier tipo (textuales, gráficos,
auditivos, etc.) que se asocien a los parámetros, a las reglas o a cualquier nodo de la red
semántica.
- 224 -
3. Propuesta arquitectural y metodológica
La figura 3.70 muestra el proceso metodológico que realiza el asistente inteligente
durante la primera fase, que obtiene la red semántica.
Experto ERP
Manuales ERP
Procesos ERP
Análisis
lingüístico
Modelo EPC
Adaptación y
validación
Modelo ARIS
Formalización
Modelo XML
Transformación
Red semántica
Figura 3.70 Proceso de obtención de la red semántica
En esta fase se parte del conocimiento de los expertos consultores del sistema ERP,
de los manuales del sistema y de las representaciones existentes de los proceso del
sistema mediante herramientas de modelado de negocio. El uso de este último tipo de
representaciones es muy habitual en el ambiente empresarial y en el de los sistemas de
información empresariales. Por ello el primer paso de esta fase consiste en modelar todo
este conocimiento en forma de diagramas EPC en un proceso denominado Análisis
lingüístico. Estos diagramas deben representar el proceso de parametrización del
sistema ERP mediante eventos y funciones, como ya hemos visto. Además añadiremos
a las funciones que realizan directamente parametrizaciones del sistema los parámetros
a definir en cada una, mediante los elementos de los EPC denominados objetos de
información. El uso de la técnica EPC favorecerá la implicación de los consultores
expertos del sistema, que están habituados a esta forma de representación. Por otro lado
se han establecido algunas normas, que se verán detalladas más adelante, para facilitar
- 225 -
3. Propuesta arquitectural y metodológica
la transformación del lenguaje natural. Igualmente no será difícil utilizar y traducir a
EPC los procesos modelados mediante otras técnicas.
A partir de la obtención de los diagramas EPC realizaremos una serie de pasos
automáticos que consisten en:
?
Adaptación y validación. En este paso, los diagramas EPC que forman el modelo
EPC se implementan en la herramienta ARIS. Para ello debemos adaptar el
modelo obtenido a las normas de esta herramienta. Una vez realizada la
implementación validaremos el modelo definiendo el control de errores a
realizar y utilizando opciones de la herramienta. Los diagramas se modificarán
según los errores encontrados hasta obtener una validación completa. Este paso
es importante, no solo por la utilización de un soporte informático para la
representación, sino también por el aseguramiento de la calidad de los modelos
que nos proporciona.
?
Formalización. Utilizaremos la posibilidad que proporciona la herramienta ARIS
de exportación de información para extraer datos de los modelos EPC
(correspondientes a subdominios) y formalizar cada modelo y cada diagrama
mediante el lenguaje estándar descriptivo XML. De esta forma pasaremos de un
soporte gráfico difícilmente procesable a través de herramientas informáticas a
un lenguaje estándar de definición.
?
Transformación. Este es el último paso de esta fase, en él transformaremos la
información obtenida en lenguaje XML a reglas de conocimiento, que, como
para cualquier sistema basado en el conocimiento, son la base del dominio de
nuestro asistente inteligente. La descripción de eventos y funciones y sus
relaciones lógicas, así como la asociación de objetos de información a funciones
se convertirán en reglas semánticas relacionadas entre sí formando una red
semántica. Como veremos en el diseño del prototipo, en el siguiente capítulo, a
las funciones o conclusiones de las reglas se le asociará la información sobre los
parámetros contenida en los objetos de información.
Veremos a continuación la segunda fase que completa la obtención del módulo del
dominio de nuestro asistente inteligente. La figura 3.71 muestra la fase final del proceso
metodológico en la que se completan con información asociada los parámetros, reglas y
nodos de la red semántica.
- 226 -
3. Propuesta arquitectural y metodológica
Red
semántica
Manuales ERP
Modelo de
datos (CASE)
Experto ERP
Asociación de
información
Módulo del
dominio
Figura 3.71 Proceso de obtención del completo módulo del dominio
En esta fase se parte del conocimiento de los expertos consultores del sistema ERP,
de los manuales del sistema, del modelo de datos del sistema representado mediante una
herramienta CASE (Computer Aided Software Engineering) y de la red semántica que
representa el proceso de parametrización del sistema. El objeto de esta fase es completar
la red semántica obtenida con información adicional útil.
Por una parte debemos obtener información que ayude al usuario a definir los
parámetros asociados a ciertas funciones, esta la obtendremos del modelo
entidad/relación o modelo conceptual de datos de la herramienta CASE, como veremos
más adelante en la explicación detallada de este paso. Básicamente se obtendrá el tipo y
los posibles valores de cada parámetro asociado a funciones presentes en reglas de la
red semántica. Esta información es imprescindible para completar el módulo del
dominio y para que el asistente pueda realizar sus funciones de guía.
Por otra parte obtendremos información adicional explicativa. Esta información
estará relacionada con objetos (conclusiones o funciones, condiciones o eventos y
parámetros) de la red semántica. El formato de esta puede ser variado, de tipo texto,
gráficos, videos, explicaciones en formato audio, etc. y estar en distintos idiomas, de
manera que a cada usuario se le pueda presentar el que mejor se adapte a sus
preferencias. Además puede existir ayuda asociada a las propias reglas que representen
las posibles acciones a tomar y sus consecuencias, es decir, explique las actuaciones que
propone el asistente o las actuaciones ya realizadas. Toda esta información no es
imprescindible para el funcionamiento del asistente pero mejora y completa su
actividad.
- 227 -
3. Propuesta arquitectural y metodológica
Obtención del modelo EPC
El modelo EPC o conjunto de diagramas EPC de un dominio o subdominio
constituirá la fase más difícil de las que veremos a continuación, ya que consiste en la
obtención del conocimiento de los expertos y su formalización. Esta obtención es la
parte más compleja de cualquier sistema basado en el conocimiento. El resto de las
fases que completarán el módulo del dominio se realizarán de forma automática
utilizando varias herramientas y la metodología aquí desarrollada, sin la participación
directa de los expertos.
Cada modelo EPC asociado a un dominio concreto o subdominio contendrá el
conocimiento formalizado de los dos primeros tipos vistos en el punto anterior, es decir,
reglas de producción unidas en una red semántica y parámetros a definir y sus posibles
valores. El origen de este conocimiento lo encontraremos en:
?
Expertos en las funciones del sistema ERP. Estos expertos deberán serlo de las
distintas partes del sistema, módulos, correspondiente a cada subdomino a
modelar, ya que es difícil, casi imposible encontrar expertos en todos los
módulos. Además dentro de cada uno pueden ser necesarios varios expertos,
normalmente consultores de la empresa constructora. Habrá que establecer
entrevistas conjuntas e individuales que nos ayuden a convertir ese
conocimiento en diagramas de proceso en formato EPC.
?
Lenguaje natural (texto). Procede de los manuales del sistema ERP. Es necesario
transformar el lenguaje natural en diagramas de proceso en formato EPC. Estos
manuales pueden ser de distinto tipo, desde los puramente funcionales con
distintos niveles de detalle hasta los técnicos, que no serán útiles durante la
selección y definición de los parámetros.
?
Procesos de negocio. Es habitual en el entorno de los sistemas ERP utilizar
como documentación representaciones gráficas de los procesos de negocio. Hay
distintos métodos de representación y es necesario transformarlos en diagramas
de proceso en formato EPC. Esta transformación es sencilla ya que, como hemos
visto en el apartado 3.2.2 de modelización de procesos, los distintos tipos de
técnicas tienen los mismos elementos principales y con el mismo significado:
actividad, estado, evento y tiempo.
?
Modelo de datos del sistema ERP. Cualquier sistema ERP de calidad tiene como
soporte alguna herramienta CASE (Computer Aided Software Engineering),
utilizada para el desarrollo y mantenimiento del producto software. El modelo
- 228 -
3. Propuesta arquitectural y metodológica
de datos contiene todos los parámetros, su definición, formato y posibles
valores. Esta información será utilizada para completar los diagramas EPC con
objetos de información.
Para la obtención del conocimiento modelado en formato EPC partiendo del lenguaje
natural, ya sea mediante entrevistas con expertos o mediante manuales, nos basaremos
en trabajos anteriores, como [Domínguez, 2005] que estudian la formalización del
lenguaje natural.
En primer lugar dada la complejidad y magnitud del conocimiento a modelar
empezaremos por dividirlo en subdominios más específicos cuantas veces sea necesario
y posible. Para hacer esto no ayudaremos de las organizaciones de los manuales y de la
división de los expertos según sus conocimientos particulares. Cualquier texto de una
cierta longitud tiene una mínima organización, suele estar dividido en partes, capítulos,
puntos, párrafos etc. Esto resultará de gran ayuda. Por ejemplo los manuales de sistemas
ERP están divididos por módulos y estos a su vez por submódulos, por temas, por
procesos generales y dentro de ellos por funciones y datos concretos. Las frases
descriptivas del tema y los títulos de los capítulos introducen y resumen la división del
texto y nos ayudan a dividirlo y comprender su ámbito. Las divisiones del texto y los
marcadores pueden usarse para sugerir los componentes de un proceso. Normalmente
para construir un proceso a partir de un párrafo usamos la cabecera como la conclusión
del proceso y las sentencias del párrafo como funciones relacionadas entre si para
obtener la conclusión. Esta estrategia es válida cuando la frase descriptiva del párrafo o
el título reflejan el aspecto ejecutable del contenido del mismo, si no es así el título debe
ser descartado y se debe buscar abstrayéndolo del texto.
Dentro de esta fase de disminución de la complejidad dividiendo el todo en partes,
podemos aplicar otro criterio. Cuando encontramos un párrafo o texto muy complejo, en
el que el resultado es un proceso, debemos encontrar procesos más simples, de forma
que de la suma de los mismos resulte el proceso inicial. Es decir si para realizar la
parametrización del proceso logístico debemos ejecutar diez funciones, debemos
analizar si el conjunto de algunas de ellas, por ejemplo la cuatro primeras conducen a la
parametrización de un subproceso dentro del logístico, por ejemplo lo relativo al
tratamiento y consumo de la demanda y, de igual modo, analizar el resto de funciones
para dividirlas en subprocesos dentro del logístico. De esta forma representaremos el
proceso inicial como varios diagramas EPC más simples, cada uno de ellos
representando un subproceso y añadiremos un diagrama EPC en el que la unión de las
conclusiones de los subprocesos conduzca al proceso completo. El objetivo es dividir un
proceso muy extenso en procesos intermedios y partir de los procesos intermedios para
llegar al proceso final.
- 229 -
3. Propuesta arquitectural y metodológica
Después de definir esta primera fase simplificadora utilizaremos algunas normas, ya
definidas en [Sturdza et alt., 2002] para analizar un texto y convertirlo en reglas
ejecutables:
?
Generalización. Dada una serie de descriptores de una función se debe
generalizarlos para crear reglas generales, para ello podemos aplicar algunos
métodos que veremos a continuación. En primer lugar cambiaremos constantes
por variables de forma que si dado un valor concreto se debe realizar cierta
parametrización, investigaremos si hay un conjunto de valores más amplio que
cumplan también esa condición y cambiaremos la constante por el conjunto de
valores posibles. En este caso es posible que a partir de dos o más valores
constantes podamos extenderlos creando un rango de valores, por ejemplo de las
constantes 2, 4 y 7, podamos deducir el rango entre 2 y 7 o entre 1 y 10. En
segundo lugar analizaremos si podemos eliminar condiciones, es decir si se usa
el operador conjunción para varios valores estudiaremos si puede ser
generalizado eliminando uno o más términos de la conjunción, que no sean
realmente de cumplimiento obligatorio o añadiendo operadores lógicos tipo OR,
que indiquen posibilidad pero no obligatoriedad de ciertas condiciones. En tercer
y último lugar, utilizaremos las posibles relaciones jerárquicas existentes entre
condiciones, es decir, si un valor determinado de un parámetro del módulo de
recursos humanos se produce cuando un empleado es un vendedor o un técnico
de soporte a las ventas, es posible que podamos extender la condición a la
jerarquía superior, es decir a cualquier empleado que pertenezca al área de
ventas.
?
Especificación. Es el proceso inverso a la generalización. Dada una serie de
descriptores generales, se pueden producir condiciones más restrictivas. Esto se
puede conseguir con algunos métodos que veremos a continuación. En primer
lugar estudiaremos la posibilidad de existencia de alguna generalización
incorrecta, es decir, si algún experto ha extendido un conjunto de valores a un
rango, o a un nivel superior de una jerarquía sin que la condición se cumpla en
todos los elementos del conjunto. En ese caso habrá que elegir los valores
correctos y unirlos mediante un operador de posibilidad. En segundo lugar
estudiaremos la especialización por concesión que aparece en sentencias
introducidas por ‘aunque’, por ejemplo ‘Aunque se establezca política por punto
de pedido a veces faltan existencias’. Esto significa que la parametrización
realizada no ha producido los resultados esperados. Este tipo de frases implican
que un parámetro relacionado con la situación planteada se ha quedado fuera.
Para formalizar un discurso explicatorio con el constructor concesión debemos
buscar el parámetro perdido e incorporarlo como condición. Para el ejemplo
anterior podríamos reescribir ‘Si se establece política por punto de pedido y se
selecciona un buen nivel de inventario no se producirá falta de existencias’, lo
- 230 -
3. Propuesta arquitectural y metodológica
que completará con otro parámetro (‘nivel de inventario’) la parametrización
correcta del sistema. En tercer y último lugar analizaremos la incorporación de
excepciones que consiste en que dada una descripción y un ejemplo negativo
que incorrectamente la satisface, se debe añadir una condición de excepción a la
descripción inicial. Por ejemplo la afirmación ‘Cuando tengamos un código de
clase A estableceremos el nivel de la demanda a cero excepto si su coste es
inferior a diez euros’ tendremos que entenderla, para formalizarla más
fácilmente, como ‘Cuando tengamos un código de clase A y su coste sea
superior a diez euros estableceremos el nivel de la demanda a cero’. Hay
expresiones clave que introducen la especificación por excepciones como
‘excepto’, ‘pero’, ‘a menos que’, ‘de no ser por’, etc. La incorporación de
excepciones en las reglas de formulación es una práctica muy extendida en el
discurso humano ya que incorporar la excepción como una premisa es ejecutable
pero menos natural y explicativa.
Una vez establecidos los procedimientos anteriores para facilitar la formalización del
conocimiento del experto y de los manuales, pasaremos a estudiar las distintas
posibilidades semánticas de un texto y la forma en que pueden ser interpretadas
mediante diagramas EPC, convirtiendo el texto en condiciones y funciones relacionadas
entre sí:
?
Funciones opcionales. Dentro de una secuencia de acciones es fácil que alguna
de ellas sea opcional, es decir, pueda o no realizarse según una determinada
condición. Un ejemplo lo tenemos en la figura 3.72.
- 231 -
3. Propuesta arquitectural y metodológica
C1
E1
C1
E1
F1
F2
F1
XOR
AND
F2
F1
Opcional
C2
E1
C2
E1
F2
F3
F1
F2
E1?
XOR
AND
F3
F2
Figura 3.72 Formalización de funciones opcionales
En la figura anterior vemos como una explicación textual del tipo ‘Si se cumple
C1 debemos realizar primero F1 y después F2, pero si se cumple C2 entonces no
debemos ejecutar F2’ podemos formalizarla fácilmente utilizando operadores
XOR y condiciones negadas. Para cumplir las normas de creación de los
diagramas EPC hemos introducido una condición después de ejecutar la función
F2 que se cumple si se ha realizado F2.
?
Funciones paralelas. Dentro de una secuencia de acciones podemos encontrar
que algunas de ellas no tienen porque realizarse una después de otra sino que se
ejecutan a la vez, quizá por personas diferentes, y cuando terminan ambas
continua el proceso. Un ejemplo lo tenemos en la figura 3.73.
- 232 -
3. Propuesta arquitectural y metodológica
C1
E1
C1
E1
F1
F2
F1
F1
E1?
F2
F1
F3
F1
AND
AND
F3
F1
F2
F3
F2
F2
E1?
F3
E1?
AND
AND
F4
F2
Figura 3.73 Formalización de funciones paralelas
En la figura anterior vemos como una explicación textual del tipo ‘Si se cumple
C1 debemos realizar primero F1 y después, a la vez, F2 y F3. Cuando se
terminen ambas ejecutamos F4’ podemos formalizarla utilizando operadores
AND. Como en el caso anterior, para cumplir las normas de creación de los
diagramas EPC hemos introducido condiciones de fin de ejecución de las
acciones para continuar con el proceso.
?
Funciones paralelas opcionales. Dentro de una secuencia de acciones podemos
encontrar que algunas de ellas se realizan a la vez pero su ejecución individual
depende de ciertas condiciones. Una vez realizadas o no confluyen en la
continuación del proceso. Un ejemplo lo tenemos en la figura 3.74.
- 233 -
3. Propuesta arquitectural y metodológica
C1
E1
C1
E1
F1
F2
F1
F1
E1?
Opcional
F2
F1
F3
F1
Opcional
C2
E1
C3
E1
AND
AND
AND
AND
AND
AND
F3
F1
F2
F3
F2
F2
E1?
F3
E1?
OR
AND
F4
F2
Figura 3.74 Formalización de funciones paralelas opcionales
En la figura anterior vemos como una explicación textual del tipo ‘Si se cumple
C1 debemos realizar primero F1 y después, a la vez, F2 y F3, pero con ciertas
condiciones ya que F2 solo lo haremos si se cumple C2 y F3 solo lo haremos si
se cumple C3. Cuando se terminemos ambas, según cada caso, ejecutamos F4’
podemos formalizarla utilizando operadores disyuntores AND y conjuntores
OR. Como en el caso anterior, para cumplir las normas de creación de los
diagramas EPC hemos introducido condiciones de fin de ejecución de las
acciones para continuar con el proceso.
?
Funciones sincronizadas. Dentro de una secuencia de acciones podemos
encontrar que alguna de ella para realizarse debe esperar a que se cumplan otras
que son independientes entre sí. Podemos referirnos a la figura 3.73 para mostrar
un ejemplo. En ella la función F4 debe esperar a ejecutarse a que terminen las
funciones F2 y F3 que no son secuenciales. Esta formalización, utilizando el
conector AND y condiciones de terminación de las funciones, representa un
discurso textual de tipo ‘Ejecutaremos F4 cuando hallamos terminado de realizar
F2 y F3’.
- 234 -
3. Propuesta arquitectural y metodológica
?
Funciones interrelacionadas. Dadas dos secuencias de acciones independientes
puede llegar un momento que confluyan en una función, a la vez que siguen
cada una su propio proceso. Un ejemplo lo tenemos en la figura 3.75.
Opcional,
después
de F2
F1
F2
F1
F5
F1
F5
F1
E1?
F1
Opcional,
después
de F1
AND
E1?
F2
C1
E1
AND
AND
AND
F3
F1
F4
F1
F5
F2
F5
E1?
OR
AND
OR
AND
F3
F2
F4
F2
Figura 3.75 Formalización de funciones interrelacionadas
En la figura anterior vemos como una explicación textual del tipo ‘Después de
hacer F1, si se cumple C1 y además hemos terminado F2, hacemos F5. Después
de F1 haremos F3 y después de F2 haremos F4, independientemente de la
ejecución de F5’. En este caso utilizaremos operadores AND relacionados para
la función que relaciona las dos secuencias y el operador OR para continuar cada
proceso independientemente.
Hemos visto hasta ahora como crear los diagramas EPC ha partir de conocimiento en
lenguaje natural, convirtiéndolo en condiciones y funciones y relacionándolas
lógicamente mediante operadores. Como colofón de estos criterios de conversión, sería
conveniente, para simplificar el diseño, evitar las relaciones directas entre conectores
lógicos, creando para ello una función de salida del primer conector que identifique la
actividad resultante de las que relaciona el conector. Veamos un ejemplo de esta
simplificación en la figura 3.76
- 235 -
3. Propuesta arquitectural y metodológica
E1
E1
E2
E2
XOR
E3
F2
XOR
AND
F2?
F1
E3
AND
F1
Figura 3.76 Simplificación de la formalización de conectores lógicos relacionados
Para finalizar vamos a analizar la forma de incluir los objetos de información a estos
diagramas. Estos elementos los asociaremos a cada función que implique dar valores a
algún parámetro y llevarán los datos necesarios para realizar esta tarea. La información
del objeto se alimentará del modelo de datos del sistema ERP almacenado en una
herramienta CASE. Esta alimentación veremos como se realiza detalladamente más
adelante, pero antes de acceder al detalle de la herramienta CASE y con la ayuda de
expertos y, principalmente, manuales, el objeto de información se cumplimentará con:
?
El nombre del parámetro o parámetros que deben definirse durante la ejecución
de la función asociada.
?
El nombre de la tabla del sistema ERP que contiene el parámetro o parámetros.
Ya que una función se refiere a un proceso muy detallado, todos los parámetros
asociados se referirán al mismo objeto o tipo de información y pertenecerán a la
misma tabla.
?
El nombre de la transacción on-line del sistema ERP que, por el procedimiento
convencional, se utilizaría para dar valores a los parámetros asociados a la
función. La transacción será única por el mismo motivo expuesto para la
determinación de la tabla. Este dato será fundamental para la posterior
parametrización automática que realizará el asistente inteligente en el sistema
ERP.
- 236 -
3. Propuesta arquitectural y metodológica
Representación del modelo EPC mediante la herramienta ARIS
ARIS (Architecture of Integrated Information Systems) es un método utilizado
ampliamente en la documentación y reingeniería de procesos de negocio y en la
implementación de aplicaciones. ARIS es una arquitectura que surge por la necesidad
de estandarización de los diferentes métodos existentes de modelización de procesos,
que complicaban la comprensión y el intercambio de información. Su creador fue
Scheer, que pensaba [Scheer, 1992] en la necesidad de poder conocer bien los procesos
de negocio de una compañía para enfrentarse a un entorno cambiante y complejo. La
conclusión de su estudio de diferentes métodos fue el desarrollo de ARIS para que
cumpliera dos objetivos:
?
Disponibilidad de un modelo de procedimientos para el desarrollo de sistemas de
aplicaciones integrados: organización, definición de requisitos, especificaciones
de diseño, etc.
?
Disponibilidad de un método sencillo que facilitara el conocimiento sobre los
procesos de negocio y que permitiera evaluarlos, modificarlos e integrarlos.
ARIS proporciona tres diferentes tipos de aplicaciones:
1. El concepto de la arquitectura ARIS que incluye normas para la modelización de
procesos de negocio e intercambio de información.
2. La casa ARIS que gestiona la documentación de la gestión del conocimiento
utilizando las siguientes vistas:
?
?
?
?
?
Vista de funciones. Agrupa los procesos de transformación de información:
función, proceso, actividad y meta.
Vista de la organización. Representa la estructura organizativa de una empresa
por medio de unidades organizacionales, responsabilidades y recursos.
Vista de datos. Comprende los objetos de información y eventos con sus
mensajes disparadores de funciones.
Vista de Output. Contiene entradas y salidas y flujos de información.
Vista de Control. Comprende las relaciones entre los elementos de las distintas
vistas para una descripción integrada de los procesos de negocios.
3. La herramienta de software integrada ARIS Toolset. Internacionalmente utilizada
por expertos y empresas para los proyectos de reingenieria de procesos de
negocio. Esta herramienta permite exportar e importar información en diversos
formatos. ARIS Toolset utiliza los diagramas EPC para la representación de
- 237 -
3. Propuesta arquitectural y metodológica
secuencias lógico-temporales, soportando la descripción integral de los procesos
de negocio en varios niveles de detalle. Parte del concepto de flujo de control
entre funciones uniéndolas mediante eventos que lanzan la ejecución de la
función o son el resultado de esta ejecución. La necesidad de una representación
de los objetos que componen este flujo y de la asociación de otro tipo de
información (organización responsable, entregables, etc.) lleva a la utilización de
los diagramas EPC que unen funciones y eventos mediante flechas y operadores.
La utilización de ARIS Toolset para representar el modelo EPC nos permitirá utilizar
las funciones de ARIS Toolset para la validación del modelo y para la generación
automática de datos sobre los elementos del modelo que permitan formalizarlo en
lenguaje XML y en reglas de conocimiento, fases siguientes del proceso. Esta
herramienta ha sido ya utilizada en [Martínez, 2004] par modelar reglas de producción
en el entorno de Sistema Inteligente de Tutorización para el aprendizaje de
procedimientos.
Veremos a continuación los pasos de adaptación del uso de la herramienta ARIS en
nuestra metodología de construcción de un dominio de conocimiento: comparación de
elementos a utilizar; análisis de validaciones automáticas del modelo; selección de
formatos de exportación de la información.
El primer paso en la utilización de la herramienta ARIS es la verificación de la
existencia y significado de los elementos utilizados, para nuestra metodología, en los
diagramas EPC. Dicho análisis concluye que cada uno de los elementos y sus relaciones
existen y se usan de forma similar en ARIS, excepto los siguientes:
? El elemento proceso. La metodología aquí desarrollada utiliza procesos para
simplificar el diseño de los diagramas EPC. Los procesos son funciones
complejas y no son ejecutables por sí mismos, deben descomponerse y dar lugar
a otro diagrama EPC. ARIS utiliza el concepto de proceso pero su nombre y
representación es diferente. En el paso del modelo de EPC a su diseño en ARIS
tendremos que sustituir el elemento Proceso, allí donde aparezca, por el objeto
‘Interfaz de Proceso’, cuya representación es la figura superpuesta de una
función sobre la de un evento.
? El elemento objeto de información. En nuestra metodología se utiliza para
asociar información, en concreto la necesaria para la parametrización, a una
función. Este elemento existe en ARIS con el mismo significado pero se llama
portador de información y se representa de forma diferente (rectángulo con línea
horizontal inferior quebrada). ARIS lo utiliza para asociar información de
entrada o salida de una función, nosotros adjuntaremos los parámetros asociados
a la función y sus posibles valores o su valor predefinido.
- 238 -
3. Propuesta arquitectural y metodológica
? El elemento flujo de control. En nuestra metodología se utiliza para relacionar
un objeto de información con una función. ARIS utiliza este elemento pero no lo
nombra de forma diferente al resto de conexiones. Su representación es
diferente, ya que lo representa con línea continua y sin flecha.
El segundo paso consiste en analizar las reglas de control y validación existentes en
la herramienta y verificar su bondad y completitud aplicadas al diseño de nuestro
modelo EPC. La importancia de la validación de los diagramas EPC y la definición de
las características y condiciones de calidad han sido analizadas por [Jorgensen, 2003] y
[Aalst, 1999]. De estos análisis se deduce que un conjunto de diagramas EPC, nuestro
modelo EPC, debe ser:
? Regular, el modelo parte de un único evento inicial o llega a un único evento
final y, además, cada nodo forma parte de un camino entre los eventos iniciales
y finales.
? Sólido, no hay funciones muertas, siempre hay un camino por el que se puede
llegar a ellas, además cada evento es alcanzable mediante alguna secuencia de
condiciones.
? Bien estructurado, no existen bucles sin salida y se cumplen las condiciones de
información y de relación entre elementos (por ejemplo no hay paso directo
entre dos funciones).
Para que cumpla estas características hemos definido una serie de condiciones que se
deben verificar, tanto para elementos, vistos individualmente, y sus atributos, como para
diagramas EPC, que muestran relaciones entre elementos, y modelos EPC, que
relacionan diagramas. Su cumplimiento garantiza la estructura lógica, consistencia y
significación completa del modelo diseñado en esta metodología. Las reglas que forman
este conjunto son las siguientes:
1. En el contexto del mismo modelo de conocimiento no pueden existir modelos
EPC con el mismo nombre.
2. En el contexto de un mismo modelo EPC no pueden existir diagramas EPC con
el mismo nombre.
3. En el contexto del mismo modelo EPC no pueden existir elementos con el mismo
nombre, aunque si pueden ser usados múltiples veces en distintos diagramas.
- 239 -
3. Propuesta arquitectural y metodológica
4. Todos los elementos iniciales de cualquier camino deben ser de tipo evento,
función o proceso.
5. Todos los elementos finales de cualquier camino deben ser de tipo evento.
6. Todos los nodos de un modelo deben ser alcanzables por algún camino. Esta
regla es útil para verificar que no existe ningún elemento innecesario. El contexto
de validación de esta regla es el modelo EPC, no diagramas EPC individuales, ya
que el camino que llegue a un nodo puede pasar a través de procesos, o lo que es
lo mismo, varios diagramas EPC conectados. En particular, la existencia de
conectores lógicos AND y XOR seguidos que conectan los mismos elementos
indica el incumplimiento de esta regla, como puede verse en la figura 3.77.
E1
E2
AND
AND
F1
F2
E3
E4
XOR
F3
E5
Figura 3.77 Estructura inválida AND-XOR
7. No deben existir bucles repetitivos sin salida. Un ejemplo de esta estructura
puede verse en la figura 3.78.
- 240 -
3. Propuesta arquitectural y metodológica
E1
E2
OR
F1
Figura 3.78 Estructura inválida de bucle repetitivo
8. Todo proceso debe tener asociado un diagrama EPC que exista en el modelo
EPC. Esta regla comprueba que cada proceso presente en un modelo EPC debe
ser desarrollado en algún diagrama EPC del modelo, y que si este diagrama
también contiene uno o varios procesos, estos, a su vez, tiene que ser
desarrollados en otros diagramas EPC, y así sucesivamente, hasta llegar a uno o
varios diagramas que no contengan procesos. Esta regla es necesaria para
verificar que todos los procesos se descomponen, al final, en funciones.
9. Los sucesores de un conector lógico solo pueden ser funciones, procesos u otros
conectores.
10. Los predecesores de un conector lógico solo pueden ser eventos u otros
conectores.
11. Un conector lógico de tipo distribuidor o disyuntor tiene una única entrada y una
o más salidas.
12. Un conector lógico de tipo distribuidor o disyuntor (una entrada, varias salidas)
solo puede ser AND, en caso de OR o XOR, la ejecución no tendría criterio de
decisión. La figura 3.79 muestra un ejemplo de este tipo de error.
E1
OR
F1
F1
Figura 3.79 Estructura de decisión incorrecta
- 241 -
3. Propuesta arquitectural y metodológica
13. Un conector lógico de tipo unificador tiene una única salida y una o más
entradas. Esta regla tiene una excepción ya que debe tener una única salida de
tipo función o proceso pero puede tener varias salidas de tipo conector lógico. Un
ejemplo de esta posibilidad lo muestra el diagrama EPC de la figura 3.80 que
ejecuta el proceso de lanzamiento de una orden en producción.
Apertura
manual de la
orden
Fecha de
apertura
alcanzada
OR
Faltantes
en la orden
AND
AND
Lanzar
orden
Informar al
planificador
Orden en
producción
Alerta del
planificador
Figura 3.80 Excepción de la estructura de un conector de tipo unificador
14. Un objeto de información solo puede estar relacionado con una función o un
proceso.
15. Una función o un proceso solo pueden tener como predecesor un evento o un
conector en la ejecución de un camino.
16. Una función o un proceso solo pueden tener como sucesor un evento. Esta regla
es necesaria porque la valoración de funciones se realiza siempre a través de un
evento. Para cumplir esta regla y simular la posibilidad de valoración de una
función como positiva o negativa y la posterior ramificación de la ejecución de
funciones según este valor, se deben crear dos diagramas EPC complementarios
que sustituyan a un conector lógico XOR que actúa como distribuidor de los dos
eventos contrarios. Un ejemplo de esta posibilidad se muestra en la figura 3.81
- 242 -
3. Propuesta arquitectural y metodológica
que representa los dos caminos de ejecución después de realizar una inspección
de material en recepción.
EPC INICIAL
EPC FINALES
Realizar
inspección
Inspección
realizada
XOR
Inspección
positiva
Inspección
negativa
Almacenar
material
Reparar
material
Material en
almacén
Material
reparado
Realizar
inspección
Comprobar
Resultado
inspección
Realizar
inspección
Comprobar
Resultado
inspección
Inspección
realizada
Inspección
positiva
Inspección
realizada
Inspección
negativa
AND
AND
Almacenar
material
Reparar
material
Material en
almacén
Material
reparado
Figura 3.81 Ejemplo de sustitución de conector distribuidor de eventos negados por dos
diagramas EPC complementarios
17. Un evento solo puede tener como predecesor una función o un proceso. Esta
regla es necesaria porque no tiene sentido un evento que no se refiere a ninguna
función, habiendo ya eliminado los eventos precedidos de un operador XOR que
actúa como distribuidor de dos eventos contrarios, posibles resultados de una
función. El ejemplo de la figura 3.81 de la regla anterior es válido para ilustrar
esta posibilidad.
18. Un evento solo puede tener como sucesor una función, un proceso o un conector.
19. Todas las funciones, procesos y eventos tienen como máximo una conexión
entrante y una conexión saliente. Un evento puede activar varias funciones, pero
su representación debe incluir un operador entre el evento y sus funciones que
indique la lógica de la activación (todas las posibles, solo una o algunas entre las
posibles). Igualmente, una función puede generar varios eventos, pero, como en
el caso anterior, un operador debe funcionar como nexo de unión. La figura 3.82
muestra un ejemplo de incumplimiento de esta regla.
- 243 -
3. Propuesta arquitectural y metodológica
F1
E1
E2
Figura 3.82 Ejemplo de incumplimiento de la regla debido a entradas y/o salidas
múltiples
20. El evento resultante o conclusión de un proceso en un diagrama EPC existe
también como evento final en el diagrama EPC asociado al proceso. Esta
comprobación debe hacerse en el contexto del modelo EPC.
21. No pueden existir elementos sin conexión. Cada elemento en un modelo EPC
debe poseer uno o más predecesores o sucesores.
22. Un elemento no puede estar conectado consigo mismo.
23. Deben tener valores válidos los atributos definidos como necesarios según el tipo
de elemento, por ejemplo será necesario, solo en el caso de objetos de
información, definir un atributo que indique el contenido del objeto.
Una vez definidas las reglas de validación a realizar sobre el modelo EPC, veremos
la forma de aplicarlas antes de pasar a la siguiente fase metodológica. El proceso será
utilizar las facilidades de la herramienta ARIS Toolset para verificar el modelo,
obteniendo informes que indiquen incumplimiento y revisando, modificando y
volviendo a validar hasta alcanzar un modelo EPC correcto. ARIS contiene un módulo
específico para realizar el control y validación de los EPC. Este módulo se llama
Asistente de Control Semántico y se compone de un conjunto de reglas definidas y un
proceso de ejecución de estas reglas contra un diagrama concreto o modelo completo.
También es posible modificar, eliminar o incluir reglas durante el proceso de
verificación. Esta opción junto con la posibilidad de obtención de informes detallados
de los componentes y las relaciones de los diagramas nos permite una validación
automática. En función de esta opción, la metodología ARIS establece dos tipos de
reglas semánticas y una subdivisión en grupos de cada uno de estos tipos, constituyendo
la siguiente estructura:
? Reglas predefinidas. Son aquellas consideradas por ARIS básicas e
imprescindibles, y por tanto, el usuario no las puede modificar ni borrar. Son de
dos tipos :
- 244 -
3. Propuesta arquitectural y metodológica
o Reglas estructurales. Son aquellas reglas que comprueban las
relaciones y la estructura del tipo de diagrama ARIS seleccionado.
Existen reglas especiales para cada tipo y se combinan en subgrupos,
cada uno de los cuales se refiere a uno o varios tipos de diagramas.
Dentro de los seis subgrupos definidos existe uno específico para
diagramas de procesos, que incluye los diagramas EPC y los grupos de
diagramas EPC.
o Reglas de asignación. Son aquellas reglas que comprueban las
relaciones de cada tipo de objeto con su diagrama asignado. Las reglas
se combinan en subgrupos, cada uno de los cuales se refiere a un tipo
de objeto, como datos, funciones, elementos organizativos y UML.
? Reglas extensibles. Son aquellas que el usuario de los modelos puede incluir y
modificar según sus convenciones propias de construcción de cada diagrama.
Estas reglas las divide en dos tipos:
o Aplicables a objetos individuales. Dentro de estas hay dos categorías:
1.
Reglas de asociación. Esta clase de reglas examina la relación
de una definición de objeto con los diagramas asociados a
ella.
2.
Reglas de atributo de objeto. Esta clase de reglas comprueba
si, para objetos de un tipo en concreto, se han mantenido tipos
determinados de atributos.
o Aplicables a diagramas completos y a grupos de diagramas. Dentro de
estas hay tres categorías:
1.
Reglas de asignación. Esta clase de reglas examina
asignaciones de objeto de un tipo determinado a objetos de
otro tipo por medio de tipos definidos de relación.
2.
Reglas de atributo de relación. Esta clase de reglas
comprueba si, para las relaciones de un tipo en concreto, se
han mantenido tipos determinados de atributos.
3.
Reglas de estructura. Esta clase de reglas examina las
relaciones y estructuras dentro de uno o varios diagramas.
El tercer paso consiste en analizar la generación automática de datos, que realiza la
herramienta, sobre los elementos de los diagramas EPC presentes en ARIS. Una vez
estudiada seleccionaremos aquella información útil y necesaria para formalizar el
conjunto de diagramas utilizando un lenguaje estándar como XML, paso siguiente de
nuestra metodología. Dentro de las funciones de Evaluación de ARIS Toolset
- 245 -
3. Propuesta arquitectural y metodológica
utilizaremos la generación de ficheros de informes para diagramas de procesos, que nos
proporcionarán automáticamente tablas de datos estructuradas que describen los objetos
y relaciones que forman el modelo de EPC. Una vez obtenidas las tablas utilizaremos su
información para generar una descripción del modelo en lenguaje XML, tal como se
explica en el paso siguiente.
Los informes ARIS posibles nos permiten seleccionar la forma de disponer de la
información: tipo de fichero de salida, nivel de detalle obtenido, grupos de modelos,
modelos individuales o diagramas individuales. La información obtenida incluirá la lista
de los elementos incluidos en la selección, los atributos asociados a cada uno de los
elementos y las relaciones entre ellos. Para poder seleccionar elementos de un solo
diagrama EPC o de un modelo EPC completo, o incluso de varios modelos EPC, a cada
diagrama en ARIS se le asigna un grupo (que corresponde con nuestra definición de
modelo) y la petición de información se puede hacer para uno o varios grupos o para
uno o varios diagramas. Para obtener toda la información necesaria para su posterior
formalización se han seleccionado dos informes de ARIS:
1. ‘TablasObjetoModelo.rsm’. A través de esta utilidad ARIS genera, en el formato
seleccionado, por ejemplo hoja Excel, las relaciones entre los distintos elementos
que componen la selección. Las posibles relaciones dentro de la herramienta
ARIS son: eventos con funciones y conectores; funciones con conectores,
portadores de información y eventos; conectores con eventos, funciones y
conectores; portadores de información con funciones. De estas relaciones, según
la metodología y estructura de reglas diseñada en este trabajo no son posibles las
relaciones función-conector ni conector-evento, ya que las entradas a conectores
no pueden ser funciones (deben ser entidades lógicas evaluables) y las salidas de
conectores no pueden ser eventos (deben ser funciones porque representamos
conocimiento procedimental, que guía la ejecución de actividades). Para este tipo
de informe los interfaces de proceso se consideran funciones a todos los efectos.
Para distinguir entre ambos tipos de elementos utilizaremos el atributo
‘descripción/definición’ que llevará el texto ‘proceso’ en el caso de que el
elemento sea un interfaz de proceso. La información viene ordenada por el
nombre del objeto origen de la relación.
2. ‘Infomodelo.rsm’. Como en el caso anterior ARIS genera la lista de los
elementos que componen la selección (eventos, funciones, interfaces de proceso,
conectores y portadores de información) y para cada uno los datos asociados o
atributos, como nombre, creador, fecha de alta y modificación, comentarios,
posición física en el gráfico, etc. En el caso de los interfaces de proceso se
incluye además el atributo ‘comentario/ejemplo’, que en nuestra metodología
utilizamos para incluir el nombre del diagrama EPC asociado. La información
viene ordenada alfabéticamente por nombre de objeto.
- 246 -
3. Propuesta arquitectural y metodológica
En los dos informes anteriores nos hemos referido a conector en el sentido genérico
de conector lógico. ARIS también se refiere a ellos así, genéricamente, en sus informes,
aunque siempre añade al nombre del conector, el tipo que puede ser AND, OR o XOR.
Esta información es la única incluida en el primer informe, sobre relaciones, que tiene
que ver con atributos, es decir, que no es identificador único (nombre) de los
componentes de la relación ni de la propia relación.
ARIS asocia un nombre a las relaciones que genera en sus informes. El nombre es
significativo, es decir, representa los dos tipos de elementos que se relacionan y el
sentido de la relación. La tabla de la figura 3.83 muestra las posibles relaciones que
contemplamos en nuestra metodología y el nombre que ARIS le asigna a cada una,
además del tipo de elemento que es origen de la relación (tipo de objeto 1) y del tipo de
elemento destino de la relación (tipo de objeto 2).
RELACIÓN
TIPO OBJETO 1
TIPO OBJETO 2
está asignado
conector
función
enlaza
es enlazado por
conector
conector
conector
conector
es evaluado
evento
conector
es generado
crea
evento
función
función
evento
activa
es activado
evento
función
función
evento
proporciona entrada para
recibe entrada de
portador de información función
función
portador de información
Figura 3.83 Relaciones, según la nomenclatura ARIS, presentes en nuestra metodología
Formalización del modelo EPC en lenguaje XML
Partiendo de un modelo de diagramas EPC que representa un subdominio del
conocimiento y que está formado por el conjunto de los diagramas relacionados entre sí
a través de procesos, premisas y conclusiones, obtendremos una representación formal
del mismo, es decir, del subdominio de conocimiento, que vaya más allá de una mera
representación gráfica y que, por tanto, sea manejable por procesos automáticos.
La representación formal elegida en este trabajo ha sido el lenguaje XML. El motivo
en la elección de este medio ha sido la propia definición, características y ámbito del
XML y a su amplio y creciente uso en entornos científicos y empresariales, debido a su
- 247 -
3. Propuesta arquitectural y metodológica
sencillez y sus prestaciones. A XML se le reconoce como un lenguaje de marcado, es
decir descriptivo, más que operativo y nace como un estándar para el intercambio de
información a través de medios telemáticos.
A través de XML podemos representar dos conceptos fundamentales de cualquier
tipo de documentos: su estructura y su contenido, es decir, podremos representar la
estructura de cada uno de los diagramas EPC (posición vertical u horizontal de sus
componentes, estructura de las conexiones, etc.) y el contenido de los mismos (acciones
y procesos a ejecutar, conexiones lógicas entre ellos, resultados de las acciones, etc.).
Obtenemos, además, las siguientes ventajas:
?
?
?
?
?
Estructura formal y concisa.
Posibilidad de extensiones, incluyendo nuevos datos o elementos.
Amplio soporte tecnológico para su creación y manipulación.
Fácil de aplicar e implantar.
Fácil de leer y editar por medios técnicos y, también, humanos.
Veamos a continuación la estructura, el contenido y la forma de generación de la
representación en XML que se obtendrá del modelo de diagramas EPC. El principal
elemento de esta representación es el diagrama EPC. Es decir, habrá un primer nivel de
información que será cada uno de los diagramas que forman el modelo y ese nivel se
repetirá tantas veces como diagramas EPC haya en el modelo. Los elementos presentes
en cada diagrama serán de segundo nivel.
Los elementos que formarán parte de la representación XML son:
? Diagrama EPC. Elemento de primer nivel. Debe caracterizarse por el nombre del
diagrama. Se generará un elemento de este tipo por cada diagrama, creado en
ARIS, existente en el directorio del subdominio que se trata. Se tomará de la
información asociada al diagrama en ARIS el nombre.
? Acción. Elemento de segundo nivel. Debe caracterizarse por el nombre de la
acción. Se generará un elemento de este tipo por cada función presente en el
diagrama que se trata, creado en ARIS. Se tomará de la información asociada a
la función en ARIS el nombre.
? Evento. Elemento de segundo nivel. Debe caracterizarse por el nombre del
evento. Se generará un elemento de este tipo por cada evento presente en el
diagrama que se trata, creado en ARIS. Se tomará de la información asociada al
evento en ARIS el nombre.
- 248 -
3. Propuesta arquitectural y metodológica
? Proceso. Elemento de segundo nivel. Debe caracterizarse por el nombre del
proceso y por el nombre del diagrama EPC que lo desarrolla. Se generará un
elemento de este tipo por cada interfaz de proceso presente en el diagrama que
se trata, creado en ARIS. Se tomará de la información asociada al interfaz de
proceso en ARIS los datos del nombre y del modelo origen (diagrama EPC
asociado en ARIS a una interfaz de proceso).
? Objeto información. Elemento de segundo nivel. Debe caracterizarse por el
nombre y el contenido del nodo informativo de ARIS portador de información.
Se generará un elemento de este tipo por cada portador de información presente
en el diagrama que se trata, creado en ARIS. Se tomará de la información
asociada al portador de información en ARIS el nombre y el hipervínculo del
propio portador de información como un campo de texto.
? And. Elemento de segundo nivel. Debe caracterizarse por un identificador
secuencial, los elementos de entrada al conector, los elementos de salida del
conector, el tipo de secuencia entre los elementos de entrada y el tipo de
secuencia entre los elementos de salida. Se generará un elemento de este tipo por
cada conector de tipo AND presente en el diagrama que se trata, creado en
ARIS. Se tomará de la información asociada al conector AND en ARIS los datos
del nombre y de los nombres de los elementos de entrada y de salida. Los
elementos de entrada pueden ser eventos y otros conectores lógicos. Los
elementos de salida pueden ser funciones, interfaz de procesos y otros
conectores lógicos. El tipo de secuencia entre los elementos de entrada y el tipo
de secuencia entre los elementos de salida se obtienen de la información gráfica
que proporciona ARIS para cada elemento de un diagrama, en esta información
incluye las coordenadas horizontal y vertical de la figura dentro del diagrama.
? Or. Elemento de segundo nivel. Se caracteriza por los mismos datos del
elemento anterior, and. Se generará un elemento de este tipo por cada conector
de tipo OR presente en el diagrama que se trata, creado en ARIS. La forma de
obtención de la información es la misma que la expuesta anteriormente para el
elemento and.
? Xor. Elemento de segundo nivel. Se caracteriza por los mismos datos del
elemento anterior, and. Se generará un elemento de este tipo por cada conector
de tipo XOR presente en el diagrama que se trata, creado en ARIS. La forma de
obtención de la información es la misma que la expuesta anteriormente para el
elemento and.
- 249 -
3. Propuesta arquitectural y metodológica
? Conector información. Elemento de segundo nivel. Debe caracterizarse por un
identificador secuencial, el elemento de entrada y el elemento de salida de la
conexión. Se generará un elemento de este tipo por cada flujo de información
presente en el diagrama que se trata, creado en ARIS. Se tomará de la
información asociada a la conexión en ARIS los datos de los nombres del
elemento de entrada y del de salida. El elemento de entrada debe ser un portador
de información. El elemento de salida puede ser una función o un interfaz de
proceso.
? Conector condición. Elemento de segundo nivel. Debe caracterizarse por un
identificador secuencial, el elemento de entrada a la conexión, el elemento de
salida de la conexión y el tipo de conexión. Se generará un elemento de este tipo
por cada flujo presente en el diagrama que se trata que no entre o salga de un
elemento and, or o xor, creado en ARIS. Se tomará de la información asociada a
la conexión en ARIS los datos de los nombres del elemento de entrada y del de
salida. El tipo de condición se calculará en función del tipo de elemento de
entrada. En el caso de tipo de condición ‘precondición’ el elemento de entrada
debe ser un evento y el de salida debe ser una función o un interfaz de proceso.
En el caso de tipo de condición ‘poscondición’ el elemento de entrada debe ser
una función o un interfaz de proceso y el de salida debe ser un evento.
Además de los datos propios, todos los elementos tendrán un identificativo que
puede ser un número secuencial.
Hemos visto como para nuestro asistente es importante la secuencia de ejecución de
los elementos de entrada y salida de cada conector lógico (AND, OR, XOR). En el
apartado de bases metodológicas de este capítulo se presento una solución gráfica,
mediante representación secuencial horizontal (es importante la secuencia de ejecución)
o vertical (es indiferente la secuencia de ejecución). Entre los atributos de los elementos
XML que formalizan un diagrama EPC, descritos anteriormente, los que representan
conectores lógicos, es decir, and, or y xor, incluyen dos atributos que indican la
importancia o no de la secuencia de ejecución de sus entradas y de sus salidas. Hemos
indicado como para obtener estos datos se parte la información gráfica que proporciona
ARIS para cada elemento de un diagrama, en esta información incluye las coordenadas
horizontal y vertical de la figura dentro del diagrama. Veamos como:
1. Tanto para los elementos de entrada como los de salida diremos que el tipo de
secuencia entre los elementos será ‘ordenado’ cuando la coordenada vertical de
cada uno de los elementos de la entrada (o salida) tenga el mismo valor o la
diferencia sea menor a un rango similar a la posible imprecisión gráfica. En caso
contrario el tipo de secuencia entre los elementos bien de entrada o de salida será
‘no_ordenado’.
- 250 -
3. Propuesta arquitectural y metodológica
2. En el caso de tipo de secuencia entre elementos de entrada (o salida) se listarán
dichos elementos en XML, dentro del elemento and, or o xor correspondiente, de
forma ordenada, del primero al último en orden de ejecución. Para conseguirlo se
tomará como primer elemento el de menor valor de su coordenada horizontal y
así sucesivamente, hasta el último, que será el que tenga un valor mayor.
La figura 3.84 representa la estructura del formato XML aplicado a un modelo EPC.
Al lado de cada elemento de la estructura aparece su cardinalidad en la misma. El
elemento inicial es el modelo EPC que estará compuesto de uno o más diagramas EPC.
Cada diagrama EPC debe contener, al menos, un evento (el final), pero puede tener
muchos más. Del resto de elementos definidos puede contener ninguno o varios, parece
lógico que tuviera una función, pero esta puede ser sustituida por un proceso, por lo que
realmente no podemos decir que la cardinalidad mínima obligatoria de alguno de estos
elementos sea uno. Todos los elementos de tipo conexión deben tener, al menos, una
entrada y una salida. Los conectores lógicos o elementos And, Or o Xor pueden tener
como entrada ninguno o varios conectores And, Or o Xor y ninguno o varios eventos y
pueden tener como salida, ninguno o varios conectores And, Or o Xor, ninguna o varias
funciones y ninguno o varios procesos. Los conectores de información solo pueden
tener como entrada un objeto de información y como salida una función o un proceso.
Los conectores condicionales pueden ser de dos tipos, en el caso de poscondiciones
tiene una única entrada, una función o un proceso, y una única salida que debe ser un
evento. En el caso de precondición tienen una única entrada que es un evento y una
única salida que puede ser una función o un proceso.
- 251 -
3. Propuesta arquitectural y metodológica
Modelo EPC
1..N
Diagrama
EPC
1..N
Evento
0..N
0..N
Conector
condicional
Función
0..1 1..1
Poscondición/
Entrada:
Función
0..1
Poscondición/
Entrada:
Proceso
1..1
Poscondición/
Salida:
Evento
Precondición/
Entrada:
Evento
0..1
Precondición/
Salida:
Función
0..N
0..N
Proceso
0..N
Objeto de
información
And/Or/Xor
0..N
0..N
Entrada:
Eventos
Salida:
Función
0..N 0..N
Conector
información
1..1
0..1
Entrada:
Objeto de
información
Salida:
Función
0..1
Salida:
Proceso
Entrada:
And/Or/Xor
0..1
0..N
Salida:
Proceso
0..N
Precondición/
Salida:
Proceso
Salida:
And/Or/Xor
Figura 3.84 Estructura del formato XML aplicado a un modelo EPC
Para completar el paso del modelo de EPC de un subdominio del conocimiento del
asistente, detallaremos un ejemplo de formalización XML aplicado a un modelo EPC
que contiene un único diagrama EPC, mostrado en la figura 3.85.
- 252 -
3. Propuesta arquitectural y metodológica
Pedido abierto
en vigor
XOR
Pedido normal
pendiente
Servicio
aceptado
XOR
Proceso de
recepción del
material
Material
recepcionado
AND
Generar
factura
Datos factura
Factura
generada
Figura 3.85 Ejemplo de diagrama EPC
La figura 3.86 muestra la estructura en formato XML de un modelo EPC en el que el
único diagrama EPC es el presentado en la figura 3.85.
<modelo id = “00000000”>
<nombre = “modelo subdominio gestion almacenes” />
<epc id = “00000001”>
<nombre = “epc-generación factura” />
<evento id = “00000002”
<nombre = “pedido abierto en vigor” />
</evento>
<evento id = “00000003”>
<nombre = “pedido normal pendiente” />
</evento>
<evento id = “00000004”>
<nombre = “servicio aceptado” />
- 253 -
3. Propuesta arquitectural y metodológica
</evento>
<proceso id = “00000005”>
<nombre = “proceso de recepción del material” />
</proceso>
<evento id = “00000006”>
<nombre = “material recepcionado” />
</evento>
<funcion id = “00000007”>
<nombre = “generar factura” />
</funcion>
<evento id = “00000008”>
<nombre = “factura generada” />
</evento>
<objeto_informacion id = “00000009”>
<nombre = “datos factura” />
<contenido = “C:/mySAPR3/Ventas/Facturas/
Parametrizacion/Datos_factura.pdf“ />
</objeto_informacion>
<xor id = “00000010”>
<nombre = “xor1” />
<entrada_id = “00000002” />
<entrada_id = “00000003” />
<salida_id = “00000012” />
<sec_ent = “no_ordenado” />
<sec_sal = “no_ordenado” / >
</xor>
<xor id = “00000011”>
<nombre = “xor2” />
<entrada_id = “00000004” />
<entrada_id = “00000006” />
<salida_id = “00000012” />
<sec_ent = “no_ordenado” />
<sec_sal = “no_ordenado” />
</xor>
<and id = “00000012”>
<nombre = “and1” />
<entrada_id = “00000010” />
<entrada_id = “00000011” />
- 254 -
3. Propuesta arquitectural y metodológica
<salida_id = “00000007” />
<sec_ent = “no_ordenado” />
<sec_sal = “no_ordenado” />
</and>
<conexión_cond id = “00000013”>
<nombre = “conexión_cond1” />
<entrada_id = “00000005” />
<salida_id = “00000006” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_cond id = “00000014”>
<nombre = “conexión_cond2” />
<entrada_id = “00000007” />
<salida_id = “00000008” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_infor id = “00000015”>
<nombre = “conexión_infor1” />
<entrada_id = “00000009” />
<salida_id = “00000007” />
</conexión_infor>
</epc>
</modelo>
Figura 3.86 Ejemplo de formalización XML
Transformación del lenguaje XML en reglas de conocimiento
La base del dominio de conocimiento de nuestro asistente, en el marco de los
sistemas basados en el conocimiento, son un conjunto de reglas de producción
relacionadas entre sí formando una red semántica. Hemos desarrollado una metodología
que permite obtenerlas a partir de un conjunto de diagramas (modelo EPC) que se ha
formalizado utilizando el estándar XML. Para poder obtener las reglas a partir de los
diagramas EPC hemos establecido una serie de pasos que detallaremos a continuación.
En primer lugar las reglas de producción se obtendrán a partir de las relaciones del
diagrama, los nodos, como eventos o funciones, proporcionaran el texto a las reglas
pero no generan reglas. De entre los distintos tipos de conexiones no debemos tener en
- 255 -
3. Propuesta arquitectural y metodológica
cuenta los conectores de información que formarán parte del módulo del dominio como
conocimiento asociado pero no se transformarán en reglas. Este tipo de conector lo
utilizará el asistente durante la ejecución de las reglas presentando información
necesaria al proponer la realización de funciones al usuario.
Respecto a los conectores condición (precondicones y poscondiciones) relacionan
eventos con funciones o procesos y deben generar reglas simples como muestra la
figura 3.87.
E1
F1
F1
E1
SI E1 ENTONCES F1
SI F1 ENTONCES E1
Figura 3.87 Reglas obtenidas de conectores condición
En las reglas anteriores y en las siguientes aparecen funciones. Como ya hemos visto
las funciones y los procesos pueden aparecer indistintamente en los diagramas. Para la
generación de reglas las funciones y los procesos funcionan de la misma forma. La
única diferencia la realizará el asistente durante la ejecución, ya que cuando lance una
función esperara la confirmación de su ejecución por parte del usuario y cuando lance
un proceso esperara la confirmación a través de la ejecución de las reglas obtenidas del
diagrama EPC asociado al proceso.
Respecto al último tipo de conectores a tratar, los conectores lógicos And, Or y Xor,
pueden generar dos tipos de reglas: las reglas compuestas cuando alguna de sus entradas
o sus salidas es otro conector lógico y las reglas simples cuando las entradas y salidas
son solo de tipo evento, función o proceso. Teniendo en cuenta los posibles tipos de
conexiones lógicas ya definidos en esta metodología, la figura 3.88 muestra las posibles
reglas generadas por los conectores conjuntores (varias entradas y una salida) y
disyuntores (una entrada y varias salidas).
- 256 -
3. Propuesta arquitectural y metodológica
E1
E1
E2
C
C = AND/OR/XOR
AND
F1
SI E1
AND
OR
XOR
F1
E2 ENTONCES F1
F2
SI E1 ENTONCES F1 Y F2
Figura 3.88 Reglas simples obtenidas de conectores lógicos
Las posibles reglas compuestas generadas por conectores lógicos unidos a otros
conectores lógicos dependerán de los tipos de conector relacionados. Los tipos aquí
considerados son los conjuntores y los disyuntores, ya que los divisores no pueden ir
conectados a otro conector por propia definición (una función unida a los posibles
eventos que produce como salida). La tabla siguiente (figura 3.89) muestra las distintas
posibilidades y su representación.
CONECTOR ENTRADA
SALIDA
EJEMPLO
E2
E1
conjuntor
conjuntor
E3
C
C = AND/OR/XOR
C
F1
- 257 -
C = AND/OR/XOR
3. Propuesta arquitectural y metodológica
E2
AND
conjuntor
disyuntor
E1
-
F2
C
C = AND/OR/XOR
F1
E1
E2
E3
C
conjuntor
-
C = AND/OR/XOR
conjuntor
C
C = AND/OR/XOR
F1
E1
E2
C
conjuntor
-
C = AND/OR/XOR
disyuntor
AND
F1
- 258 -
F2
3. Propuesta arquitectural y metodológica
E1
E2
C
disyuntor
conjuntor
C = AND/OR/XOR
AND
F1
F2
E1
AND
disyuntor
disyuntor
AND
F3
F1
F2
E1
E2
AND
disyuntor
-
conjuntor
F1
C
F2
- 259 -
C = AND/OR/XOR
3. Propuesta arquitectural y metodológica
E1
AND
disyuntor
-
disyuntor
F1
AND
F2
F3
Figura 3.89 Tabla de posibles conexiones entre conectores lógicos
De la tabla anterior podemos concluir lo siguiente:
? Las relaciones ‘disyuntor con entrada disyuntor’ y ‘disyuntor con salida
disyuntor’ no son posibles ya que deben ser reemplazadas por un único conector
disyuntor (AND) con varias funciones como salida (el total de las funciones de
salida de cada uno de los disyuntores).
? Las relaciones ‘conjuntor con entrada conjuntor’ y ‘conjuntor con salida
conjuntor’ son iguales.
? Las relaciones ‘conjuntor con entrada disyuntor’ y ‘disyuntor con salida
conjuntor’ son iguales.
? Las relaciones ‘conjuntor con salida disyuntor’ y ‘disyuntor con entrada
conjuntor’ son iguales.
De las conclusiones anteriores podemos deducir que todas las posibilidades teóricas
de conexión entre conectores lógicos pueden reducirse a las mostradas en la figura 3.90,
en la que la ‘C’ representa un conjuntor y la ‘D’ un disyuntor.
C
C = AND/OR/XOR
D
D = AND
C1
C = AND/OR/XOR
D
D = AND
C
C = AND/OR/XOR
C2
C = AND/OR/XOR
Figura 3.90 Posibilidades reales de conexión entre conectores lógicos
Como siguiente paso debemos establecer la forma de obtener reglas de producción
para cada una de las posibilidades reales determinadas de conexión entre conectores
- 260 -
3. Propuesta arquitectural y metodológica
lógicos. Teniendo en cuenta que la estructura de nuestras reglas de producción
compuestas son de alguno de estos dos tipos:
SI (condición compuesta) ENTONCES Función
SI (condición compuesta) ENTONCES Función1 Y Función2 Y…..Y Funciónn
y que la segunda de ellas es equivalente al conjunto de reglas:
SI (condición compuesta) ENTONCES Función1
SI (condición compuesta) ENTONCES Función2
……..
SI (condición compuesta) ENTONCES Funciónn
podemos deducir que el conector lógico que debe guiar la generación de reglas debe
ser aquel cuya salida sea una función, evitando los conectores que tengan como salida
otros conectores. Vamos a analizar los tres casos posibles de la anterior figura 3.89:
? Conjuntor que entra en un disyuntor. Dado que el conjuntor al tener una única
salida, y esta ser un conector (el disyuntor), no puede tener como salida una
función, luego elegimos el disyuntor como generador de reglas.
? Disyuntor que entra en un conjuntor. Dado que el disyuntor puede tener varias
salidas y que solo sabemos que una de ellas es un conector (conjuntor) y que el
conector puede tener como salida una función, elegimos ambos como
generadores de reglas.
? Conjuntor que entra en un conjuntor. Dado que el conjuntor solo tiene una salida
y que el primero de ellos no puede tener como salida una función (ya que entra
en el otro conjuntor) pero si puede tenerla el segundo, elegimos el segundo
conector como generador de reglas.
Una vez establecido este principio la generación de reglas compuestas será un
proceso recursivo ya que las posibles relaciones entre conectores lógicos analizadas
pueden conectarse entre sí. Como todo proceso recursivo el generador de reglas tendrá
una pila en la que incluirá los conectores elegidos para generar reglas hasta que el
proceso de generación que lance cada una esté completo, en cuyo caso el conector se
eliminará de la pila.
Durante el proceso de generación de reglas se tendrá en cuenta la secuencia de
ejecución establecida en los diagramas EPC: representación horizontal que implica
orden de ejecución de izquierda a derecha y representación vertical que implica orden
- 261 -
3. Propuesta arquitectural y metodológica
de ejecución indiferente. Esta estructura gráfica se ha formalizado mediante atributos de
la conexión lógica en XML por lo que será fácil aplicarla al generar las condiciones y
conclusiones de cada regla.
A continuación veremos para cada uno de los tres posibles casos de conexión entre
conectores lógicos la obtención de las reglas compuestas asociadas.
1. Conjuntor que entra en un disyuntor. Se genera tantas reglas como funciones de
salida tiene el disyuntor como muestra la figura 3.91. Las reglas deben ser
generadas en el orden correcto si las funciones son horizontales, es decir, de
izquierda a derecha.
E1
E2
C
C = AND/OR/XOR
AND
F1
F2
AND
OR
XOR
AND
SI E1 OR
XOR
SI E1
E2 ENTONCES F1
E2 ENTONCES F2
Figura 3.91 Regla generada por la conexión ‘conjuntor-disyuntor’
2. Disyuntor que entra en un conjuntor. Se generan dos reglas, una desde cada
conector como muestra la figura 3.92. Las reglas deben ser generadas en el orden
correcto si el disyuntor tiene orden de ejecución (representación de las salidas
horizontal), es decir, para el ejemplo del dibujo, primero la regla con conclusión
F1 y después la regla con conclusión F2.
- 262 -
3. Propuesta arquitectural y metodológica
E2
AND
E1
F2
C
C = AND/OR/XOR
F1
SI E1
AND
OR
XOR
E2 ENTONCES F1
SI E2 ENTONCES F2
Figura 3.92 Reglas generadas por la conexión ‘disyuntor-conjuntor’
3. Conjuntor que entra en un conjuntor. Se genera una regla desde el segundo
conector como muestra la figura 3.93.
E2
E3
E1
C
C
C = AND/OR/XOR
C = AND/OR/XOR
F1
SI E1
AND
OR
XOR
( E2
AND
OR
XOR
E3) ENTONCES F1
Figura 3.93 Regla generada por la conexión ‘conjuntor-conjuntor’
Para finalizar este punto vamos a transformar en reglas de conocimiento el ejemplo
de formalización XML, ya visto, de la figura 3.86. Como hemos visto solo tendremos
que tener en cuenta los conectores que no sean de tipo información.
- 263 -
3. Propuesta arquitectural y metodológica
1. Transformaremos los conectores de condición. Tenemos dos de tipo
poscondición. Buscamos para cada uno el nombre de los identificadores de
entrada y de salida. Las reglas quedarán:
SI Proceso de recepción del material ENTONCES Material recepcionado
SI Generar factura ENTONCES Factura generada
2. Transformaremos los conectores And, Or y Xor. El primero que encontramos es
el primer Xor. Controlamos el número de entradas y de salidas: dos entradas y
una salida, luego es un conector conjuntor. Controlamos el tipo de entradas y de
salidas. Su salida es un conector. Verificamos el tipo de conector de salida, que
resulta un conjuntor (dos entradas y una salida). Desarrollamos, entonces, este
segundo conjuntor. Controlamos el tipo de entradas y de salida. Las entradas son
conectores que no van ordenados y la salida es una única función. Como primer
paso tenemos la segunda parte de la regla (ENTOCES Generar factura). Como
segundo paso desarrollamos el primer conector, buscando sus entradas,
obteniendo una porción de la primera parte de la regla (O Pedido abierto en vigor
O Pedido normal pendiente). Como tercer paso desarrollamos el segundo
conector de la misma forma (O Servicio aceptado O Material recepcionado).
Como cuarto y último paso componemos la regla final:
(O Pedido abierto en vigor O Pedido normal pendiente) Y (O Servicio
aceptado O Material recepcionado) ENTONCES Generar factura
El resultado final de la transformación son tres reglas de producción encadenadas
entre sí, formando una pequeña red semántica.
Obtención de parámetros
Durante la obtención de los diagramas EPC se han asociado objetos de información a
ciertas funciones. Estos objetos de información deben contener los parámetros y la
información necesaria sobre ellos cuya definición constituye el resultado de la función.
Por ejemplo si la función es ‘Asignar nivel’ cuando la condición ‘Política por punto de
pedido’ se cumple, el objeto de información asociado será el parámetro ‘Nivel del punto
de pedido’ y los posibles valores que puede tomar. Además, como ya hemos visto en la
definición de la arquitectura, el asistente podrá tener asociada información a cualquier
elemento del dominio, como una explicación del significado del parámetro, su utilidad y
sus consecuencias, por ejemplo un gráfico que muestre su aplicación con datos reales.
- 264 -
3. Propuesta arquitectural y metodológica
Cualquier sistema ERP de calidad tiene como soporte alguna herramienta CASE
(Computer Aided Software Engineering), utilizada para el desarrollo y mantenimiento
del producto software. Una parte fundamental de estas herramientas constituye el
modelo de datos. Este modelo contiene todos los parámetros, su definición, formato y
posibles valores. Además los datos están agrupados en tablas, que es fácil identificar
con subdominios. Hay que establecer, por tanto, la conversión de esta información en
una estructura formal que represente los parámetros a utilizar en cada subdominio.
Dentro de las distintas posibilidades de las Herramientas CASE utilizaremos la
técnica Entidad/Relación extendida. Se trata de una técnica cuyo objetivo es la
representación y definición de todos los datos que se introducen, almacenan,
transforman y producen dentro de un sistema de información, sin tener en cuenta las
necesidades de la tecnología existente, ni otras restricciones. Esta técnica es
ampliamente utilizada y, por ejemplo, se propone en la metodología Métrica Versión 3
del Ministerio de las Administraciones Públicas español, en la que nos basamos en esta
fase del trabajo. Además ha sido ya utilizada por [Diez, 2006] para la obtención de
reglas para un agente inteligente en el entorno de la producción flexible. Dado que el
modelo de datos es un medio para comunicar el significado de los datos, las relaciones
entre ellos y las reglas de negocio de un sistema de información, su uso es básico para la
obtención de la información que debe manejar el módulo del dominio de nuestro
asistente.
Dentro de los diagramas entidad/relación de las herramientas CASE estándar se
definen tres elementos principales:
? Entidades. Es aquel objeto, real o abstracto, acerca del cual se desea almacenar
información en la base de datos. Durante el proceso de transformación del
modelo conceptual de datos al modelo físico, que se realiza en las de las
herramientas CASE, las entidades se transforma, excepto algunas excepciones,
en tablas que constituirán la base de datos. En los sistemas ERP existen tablas, y
por tanto entidades, que forma la estructura de datos de parametrización de cada
módulo.
? Relaciones. Es una asociación o correspondencia existente entre una o varias
entidades. Al establecer ciertas relaciones en las herramientas CASE, estas
definen como información de las tablas que relacionan los atributos clave.
? Atributos. Es una propiedad o característica de un tipo de entidad. Se trata de la
unidad básica de información que sirve para identificar o describir la entidad. Un
atributo se define sobre un dominio. Cada tipo de entidad ha de tener un
- 265 -
3. Propuesta arquitectural y metodológica
conjunto mínimo de atributos que identifiquen unívocamente cada ocurrencia
del tipo de entidad. Este atributo o atributos se denomina identificador principal.
Para obtener la información de parametrización asociada a una función que el
usuario del asistente debe ejecutar como consecuencia de su recorrido por la red
semántica del dominio, partimos de dos elementos:
1. Objeto de información asociado a la función en el diagrama EPC en el que
aparece la función. Partiremos de la transformación en formato XML del
diagrama EPC del que obtendremos los datos del objeto de información. Estos
datos se refieren a la tabla del sistema ERP a la que pertenecen los parámetros
que deben ser definidos en la función correspondiente, el nombre de estos
parámetro (puede ser uno o varios) y el nombre de la transacción del sistema
ERP en la que de forma on-line pueden parametrizarse.
2. Información obtenida de la herramienta CASE sobre las entidades y sus atributos
y datos detallados sobre estos. Cualquier herramienta CASE estándar contiene
utilidades de extracción de la información, desde simples informes en formato
texto, hasta documentos XML, pasando por tablas en Excel.
La información estándar extraída de la herramienta CASE consistirá en la lista de
todas las entidades existentes. En algunos casos es posible dividir la información que se
crea en la herramienta CASE en esquemas o proyectos, de esta forma dentro de un
esquema o proyecto se crearán las entidades asociadas a cada modulo del sistema ERP
representado. Si esto es así será posible obtener información más restringida, solamente
aquella relativa a las entidades del modelo de datos de un modulo del sistema ERP que
corresponde a un subdominio de nuestro asistente. Para cada una de las entidades
obtenidas se listarán todos sus atributos.
La información que se extrae de cada atributo tendrá los siguientes datos:
? Nombre del atributo. Identificador del atributo, corresponderá con el nombre del
parámetro del sistema ERP, por ejemplo ‘nivel de punto de pedido’.
? Descripción. Información textual sobre el atributo, en nuestro caso, descripción
básica del significado del parámetro. Este dato será utilizado por el asistente
como información asociada al parámetro. Además, como ya hemos visto, el
asistente podrá asociar más información, incluso de otro tipo (gráfica, auditiva,
etc.) a cada parámetro.
- 266 -
3. Propuesta arquitectural y metodológica
? Identificador principal. Es un valor booleano que indica si el atributo es el
identificador principal de la entidad, es decir, si representa unívocamente a una
ocurrencia de la entidad. El identificador principal es un atributo con valor
requerido obligatorio.
? Tipo de dato. Indica el tipo de valores aceptados para el parámetro. Los distintos
tipos de datos pueden ser:
Entero;
Real;
Entero positivo;
Real positivo;
Texto;
Fecha;
Hora;
Booleano;
Enumerado de un tipo determinado. Significa que existe una
lista de valores del tipo indicado entre cualquiera de los tipos
anteriores;
o Rango de un tipo determinado. Significa que existe un valor
inicial y un valor final del tipo indicado entre cualquiera de
los tipos anteriores.
o
o
o
o
o
o
o
o
o
? Valor requerido. Es un valor booleano que indicará si es obligatorio o no rellenar
este atributo. Nuestro asistente no utilizará este valor ya que la obligatoriedad o
no de rellenarlo vendrá definida por el camino de la red semántica recorrido por
cada usuario concreto. Si un usuario ha llegado a la función asociada a este
parámetro, debe obligatoriamente rellenarlo.
? Valor por defecto. En algunos casos, el sistema ERP propone un valor por
defecto que será el utilizado si el usuario no lo cambia. Nuestro asistente
utilizará este valor si no existe un valor en el módulo de usuario que sea
específico para la empresa que esté, en ese momento, realizando la
parametrización. Los valores específicos de usuario serán establecidos según la
taxonomía empresarial de cada organización.
? Valores. Detalla los valores válidos según el tipo de dato. En el caso que el tipo
de dato sea un enumerado apuntará a una lista con todos los valores de la
enumeración. En el caso que el tipo de datos sea un rango indicará los valores
iniciales y finales del rango. En el caso que el tipo de dato sea un texto indicará
el número de caracteres máximo del texto.
- 267 -
3. Propuesta arquitectural y metodológica
? Comentario. Información opcional sobre el atributo. Nuestro asistente puede
utilizar este dato como información asociada al parámetro.
Visto lo anterior, el proceso de obtención de la información asociada a una regla que
aparece relacionada con un objeto de información en el modelo EPC se hará como
sigue: se leerá la información del objeto de información, en la que aparecerá el nombre
de la tabla del sistema ERP y del parámetro o parámetros que deben ser introducidos
por el usuario al realizar la función asociada. A continuación se buscará en la
información extraída de la herramienta CASE la entidad correspondiente a la tabla
indicada y los parámetros. El módulo del dominio asociará a la función los atributos a
parametrizar, su tipo de dato, su valor por defecto y sus valores. También asociará el
atributo que sea identificador clave, ya que este definirá la tabla que se está
parametrizando. Por ejemplo si se está definiendo el parámetro ‘nivel de punto de
pedido’ para una determinada categoría de códigos, el atributo clave será ‘categoría’ y
tendrá un valor ya definido por el usuario durante el recorrido por la red semántica o un
valor que se debe definir en ese momento. Además mantendrá almacenado el nombre de
la transacción que se utilizaría en el sistema ERP para realizar la parametrización. La
estructura de datos detallada de todos los modelos se concretará en el capítulo cuarto
sobre la creación de un prototipo del asistente inteligente para SAP R/3.
Es importante asociar a cada parámetro que se rellene durante el recorrido del
usuario por la red semántica el nombre de la transacción que se debería utilizar durante
la parametrización directa en el sistema ERP. Esta información será imprescindible para
poder utilizar el asistente inteligente para parametrizar el sistema ERP una vez que el
usuario haya recorrido la red semántica del dominio completo o de algún subdominio.
Esta parametrización se podrá realizar automáticamente a partir del asistente utilizando
el nombre de la transacción, el nombre del identificador clave de la tabla donde está el
parámetro, el nombre del parámetro y el valor (ya validado) que ha decidido el usuario.
3.3.2. Módulo del usuario
En el modelo de usuario distinguimos tres tipos de conocimiento: el conjunto de
reglas valoradas y preferencias de cada usuario colectivo e individual, las métricas de
calidad con los criterios y valores de cada usuario colectivo y la situación de
parametrización de cada usuario individual en cada subdominio.
La parte más importante del módulo de usuario son las reglas valoradas y las
preferencias definidas por cada usuario individual o colectivo que se utilizarán para
guiar en la parametrización del sistema ERP de forma personalizada según cada usuario
y la taxonomía empresarial a la que pertenezca. La figura 3.94 muestra la estrategia
- 268 -
3. Propuesta arquitectural y metodológica
metodológica utilizada por el asistente para obtener esta parte, reglas valoradas y
preferencias, del módulo de usuario.
Taxonomía
empresarial
Módulo del
dominio
Estrategia
empresarial
Experto
empresarial
Planes
Procesos de
negocio
Decisiones de
negocio
Usuarios
Estrategia de
negocio
Sistema ERP
Preferencias
Reglas valoradas
y preferencias
Figura 3.94 Proceso de obtención de reglas valoradas y preferencias en el módulo de
usuario
Para la obtención del conocimiento relativo a reglas valoradas y preferencias se ha
dividido el proceso en tres partes. En cada una de ellas se obtiene información útil por si
misma.
Para obtener el resultado del primer paso (Planes) partimos de:
?
Taxonomía empresarial. Como hemos visto en el apartado 3.2.1 hemos
desarrollado una taxonomía empresarial que determina, para cada tipo definido,
un conjunto de procesos y funciones que establecen una estrategia empresarial.
- 269 -
3. Propuesta arquitectural y metodológica
?
Módulo del dominio. Contiene la red semántica que indica los posibles caminos
de parametrización de cada subdominio y la información sobre cada parámetro:
transacción, tipo de valores, etc. También posee información adicional que
puede ayudar al usuario en sus decisiones.
El conocimiento obtenido en este paso contiene la información relativa a los deseos y
preferencias en cuanto a la forma de realizar la parametrización de cada estrategia
empresarial asociada a cada tipo de empresa de la taxonomía creada. La información se
obtiene de la taxonomía empresarial en la que se encuentra cada usuario colectivo. La
taxonomía empresarial determinará procesos y funciones a realizar y algunas decisiones
estratégicas que deben ir reflejadas en la actuación del ERP, y, por tanto, en la
parametrización, que es su guía de actuación. Según la taxonomía habrá algunas
decisiones que el asistente pueda tomar, tanto en el camino que debe seguir la
parametrización, asociando valores a las premisas de algunas reglas de la red semántica,
como en el valor que se deben dar a los parámetros necesarios.
Para obtener el resultado del segundo paso (Decisiones de negocio), además de usar
el conocimiento sobre los Planes, partimos de:
?
Expertos en los procesos de negocio de la empresa que va a implantar el sistema
ERP. Estos expertos deberán serlo de las distintas partes del negocio, áreas,
correspondiente a cada subdomino del módulo del dominio. Serán personas que
conozcan la organización que va a usar el ERP, directivos o personal con
experiencia. Habrá que establecer entrevistas conjuntas e individuales que nos
ayuden a formalizar ese conocimiento. Dentro de esta categoría se considera
cualquier documento en lenguaje natural (texto), por ejemplo manuales sobre la
forma de trabajo de la empresa que va a implantar el sistema, sus planes
estratégicos, presupuestos, etc., es decir, cualquier información escrita que
complemente el conocimiento del experto.
?
Procesos de negocio. Es habitual en el entorno empresarial utilizar como
documentación representaciones gráficas de los procesos de negocio. Hay
distintos métodos de representación pero, como hemos visto en el apartado 3.2.2
de modelización de procesos, los distintos tipos de técnicas tienen los mismos
elementos principales y con el mismo significado: actividad, estado, evento y
tiempo, por lo que será fácil su comprensión. Dentro de esta categoría se
consideran también documentos en lenguaje natural (texto) que pueden proceder
de las descripciones de procesos de negocio y de cualquier definición escrita de
pautas de trabajo de la empresa que va a implantar el sistema.
El conocimiento obtenido en este paso contiene la información relativa a los deseos y
preferencias en cuanto a la forma de realizar la parametrización. Esta información esta
- 270 -
3. Propuesta arquitectural y metodológica
asociada a cada usuario individual que parametriza el sistema y consiste en aplicar
valores a algunas premisas de las reglas de la red semántica, de forma que se
establezcan caminos personalizados para recorrerla, y valores a algunos parámetros
asociados a estos caminos. Esta información se obtiene por defecto de los planes
propios del usuario colectivo al que pertenezca y posteriormente puede ser modificada
por cada usuario individual. De esta forma el asistente, además de guiar de forma
inteligente según cada estrategia empresarial de la taxonomía creada, guiará de forma
personalizada según las decisiones estratégicas de cada empresa.
Para obtener el resultado del tercer paso (Preferencias) partimos de:
?
Usuario. Pueden ser colectivos, empresas, o individuales, personal de la empresa
o consultores. Se refiere a cualquier utilizador del sistema que puede indicar sus
preferencias en cuanto a la forma de usarlo (idioma, tamaño de letra, prioridad
en el tipo de ayuda, etc.).
?
Sistema ERP. Contiene la información sobre los usuarios dados de alta en el
sistema, su clave y su descripción, en la que se incluye la empresa a la que
pertenecen e, incluso, el departamento si es necesario.
El conocimiento obtenido en este paso contiene la información relativa a la
identificación de los usuarios, tanto individuales como colectivos, la relación entre
ellos, es decir la pertenencia de los individuales a colectivos y sus preferencias en
cuanto a la presentación de la información.
Los usuarios colectivos se crearán directamente en el asistente a través del interfaz y
serán aquellas empresas que están implantando o usando el sistema ERP. Se añadirá
información en el asistente sobre sus preferencias, por ejemplo el idioma, el tamaño y
tipo de letra, etc. Los usuarios individuales podrán cargarse directamente en el asistente,
como los colectivos, o tomarse de cada sistema ERP que se está implantando,
creándose, además, la relación entre usuario individual (persona) y colectivo (empresa).
También podrá tomar la clave de cada usuario del sistema ERP, útil para la posterior
parametrización automática del sistema. Además tomarán, por defecto las preferencias
de uso del usuario colectivo al que pertenecen, por ejemplo el idioma que usará el
asistente en el interfaz. Posteriormente el usuario individual podrá modificar sus
preferencias directamente en el asistente y este podrá modificarlas automáticamente,
durante su uso, en función de acciones reiteradas del usuario, por ejemplo cambio del
idioma que aparece en la interfaz cuando está trabajando con el asistente.
Durante el uso del asistente se podrá añadir información sobre cada usuario relativa a
la utilización del sistema, como tiempo y frecuencia de uso, subdominios a los que
accede, etc.
- 271 -
3. Propuesta arquitectural y metodológica
Otra parte importante del módulo de usuario son las métricas de calidad definidas
que se utilizarán para mejorar la parametrización inicial del sistema después de haber
utilizado el ERP y haber medido sus resultados. La figura 3.95 muestra la estrategia
metodológica utilizada por el asistente para obtener esta parte, métricas de calidad, del
módulo de usuario.
Taxonomía
empresarial
Resultados
Sistema ERP
Experto
empresarial
Definición y
valoración de
criterios
Métricas de
calidad
Figura 3.95 Proceso de obtención de métricas de calidad en el módulo de usuario
Para obtener las métricas de calidad partimos de:
?
Experto empresarial. Expertos de alto nivel, en general, personas con
responsabilidad directiva que conocen la estrategia y planes empresariales y
pueden determinar la importancia de los factores de éxito del sistema ERP en su
negocio y los valores deseables y óptimos de cada criterio de calidad.
?
Taxonomía empresarial. Contiene para cada tipo definido dentro de la taxonomía
los procesos, funciones e, incluso, valores de los parámetros que establecen su
propia estrategia empresarial.
?
Resultados sistema ERP. Según la métrica de calidad elegida, el sistema ERP
deberá enviar al asistente informes con los valores reales obtenidos durante el
uso del sistema, para cada criterio.
La métrica de calidad debe definirse para cada usuario colectivo, es decir, cada
empresa implantadora y contiene los criterios de calidad y los valores, para cada uno de
ellos, aceptables y óptimos de cada subdominio, que serán definidos para cada usuario
colectivo, ya que dependen de la estrategia empresarial de cada empresa u organismo.
Se ayudarán de la definición estratégica de cada taxonomía. Además debe contener la
información relativa a las mediciones de calidad efectuadas durante la utilización del
- 272 -
3. Propuesta arquitectural y metodológica
sistema ERP ya implantado y parametrizado. Por tanto, dentro de cada proceso se
definirán criterios que se categorizarán según su importancia estratégica para el entorno
empresarial y estarán definidos por atributos, ya establecidos en el capítulo sobre las
bases metodológicas (prioridad, requerimientos mínimos, importancia relativa, índice,
valor mínimo, valor óptimo) y por el valor real obtenido en las mediciones de uso del
sistema. Este valor puede estar formado por un conjunto de valores que cubran períodos
temporales determinados.
El conocimiento sobre métricas de calidad contenido en este módulo es, por tanto,
útil durante la vida y utilización del sistema ERP, no durante su implantación. En la fase
de implantación está información podrá definirse aunque no utilizarse. Posteriormente,
cuando el asistente haya parametrizado el sistema y esté implantado y en uso se
completará para que el asistente analice los resultados según los datos reales, aceptables
y óptimos de cada subdominio. Esta información es importante porque, según el
resultado, el asistente propondrá la modificación de la parametrización realizada.
Para finalizar, dentro del módulo de usuario, se incluirá la situación de
parametrización de cada uno. Esta información es fundamental para parametrizar el
sistema ERP una vez que el usuario haya recorrido la red semántica del dominio
completo o de algún subdominio. La figura 3.96 muestra la estrategia metodológica
utilizada por el asistente para obtener esta parte, situación de parametrización, del
módulo de usuario.
Módulo de
dominio
Usuario
Módulo de
usuario
Parametrización
Situación de
parametrización
Figura 3.96 Proceso de obtención de la situación de parametrización en el módulo de
usuario
Para obtener la situación de parametrización partimos de:
- 273 -
3. Propuesta arquitectural y metodológica
?
Usuario. Toma las decisiones en cuanto a subdominio a parametrizar y valor a
establecer en cada parámetro que le propone el asistente, también puede decidir
usar los valores que le sugiere el asistente.
?
Módulo de usuario. Contiene la situación actual de parametrización de cada
subdominio, así como las preferencias y planes de usuario que definen valores
para parámetros concretos determinados por su estrategia empresarial y sus
prioridades.
?
Módulo del dominio. Contiene el camino de parametrización de cada
subdominio y la información sobre cada parámetro: transacción, valores, etc.
También posee información adicional que puede ayudar al usuario en sus
decisiones.
La situación de parametrización contendrá la información de la parametrización
realizada hasta el momento por cada usuario individual en su propio subdominio de la
implantación ERP que este realizando y, por lo tanto, la situación de parametrización
total de cada implantación ERP, entendida como el conjunto de parametrizaciones de
subdominios. Esta información se obtendrá mientras el usuario recorre todos los
caminos de la red semántica del subdominio y decide los valores de cada parámetro o
utiliza los que le presenta como propuesta el asistente.
La parametrización real sobre el propio sistema ERP, objeto final del trabajo del
asistente, se podrá realizar automáticamente a partir del módulo de usuario, ya que
contiene la lista de todos los parámetros a actualizar, el valor válido definido por el
usuario, el nombre de la transacción del ERP a ejecutar y cualquier otro dato necesario
para su ejecución. Estos últimos datos están asociados a cada parámetro en el módulo
del dominio. Para el proceso de carga automática sobre el sistema MRP de la situación
de parametrización utilizaremos las técnicas que cada sistema proporciona. Veremos un
ejemplo en el capítulo siguiente que desarrolla un prototipo para SAP R/3.
3.3.3. Módulo de calidad
Este modelo contiene el conocimiento necesario para relacionar los criterios de
calidad genéricos que será posible que utilice cada organismo o empresa con las reglas
de la red semántica que están implicadas en cada criterio. La figura 3.97 muestra la
estrategia metodológica utilizada por el asistente para obtener el módulo de calidad.
- 274 -
3. Propuesta arquitectural y metodológica
Módulo de
dominio
Módulo de
usuario
Experto
empresarial
Manuales ERP
Taxonomía
empresarial
Experto ERP
Interrelación
calidad
empresarial/ERP
Módulo de
calidad
Figura 3.97 Proceso de obtención del módulo de calidad
Para obtener esta información partimos de varias fuentes de conocimiento y de los
modelos ya obtenidos de dominio y de usuario:
?
Módulo del dominio. Contiene la información normalizada de la completa red
semántica del dominio. Está dividido en subdominios y cada uno de ellos
asociado a una parte de la red semántica. La red semántica se compone de reglas
de conocimiento encadenadas entre sí. Por otro lado la información sobre los
parámetros del sistema ERP está relacionada, en el módulo del dominio, con la
función en la que se debe definir cada uno. Además cada función forma parte de
una regla de producción. De esta forma es fácil determinar que función, regla de
producción y subdominio definen cada parámetro.
?
Módulo de usuario. Contiene la información normalizada de los criterios de
calidad definidos por cada empresa, según su estrategia y decisiones de negocio.
Además contiene información histórica de las actuaciones del usuario en el
asistente, los resultados de parámetrización y las métricas de calidad obtenidas
como consecuencia de su actuación.
?
Manuales del sistema ERP. Contienen información útil sobre el proceso de
parametrización y el significado y uso de cada parámetro.
?
Expertos del sistema ERP y del negocio. Personal experto en el uso del sistema
ERP, la utilización de cada parámetro y sus consecuencias. Además personal
- 275 -
3. Propuesta arquitectural y metodológica
experto de la empresa que conozca las decisiones de negocio, sus prioridades y
sus puntos fuertes y débiles.
?
Taxonomía empresarial. Contiene información sobre la estrategia empresarial de
cada empresa clasificada, es decir, funciones y procesos principales que
corresponden con los subdominios que influirán más en los resultados
empresariales.
A partir de toda esta información el módulo de calidad debe asociar cada indicador
de calidad con un subdominio cuya parametrización es responsable de los resultados de
calidad, sabiendo que cada subdominio corresponde con una parte de la red semántica
de conocimientos del asistente. Para ello se utilizará la información de los expertos, los
manuales y la estrategia empresarial que relacionará cada criterio definido en el módulo
de usuario con el parámetro o parámetros del sistema ERP que influyen en su
cumplimiento. Una vez determinado esto, a través del módulo del dominio, podemos
asociar cada criterio con una función, una regla de conocimiento y la parte de la red
semántica o subdominio a la que pertenece. De esta forma el asistente puede aconsejar
al usuario la parte del dominio cuya parametrización debe revisar en función de los
resultados de calidad obtenidos en el sistema ERP implantado y en funcionamiento.
Además de indicar la parte de la red semántica a revisar debe aconsejar sobre los
posibles cambios a realizar en la parametrización según el criterio de calidad
considerado, analizando el historial de calidad de la propia empresa o de otras similares
incluidas en la misma taxonomía, los valores y las condiciones ya utilizadas y sus
resultados, información incluida en el módulo de usuario.
- 276 -
4 IMPLEMENTACIÓN DE UN PROTOTIPO PARA
SAP/R3
En este capítulo desarrollaremos un prototipo basado en nuestra propuesta de
asistente inteligente aplicado al sistema ERP SAP R/3. En primer lugar introduciremos
este sistema y, en concreto, explicaremos el ámbito general en el que se encuadrará el
prototipo: el proceso de la cadena de suministro o supply chain en SAP R/3. Dentro de
este proceso detallaremos el subproceso de parametrización de la planificación de
necesidades de material que será el conocimiento del dominio del asistente. A
continuación estableceremos las características particulares de este subproceso para un
tipo de empresa concreta dentro de la taxonomía creada en este trabajo. Hemos
seleccionado una empresa típica de producción y venta de tecnología en el ámbito de las
telecomunicaciones.
Una vez seleccionado el entorno de aplicación del prototipo realizaremos su análisis
completo siguiendo la arquitectura propuesta, comenzando por el modelo de datos a
nivel conceptual, entidades y relaciones, y a nivel físico, desarrollando una estructura de
datos que representará las reglas y los objetos de información del subdominio, así como
su aplicación a la taxonomía elegida. Tras el modelo de datos, analizaremos el modelo
de procesos, creando los procedimientos y funciones del asistente, así como el interfaz
con el usuario y con el sistema SAP R/3.
Finalmente aplicaremos la metodología propuesta para la creación de contenidos en
el desarrollo de las reglas y objetos de información necesarios para implementar el
subproceso elegido, basándonos en la documentación de SAP R/3.
- 277 -
4. Implementación de un prototipo para SAP R/3
4.1. SAP/R3
El sistema SAP R/3 es un paquete avanzado de elaboración de datos que proporciona
una serie completa de soluciones aplicativas de gestión que cubren todas las áreas
empresariales. SAP R/3 es la solución principal de la compañía SAP y, de hecho, de ella
derivan el resto de soluciones que tiene en el mercado. SAP, es una de las primeras
empresas mundiales en implantaciones ERP. Según [Brandt, 2005], a finales de 2004
SAP cubría una cuota de mercado global del 58%, mientras que su más directo
competidor PeopleSoft (ya unido a Oracle) alcanzaba el 22%. La versión SAP R/3 se
lanzó al mercado en el año 1992 y fue un cambio decisivo en el mercado ERP por su
arquitectura cliente/servidor, la integración total de sus funciones, la posibilidad de
manejo de la información por parte del usuario y las posibilidades de parametrización
que le permiten una gran escalabilidad para su adaptación tanto a pequeñas como a
grandes empresas.
SAP R/3 se compone de una base de datos única para todas las funciones, más de
cuarenta módulos independientes y a la vez integrados y un entorno de desarrollo de
aplicaciones y datos que posibilita modificar y crear tanto programas como datos,
personalizando totalmente la aplicación. También dispone de un soporte total al cliente
con servicio continuo y actualizaciones y mejoras periódicas.
La arquitectura de SAP R/3 es del tipo cliente servidor a tres niveles como muestra la
figura 4.1.
Nivel cliente
Nivel aplicación
Nivel de datos
Figura 4.1 Arquitectura a tres niveles de SAP R/3
- 278 -
4. Implementación de un prototipo para SAP R/3
?
Nivel cliente. Está instalado en cada ordenador de usuario y consiste en una
aplicación (sapgui.exe) que gestiona la interfaz de usuario, presenta el menú,
controla teclas de función, teclado y ratón y realiza el intercambio de
información con el nivel de aplicación.
?
Nivel aplicación. Puede estar instalado en uno o más servidores conectados entre
sí. Consiste en la ejecución de la lógica del sistema, realizando la entrada y
salida con el usuario y ejecutando el código ABAP (Advanced Business
Application Programming) que es el lenguaje propietario de cuarta generación
en el que está programado SAP. Para la ejecución de las aplicaciones envía
peticiones al nivel de datos y recibe de él información.
?
Nivel datos. Esta instalado en el servidor de datos y contiene la base de datos
integrada del sistema. Gestiona todos los accesos y actualizaciones de datos,
comunicándose con el nivel de aplicación.
La plataforma en la que se puede instalar SAP R/3 es muy variada e incluye las más
importantes del mercado. En la parte cliente y aplicativa el sistema operativo puede ser
WinNT, Win2000, Unix, Solaris, AS/400 y MVS. En la parte de datos el sistema de
gestión de base de datos puede ser Informix, DB2, Microsoft y SQL Server.
En cuanto a la lógica de funcionamiento, SAP R/3 es un sistema ERP guiado por
eventos, es decir, las funciones se relacionan unas con otras en base a la cadena de
actividad de cada proceso, es decir todas las funciones, independientemente de su
módulo, están relacionadas, olvidando las rígidas separaciones de las funciones según
su área de trabajo. La figura 4.2 muestra la estructura modular de SAP R/3.
Figura 4.2 Estructura modular de SAP R/3
- 279 -
4. Implementación de un prototipo para SAP R/3
A pesar de esta división modular, como ya hemos dicho, la ejecución de funciones y
el acceso a los datos es transversal, pero al mismo tiempo, es posible hacer
implantaciones parciales que incluya solo algunos módulos. Vamos a listar los módulos
principales divididos por áreas:
?
Sistema Contable. Gestiona los aspectos económicos. Se divide en:
o
o
o
o
?
Logística. Gestiona los aspectos relacionados con la actividad empresarial. Se
divide en:
o
o
o
o
o
?
FI (Financial Accounting). Contabilidad financiera.
CO (Controlling). Contabilidad de gestión.
TR (Treasury). Tesoreria.
AM (Asset Management). Gestión de productos y componentes.
PP (Production Planning). Planificación de la producción.
MM (Material Management). Gestión de materiales.
SD (Sales and Distribution). Ventas y distribución.
PM (Plant Maintenence). Mantenimiento de sedes.
QM (Quality Management). Gestión de la calidad.
Recursos Humanos. Solo contiene un módulo:
o HR (Human Resources). Gestión de los recursos humanos.
?
Otros módulos. Agrupa los siguientes módulos:
o PS (Project System). Gestión de proyectos.
o WF (Workflow). Gestión de flujos de trabajo.
o IS (Industry Solution). Gestión específica de algunos procesos.
Las funciones a realizar en el sistema están guiadas por el proceso al que pertenecen
y son transversales a los módulos. Por ejemplo una orden de venta se introduce en el
módulo SD (ventas), produce la utilización del PP (producción) que se integra con el
MM (materiales) y el CO (contabilidad). La realización de las funciones se basa en los
documentos, es decir el producto de ellas. Un documento se compone de cabecera, que
incluye información general, como fecha y sociedad, y cuerpo, que incluye datos
particulares del tipo de documento. Las transacciones en SAP R/3 no finalizan hasta que
los datos necesarios han sido introducidos y evaluados con éxito. Los documentos y los
datos que son necesarios y opcionales en cada uno pueden ser determinados por cada
empresa utilizadora, en lo que se llama parametrización del sistema. La configuración
del sistema, que incluye la definición de la arquitectura y la parametrización, se realiza
- 280 -
4. Implementación de un prototipo para SAP R/3
en dos momentos secuenciales. El primero incluye los aspectos fundamentales del
sistema completo o funciones centrales, como el calendario, las sedes, la moneda, etc.,
que identifican el entorno de funcionamiento. En un segundo momento se interviene
sobre los parámetros de cada módulo, definiendo la estrategia de funcionamiento
particular. Par la configuración completa SAP R/3 utiliza más de 8000 tablas. La
definición de la estructura y política empresarial y su traducción a la configuración del
sistema, es un momento fundamental y de él depende el éxito de su uso, ya que
permitirá la unión de las distintas funciones y la activación de los elementos necesarios
en cada proceso, integrando los flujos lógicos e informativos. La figura 4.3 muestra una
pantalla de SAP R/3 que permite iniciar la parametrización de algunos aspectos del
sistema.
Figura 4.3 Ejemplo de pantalla de parametrización en SAP R/3
4.1.1. El proceso de la cadena de suministro (supply chain) en SAP/R3
La cadena de suministro o Supply Chain se define como una red de organizaciones
que están colegadas a través de relaciones en diferentes procesos y actividades que
producen valor en forma de productos y servicios destinados al consumidor final,
incluye proveedores, almacenes, sedes de distribución, políticas de planificación, etc. La
figura 4.4 muestra la parte del proceso de negocio de la cadena de suministro gestionada
por un sistema SAP R/3.
- 281 -
4. Implementación de un prototipo para SAP R/3
contabilidad
distribución
fabricación e e contabilidad
distribución
fabricación
inventario
inventario
ventas
ventas
BD de
productos
y
servicios
Base de
datos
clientes
Obtener
datos
cliente
Obtener
detalles
del cliente
Comprobar
crédito
cliente
Sistema
contable
Identificar
servicio
solicitado
Obtener
requisitos
Gestión de
distribución
Petición
almacén
Introducir
detalles
factura
Entregar
pedido
Fabricación
Sistema
gestión
de
pedidos
ERP
SAP(SAP,
R/3ERP
People
Soft, Baan,
Oracle, …)
(SAP, PeopleSoft,
Oracle, Baan,...)
Figura 4.4 Ámbito de gestión de la cadena de suministro de SAP R/3
Cada entidad en la cadena representa un nodo que tiene una demanda propia y una
cierta capacidad. La dificultad estriba en gestionar estos parámetros de forma síncrona
entre todos los nodos, maximizando la eficiencia del global de la demanda y la
capacidad productiva y siendo lo bastante flexible como para reconfigurarse según las
fluctuaciones del mercado. Los nodos se dividen en dos categorías:
?
Agentes de producción. Comprenden, los puntos de venta con los que se
relaciona el consumidor final, los centros de distribución que almacenan y
distribuyen el material a mayoristas o minoristas y las plantas o sedes que
realizan la producción y/o ensamblaje de los componentes para obtener un
producto final e incluyen los proveedores y subcontratistas.
?
Agentes de servicio. Comprenden los nodos de transporte, que se ocupan de la
transferencia física de los bienes y los nodos de servicio que ofrecen los
servicios de base para todas las actividades, por ejemplo el control contable.
Desde un punto de vista organizativo las funciones que desarrolla cada nodo se
pueden dividir en tres grupos:
?
Funciones internas. Comprenden la gestión de la producción, la ejecución de las
órdenes y la coordinación de los flujos de información y trabajo.
?
Funciones externas iniciales. Comprenden la compra y gestión de materiales, la
gestión de las relaciones y el intercambio de información con los
suministradores.
- 282 -
4. Implementación de un prototipo para SAP R/3
?
Funciones externas finales. Comprenden la creación y gestión de órdenes de
venta, la gestión del almacén de productos terminados y la expedición y la
gestión de las relaciones y el intercambio de información con los clientes.
El objetivo principal de coordinación entre todos los nodos y funciones consiste en el
equilibrio entre tres componentes: los recursos, el inventario y la demanda. Por un lado
la definición de recursos, como centros productivos y de otros servicios, maquinaría,
herramientas y recursos humanos y su control y actualización en función de los otros
dos parámetros. Por otro lado la definición del inventario a dos niveles, el superior que
ve el medio y largo plazo y los productos considerados de alto nivel de control y el
inferior que se refiere a la necesidad de aprovisionamiento de los materiales
individuales de cualquier nivel. El inventario utiliza los recursos para crearse y
mantenerse mientras que satisface las necesidades de la demanda. Finalmente, la
demanda que se divide en previsiones, es decir el resultado de los estudios de mercado
que nos ayudan a la posible entrega del producto en un tiempo menor al de su total ciclo
productivo y la demanda cliente o real, que es el resultado del conjunto de órdenes de
venta en firme. La búsqueda del equilibrio entre estos tres elementos define la política
de actuación de la cadena de suministro basada en el tipo de demanda, que puede ser:
?
?
?
Make-to-stock. Gestionar teniendo en cuenta demanda solo de previsiones, de
forma que las órdenes de venta se satisfarán de forma inmediata;
Make-to-order. Gestionar teniendo en cuenta solo la demanda procedente de las
órdenes de venta;
Assembly-to-order. Gestionar solo con previsiones hasta un cierto punto,
variable, en el que continua solo con órdenes de venta.
El objetivo de la política elegida será tener el producto justo, en la cantidad justa, en
el momento justo y con el coste mínimo.
Finalmente vamos a ver como la gestión de la cadena de suministro se desarrolla a
tres niveles:
?
Plano estratégico. Trata de definir y utilizar la estructura de red organizativa para
conseguir los objetivos del negocio a menor coste. Es el responsable de la
definición de los procesos de negocio y la estrategia empresarial. Utiliza el ERP
para la parametrización del entorno y la obtención y análisis de información de
alto nivel.
?
Plano táctico. Gestiona las actividades de previsión de la demanda, distribución
del transporte y planificación del aprovisionamiento y la producción a
corto/medio plazo. Incluye las decisiones y parámetrizaciones fundamentales del
- 283 -
4. Implementación de un prototipo para SAP R/3
ERP, la definición logística y el uso del sistema en cuanto a creación de
recursos, entrada de datos principales y obtención y análisis de información
sobre las relaciones con clientes y suministradores.
?
Plano operativo. Comprende las actividades de programación de las operaciones
en general, movimientos de almacén, envío y recepción de pedidos de compra,
lanzamiento y cierre de órdenes de producción, gestión del transporte y
transmisión de información recogida en planta y en tiempo real.
Es en este ámbito en el que nos vamos a mover en el diseño del prototipo, aunque
todavía bastante amplio, y por tanto, la parametrización se realizará solo para una parte
de este proceso. Digamos que el dominio completo del prototipo será la cadena del
suministro, aunque el desarrollo se hará para uno de sus subdominios, la política de
planificación de necesidades de material.
4.1.2. El proceso de parametrización de la planificación de necesidades de
material en SAP R/3
El proceso de parametrización de necesidades de material en SAP R/3 se realizará
para definir de qué forma quiere trabajar el planificador de materiales en su función.
Para ello debe conocer las características de funcionamiento del sistema R/3 y los
parámetros que utiliza. En este apartado vamos a describir brevemente este entorno.
La función principal de la planificación de necesidades de material es abastecer el
almacén con la cantidad adecuada y en el tiempo justo con aquellos productos que son
necesarios para cubrir las necesidades de los clientes. En SAP R/3 estas funciones están
representadas básicamente en el ámbito de la Logística, que incluye los módulos PP de
planificación de la producción, MM de gestión de materiales, SD de Ventas y
distribución, PM de mantenimiento de sedes y QM de gestión de la calidad. Además de
estos módulos, se relaciona con el resto en cuanto a envío y recepción de información
relativa a su función. En el Anexo III se presenta un breve diccionario de términos
referentes a la planificación de necesidades de material.
Para conseguir sus objetivos, la planificación de necesidades de material debe
realizar funciones a dos niveles:
?
Nivel MPS (Master Production Scheduling). Este es el nivel superior, de
productos finales o que forman parte del montaje final, y mira al medio y largo
plazo. Para ello debe considerar las órdenes cliente y las demandas
previsionales.
- 284 -
4. Implementación de un prototipo para SAP R/3
?
Nivel MRP (Material Requirement Planning). Este es el nivel inferior y su
utilidad es crear y hacer el seguimiento de un plan detallado de prioridades, a
corto y medio plazo, que abarca a todos los artículos de producción y de
compras.
El MPS distingue entre dos tipos de demanda: la real o proveniente de órdenes
cliente y la previsional o proveniente de previsiones e hipótesis sobre la futura demanda
comercial. Por tanto la demanda previsional no existe pero es necesaria para empezar a
comprar y/o fabricar los artículos más básicos que serán necesarios en futuras órdenes
cliente. Con ello se consigue disminuir el tiempo de respuesta al cliente asumiendo el
riesgo de obtener materiales fabricados o comprados en demasía. El proceso de
planificación debe realizar el llamado consumo entre las demandas previsionales
existentes en el sistema y las órdenes cliente, para evitar una duplicidad en la demanda.
El proceso de consumo consiste en la eliminación de las previsiones que han alcanzado
cierto límite o que tienen como respaldo una demanda real de órdenes cliente.
El MPS permite, además, realizar la planificación sobre los diferentes artículos de
forma agregada, definiendo las previsiones sobre las que no se tiene una configuración
de producto real, sobre artículos ficticios que representan familias de productos. A estos
artículos ficticios o sistemas se les puede asociar una estructura de producto que indique
sus componentes. Esta estructura de producto para las previsiones se denomina planning
bill. Los elementos que la componen, a uno o varios niveles pueden ser:
?
?
?
Básicos, deben ir siempre presentes en el producto final;
Opcionales, pueden ir o no de forma independiente o dependiendo de otros
según reglas definidas;
Alternativos, dentro de una selección de ítems solo es posible elegir uno o varios
entre un conjunto definido.
Para completar esta estructura cada elemento lleva incluido un porcentaje (menos en
el caso de elementos básicos), que indica la frecuencia probable de petición de ese
elemento. Cuando el MPS planifica la demanda previsional utiliza estos porcentajes
para prever, con mayor grado de similitud a la realidad, las cantidades necesarias en
futuras órdenes clientes.
Por otro lado el MRP cubre, fundamentalmente, las áreas de planificación de
materiales y análisis del estado de las órdenes. Para ello utiliza los datos de la parte alta
del sistema (MPS) para conocer la demanda existente, ya sea en forma de demanda
previsional o de órdenes cliente. Compara esta demanda con la existencia en el almacén
y las órdenes ya pendientes, para determinar si la demanda está o no cubierta, y, en caso
negativo, generar las órdenes necesarias. El plan de materiales así obtenido es la base
para la obtención de los planes diarios de producción y de compras.
- 285 -
4. Implementación de un prototipo para SAP R/3
El plan de materiales es controlado por los datos de artículos y estructuras, de forma
que es capaz de generar demanda dependiente según la estructura de cada artículo (que
artículos lo forman y en que cantidad, si son de fabricación) y la fecha de efectividad de
esa estructura (si el artículo está siendo modificado por Ingeniería), entre otros
parámetros.
Veamos ahora los parámetros principales logísticos que influyen en el plan de
materiales, tanto a nivel MRP como MPS. Alguno de ellos son generales, pero la
mayoría se deben definir para cada artículo, en estos casos pueden darse valores
particulares o los mismos valores para grupos o categorías de artículos:
?
Primero se debe definir el método de planificación que indica si el artículo se
planificará a nivel MPS, a nivel MRP o será planificado manualmente.
?
Para establecer el método de trabajo con la demanda previsional se define la
barrera de la demanda, que indica las semanas en las que el sistema solo
trabajará con demanda real proveniente de órdenes cliente. Esto implica el
entorno de planificación a utilizar:
o Make to order. Si la barrera de la demanda es igual al lead time del producto
final (tiempo necesario total hasta su entrega en el almacén). Significa que
durante la fabricación no se trabajará con demanda previsional, solo con
órdenes cliente. Las previsiones pueden utilizarse como control de
capacidades a largo plazo.
o Assembly to order. Si la barrera de la demanda es mayor que cero y menor
que el lead time del producto. Implica que ciertos niveles de producto serán
comprados o fabricados con demanda previsional, pero solo se continuará la
fabricación del producto final si hay órdenes cliente.
o Make to stock. Si la barrera de la demanda es cero y, por tanto, hasta la
entrega del producto final en el almacén se trabaja con demanda no real o
previsional, es decir, se trabaja para el almacén no para el cliente.
?
Se determinará el modo de consumo a realizar entre la demanda previsional y la
real. El modo determina si se lleva a cabo el consumo hacia adelante, hacia atrás
o se permiten ambos tipos. El consumo hacia delante o hacia atrás se refiere a la
búsqueda que hace el sistema entre la demanda previsional, seleccionando
aquella que encuentra la primera justo, antes o después, de la fecha de la
demanda real que consume. La figura 4.5 muestra gráficamente los modos de
consumo.
- 286 -
4. Implementación de un prototipo para SAP R/3
Demanda
previsional
Consumo hacia atrás
Demanda
real
Periodo de consumo
Demanda
previsional
Periodo de consumo
Consumo hacia adelante
Demanda
real
Periodo de consumo
Demanda
previsional
Periodo de consumo
Consumo hacia atrás/adelante
Demanda
real
Periodos de consumo
Periodos de consumo
Figura 4.5 Modos de consumo de la demanda previsional
?
Se debe indicar el tipo de artículo, es decir, el tipo de gestión que realizará el
sistema con él: compras, producción o transferencia de otras sedes.
?
Control por proyecto. Indica si un artículo estará siempre controlado por
proyecto, no lo estará nuca o lo estará o no dependiendo de la estructura donde
se use. El control por proyecto de un artículo significa que sus órdenes,
existencias y necesidades aparecen separadas y tiene un propietario.
?
La planificación puede funcionar de forma net-change, que implica tomar en
consideración solo los artículos que han sufrido algún cambio relativo a sus
parámetros de planificación, su existencia en almacén, su demanda, etc., o en
forma regenerativa, que planifica todos los artículos existentes, anulando la
planificación anterior. En ambos casos es interactivo con el planificador,
devolviéndole, después de la planificación, mensajes que le sirven de guía en las
acciones que debe tomar.
?
El proceso de planificación ve la existencia en el almacén dividida en tres partes.
Esto significa que al definir los estados del material en el almacén hay que
- 287 -
4. Implementación de un prototipo para SAP R/3
definir como serán vistos por el proceso. La clasificación utilizada es la
siguiente:
o Disponible para la planificación. El sistema considera el material de este tipo
solamente disponible para la planificación no para el uso, por ejemplo
material pendiente de inspección.
o Disponible total. El material de esta clase es considerado disponible en todos
los sentidos para el sistema, por ejemplo material en almacén listo para su
uso.
o No disponible. El material de este tipo es ignorado, prácticamente, por el
sistema.
?
Cada artículo será planificado de acuerdo con su política asociada. Estas
políticas definen la lógica de cálculo de la cantidad y la fecha de la orden. Las
políticas posibles son las siguientes:
o Discreta. El sistema genera una orden por cada necesidad neta existente.
o Cantidad fija. El sistema siempre genera una orden con una cantidad fija.
o Periodo fijo. Genera una única orden para el conjunto de necesidades
existentes en un periodo fijo de tiempo que empieza a contar a partir de la
fecha de la primera necesidad existente.
o Phantom. El sistema no genera órdenes para este artículo, lo salta de la
estructura del producto generando órdenes directamente sobre sus hijos.
o Días fijos. El sistema genera una única orden para todas las necesidades
existentes en el número de días definidos, contando a partir de una fecha
definida.
o Semanas fijas. Como el anterior, considerando el número indicado como
número de semanas.
o Meses fijos. Como el anterior, considerando el número indicado como
número de meses.
?
Otros datos asociados a la política de orden son:
o Cantidad de la orden. Define la cantidad fija utilizada en el caso de la
política cantidad fija.
o Periodo de orden. Es el periodo fijo de tiempo utilizado en las políticas días
fijos, semanas fijas, meses fijos y periodo fijo.
o Factor de descarte. Es el factor multiplicativo que se debe aplicar a la
cantidad de la orden para prevenir los posibles descartes de material durante
la producción.
o Cantidad mínima. Se puede utilizar en algunas políticas de orden para no
generar nunca una orden con cantidad menor de la aquí indicada.
- 288 -
4. Implementación de un prototipo para SAP R/3
o Cantidad máxima. Se puede utilizar en algunas políticas de orden para no
generar nunca una orden con cantidad mayor de la aquí indicada.
?
Límites temporales. Se establecen tres barreras temporales que facilitan el
control de las órdenes a través del tiempo, están expresadas en días de trabajo:
o Lead Time. El tiempo necesario para la producción o la compra de un
artículo, desde que se abre la orden correspondiente hasta que llega el
material al almacén o a recepción.
o Límite de confirmación. Puede indicar el lead time acumulativo. Cuando la
orden entra en este límite, pasa a un estado en el que el proceso de
planificación no la puede modificar automáticamente.
o Límite de lanzamiento. Representa el periodo de tiempo necesario para la
preparación del lanzamiento de la orden.
?
Estado de la orden. Indica una secuencia estándar de estados por los que pasará
una orden. Puede ser:
o Planificada. Hasta que alcanzan el límite de confirmación.
o Confirmada. Cuando entra en el límite de confirmación. El sistema no la
puede modificar en automático, pero emite mensajes de excepción.
o Lista para el lanzamiento. Cuando entra en el límite de lanzamiento. Al
llegar a este punto el sistema cambia el estado de los componentes que
forman parte de las necesidades dependientes de la orden a empeñado, de
forma que no puedan ser considerados disponibles por otras necesidades.
o Abierta. La orden esta lanzada. Si no se indica lo contrario (apertura
automática) el sistema no cambia a este estado automáticamente sino que
avisa de que se llega el momento y debe ser cambiado manualmente. La
orden permanece en este estado hasta que se carga en el almacén. El sistema
sigue dando mensajes sobre esta orden.
o Parcialmente recibida. Se ha cargado una cantidad parcial. El sistema sigue
dando mensajes sobre esta orden.
o Recibida. Se ha cargado la cantidad total.
o Cerrada. Se cierra la orden, no se realiza ninguna otra acción sobre ella.
Después de un tiempo indicado por el usuario será borrada por el sistema.
La relación entre los límites temporales y el estado de la orden se puede ver en la
figura siguiente (figura 4.6):
- 289 -
4. Implementación de un prototipo para SAP R/3
parcialmente cargada
planificada
confirmada
lanzamiento
abierta
cargada
cerrada
LEAD TIME
LIMITE DE LANZAMIENTO
LIMITE DE CONFIRMACION
Figura 4.6 Relación entre límites temporales y estado de la orden
Al finalizar el proceso de planificación se obtiene un plan de materiales que debe ser
gestionado por los planificadores. Cada artículo tiene asignado un planificador que será
responsable de la gestión de su plan. Esta gestión incluye la visualización detallada del
plan de materiales en la que es posible ver por artículo la lista de las órdenes existentes,
provenientes de demanda cliente o previsional, su fecha de entrega, la cantidad
pendiente y el balance por fecha entre las previsiones y la demanda cliente. Además
puede analizar por separado las necesidades, las órdenes y las existencias.
SAP R/3 proporciona facilidades para revisar y modificar lo planificado
automáticamente: visualizaciones on-line, informes y transacciones que permiten
modificar los datos. Estas últimas van siempre separadas de las simples visualizaciones
y necesitan una autorización especial (planificador responsable). SAP R/3 genera
mensajes de error y de atención al cumplirse ciertas condiciones, por ejemplo si no
cuadran la demanda y las previsiones. Estos mensajes se pueden visualizar de varias
formas y son de varios tipos:
?
Mensajes de excepción sobre órdenes. Son mensajes referentes a: anticipar o
retardar la fecha de entrega; fecha de entrega pasada y orden no cerrada o no
cargado el material en el almacén completamente; incrementar o decrementar la
cantidad de la orden; inserción de órdenes o cambio de cantidad antes del limite
de confirmación; gestión del multi-establecimiento.
?
Mensajes de excepción sobre necesidades. Son mensajes referentes a: fecha de
retirada de material pasada y material no completamente retirado; cantidad
necesaria no disponible en la fecha de necesidad; cantidad no disponible en
stock y orden del padre lista para el lanzamiento.
?
Menajes de acción y de atención. Son mensajes referentes a: órdenes
completamente cargadas al almacén y no cerradas; órdenes que han llegado a la
- 290 -
4. Implementación de un prototipo para SAP R/3
fecha de inicio y no están abiertas; necesidades independientes con material ya
retirado pero no cerradas; necesidades independientes con fecha de retirada de
material pasada y sin el material completamente retirado.
Es posible hacer desaparecer los mensajes de error cambiando los parámetros que
generan los mensajes o actuando sobre los datos de las órdenes, de las necesidades o de
los artículos. Cada artículo contiene dos parámetros que guían al sistema a la hora de
generar los mensajes de excepción:
?
Factor de anticipación. Indica cuantos días antes de la fecha de necesidad se
puede planificar la fecha de la orden sin que se emita un mensaje de anticipar la
fecha.
?
Factor de retraso. Indica cuantos días después de la fecha de necesidad se puede
planificar la fecha de la orden sin que se emita un mensaje de retrasar la fecha.
4.1.3. La planificación de necesidades de material en empresas de
telecomunicaciones
Para la construcción del prototipo, dentro del conocimiento sobre planes estratégicos
de empresas según su taxonomía, hemos elegido una empresa típica de producción y
venta de tecnología en el ámbito de las telecomunicaciones. Según la taxonomía
desarrollada en esta tesis se encuadra en el área de Industrias Productivas, el sector de
Alta Tecnología y el negocio de Fabricantes de equipos.
Este tipo de empresas de alta tecnología se caracterizan por una rápida innovación,
gestión del riesgo e investigación, aunque también gestionan los procesos típicos
productivos, desde el diseño y la planificación hasta el aprovisionamiento, fabricación,
venta y distribución y prestación de servicios, conocidos como cadena de suministro
(coordinar la planificación, previsión y producción), que es, precisamente, el entorno
del prototipo. En concreto, nos centramos en los fabricantes de equipos de
telecomunicación, como equipos de conmutación y telefonía. Se caracterizan por el
diseño de productos complejos y altamente configurables, la necesidad de previsión de
la demanda y el uso de fabricación con montaje bajo pedido.
Dentro de sus procesos principales, ya vistos en el capítulo 3, los relativos a la
planificación de necesidades están incluidos en tres: Planificación de demanda y
suministro, Logística y Planificación de repuestos. En los tres están implicados tanto
clientes como proveedores y, en conjunto, abarcan las áreas de Gestión de orden,
Gestión del suministro, Producción, Distribución y Servicios. Vamos a ver, en detalle,
- 291 -
4. Implementación de un prototipo para SAP R/3
las decisiones estratégicas más importantes relativas al conocimiento del prototipo, es
decir, la planificación de necesidades, para esta taxonomía empresarial.
En primer lugar hay que establecer la definición del tipo de política de planificación
y su visibilidad, que depende de la importancia y criticidad de los artículos respecto a la
respuesta al cliente. Por ello es necesario establecer como artículos MPS aquellos que
estén en los dos últimos niveles de producto (productos finales o que entren en el
montaje final), los que aparezcan en las estructuras de planificación de previsiones
(planning bill) y, en general, aquellos con un tiempo de compra o fabricación muy largo
o un coste muy elevado, que forman el conjunto de códigos de clase A. La visibilidad
del MPS debe ser lo suficientemente amplia para permitir eventuales modificaciones en
la capacidad productiva, lo que significa un par de meses más que el tiempo de
producción más largo. Respecto a la frecuencia se debe establecer la del MPS como
semanal, ya que implica un estudio y control detallado del plan obtenido y la capacidad
de llevarlo a cabo, y la del MRP diaria, porque constituye el plan de trabajo a todos los
niveles.
Lo siguiente a definir es la política de fabricación. La elegida para este tipo de
empresas es la Assembly to order o con montaje bajo pedido. En este tipo de
fabricación se compra y se produce hasta un cierto nivel de la estructura del producto
final, utilizando un valor de la barrera de la demanda mayor que cero y menor que el
lead time del producto. Se debe utilizar como valor el correspondiente al tiempo
necesario hasta el montaje final, es decir el lead time del producto final menos el lead
time sumado de los dos últimos niveles de producto. Implica que los niveles inferiores a
estos serán comprados o fabricados con demanda previsional sin esperar a recibir una
orden cliente, pero solo se realizará la fabricación y compra de los dos últimos niveles si
hay órdenes cliente. Esta estrategia concuerda con la definición de niveles MPS/MRP y
de artículos a incluir en la planning bill. Además es en el montaje final y en los últimos
niveles de producto donde, generalmente, se configuran las características propias de
cada orden cliente, por ejemplo la frecuencia, que no podrían realizarse sin conocer
dicha orden. La ventaja de esta política de fabricación es la disminución del tiempo de
respuesta al cliente, ya que desde que llega su orden hasta que se realiza la entrega de su
pedido solo transcurre el tiempo final de la producción (últimos dos niveles) porque se
dispone en inventario de los artículos de niveles inferiores. El problema es que una mala
gestión de las previsiones supone que falten artículos inferiores y no se pueda dar una
respuesta tan rápida o que sobren materiales que se hayan pedido y que luego no sean
necesarios en órdenes cliente.
Para gestionar las previsiones se debe establecer una política de consumo de las
mismas. En este caso se decide una política de consumo hacia delante y hacia atrás, que
implicará usar previsiones adelantadas, asegurándonos la existencia en almacén y, si no
hubiera, usar previsiones de material que van a llegar con retraso respecto a la necesidad
- 292 -
4. Implementación de un prototipo para SAP R/3
de nuestra orden cliente, pero que, en cualquier caso, va a mejorar el tiempo de entrega
respecto al lead time total del producto y va a evitar exceso en el almacén si las
previsiones no se consumen y se suman a las órdenes cliente. Se utilizará como periodo
hacia delante y hacia atrás un tiempo que estará en relación con la frecuencia de emisión
de órdenes cliente, para este tipo de empresas debería rondar el mes. En ciertos casos
especiales, por ejemplo cuando hay acuerdos marco con grandes operadores, se podrán
gestionar las previsiones y las órdenes dentro de una gestión por proyecto, es decir,
crear las previsiones necesarias para el contrato marco con un tipo de proyecto y
permitir el consumo de las mismas solo para las órdenes cliente de ese proyecto. De esta
forma ningún otro cliente podrá usar esas previsiones para cubrir su demanda.
Para el control de los mensajes de excepción se propone crear planificadores
diferentes para los artículos de compra y producción, por su diferente necesidad de
conocimiento e implicaciones. Distinguir, también entre artículos MPS y MRP y entre
artículos de clase A, B y C. De esta forma habría un total de ocho planificadores: cuatro
para artículos MPS, distinguiendo entre compras y producción y para cada categoría,
entre clase A y el resto; y otros cuatro para artículos MRP, distinguiendo entre compras
y producción y para cada categoría, entre clase B y clase C, ya que por definición no
hay artículos de clase A que sean MRP. La tabla de la figura 4.7 muestra esta división
de artículos.
TIPO DE
TIPO DE
PLANIFICACIÓN FABRICACIÓN
Compras
MPS
Fabricación
Compras
MRP
Fabricación
CLASES DE
ARTÍCULO
Clase A
Clases B y C
Clase A
Clases B y C
Clase B
Clase C
Clase B
Clase C
Figura 4.7 División de artículos para el establecimiento de planificadores
Respecto al valor de los parámetros que guían el sistema a la hora de generar los
mensajes de excepción (Factor de anticipación y de retraso) será: Como anticipación se
indicará un valor de cero días para los artículos de clase A y MPS; cinco días para el
resto de artículos MPS; diez días para los artículos de clase B y MRP; y quince días
para los de clase C y MRP. Como retraso se dará un valor de quince días para todos los
artículos. Este valor es, en general, mayor ya que es más prioritario la posible falta de
- 293 -
4. Implementación de un prototipo para SAP R/3
cobertura de una necesidad (y la consecuente petición de adelantar la orden) que la
fabricación adelantada de la orden.
Falta por establecer estrategias para la forma en que se generaran las órdenes de
producción y compra. Vamos a establecer los siguientes parámetros referidos a la
cantidad y la fecha de la orden:
?
Política de orden. Se utilizará una política discreta (una orden para cada
necesidad de material) en los artículos MPS de clase A, una política de
agrupamiento semanal en el resto de artículos MPS de fabricación y un
agrupamiento quincenal para el resto de artículos MPS de compras. Para los
artículos MRP se emitirán pedidos de compra agrupados mensualmente para
clase B y con frecuencia bimensual para clase C. La frecuencia de la fabricación
es un poco menor y será con agrupación quincenal para clase B y mensual para
clase C. Esto es consecuencia de la mayor necesidad de control de los artículos
más importantes y de que el coste de emisión de pedidos, superior al de emisión
de órdenes de fabricación, hace necesario agrupar las necesidades para optimizar
el número y frecuencia de pedidos y órdenes emitidos.
?
Lead time. Los artículos de compras utilizarán el tiempo de entrega dado por el
proveedor preferente para cada artículo y los de fabricación utilizarán el tiempo
propio necesario para la fabricación de cada uno, suponiendo disponibles sus
componentes.
?
Límite de lanzamiento. Este límite es diferente para los artículos de compras y
fabricación. Se fija en diez días para los de fabricación, lo que supone tener sus
componentes empeñados (no disponibles para otras órdenes) diez días antes del
comienzo de su ejecución. Esto asegura que la orden podrá ser llevada a cabo sin
problemas de materiales faltantes. Se fija en tres días para los artículos de
compra, que indica el periodo de tiempo de gestión y administrativo necesario
para realizar la emisión del pedido.
?
Límite de confirmación. Este tiempo define la congelación de órdenes y pedidos
planificados. Indica que cualquier cambio debe realizarlo a mano el planificador.
Por tanto, para los artículos MPS, más importantes y mejor controlados, se
establece en diez días y cinco para los MRP.
?
Cantidad mínima de orden. Para los artículos de compras se utilizará la cantidad
mínima dada por el proveedor preferente. Si se decide utilizar otro proveedor y
su cantidad mínima es mayor que la del preferente, el planificador deberá
cambiar la cantidad manualmente. Para los artículos de fabricación se utilizará el
- 294 -
4. Implementación de un prototipo para SAP R/3
lote mínimo de fabricación de cada uno, que se calcula en función de las
máquinas a utilizar y del lote económico calculado.
Para finalizar vamos a mostrar el resultado de todos estos parámetros aplicados a un
artículo de compras de clase B, definido como MPS y con un tiempo de entrega dado
por su proveedor preferente de 19 días. La figura 4.8 muestra en un eje temporal como
transcurren los eventos relacionados con las necesidades existentes de ese artículo,
entendiendo LT como lead time, RR como límite de lanzamiento y FP como límite de
confirmación.
Figura 4.8 Ejemplo de aplicación de parámetros de planificación estratégicos
- 295 -
4. Implementación de un prototipo para SAP R/3
4.2. ARQUITECTURA DEL PROTOTIPO
Una vez establecido el entorno de trabajo del prototipo vamos a analizar y diseñar su
estructura coherentemente con la arquitectura establecida en el capítulo anterior.
Primero desarrollaremos el modelo de datos a dos niveles: nivel conceptual, definiendo
entidades y relaciones, y físico, deduciendo una estructura de datos que represente las
reglas y los parámetros del subdominio. Tras el modelo de datos, analizaremos el
modelo de procesos, creando los procedimientos necesarios para cubrir las funciones del
asistente y las necesidades de interfaz con el usuario y con el sistema SAP R/3.
4.2.1. Modelo de datos
La finalidad del modelo de datos es representar el contexto del asistente, primero de
forma conceptual, entendiendo el mundo que lo rodea, y, después, formalizar este
mundo diseñando una estructura implementable de tablas y campos que lo represente y
que sea accesible por procesos computacionales.
Modelo conceptual
El siguiente diagrama (figura 4.9) representa las entidades y relaciones principales
del contexto del Asistente Inteligente propuesto:
ESTADO PARAMETRIZACIÓN
(0,N)
(0,N)
(1,1)
USUARIO
INDIVIDUAL
(1,1)
SUBDOMINIO
ERP
(1,1)
(0,N)
CRITERIOS
CALIDAD
(0,N)
(0,N)
(1,N)
(0,N)
PLANES
ESTRATÉGICOS
(0,N)
(1,N)
(0,1)
(1,N)
USUARIO
COLECTIVO
(1,N)
(1,N)
(1,N)
(1,N)
MÉTRICAS
CALIDAD
(0,N)
(0,1)
Figura 4.9 Modelo Entidad/Relación del contexto del Asistente Inteligente
- 296 -
4. Implementación de un prototipo para SAP R/3
A continuación vamos a explicar cada una de las entidades y relaciones
representadas:
?
Entidad Usuario Individual. Representa a cualquier persona que acceda al
asistente. Para poder realizar la parametrización automática sobre un Sistema
ERP, el usuario que parametriza debe estar dado de alta, también, en dicho
sistema, por lo que será posible crear los usuarios individuales desde el sistema
ERP. Esta entidad contendrá la información necesaria sobre cada persona que
acceda al asistente: nombre, clave de acceso, preferencias de uso del sistema,
etc.
?
Entidad Usuario Colectivo. Representa a una empresa u organismo que va a
implantar, o ya utiliza, un sistema ERP y va crear o modificar su
parametrización través del asistente. Esta entidad contendrá la información
necesaria sobre cada empresa u organismo que utilice el asistente: nombre, tipo
según la taxonomía empresarial definida, fecha de implantación, fecha de
comienzo del proyecto, etc.
?
Entidad Planes Estratégicos. Representa el conjunto de decisiones estratégicas
de cada tipo de empresa definida en la taxonomía empresarial Las decisiones
estratégicas se traducen a la forma de parametrizar el sistema ERP, definiendo
que hay que parametrizar (caminos de la red semántica) y como (valores de los
parámetros).
?
Entidad Subdominio ERP. Representa el proceso de parametrización de cada
uno de los procesos de negocio (subdominios) del Sistema ERP, es decir, indica
que es posible parametrizar y que implica cada decisión de parametrización en la
funcionalidad del sistema. Esta representación estará formalizada en forma de
red semántica y parámetros y veremos su estructura conceptual más adelante, en
un diagrama secundario.
?
Entidad Estado Parametrización. Representa la situación de parametrización
(terminada o en curso) que puede haber realizado o estar realizando un usuario
individual de cada uno de los subdominio del Sistema ERP. Se representa
mediante los valores dados a las reglas y los parámetros.
?
Entidad Métricas Calidad. Representa las decisiones estratégicas sobre como la
parametrización del sistema ERP afecta a los resultados cuantificables del
negocio y la satisfacción de los clientes y proveedores en sus relaciones con la
empresa.
- 297 -
4. Implementación de un prototipo para SAP R/3
?
Entidad Criterios Calidad. Representa el conjunto de criterios que forman una
métrica de calidad, es decir, el detalle de los factores a medir en el sistema ERP
durante su uso, los valores obtenidos y los valores deseables y óptimos que se
esperan.
?
Relación Usuario Individual - Usuario Colectivo. Representa la relación de
pertenencia que existe entre los usuarios individuales y colectivos. Cada usuario
individual, es decir, persona que trabaja en el sistema, debe pertenecer al menos
a una empresa u organismo existente en el sistema, aunque pude pertenecer a
varios en caso de representar a un consultor que trabaje a la vez en la
implantación de sistemas ERP en varias empresas. Cada usuario colectivo o
empresa u organismo que implanta un sistema ERP puede tener varios usuarios
individuales asociados, al menos tendrá uno, que realizará la parametrización,
pero puede tener varios, por ejemplo uno para cada subdominio según su
experiencia y conocimiento.
?
Relación Usuario Colectivo – Planes Estratégicos. Representa la relación de
asociación entre una empresa y un plan estratégico. Cada empresa puede tener
asociado, aunque no necesariamente, un plan estratégico, es decir, una forma de
parametrizar el Sistema ERP, según el tipo al que pertenezca (sector, negocio)
dentro de la taxonomía empresarial creada. Por otro lado, un plan estratégico
puede estar asociado a ninguna o varias empresas, a tantas como trabajen con el
asistente y pertenezcan a la taxonomía empresarial que representa.
?
Relación Usuario Individual – Planes Estratégicos. Representa la relación de
personalización de cada plan estratégico. Cada usuario individual, como
responsable de un proceso de negocio (subdominio) puede personalizar el plan
estratégico general de la taxonomía a la que pertenezca la empresa a la que
represente en ese momento, por tanto cada usuario individual podrá personalizar
varios planes estratégicos (por ejemplo de varias empresas si actúa como
consultor) o ninguno si no realiza esta tarea.
?
Relación Usuario Individual – Subdominio ERP. Representa la relación de
parametrización de cada utilizador del asistente respecto a los subdominios (o
procesos de negocio) del Sistema ERP a parametrizar. Cada usuario individual
puede parametrizar varios subdominios, aunque en algún momento puede no
estar parametrizando ninguno, y, a la vez, cada subdominio puede ser
parametrizado por varios usuarios en el caso de que haya varias empresas
parametrizando el sistema. No es obligatorio que se parametrice a través del
asistente, de ahí la cardinalidad mínima cero (subdominios no relacionados con
ningún usuario), ya que puede hacerse directamente en el Sistema ERP. Esta
relación puede ser redundante respecto a las representadas como Usuario
- 298 -
4. Implementación de un prototipo para SAP R/3
Individual – Estado Parametrización y Subdominio ERP – Estado
Parametrización, ya que es deducible de ellas, pero creemos conveniente
representarla para mejor comprensión del modelo.
?
Relación Usuario Individual – Estado Parametrización. Representa la relación
entre cada usuario individual y el resultado de las parametrizaciones terminadas
o en curso de cada subdominio ERP. Cada usuario puede tener terminado o en
marcha ninguno o varios procesos de parametrización, uno por cada subdominio
o, incluso, para los usuarios consultores varios por cada subdominio. Además,
cada situación o estado de parametrización está realizada por un usuario y
solamente uno, ya que para cada subdominio parametrizado tiene un responsable
para evitar incongruencias o pérdidas de datos.
?
Relación Subdominio ERP – Estado Parametrización. Representa la relación
entre los diferentes subdominios del Sistema ERP y los procesos de
parametrización realizados sobre ellos o en marcha. Un subdominio (o proceso
de negocio) puede tener varios estados de parametrización de distintas empresas,
pero cada estado de parametrización se refiere siempre a un único subdominio
ERP.
?
Relación Usuario Colectivo- Métricas Calidad. Representa la relación entre cada
usuario colectivo (empresa u organismo implantador) y la estrategia de control
de calidad establecida. Cada empresa puede o no tener establecida una métrica
de calidad, pero solo puede tener una establecida, en cambio, cada métrica puede
definirse para varias empresas, según su sector de aplicación y su nivel de
detalle.
?
Relación Métricas Calidad – Criterios Calidad. Representa la relación entre las
métricas de calidad y los criterios que las componen. Una métrica estará
formada al menos por un criterio de calidad o por varios. Cada criterio puede ser
utilizado en varias métricas, ya que muchos de ellos son comunes a varios
sectores o estrategias y pueden ser bastante generales. Evidentemente, cada
criterio debe formar parte de al menos una métrica de calidad.
?
Relación Usuario Colectivo – Criterios Calidad. Representa la relación entre
cada usuario colectivo (empresa) con los criterios de calidad que midan el uso de
su Sistema ERP. Cada empresa podrá utilizar varios criterios, aunque puede no
tener ninguno si no ha definido una métrica de calidad. Cada criterio puede ser
utilizado por varias empresas, al menos por una ya que ha sido definido. Esta
relación puede ser redundante respecto a las representadas como Usuario
Colectivo – Métrica Calidad y Métricas Calidad – Criterios Calidad, ya que es
- 299 -
4. Implementación de un prototipo para SAP R/3
deducible de ellas, pero creemos conveniente representarla para mejor
comprensión del modelo.
?
Relación Criterios Calidad – Subdominio ERP. Representa la relación entre cada
criterio de calidad y el subdominio del sistema ERP que está relacionado con su
cumplimiento. Para que el asistente pueda proponer la parametrización a
modificar según la falta de cumplimiento de cada criterio (deducida de datos
reales de funcionamiento del sistema ERP), es necesaria esta relación, que
indica, para cada criterio, el subdominio o proceso de negocio, solo uno, cuya
parametrización influye en su cumplimiento. Por otro lado, cada subdominio
puede influir en el cumplimiento de varios criterios de calidad.
Una vez determinado el contexto del Asistente Inteligente, vamos especificar la parte
secundaria del modelo conceptual de datos mediante un diagrama Entidad/Relación que
represente las entidades y relaciones que formalicen la red semántica, los parámetros, la
información adicional y los planes estratégicos que forma el conocimiento del dominio.
Este diagrama se muestra en la figura 4.10.
DOCUMENTO
(0,N)
PARAMETRO
CONDICIÓN
(0,N)
(1,N)
(0,N)
(0,N)
(0,N)
(1,1)
(1,1)
ACCIÓN
(1,N)
(1,N)
(1,1)
(1,1)
TRANSACCIÓN
ERP
(0,N)
(0,N)
SUBDOMINIO
ERP
Figura 4.10 Modelo Entidad/Relación del dominio del Asistente Inteligente
Vamos a detallar cada una de las entidades y relaciones del diagrama explicando su
utilidad y cardinalidad, necesarias para la construcción posterior del modelo físico:
?
Entidad Subdominio ERP. Representa el proceso de parametrización de cada
uno de los procesos de negocio (subdominios) del sistema ERP, es decir, indica
que es posible parametrizar y que implica cada decisión de parametrización en la
funcionalidad del sistema. Esta representación consiste en una red semántica
compuesta de acciones y condiciones.
- 300 -
4. Implementación de un prototipo para SAP R/3
?
Entidad Acción. Representa acciones simples o agregadas relacionadas con el
proceso de parametrización, que pueden hacer referencia a una función o a un
proceso, en general a un nodo de la red semántica. Cuando se refieren a un
proceso, la acción estará formada por otras acciones relacionadas entre sí (acción
inicial de una red semántica) y cuando se refiere a funciones, la acción puede, a
su vez, estar relacionada con otras que son necesarias para su cumplimiento
(acción intermedia de una red semántica) o no estarlo, siendo esta una acción
que no necesita continuación (acción final de una de las ramas de una red
semántica).
?
Entidad Condición. Representa la conclusión o el resultado de la ejecución de la
actividad asociada a una acción. La condición se representará como un
interrogante respecto a la ejecución de la actividad que solo podrá ser resuelto de
forma positiva o negativa. La respuesta a esta condición guiará el recorrido de la
red semántica, ya que entrará con su valor como premisa en las reglas
semánticas donde aparezca la acción asociada.
?
Entidad Parámetro. Representa un campo del sistema ERP al que hay que darle
un valor. Según el valor dado el sistema ERP tendrá un funcionamiento
diferente, por ejemplo el parámetro relativo al nivel de inventario en la política
de creación de órdenes, determinará en que momento se crea una orden de
producción o un pedido de compras de cierto material de forma automática.
Muchos parámetros tienen un valor por defecto que el usuario puede o no
cambiar. El conjunto de valores dados a los parámetros relativos a un proceso de
negocio definen la estrategia de cada empresa para ese proceso. Los elementos
de esta entidad pueden conseguirse directamente del sistema ERP a través de la
herramienta CASE que describe su modelo de datos.
?
Entidad Transacción ERP. Representa cada una de las transacciones on-line del
Sistema ERP que se utilizan para introducir los valores de los parámetros. El
proceso de parametrización de un Sistema ERP se realizan introduciendo datos
directamente, de forma manual, en estas transacciones. La función final de
nuestro Asistente Inteligente será simular estas transacciones automáticamente.
Los elementos de esta entidad pueden conseguirse directamente del Sistema
ERP a través de la herramienta CASE que describe su diseño.
?
Entidad Documento. Representa un material de ayuda que ilustra o explica una
acción (función o proceso) a ejecutar durante el proceso de parametrización o
explica el significado, la utilidad o consecuencias de los valores posibles de un
parámetro. Este material de ayuda físicamente puede ser de varios tipos: texto,
video, gráfico, audio, imagen, etc.
- 301 -
4. Implementación de un prototipo para SAP R/3
?
Relación Subdominio ERP – Acción. Representa la relación entre cada
subdominio ERP (proceso de negocio) y las acciones (funciones y procesos) que
hay que realizar para parametrizar dicho proceso de negocio. Por un lado la
cardinalidad es (1,N), es decir, cada subdominio ERP tendrá asociadas, para su
parametrización, una o más acciones. Por otro lado la cardinalidad es (1,1), es
decir, una acción será necesaria para parametrizar un determinada subdominio
ERP y solo uno. Además no existirá si no sirve para parametrizar algún
subdominio ERP.
?
Relación Acción – Acción. Representa la relación reflexiva entre acciones, es
decir, el hecho de que una acción este relacionada con otras en alguna red
semántica. Por un lado la cardinalidad es (0,N), lo que significa que una acción
puede no tener ninguna premisa (ejecución de alguna acción) para su
realización, en el caso de ser la acción final de un subdominio ERP, o puede
tener varias premisas (acciones) necesarias para su ejecución cuando se recorre
una red semántica. Por otro lado la cardinalidad es (0,N), es decir, una acción
puede no ser premisa de ninguna otra acción, en el caso de ser la acción inicial
de un proceso, o ser premisa de varias acciones, ya que su actividad puede
formar parte de varias actividades más complejas, es decir de varios recorridos
de la red semántica.
?
Relación Acción – Condición. Representa la relación entre una acción y la
condición o evento derivada de su ejecución. Por un lado la cardinalidad es (1,1)
ya que una condición puede definir el cumplimiento de una única acción ya que
la entidad condición existe solo para la acción a la que hace referencia y solo
hace referencia a ella. Por otro lado la cardinalidad es (1,N), es decir, la
ejecución de una acción puede ser evaluada a través de un número de
condiciones que va desde 1 (ninguna acción puede ser conclusión de una reglas
semánticas sin una condición) hasta un número indeterminado. El hecho de que
la misma acción pueda ser evaluada con distintas condiciones tiene sentido
porque la misma acción puede participar en distintas reglas y en cada una la
condición necesaria por parte de la acción podrá ser distinta. Por ejemplo para la
acción ‘Valor del lead time del código’ puede haber condiciones distintas como:
‘¿Valor superior al tiempo de respuesta al cliente?’, ‘¿Valor menor de dos
semanas?’, etc.
?
Relación Acción – Parámetro. Representa la relación entre las acciones a realizar
durante la parametrización y el conjunto de parámetros que deben valorarse
durante la actividad asociada a esa acción. Por un lado la cardinalidad es (0,N)
ya que una acción puede tener asociado un conjunto de parámetros a introducir o
ninguno. Es posible que haya acciones, por ejemplo las agrupadas, que no
supongan la introducción de ningún parámetro, pero las que si tienen que
- 302 -
4. Implementación de un prototipo para SAP R/3
hacerlo es habitual que introduzcan varios. Por otro lado la cardinalidad es (1,1),
es decir, un parámetro a valorar tiene que realizarse obligatoriamente durante la
actividad de una acción y solamente durante esa acción.
?
Relación Parámetro – Transacción ERP. Representa la relación entre los
parámetros y las transacciones del Sistema ERP que se usan para darles valor.
Esta relación viene dada por el propio sistema ERP y pueden ser obtenidas de
forma automática de la herramienta CASE que describe su diseño de datos y
procesos. Por un lado la cardinalidad es (1,N) ya que una misma transacción
ERP puede servir para introducir varios parámetros y siempre tendrá que servir
para introducir al menos uno, por ello la damos de alta en nuestro asistente. Por
otro lado la cardinalidad es (1,1), es decir, todo parámetro se introducirá
mediante alguna transacción y solo en una.
?
Relación Acción – Documento. Representa la relación entre las acciones de
parametrización y la información con ayuda adicional para su realización. Por un
lado la cardinalidad es (0,N) ya que una acción puede ser explicada o ilustrada
por un número de documentos que va desde 0 (si no se ha generado material de
ayuda sobre esa acción) hasta un número indeterminado. Cuando una acción se
relaciona con varios documentos la presentación de uno u otro o varios al
usuario, durante el proceso del asistente, dependerá del tipo de documento
(visual, auditivo, texto) y de las preferencias definidas para ese usuario concreto.
Por otro lado la cardinalidad es (0,N), es decir, un documento puede explicar o
ilustrar un número de acciones que va desde 0 (el documento está creado pero
aún no se ha asociado a ninguna acción) hasta un número indeterminado.
Conceptualmente un documento puede contener información que sirva para más
de una acción.
?
Relación Parámetro – Documento. Representa la relación entre los parámetros
que guían el funcionamiento del sistema ERP y la información de ayuda
adicional para su realización. Por un lado la cardinalidad es (0,N) ya que un
parámetro puede ser explicado o ilustrado por un número de documentos que va
desde 0 (si no se ha generado material de ayuda sobre ese parámetro) hasta un
número indeterminado. Cuando un parámetro se relaciona con varios
documentos la presentación de uno u otro o varios al usuario durante el proceso
del asistente dependerá del tipo de documento (visual, auditivo, texto) y de las
preferencias del usuario. Por otro lado la cardinalidad es (0,N), es decir, un
documento puede explicar o ilustrar un número de parámetros que va desde 0 (el
documento está creado pero aún no se ha asociado a ningún parámetro) hasta un
número indeterminado. Conceptualmente un documento puede contener
información que sirva para más de un parámetro.
- 303 -
4. Implementación de un prototipo para SAP R/3
Modelo físico
Partiendo del modelo de datos conceptual (figuras 4.9 y 4.10) obtenemos una serie de
tablas físicas y sus relaciones entre ellas mediante la clave u otros campos de la tabla,
considerando lo siguiente:
?
Las entidades principales definidas son: Usuario (Individuales y Colectivos),
Parámetro y Acción. Los Documentos y Transacciones ERP son características o
atributos de los Parámetros. Las Condiciones y los Documentos son
características o atributos de las Acciones. Los Subdominios ERP son tipos
especiales de Acciones. Los Estados de Parametrización y los Planes
Estratégicos son particularizaciones del Subdominio ERP y tendrán su misma
estructura. Finalmente, las Métricas de Calidad y los Criterios de Calidad son
actuaciones posteriores al proceso de parametrización que no van a ser
desarrolladas en este prototipo.
?
Cada una de las entidades principales debe definirse en una tabla independiente
con todas sus características.
?
La entidad Subdominio ERP se reflejará en el modelo físico como un atributo de
las Acciones que indicará si una Acción es la inicial de un proceso de negocio y
por tanto de un Subdominio ERP.
?
Las entidades Usuario Individual, Parámetro y Transacción ERP están ya
definidas en el sistema ERP y serán enviadas mediante interfaz en el momento
de la carga de datos del Asistente Inteligente. También están definidas en el
sistema ERP las relaciones entre los Parámetros y las Transacciones ERP.
?
La relación múltiple de pertenencia entre los Usuarios Individuales y Colectivos
se representará mediante una tabla (Individual_Colectivo) que tiene una doble
clave Usuario_Individual/Usuario_Colectivo, de tal forma que podemos ver que
usuarios individuales están empleados en los Usuarios Colectivos (empresas u
organizaciones) y a la inversa. No vamos a desarrollar en este prototipo las
tablas correspondientes a las entidades Usuario Individual, Usuario Colectivo y
la relación entre ellos, ya que solo utilizaremos un único usuario individual, un
único usuario colectivo y una única relación entre ellos. Por otro lado su
estructura, significado y contenido ha sido ampliamente comentado en este
capítulo y en el anterior.
?
Para normalizar el diseño físico de la tabla de Acciones se creará una tabla de
Condiciones en la que se hará referencia en un campo a la acción con la que se
- 304 -
4. Implementación de un prototipo para SAP R/3
relaciona, es decir, aquella cuyo cumplimiento viene definido por la condición.
De esta forma se representa la relación entre Acciones y Condiciones. La
normalización implica no tener que repetir en la tabla Acción tantas ocurrencias
de una acción como condiciones asociadas tenga.
?
Para normalizar el diseño físico de la tabla de Acción se creará una tabla de
Documentos y una tabla que relacione las Acciones y Documentos. La
normalización implica no tener que repetir en la tabla Acción tantas ocurrencias
de una acción como documentos asociados tenga. En la primera tabla
(Documentos) se definirán los datos propios de los documentos, por ejemplo su
dirección física, que sean independientes de la acción con el que se relaciona. En
la segunda tabla (Acciones_Documentos), que tiene una doble clave
Acción/Documento, representa la relación múltiple entre Acciones y
Documentos, de tal forma que podemos ver que documentos se asocian a que
acciones y a la inversa.
?
De la misma forma que en el punto anterior para normalizar el diseño físico de la
tabla Parámetros crearemos una tabla que represente la relación entre Parámetros
y Documentos (Parámetros_Documentos) que tiene una doble clave
Parámetro/Documento, de tal forma que podemos ver que documentos se
asocian a que parámetros y a la inversa.
?
Para normalizar el diseño físico de la tabla de Parámetros se creará una tabla de
Transacciones ERP. En la tabla de Parámetros se incluirá un campo que hará
referencia a la Transacción ERP que sirve para introducir el valor del Parámetro.
?
Para representar la relación entre Acciones y Parámetros se creará un campo en
la tabla Parámetros que indicará la Acción durante la cual se debe introducir un
valor a ese Parámetro.
?
La relación reflexiva múltiple entre Acciones que forma las reglas semánticas
que guiarán la parametrización está representada en una tabla propia de Reglas.
En esta tabla se relaciona la acción conclusión con las acciones premisas que
forman parte de la regla, el conector y la secuencia de ejecución de las acciones
que componen la regla.
?
Es necesario establecer la relación entre los Usuarios y los Subdominios ERP
que parametrizan. Esta relación es necesaria para la parte del asistente que se
encarga de mantener la situación de parametrización y de la posterior carga
automática en el Sistema ERP, ya que conservará el recorrido de
parametrización por el que ha pasado cada usuario dentro de cualquier
- 305 -
4. Implementación de un prototipo para SAP R/3
subdominio ERP y permitirá al usuario incorporarse al proceso de
parametrización en el paso en que lo dejó por última vez. Esta tabla
(Situación_Parametrización) estará vacía inicialmente y se irá cargando cuando
trabajen los usuarios en el asistente. Será este el que inserte, borre y modifique
los datos de esta tabla en función de la actividad del usuario.
?
Como la entidad Planes Estratégicos tiene la misma estructura que la Situación
de Parametrización utilizaremos la misma tabla para representarlas
(Situación_Parametrización). Esto es así porque los Planes Estratégicos suponen
la introducción de valores a algunas condiciones de las premisas de las reglas y a
algunos parámetros, igual que hace el usuario durante el proceso de
parametrización, luego su formalización será la misma. Para diferenciar entre
esta información diferente que comparte la misma tabla, los registros referentes
a Planes Estratégicos tendrán como usuario responsable el propio sistema y
tendrán un campo que indique la taxonomía empresarial a la que se refieren.
Cuando sea una particularización de una taxonomía para una empresa
determinada (relación entre Planes Estratégicos y Usuarios Colectivos) el
usuario responsable será el usuario colectivo que represente a la empresa.
Además la tabla contendrá un tipo de registro que diferencie claramente la
situación de parametrización de un usuario individual, los planes estratégicos
por taxonomía y las decisiones de negocio de cada empresa.
Todas estas tablas y relaciones a las que hemos llegado con las consideraciones
anteriores se reflejan en la figura 4.11.
- 306 -
4. Implementación de un prototipo para SAP R/3
DOCU_ACCIÓN
Documento
DOCUMENTO
Documento
Acción
DOCU_PARAM
Documento
Parámetro
CONDICIÓN
ACCIÓN
Condición
Acción
Acción
PARÁMETRO
Parámetro
Acción
Transacción
REGLA
SITUAC_PARAM
Acción_padre
Tipo
Acción_hijo
Acción
Condición
TRANSAC.ERP
Transacción
Usuario Individual
Usuario Colectivo
Taxonomía
Figura 4.11 Modelo físico de tablas del prototipo
La figura anterior muestra el diagrama de tablas del asistente. En cada una de ellas se
representan el nombre de la tabla, los campos claves, entre líneas dobles, y los campos
clave alternativa, es decir, que son claves de otras tablas. Estos últimos marcan las
líneas de relación entre las tablas.
A continuación se define la estructura de datos y el significado del contenido de cada
una de las tablas. Para definir la estructura de datos detallamos los campos que
componen la tabla indicando, para cada uno, lo siguiente:
?
?
?
?
?
Nombre. Nombre físico del campo;
Descripción. Significado del contenido del campo;
Tipo. Indica si el campo es clave, obligatorio u opcional;
Formato. Indica el formato del campo: numérico entero (int), número real (real)
o alfanumérico (alfa), y en este caso el número de caracteres que contiene;
Valores. Indica la lista de posibles valores, si los hay, o comentarios sobre
rangos permitidos o diseño del contenido.
- 307 -
4. Implementación de un prototipo para SAP R/3
Documento.
Esta tabla contendrá la información de ayuda al proceso de parametrización formada
por documentos de distinto tipo (txt, doc, ppt, jpg, gif, etc.) que ilustran de manera
visual, auditiva, textual, gráfica, etc. las acciones que va realizando el usuario y los
parámetros que debe introducir y sobre los que quiere más información. Cada
ocurrencia de la tabla hará referencia a un único documento independientemente de su
tipo y de las acciones o parámetros con los que se relacione.
Su estructura de datos es la siguiente:
NOMBRE
CLV_DOC
DESCRIPCION
Identificativo único del
documento
TIPO
clave
FORMATO
Alfa(10)
TIPO
Clase del documento. Hace
referencia a las posibles
extensiones de los ficheros
obligatorio
Alfa(10)
DESCRIP
Texto explicativo sobre el
documento
Texto breve que identifica
unívocamente un
documento
Dirección física del
ordenador donde se puede
localizar el documento
obligatorio
Alfa(500)
obligatorio
Alfa(200)
obligatorio
Alfa(200)
IDENTIF
DIRECCION
VALORES
Se compone de una
constante (‘D’) que hace
referencia al tipo de dato
(Documento), tres
caracteres que hacen
referencia al Sistema ERP
y 6 caracteres numéricos
que se asignan
secuencialmente
Posibles valores:
JPG
GIF
DOC
TXT
PPT
XLS
PDF
HTML
Formato de una dirección
física del ordenador
Acción.
Esta tabla contendrá todas las acciones por las que el asistente puede guiar al usuario
para parametrizar un Sistema ERP. Cada ocurrencia de la tabla hará referencia a una
única acción independientemente de su tipo y de sus relaciones.
Su estructura de datos es la siguiente:
- 308 -
4. Implementación de un prototipo para SAP R/3
NOMBRE
CLV_ACC
DESCRIPCION
Identificativo único de la
acción
TIPO
clave
FORMATO
Alfa(10)
IDENTIF
Texto breve que identifica
unívocamente una acción
Indicativo de la clase de
acción respecto a la
posibilidad de
parametrización
obligatorio
Alfa(200)
obligatorio
Alfa(1)
Texto explicativo sobre la
acción
obligatorio
Alfa(500)
CLASE
DESCRIP
VALORES
Se compone de una
constante que hace
referencia al tipo de
dato(‘A’=Acción), tres
caracteres que hacen
referencia al Sistema ERP
y 6 caracteres numéricos
que se asignan
secuencialmente
Posibles valores:
S (subdominio)=Acciones
que marcan el inicio de la
parametrización de un
proceso de negocio
N (normal)=Resto de
acciones
Condición.
Esta tabla contendrá todas las posibles condiciones de las acciones, es decir, los
resultados de las actividades realizadas durante la ejecución de las acciones y con cual
de ellas se relaciona. Cada ocurrencia de la tabla hará referencia a una única condición.
Su estructura de datos es la siguiente:
NOMBRE
CLV_CON
DESCRIPCION
Identificativo único de la
condición
TIPO
clave
FORMATO
Alfa(10)
CLV_ACC
Identificativo único de la
acción con la que se
relaciona
Texto breve de la pregunta
asociada a la condición
Texto explicativo sobre la
condición
obligatorio
Alfa(10)
obligatorio
Alfa(200)
obligatorio
Alfa(500)
IDENTIF
DESCRIP
VALORES
Se compone de una
constante (‘C’) que hace
referencia al tipo de dato
(Condición), tres
caracteres que hacen
referencia al Sistema ERP
y 6 caracteres numéricos
que se asignan
secuencialmente
Debe existir en la tabla
Acción
Regla.
Esta tabla contendrá todas las reglas semánticas necesarias para el proceso de
parametrización. Cada valor diferente del identificativo de regla indicará las acciones y
sus condiciones que hay que realizar para que se pueda ejecutar la regla, la acción
- 309 -
4. Implementación de un prototipo para SAP R/3
resultado de la ejecución de la regla, el conector que relaciona las condiciones y la
secuencia de ejecución de las condiciones. Cada ocurrencia de la tabla hará referencia a
una condición de una regla, es decir habrá tantos registros en la tabla para una única
regla como condiciones entran en la regla. Cada ocurrencia de la misma regla tendrá la
misma acción padre, ya que es el único resultado del cumplimiento de todas las
condiciones de la regla.
Su estructura de datos es la siguiente:
NOMBRE
CLV_REG
DESCRIPCION
Identificativo único de la
regla
TIPO
obligatorio
FORMATO
Alfa(10)
CLV_ACCP
Identificativo único de la
acción que se ejecutará si
se cumple la regla
Identificativo único de la
acción cuya condición
forma parte de las
condiciones de la regla
Indicativo del conector
lógico con que se
relacionan las distintas
condiciones de la regla
para que se pueda ejecutar
esta.
Número que indica en que
orden se debe realizar la
acción hija respecto al resto
de acciones hijas de la
regla
clave
Alfa(10)
clave
Alfa(10)
Debe existir en la tabla
Acción
obligatorio
Alfa(3)
Valores:
AND
XOR
OR
obligatorio
Int
obligatorio
Alfa(10)
El orden de ejecución irá
de menor a mayor. Valores
iguales indican que el
orden de ejecución entre
esas acciones es
indiferente
Debe existir en la tabla
Condición y llevar
asociado en esa tabla la
acción que aparece en esta
como acción hija
CLV_ACCH
CONECTOR
SECUENCIA
CLV_CON
Identificativo único de la
condición, relacionada con
la acción hija, que se debe
cumplir
VALORES
Se compone de una
constante (‘R’)que hace
referencia al tipo de dato
(Regla), tres caracteres que
hacen referencia al
Sistema ERP y 6
caracteres numéricos que
se asignan
secuencialmente
Debe existir en la tabla
Acción
TransacERP.
Esta tabla contendrá todas las transacciones del sistema ERP que se utilicen para dar
valores a los parámetros del sistema. Cada ocurrencia de la tabla hará referencia a una
única transacción independientemente del número de parámetros que contenga.
Su estructura de datos es la siguiente:
- 310 -
4. Implementación de un prototipo para SAP R/3
NOMBRE
CLV_TRAN
DESCRIPCION
Identificativo único de la
transacción ERP
TIPO
clave
FORMATO
Alfa(10)
SISTERP
Nombre que identifica
unívocamente el Sistema
ERP al que pertenece la
transacción
Nombre que identifica
unívocamente la
transacción
Texto descriptivo de la
transacción
obligatorio
Alfa(20)
obligatorio
Alfa(10)
obligatorio
Alfa(200)
IDENTIF
DESCRIP
VALORES
Se compone de una
constante (‘T’) que hace
referencia al tipo de dato
(Transacción), tres
caracteres que hacen
referencia al Sistema ERP
y 6 caracteres numéricos
que se asignan
secuencialmente
Procede del nombre de la
transacción del sistema
ERP
Procede de la descripción
de la transacción del
sistema ERP
Parámetro.
Esta tabla contendrá todos los parámetros del sistema ERP que se utilicen para
determinar el funcionamiento del sistema y que se deban valorar a través del asistente
para poder realizar la posterior parametrización automática del sistema ERP. Cada
ocurrencia de la tabla hará referencia a un único parámetro independientemente de sus
relaciones con las transacciones del sistema ERP y con las acciones del Asistente
Inteligente.
Su estructura de datos es la siguiente:
NOMBRE
CLV_PAR
DESCRIPCION
Identificativo único del
parámetro ERP
TIPO
clave
FORMATO
Alfa(10)
IDENTIF
Nombre que identifica el
parámetro
obligatorio
Alfa(10)
DESCRIP
Texto descriptivo del
parámetro
obligatorio
Alfa(500)
ERPCLAVE
Nombre del campo y de
la tabla del sistema ERP
que son clave en la tabla
donde está el parámetro
obligatorio
Alfa (50)
- 311 -
VALORES
Se compone de una
constante (‘P’) que hace
referencia al tipo de dato
(Parámetro), tres
caracteres que hacen
referencia al Sistema ERP
y 6 caracteres numéricos
que se asignan
secuencialmente
Procede del nombre del
parámetro del Sistema
ERP (herramienta CASE)
Procede de la descripción
del parámetro del Sistema
ERP (herramienta CASE)
Procede del Sistema ERP
(herramienta CASE)
4. Implementación de un prototipo para SAP R/3
Valor por defecto que se
propondrá para el campo
clave de la tabla donde
está el parámetro
Indica el tipo de valores
aceptados para el
parámetro
opcional
Alfa (100)
Procede del Sistema ERP
(herramienta CASE) y del
conocimiento experto
obligatorio
Alfa (20)
VALORES
Lista con el detalle de los
valores válidos según el
tipo de dato
opcional
Puntero
DEFECTO
Valor por defecto que se
propondrá inicialmente
Identificativo único de la
transacción ERP en la
que se da valor al
parámetro en el Sistema
ERP
Identificativo único de la
acción en la que se debe
definir el parámetro en el
Asistente Inteligente
opcional
Alfa (100)
obligatorio
Alfa(10)
Los distintos tipos de
datos pueden ser: Entero;
Real; Entero_positivo;
Real_positivo; Texto;
Fecha; Hora; Booleano;
Enumerado_tipo (existe
una lista de valores del
tipo indicado entre
cualquiera de los tipos
anteriores); Rango_tipo
(existe un valor inicial y
un valor final del tipo
indicado entre cualquiera
de los tipos anteriores)
En el caso que el tipo de
dato sea un enumerado
apuntará a una lista con
todos los valores de la
enumeración. En el caso
que el tipo de datos sea un
rango indicará los valores
iniciales y finales del
rango. En el caso que el
tipo de dato sea un texto
indicará el número de
caracteres máximo del
texto.
Procede del sistema ERP
(herramienta CASE)
Debe existir en la tabla
TransacERP
obligatorio
Alfa(10)
VAL_CLAVE
TIPO
CLV_TRAN
CLV_ACC
Debe existir en la tabla
Acción
Docu_Acción.
Esta tabla contendrá todas las relaciones entre documentos y acciones. Es decir, en
cada registro aparece un documento cuyo contenido informativo hace referencia a una
acción. El mismo documento puede relacionarse con distintas acciones y la misma
acción puede tener asociados distintos documentos, por ejemplo, se puede ilustrar la
misma actividad de diferentes formas: visual, textual, gráfica, etc. y cada una de estas
formas estar plasmada en un documento diferente. Cada ocurrencia de la tabla hará
referencia a una asociación documento/acción.
Su estructura de datos es la siguiente:
- 312 -
4. Implementación de un prototipo para SAP R/3
NOMBRE
CLV_ACC
CLV_DOC
DESCRIPCION
Identificativo único de la
acción al que se asocia el
documento
Identificativo único del
documento asociado con la
acción
TIPO
clave
FORMATO
Alfa(10)
VALORES
Debe existir en la tabla
Acción
clave
Alfa(10)
Debe existir en la tabla
Documento
Docu_Param.
Esta tabla contendrá todas las relaciones entre documentos y parámetros. Es decir, en
cada registro aparece un documento cuyo contenido informativo hace referencia a un
parámetro. El mismo documento puede relacionarse con distintos parámetros y el
mismo parámetro puede tener asociados distintos documentos, por ejemplo, se puede
ilustrar el mismo concepto de diferentes formas: visual, textual, gráfica, etc. y cada una
de estas formas estar plasmada en un documento diferente. Cada ocurrencia de la tabla
hará referencia a una asociación documento/parámetro.
Su estructura de datos es la siguiente:
NOMBRE
CLV_PARA
CLV_DOC
DESCRIPCION
Identificativo único del
parámetro al que se asocia
el documento
Identificativo único del
documento asociado con el
parámetro
TIPO
clave
FORMATO
Alfa(10)
VALORES
Debe existir en la tabla
Parámetro
clave
Alfa(10)
Debe existir en la tabla
Documento
Situ_Param.
Esta tabla contendrá tres tipos de información con la misma estructura:
?
La situación actual de todos los usuarios autorizados en la parametrización del
sistema ERP seleccionado y que hayan comenzado algún proceso de
parametrización de algún subdominio (proceso de negocio). La situación de
parametrización se almacenará solamente sobre los subdominios y contendrá
todas las reglas que ha ejecutado, el valor de los parámetros dados y el contenido
de las condiciones de las reglas pendientes, que formarán la cadena de
parametrización. Almacenar la cadena de parametrización de cualquier acción
(no subdominio) aumentaría la necesidad de almacenaje y la complejidad de los
procesos sin aportar prácticamente ningún valor añadido. Cada registro hará
referencia a la cadena de un subdominio pendiente de un usuario. Es decir, un
usuario puede tener abiertas varias cadenas de parametrización de diferentes
subdominio, aunque solo una para cada subdominio diferente. Cada cadena de
parametrización pendiente (de un usuario y subdominio) será una ocurrencia del
- 313 -
4. Implementación de un prototipo para SAP R/3
fichero. Cada ocurrencia de la tabla hará referencia a la última situación del
usuario dado respecto a la parametrización del subdominio dado.
?
La estrategia empresarial o plan estratégico de cada uno de los tipos definidos en
la taxonomía creada. La situación de parametrización se almacenará sobre los
subdominios y contendrá los valores de las condiciones de algunas reglas y el
valor de algunos parámetros (valores que definen la forma de actuar de la
taxonomía correspondiente), que formarán la cadena de parametrización. Cada
registro hará referencia a un subdominio de una taxonomía. Es decir, una
taxonomía puede tener abiertas varias estrategias empresariales de diferentes
subdominios, aunque solo una para cada subdominio diferente. Cada estrategia
empresarial definida (de una taxonomía y subdominio) será una ocurrencia del
fichero.
?
Las decisiones de negocio particulares de una empresa que personalizan la
estrategia empresarial de la taxonomía que le corresponde en un subdominio. La
situación de parametrización se almacenará sobre los subdominios y contendrá
los valores de las condiciones de algunas reglas y el valor de algunos parámetros
que modifican a los dados genéricamente para su taxonomía (valores que
definen la forma de actuar de la empresa correspondiente), que formarán la
cadena de parametrización. Cada registro hará referencia a un subdominio
particularizado de una empresa, pero no totalmente determinado. Es decir, una
empresa puede tener abiertas varias decisiones de negocio de diferentes
subdominio, aunque solo una para cada subdominio diferente. Cada decisión
empresarial definida (de una empresa y subdominio) será una ocurrencia del
fichero.
Su estructura de datos es la siguiente:
NOMBRE
CLV_TIPO
DESCRIPCION
Indica el tipo de valores
posibles que contiene el
registro
TIPO
clave
- 314 -
FORMATO
Alfa(1)
VALORES
Posibles valores:
‘S’=La situación última de
parametrización del
subdominio en el que ha
trabajo el usuario
individual;
‘P’=El plan estratégico de
cada taxonomía definida
de un subdominio;
‘E’= Las decisiones
empresariales particulares
de una empresa sobre un
subdominio
4. Implementación de un prototipo para SAP R/3
CLV_UIN
CLV_UCO
CLV_ACC
TAXONOMÍA
CADENA
Identificativo único del
usuario individual
(persona) responsable de la
cadena de parametrización
Identificativo único del
usuario colectivo
(empresa) responsable de
la cadena de
parametrización
clave
El mismo
del Sistema
ERP
clave
El mismo
del Usuario
Individual
Identificactivo único del
subdominio para el que se
almacena una cadena de
parametrización
Identificactivo único que
representa cada tipo
definido en la taxonomía
utilizada
clave
Alfa(10)
clave
Alfa(10)
obligatorio
Puntero
Apuntador a la cadena de
parametrización, que
contiene alguno de estos
tipos de información: ‘S’,
‘P’ y ‘E’.
Los tipos ‘P’ y ‘E’ pueden
ser el punto de partida del
trabajo de los usuarios
individuales para obtener
información tipo ‘S’.
La cadena de
parametrización es la
memoria de los parámetros
valorados y los caminos
seleccionados
Proviene de un interfaz
con el Sistema ERP. En el
caso de tipo ‘E’ y ‘P’ tiene
el valor ‘Sistema’
Debe identificarse
mediante un código único
cada empresa que trabaje
con el asistente. En el caso
de tipo ‘P’ tiene el valor
‘Sistema’
Debe existir en la tabla
Acción y ser de clase ‘S’
(subdominio)
En el caso de tipo ‘S’ y
‘E’ tiene el valor de la
taxonomía
correspondiente al usuario
colectivo. En el caso de
tipo ‘P’ estará formado por
tres dígitos que identifican
el área temática, cuatro
que identifican el sector y
tres que identifican el
negocio
Apunta a una dirección de
memoria que inicia la lista
enlazada que contiene la
cadena de parametrización
Cada una de estas tablas debe cargarse inicialmente en la Base de Datos del Asistente
Inteligente, con los datos correspondientes a las reglas, acciones y parámetros
necesarios para la parametrización de la planificación de necesidades de material en
SAP R/3. Estos datos deben estar cargados para poder, después de finalizado el trabajo
del usuario, generar un fichero para cargar automáticamente la parametrización de este
proceso en SAP R/3, pero no es necesario, hasta ese momento, que este instalado SAP
R/3. Se hace hincapié en que no hay carga inicial de datos en la tabla SITU_PARAM
para la información referida a la situación de parametrización de los usuarios que, como
hemos visto antes, es una tabla cuyo contenido se actualiza en función de la actividad de
los usuarios pero si para aquella relativa a la estrategia de negocio del tipo de empresa
seleccionada en el prototipo, producción y venta de tecnología en el ámbito de las
telecomunicaciones. El detalle de los datos iniciales de carga se presenta en el Anexo II.
- 315 -
4. Implementación de un prototipo para SAP R/3
4.2.2. Modelo de procesos
La finalidad del modelo de procesos es formalizar las funciones que debe realizar el
asistente determinando la estructura de programas necesarios para cubrirlas, y, para
cada uno, su funcionamiento, el diseño de las comunicaciones con los utilizadores del
programa y con otros sistemas informáticos, los accesos a la estructura de datos que
debe realizar y el diseño de las estructuras de datos internas que necesita.
En la descripción de este modelo vamos a distinguir cuatro partes: los procesos de
gestión de la base de datos, el proceso de inicio del Asistente Inteligente, el propio
proceso de parametrización y el proceso de carga automática del Sistema ERP.
Procesos de gestión de la Base de Datos.
Para facilitar la gestión propia de la Base de Datos se deberán construir los siguientes
procedimientos:
?
ALTA. Introducción de nuevos registros en cualquiera de las tablas. Incluida la
tabla Situ_Param en los casos de Estrategia o Plan Empresarial y Decisiones de
Negocio particulares;
?
BORRADO. Baja de registros en cualquiera de las tablas. Este procedimiento
deberá tener en cuenta las restricciones lógicas de dependencias entre tablas, por
ejemplo, no será posible borrar una acción sin borrar registros asociados de otras
tablas, como documentos o condiciones;
?
MODIFICACION. Modificación de campos no clave de registros en cualquiera
de las tablas;
?
CONSULTAS. Acceso a visualización de los datos de cualquiera de las tablas.
Además para obtener información enlazada, es decir, relaciones de los registros
de distintas tablas se crean las siguientes consultas a la Base de Datos:
1. CONDICIONES. Esta consulta recupera los datos de la tabla Condición y
añade, para cada registro, la acción (tabla Acción) asociada e información
descriptiva de ambas tablas.
2. REGLAS. Esta consulta recupera los datos de la tabla Regla y añade la
descripción de las acciones asociadas a cada registro tanto padre como hijo,
de la tabla Acción. También añade la descripción de la condición que
aparece en el registro de la tabla de Condición y datos importantes de la
regla como conector y secuencia.
- 316 -
4. Implementación de un prototipo para SAP R/3
3. DOCUMENTOS. Esta consulta recupera los datos de las tablas
Docu_Acción y Docu_Param, que relacionan Acciones con Documentos y
Parámetros con Documentos y añade los nombres de las acciones y los
parámetros de las tablas Acción y Parámetro. También añade la descripción
y la dirección del documento que aparece en cada registro de la tabla,
tomándolo de la tabla Documento.
4. PARÁMETROS. Esta consulta recupera los datos de la tabla Parámetro y
asocia a cada uno de los registros los datos de la acción (tabla Acción) y la
transacción (tabla Transacción) que se utiliza para darles valor en el
Asistente Inteligente y en el sistema ERP: Además se añade información
descriptiva de las tres tablas.
Proceso de inicio del Asistente Inteligente.
El proceso que se pone en marcha al ejecutar el asistente comienza con la pantalla
inicial del Asistente Inteligente, mostrada en la figura 4.12.
AIP
Figura 4.12 Diseño de la pantalla inicial del Asistente Inteligente
En esta pantalla se pedirá la identificación del usuario individual, su clave y la
empresa a la que pertenece. El asistente verificará la clave y la existencia de una
conexión entre los usuarios individual y colectivo introducidos. Si todos los datos son
correctos se permitirá al usuario elegir alguna de las opciones del menú: Usuarios,
Taxonomía empresarial, Documentos, Sistema ERP y Parametrización.
- 317 -
4. Implementación de un prototipo para SAP R/3
Si se selecciona la opción Usuarios se abrirá un submenú que permitirá la gestión de
usuarios colectivos e individuales (altas, bajas, consultas y modificaciones), la
posibilidad de relacionar usuarios individuales con colectivos (empresas) y la gestión de
preferencias de ambos tipos de usuarios.
Si se selecciona la opción Taxonomía Empresarial se abrirá un submenú que
permitirá la gestión (alta, baja y consulta y modificación) de los planes estratégicos
asociados a cada taxonomía empresarial. En algunas de estas opciones se enviará al
usuario al menú de Parametrización, ya que la estructura de los Planes Estratégicos se
corresponde con la cadena de parametrización obtenida de este proceso. En este mismo
menú se gestionarán de la misma manera las decisiones de negocio, que son
particularizaciones empresariales de las taxonomías.
Si se selecciona la opción Documentos se abrirá un submenú que permitirá la gestión
de documentos (carga, baja, consulta y modificación) y la asociación de documentos a
parámetros y acciones.
Si se selecciona la opción Sistema ERP se abrirá un submenú que permitirá la
gestión de las transacciones ERP y los parámetros que maneja el asistente. Además se
presentarán los procedimientos de interfaz con el sistema ERP: proceso de carga de
usuarios, de parámetros y de transacciones y proceso de generación del fichero de carga
automática de la parametrización realizada de un subdominio.
La última opción, Parametrización, la vamos a ver en el punto siguiente, ya que da
paso al proceso de parametrización.
Proceso de Parametrización.
Debido a la complejidad de este proceso vamos a distinguir varias fases:
1. Selección del tipo de Parametrización.
Si se selecciona la opción Parametrización, dentro del menú de inicio del Asistente
Inteligente, se presentará al usuario tres posibilidades:
?
Parametrización a partir de un plan estratégico. Se utilizará el usuario colectivo
introducido en la pantalla de inicio para buscar en la base de datos la taxonomía
a la que pertenece (en este prototipo solo se ha creado un usuario y una
taxonomía por lo que esta búsqueda puede obviarse). Se abrirá una ventana en la
que se mostrarán una lista con todas las cadenas de parametrización del fichero
Situ_Param que sean de clase ‘P’ (Plan Estratégico) y en las que el campo
Taxonomía se corresponda con la taxonomía del usuario colectivo que tratamos.
- 318 -
4. Implementación de un prototipo para SAP R/3
El usuario marcará un elemento de la lista para comenzar el proceso de
parametrización.
?
Parametrización a partir de decisiones de negocio. Se abrirá una ventana en la
que se mostrarán una lista con todas las decisiones de negocio del fichero
Situ_Param que sean de clase ‘E’ (Decisión Empresarial) y en las que el campo
Usuario Colectivo corresponda con el introducido en la pantalla de inicio. El
usuario marcará un elemento de la lista para comenzar el proceso de
parametrización.
?
Parametrización libre o continuar una parametrización en curso. Se abrirá una
ventana en la que se mostrarán para el usuario individual introducido en la
pantalla de inicio los posibles subdominios a parametrizar. Para elegir los
subdominios a presentar primero se seleccionaran de la tabla Acción aquellos
registros que sean subdominios y después se verificará si alguno de ellos ya
tiene una parametrización en proceso para la empresa (usuario colectivo) a la
que pertenece el usuario individual. Estos subdominios seleccionados se
presentarán en una lista. Esta lista se rellenará con aquellas acciones del fichero
Acción que tengan CLASE=’S’ y que no existan en el campo CLV_ACC del
fichero Situ_Param con el campo CLV_UCO igual al usuario colectivo al que
pertenece el individual y con el campo CLASE = ‘S’ (Situación de
Paramerización), más aquellos subdominios que existan en el fichero
Situ_Param con el campo CLV_UCO igual al usuario colectivo al que pertenece
el individual y con el campo CLASE = ‘S’ (Situación de Paramerización). Cada
elemento de la lista tendrá los siguientes campos:
o Identificativo del subdominio. Valor del campo CLV_ACC de la tabla
Acción (si el subdominio nunca ha sido parametrizado en esta empresa)
o de la tabla Situ_Param (si el subdominio tiene ya un proceso de
parametrización en esta empresa);
o Nombre del subdominio. Valor del campo IDENTIF de la tabla Acción
del registro que tenga en el campo CLV_ACC el valor del campo
anterior (identificativo del subdominio);
o Estado de parametrización. Indica la situación de parametrización del
subdominio. Sus posibles valores son ‘no iniciado’, ‘en proceso’, y
‘completado’. Si el subdominio nunca ha sido antes parametrizado en
esta empresa (subdominios que no existe en el fichero Situ_Param con el
campo CLV_UCO igual al usuario colectivo al que pertenece el
individual y con el campo CLASE = ‘S’) se pondrá ‘no iniciado’. En
caso contrario se pondrá ‘completado’ si todos los registros de la cadena
- 319 -
4. Implementación de un prototipo para SAP R/3
de parametrización asociada mediante el campo CADENA tienen todas
las respuestas marcadas (con ‘SI’ o ‘NO’) o se pondrá ‘en proceso’ si
hay alguna respuesta en blanco;
o Usuario responsable. Si el estado de parametrización (campo anterior) es
‘no iniciado’ se dejará en blanco. En los otros dos casos se tomará el
valor del campo CLV_UIN del registro correspondiente de la tabla
Situ_Param que cumpla que CLV_ACC sea igual al identificativo del
subdominio, CLV_UCO sea igual al usuario colectivo al que pertenece el
individual y CLASE sea igual a ‘S’ (Situación de Paramerización).
El usuario marcará un elemento de la lista, entre aquellos que no tengan usuario
responsable o que tengan como usuario responsable el usuario introducido en la
pantalla de inicio, para comenzar el proceso de parametrización. La figura 4.13
muestra un ejemplo de pantalla de selección de subdominio a parametrizar.
AIP
Figura 4.13 Diseño de la pantalla de selección de subdominio a parametrizar
2. Diseño de la tabla interna de trabajo o cadena de parametrización.
El proceso del parametrización se basa en una tabla de trabajo que residirá en
memoria y contendrá la situación de parametrización de cada usuario que esté
trabajando con el Asistente Inteligente. El diseño de la tabla se muestra en la figura
4.14.
- 320 -
4. Implementación de un prototipo para SAP R/3
Acción
Padre1
Acción
Padre2
…
Acción
Padren
Acción
Hija11
Acción
Hija21
…
Acción
Hijan1
Respuesta11 Parámetros11 … Acción
Hija1n
Respuesta21 Parámetros21 … Acción
Hija2n
…
…
… …
Respuestan1 Parámetrosn1 … Acción
Hijann
Respuesta1n Parámetros1n
Respuesta2n Parámetros2n
…
…
Respuestann Parámetrosnn
Fig. 4.14 Tabla interna de trabajo o cadena de parametrización
Cada registro de esta tabla corresponde con una regla semántica cuya acción padre es
la acción conclusión de la regla. Los campos de cada registro serán, además de la acción
padre, todas las acciones hijas o condiciones de la regla, las respuestas (‘SI’, ‘NO’ o
vacío) que ha dado el usuario al cumplimiento de cada condición y el valor dado por el
usuario a los parámetros asociados a cada acción hija. El número posible de condiciones
en una regla es indefinido pero, utilizando las normas de formalización de las reglas
semánticas de la metodología de este trabajo, hemos definido un número máximo de 10
condiciones por cada conclusión.
El valor dado a los parámetros, en cada acción hija que lleve asociada esta actividad,
se representará mediante un fichero que contiene los parámetros y los valores que se han
definido durante la parametrización de cada acción hija. El campo llamado Parámetros
de la tabla interna o cadena de parametrización contendrá un apuntador a un fichero de
este tipo. La estructura de cada uno de los ficheros apuntados será la mostrada en la
figura 4.15. En ella se representa para cada campo su nombre, descripción, tipo, formato
y valores, de forma similar a la utilizada en el modelo de datos.
NOMBRE
CLV_PAR
CLV_TRAN
ERPCLAVE
VALOR_C
VALOR_P
DESCRIPCION
Identificativo único del
parámetro ERP
Identificativo único de la
transacción ERP
Nombre del campo y de la
tabla del sistema ERP que
son clave en la tabla donde
está el parámetro
Valor asociado al campo
clave de la tabla donde está
el parámetro
TIPO
clave
FORMATO
Alfa(10)
obligatorio
Alfa(10)
obligatorio
Alfa (50)
opcional
Alfa (100)
Valor asociado al
parámetro
obligatorio
Alfa (100)
VALORES
Procede de la tabla
Parámetro
Procede de la tabla
Parámetro
Procede de la tabla
Parámetro
Procede del valor por
defecto que da el asistente
o del valor introducido por
el usuario
Procede del valor por
defecto que da el asistente
o del valor introducido por
el usuario
Fig. 4.15 Fichero de valoración de parámetros apuntado desde la tabla interna o
cadena de parametrización
- 321 -
4. Implementación de un prototipo para SAP R/3
En la tabla interna de trabajo o cadena de parametrización se insertará un registro
cada vez que el usuario pase a ejecutar una nueva acción. Se modificará un registro de
la tabla con las respuestas de los usuarios a las condiciones de las acciones hijas y con la
introducción de valores a los parámetros en aquellas acciones hijo que tengan esta
actividad asociada. Solo se borrarán registros de la tabla cuando el usuario quiera
modificar la parametrización realizada y volver a un paso anterior.
3. Estructura del interfaz del Asistente Inteligente.
El interfaz del Asistente Inteligente consta de una única pantalla principal aunque,
sobre ella, pueden abrirse otras ventanas, informativas o de parametrización,
dependiendo de las acciones del usuario. La figura 4.16 muestra el diseño de la pantalla
principal.
(AND = Realizar todas las acciones)
Volver a un paso anterior
Salir del asistente
Fig. 4.16 Interfaz del Asistente Inteligente
En esta pantalla la parte principal se dedicará a presentar las acciones y condiciones
por las que el usuario se moverá (reglas semánticas) para realizar el proceso de
parametrización. Por tanto, en ella aparecerán los datos de la regla asociada a la acción
que el usuario quiere realizar.
En la primera línea se puede leer el texto identificativo de la conclusión lógica de la
regla o acción padre (campo IDENTIF de la tabla Acción correspondiente al registro de
clave CLV_ACCP de la tabla Regla para la regla que estamos presentando). También en
la primera línea se debe mostrar el significado del conector de la regla de la siguiente
- 322 -
4. Implementación de un prototipo para SAP R/3
forma: AND=’Realizar todas las acciones’; OR=’Realizar al menos una acción’;
’XOR=’Realizar solo una acción’.
En las líneas siguientes aparecerán las premisas lógicas de la regla o acciones hijas.
Se mostrarán ordenadas por el campo SECUENCIA de la tabla Regla y, en caso de
haber secuencias repetidas (la misma secuencia en varias premisas indica que el orden
de ejecución entre ellas es indiferente) dará igual el orden en que aparezcan. El valor del
campo SECUENCIA se mostrará al lado izquierdo del texto de la acción hija, bajo el
título genérico ‘ORDEN DE EJECUCION’. Al lado derecho del texto se podrá leer la
condición asociada a la acción hija que se obtendrá del campo DESCRIP de la tabla
Condición correspondiente al registro de clave CLV_CON de la tabla Reglas para la
acción hija de la regla que estamos presentando. A la derecha de la pregunta de la
condición se pondrán dos marcadores con los textos ‘SI’ y ‘NO’ que será sobre los que
haga clic el usuario en función de su respuesta a la condición.
Además, en una zona más pequeña de la pantalla de interfaz, se mostrara la cadena
de parametrización seguida hasta ese momento por el usuario, presentando
secuencialmente las acciones por los que ha ido pasando y señalando cuales de ellas
están concluidas y cuales están pendientes de terminar (en el caso de acciones iniciales
o intermedias de la red semántica que necesiten para su realización completa la
ejecución de otras acciones). Esta información se obtendrá de la tabla de trabajo que
maneja el asistente. El asistente determina que una acción está concluida, si todas las
condiciones asociadas a ella (acciones hijas) en el registro de la tabla en que aparezca
como acción padre han sido respondidas por el usuario con ‘SI’ o ‘NO’. Esta tabla
tendrá más o menos acciones según el desarrollo de la parametrización que lleve el
usuario en esta sesión o contando con sesiones anteriores si había almacenado la cadena
de parametrización en otras sesiones.
Dado que la tabla de trabajo puede ser muy larga y el usuario debe poder visualizarla
completamente, aunque en la pantalla solo aparezca una parte, esta debe poder moverse
desplazándose hacia la zona que marque el usuario. También en esta zona el usuario
podrá seleccionar las opciones ‘Salir del asistente’ o ‘Volver a un paso anterior de la
parametrización’ y para poder usar esta última opción marcará sobre la acción a la que
quiere volver.
4. Recorrido por la red semántica.
Comienza cuando el usuario tiene en la pantalla principal una regla correspondiente a
una acción a realizar. Cuando al usuario se le presenta una regla y sus acciones
asociadas y las condiciones de estas se le permitirá marcar la respuesta ‘SI’ o ‘NO’ de
una de las condiciones (dependiendo de la secuencia de ejecución y del tipo de
conector), pero solo una cada vez.
- 323 -
4. Implementación de un prototipo para SAP R/3
Al presentar en la pantalla una regla, si el usuario está realizando la parametrización
partiendo de un plan estratégico o de una decisión particular de negocio no se le
presentarán en la pantalla las acciones que en dicha estrategia han sido marcadas con
‘NO’ (no realizar la acción correspondiente), de esta forma se obligará al usuario a
recorrer el camino que marca la estrategia. Igualmente como veremos en la ventana de
parametrización no se presentarán los parámetros ya establecidos por la estrategia.
Cuando se presenta una regla en la pantalla principal comienza el proceso de
recorrido de la red semántica por parte del asistente que, según el conector, iniciará de
la siguiente forma:
?
Conector AND.
El usuario debe obligatoriamente marcar todas las respuestas con ‘SI’ (debe
realizar todas las acciones hijas de la acción padre o conclusión de la regla) en el
orden señalado por el orden de ejecución (con un número de secuencia menor).
Si se señala alguna respuesta con ‘NO’ se enviará un mensaje del tipo ‘Debe
realizar esa acción, acción obligatoria’. Si hay varias acciones con la misma
secuencia se permitirá marcar cualquiera de ellas, pero solo una cada vez. El
resto de respuestas estarán bloqueadas hasta que se procese la marcada y se
desbloquee la siguiente en orden de ejecución.
?
Conector XOR.
El usuario debe obligatoriamente marcar una de las respuestas con ‘SI’ pero
solamente una de ellas (debe realizar una y solo una entre todas las acciones
hijas de la acción padre o conclusión de la regla). En el caso de este conector al
tener que realizar una sola acción no tiene sentido el orden de ejecución, pero se
seguirá utilizando por coherencia con el resto de conectores. Se desbloquearán
todas las respuestas según el orden de ejecución y se permitirá marcar una cada
vez. Cuando el usuario haya ya marcado una respuesta con ‘SI’ el asistente no
permitirá marcar otra con ‘SI’, si el usuario lo intenta dará un mensaje del tipo
‘Ya ha sido realizada una acción. Solo es posible realizar una de las acciones
presentadas’. Si el usuario se ha equivocado de acción y se da cuenta en ese
momento puede elegir la opción de ‘Volver a un paso anterior’ y modificar el
recorrido de la red semántica. Si al final de todas las respuestas, no se ha
señalado ninguna con ‘SI’ se enviará un mensaje del tipo ‘Debe realizar una de
las acciones presentadas’ y se volverá al inicio del proceso de la regla,
borrándose de la tabla de trabajo todas las respuestas.
?
Conector OR.
El usuario debe obligatoriamente marcar una de las respuestas con ‘SI’ pero,
además, puede marcar con ‘SI’ todas las que quiera (debe realizar al menos una
- 324 -
4. Implementación de un prototipo para SAP R/3
de todas las acciones hijas de la acción padre o conclusión de la regla). El
asistente tiene el cuenta el orden de ejecución luego desbloqueará aquellas
acciones que tengan la secuencia menor (una o más de una) hasta que el usuario
de una respuesta (‘SI’ o ‘NO’) a alguna de ellas (una cada vez), desbloqueando,
cuando todas las de la misma secuencia estén marcadas, las siguientes según este
orden. Cuando se hayan marcado todas las condiciones el asistente verificará
que al menos una respuesta sea ‘SI’. Si esto no se cumple se dará un mensaje del
tipo ‘Marque una de las respuestas’ y se volverá al inicio del proceso de la regla,
borrándose de la tabla de trabajo todas las respuestas.
A continuación se seguirá con el recorrido por la red semántica según la respuesta
marcada por el usuario:
?
Cuando se marque una respuesta con ‘NO’ se deben seguir los pasos siguientes:
1. Marcar en la tabla de trabajo la respuesta ‘NO’ de la acción hija.
2. Verificar que todas las otras respuestas a todas las condiciones de la
acción padre están marcadas. Puede ocurrir que:
o Todas las respuestas estén marcadas. En este caso esta acción está
finalizada y se debe recorrer la tabla de trabajo desde el último
registro hasta el primero o hasta encontrar una acción padre con
alguna condición sin respuesta. Esta acción padre encontrada será la
acción más próxima que ha quedado pendiente de su completa
realización, y es la que debe pasar a realizarse. Por tanto las acciones
hijas de esta acción se mostrarán en la pantalla principal con las
respuestas que tuvieran en la tabla de trabajo y se pedirá al usuario
que marque una acción, volviendo al principio del proceso. Si al
recorrer toda la tabla no se encuentra ninguna acción pendiente se
dará un mensaje ‘Parametrización finalizada ¿Quiere guardar la
parametrización realizada?’ y se actuará como se explica en el punto
7 (Finalización y modificación de la parametrización realizada).
o No todas las respuestas estén marcadas. En este caso se deben
desbloquear los marcadores ‘SI’ y NO’ de la acción hija con orden de
ejecución siguiente al que se ha respondido. Si hubiera acciones con
la misma secuencia no marcadas se desbloquearían todos sus
marcadores a la vez. Se pedirá al usuario que marque una acción y se
volverá al principio del proceso
?
Cuando se marque una respuesta con ‘SI’ se deben seguir los pasos siguientes:
- 325 -
4. Implementación de un prototipo para SAP R/3
1. Abrir la ventana de parametrización asociada a la acción hija marcada.
2. Una vez rellenos los parámetros, marcar en la tabla de trabajo la
respuesta ‘SI’ en la acción hija.
3. Buscar la acción hija marcada en la tabla Regla como acción padre con
CLV_ACCP. Si se encuentra se insertará este registro en la tabla de
trabajo con esta regla, se mostrará en la pantalla principal y se pedirá al
usuario que marque una acción, volviendo al principio del proceso. Si no
se encuentra se debe verificar que todas las otras respuestas a todas las
condiciones de la acción padre están marcadas, igual que se ha hecho en
el segundo paso en caso de respuesta ‘NO’.
5. Ventana informativa.
Esta ventana se abrirá sobre la pantalla principal para presentar los documentos
asociados a cualquier acción que aparezca en la pantalla principal, ya sea en la regla en
ejecución o en la cadena de parametrización realizada, o a cualquier parámetro que
aparezca en la ventana de parametrización conectada a una acción en ejecución. La
ventana se abre al hacer clic con el ratón sobre una acción o un parámetro. Entonces el
asistente buscará los documentos asociados en la tabla DOCU_ACCIÓN, para acciones,
o DOCU_PARAM, para parámetros, entrando con la clave CLV_ACC de la acción o
CLV_PARA del parámetro. Si existe más de un documento asociado se pueden mostrar
en el orden en que aparezcan o teniendo en cuenta las preferencias del usuario. La
selección de la preferencia se hace en base a lo definido por el propio usuario o, si no
existe preferencia particular, por el usuario colectivo (empresa) al que pertenece. Esta
preferencia ayudará al asistente a decidir el orden de presentación de los documentos en
función de su tipo: más orientados al texto o a gráficos, más auditivos o más visuales,
etc.
Los documentos que se presentan se localizan físicamente a través de la tabla
Documento con clave CLV_DOCU. Una vez mostrado el documento se debe preguntar
al usuario si desea más información y, en caso afirmativo, se le presentará el segundo
documento y así hasta que el usuario decida no necesitar más información o no haya
más documentos. Si alguna acción o parámetro no tiene ningún documento asociado
solo se sacará en esta zona el texto del campo DESCRIP de la tabla Acción con clave
CLV_ACC de la acción que se trata o de la tabla Parámetro con clave CLV_PARA del
parámetro que se trata.
- 326 -
4. Implementación de un prototipo para SAP R/3
6. Ventana de parametrización.
Esta ventana se mostrará al usuario cuando una acción hija ha sido marcada con ‘SI’
y dicha acción tiene asociado algún parámetro. El usuario deberá rellenar o ratificar (si
el asistente propone un valor) los parámetros que aparecen en esta pantalla. Para abrir la
ventana de parametrización asociada a una acción se busca en la tabla Parámetro el
valor del campo CLV_ACCH de la pantalla principal del interfaz que ha sido marcada
con ‘SI’, en el campo CLV_ACC. A continuación con estos registros seleccionados se
crea una pantalla en la que se muestran estos registros, ya que cada uno corresponde a
un parámetro a rellenar o ratificar por el usuario.
El proceso de presentación y verificación de los parámetros tendrá en cuenta el tipo
de dato (campo TIPO) y los posibles valores (campo VALORES) que hay en el registro
correspondiente de la tabla Parámetro. En esta pantalla al lado del nombre de cada
parámetro aparecerá el campo para que lo introduzca el usuario, vacío o con el valor por
defecto que hay en la tabla Parámetro. Si el usuario se posiciona y hace clic sobre el
campo a rellenar se abrirá una ventana que le indique el tipo de dato y los valores
posibles, es decir, ayuda para rellenarlo correctamente. Si el usuario se posiciona y hace
clic sobre el nombre del parámetro el asistente, como ya hemos visto, abrirá una ventana
informativa.
Si el usuario está realizando la parametrización partiendo de un plan estratégico o de
una decisión particular de negocio no se le presentarán en la pantalla los parámetros que
ya hayan sido valorados por la estrategia que se sigue y que por tanto no puedan ser
modificados por el usuario que debe ceñirse a la estrategia establecida.
Cuando el usuario está parametrizando en nombre de la empresa una decisión de
negocio o en nombre del sistema una taxonomia empresarial, en esta ventana no se
considerará la obligatoriedad de rellenar todos los parámetros, ya que la estrategia
definida puede, solo, determinar algunos de ellos. Esto no es así cuando parametrice un
usuario individual que debe obligatoriamente dar valor a todos los parámetros no
definidos por la estrategia de la que parte.
Con los valores tecleados o aceptados por el usuario se creará un fichero, cuya
estructura ya hemos visto en el apartado sobre el diseño de la tabla de trabajo, y su
apuntador se introducirá en el registro actual de la tabla de trabajo, en el
correspondiente a la acción hija que se está tratando.
7. Finalización y modificación de la parametrización realizada.
La zona donde se muestra la cadena de parametrización se actualizará
constantemente con el contenido de la tabla de trabajo. En esta zona, además, aparecerá
- 327 -
4. Implementación de un prototipo para SAP R/3
la opción de ‘Vuelta a un paso anterior’. El usuario podrá utilizar esta opción cuando
haya cometido un error o quiera repetir (deshacer y volver a hacer) parte del proceso de
parametrización desde un punto. Si elige esta opción el usuario deberá marcar una
acción de las que aparecen en la cadena de parametrización. En este caso se deben
realizar tres acciones:
1. Presentar en la zona principal del interfaz la regla de la tabla Regla con clave
CLV_ACCP (acción padre) igual a la clave de la acción marcada.
2. Marcar en las respuestas a las condiciones de la regla presentada (acciones hijas)
que se presentan en la pantalla de interfaz los valores que aparecen en el registro
correspondiente de la tabla de trabajo.
3. Borrar de la tabla de trabajo los registros posteriores al registro correspondiente a
la acción marcada para volver. Se borraran igualmente los ficheros de
parametrización asociados a las acciones hijas de los registros borrados.
La otra opción que aparece en la zona donde se muestra la cadena de parametrización
es ‘Salir del asistente’. Si el usuario marca esta opción se le preguntará ‘¿Quiere guardar
la parametrización realizada para continuar en la próxima conexión? Si el usuario
responde:
?
‘NO’. Se finaliza el proceso del Asistente Inteligente sin guardar la tabla de
trabajo actual, es decir, se perderán los cambios realizados en esta sesión.
?
‘SI’. Se guardará la tabla de trabajo en memoria permanente y se buscará en la
tabla Situ_Param si existe un registro de clase igual a ‘S’ (Situación de
Parametrización) para el mismo subdominio y usuario individual. Si este registro
existe se modificará el campo CADENA con la dirección de la memoria
permanente donde se ha almacenado la tabla de trabajo (cadena de
parametrización). Si no existe este registro se crea con los datos ya indicados
(usuario individual, subdominio y clase=’S’) apuntando a la tabla de trabajo. Por
último se finaliza el proceso del Asistente Inteligente.
Proceso de carga automática del Sistema ERP.
El usuario tiene opción de cargar de forma automática la parametrización de un
subdominio realizada a través del asistente en la propia base de datos del sistema ERP.
Esta posibilidad tiene la ventaja de que no es necesario tener implantado ni utilizar el
sistema ERP mientras se realiza su parametrización. Una vez que esta se ha terminado y
el sistema ERP está implantado se parametriza mediante la ejecución de un proceso
- 328 -
4. Implementación de un prototipo para SAP R/3
batch, utilidad existente en los todos los sistemas ERP importantes, con los datos
generados por el Asistente Inteligente.
Cuando seleccione esta opción el asistente mostrará una lista con los subdominio
presentes en la tabla Situ_Param (campo CLV_ACC) que tengan clase = ‘S’, usuario
responsable el mismo que está seleccionando esta opción y esté completo (con el mismo
criterio visto al describir el inicio del Asistente Inteligente). El usuario podrá marcar
uno o varios elementos de la lista y el asistente generará uno o varios ficheros
compatibles con el sistema ERP que hay que cargar.
Para seleccionar los parámetros que deben ir en cada fichero se leerá la cadena de
parametrización apuntada por el campo CADENA del subdominio seleccionado de la
tabla Situ_Param. La estructura apuntada tendrá varios registros y cada uno de ellos
puede tener varias acciones hija con un fichero de parámetros asociado. Se tomarán
todos los registros de todos esos ficheros, ya que cada uno de estos registros se refiere a
un parámetro que ha sido valorado durante el proceso de parametrización de ese
subdominio.
Se creará un fichero para cada subdominio y tendrá un registro por cada parámetro
relleno durante la parametrización de ese subdominio. La estructura del fichero se
muestra en la figura 4.17, en el caso de este prototipo, para su carga en el Sistema ERP
SAP R/3.
NOMBRE
TRANSACCIÓN
VALOR_C
PARÁMETRO
VALOR_P
DESCRIPCION
Nombre de la transacción
del Sistema ERP
Valor asociado al campo
clave en la tabla donde
está el parámetro
Nombre del parámetro del
Sistema ERP
Valor asociado al
parámetro
TIPO
obligatorio
FORMATO
Alfa(10)
obligatorio
Alfa (25)
obligatorio
Alfa(10)
obligatorio
Alfa (100)
VALORES
Transacción a ejecutar en
SAP R/3
Valor del campo clave,
necesario para poder
ejecutar la transacción
Parámetro a actualizar en
SAP R/3
Valor a actualizar para el
parámetro dado
Fig. 4.17 Estructura del fichero de carga automática para SAP R/3
Esta estructura es utilizada por SAP R/3 para actualizar el valor de los parámetros
enviados en su base de datos. Para ellos SAP R/3 utiliza la herramienta Business
Application Program Interface (BAPI) que es una interfaz estándar, independiente de la
plataforma de desarrollo, que permite a aplicaciones externas acceder a los objetos de la
base de datos a través de modelos de funciones. Una aplicación, para acceder a un dato
de SAP R/3 a través de BAPI necesita solo saber el nombre de la función (transacción)
y el detalle de la interfaz. Estos detalles pueden ser de dos tipos:
- 329 -
4. Implementación de un prototipo para SAP R/3
?
?
Parámetros de importación. Contiene los datos que se deben transferir a SAP
desde la aplicación que ejecuta la función desde BAPI.
Parámetros de exportación. Contiene los datos que debe enviar SAP a la
aplicación que ejecuta la función desde BAPI.
Para definir estos parámetros BAPI utiliza los IDoc (Intermediate Document) que
son formatos estándar de datos estructurados en modo de facilitar la comunicación a
través de BAPI. Estas estructuras contenedoras propietarias de SAP constituyen el
contenido de la comunicación cuando se efectúa una llamada desde BAPI. En SAP R/3
hay muchísimos tipos de IDoc, cuyo número aumenta proporcionalmente al uso de SAP
R/3 y las necesidades de comunicación de sus clientes y asociados, ya que es fácil
modificarlos o crearlos nuevos, según sus exigencias. Se pueden visualizar todas las
categorías de IDoc y el detalle de sus registros solamente ejecutando una transacción,
normalmente autorizada al personal de desarrollo o administración del sistema (WE61),
o consultando la documentación disponible en la Herramienta de Documentación de la
Interfaz IDoc.
Para crear estas estructuras de datos de tipo importación existe una utilidad en SAP
R/3, llamada Batch Input, que permite ejecutar una transacción cualquiera, siempre que
tenga definido un IDoc, y a continuación, generar un código de programa con las
sentencias necesarias para que esa transacción sea ejecutada de forma batch a través de
BAPI con el valor de los datos que se ha introducido de forma on-line en la transacción.
Todas las transacciones de parametrización del sistema tienen definido un IDoc y, por
tanto, pueden ser diseñadas con la utilidad de Batch Input y ejecutadas con la
herramienta BAPI.
Para utilizar estas ventajas de SAP R/3 para nuestra carga automática de parámetros
solo es necesario ejecutar los pasos siguientes:
1. Obtener el batch input de las transacciones de parametrización con unos valores
determinados de prueba.
2. Obtener el fichero de carga del Asistente Inteligente.
3. Ordenar el fichero anterior por nombre de transacción.
4. Ejecutar una utilidad que lea todos los registros del fichero de carga de la misma
transacción y para cada una copie el batch input correspondiente sustituyendo
los valores determinados de prueba por los valores obtenidos del Asistente
Inteligente.
5. Ejecutar los batch input obtenidos a través de la herramienta BAPI.
- 330 -
4. Implementación de un prototipo para SAP R/3
4.3. CONSTRUCCIÓN DE LA BASE DE CONOCIMIENTOS DEL
DOMINIO
Como última fase de diseño del prototipo, y una vez desarrollado este, vamos a
obtener el conocimiento del módulo del dominio diseñado correspondiente al
subdominio elegido: la política de planificación de necesidades de material en SAP R/3.
La obtención incluye la red semántica del subdominio y la asociación de información
adicional, aplicando, para ello, la metodología propuesta para la creación de contenidos
en el desarrollo de las reglas y objetos de información necesarios para su
implementación. También desarrollaremos el subdominio anterior especificando valores
de las reglas y parámetros según le estrategia empresarial para la producción y venta de
tecnología en el ámbito de las telecomunicaciones. Según la taxonomía desarrollada en
esta tesis se encuadra en el área de Industrias Productivas, el sector de Alta Tecnología
y el negocio de Fabricantes de equipos.
Para realizar esta tarea, presentaremos el modelo EPC del subdominio obtenido a
través de manuales y conocimiento del experto. A continuación, para cada diagrama
EPC del modelo, traduciremos su representación gráfica a representación mediante
reglas semánticas, el conjunto de las cuales constituye la red semántica. El resto de
pasos intermedios y finales de la metodología desarrollada se detallara con ejemplos en
el Anexo I: ejemplo de diagrama EPC estructurado para su conversión automática,
ejemplo de formateo de un diagrama EPC mediante XML, ejemplo de documentación
asociada a un elemento de conocimiento y ejemplo de programa de batch input (carga
de transacciones) para SAP R/·3. Finalmente concretaremos los valores de parámetros y
eventos presentes en cada diagrama EPC, según la estrategia empresarial de la
taxonomía elegida, lo que constituirá la base para el proceso de parametrización de
empresas de ese ámbito. El conjunto de todo el conocimiento expresado mediante el
modelo de datos diseñado para nuestro prototipo en este capítulo, se detalla en el Anexo
II.
Los cuadros siguientes muestran para cada diagrama EPC del modelo:
?
?
?
?
Número y título del diagrama;
Representación gráfica del diagrama;
Representación mediante reglas de producción del diagrama;
Valores de condiciones y parámetros para la estrategia empresarial de la
taxonomía Industrias Productivas/Alta Tecnología/Fabricantes de equipos.
- 331 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 1 – Parametrización planificación de necesidades
Longitud
Máscara
Autom./manual
Codificación de
artículos
¿Establecer
codificación de
artículos?
Descripc.clase A
Descripc.clase B
Descripc.clase C
Descripción
clasificación
ABC
¿Describir
clasificación
ABC?
Codificación de
órdenes
¿Establecer
codificación de
órdenes?
AND
¿Parametrizar
gestión de la
demanda?
Parametrización
gestión de la
demanda
¿Parametrizar
grupos de
planificación?
Parametrización
grupos de
planificación
AND
Parametrización
planificación de
necesidades
¿Parametrizar
planificación de
necesidades?
SI (¿Establecer codificación de artículos? Y ¿Describir codificación ABC? Y
¿Establecer codificación de órdenes?) Y ¿Parametrizar gestión de la demanda? Y
¿Parametrizar grupos de planificación? ENTONCES Parametrización planificación de
necesidades
Todas las condiciones son susceptibles de ejecución. Ninguno de los parámetros tiene
un valor fijo, aunque se presenta un valor por defecto para la longitud y el indicador de
automático o manual.
- 332 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 2 – Codificación de órdenes
¿Codificación
por línea de
producto?
Codificación por
línea de
producto
MPS:nºinicial/nºfinal
MRP:nºinicial/nºfinal
¿Codificar
por tipo de
planificación?
Codificación por
tipo de
planificación
¿Codificar
por tipo de
producción?
Codificación por
tipo de
producción
XOR
Codificación de
órdenes
SI ¿Codificación por línea de producto? O EXCLUSIVO ¿Codificación por tipo de
planificación? O EXCLUSIVO ¿Codificación por tipo de producción? ENTONCES
Codificación de órdenes
Todas las condiciones son susceptibles de ejecución, ya que la estrategia empresarial
no implica la obligatoriedad de un tipo de codificación de órdenes, por tanto ninguno
de los parámetros tiene un valor fijo.
- 333 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 3 – Codificación por línea de producto
Nombre línea
Nºinicial
Nºfinal
¿Finalizar?
Codificación
de rango
¿Rango de
una línea?
Fin codificación
por líneas
XOR
¿Rango
para otras
líneas?
Codificación por
línea de
producto
AND
Codificación por
línea de
producto
SI ¿Rango de línea? Y (¿Rango para otras líneas? O EXCLUSIVO ¿Finalizar?)
ENTONCES Codificación por línea de producto
Todas las condiciones son susceptibles de ejecución, ya que la estrategia empresarial
no implica la obligatoriedad de definir un número determinado de líneas de producto,
por tanto ninguno de los parámetros tiene un valor fijo.
- 334 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 4 – Codificación por tipo de producción
nºinicial subcontrata
nºfinal subcontrata
Establecer
rango órdenes
de subcontrata
nºinicial compra
nºfinal compra
Establecer
rango órdenes
de compra
nºinicial fabricación
nºfinal fabricación
Establecer
rango órdenes
de fabricación
¿Codificar
órdenes de
subcontrata?
¿Codificar
órdenes de
compra?
¿Codificar
órdenes de
fabricación?
OR
Codificación por
tipo de
producción
SI ¿Codificar órdenes de subcontrata? O ¿Codificar órdenes de compra? O ¿Codificar
órdenes de fabricación? ENTONCES Codificación por tipo de producción
Todas las condiciones son susceptibles de ejecución, ya que la estrategia empresarial
no implica la obligatoriedad de definir un tipo de producción exclusivo, por tanto
ninguno de los parámetros tiene un valor fijo.
- 335 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 5 – Parametrización gestión de la demanda
Barrera de la demanda
Parametrización
política ATO
¿Política ATO?
Parametrización
barrera de la
demanda para MTS
¿Política MTS?
Parametrización
política MTO
¿Política MTO?
XOR
Parametrización
gestión de la
demanda
SI ¿Política ATO? O EXCLUSIVO ¿Política MTS? O EXCLUSIVO ¿Política MTO?
ENTONCES Parametrización gestión de la demanda
Las condiciones Política MTO y Política MTS tiene los valores fijos ‘NO’, ya que la
estrategia empresarial de esta taxonomía implica una política Assembly to Order, por
tanto los parámetros de este diagrama no son parametrizables en este caso.
- 336 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 6 – Parametrización política MTO
Barrera de la demanda
Parametrización
política de
consumo
Prametrización
barrera de la
demanda
¿Parametrizar
política de
consumo?
¿Parametrizar
barrera de la
demanda?
AND
Parametrización
política MTO
SI ¿Parametrización barrera de la demanda? Y ¿Parametrización política de consumo?
ENTONCES Parametrización política MTO
Este diagrama no aparecerá en el camino de parametrización de esta taxonomía, ya que
la condición se ha cerrado en el diagrama anterior.
- 337 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 7 – Parametrización política ATO
Barrera de la demanda
Barrera de la demanda
Parametrizar
barrera de la
demanda para
nivel
Parametrizar
barrera de la
demanda para
montaje
¿Niveles
iniciales con
previsiones?
Parametrización
política de
consumo
¿Todos los
niveles excepto
montaje
final?
¿Parametrizar
política de
consumo?
XOR
AND
Parametrización
política ATO
SI (¿Niveles iniciales con previsiones? O EXCLUSIVO ¿Todos los niveles excepto
montaje final?) Y ¿Parametrización política de consumo? ENTONCES
Parametrización política ATO
Este diagrama es obligatorio en el camino de parametrización de esta taxonomía.
Dependiendo de la empresa se elegirá la acción Parametrización barrera de la demanda
para nivel o Parametrización barrera de la demanda para montaje, en ambos casos el
parámetro correspondiente llevará una ayuda asociada: en el primero indicará
introducir el tiempo de producción de los niveles inferiores de producto y en el
segundo el tiempo total de producción menos el del montaje final.
- 338 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 8 – Parametrización política de consumo
Periodo adelante
Consumo
hacia adelante
¿Consumo
de previsiones
posteriores?
Periodo atrás
Consumo
hacia atrás
¿Consumo
de previsiones
anteriores?
Periodo adelante
Periodo atrás
Consumo
hacia delante y
atrás
¿Consumo
de previsiones
anteriores y
posteriores?
XOR
Parametrización
política de
consumo
SI ¿Consumo de previsiones posteriores? O EXCLUSIVO ¿Consumo de previsiones
anteriores? O EXCLUSIVO ¿Consumo de previsiones anteriores y posteriores?
ENTONCES Parametrización política de consumo
Para la taxonomía elegida las condiciones ¿Consumo de previsiones posteriores? y
¿Consumo de previsiones anteriores? tienen un valor NO, ya que se debe elegir un
consumo adelante y atrás (la otra condición). Además, se propondrá como valor por
defecto para los parámetros Periodo adelante y Periodo atrás, un mes, que puede ser
modificado según las decisiones de cada empresa particular.
- 339 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 9 – Parametrización grupos de planificación
Parametrización
política de
planificación
¿Finalizar?
¿Parametrizar
política de
planificación?
Fin grupos de
planificación
XOR
¿ Parametrizar
otro grupo de
planificación?
Parametrización
grupos de
planificación
AND
Parametrización
grupos de
planificación
SI ¿Parametrizar política de planificación? Y (¿Parametrizar otro grupo de
planificación? O EXCLUSIVO ¿Finalizar?) ENTONCES Parametrización grupos de
planificación
Todas las condiciones son susceptibles de ejecución, ya que la estrategia empresarial
implica la definición de unos grupos de planificación según se explicó en el apartado
4.1.3 de este capítulo. Este diagrama permite parametrizar tantos grupos de
planificación como sea necesario. En la taxonomía elegida, como ya hemos visto, debe
recorrerse el camino del proceso Parametrización política de planificación diez veces
correspondientes a los siguientes grupos de planificación:
Grupo 1 – Artículos MPS, de compras y clase A;
Grupo 2 – Artículos MPS, de compras y clase B;
Grupo 3 – Artículos MPS, de compras y clase C;
Grupo 4 – Artículos MPS, de fabricación y clase A;
Grupo 5 – Artículos MPS, de fabricación y clase B;
Grupo 6 – Artículos MPS, de fabricación y clase C;
Grupo 7 – Artículos MRP de compras y clase B
Grupo 8 – Artículos MRP de compras y clase C
Grupo 9 – Artículos MRP de fabricación y clase B
Grupo 10 – Artículos MRP de fabricación y clase C
- 340 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 10 – Parametrización política de planificación
Parametrización
por tipo de
artículo
Parametrización
por tipo de
artículo
¿Parametrizar
artículos MRP?
¿Parametrizar
artículos MPS?
OR
¿Parametrizar
por tipo de
artículo?
Parametrización
por tipo de
artículo
XOR
Parametrización
política de
planificación
SI (¿Parametrizar artículos MRP? O ¿Parametrizar artículos MPS?) O EXCLUSIVO
¿Parametrizar por tipo de artículo? ENTONCES Parametrización política de
planificación
Según lo definido en el diagrama anterior, la estrategia definida pasará por diferenciar
entre artículos MPS y MRP, por lo que la condición ¿Parametrizar por tipo de artículo?
No se recorrerá nunca, tendrá valor NO.
- 341 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 11 – Parametrización por tipo de artículo
Parametrización
por tipo de
gestión
¿Parametrizar
gestión de
compra?
Parametrización
por tipo de
gestión
¿Parametrizar
gestión de
fabricación?
Parametrización
por tipo de
gestión
¿Parametrizar
gestión de
subcontrata?
OR
Parametrización
por tipo de
gestión
¿Parametrizar
todo tipo de
gestión?
XOR
Parametrización
por tipo de
artículo
SI (¿Parametrizar gestión de compra? O ¿Parametrizar gestión de fabricación? O
¿Parametrizar gestión de subcontrata?) O EXCLUSIVO ¿Parametrizar todo tipo de
gestión? ENTONCES Parametrización por tipo de artículo
Según lo definido en el diagrama anterior, la estrategia definida pasará por diferenciar
entre gestión de fabricación y de compra, por lo que las condiciones ¿Parametrizar por
gestión de subcontrata? y ¿Parametrizar todo tipo de gestión? no se recorrerán nunca,
tendrán valor NO.
- 342 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 12 – Parametrización por tipo de gestión
Parametrización
perfiles de
planificación
¿Parametrizar
clase A?
Parametrización
¿Parametrizar
Parametrización
¿Parametrizar
clase C?
perfiles de
planificación
perfiles de
planificación
clase B?
OR
Parametrización
perfiles de
planificación
¿Parametrizar
todas las clases
ABC?
XOR
Parametrización
por tipo de
gestión
SI (¿Parametrizar clase A? O ¿Parametrizar clase B? O ¿Parametrizar clase C?) O
EXCLUSIVO ¿Parametrizar todas las clases ABC? ENTONCES Parametrización por
tipo de gestión
Según lo definido en el diagrama anterior, la estrategia definida pasará por diferenciar
entre gestión de fabricación y de compra, por lo que las condiciones ¿Parametrizar por
gestión de subcontrata? Y ¿Parametrizar todo tipo de gestión? no se recorrerán nunca,
tendrán valor NO.
- 343 -
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 13 – Parametrización perfiles de planificación
Nombre perfil
Descripción perfil
Parametrización
datos del perfil
¿Parametrizar
mensajes de
excepción?
Parametrización
mensajes de
excepción
Factor anticipación
Factor retraso
¿Parametrizar
gestión de
órdenes?
Parametrización
gestión de
órdenes
Planificador
Límite lanzamiento
Límite confirmación
¿Parametrizar
política de
orden?
¿Parametrizar
datos del
perfil?
Parametrización
política de
orden
AND
Parametrización
perfiles de
planificación
SI (¿Parametrizar datos del perfil? Y (¿Parametrizar mensajes de excepción? Y
¿Parametrizar gestión de órdenes? Y ¿Parametrizar política de orden?) ENTONCES
Parametrización perfiles de planificación
Según los grupos de planificación y los correspondientes caminos a recorrer el valor de
los parámetros será el siguiente:
Nombre
G.1
G.2
G.3
G.4
G.5
G.6
G.7
G.8
G.9
G.10
Descripción
MPS/C/A
MPS/C/B
MPS/C/C
MPS/F/A
MPS/F/B
MPS/F/C
MRP/C/B
MRP/C/C
MRP/F/B
MRP/F/C
F.anticip.
0
5
5
0
5
5
10
15
10
15
F.rechazo
15
15
15
15
15
15
15
15
15
15
- 344 -
Planific.
P1
P2
P2
P3
P4
P4
P5
P6
P7
P8
L.Lanzam.
3
3
3
10
10
10
3
3
10
10
L.Confir.
10
10
10
10
10
10
5
5
5
5
4. Implementación de un prototipo para SAP R/3
Diagrama EPC 14 – Parametrización política de orden
Tipo de política
¿Política =
cantidad fija?
Definición de
cantidad
Cantidad
¿ Política =
semana fija?
Definición de
semanas
Semanas
¿ Política =
mes fijo?
Definición de
meses
Meses
Selección de
modificadores
Selección de
política
¿Elegir política?
Cant.máxima
Cant.mínima
¿Elegir
modificadores?
XOR
AND
Parametrización
política de
orden
SI ¿Selección de política? Y (¿Política = cantidad fija? O EXCLUSIVO ¿Política =
semana fija? O EXCLUSIVO ¿Política = mes fijo?) Y ¿Elegir modificadores?
ENTONCES Parametrización política de orden
Según los grupos de planificación y los correspondientes caminos a recorrer el valor de
los parámetros será el siguiente:
Nombre
G.1
G.2
G.3
G.4
G.5
G.6
G.7
G.8
G.9
G.10
T.política
E
W
W
E
W
W
M
M
W
M
Semanas
Meses
2
2
1
1
1
2
2
1
- 345 -
4. Implementación de un prototipo para SAP R/3
El parámetro Cantidad no tendrá nunca valor, ya que no se utiliza la política cantidad
fija. El parámetro Cantidad Máxima, no tiene, en ningún caso, un valor definido en la
taxonomía. El parámetro Cantidad Mínima, no tendrá un valor definido, pero debe
asociársele una ayuda que indique que se debe utilizar para cada artículo, en el caso de
compras, el valor dado como lote mínimo del proveedor preferente y en el caso de
fabricación, el lote mínimo calculado de fabricación.
- 346 -
5 CONCLUSIONES Y TRABAJOS FUTUROS
Conviene recordar el objetivo inicial de este trabajo de investigación que
enunciábamos de la manera siguiente:
Crear un asistente de parametrización de sistemas ERP que
aúne las funcionalidades de los sistemas de parametrización
actuales con funcionalidades dotadas de cierta inteligencia en la
ayuda y tutorización de procedimientos, estableciendo así
mismo el marco metodológico adecuado para la creación de
contenidos procedimentales, estructurados y formalizados,
soportados por dicho sistema.
Podemos concluir que, lo pretendido inicialmente, se ha logrado de una manera
efectiva ya que hemos realizado una propuesta de arquitectura que integra varios
módulos con inteligencia con sistemas ERP existentes en el mercado. Así mismo,
hemos construido una metodología de creación de contenidos para dichos módulos con
un enfoque sistemático, formal, preciso y, sobre todo, eficaz, mostrando la validez de la
propuesta con la construcción de un prototipo que implementa un sistema concreto,
basado en dicha arquitectura y utilizando dicha metodología para dotarle de contenidos.
Durante el desarrollo del trabajo, se han obtenido una serie de conclusiones como
consecuencia directa de la misma y de las dificultades que se han ido resolviendo. Estas
conclusiones que ponen de relevancia los puntos clave se resumen en las siguientes:
?
Existe una necesidad de herramientas que ayuden en la importante tarea de
parametrización de los sistemas ERP de forma inteligente pero sin
prescindir de la capacidad del humano para tomar decisiones, en un
ámbito, el empresarial, en el que la Inteligencia Artificial es poco utilizada.
- 347 -
5. Conclusiones y trabajos futuros
El uso de sistemas ERP para la gestión empresarial permite la personalización
de los flujos de trabajo y proporciona la posibilidad de configuración del sistema
mediante un proceso de parametrización del mismo que se debe abordar antes de
su uso, es decir, en fase de implantación. Los sistemas ERP proporcionan así
una vasta gama de elecciones estratégicas y de posibilidad de personalización
superando la rigidez de sistemas precedentes y garantizando, además, mejores
resultados de negocio y menores costes de mantenimiento y actualización. Para
que esto sea posible es fundamental la forma de parametrizar el sistema. Para
instalar y parametrizar correctamente el sistema, se suele requerir de la ayuda de
integradores expertos, tanto del sistema como del funcionamiento y estrategia de
la empresa utilizadora del mismo. Además, toda la información necesaria para
llevar a buen puerto este proceso se encuentra fragmentada, dado su extensión y
atomización, entre distintos expertos. Por tanto es necesario diseñar
procedimientos, herramientas y técnicas que ayuden a realizar esta tarea. El
asistente fruto de este trabajo nace para cumplir este objetivo y cubrir esta
carencia, dotando de inteligencia a un proceso complejo y cuyas consecuencias
son vitales para el éxito del negocio, en un ámbito en el que la Inteligencia
Artificial apenas se conoce, el ámbito empresarial
Nuestra propuesta implica el uso de un sistema inteligente que ayuda al humano
en la realización de una tarea compleja, pero sin prescindir de la capacidad de
este para percibir, razonar y actuar ya que interactúa con él proporcionándole
información útil en cada momento, presentándole posibles recorridos del
proceso y proponiéndole valores personalizados según sus preferencias y
estrategia empresarial.
?
La definición del asistente propuesta en este trabajo supone un gran avance
arquitectural integrándose en la política de mejora continua y
disminuyendo el tiempo de los procesos de implantación de sistemas ERP.
La arquitectura aquí propuesta utiliza las ventajas de los Sistemas Basados en el
Conocimiento, en concreto los Sistemas Inteligentes de Tutorización (SIT) y de
los Sistemas de Ayuda Inteligente (SAI). Para que estos sistemas se comporten
inteligentemente, además de poseer conocimientos fieles a la realidad deben ser
capaces de utilizarlos eficientemente al realizar inferencias. Los sistemas
basados en reglas son los más comúnmente utilizados para realizar estas
inferencias por su simplicidad y similitud con el razonamiento humano, por lo
que se sus características y arquitectura se han tenido en cuenta para realizar este
trabajo.
Nuestro asistente tiene una arquitectura parecida a los sistemas estudiados: una
interfaz interactiva y amigable con el usuario, un módulo estructurado de
348
5. Conclusiones y trabajos futuros
conocimientos procedimentales, un módulo del usuario que permita tratamientos
personalizados y un modulo similar al del tutor, en los SIT, que guía de forma
inteligente a través de los conocimientos procedimentales, el proceso de
parametrización de los sistemas ERP. Presenta la novedad, en comparación con
los SIT y SAI, de un módulo de calidad integrado que retroalimenta al sistema y
sugiere mejoras. La necesaria flexibilidad empresarial implica redefinir los
elementos que la constituyen y sus características para poder mantener o
aumentar su propio nivel de prestaciones, frente a los cambios del ambiente y
del entorno. De este modo es necesario realizar una gestión de la calidad
permanente, para alcanzarla y mantenerla, como parte de un proceso de mejora
continua. De ahí que nuestro trabajo integre un módulo de calidad que permita el
control de calidad continúo, de forma que el asistente inteligente proponga la
revisión constante de la parametrización inicial del sistema para adecuarse a los
cambios. Por tanto, nuestro asistente no solo será útil durante el desarrollo del
proyecto de implantación del sistema ERP, sino que deberá ser utilizado a lo
largo de todo su ciclo de vida, proporcionando una evolución continúa en la
optimización del ERP. Esta actividad no se realiza actualmente por el
desconocimiento de los usuarios utilizadores de las tareas de parametrización y
su significado. La definición de un módulo de calidad implica establecer unos
criterios e índices de calidad a aplicar y relacionarlos con la parametrización
realizada en el sistema. Este conocimiento debe ser integrado en el dominio
inicialmente, siendo más sencillo construirlo a partir del conocimiento experto a
la vez que el necesario para las tareas de parametrización durante la
implantación.
Además la arquitectura posee un flujo directo de comunicación con el sistema
ERP que permite formalizar las decisiones de parametrización realizadas por el
usuario y por el asistente y la posterior carga automática de esta estructura en el
sistema ERP. Esta funcionalidad disminuirá el tiempo total de los proyectos de
implantación ya que las fases de instalación del paquete y de parametrización
podrían realizarse en paralelo, puesto que el asistente obtiene la estructura de
parametrización sin necesidad de instalar el sistema ERP.
?
Es fundamental para el desarrollo de sistemas procedimentales tener una
metodología que permita generar contenidos de una manera eficaz y con
criterios de ingeniería y que los represente mediante modelos de fácil y
rápida creación.
Entendiendo por ingeniería “el conjunto de métodos, técnicas y herramientas
para el diseño, construcción y utilización de productos diversos”, también el
desarrollo de contenidos procedimentales, como los que se manejan en la
arquitectura propuesta, debería abordarse utilizando un enfoque ingenieril que
349
5. Conclusiones y trabajos futuros
suponga el establecimiento de un método riguroso de trabajo basado en una
descomposición del proceso de creación de contenidos en varias fases en las que
se aplique un conjunto de procedimientos, técnicas y herramientas.
En nuestro caso es fundamental establecer una metodología estricta ya que
debemos construir un conocimiento procedimental fragmentado entre distintas
personas, con distintos formatos y en varios modelos (modelo de procesos de
negocio, modelo de datos del ERP). Además es necesario por las características
de la tarea de nuestro asistente: integrar procesos con información para facilitar
la toma de decisiones. Analizar, diseñar, crear y gestionar este tipo de
contenidos es muy difícil careciendo de un método riguroso y preciso.
Siempre que se quiere capturar datos e información de la realidad circundante es
necesario recurrir a modelos que simplifiquen la difícil, compleja y difusa
estructura con la que estos se muestran. Dichos modelos tienden a simplificar y
esquematizar dicha estructura haciendo que sea más fácil su manejo a través de
procesos automáticos. La dificultad radica en construir modelos que sean lo más
completos posibles sin aumentar de manera significativa su complejidad. En
nuestro caso son los procesos de negocio y su información relativa los que
tenían que ser modelados en forma de reglas que guiaran el proceso de
parametrización y conseguir esto de una manera fiable y, más o menos rápida,
tarea que ha sido siempre el cuello de botella de los Sistemas Expertos. El
poseer una técnica, inmersa dentro de una metodología, como soporte gráfico y
en lenguaje estándar para la representación de modelos es fundamental a la hora
de recoger y sintetizar la información dispersa por manuales, libros, en las
propias personas expertas, etc.
El uso, en el escenario de este trabajo, de la técnica gráfica EPC y la herramienta
de software integrada ARIS que la soporta, facilita el trabajo de extracción del
conocimiento, ya que son utilizadas internacionalmente por expertos y empresas
para proyectos de ingeniería de procesos de negocios. Además proporcionan
funciones para la validación del modelo y para la generación automática de
datos sobre los elementos del mismo que permitan formalizarlo en lenguaje
XML y en reglas de conocimiento. La representación formal elegida en este
trabajo ha sido el lenguaje de marcado XML, por su amplio y creciente uso en
entornos científicos y empresariales, su sencillez y sus prestaciones y su
reconocimiento como un estándar para el intercambio de información a través de
medios telemáticos. Con estas bases creemos posible el obtener unos grados de
rendimiento a la hora de capturar e implementar reglas superiores a los logrados
hasta la fecha.
350
5. Conclusiones y trabajos futuros
?
El éxito de un sistema ERP depende de una parametrización
particularizada para cada organización y su propia estrategia empresarial,
para lo cual nuestro asistente personalizará su interacción con el usuario y
sus decisiones y propuestas en base una taxonomía empresarial adecuada.
La necesaria flexibilidad y adaptabilidad empresarial conduce a la posible
definición y uso de distintas estrategias empresariales, distintos modelos de
explicación, pronóstico y decisión unidos a métodos de planificación, dirección
y control aplicables a distintas situaciones. Este entorno conduce a la
clasificación de las empresas en base a distintos factores que pueden influir en
su estrategia empresarial y determinar su flujo de trabajo. Es decir, la elección
de una taxonomía empresarial que ayude a definir sus procesos adaptados a los
distintos tipos de problemas y situaciones, será condición necesaria para el éxito.
La necesidad de crear una taxonomía, como la definida en este trabajo, nace para
agrupar las diferentes empresas posibles utilizadoras de sistemas ERP según la
estrategia empresarial que guíe el uso de dicho sistema y, por tanto, su
parametrización. El asistente la utilizará para definir de forma inteligente
parámetros y condiciones de las reglas de producción del dominio que
conformarán la parametrización del sistema ERP y, por tanto, para facilitar la
consecución de la estrategia empresarial en cada caso.
Para cada uno de los tipos de la taxonomía definida es importante establecer
soluciones diseñadas a medida de los estándares o mejores prácticas, procesos y
retos específicos de cada sector, teniendo en cuenta la visión de las necesidades
y características de procesos sectoriales específicos y optimizando las estrategias
y procesos de negocio con estructuras de soporte efectivas que garantizan el
intercambio y la disponibilidad de la información a través de las técnicas y
herramientas ya especificadas.
El trabajo de investigación de esta tesis continúa el desarrollado por otros
investigadores, ya citados, relativo a la aplicación de la Inteligencia Artificial y la
Ingeniería Lingüística del Conocimiento, pero deja, todavía, abiertos algunos aspectos
importantes. Como continuación del trabajo aquí expuesto podemos establecer varias
líneas futuras de investigación: la aplicación de la arquitectura y metodologías
propuestas a otros ámbitos técnicos y empresariales; la extensión de la metodología al
uso de otras técnicas y herramientas de formalización y validación que mejoren su
interoperabilidad; la construcción de otros dominios de conocimiento relativos a
distintos procesos empresariales e, incluso, a otros sistemas ERP, además de los
utilizados en el prototipo; la ampliación de la creación y aplicación de taxonomías
empresariales; la mejora del sistema de calidad; y la adaptación y gestión de los
contenidos informativos.
351
5. Conclusiones y trabajos futuros
Los objetivos que nos hemos planteado en este sentido y una breve descripción de
estos trabajos futuros se detallan a continuación.
1. Aplicación de la arquitectura y metodologías propuestas a otros ámbitos
técnicos y empresariales. Entre estos ámbitos podemos especificar los
siguientes:
?
Asistente para la configuración del hardware y el software de base en
ordenadores personales o de negocio. Este sistema determinaría la mejor
configuración de hardware y software de base mediante reglas de producción
que formalizarían una gran base de conocimiento con recomendaciones,
requisitos del cliente, configuraciones pasadas, restricciones y dependencias.
Una vez obtenida la configuración la enviaría a la sección comercial que
recibiría los datos del cliente, la fecha de obtención de la configuración, los
requisitos iniciales que solicitó el cliente, un diagrama del producto que
mostraría la forma apropiada de configurar el equipo y detalles técnicos de
cada elemento de la configuración. Este sistema debería también prever la
retroalimentación, es decir, los problemas que le surjan a los clientes con sus
equipos se formalizan y almacenan en la base de conocimientos y se utilizan
en las configuraciones futuras, seleccionando entre las posibles
configuraciones aquellas de menor coste, mayor fiabilidad y mayores
prestaciones.
?
Aplicación dentro del área financiera, como la definición de presupuestos.
Un asistente como el aquí propuesto crearía un dominio de conocimiento con
reglas y sus dependencias que indicarían cuáles son las mejores decisiones
sobre la asignación de recursos en base a varios años de información
histórica. Se podría establecer un módulo de calidad que midiera resultados y
cuantificara la eficiencia, comparando el dinero real gastado y necesitado
con el dinero asignado.
?
Configuración de productos manufacturados. El proceso de ingeniería de
productos, en este caso la fase de configuración previa al montaje final,
consiste en obtener productos personalizados y con funcionalidades
diferentes en función de unas normas establecidas partiendo de un conjunto
de productos componentes. Por tanto, configurar consiste en seleccionar
elementos que se utilizan en el montaje del producto final para obtener
funcionalidades diferentes. Un sector donde sería muy útil sería el área de
telefonía acceso-radio, en la que el experto decide condiciones, premisas,
opciones configurables, etc. de un producto final, según cada pedido de cada
cliente, aunque también se podría aplicar a sectores más cotidianos como
352
5. Conclusiones y trabajos futuros
coches o muebles. Las condiciones de configuración se basan en la
existencia de los siguientes elementos, individuales o agrupados,
combinados de muchas formas y presentes en distintos niveles del producto:
básicos, deben ir siempre presentes en el producto final; opcionales, pueden
ir o no de forma independiente o dependiendo de otros según reglas
definidas; alternativos, dentro de una selección de ítems solo es posible
elegir uno o varios entre un conjunto definido. El análisis lingüístico de los
manuales y el conocimiento de expertos que establecen las normas y las
agrupaciones y tipos de elementos producirá un conjunto de reglas
semánticas que utilizarán los operadores lógicos condicionando la estructura
del producto final en sus distintos niveles de fabricación. Además podría
integrarse con otras funciones de los sistemas ERP, como el proceso de
ofertas, el control de capacidades, la planificación de órdenes de producción
y de compra y la planificación a largo plazo que incluye la gestión de las
previsiones comerciales.
?
Sistemas para el archivo de documentación y bibliotecas, en las que el
asistente guiaría al experto en las decisiones sobre la estructura del archivo
según una serie de parámetros y el establecimiento de la medida y la altura
de estantes y librerías para optimizar el espacio. En este asistente sería muy
útil la función de mejora continua, ya que la inserción de nuevos elementos
es constante y, por tanto, es necesaria reconfigurar la estructura para que sea
eficiente.
2. Extensión de la metodología al uso de otras técnicas y herramientas de
formalización y validación que mejoren su interoperabilidad. Frente al alto
número de diferentes lenguajes y técnicas de modelado de procesos y
herramientas CASE presentes en el mercado, se podrían analizar y diseñar otras
interfaces entre nuestro asistente y estos productos para mejorar su
interoperabilidad.
3. Construcción de otros dominios de conocimiento relativos a distintos
procesos empresariales e, incluso, a otros sistemas ERP, además de los
utilizados en el prototipo. Este trabajo continuaría con la formalización y
validación del total de subdominios que cubren el completo proceso de negocio
que gestiona SAP R/3. Podría ampliarse a otros sistemas ERP, que aunque
básicamente realizan las mismas funciones pueden contener parámetros
diferentes. El uso del asistente para otros sistemas ERP supondría no solo el
análisis y construcción de diferentes contenidos sino, además, el desarrollo de
interfaz de comunicación de datos en los dos sentidos: recogida y validación de
usuarios y carga automática de parámetros. También sería posible desarrollar
asistentes similares al aquí propuesto para la parametrización de otras
353
5. Conclusiones y trabajos futuros
aplicaciones empresariales complejas como CRM (Customer Relationship
Management) y el control del nivel de fábrica en tiempo real.
4. Ampliación de la creación y aplicación de taxonomías empresariales. Dentro
de este aspecto sería interesante definir otras taxonomías empresariales que
guiaran al asistente según el tipo de empresa que lo utilice. En este trabajo
hemos desarrollado una taxonomía por sectores, pero podría desarrollarse otra
por dimensión, en el que se distinga entre pequeña, mediana y gran empresa, e,
incluso, una combinación sector/dimensión que ayudaría a que el asistente
pudiera establecer muchos parámetros por defecto sin necesidad de la
intervención del usuario. La estrategia de las empresas pequeñas y medianas
necesita, independientemente del sector, unas soluciones sencillas, escalables y
potentes, por lo que cierta parametrización será similar para todas ellas. Debe
cubrir los requisitos empresariales más comunes relativos a contabilidad,
generación de informes, compras y ventas, siendo fundamental la simplicidad y
facilidad de uso.
5. Mejora del sistema de gestión de calidad. El sistema desarrollado en la
arquitectura de nuestro asistente podría mejorarse añadiendo un submódulo de
gestión de la configuración que mantuviera las distintas versiones de
parametrización de cada empresa e identificara los cambios que se introducen en
cada versión. Debería poder comparar versiones no solo entre las de la misma
empresa sino entre una empresa y otra y recoger el motivo de cada cambio, sus
consecuencias, fecha, responsables, etc. Incluso debería tener funciones de
vuelta atrás en los casos en que un cambio produjera resultados inesperados y no
deseados. Por otro lado se podría mejorar la metodología de creación de los
contenidos de usuario relativos a las métricas de calidad analizando el trabajo
realizado en [Herrera et alt., 2003] y [Sanchez et alt., 2005], ya descrito en el
capítulo 2, en el que se definirían criterios, utilizando lógica difusa y procesos de
decisión lingüística, para la valoración de proyectos de implantación de sistemas
ERP. Sería posible utilizar esta misma técnica para definir los criterios, no para
la implantación, sino para el resultado del uso del sistema e integrar esta
definición con la estructura de conocimiento definida en esta tesis.
6. Adaptación y gestión de contenidos informativos. Nuestro asistente debe
proporcionar información adicional multimedia que sirva para explicar las
decisiones tomadas o para ayudar al usuario a tomarlas Esta información en
diversos formatos (texto, video, audio, etc.) está asociada a parámetros y reglas a
través de los objetos de información. Estos objetos, cuyo contenido proviene de
la documentación existente y del conocimiento de los expertos, puede
considerarse como material docente. Existen numerosos estudios en el ámbito
del e-learning sobre las características que deben cumplir los objetos docentes.
354
5. Conclusiones y trabajos futuros
Sería conveniente aplicar los estándares existentes sobre la definición y
estructura de los objetos educativos, como el LOM (Learning Object Metadata)
de IEEE o SCORM, a nuestros contenidos. Las ventajas de tal adaptación son
evidentes, por ejemplo la posibilidad de ser utilizados e integrados en otros
ámbitos como la formación de los empleados, tanto de la empresa creadora del
sistema ERP como de la utilizadora, y la facilidad de transporte (portabilidad) a
otros plataformas informáticas. Permitiría, también, que estos materiales
formaran parte de repositorios de objetos y contenidos docentes existentes (por
ejemplo MERLOT o GEM) o, incluso, la creación de repositorios propio. Esta
última posibilidad sería muy interesante para empresas consultoras en proyectos
de implantación de sistemas ERP, ya que podrían proporcionar estos repositorios
a sus clientes y utilizarlos en su trabajo de asesoría, aprovechando sus
facilidades de búsqueda y gestión de contenidos.
355
5. Conclusiones y trabajos futuros
356
6 BIBLIOGRAFÍA
[Aalst, 1999]
W.M.P.var der Aalst. “Formalization and Verification of Event-driven Process Chains”.
En: Information and Software Technology, vol.41, n.10, pp.639-650, 1999.
[Aalst y Hofstede, 2002]
W.M.P.van der Aalst y A.H.M. ter Hofstede. “Workflow Patterns: On the Expressive
Power of (Petri-net-based) Workflow Languages”. En Proceedings of the Fourth
Workshop on the Practical Use of Coloured Petri Nets and CPN Tools (CPN 2002),
vol.560 of DAIMI, pp.1-20. Aarhus: University of Aarhus, 2002.
[Aberg y Shahmehri, 2001]
J.Aberg y N.Shahmehri. “An Empirical Study of Human Web Assistants: Implications
for User Support in Web Information Systems”. En Proceedings of the CHI Conference
on Human Factors in Computing Systems, pp.404-411. Seattle, Washington, USA:
ACM Press, 2001.
[Acs y Audretsch, 1990]
Z.Acs y D.Audretsch. “Innovation and Small Firms”. Cambridge: The MIT Press, 1990.
[Allen et alt., 2002]
D.Allen et alt. “ERP Critical Success Factors: an exploration of the contextual factors in
public sector institutions”. En Proceedings of the 35th Hawaii International Conference
on System Sciences, 2002.
[Al-Mashari, 2001]
M.Al-Mashari. “Process Orientation Through Enterprise Resource Planning (ERP): A
Review of Critical Issues”. En Knowledge and Process Management, vol.8, n.3, pp.175185, 2001.
[Anderson et alt., 1987]
J.R.Anderson et alt. “Cognitive principles in the design of computer tutors”. En
Modeling Congnition. P.Morris (ed.), pp.93-134. New York: Wiley, 1987.
- 357 -
6. Bibliografía
[Anderson y Reiser, 1985]
J.R.Anderson y B.J.Reiser. “The LISP tutor”. Byte, n.10, pp.159-175, 1985.
[Andreu y Ciborra, 1996]
R.Andreu y C.Ciborra. “Organisational Learning and Core Capabilities Development:
The Role of IT”. En Journal of Strategic Information Systems, n. 5(2), pp. 111-127.
Elsevier Science BV, 1996.
[Arrow, 1974]
K.J.Arrow. “The Limits of Organization”. New York: W.W. Norton & Co., Inc., 1974.
[Bagchi et alt., 2003]
S.Bagchi et alt. “Modeling use of enterprise resource planning systems: a path analytic
study”. En European Journal of Information Systems, n.12, pp.142–158, 2003.
[Barr y Feigenbaum, 1981]
A.Barr y E.A.Feigenbaum. “The Handbook of Artificial Intelligence”. Vol. 1, 2 y 3. Los
Altos, CA: William Kaufmann, 1981.
[Batman, 1999]
J.Batman. “Characteristics of an Organization with Mature Architecture Practices.”
[online]. En Essays on Software Architecture of Software Engineering Institute.
Carnegie Mellon University, 1999. [Consulta: 27 noviembre 2005].
http//www.sei.cmu.edu/architecture/essays.html.
[Benavente, 1992]
M.Benavente. “Las tecnologías de la información y su impacto en las PYMES:
comportamiento y tipología de empresas”. Madrid: Ed. Fundesco, 1992.
[Berg et alt., 1997]
T.Berg et alt. “Next Generation Enterprise Applications”. Gartner Group (ed.).
Documento R-ITD-117, 1997.
[Booch et alt., 1999]
G.Booch et alt. “The UML Modeling Language User Guide”. Boston, MA.: AddisonWesley, 1999.
[Brandt, 2005]
W.Brandt. “Innovation and Growth in Enterprise Application Software”. En CSFB
European Technology Conference 2005. Barcelona, 2005.
[Brusilovsky, 1993]
P.Brusilovsky. “Student as user: Towards an adaptative interface for an intelligent
learning environment”. En P.Brna, S.Ohlsson y H.Pain (eds.) Proceedings of the AIED’93 , World Conference on Artificial Intelligent in Education. AACE,
Charlottesville, pp.386-393, 1993.
[Brusilovsky, 1997]
P.Brusilovsky. “Integrating hypermedia and intelligent tutoring technologies: from
systems to authoring tools”. En P.Kommers, A.Dovgiallo, V.Petrushin y P.Brusilovsky
358
6. Bibliografía
(eds.) New media and telematic technologies for education in Eastern European
countries, Twente University Press, Enschede, pp.129-140, 1997.
[Brusilovsky, 1999]
P.Brusilovsky. “Adaptive and Intelligent Technologies for Web-based Education”. En
C.Rollinger y C.Peylo (eds.) Künstliche Intelligenz, Special Issue on Intelligent
Systems and Teleteaching, n.4, pp.19-25, 1999.
[Brusilovsky, 2003]
P.Brusilowsky. “Adaptive Navigation Support in Educational Hypermedia: the Role of
Student Knowledge Level and the Case for Meta-Adaptation”. En British Journal of
Educational Technology, vol.34, issue 4, pp. 487, 2003.
[Brusilovsky, 2004]
P.Brusilovsky. “Adaptive Help Systems”. En W. S. Bainbridge (ed.) Berkshire
Encyclopedia of Human-Computer Interaction. Great Barrington, MA: Berkshire
Publishing Group, 2004.
[Brusilovsky et alt., 1996]
P.Brusilovsky et alt. “ELM-ART: An intelligent tutoring system on World Wide Web”.
En C.Frasson, G.Gauthier and A.Lesgold (eds.) Intelligent Tutoring Systems. Lecture
Notes in Computer Science, 1086, (Proceedings of Third International Conference on
Intelligent Tutoring Systems, ITS-96, Montreal), pp.261-269. Berlin: Springer Verlag,
1996.
[Brusilovsky y Schwarz, 1997]
P.Brusilovsky y E.Schwarz. “User as student: Towards an adaptive interface for
advanced web-based applications”. En Proceedings of the Sixth International
Conference on User Modeling, UM97, Sardinia, Italy, 1997.
[Buchanan, 2002]
G.B.Buchanan. “Brief history of Artificial Intelligence” [on-line]. University of
Pittsburgh, 2002. [Consulta: 31 septiembre 2004]. http://www.aaai.org/Pathfinder/
bbhist.html
[Burns y Stalker, 1961]
T.Burns y M.Stalker. “The Management of Innovation”. London: Tavistock, 1961.
[Caldwell y Clarkson, 2000]
N.CaldWell y J.Clarkson. “Web-Based Knowledge Management for Distributed
Desing”. En IEEE Intelligent Systems, pp.40-47, mayo-junio, 2000.
[Calamandrei, 1998]
D.Calamandrei. “Organizzarsi per la globalità- Atteggiamento delle imprese nella
competizione internazionale”. Milán: FrancoAngeli editore, 1998.
[Carmona et alt., 2002]
C.Carmona et alt. “An adaptive Web-based tutorial of agrarian economy”. En P.
Brusilovsky, N. Henze and E. Millán (eds.) Proceedings of Workshop on Adaptive
Systems for Web-Based Education at the 2nd International Conference on Adaptive
359
6. Bibliografía
Hypermedia and Adaptive Web-Based Systems (AH'2002) Proceedings, Málaga, Spain,
pp.57-67, 2002.
[Castells, 1998]
M.Castells. “La era de la información: Economía, sociedad y cultura”. Vol I: La
sociedad red. Madrid: Siglo XXI, 1998.
[CCE, 2000]
COMISION DE LAS COMUNIDADES EUROPEAS. “E-Learning. Concebir la
educación del futuro” [online]. Comunicación de la Comisión. Bruselas, 25 mayo 2000.
Referencia: Bruselas 25.5.2000 COM(2000) 318 Final. [Consulta: 21 octubre 2005].
http://europa.eu.int/comm/education/programmes/elearning/comes.pdf.
[Chalmeta, 1999]
R.Chalmeta. “Arquitectura de referencia para la organización integrada de la empresa”.
Castellón de la Plana: Ed. Servicio de Publicaciones de la Universidad Jaume I, 1999.
[Chandler, 1962]
A.D.Chandler. “Strategy and structure”. Cambridge: MIT Press, 1962.
[Coda, 1988]
V.Coda. “L’orientamento strategico dell’impresa”. Torino: UTET, 1988.
[Coello y Castillo, 1999]
C.A.Coello y M.G.Castillo. “Uso de Técnicas de Inteligencia Artificial para
Aplicaciones Financieras”. En Soluciones Avanzadas. Tecnologías de Información y
strategias de Negocios, año 7, n.75, pp.16-20, 1999.
[Coughlin, 2005]
M.Coughlin. “IDC's Worldwide Services Taxonomy”. Documento #32904 del área
Industry Development and Models. IDC, 2005.
[Cox, 1996]
E.Cox. “A Fuzzy System for Detecting Anomalous Behaviors in Healthcare Provider
Claims”. En Intelligent Systems for Finance and Business, pp. 111-134, John Wiley y
Sons, 1996.
?Cuena, 1997]
J.Cuena. “Sistemas Inteligentes. Conceptos, técnicas y métodos de construcción.”.
Madrid: Servicio de publicaciones de la Facultad de Informática de la Universidad
Politécnica de Madrid, 1997.
[Davenport, 1993]
T.H.Davenport. “Process innovation”. Boston: Harvard Business Press, 1993.
[Davenport, 1998]
T.H.Davenport. “Putting the Enterprise into the Enterprise System”. En Harvard
Business Review, vol.4, n.76, pp.121-131. Harvard Business School Publishing, 1998.
360
6. Bibliografía
[Davenport, 2000]
T.H.Davenport. “Mission Critical: Realising the Promise of Enterprise Systems”.
Boston: Harvard Business School Press, 2000.
[Davenport y Prusak, 1997]
T.H.Davenport y L.Prusak. “Information ecology: Mastering the information and
knowledge environment”. London: Oxford University Press, 1997.
[Davis et alt., 1993]
Davis et alt. “What is a knowledge representation?”. En AI Magazine, n.14(1), pp.
17,33. American Association for Artificial Intelligence (AAAI), 1993.
[Dezi, 2000]
L.Dezi. “Economia e governo delle imprese. Funzioni, strumenti, tecniche”. Cedam,
2000.
[Diez, 2006]
T.I.Diez. “Un Entorno Aplicativo para Agentes Inteligentes en Manufactura Flexible”.
Tesis doctoral de la Universidad de Alcalá, 2006.
[Domingue y Motta, 2000]
J.Domingue y E.Motta. “PlanetOnto: From News Publishing to Integrated Knowledge
Management Support”. En IEEE Intelligent Systems, pp.26-31, mayo-junio, 2000.
[Dominguez, 2005]
M.J.Dominguez. “LKE una metodología para la adquisición del conocimiento en los
sistemas expertos”. Tesis doctoral de la Universidad de Alcalá, 2005.
[Dubois et alt., 1995]
P.Dubois et alt. “New technologies and post-taylorist regulation models. The
introduction and use of production planning systems in French, Italian and German
enterprises“. En The new division of labour, pp.287-315. New York: De Gruyter, 1995.
[Dutta y Shekhar, 1988]
S.Dutta y S.Shekhar. “Bond rating: A non-conservative application of neural networks”.
En Proceedings of the IEEE International Conference on Neural Networks, San Diego,
California,1988.
[Erlandsen y Holm, 1987]
J.Erlandsen y J.Holm. “Intelligent Help Systems,” Information and Software
Technology, vol.29, n.3, pp.115-121, 1987.
[Ernst, 1992]
D.Ernst y D.O'Connor. “Competing in the Electronics Industry. The Experience of
Newly Industrialising Economies”. En Development Centre Studies. Paris: OECD,
1992.
[Fariñas et alt., 1992]
J.C.Fariñas et alt. “La Pyme industrial en España”. Madrid: Editorial Cívitas, 1992.
361
6. Bibliografía
[Fernandez-Manjon, 2001]
B.Fernandez-Manjon. “Sistemas de ayuda inteligente para entornos informáticos
complejos”. En Inteligencia Artificial, Revista Iberoamericana de Inteligencia Artificial,
n.12, pp.59-67, 2001.
[Fischer, 1999]
G.Fischer. “User Modeling: The Long and Winding Road”. En Proceedings of the
Seventh International Conference on User Modeling (UM99), Banff, Canada, pp.20-24,
1999.
[Fischer et alt, 1985]
G.Fischer et alt. “Knowledge-based Help Systems”. En Proceedings of the CHI85
Conference on Human Factors in Computing Systems, pp.161-167, 1985.
[Ford, 1987]
L.Ford. “Teaching strategies and tactics in intelligent computer aided instructions”. En
Artificial Intelligence, review 1, pp.201-215, 1987.
[Fowler, 2000]
A.Fowler. “The role of AI-based technology in support of the knowledge management
value activity cycle”. En The Journal of Strategic Information Systems, n.9(2-3),
pp.107-128, 2000.
[Gailbraith, 1973]
J.R.Galbraith. “Designing Complex Organizations”. Reading, MA: Addison-Wesley,
1973.
[Giachetti et alt, 2004]
R.E.Giachetti et alt. “A Research Framework for Operationalizing Measures of
Enterprise Integration” [on-line]. Presentación de: 2004 International Conference on
Enterprise Integration and Modelling Technology (ICEIMT'04). Universidad de
Toronto,
Canada.
Octubre,
2004.
[Consulta:
16
septiembre
2005].
http://www.eil.utoronto.ca/ICEIMT04/program.html.
[Giarretano, 1989]
J.Giarretano. “Expert Systems: Principles and Programming”. Boston: PWS-Kent
Publishing Company, 1989.
[Goldberg et alt., 2003]
H.Goldberg et alt. “The NASD Securities Observation, News Analysis and Regulation
System (SONAR)”. En Proceedings of The Fifteenth Annual Conference on Innovative
Applications of Artificial Intelligence (IAAI03), 2003.
[Goonatilake, 1996]
S.Goonatilake. “Intelligent Systems for Finance and Business: An Overview”. En
Intelligent Systems for Finance and Business, pp.1-28, John Wiley y Sons, 1996.
362
6. Bibliografía
[Granlund y Malmi, 2002]
M.Granlund y T.Malmi. “Moderate impact of ERPS on management accounting: a lag
or permanent outcoming?”. En Management Accounting Research, vol.13, n.3, pp.299231. Academic Press, 2002.
[Guida y Tasso, 1994]
G. Guida y C.Tasso. “Design and Development of Knowledge Based Systems”.
England: John Wiley & Sons, 1994.
[Harmon y King, 1988]
P.Harmon y D.King. “Sistemas expertos. Aplicaciones de la Inteligencia Artificial a la
actividad empresarial”. Madrid: Díaz de Santos, 1988.
[Hayes-Roth, 1994]
F.Hayes-Roth. “Architecture-based acquisition and development of software:
Guidelines and recommendations from the ARPA Domain-Specific Software
Architecture (DSSA) program”. Palo Alto: Teknowledge Federal Systems, 1994.
[Hecking et alt., 1988]
M.Hecking et alt. “The Sinix Consultant - A progress report”. Memo n.28, University of
Saarlndes, Saarbrücken, Alemania, 1988.
[Hedman y Kalling, 2002]
J.Hedman y T.Kalling. “IT and Business Models”. Malmö, Suecia: Liber, 2002.
[Herrera et alt., 2003]
F.Herrera et alt. “A Linguistic Decision Process for Evaluating the Installation of an
ERP System”. En Proceedings of 9th International Conference on Fuzzy Theory and
Technology, Florida, EEUU, pp. 164-167, 2003.
[Hickman et alt., 1989]
F.Hickman et alt. “Analysis for Knowledge-Based Systems: A Practical Guide to the
KADS Methodology”. England: Ellis Horwood, 1989.
[Hitt, 1999]
L.M.Hitt. “Information technology and firm boundaries: Evidence from panel data”. En
Information Systems Research, n.10(2), pp.134–149, 1999.
[Holder, 1994]
V.Holder. “Tackling insider dealing with fuzzy logic”. En Financial Times, n.29, 1994.
[IEEE, 2001]
IEEE P1484.1/D9 2001-11-30. “Draft Standard for Learning Technology — Learning
Technology Systems Architecture (LTSA)”, 2001.
[IMAGINATION ENGINES, 2002]
IMAGINATION ENGINES. “IEI's Patented Creativity Machine Paradigm” [online].
IEI, 2002. [Consulta: 16 marzo 2004]. http://www.imaginationengines.com/
technologies/cm.htm.
363
6. Bibliografía
[INTERTEK GROUP, 1995]
INTERTEK GROUP. “Adaptive Computational Methods in Retail Banking and
Finance”. En Proceedings of Parallel Applications in Statistics and Economics
(PASE95), 1995.
[Jackson, 1990]
P.Jackson. “Introduction to Expert Systems”. Massachusetts: Addison-Wesley, 1990.
[Jones y Virnou, 1991]
J.Jones y M.Virnou. “User modelling and advice giving in intelligent help system for
Unix”. En Information and Software Technology, vol.3, n.2, pp.121-133, 1991.
[Jorgensen, 2003]
H.D.Jorgensen. “Formal Process Modelling”. Trondheim: Norwegian University of
Science and Technology, 2003.
[Kahn, 1991]
B.Kahn. “Os computadores no ensino da ciencia.”. Publicaçoes Dom Quixote, 1991.
[Kay, 2001]
A.Kay. “Artificial Neural Networks”. En Framingham US Computer world, vol.35, n.7,
pp. 60, 2001
[Kéller et alt., 1992]
G.Keller et alt. “Semantische Processmodellierung auf der Grundlage
Ereignisgesteuerter Processketten (EPK)”. Ver öffentlichungen des Instituts für
Wirtschaftsinformatik, Heft 89. Saarbrücken: University of Saarland, 1992.
[Kingston, 1994]
J.Kingston. “Linking Knowledge Acquisition with CommonKADS Knowledge
Representation”. Technical report AIAI-TR-156, Artificial Intelligence Applications
Institute, University of Edinburgh, 1994.
[Klaus et alt., 2000]
H.Klaus et alt. “What is ERP?”. En Information Systems Frontiers, vol.2, n.2, pp.142162, 2000.
[Kremer, 2001]
R.Kremer. “Artificial Intelligence” [online]. University of Calgary, 2001. [Consulta: 25
octubre 2005]. http://sern.ucalgary.ca/courses/CPSC/533/W99/intro/tsld024.htm.
[Llata et alt., 2000]
J.R.Llata et alt. “Aplicación de Inteligencia Artificial en Sistemas Automatizados de
Producción“. En Revista Iberoamericana de Inteligencia Artificial, n.10, pp100-110,
2000.
[Lowrence y Lorsch, 1967]
P.R.Lawrence y J.W.Lorsch. “Organization and Environment”. Boston: Graduate
School of Business Adrninistration, Harvard University, 1967.
364
6. Bibliografía
[Lozano y Fuentes, 2004]
M.C.Lozano y F.Fuentes. “La Inteligencia Artificial aplicada a la toma de decisiones en
la Empresa de Internet”. En Documentos de Trabajo en Análisis Económico, vol.3,
n.10, 2004.
[Mahdjoubi, 1997]
D.Mahdjoubi. “The Matrix Taxonomy for Industrial Classification Systems” [on-line].
[Consulta: 9 enero 2005]. http://www.gslis.utexas.edu/~darius/mtx_tax/mtx_tax.html.
[Malerba y Orsenigo, 1995]
F.Malerba y L.Orsenigo. “Schumpeterian patterns of innovation”. En Cambridge
Journal of Economics, n.19, pp. 47-75. Oxford: Oxford University Press, 1995.
[Markus et alt., 2001]
M.L.Markus et alt. “Learning from adopters’ experiences with ERP: problems
encountered and success achieved”. En Enterprise Systems: ERP Implementation and
Effectiveness, 2001.
[Markus y Tanis, 2000]
M.L.Markus y C.Tanis. “The Enterprise System Experience – From Adoption to
Success”. En Framing the Domains of IT Research: Glimpsing the Future Through the
Past, pp.173-207. Cincinnati, OH: Pinnaflex Educational Resources, 2000.
[Marchionini, 1995]
G.Marchionini. “Information Seeking in Electronic Enviroments”. Cambridge:
Cambridge University Press, 1995.
[Martínez, 2004]
J.J.Martínez. “Propuesta arquitectural y metodológica para la integración de un módulo
inteligente de tutorización en sistemas de aprendizaje basados en Internet”. Tesis
doctoral de la Universidad de Alcalá, 2004.
[McArthhur et alt., 1990]
D.McArthur et alt. “Tutoring techniques in algebra”. En Cognition and Instruction,
vol.7, n.3, pp.197-244, 1990.
[McKelvey, 1982]
B.McKelvey. “Organizational Systematics”. Berkeley (CA): University of California
Press, 1982.
[McNeil y Freiberger, 1993]
D.McNeil y P.Freiberger. “Fuzzy Logic”. New York: Simon y Schuster, 1993.
[MICROSOFT, 2001]
MICROSOFT. “La integración empresarial de la nueva generación: ventajas de
Microsoft .NET” [on-line]. Recursos de negocio de microsoft.com. [Consulta: 13
octubre 2005]. http://www.microsoft.com/latam/net/business/nextgenbiz.asp.
[Mintzberg, 1995]
H.Mintzberg. “La estructuración de las organizaciones”. Barcelona: Ariel, 1995.
365
6. Bibliografía
[Mucelli, 2000]
A. Mucelli. “I sistemi informativi integrati per il controllo dei processi aziendali”.
Torino: Giappichelli Editore, 2000.
[NAICS, 2002]
U.S. Executive Office of the President: Office of Management and Budget. “North
American industry classification system, United States, 2002”. Washington, DC:
Bernan Press, 2002.
[Nakabayashi et alt., 1997]
K.Nakabayashi et alt. “Architecture of an intelligent tutoring system on the WWW”. En
B.d.Boulay y R.Mizoguchi (eds.) Artificial Intelligence in Education: Knowledge and
Media in Learning Systems. (Proceedings of AI-ED'97, World Conference on Artificial
Intelligence in Education, Kobe, Japan, Amsterdam: IOS), pp.39-46, 1997.
[Nelson y Winter, 1982]
R.Nelson y S.Winter. “An Evolutionary Theory of Organizations”. Cambridge, MA:
Harvard University Press, 1982.
[Nezami, 1997]
R.Nezami. “General Analysis and Design of the Intelligent Tutoring Systems” [online].
1997. [Consulta: 16 diciembre 2005]. http://www.cs.unb.ca/grads/a9sj/ITS.html.
[Nicolussi y Grontzki, 2005]
A.Nicolussi y S.Grontzki “DB2 Intelligent Miner: Comprehensive Guide to IBM DB2
Intelligent Miner, Version 8.2 [on-line]. IBM, 2005. [Consulta: 23 de noviembre de
2005]. http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0506nico
lussi/index.html
?Nilsson, 1971]
N.Nilsson. “Principles of Artificial Intelligence”. Nueva York: McGraw-Hill, 1971.
[Nordlander, 2001]
T.E.Nordlander. “AI Surveying: Artificial Intelligence in Business”. Masters Thesis, De
Montfort University , 2001.
[O´Leary, 2000]
D.E.O´Leary. “Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic
Commerce and Risk”. Cambridge: Cambridge University Press, 2000.
[Ohlsson, 1991]
S.Ohlsson. “System hacking meets learning theory: Reflections on the goals and
standards of research in artificial intelligence and education.”. En Journal of Artificial
Intelligence and Education, vol.2, n.3, pp.5-18, 1991.
[Okazaki et alt., 1997]
Y.Okazaki et alt. “An Implementation of the WWW Based ITS for Guiding Differential
Calculations”. En P.Brusilovsky, K.Nakabayashi y S.Ritter (eds.) Proceedings of
Workshop Intelligent Educational Systems on the World Wide Web at AI-ED'97, 8th
366
6. Bibliografía
World Conference on Artificial Intelligence in Education, Kobe, Japan, ISIR, pp.18-25,
1997.
[Pagés et alt., 2005]
C.Pagés et alt. “Metodología de creación de contenidos docentes en un Sistema
Inteligente de Tutorización Avanzada (SITA)”. En Revista Iberoamericana de Sistemas,
Cibernética e Informática, vol.1, n.2, 2005.
[Pagés et alt., 2004]
C.Pagés et alt. “Sistema Inteligente de Tutorización Avanzada (SITA). Un caso de
aplicación: GEKA”. En Actas del I Simposio Pluridisciplinar sobre Diseño, Evaluación
y Descripción de Contenidos Didácticos Reutilizables (SPDECE 2004), n.35, 2004.
[Panati y Golinelli, 1994]
G.Panati y G.M.Golinelli. “Tecnica economica industriale e commerciale: imprese
strategie e management”. Roma: La Nuova Italia Scientifica, 1994.
[Panczyk, 1999]
T.D.PanczyK. “A smart choice for collectors?”. En Credit Card Management, vol.11,
n.12, pp.78-83, 1999.
[Parson, 2004]
R.Parson. “Inductive Logic Programming iHex™ Discovery: An Overview” [on-line].
Future Route Limited, 2004. [Consulta: 15 de enero de 2006].
http://www.futureroute.co.uk/download/white_papers/ihexdiscovery.pdf.
?Pazos et alt., 1997]
J.Pazos, A.Gomez., N.Juristo y C.Montes. “Ingeniería del Conocimiento.”. Madrid:
Editorial Centro de Estudios Ramón Areces S.A, 1997.
[Pavitt, 1984]
K.Pavitt. “Sectoral patterns of technical change: towards a taxonomy and a theory”. En
Research Policy, n.13 (6), pp.343-373. Amsterdam: Elsevier Science Publishers B.V.,
1984.
[Peña et alt., 2002]
I.Peña et alt. “Un sistema de tutoría inteligente adaptativo considerando estilos de
aprendizaje”. En Proceedings of 6 Congreso Iberoamericano, 4 Simposio Internacional
de Informática Educativa, 7 Taller Internacional de Software Educativo (IE2002), Vigo
(España), 2002.
[Pfeffer y Salancik, 1978]
J.Pfeffer y G.R.Salancik. “The External Control of Organizations: A Resource
Dependence Perspective”. New York: Harper & Row, 1978.
[Pivato y Gilardoni, 2000]
S.Pivato y A.Gilardoni. “Elementi di economia e gestione delle imprese”.Milano: Egea,
2000.
367
6. Bibliografía
[Resnick, 1998]
M.Resnick. “Trutles, Termites and Traffic Jams”. MIT Press, 1998.
[Rich y Knight, 1991]
E.Rich y K.Knight. “Artificial Intelligence”. Londres: McGraw-Hill, 1991.
[Rickel et alt., 2000]
J.Rickel et alt. “Task-Oriented Tutorial Dialogue: Issues and Agents”. En AAAI Fall
Symposium on Building Dialogue Systems for Tutorial Applications, Technical Report
FS-00-01, pp.52-57, 2000.
[Rifkin, 2000]
J.Rifkin. “L’era dell’accesso”. Milano: Mondadori, 2000.
[Ritter, 1997]
S.Ritter. “Pat Online: A Model-tracing tutor on the World-wide Web”. En
P.Brusilovsky, K.Nakabayashi y S.Ritter (eds.) Proceedings of Workshop Intelligent
Educational Systems on the World Wide Web at AI-ED'97, 8th World Conference on
Artificial Intelligence in Education, Kobe, Japan, ISIR, pp.1-17, 1997.
[Rodríguez, 2000]
M.Rodríguez. “Una Arquitectura congnitiva para el diseño de entornos telemáticos de
enseñanza y aprendizaje”. Tesis Doctoral de la Escuela Técnica Superior de Ingenieros
Industriales, UNED, 2000.
[Rodríguez de Rivera, 2000]
J.Rodríguez de Rivera. “Epistemología o Teoría de la Ciencia y Reflexión Crítica sobre
los Fundamentos de las Ciencias de la Organización (en cuanto ciencias sociales)”. [online].
[Consulta:
18
noviembre
2005].
Universidad
de
Alcalá.
http://www2.uah.es/estudios_de_organizacion/epistemologia/epistemologia_inicio.htm.
[Ross y Vitale, 2000]
W.R.Ross y M.R.Vitale. “The ERP Revolution: Surviving Versus thriving”. En
Information Systems Frontier, n.2(2), pp.233-241, 2000.
[Ruffino et alt, 2003]
M.Ruffino et alt. “Competency Needs Induced by Production Model Innovation: the
starting point of BATCOS project”. En Proceedings of ICETA Conference 2003.
Kosice, Eslovaquia. Octubre, 2003.
[Sanchez et alt., 2005]
P.J.Sanchez et alt. “A Fuzzy Model to Evaluate the Suitability of Installing an ERP
System”.
En
Information
Sciences
(to
appear).
Disponible
en
http://decsai.ugr.es/~viedma/public.html. Consulta 18-01-2006.
[SAP, 2002]
SAP. “Anual Report 2002”. [on-line]. [Consulta: 18 diciembre
http://www.sap.com/company/investor/reports/annualreport/2002/index.epx.
368
2004].
6. Bibliografía
[Scheer, 1992]
A.Scheer. “Architecture of integrated information systems systems - bases for company
modeling”. Berlin: Springer,1992.
[Scheer y Habermann, 2000]
A.W.Scheer y F.Habermann. “Making ERP a Success”. En Communication of the
Association for Computing Machinery, vol.43, n.4, pp.57-61, 2000
[Scherer y Ross, 1990]
F.M.Scherer y D.Ross. “Industrial Market Structure and Economic Performance”.
Boston: Houghton Mifflin, 1990.
[Schofield et alt., 1990]
J.W.Schofield et alt. “Artificial Intelligence in the Classroom: The Impact of a
Computer-based Tutor on Teachers and Students”. En Social Science Computer
Review, vol.8, n.1, pp.24-41, 1990.
[Segura et alt., 1992]
J.Segura et alt. “Un panorama de la industria española”. Madrid: Ministerio de Industria
y Energía, 1992.
[Self, 1994]
J.Self. “The role of student models in learning environments”. En Transactions of the
Institute of Electronics, Information and Communication Engineers, E77-D(1), pp.3-8,
1994
[Shapiro, 1992]
S.C.Shapiro. “Encyclopedia of Artificial Intelligence”. New York: Wiley, 1992.
[Shaw et alt., 1996]
M.Shaw y D.Garlan. “Software Architecture: Perspectives on an Emerging Discipline”.
New Jersey: Prentice Hall, 1996.
[Shell, 1990]
C.Sheel. “Ingeniería de Sistemas Basados en Conocimientos”. México: Instituto
Tecnológico y de Estudios Superiores de Monterrey, 1990.
[Silber, 1990]
J.Silber. “PAL: an intelligent help system”. En Proceedings of the third international
conference on Industrial and engineering applications of artificial intelligence and
expert systems, vol. 2, 1990.
[Sloman y Logan, 1999]
A.Sloman y B.Logan. “Building cognitively rich agents using the SIM_agent toolkit”.
En Association for Computing Machinery, vol.42, n.3, pp.8, 1999.
[Söderström et alt., 2002]
E.Söderstrom et alt. “Towards a Framework for Comparing Process Modelling
Languages”. En Proceedings of the 14th International Conference on Advanced
369
6. Bibliografía
Information Systems Engineering (CAiSE), vol. 2348 of Lecture Notes in Computer
Science, pp.600-611, 2002.
[Soh et alt., 2000]
C.Soh et alt. “Cultural Fits and Misfits: Is ERP a Universal Solution?”. En
Communications of the Association for Computing Machinery, vol.43, n.4, 2000
[Soller, 2001]
A.L.Soller. “Supporting Social Interaction in an Intelligent Collaborative Learning
System”. En International Journal of Artificial Intelligence in Education, n.12, pp.4062, 2001.
[Sprott, 2000]
D.Sprott. “Componentizing the enterprise application packages.” En Communications
of the ACM, n.43(4), pp.63-69, 2000.
[STANDARD AND POOR, 2004]
STANDARD AND POOR. “S&P's The Outlook”. Browse Outlook Issues of S&P's The
Outlook, 2004.
[Sturdza et alt., 2002]
P.Sturdza et alt. “An intelligent tutoring e-learning for training archivist”. En Actas del
DLM-Forum 2002. Barcelona, 6-8 mayo 2002.
[Suthers y Jones, 1997]
D.Suthers y D.Jones. “An architecture for intelligent collaborative educational
systems”. En Artificial Intelligence in Education: Knowledge and Media in Learning
Systems. (Proceedings of AI-ED'97, 8th World Conference on Artificial Intelligence in
Education, Kobe, Japan) Amsterdam: IOS, pp.55-62, 1997.
[Utterback, 1982]
J.M.Utterback. “Patterns of Industrial Innovation”. En Readings in the Management of
Technology, pp.97-108. Cambridge: Ballinger, 1982.
[Waltz, 1997]
D.L.Waltz. “Artificial Intelligence: Realizing the Ultimate Promises of Computing”. En
AI Magazine, n.18(3), pp.49-52, 1997.
[Warendorf y Tan, 1997]
K.Warendorf y C.Tan. “ADIS - An animated data structure intelligent tutoring system
or Putting an interactive tutor on the WWW”. En P.Brusilovsky, K.Nakabayashi y
S.Ritter (eds.) Proceedings of Workshop Intelligent Educational Systems on the World
Wide Web at AI-ED'97, 8th World Conference on Artificial Intelligence in Education,
Kobe, Japan, ISIR, pp.54-60,1997.
[Waterman, 1986]
D.Waterman. “A Guide to Expert Systems”. USA: Addsison-Wesley Publishing
Company, 1986.
370
6. Bibliografía
[Wilensky et alt., 1989]
R.Wilensky et alt. “The Berkeley Unix Consultant Project”. Informe técnico
UCB//CSD-89-520. University of California, Berkeley, USA, 1989.
[Williams, 2001]
F.Williams. “Artificial Intelligence has small but loyal following”. En Pensions and
Investments, vol.29, n.10, pp.4-124, 2001.
[Winkels y Breuker, 1992]
R.Winkels y J.Breuker. “What´s in n ITS? A functional descomposition”. En New
Directions for Intelligent Tutoring Systems, vol.91, pp.57-68. Berlin: Springer-Verlag,
1992.
[Winston, 1992]
P.Winston. “Artificial Intelligence”. Massachusetts: Addison-Wesley, 1992.
[Woodward, 1958]
J.Woodward. “Management and Technology”. London: H.M.S.O, 1958.
[Yen y Chou, 2001]
D.C.Yen y D.C.Chou. “Intranets for Organizational Innovation”. En Information
Management and Computer Security, vol.9, n.2, pp.80-87, 2001.
[Yen et alt., 2002]
D.C.Yen et alt. “A synergic analysis for web-based Enterprise Resource Planning
Systems”. En Computer Standards and Interfaces, n.24, pp.337-346, 2002.
[Zissos y Witten, 1985]
A.Y.Zissos y I.H.Witten. “User modelling for a computer coach: a case study”. En Int.
J. Man-Machine Studies, vol. 23, pp.729-750, 1985.
371
6. Bibliografía
372
ANEXO I – EJEMPLOS CONOCIMIENTO DEL
DOMINIO
Este anexo presenta algunos ejemplos de elementos obtenidos durante la obtención
del conocimiento del dominio del prototipo construido en el Capítulo 4:
1. Ejemplo de diagrama EPC estructurado para su conversión automática;
2. Ejemplo de formateo de un diagrama EPC mediante XML;
3. Ejemplo de documentación asociada a un elemento de conocimiento;
4. Ejemplo de programa de batch input (carga de transacciones) para SAP R/·3;
5. Ejemplo de pantalla de parametrización de SAP R/3 con valores actualizados.
- 373 -
Anexo I
1. Ejemplo de diagrama EPC estructurado para su conversión automática.
¿Política =
cantidad fija?
Definición de
cantidad
Cantidad
¿ Política =
semana fija?
Definición de
semanas
Semanas
¿ Política =
mes fijo?
Definición de
meses
Meses
XOR
Tipo de política
Selección de
política
Selección de
datos asociados
¿Elegir política?
¿Elegir
datos
asociados?
Selección de
modificadores
Cant.máxima
Cant.mínima
¿Elegir
modificadores?
AND
Parametrización
política de
orden
El diagrama anterior muestra como se simplifican las relaciones entre dos conectores
lógicos, partiendo del diagrama EPC número 14 desarrollado durante la obtención del
conocimiento del dominio del prototipo en el Capítulo 4. Para ello se utiliza el criterio
de simplificación definido en las fases metodológicas del Capítulo 3, que evita las
relaciones directas entre conectores lógicos, creando para ello una función de salida del
primer conector que identifica la actividad resultante de las que relaciona el conector.
2. Ejemplo de formateo de un diagrama EPC mediante XML
<modelo id = “msap000001”>
<nombre = “modelo subdominio planificación gestión de materiales” />
<epc id = “esap000014”>
<nombre = “epc-parametrización política de orden” />
<evento id = “csap000047”
<nombre = “¿Elegir política?” />
</evento>
<evento id = “csap000048”>
<nombre = “¿Elegir datos asociados?” />
</evento>
<evento id = “csap000049”>
374
Anexo I
<nombre = “¿Elegir modificadores?” />
</evento>
<evento id = “csap000050”>
<nombre = “¿Política = cantidad fija?” />
</evento>
<evento id = “csap000051”>
<nombre = “¿Política = semana fija?” />
</evento>
<evento id = “csap000052”>
<nombre = “¿Política = mes fijo?” />
</evento>
<proceso id = “asap000031”>
<nombre = “parametrización política de orden” />
</proceso>
<funcion id = “asap000034”>
<nombre = “Selección de política” />
</funcion>
<funcion id = “asap000035”>
<nombre = “Selección de datos asociados” />
</funcion>
<funcion id = “asap000036”>
<nombre = “Selección de modificadores” />
</funcion>
<funcion id = “asap000037”>
<nombre = “Definición de cantidad” />
</funcion>
<funcion id = “asap000038”>
<nombre = “Definición de semanas” />
</funcion>
<funcion id = “asap000039”>
<nombre = “Definición de meses” />
</funcion>
<objeto_informacion id = “dsap000015”>
<nombre = “Tipo de política” />
<contenido
=
“C:/mySAPR3/Parametrizacion/Planificacion_
necesidades/Tipo_política.pdf“ />
</objeto_informacion>
<objeto_informacion id = “dsap000016”>
<nombre = “Cant.maxima_Cant.minima_Cant.multipla” />
<contenido
=
“C:/mySAPR3/Parametrizacion/Planificacion_
necesidades/Modificadores_política.pdf“ />
</objeto_informacion>
<objeto_informacion id = “dsap000017”>
375
Anexo I
<nombre = “Cantidad” />
<contenido
=
“C:/mySAPR3/Parametrizacion/Planificacion_
necesidades/Cantidad_política.pdf“ />
</objeto_informacion>
<objeto_informacion id = “dsap000018”>
<nombre = “Semanas” />
<contenido
=
“C:/mySAPR3/Parametrizacion/Planificacion_
necesidades/Semanas_política.pdf“ />
</objeto_informacion>
<objeto_informacion id = “dsap000019”>
<nombre = “Meses” />
<contenido
=
“C:/mySAPR3/Parametrizacion/Planificacion_
necesidades/Meses_política.pdf“ />
</objeto_informacion>
<and id = “rsap000019”>
<nombre = “and7” />
<entrada_id = “csap000047” />
<entrada_id = “csap000048” />
<entrada_id = “csap000049” />
<salida_id = “asap000031” />
<sec_ent = “ordenado” />
<sec_sal = “no_ordenado” / >
</and>
<xor id = “rsap000020”>
<nombre = “xor9” />
<entrada_id = “csap000050” />
<entrada_id = “csap000051” />
<entrada_id = “csap000052” />
<salida_id = “asap000035” />
<sec_ent = “no_ordenado” />
<sec_sal = “no_ordenado” />
</xor>
<conexión_cond id = “xsap000048”>
<nombre = “conexión_cond48” />
<entrada_id = “asap000034” />
<salida_id = “csap000047” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_cond id = “xsap000049”>
<nombre = “conexión_cond49” />
<entrada_id = “asap000035” />
<salida_id = “csap000048” />
<tipo = “poscondicion” />
376
Anexo I
</conexión_cond>
<conexión_cond id = “xsap000050”>
<nombre = “conexión_cond50” />
<entrada_id = “asap000036” />
<salida_id = “csap000049” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_cond id = “xsap000051”>
<nombre = “conexión_cond51” />
<entrada_id = “asap000037” />
<salida_id = “csap000050” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_cond id = “xsap000052”>
<nombre = “conexión_cond52” />
<entrada_id = “asap000038” />
<salida_id = “csap000051” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_cond id = “xsap000053”>
<nombre = “conexión_cond53” />
<entrada_id = “asap000039” />
<salida_id = “csap000052” />
<tipo = “poscondicion” />
</conexión_cond>
<conexión_infor id = “isap000018”>
<nombre = “conexión_infor18” />
<entrada_id = “dsap000015” />
<salida_id = “asap000034” />
</conexión_infor>
<conexión_infor id = “isap000019”>
<nombre = “conexión_infor19” />
<entrada_id = “dsap000016” />
<salida_id = “asap000036” />
</conexión_infor>
<conexión_infor id = “isap000020”>
<nombre = “conexión_infor20” />
<entrada_id = “dsap000017” />
<salida_id = “asap000037” />
</conexión_infor>
<conexión_infor id = “isap000021”>
<nombre = “conexión_infor21” />
<entrada_id = “dsap000018” />
377
Anexo I
<salida_id = “asap000038” />
</conexión_infor>
<conexión_infor id = “isap000022”>
<nombre = “conexión_infor22” />
<entrada_id = “dsap000019” />
<salida_id = “asap000039” />
</conexión_infor>
</epc>
</modelo>
Ele ejemplo anterior muestra la traducción a lenguaje XML del diagrama EPC
presentado anteriormente como ejemplo en este anexo. Para ello se ha utilizado la
metodología definida en las fases metodológicas del Capítulo 3.
3. Ejemplo de documentación asociada a un elemento de conocimiento;
La siguiente pantalla muestra un ejemplo de información asociada a una actividad, en
este caso la actividad asap000005 (Codificación de artículos) en la que hay que definir
los parámetros: longitud número de material, patrón para conversión de números de
material e indicador para números interno o externo
378
Anexo I
Otro ejemplo, en este caso de información asociada a un parámetro utilizado en la
actividad anterior (patrón para conversión de números de material), lo muestra la
pantalla siguiente:
379
Anexo I
4. Ejemplo de programa de batch input (carga de transacciones) para SAP R/·3.
A continuación se muestra la pantalla de SAP R/3 correspondiente a la grabación del
batch-input de la transacción OPPR (Modificar vista de compensación: detalle):
Realizando una exportación de dicha grabación obtenemos el siguiente código:
SAPMM61C
SAPMM61C
SAPMM61C
SAPL0PP2
SAPLSTRD
SAPL0PP2
0300
0340
0400
0021
0300
0020
T
X
OPPR
BS AA X F
BDC_CURSOR
BDC_OKCODE
RM61C-WERKS
RM61C-WERKS
=DUPD
0001
BDC_CURSOR
BDC_OKCODE
RM61C-MTART
RM61C-MTART
=DUPD
0001
BDC_CURSOR
BDC_OKCODE
RM61C-GRTXT
RM61C-GRTXT
=DG03
Politica ATO
BDC_CURSOR
BDC_OKCODE
V_T438M_V-VRMOD
V_T438M_V-VINT1
V_T438M_V-VINT2
V_T438M_V-VINT2
=SAVE
2
30
30
BDC_CURSOR
BDC_OKCODE
KO008-TRKORR
KO008-TRKORR
=LOCK
NARK900008
BDC_CURSOR
V_T438M_V-WERKS(01)
X
X
X
X
X
380
Anexo I
SAPMM61C
SAPMM61C
0400
0300
BDC_OKCODE
=BACK
BDC_CURSOR
BDC_OKCODE
RM61C-GRTXT
RM61C-GRTXT
=BACK
Politica ATO
BDC_CURSOR
BDC_OKCODE
RM61C-WERKS
RM61C-WERKS
=BACK
0001
X
X
Hemos marcado los valores que son introducidos a través de la parametrización
realizada por nuestro prototipo: modo de compensación (2), intervalo compensación
hacia atrás en política adelante/atrás (30) e intervalo compensación hacia adelante en
política adelante/atrás (30).
5. Ejemplo de pantalla de parametrización de SAP R/3 con valores actualizados.
A continuación se muestra la pantalla de SAP R/3 correspondiente a la
parametrización de la descripción de la Clasificación ABC:
381
Anexo I
382
ANEXO II - CONTENIDO BASE DE DATOS DEL
PROTOTIPO
Este anexo lista los diferentes datos que configuran el conocimiento del dominio del
prototipo construido en el capítulo 4.
1. Tabla de reglas.
CLV_REG
rsap000001
rsap000001
rsap000001
rsap000002
rsap000002
rsap000002
rsap000003
rsap000003
rsap000003
rsap000004
rsap000004
rsap000005
rsap000005
rsap000006
rsap000006
rsap000006
rsap000007
rsap000007
rsap000007
rsap000008
rsap000008
rsap000009
rsap000009
rsap000010
rsap000010
rsap000011
rsap000011
CLV_ACCP
asap000001
asap000001
asap000001
asap000002
asap000002
asap000002
asap000007
asap000007
asap000007
asap000008
asap000008
asap000012
asap000012
asap000010
asap000010
asap000010
asap000003
asap000003
asap000003
asap000018
asap000018
asap000019
asap000019
asap000021
asap000021
asap000020
asap000020
CLV_ACCH
asap000002
asap000003
asap000004
asap000005
asap000006
asap000007
asap000008
asap000009
asap000010
asap000011
asap000012
asap000008
asap000013
asap000014
asap000015
asap000016
asap000017
asap000018
asap000019
asap000040
asap000020
asap000021
asap000020
asap000041
asap000042
asap000026
asap000027
CONECTOR
AND
AND
AND
AND
AND
AND
XOR
XOR
XOR
AND
AND
XOR
XOR
OR
OR
OR
XOR
XOR
XOR
AND
AND
AND
AND
XOR
XOR
XOR
XOR
- 383 -
SECUENCIA
1
2
2
1
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
2
1
2
1
1
1
1
CLV_CON
csap000002
csap000003
csap000004
csap000005
csap000006
csap000007
csap000008
csap000009
csap000010
csap000011
csap000012
csap000013
csap000014
csap000015
csap000016
csap000017
csap000018
csap000019
csap000020
csap000021
csap000022
csap000023
csap000022
csap000024
csap000025
csap000022
csap000023
Anexo II
rsap000011
rsap000012
rsap000012
rsap000013
rsap000013
rsap000014
rsap000014
rsap000015
rsap000015
rsap000015
rsap000016
rsap000016
rsap000017
rsap000017
rsap000017
rsap000018
rsap000018
rsap000018
rsap000018
rsap000019
rsap000019
rsap000019
rsap000020
rsap000020
rsap000020
rsap000021
rsap000021
rsap000022
rsap000022
asap000020
asap000044
asap000044
asap000024
asap000024
asap000025
asap000025
asap000026
asap000026
asap000026
asap000027
asap000027
asap000028
asap000028
asap000028
asap000029
asap000029
asap000029
asap000029
asap000031
asap000031
asap000031
asap000035
asap000035
asap000035
asap000004
asap000004
asap000045
asap000045
asap000028
asap000024
asap000025
asap000025
asap000025
asap000026
asap000027
asap000027
asap000027
asap000027
asap000028
asap000029
asap000029
asap000029
asap000029
asap000030
asap000031
asap000032
asap000033
asap000034
asap000035
asap000036
asap000037
asap000038
asap000039
asap000044
asap000045
asap000004
asap000046
XOR
XOR
XOR
OR
OR
XOR
XOR
OR
OR
OR
XOR
XOR
OR
OR
OR
AND
AND
AND
AND
AND
AND
AND
XOR
XOR
XOR
AND
AND
OR
OR
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
1
2
3
1
1
1
1
2
1
1
csap000043
csap000029
csap000030
csap000031
csap000032
csap000033
csap000034
csap000035
csap000036
csap000037
csap000038
csap000039
csap000040
csap000041
csap000042
csap000043
csap000044
csap000045
csap000046
csap000047
csap000048
csap000049
csap000050
csap000051
csap000052
csap000053
csap000054
csap000055
csap000056
2. Tabla de acciones.
CLV_ACC
asap000001
IDENTIF
Parametrización
planificación de
necesidades
CL.
S
DESCRIP
Conjunto de acciones encaminadas a
parametrizar el subdominio de
planificación de necesidades de material
asap000002
Parametrización datos
básicos
N
Conjunto de acciones encaminadas a
parametrizar datos básicos necesarios
para la gestión de necesidades de material
asap000003
Parametrización gestón
de la demanda
N
Conjunto de acciones encaminadas a
parametrizar los datos necesarios para la
gestión de previsiones y su consumo
asap000004
Parametrización grupos
de planificación
N
asap000005
Codificación de artículos
N
asap000006
Descripción clasificación
ABC
N
Conjunto de acciones encaminadas a
parametrizar las distintas posibilidades de
la planificación de necesidades de material
según carácterísticas de estos materiales
(grupos de planificación)
Tarea para definir el formato de
codificación de los artículos y su
asignación
Tarea para definir el significado de las
clases A, B y C
384
Anexo II
asap000007
Codificación de órdenes
N
Conjunto de acciones encaminadas a
parametrizar los rangos de los números de
orden y el criterio de clasificación
asap000008
Codificación por línea de
producto
N
Conjunto de acciones necesarias para
definir los rangos de numeración de las
órdenes por líneas diferentes de producto
asap000009
Codificación por tipo de
planificación
Codificación por tipo de
producción
N
Tarea para definir los rangos de las
órdenes de los artículos MPS y MRP
Conjunto de acciones necesarias para
definir los rangos de numeración de las
órdenes por tipos diferentes de producción
asap000011
Codificación de rago
N
asap000012
Continuación rango de
líneas
Fin codificación por
líneas
N
Establecer rango
órdenes de subcontrata
Establecer rango
órdenes de compra
Establecer rango
órdenes de fabricación
Parametrización barrera
de la demanda para
MTS
N
Parametrización política
MTO
Parametrización política
ATO
Parametrización política
de consumo
N
asap000021
Parametrización nivel de
uso de previsiones
N
Acción para seleccionar el plazo, dentro
del tiempo total del producto, de uso de las
previsiones para el consumo
asap000022
Consumo hacia adelante
N
asap000023
Consumo hacia atrás
N
asap000024
Parametrización por
artículos MPS/MRP
N
Tarea para definir el periodo temporal de
consumo hacia adelante (con fecha
posterior) en el tiempo
Tarea para definir el periodo temporal de
consumo hacia atrás (con fecha anterior)
en el tiempo
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer según el tipo de artículo
asap000025
Parametrización por tipo
de artículo
N
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer para cada tipo de artículo
asap000026
Parametrización por
gestión
compras/fabricación/subcontrata
N
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer según el tipo de gestión
asap000010
asap000013
asap000014
asap000015
asap000016
asap000017
asap000018
asap000019
asap000020
N
N
N
N
N
N
N
Tarea para definir los rangos de cada línea
de producto
Conjunto de acciones necesarias para
definir el rango de una nueva línea
Tarea que implica la finalización del
proceso de generación de rangos por línea
de producto
Tarea para definir los rangos de las
órdenes de subcontrata
Tarea para definir los rangos de las
órdenes de compra
Tarea para definir los rangos de las
órdenes de fabricación
Tarea para definir la barrera de la
demanda para la existencia de previsiones
en caso de política Make To Stock
Conjunto de acciones necesarias para
definir la política Make To Orden
Conjunto de acciones necesarias para
definir la política Assembly To Orden
Conjunto de acciones necesarias para el
modo y el plazo en el que realizar el
consumo de las previsiones
385
Anexo II
asap000027
Parametrización por tipo
de gestión
N
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer para cada tipo de gestión
asap000028
Parametrización por
clase A, B y C
N
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer según la clase ABC
asap000029
Parametrización perfiles
de planificación
N
Conjunto de acciones necesarias para
definir los críterios, parámetros y valores a
establecer para cada tipo de clase ABC
asap000030
Parametrización datos
del perfil
Parametrización política
de orden
N
asap000032
Parametrización gestión
de órdenes
N
Tarea para definir el nombre, descripción y
validez de cada perfil de planificación
Conjunto de acciones necesarias para
definir el tipo de política de orden a utilizar
y sus datos asociados en cada perfil de
planificación
Tarea para definir el planificador y los
límites temporales de gestión de órdenes
de cada perfil de planificación
asap000033
Parametrización
mensajes de excepción
N
Tarea para definir los límites de tolerancia
de los mensajes de excepción de cada
perfil de planificación
asap000034
Selección de política
N
asap000035
Selección de datos
asociados
N
asap000036
Selección de
modificadores
N
asap000037
Definición de cantidad
N
asap000038
Definición de semanas
N
asap000039
Definición de días
N
asap000040
Parametrización barrera
de la demanda para
MTO
N
Tarea para definir el tipo de política
elegida en cada perfil de planificación
Tarea para definir los datos asociados a la
política elegida en cada perfil de
planificación
Tarea para definir los modificadores de la
cantidad de la orden en cada perfil de
planificación
Tarea para definir la cantidad de la orden
si se utiliza cantidad fija
Tarea para definir la cantidad de semanas
si se utiliza periodo fijo semanal
Tarea para definir la cantidad de días si se
utiliza periodo fijo diario
Tarea para definir la barrera de la
demanda para la existencia de previsiones
en caso de política Make To Order
asap000041
Parametrización barrera
de la demanda para
inicial
N
asap000042
Parametrización barrera
de la demanda para
montaje
N
asap000043
Consumo hacia delante
y hacia atrás
N
asap000044
Parametrización política
de planificación
N
asap000031
N
Tarea para definir la barrera de la
demanda para la existencia de previsiones
en caso de política Assembly To Order
para niveles iniciales de producto
Tarea para definir la barrera de la
demanda para la existencia de previsiones
en caso de política Assembly To Order
para montaje final
Tarea para definir el periodo temporal de
consumo hacia adelante (con fecha
posterior) y hacia atrás (con fecha anterior)
en el tiempo
Conjunto de acciones encaminadas a
parametrizar para cada grupo de
planificación las distintas posibilidades de
la planificación de necesidades de material
según carácterísticas de cada grupo
386
Anexo II
asap000045
Continuación grupos de
planificación
N
asap000046
Fin grupos de
planificación
N
Conjunto de acciones necesarias para
definir la parametrización de un nuevo
grupo de planificación
Tarea que implica la finalización del
proceso de parametrización de la
planificación de necesidades por grupos
de planificación
3. Tabla de condiciones.
CLV_CON
csap000001
CLV_ACC
asap000001
IDENTIF
¿Parametrizar planificación
de necesidades?
csap000002
asap000002
¿Parametrizar datos
básicos?
csap000003
asap000003
¿Parametrizar gestión de la
demanda?
Este evento desencadena la
parametrización de los datos
necesarios para la gestión de
previsiones y su consumo
csap000004
asap000004
¿Parametrizar grupos de
planificación?
csap000005
asap000005
¿Establecer codificación de
artículos?
csap000006
asap000006
¿Describir clasificación
ABC?
csap000007
asap000007
¿Establecer codificación de
órdenes?
Este evento desencadena la
parametrización de las
distintas posibilidades de la
planificación de necesidades
de material según
carácterísticas de estos
materiales (grupos de
planificación)
Este evento desencadena la
definición del formato de
codificación de los artículos y
su asignación
Este evento desencadena la
definición del significado de
las clases A, B y C
Este evento desencadena la
parametrización de los rangos
de los números de orden y el
criterio de clasificación
csap000008
asap000008
¿Codificar por línea de
producto?
csap000009
asap000009
¿Codificar por tipo de
planificación?
csap000010
asap000010
¿Codificar por tipo de
producción?
387
DESCRIP
Este evento desencadena el
recorrido por el subdominio de
parametrización de la
planificación de necesidades
de material
Este evento desencadena la
parametrización de los datos
básicos necesarios para la
planificación de necesidades
Este evento desencadena el
proceso de definición de los
rangos de numeración de las
órdenes por líneas diferentes
de producto
Este evento desencadena el
proceso de definición de los
rangos de las órdenes de los
artículos MPS y MRP
Este evento desencadena el
proceso de definición de los
rangos de numeración de las
órdenes por tipos diferentes
de producción
Anexo II
csap000011
asap000011
¿Rango de una línea?
Este evento desencadena la
definición de los rangos de
cada línea de producto
csap000012
asap000012
¿Continuar rango de línea?
csap000013
asap000008
¿Rango para otra línea?
csap000014
asap000013
¿Fin codificación por líneas?
Este evento desencadena la
definición del rango de una
nueva línea
Este evento desencadena el
proceso de definición de los
rangos de numeración de las
órdenes por líneas diferentes
de producto
Con este vento se finaliza el
proceso de generación de
rangos por línea de producto
csap000015
asap000014
¿Codificar órdenes de
subcontrata?
csap000016
asap000015
¿Codificar órdenes de
compra?
csap000017
asap000016
¿Codificar órdenes de
fabricación?
csap000018
asap000017
¿Política MTS?
csap000019
asap000018
¿Política MTO?
csap000020
asap000019
¿Política ATO?
csap000021
asap000040
¿Parametrizar barrera de la
demanda?
csap000022
asap000020
¿Parametrizar política de
consumo?
csap000023
asap000021
¿Parametrizar uso de
previsiones?
csap000024
asap000041
¿Niveles iniciales con
previsiones?
388
Este evento desencadena el
proceso de definición de los
rangos de las órdenes de
subcontrata
Este evento desencadena el
proceso de definición de los
rangos de las órdenes de
compra
Este evento desencadena el
proceso de definición de los
rangos de las órdenes de
fabricación
Este evento desencadena el
proceso de definición de la
barrera de la demanda para la
existencia de previsiones en
caso de política Make To
Stock
Este evento desencadena el
proceso de parametrización
para la política Make To Orden
Este evento desencadena el
proceso de parametrización
para la política Assembly To
Orden
Este evento desencadena la
definición de la barrera de la
demanda para la existencia de
previsiones en caso de política
Make To Order
Este evento desencadena la
definición del modo y el plazo
en el que realizar el consumo
de las previsiones
Este evento desencadena la
selección del plazo, dentro del
tiempo total del producto, de
uso de las previsiones para el
consumo
Este evento desencadena la
definición de la barrera de la
demanda para la existencia de
previsiones en caso de política
Assembly To Order para
niveles iniciales de producto
Anexo II
csap000025
asap000042
¿Todos los niveles excepto
montaje final con
previsiones?
csap000026
asap000022
¿Consumo de previsones
posteriores?
csap000027
asap000023
¿Consumo de previsones
anteriores?
csap000028
asap000043
¿Consumo de previsiones
anteriores y posteriores?
csap000029
asap000024
¿Parametrizar por artículos
MPS/MRP?
csap000030
asap000025
¿Parametrizar por tipo de
artículo?
csap000031
asap000025
¿Parametrizar artículos
MPS?
csap000032
asap000025
¿Parametrizar artículos
MRP?
csap000033
asap000026
¿Parametrizar por gestión
compras/fabricación/subcontrata?
csap000034
asap000027
¿Parametrizar todo tipo de
gestión?
csap000035
asap000027
¿Parametrizar gestión de
compras?
389
Este evento desencadena la
definición de la barrera de la
demanda para la existencia de
previsiones en caso de política
Assembly To Order para
montaje final
Este evento desencadena la
definición del periodo temporal
de consumo hacia adelante
(con fecha posterior) en el
tiempo
Este evento desencadena la
definición del consumo hacia
atrás (con fecha anterior) en el
tiempo
Este evento desencadena la
definición del periodo temporal
de consumo hacia adelante
(con fecha posterior) y hacia
atrás (con fecha anterior) en el
tiempo
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer según el tipo de
artículo
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para cada tipo de
artículo
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para cada tipo de
artículo
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para cada tipo de
artículo
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer según el tipo de
gestión
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para cada tipo de
gestión
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la gestión de
compras
Anexo II
csap000036
asap000027
¿Parametrizar gestión de
fabricación?
csap000037
asap000027
¿Parametrizar gestión de
subcontrata?
csap000038
asap000028
¿Parametrizar por clase
ABC?
csap000039
asap000029
¿Parametrizar todas las
clases ABC?
csap000040
asap000029
¿Parametrizar clase A?
csap000041
asap000029
¿Parametrizar clase B?
csap000042
asap000029
¿Parametrizar clase C?
csap000043
asap000030
¿Parametrizar datos perfil?
csap000044
asap000031
¿Parametrizar política de
orden?
csap000045
asap000032
¿Parametrizar gestión de
órdenes?
csap000046
asap000033
¿Parametrizar mensajes de
excepción?
csap000047
asap000034
¿Elegir política?
390
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la gestión de
fabricación
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la gestión de
subcontrata
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer según la clase
ABC
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para cada tipo de
clase ABC
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la clase A
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la clase B
Este evento desencadena el
proceso de definición de los
críterios, parámetros y valores
a establecer para la clase C
Este evento desencadena el
proceso de definición del
nombre, descripción y validez
de cada perfil de planificación
Este evento desencadena el
proceso de definición del tipo
de política de orden a utilizar y
sus datos asociados en cada
perfil de planificación
Este evento desencadena el
proceso de definición del
planificador y los límites
temporales de gestión de
órdenes de cada perfil de
planificación
Este evento desencadena el
proceso de definición de los
límites de tolerancia de los
mensajes de excepción de
cada perfil de planificación
Este evento desencadena el
proceso de definición del tipo
de política elegida en cada
perfil de planificación
Anexo II
csap000048
asap000035
¿Elegir datos asociados?
csap000049
asap000036
¿Elegir modificadores?
csap000050
asap000037
¿Política = cantidad fija?
csap000051
asap000038
¿Política = semanas fijas?
csap000052
asap000039
¿Política = días fijos?
csap000053
asap000044
¿Parametrizar política de
planificación?
csap000054
asap000045
¿Continuar grupos de
planificación?
csap000055
asap000044
¿Parametrizar otro grupo de
planificación?
csap000056
asap000046
¿Fin grupos de
planificación?
Este evento desencadena el
proceso de definición de los
datos asociados a la política
elegida en cada perfil de
planificación
Este evento desencadena el
proceso de definición de los
modificadores de la cantidad
de la orden en cada perfil de
planificación
Este evento desencadena el
proceso de definición de la
cantidad de la orden si se
utiliza cantidad fija
Este evento desencadena el
proceso de definición de la
cantidad de semanas si se
utiliza periodo fijo semanal
Este evento desencadena el
proceso de definición de la
cantidad de días si se utiliza
periodo fijo diario
Este evento desencadena la
parametrización para cada
grupo de planificación de las
distintas posibilidades de la
planificación de necesidades
de material según
carácterísticas de cada grupo
Este evento desencadena la
definición de la política de
planificación de otros grupos
de planificación
Este evento desencadena la
definición de la política de
planificación de un grupo de
planificación
Este evento desencadena la
finalización del proceso de
definición de la política de
planificación de grupos de
planificación
4. Tabla de documentos.
CLV_DOC
dsap000001
TIPO
pdf
dsap000002
pdf
DESCRIP
Determina a forma de
realizar el proceso de
definición del Tipo de
política
Determina la posible
utilización y
consecuencias de los
parámetros Cantidad
máxima y Cantidad
Mínima como en el
proceso de selección de
modificadores para las
IDENTIF
Tipo política
DIRECCION
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Tipo_política.pdf
Modificadores
política
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Modificadores_política.pdf
391
Anexo II
políticas de planificación
dsap000003
pdf
dsap000004
pdf
dsap000005
pdf
dsap000006
html
dsap000007
html
dsap000008
jpg
dsap000009
jpg
dsap000010
doc
Determina el significado
y el uso en el proceso
de definición de la
cantidad en las políticas
de orden, del parámetro
Cantidad
Determina el significado
y el uso en el proceso
de definición de las
semanas en las políticas
de orden del parámetro
Semanas
Determina el significado
y el uso en el proceso
de definición de las
semanas en las políticas
de orden del parámetro
Meses
Determina la forma de
realizar el proceso de
definición de la
representación de la
codificación de los
artículos
Determina la posible
utilización del parámetro
máscara en la definición
de la representación de
la codificación de los
artículos
Determina la forma de
realizar el proceso de
establecimiento de la
política de consumo de
las previsiones
Determina la posible
utilización de los
parámetros límite de
lanzamiento y límite de
confirmación en la
gestión de las órdenes
Determina la forma de
realizar el proceso de
definición de grupos de
planificación
Cantidad
política
C:/mySAPR3/Parametrizacio
n/Planificacion_ necesidades/
Cantidad_política.pdf
Semanas
política
C:/mySAPR3/Parametrizacio
n/Planificacion_ necesidades/
Semanas_política.pdf
Meses política
C:/mySAPR3/Parametrizacio
n/Planificacion_ necesidades/
Meses_política.pdf
Representación
material
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Representacion_material.html
Máscara
material
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Mascara_material.html
Politica
consumo
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Politica_consumo.jpg
Límites
órdenes
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Limites_ordenes.jpg
Grupo
planificación
C:/mySAPR3/Parametrizacio
n/Planificacion_necesidades/
Grupo_planificacion.doc
392
Anexo II
5. Tabla de parámetros.
CLV_PAR
IDENTIF
DESCRIP
ERPCLAVE
psap000001
LMATNR
TMCNV
psap000002
LMASKE
psap000003
EXTERNIND
psap000004
TMABC
psap000005
TMABC
Longitud
número de
material
Patrón para
conversión
de
números
de material
Ind. para
números
interno (' ')
o bien
externo
('X')
Denomina
ción
indicador
clase A
Denomina
ción
indicador
clase B
psap000006
TMABC
psap000007
NRFROM
psap000008
NRTO
psap000009
NRFROM
psap000010
NRTO
psap000011
NRFROM
psap000012
NRTO
psap000013
OBJECT
psap000014
NRFROM
psap000015
NRTO
psap000016
NRFROM
psap000017
NRTO
psap000018
NRFROM
V_C
TMCNV
TMCNV
TIPO
VAL
DEFEC
CLV_TRAN
CLV_ACC
rango_
entero_
positivo
texto
1/18
18
tsap000001
asap000005
tsap000001
asap000005
enume
rado
_texto
' '/X
''
tsap000002
asap000005
Material
de gran
importan
cia
Material
de
media
importan
cia
Material
de poca
importan
cia
tsap000003
asap000006
tsap000003
asap000006
tsap000003
asap000006
18
TMABC/
MAABC
A
texto
30
TMABC/
MAABC
B
texto
30
TMABC/
MAABC
C
texto
30
NRIV/
OBJECT
MS
texto
20
tsap000004
asap000009
NRIV/
OBJECT
MS
texto
20
tsap000004
asap000009
NRIV/
OBJECT
MR
texto
20
tsap000004
asap000009
Rango
hasta para
MRP
Rango
desde para
línea de
producción
Rango
hasta para
línea de
producción
Nombre de
la línea de
producción
objeto del
rango
Rango
desde para
subcontrata
NRIV/
OBJECT
MR
texto
20
tsap000004
asap000009
NRIV/
OBJECT
texto
20
tsap000004
asap000011
NRIV/
OBJECT
texto
20
tsap000004
asap000011
NRIV
texto
10
tsap000004
asap000011
NRIV/
OBJECT
SC
texto
20
tsap000004
asap000014
Rango
hasta para
subcon
trata
Rango
desde para
compras
Rango
hasta para
compras
Rango
desde para
fabricación
NRIV/
OBJECT
SC
texto
20
tsap000004
asap000014
NRIV/
OBJECT
CO
texto
20
tsap000004
asap000015
NRIV/
OBJECT
CO
texto
20
tsap000004
asap000015
NRIV/
OBJECT
FB
texto
20
tsap000004
asap000016
Denomina
ción
indicador
clase C
Rango
desde para
MPS
Rango
hasta para
MPS
Rango
desde para
MRP
393
Anexo II
psap000019
NRTO
psap000020
RESVP
psap000021
RESVP
psap000022
RESVP
psap000023
RESVP
psap000024
VINT1
psap000025
VINT2
psap000026
VINT1
psap000027
VINT2
psap000028
DISPR
psap000029
DPRTX
Rango
hasta para
fabricación
Horizonte
de ajuste
para la
preplanifi
cación en
política
MTS
Horizonte
de ajuste
para la
preplanifi
cación en
política
MTO
Horizonte
de ajuste
para la
preplanifi
cación en
política
ATO para
niveles
iniciales
Horizonte
de ajuste
para la
preplanifi
cación en
política
ATO para
montaje
final
Intervalo
compensa
ción hacia
atrás en
política
solo atrás
Intervalo
compensa
ción hacia
delante en
política
solo
adelante
Intervalo
compensa
ción hacia
atrás en
política
adelante
/atrás
Intervalo
compensa
ción hacia
delante en
política
adelante
/atrás
Grupo de
planifica
ción de
necesida
des
Descrip
ción grupo
de planifica
ción de
necesida
des
NRIV/
OBJECT
FB
texto
20
tsap000004
asap000016
V_T438M
_V
rango_
entero_
positivo
0/999
tsap000005
asap000017
V_T438M
_V
rango_
entero_
positivo
0/999
tsap000005
asap000040
V_T438M
_V
rango_
entero_
positivo
0/999
tsap000005
asap000041
V_T438M
_V
rango_
entero_
positivo
0/999
tsap000005
asap000042
0
V_T438M
_V/VRMOD
1
rango_
entero_
positivo
0/999
tsap000005
asap000023
V_T438M
_V/VRMOD
3
rango_
entero_
positivo
0/999
tsap000005
asap000022
V_T438M
_V/VRMOD
2
rango_
entero_
positivo
0/999
tsap000005
asap000043
V_T438M
_V/VRMOD
2
rango_
entero_
positivo
0/999
tsap000005
asap000043
T401T
texto
4
tsap000006
asap000030
T401T
texto
40
tsap000006
asap000030
394
Anexo II
psap000030
DISPO
psap000031
FREIZ
psap000032
ERHOR
psap000033
DISPR
psap000034
VWVOR
psap000035
VWVER
psap000036
DISPR
psap000037
LOSKZ
psap000038
DISPR
psap000039
BSTMA
psap000040
BSTMI
psap000041
DISPR
psap000042
BSTFE
psap000043
DISPR
psap000044
PERAZ
psap000045
Planifica
dor de
necesida
des
Horizonte
de
lanzamien
to en días
Horizonte
de confirma
ción en
días
Perfil de
planifica
ción de
necesida
des
Valor de
tolerancia
para el
adelanto de
elementos
de entrada
Valor de
tolerancia
para el
retraso de
elementos
de entrada
Grupo de
planifica
ción de
necesida
des
Política de
planifica
ción
Grupo de
planifica
ción de
necesida
des
V_T024D/
DISPR
texto
3
tsap000007
asap000032
V_T024D/
DISPR
rango_
entero_
positivo
0/999
tsap000007
asap000032
V_T024D/
DISPR
rango_
entero_
positivo
0/999
tsap000007
asap000032
V_T024D
texto
4
tsap000007
asap000032
V_438M
_U /DISPR
rango_
entero_
positivo
0/99
0
tsap000007
asap000033
V_438M
_U/DISPR
rango_
entero_
positivo
0/99
0
tsap000007
asap000033
V_438M
_U
texto
4
tsap000007
asap000033
MDIP/
DISPR
E/F/T/
W/M
tsap000008
asap000034
MDIP
enume
rado_
texto
texto
4
tsap000008
asap000034
Tamaño de
lote
máximo
Tamaño de
lote mínimo
Grupo de
planifica
ción de
necesida
des
Tamaño de
lote fijo
Grupo de
planifica
ción de
necesida
des
Cantidad
de periodos
MDIP/
DISPR
real_
positivo
tsap000008
asap000035
MDIP/
DISPR
MDIP
real_
positivo
texto
tsap000008
asap000035
tsap000008
asap000035
MDIP/
DISPR
MDIP
real_
positivo
texto
tsap000008
asap000037
4
tsap000008
asap000037
MDIP/
DISPR
0/999
tsap000008
asap000038
PERKZ
Indicador
de periodo
MDIP/
DISPR
T/W/M
tsap000008
asap000038
psap000046
DISPR
MDIP
4
tsap000008
asap000038
psap000047
PERAZ
Grupo de
planifica
ción de
necesida
des
Cantidad
de periodos
rango_
entero_
positivo
enume
rado_
texto
texto
0/999
tsap000008
asap000039
MDIP/
DISPR
rango_
entero_
positivo
395
4
Anexo II
psap000048
PERKZ
Indicador
de periodo
MDIP/
DISPR
psap000049
DISPR
Grupo de
planifica
ción de
necesida
des
MDIP
enume
rado_
texto
texto
T/W/M
tsap000008
asap000039
4
tsap000008
asap000039
6. Tabla de transacciones.
CLV_TRAN
tsap000001
SISTERP
SAP R/3
IDENTIF
OMSL
tsap000002
SAP R/3
MMNR
tsap000003
SAP R/3
SPRO
tsap000004
SAP R/3
OM12
tsap000005
tsap000006
SAP R/3
SAP R/3
OPPQ
MMD1
tsap000007
tsap000008
SAP R/3
SAP R/3
OPPR
OMI4
DESCRIP
Modificar vista representación num.material:
Detalle
Rangos de números maestro de
materiales:Detalle
Modificar vista indicadores ABC para materiales:
Resumen
Modificar vista estrategia de
repos.aprovisionamiento: Resumen
Modificar vista compensación: Detalle
Crear perfil planificación de necesidades:
Acceso
Grupo de planificación de necesidades
Tamaño de lote
7. Tabla de documentos/acciones.
CLV_ACC
dsap000001
dsap000002
dsap000003
dsap000004
dsap000005
dsap000006
dsap000008
dsap000010
CLV_DOC
asap000034
asap000036
asap000037
asap000038
asap000039
asap000005
asap000020
asap000004
8. Tabla de documentos/parámetros.
CLV_PARA
dsap000002
dsap000002
dsap000003
dsap000004
dsap000004
dsap000004
dsap000005
dsap000007
dsap000009
dsap000009
CLV_DOC
psap000039
psap000040
psap000042
psap000047
psap000048
psap000048
psap000047
psap000002
psap000031
psap000032
396
Anexo II
9. Fichero de taxonomía empresarial.
AC.PADRE
AC.HIJA 1
R.1
AC.HIJA 2
R.2
AC.HIJA 3
R.3
asap000001
asap000002
SI
PARAM.1
asap000003
SI
asap000004
SI
asap000002
asap000005
SI
asap000006
SI
asap000007
SI
asap000003
asap000017
NO
asap000018
NO
asap000019
SI
asap000019
asap000021
SI
asap000020
SI
asap000020
asap000022
NO
asap000023
NO
asap000043
SI
asap000004
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
SI
asap000027
NO
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
SI
asap000029
NO
asap000029
NO
asap000029
asap000030
SI
asap000031
SI
asap000032
SI
asap000031
asap000034
SI
asap000035
NO
asap000036
NO
asap000045
asap000004
SI
asap000046
NO
asap000004
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
SI
asap000027
NO
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt2.txt
C:/mySAPR3
/Parametriza
cion/prt3.txt
PARAM.2
asap000029
SI
asap000029
NO
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
SI
asap000039
NO
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
SI
asap000027
NO
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt6.txt
C:/mySAPR3
/Parametriza
cion/prt7.txt
C:/mySAPR3
/Parametriza
cion/prt8.txt
asap000029
NO
asap000029
SI
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
SI
asap000039
NO
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
NO
asap000027
SI
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
SI
asap000029
NO
asap000029
NO
asap000029
asap000030
SI
asap000031
SI
asap000032
SI
asap000031
asap000034
SI
asap000035
SI
asap000036
NO
asap000035
asap000037
NO
asap000038
NO
asap000039
NO
asap000045
asap000004
SI
asap000046
NO
asap000004
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
NO
asap000027
SI
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
SI
asap000029
NO
C:/mySAPR3/
Parametriza
cion/prt11.txt
C:/mySAPR3/
Parametriza
cion/prt12.txt
C:/mySAPR3/
Parametriza
cion/prt16.txt
C:/mySAPR3/
Parametriza
cion/prt17.txt
C:/mySAPR3/
Parametriza
cion/prt13.txt
397
PARAM.3
AC.HIJA 4
R.4
PARAM.4
C:/mySAPR3/
Parametriza
cion/prt4.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt5.txt
C:/mySAPR3/
Parametriza
cion/prt9.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt10.txt
C:/mySAPR3/
Parametriza
cion/prt14.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt15.txt
C:/mySAPR3/
Parametriza
cion/prt18.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt19.txt
C:/mySAPR3/
Parametriza
cion/prt1.txt
Anexo II
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt20.txt
C:/mySAPR3/
Parametriza
cion/prt21.txt
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
SI
asap000039
NO
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
SI
asap000025
NO
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
NO
asap000027
SI
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt22.txt
asap000029
NO
asap000029
SI
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
SI
asap000039
NO
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
NO
asap000025
SI
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
SI
asap000027
NO
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
SI
asap000029
NO
asap000029
asap000030
SI
C:/mySAPR3/
Parametriza
cion/prt30.txt
asap000031
SI
asap000032
SI
asap000031
asap000034
SI
C:/mySAPR3/
Parametriza
cion/prt31.txt
asap000035
SI
asap000036
NO
asap000035
asap000037
NO
asap000038
NO
asap000039
SI
asap000045
asap000004
SI
asap000046
NO
asap000004
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
NO
asap000025
SI
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
SI
asap000027
NO
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt25.txt
C:/mySAPR3/
Parametriza
cion/prt26.txt
C:/mySAPR3/
Parametriza
cion/prt27.txt
asap000029
NO
asap000029
SI
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
NO
asap000039
SI
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
NO
asap000025
SI
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
NO
asap000027
SI
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
asap000045
asap000004
C:/mySAPR3/
Parametriza
cion/prt35.txt
C:/mySAPR3/
Parametriza
cion/prt36.txt
asap000029
SI
asap000029
NO
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
NO
asap000038
SI
asap000039
NO
asap000004
SI
asap000046
NO
asap000044
SI
asap000045
SI
asap000044
asap000024
SI
asap000025
NO
asap000024
asap000025
NO
asap000025
SI
asap000025
asap000026
SI
asap000027
NO
asap000026
asap000027
NO
asap000027
SI
asap000027
NO
asap000027
asap000028
SI
asap000029
NO
C:/mySAPR3/
Parametriza
cion/prt40.txt
C:/mySAPR3/
Parametriza
cion/prt41.txt
C:/mySAPR3/
Parametriza
cion/prt42.txt
398
C:/mySAPR3
/Parametriza
cion /prt23.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt24.txt
C:/mySAPR3/
Parametriza
cion/prt28.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt29.txt
C:/mySAPR3/
Parametriza
cion/prt33.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt34.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt39.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt44.txt
C:/mySAPR3/
Parametriza
cion /prt32.txt
C:/mySAPR3/
Parametriza
cion/prt38.txt
C:/mySAPR3/
Parametriza
cion/prt37.txt
C:/mySAPR3/
Parametriza
cion/prt43.txt
Anexo II
asap000028
asap000029
NO
asap000029
asap000030
SI
asap000031
asap000034
SI
asap000035
asap000037
NO
C:/mySAPR3
/Parametriza
cion/prt45.txt
C:/mySAPR3/
Parametriza
cion/prt46.txt
asap000029
NO
asap000029
SI
asap000031
SI
asap000032
SI
asap000035
SI
asap000036
NO
asap000038
NO
asap000039
SI
C:/mySAPR3/
Parametriza
cion/prt48.txt
asap000033
SI
C:/mySAPR3/
Parametriza
cion/prt49.txt
C:/mySAPR3/
Parametriza
cion/prt47.txt
10. Ficheros de parámetros de la taxonomía empresarial.
FICHERO
CLV_PAR
CLV_TRAN
ERPCLAVE
C:/mySAPR3/
Parametrizacion
/prt1.txt
psap000026
tsap000005
V_T438M_V/VRMOD
2
30
C:/mySAPR3/
Parametrizacion
/prt1.txt
psap000027
tsap000005
V_T438M_V/VRMOD
2
30
C:/mySAPR3/
Parametrizacion
/prt2.txt
psap000028
tsap000006
T401T
G.1
C:/mySAPR3/
Parametrizacion
/prt2.txt
psap000029
tsap000006
T401T
MPS/C/A
C:/mySAPR3/
Parametrizacion
/prt3.txt
psap000037
tsap000008
MDIP/DISPR
G.1
E
C:/mySAPR3/
Parametrizacion
/prt4.txt
psap000030
tsap000007
V_T024D/DISPR
G.1
P1
C:/mySAPR3/
Parametrizacion
/prt4.txt
psap000031
tsap000007
V_T024D/DISPR
G.1
3
C:/mySAPR3/
Parametrizacion
/prt4.txt
psap000032
tsap000007
V_T024D/DISPR
G.1
10
C:/mySAPR3/
Parametrizacion
/prt5.txt
psap000034
tsap000007
V_438M_U/DISPR
G.1
0
C:/mySAPR3/
Parametrizacion
/prt5.txt
psap000035
tsap000007
V_438M_U/DISPR
G.1
15
C:/mySAPR3/
Parametrizacion
/prt6.txt
psap000028
tsap000006
T401T
G.2
C:/mySAPR3/
Parametrizacion
/prt6.txt
psap000029
tsap000006
T401T
MPS/C/B
C:/mySAPR3/
Parametrizacion
/prt7.txt
psap000037
tsap000008
MDIP/DISPR
G.2
C:/mySAPR3/
Parametrizacion
/prt8.txt
psap000044
tsap000008
MDIP/DISPR
G.2
399
VALOR_
C
VALOR_P
W
2
Anexo II
C:/mySAPR3/
Parametrizacion
/prt8.txt
psap000045
tsap000008
MDIP/DISPR
G.2
W
C:/mySAPR3/
Parametrizacion
/prt9.txt
psap000030
tsap000007
V_T024D/DISPR
G.2
P2
C:/mySAPR3/
Parametrizacion
/prt9.txt
psap000031
tsap000007
V_T024D/DISPR
G.2
3
C:/mySAPR3/
Parametrizacion
/prt9.txt
psap000032
tsap000007
V_T024D/DISPR
G.2
10
C:/mySAPR3/
Parametrizacion
/prt10.txt
psap000034
tsap000007
V_438M_U/DISPR
G.2
5
C:/mySAPR3/
Parametrizacion
/prt10.txt
psap000035
tsap000007
V_438M_U/DISPR
G.2
15
C:/mySAPR3/
Parametrizacion
/prt11.txt
psap000028
tsap000006
T401T
G.3
C:/mySAPR3/
Parametrizacion
/prt11.txt
psap000029
tsap000006
T401T
MPS/C/C
C:/mySAPR3/
Parametrizacion
/prt12.txt
psap000037
tsap000008
MDIP/DISPR
G.3
C:/mySAPR3/
Parametrizacion
/prt13.txt
psap000044
tsap000008
MDIP/DISPR
G.3
C:/mySAPR3/
Parametrizacion
/prt13.txt
psap000045
tsap000008
MDIP/DISPR
G.3
W
C:/mySAPR3/
Parametrizacion
/prt14.txt
psap000030
tsap000007
V_T024D/DISPR
G.3
P2
C:/mySAPR3/
Parametrizacion
/prt14.txt
psap000031
tsap000007
V_T024D/DISPR
G.3
3
C:/mySAPR3/
Parametrizacion
/prt14.txt
psap000032
tsap000007
V_T024D/DISPR
G.3
10
C:/mySAPR3/
Parametrizacion
/prt15.txt
psap000034
tsap000007
V_438M_U/DISPR
G.3
5
C:/mySAPR3/
Parametrizacion
/prt15.txt
psap000035
tsap000007
V_438M_U/DISPR
G.3
15
C:/mySAPR3/
Parametrizacion
/prt16.txt
psap000028
tsap000006
T401T
G.4
C:/mySAPR3/
Parametrizacion
/prt16.txt
psap000029
tsap000006
T401T
MPS/F/A
400
W
2
Anexo II
C:/mySAPR3/
Parametrizacion
/prt17.txt
psap000037
tsap000008
MDIP/DISPR
G.4
E
C:/mySAPR3/
Parametrizacion
/prt18.txt
psap000030
tsap000007
V_T024D/DISPR
G.4
P3
C:/mySAPR3/
Parametrizacion
/prt18.txt
psap000031
tsap000007
V_T024D/DISPR
G.4
10
C:/mySAPR3/
Parametrizacion
/prt18.txt
psap000032
tsap000007
V_T024D/DISPR
G.4
10
C:/mySAPR3/
Parametrizacion
/prt19.txt
psap000034
tsap000007
V_438M_U/DISPR
G.4
0
C:/mySAPR3/
Parametrizacion
/prt19.txt
psap000035
tsap000007
V_438M_U/DISPR
G.4
15
C:/mySAPR3/
Parametrizacion
/prt20.txt
psap000028
tsap000006
T401T
G.5
C:/mySAPR3/
Parametrizacion
/prt20.txt
psap000029
tsap000006
T401T
MPS/F/B
C:/mySAPR3/
Parametrizacion
/prt21.txt
psap000037
tsap000008
MDIP/DISPR
G.5
C:/mySAPR3/
Parametrizacion
/prt22.txt
psap000044
tsap000008
MDIP/DISPR
G.5
C:/mySAPR3/
Parametrizacion
/prt22.txt
psap000045
tsap000008
MDIP/DISPR
G.5
W
C:/mySAPR3/
Parametrizacion
/prt23.txt
psap000030
tsap000007
V_T024D/DISPR
G.5
P4
C:/mySAPR3/
Parametrizacion
/prt23.txt
psap000031
tsap000007
V_T024D/DISPR
G.5
10
C:/mySAPR3/
Parametrizacion
/prt23.txt
psap000032
tsap000007
V_T024D/DISPR
G.5
10
C:/mySAPR3/
Parametrizacion
/prt24.txt
psap000034
tsap000007
V_438M_U/DISPR
G.5
5
C:/mySAPR3/
Parametrizacion
/prt24.txt
psap000035
tsap000007
V_438M_U/DISPR
G.5
15
C:/mySAPR3/
Parametrizacion
/prt25.txt
psap000028
tsap000006
T401T
G.6
C:/mySAPR3/
Parametrizacion
/prt25.txt
psap000029
tsap000006
T401T
MPS/F/C
401
W
1
Anexo II
C:/mySAPR3/
Parametrizacion
/prt26.txt
psap000037
tsap000008
MDIP/DISPR
G.6
C:/mySAPR3/
Parametrizacion
/prt27.txt
psap000044
tsap000008
MDIP/DISPR
G.6
C:/mySAPR3/
Parametrizacion
/prt27.txt
psap000045
tsap000008
MDIP/DISPR
G.6
W
C:/mySAPR3/
Parametrizacion
/prt28.txt
psap000030
tsap000007
V_T024D/DISPR
G.6
P4
C:/mySAPR3/
Parametrizacion
/prt28.txt
psap000031
tsap000007
V_T024D/DISPR
G.6
10
C:/mySAPR3/
Parametrizacion
/prt28.txt
psap000032
tsap000007
V_T024D/DISPR
G.6
10
C:/mySAPR3/
Parametrizacion
/prt29.txt
psap000034
tsap000007
V_438M_U/DISPR
G.6
5
C:/mySAPR3/
Parametrizacion
/prt29.txt
psap000035
tsap000007
V_438M_U/DISPR
G.6
15
C:/mySAPR3/
Parametrizacion
/prt30.txt
psap000028
tsap000006
T401T
G.7
C:/mySAPR3/
Parametrizacion
/prt30.txt
psap000029
tsap000006
T401T
MRP/C/B
C:/mySAPR3/
Parametrizacion
/prt31.txt
psap000037
tsap000008
MDIP/DISPR
G.7
C:/mySAPR3/
Parametrizacion
/prt32.txt
psap000047
tsap000008
MDIP/DISPR
G.7
C:/mySAPR3/
Parametrizacion
/prt32.txt
psap000048
tsap000008
MDIP/DISPR
G.7
M
C:/mySAPR3/
Parametrizacion
/prt33.txt
psap000030
tsap000007
V_T024D/DISPR
G.7
P5
C:/mySAPR3/
Parametrizacion
/prt33.txt
psap000031
tsap000007
V_T024D/DISPR
G.7
3
C:/mySAPR3/
Parametrizacion
/prt33.txt
psap000032
tsap000007
V_T024D/DISPR
G.7
5
C:/mySAPR3/
Parametrizacion
/prt34.txt
psap000034
tsap000007
V_438M_U/DISPR
G.7
10
C:/mySAPR3/
Parametrizacion
/prt34.txt
psap000035
tsap000007
V_438M_U/DISPR
G.7
15
402
W
1
M
1
Anexo II
C:/mySAPR3/
Parametrizacion
/prt35.txt
psap000028
tsap000006
T401T
G.8
C:/mySAPR3/
Parametrizacion
/prt35.txt
psap000029
tsap000006
T401T
MRP/C/C
C:/mySAPR3/
Parametrizacion
/prt36.txt
psap000037
tsap000008
MDIP/DISPR
G.8
C:/mySAPR3/
Parametrizacion
/prt37.txt
psap000047
tsap000008
MDIP/DISPR
G.8
C:/mySAPR3/
Parametrizacion
/prt37.txt
psap000048
tsap000008
MDIP/DISPR
G.8
M
C:/mySAPR3/
Parametrizacion
/prt38.txt
psap000030
tsap000007
V_T024D/DISPR
G.8
P6
C:/mySAPR3/
Parametrizacion
/prt38.txt
psap000031
tsap000007
V_T024D/DISPR
G.8
3
C:/mySAPR3/
Parametrizacion
/prt38.txt
psap000032
tsap000007
V_T024D/DISPR
G.8
5
C:/mySAPR3/
Parametrizacion
/prt39.txt
psap000034
tsap000007
V_438M_U/DISPR
G.8
15
C:/mySAPR3/
Parametrizacion
/prt39.txt
psap000035
tsap000007
V_438M_U/DISPR
G.8
15
C:/mySAPR3/
Parametrizacion
/prt40.txt
psap000028
tsap000006
T401T
G.9
C:/mySAPR3/
Parametrizacion
/prt40.txt
psap000029
tsap000006
T401T
MPS/F/B
C:/mySAPR3/
Parametrizacion
/prt41.txt
psap000037
tsap000008
MDIP/DISPR
G.9
C:/mySAPR3/
Parametrizacion
/prt42.txt
psap000044
tsap000008
MDIP/DISPR
G.9
C:/mySAPR3/
Parametrizacion
/prt42.txt
psap000045
tsap000008
MDIP/DISPR
G.9
W
C:/mySAPR3/
Parametrizacion
/prt43.txt
psap000030
tsap000007
V_T024D/DISPR
G.9
P7
C:/mySAPR3/
Parametrizacion
/prt43.txt
psap000031
tsap000007
V_T024D/DISPR
G.9
10
C:/mySAPR3/
Parametrizacion
/prt43.txt
psap000032
tsap000007
V_T024D/DISPR
G.9
5
403
M
2
W
2
Anexo II
C:/mySAPR3/
Parametrizacion
/prt44.txt
psap000034
tsap000007
V_438M_U/DISPR
G.9
10
C:/mySAPR3/
Parametrizacion
/prt44.txt
psap000035
tsap000007
V_438M_U/DISPR
G.9
15
C:/mySAPR3/
Parametrizacion
/prt45.txt
psap000028
tsap000006
T401T
G.10
C:/mySAPR3/
Parametrizacion
/prt45.txt
psap000029
tsap000006
T401T
MRP/F/C
C:/mySAPR3/
Parametrizacion
/prt46.txt
psap000037
tsap000008
MDIP/DISPR
G.10
C:/mySAPR3/
Parametrizacion
/prt47.txt
psap000047
tsap000008
MDIP/DISPR
G.10
C:/mySAPR3/
Parametrizacion
/prt47.txt
psap000048
tsap000008
MDIP/DISPR
G.10
M
C:/mySAPR3/
Parametrizacion
/prt48.txt
psap000030
tsap000007
V_T024D/DISPR
G.10
P8
C:/mySAPR3/
Parametrizacion
/prt48.txt
psap000031
tsap000007
V_T024D/DISPR
G.10
10
C:/mySAPR3/
Parametrizacion
/prt48.txt
psap000032
tsap000007
V_T024D/DISPR
G.10
5
C:/mySAPR3/
Parametrizacion
/prt49.txt
psap000034
tsap000007
V_438M_U/DISPR
G.10
15
C:/mySAPR3/
Parametrizacion
/prt49.txt
psap000035
tsap000007
V_438M_U/DISPR
G.10
15
404
M
1
ANEXO III - GLOSARIO
Este anexo muestra un pequeño diccionario de términos relativos a la planificación
de materiales, subdominio elegido para el prototipo.
Activity Chain
Activity Chain es el archivo que contiene la lista de
los artículos a planificar, que utiliza el MRP con
cambio neto para decidir el siguiente artículo a
tratar
Artículo
Cualquier elemento codificable de una estructura,
ya sea item de ventas, aparato padre, grupo,
subgrupo o componente.
Available
Indica la disponibilidad de material en un periodo,
teniendo en cuenta la disponibilidad en el periodo
precedente y lo ordenado y las necesidades brutas
del periodo (considerando previsiones y demanda
real).
Available to promise
Indica la posibilidad real de material en un periodo,
ya que considera solo la demanda real y no
considera la disponibilidad de periodos precedente
a no ser en el pasado.
Bill of Material
Elenco de materiales de un artículo.
Capacidad
Posibilidad de producción de un centro de trabajo,
calculada como la suma de los recursos de
máquinas o de mano de obra de que dispone en
cada momento, pudiendose distinguir entre
capacidad máxima, normal y estimada
Carga
Volumen de trabajo previsto en función de las
órdenes programadas.
- 405 -
Anexo III
Catálogo
Clasificación que permite agrupar artículos de
forma personalizada.
Centro de Trabajo
Cualquier máquina o recurso utilizable en el ciclo
de fabricación de un aparato.
Ciclo Alternativo
Ciclo de fabricación de un artículo que difiere del
Ciclo Principal en al menos una operación.
Ciclo Principal
Lista o secuencia de operaciones necesarias para la
fabricación de un artículo.
Ciclo Representativo
Secuencia de recursos asociados a la fabricación de
un artículo, utilizada para la obtención del Plan
Maestro de Producción.
Consumo
La elaboración mediante la cual se reduce el valor
de las previsiones en función de la demanda
efectiva, evitando de esta forma duplicar la
planificación
Contrato Marco
Acuerdo a largo plazo con un proveedor para el
suministro de materiales y/o servicios. A grandes
líneas, debe especificar un periodo de validez, un
volumen de negocio.
Control por proyecto
Indica si un artículo estará siempre controlado por
proyecto (órdenes, necesidades y almacenes
separados), no lo estará nunca o lo estará o no
dependiendo de la estructura donde se use.
Coste Acumulado
Es la suma del coste incremental de un artículo, y
los costes agregados de los artículos de primer
nivel de su estructura.
Coste Agregado
Es el producto del coste incremental de un artículo
por el número de veces que éste aparece en un
nivel de una estructura.
Coste Incremental
Es el valor añadido para los artículos de
producción interna y el Coste de Compras para los
materiales de compras.
Coste Standard Congelado
Coste estándar de un artículo calculado al inicio de
cada nuevo año fiscal, permaneciendo invariable a
lo largo del mismo.
Coste Standard Planificado
Utilizado durante el cálculo de coste para la
evaluación de nuevos proyectos.
406
Anexo III
Coste Standard Real
Coste estándar de un artículo calculado al inicio de
cada nuevo año fiscal, y que se revisa a lo largo del
año en función de las actividades industriales.
Demanda efectiva
Se define demanda efectiva aquella que realmente
da lugar a retirada del material del almacén y a
expediciones
Due-date
Fecha en la que debe estar disponible la cantidad
pedida en una orden
Estado de la orden
Identifica el momento en que se encuentra dentro
de su ciclo de vida
Existencia
Cantidad de un artículo almacenada en el
establecimiento para el que se planifica el artículo,
incluyendo tanto el disponible como la cantidad
reservada para órdenes a punto de ser lanzadas a la
fábrica
Horizonte de planificación
Arco temporal que define la visibilidad del sistema,
debe ser lo bastante amplio como para definir
previsiones que permitan dimensionar la empresa a
largo plazo
Horizonte MRP (Commit)
Arco temporal que establece la barrera entre el
MPS y el MRP indicando cuando se desea que las
órdenes MPS sean desarrolladas a todos los niveles
por el MRP
Lead Time
Número de días de trabajo que pasa entre el
comienzo de una orden y la disponibilidad del
material resultante
Lead Time acumulativo
Representa el tiempo necesario para completar un
producto asumiendo que ninguno de sus
componentes de cualquier nivel está disponible
Lead Time Administrativo
Tiempo
a
disposición
de
un
planificador/comprador para emitir órdenes de
compras de materiales relativas a una propuesta de
compras.
Lead Time de Aceptación
Tiempo transcurrido desde que el proveedor
entrega el material, y éste es aceptado.
Lead Time de ajuste
Indica cuanto tiempo después de la apertura de una
orden es necesario un componente.
407
Anexo III
Lead Time de Aprovisionamiento Tiempo transcurrido desde la aceptación de una
orden por parte del proveedor hasta que suministra
el material.
Límite de confirmación
Establece el momento en que el MRP o el MPS no
realizan modificaciones, estas se deben hacer
manualmente.
Límite de la demanda
Momento en el cual las previsiones dejan de
tenerse en cuenta en la planificación de órdenes
Límite de replanificación
La fecha más lejana a la fecha actual en la que
existe una orden que se puede considerar ordenado
en firme
Listo para el lanzamiento
Barrera temporal que comprende el LT del artículo
más el tiempo necesario de preparación de la orden
y control de los materiales. Se utiliza para calcular
la fecha de inicio de la orden en función de la fecha
necesaria de entrega.
Método de planificación
Establece para cada artículo si será planificado por
el MPS, el MRP o no será planificado en
automático.
Modificador de orden
Parámetro que utiliza el MRP para modifican las
cantidades de las órdenes calculadas
Necesidad bruta
Cantidad necesaria de un artículo obtenida después
de realizar el proceso de consumo utilizando el
conjunto de necesidades dependientes e
independientes de la parte.
Necesidad dependiente
Es aquella necesidad de un artículo que proviene
de una orden de producción de algún artículo de en
nivel superior según la estructura de producto
Necesidad independiente
Es aquella necesidad de un artículo que crea
manualmente el usuario o que proviene
directamente de previsiones u órdenes cliente
Necesidad neta
Cantidad de un código que es necesaria tener
disponible para una fecha dada , obtenida restando
a las necesidades brutas la existencia en el almacén
y lo ordenado en firme
Operación
Cada uno de los pasos de un ciclo. Está asociado a
algún recurso (hombre, máquina, etc.), pudiendo
ser cuantificable.
408
Anexo III
Orden
Cantidad de un artículo que hay que producir,
comprar o transferir para satisfacer la demanda
productiva en cada sede
Ordenado en firme
Conjunto de órdenes confirmadas o lanzadas en
fábrica
Periodo de planificación
Indica el periodo de tiempo en que se desea
agrupar el plano obtenido por el MPS o el MRP
para la visualización de dicho plano.
Plan Operativo de Compras
Específico de un material de compras. Muestra en
cada periodo de planificación, las necesidades y
órdenes relativas al material de compras, y su
estado (planificado, confirmado, abierto, etc.).
Planificador
Persona responsable de la planificación de un
artículo: seguimiento de las órdenes, retrasos, falta
de material, etc.
Planning Bill
Estructura utilizada para definir las previsiones: el
nivel más alto de esta estructura lo forman las
familias de producto y se definen los componentes
de cada familia en función de unos porcentajes
según la situación del mercado y la configuración
de la familia
Política de orden
Parámetro utilizado para calcular la fecha y la
cantidad de la orden
Previsión
Representa, en forma de cantidad y fecha las
perspectivas de mercado
Sede
Cada una los centros dedicados a planificación de
la empresa, entendiendo tanto los centros
productivos como aquellos que solo dispongan de
almacenes o dedicados a la compra de
componentes
Tipo de artículo
Parámetro que indica a la planificación MRP o
MPS que tipo de orden debe generar para cubrir la
demanda de cada artículo: compras, producción o
transferencia.
409