INFORME TÉCNICO

Carrera de:
Tecnologías de la Información y Comunicación

Modelado de un Sistema Informático Empresarial

(ERP)
Para la Universidad Tecnológica de Coahuila
Utilizando UML 2.x

Presenta

Ing. José Martínez Huerta

Saltillo, Coahuila, abril de 2015

1
Contenido
Resumen general
I. Introducción
1.1 Descripción general
1.2 Motivaciones
1.3 Planteamiento del problema
1.4 Justificación
1.5 Objetivos
1.6 Contribuciones
1.7 Alcances
1.8 Limitaciones
1.9 Resumen del capítulo

II. Estado del arte sobre ERP y modelado en UML

2.1 Introducción
2.2. ERP
2.2.1 Conceptos básicos de ERP
2.2.2 Modelo conceptual de un ERP
2.2.3 Funciones generales de los ERP
2.2.4 Aplicaciones de los ERP
2.2.4.1 En las universidades
2.2.4.2 En la industria
2.2.4.3 En los negocios
2.3 Lenguaje Unificado de Modelación (UML)
2.3.1 Introducción
2.3.2 Conceptos básicos de UML
2.3.3 Análisis y diseño de sistemas con UML
2.3.4 Diagramas en UML
2.3.5 Aplicaciones de UML
2.4 Modelado de ERP con UML
2.5 Resumen del capítulo

III Aplicación de un ERP: un caso de estudio

3.1 Introducción
3.2. Situación actual de los sistemas
3.3. Funciones generales de la UTC
3.4 Requerimientos en la aplicación de tecnologías de información
3.5 Solución propuesta
3.5.1 Modelo conceptual de un ERP aplicado en la UTC
3.5.2 Modelo sistémico
3.5.2.1 Diagrama general de sistemas
3.5.2.2 Flujos generales de procesos
3.5.2.3 Diagramas generales causales
3.5.2.4 Diagrama de Forrester
3.6 Resumen del capitulo

2
IV. Modelado de un ERP con UML
4.1 Introducción
4.2 Diagramas de análisis con UML

4.2.1 Diagrama de Casos de Uso

4.2.2 Diagrama de Requisitos
4.2.3 Diagrama de Actividad

4.3 Diagramas de diseño

4.3.1 Diagramas de Dominio
4.3.2 Diagramas de Clases
4.4 Diagramas de Secuencia
4.5 Diagramas de Objetos
4.6 Diagramas de Comunicación
4.7 Diagramas de Componentes
4.8 Diagramas de Despliegue
4.9 Diagramas de Implementación
4.10 Diagrama de Estados

Conclusiones

Referencias

3
I Introducción

1.1 Introducción
El Sistema Universitario de Planeación de Recursos Académicos y Administrativos (SUPRAA) es
un proyecto del área de Tecnologías de la Información, tipo Enterprise Resource Planning (ERP)
que está en etapa de modelado, análisis, y diseño en la Universidad Tecnológica de Coahuila;
como una aportación del esfuerzo de algunos maestros de tiempo completo, de la carrera de
Tecnologías de Información y Comunicación.

La falta de control y de organización de la información debilita a las organizaciones [1]. Es por

este motivo que se pretende analizar y modelar una solución al problema del manejo de la
información en la Universidad Tecnológica de Coahuila, de tal modo que se eviten los problemas
que se presentan por falta de un sistema de información integral para la Universidad.
Los resultados esperados es contar con el análisis y diseño integral basado en UML versión 2 [3]
que soporte la solución integral al problema y que permita iniciar las etapas futuras del proyecto.

1.2 Motivaciones
1.2.1 Eficiencia de operación
Contar con procesos eficientes y eficaces en cuanto a la administración, academia y escolar es
de gran importancia para cualquier organización [1]. Las universidades públicas (o privadas)
pueden logran sus objetivos a través de un sistema integral de tipo ERP que ofrezca las
facilidades para el control y organización de la información. Los sistemas ERP son las bases
para la toma de decisiones de cualquier organización [4-6].

1.2.2 Congruencia con la misión de la institución

Es importante tener congruencia con la misión de la Universidad Tecnológica de Coahuila en
cuanto a la enseñanza de las tecnologías de la información. La solución que se propone deberá
contemplar las mejores prácticas. [10] realizadas en los sistemas de información integrales.

1.3 Planteamiento del problema

Actualmente en la Universidad Tecnológica de Coahuila se presentan problemas relacionados
con el flujo de información efectiva entre las distintas áreas. La UTC no cuenta con un sistema
integral de información de tipo ERP por lo que existen problemas relacionados con la integración
y redundancia de la información, y esto genera diversas dificultades en la toma de decisiones y
en las actividades normales de la universidad. Actualmente existen sistemas de información
aislados que no se interconectan y esto provoca llevar a cabo actividades para integrar la
información de una manera no adecuada.

Actualmente la UTC no cuenta con una base de datos integral en donde se almacene la
información en forma íntegra y sin redundancia. Por tal motivo, esta falta de una base de datos
integral afecta al flujo de información entre los sistemas de: Servicios escolares, Finanzas,
Recursos materiales, Proveedores, Caja, Centro de Información y Consulta, Contabilidad, Activos
fijos, Presupuestos, Vinculación, Relaciones Industriales, Jurídico, Calidad, Rectoría, Dirección
de Planeación, Secretaría Académica, Servicios Estudiantiles Mantenimiento e instalaciones de
la universidad, Extensión y difusión universitaria, Recursos Humanos. En los sub sistemas de
información de las distintas áreas de la universidad no se recibe en tiempo y forma la información
procesada por otros sub sistemas de la institución.

1.4 Justificación del proyecto

Una solución integral basada en un ERP es un producto tecnológico que ayuda a que una
organización logre sus objetivos [4-6]. Un sistema adecuadamente analizado y diseñado
utilizando diagramas y modelos en UML 2.0 [7-8] puede ser la plataforma tecnológica que

4
soporte el flujo de información en la organización, y así, mantener la integridad de la información,
y además facilite la comunicación entre las distintas áreas de la Universidad Tecnológica de
Coahuila. El análisis y diseño basado en el Lenguaje Unificado de Modelado (UML) son dos
fases de suma importancia en el ciclo de vida de un producto de software [7-9]. Estas fases
llevadas a cabo correctamente, permitirán implementar, en un futuro cercano, el sistema integral
de información de tipo ERP que requiere la UTC.

1.5 Objetivos

1.5.1 Objetivo General

El objetivo principal en este trabajo es Modelar el flujo de información existente entre todas las
áreas de la Universidad Tecnológica, con la finalidad de comprender los diversos sistemas
automáticos y manuales que actualmente integran el modo en que se trabaja, construyendo los
diagramas UML pertinentes desde la etapa de Modelado del Negocio y posteriormente los
diagramas de Modelado del Sistema total [3], haciendo énfasis en las interrelaciones de los
diversos procesos con los nodos computacionales de procesamiento de información
actualmente utilizados tales como: Servidores de bases de datos, servidores de aplicaciones y
computadoras personales. [6-8]

1.5.2 Objetivos Particulares

Se contempla cumplir con los siguientes objetivos particulares:

 Analizar y modelar los requerimientos actuales de todas las áreas de la Universidad

Tecnológica de Coahuila
 Determinar los artefactos y flujos de entrada y de salida a los procesos
 Modelar las interacciones entre los procesos de la universidad
 Modelar el ámbito general del sistema total
 Realizar una planeación de actividades por sistema y total.

1.6 Estado del arte (Marco teórico)

Enterprise Resource Planning

Los sistemas de planificación de recursos empresariales (en inglés ERP, Enterprise Resource
Planning) son sistemas de gestión de información que integran y automatizan muchas de las
prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa.

Los objetivos principales de los sistemas ERP son:

 Optimización de los procesos empresariales.

 Acceso a toda la información de forma confiable, precisa y oportuna (integridad de
datos).
 La posibilidad de compartir información entre todos los componentes de la organización.
 Eliminación de datos y operaciones innecesarias de reingeniería.

El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos
de respuesta a sus problemas, así como un eficiente manejo de información que permita la toma
oportuna de decisiones y disminución de los costos totales de operación. Las características que
distinguen a un ERP de cualquier otro software empresarial, es que deben de ser sistemas
integrales, con modularidad y adaptables:

Otras características destacables de los sistemas ERP son:

 Base de datos centralizada.

5
  Los componentes del ERP interactúan entre sí consolidando todas las operaciones.
 En un sistema ERP los datos se ingresan sólo una vez y deben ser consistentes,
completos y comunes.
 Las empresas que lo implanten suelen tener que modificar alguno de sus procesos para
alinearlos con los del sistema ERP. Este proceso se conoce como Reingeniería de
Procesos, aunque no siempre es necesario.
 Aunque el ERP pueda tener menús modulares configurables según los roles de cada
usuario, es un todo. Esto significa: es un único programa (con multiplicidad de
bibliotecas, eso sí) con acceso a una base de datos centralizada. No debemos confundir
en este punto la definición de un ERP con la de una suite de gestión.
 La tendencia actual es a ofrecer aplicaciones especializadas para determinadas
empresas. Es lo que se denomina versiones sectoriales o aplicaciones sectoriales
especialmente indicadas o preparadas para determinados procesos de negocio de un
sector (los más utilizados).

Análisis Orientado a objetos

El Análisis Orientado a Objetos AOO [9], se basa en un conjunto de principios básicos. Para
construir un modelo se aplican 5 principios básicos:
1.- Se modela el dominio de la información
2.- Se describe la función
3.- Se representa el comportamiento del modelo
4.- Los modelos de datos, función y comportamiento se dividen para mostrar más detalle
5.- Los modelos iniciales representan la esencia del problema mientras que los últimos
muestran detalles de la implementación.

Diseño Orientado a objetos

El diseño orientado a objetos transforma el modelo del análisis creado usando el análisis
orientado a objetos [9] en un modelo de diseño que sirve como un anteproyecto para la
construcción del software. A diferencia de los métodos convencionales de diseño de software, el
DOO constituye un tipo de diseño que logra un cierto número de diferentes niveles de
modularidad. Las componentes principales del sistema están organizadas en “módulos”
denominados subsistemas.

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la
actualidad [3]; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos
de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y componentes reutilizables

1.6 Contribuciones

 Modelar el funcionamiento real de la Universidad Tecnológica de Coahuila

 Hacer un diagnóstico de la salud organizacional de la institución
 Contribuir con los hallazgos del modelado del sistema a una re-ingeniería de procesos
total, previa al desarrollo de un ERP.
 Realizar los diagramas de Modelado UML de procesos de todas las áreas de la
Universidad en su forma actual de trabajo, que muestren una visión general. Únicamente
diagramas de análisis y diseño

 Casos de Uso,
 Clases,

6
  Secuencia,
 Actividades y
 Comunicación

1.7 Alcances

En esta tesis se modelan las funciones de una universidad pública la Universidad Tecnológica de
Coahuila, realizándose un estudio de requisitos basados en el sistema de gestión de calidad
certificado: ISO 9001:2008, a partir del cuál se incluyen los procesos, sus interacciones
generales, se representan mediante diagramas los causales, sus Flujos de datos a nivel procesos
y áreas, Luego se crea el libro de requisitos funcionales, no funcionales y no técnicos, aunado a
la Ingeniería de Dominio de los cuáles se realizará un estudio de dependencias entre áreas
funcionales de la universidad enfocado a la reutilización de requisitos mediante el modelado de
Objetivos y actores. Debido al tiempo disponible para el proyecto se obtendrán los diagramas de
UML 2.0 correspondientes a los casos de uso de las funciones de Servicios Escolares y Pagos
de alumnos; correspondientes al proceso Académico y al proceso de Gestión respectivamente.

1.8 Limitaciones
 El tiempo del proyecto se reduce a 5 meses
 El sistema de la Universidad es complejo, lo que limita el alcance del modelado al
Análisis y Diseño
 Se enfocará el proyecto solamente a las interrelaciones a nivel sub sistema
 Se abarcarán las funciones globales del sistema integral ERP
 Se trabajará con diagramas de modelado con UML 2.0 que reflejen la idea global del
sistema

1.9 Resumen del capítulo

Se decidió realizar este proyecto para una universidad pública debido a que es una queja
frecuente que, a pesar de trabajarse en la catedra de las tecnologías de información, es muy
frecuente que los organismos públicos de educación no cuentan ellos mismos con desarrollos de
productos de alta tecnología de información para su propia administración y control.

En los mejores casos se cuenta con diversos sistemas comprados a terceros o cedidos por otras
instituciones afines que han hecho algún avance, pero desafortunadamente el desarrollo de
software recibido es de un enfoque personalizado para aquella institución. Entonces se hacer
necesario invertir mucho tiempo y esfuerzo en personalizar o al menos aprovechar las funciones
básicas del producto recibido.

En este proyecto se utilizará el modelado mediante BPMN, UML 2.0, ITHINK y algunas otras
herramientas para realizar en primera instancia y como motivo de esta tesis, una representación
del funcionamiento real de la Universidad Tecnológica de Coahuila. La fuente inmejorable para el
inicio de los trabajos se constituirá en el sistema de Gestión de Calidad Certificado de la
Universidad, mismo que tiene ya 11 años certificado y está en marcha. Como en todo modelo se
tienen posibilidades de mejora de las interacciones entre procesos acercándolas al mundo real,
para ello se realizará una verificación de las funciones críticas que son: Servicios escolares y
Pagos de alumnos como punto de partida para una trabajo más amplio a nivel Universidad que
llevará gradualmente al establecimiento de las bases para contar con un software integral para la
operación de todas las funciones de la UTC a semejanza de un Enterprise Resource Planning
(ERP).

7
Como consecuencia de los primeros estudios de este proyecto, la rectoría y Secretaría
Académica de esta casa de estudios ya ha autorizado en febrero 2015 el desarrollo del producto
de software que resuelva las necesidades de las áreas críticas mencionadas. Interviniendo
directamente en ello el empleado que esto escribe.

II. Estado del arte sobre ERP y modelado en UML

2.1 Introducción

Desde finales de la segunda Guerra mundial, las innovaciones basadas en la tecnología han
tenido un crecimiento vertiginoso. Ellas se han visto como una fuente crucial de prosperidad
social, así como remedios para los problemas de negocios [12].
De hecho, la tecnología actualmente está acelerando la tranquilidad de las operaciones diarias
forzando a las empresas a tener la información exacta y disponible en todo momento. Estos
requerimientos comerciales han dado lugar al nacimiento de los sistemas Enterprise resource
planning (ERP) [13].

La idea detrás de los sistemas ERP es la de integrar las funciones del negocio en una base de
datos accesible a través de la red. La estrategia mercadológica de la venta de los ERP es que
ellos ofrecen integración de todo el negocio incluyendo recursos humanos, contabilidad,
Manufactura, Manejo de materiales y otros módulos importantes [14].
Esta integración significa procesos perfectamente alineados, mejores servicios a los clientes y
por consecuencia obtener valor agregado para la compañía. Desafortunadamente muchos
sistemas ERP no han visto cristalizar sus promesas [15]. Un factor causante del desencanto de
muchas compañías que han hecho en intento de implementar ERP’S es el problema de los
estándares de “Las mejores prácticas de negocios”.
Esas prácticas han causado confusión en las organizaciones debido a que en opinión de todos
las mejores prácticas varían en su interpretación en cada empresa. Este problema es complicado
por el hecho de que los sistemas empresariales se diseñan para cumplir con una gran cantidad
de reglas y regulaciones con los que interactúan los desarrolladores de estos. Adicionalmente
existe mucha confusión de las empresas públicas que los utilizan pues estos originalmente se
desarrollaron para la empresa privada. Lo que obliga a los desarrolladores a ser más creativos
teniendo como base de su éxito la creatividad e innovación [16];Siau, 1995, 1996, 1999, 2000;
Zawacki, 1993).

2.2. ERP

2.2.1 Conceptos básicos de ERP

Un Enterprise Resource Planning (ERP) es un componente de software desarrollado por terceros

“Off-The-Shelf” (OTS) que proporciona una plataforma de tecnología mediante la cual las
organizaciones pueden integrar y coordinar sus principales procesos internos de negocios. Cada
organización tiene necesidades distintas y los ERP necesitan una parametrización que depende
de estas necesidades [4].

La implantación de sistemas de gestión ERP en las empresas no es un fenómeno nuevo. Por lo

que a lo largo de los años ha pasado por diferentes etapas basadas en la idea de incorporar
mayor funcionalidad. Existe una gran cantidad de casos de éxito reportados y se aportan muchas
ventajas gracias a su implementación. Sin embargo las investigaciones demuestran que mientras
unas organizaciones tienen éxito en su implementación, otras tienen que aceptar beneficios
mínimos o abandonarla [5], e incluso algunas caen en bancarrota por perder el control en la
implementación [6].

8
Un problema comúnmente encontrado es el alineamiento en la adaptación del ERP [4,6], que
consiste en alinear los requisitos de los interesados en el proyecto (stakeholders) con los del
ERP. Esta necesidad de alineamiento nos lleva al problema común de los componentes OTS: La
selección apropiada y correcta del componente. En este caso un ERP.

Historia

El surgimiento de los ERP [26, 27] data de 1960 con la introducción en entornos industriales del
Inventory Management & Control. En ese momento el principal uso de software en dichos
entornos era para la gestión de inventario, y la mayor parte del software utilizado era hecho a
medida y diseñado según los conceptos tradicionales de gestión de inventarios. En 1970s
surgieron los llamados Material Requirement Planning (MRP). Con ellos se pretendía planificar
los materiales que serian necesarios durante el proceso de producción, y gestionar la adquisición
de dichos materiales. En 1980s evoluciona hacia los sistemas Manufacturing Requirements
Planning (MRP II). Estos sistemas incluían la gestión de la planta de fabricación y actividades
relacionadas con la distribución de los artículos fabricados, sincronizando los materiales con
requisitos de producción. En 1990s los MRP-II fueron ampliados, aun más, para abarcar áreas
como Ingeniería, Finanzas, Recursos Humanos, Gestión de Proyectos, etc.; es decir la totalidad
de las funciones desarrolladas dentro de una empresa. Fue esta evolución la que introdujo el
concepto de ERP. El mercado de los ERP creció rápidamente en los 90s entre otras razones
debido a que:

• El enfoque cliente/servidor se hizo popular en las empresas y los ERP fueron diseñados para
tomar ventaja de ello [6].

• Las implementaciones de ERP se convirtieron en catalizadores y facilitadores de muchas

actividades de reingeniería corporativa [6].

• Los ERP estaban ya adaptados para que no se vieran afectados por el problema del año 2000
(Y2K) [6, 28].

• La frontera de ERP fue presionada por proveedores (con organizaciones de investigación y

desarrollo) agresivos y poderosos [6].

Hoy en día, según [29] hay una transformación de ERP hacia ERP II. GartnerGroup [30] define a
ERP II como una transformación de ERP en una nueva generación de sistemas empresariales.
Una estrategia empresarial y un conjunto aplicaciones empresariales de dominio específico que
crea valor en clientes y accionistas al permitir la optimización del funcionamiento de las empresas
y de las relaciones existentes inter-empresas.

ERP II tiene como principal componente el soporte a los procesos de e-Business y la

colaboración en la cadena de suministro. El término e-Business hace particular referencia a la
adopción de Internet para fomentar las nuevas herramientas en el fortalecimiento de los procesos
de negocio y en la aceleración del objetivo de integración de la cadena de suministro.

ERP II tiene como objetivo la gestión de la cadena de suministro en su totalidad integrando y

coordinando actividades a través de la frontera de la organización.

En los últimos años sigue la tendencia de crecimiento de los ERP. Según declaraciones de Bo
Lykkegaard, encargado de la investigación europea de la empresa en ID parece ser el año del
retorno de los ERP en Europa occidental”. No se equivocaba, ya que [32] destaca que el 2006
fue un año con grandes ganancias para el mercado de los ERP, con unos ingresos que llegaron a
28 billones de dólares.

En el 2007, el mercado europeo de ERP se ha beneficiado del reemplazo de ERP implantado a

9
finales de los noventa, así como de una mejora en las condiciones de negocio en Europa en
general. Para este mismo año se preveía que el mercado de los ERP en Europa, Oriente Medio y
África generaría 6.7 mil millones euros en rédito total del software. Esto representa el crecimiento
de 5.7% comparados con 2006. En el estudio realizado por [33] se preveía que para ese mismo
año que el 17% de las empresas europeas planificaban una actualización en sus ERP.

Según [34], en España, el 61.9% del negocio total relacionado con los ERP (641,85 millones de
Euros) corresponde a servicios con unas ventas totales de 397.16 millones de Euros, de los
cuales el 29.2% corresponde a software, con unas ventas de 187.13 millones de Euros.

Por su parte, [32] estima que para el 2008 las ganancias estimadas serán de 35.8 Billones de
dólares, 39.4 billones de dólares, para el 2009, 43.4 billones de dólares para el 2010.

Definición y Características

El concepto de ERP se puede ver desde una gran cantidad de perspectivas [27], para el
desarrollo de esta tesis hemos considerado la definición de ERP aportada por [36] como la más
adecuada:

Un ERP es un paquete de software (packaged software), generalmente compuesto por múltiples

módulos, que ofrece soluciones integradas diseñadas para dar soporte a múltiples procesos de
negocio (recursos humanos, ventas, finanzas, producción, etc.), proporcionando una integración
de los datos de la organización con los procesos de negocio.

Un ERP tiene un diseño genérico para poder abarcar gran diversidad de empresas de tipos
distintos y por tanto con características muy variadas [27, 37] y por tanto refleja la forma en la que
en general operan las empresas [6]. Por esta razón necesitan una configuración personalizada
para cada empresa partiendo de una parametrización inicial del ERP (la parte que es común a
todas las empresas), definiendo valores asignados a los parámetros de control del ERP durante
la implementación, lo que determina las operaciones y procesos exactos que soportara el ERP en
una empresa específica [38, 39].

Por tanto podemos decir que las características que distinguen a un ERP de cualquier otro
software empresarial son que deben de ser sistemas [40]:

• Integrales. Deben permitir controlar los diferentes procesos de la organización, entendiendo que
todos los departamentos de una empresa se relacionan entre si. Por lo que:

• Poseen una base de datos centralizada controlando así la redundancia de los datos [27].

• Los datos se ingresan sólo una vez y deben ser consistentes, completos y comunes.

• Están diseñados para trabajar en varios países, por lo cual pueden manejar requisitos
específicos a diferentes regiones [27].

• Modulares. Una empresa está formada por un conjunto de departamentos que se encuentran
interrelacionados por la información que comparten y que se genera a partir de sus procesos. Los
ERP, tanto económica como técnicamente, deben tener dividida su funcionalidad en módulos [27,
36], los cuales pueden instalarse de acuerdo con los requisitos del cliente. Por lo que:

• Soportan una alta funcionalidad de negocio, brindando funciones de negocio, especialmente

producción, logística, manejo de materiales, ventas, distribución, financieras, contables,
plantación estratégica, gestión de calidad y compras [27].

• Sus módulos interactúan entre sí consolidando todas las operaciones (llamado funciones
cruzadas), por lo que en muchas ocasiones el usuario no se da cuenta en qué modulo esta

10
trabajando [27].

• Adaptables. Deben estar creados para adaptarse a la idiosincrasia de cada empresa (debido a
que son un paquete de software estándar [27]). Esto se logra por medio de la configuración o
parametrización de los procesos de acuerdo con los requisitos específicos de la empresa. La
parametrización es el valor añadido fundamental que se debe hacer con cualquier ERP para
adaptarlo a las necesidades concretas de cada empresa. Por lo que:

• Imponen su propia lógica a la estrategia, organización y cultura de la empresa [6, 27]. Las
empresas que los implantan suelen tener que modificar alguno de sus procesos para alinearlos
con los del ERP. Este proceso se conoce como Reingeniería de Procesos [23].

• La tendencia actual es que ofrezcan también funcionalidades especializadas para determinadas

empresas [27] (hospitales, universidades, gobierno, etc.). Es lo que se denomina versiones
sectoriales o aplicaciones sectoriales especialmente indicadas o preparadas para determinados
procesos de negocio de un sector.

Dichas características inducen a que las empresas tengan una serie de ventajas si implementan
un ERP, respecto a una solución más tradicional:

• Optimización de los procesos empresariales.

• Acceso a información confiable, precisa y oportuna.

• Mejoras en la comunicación entre las áreas de producción.

• Reducción en la duplicidad de información.

• Mayor eficiencia en la integración de los procesos comerciales.

• Reducción de tiempos en los costos de los procesos.

• Mayor información para la toma de decisiones.

• Extensión de las mejores prácticas y difusión de conocimiento a lo largo de la organización.

Claramente las ventajas de la implementación de un ERP son enormes y existe una gran
cantidad de casos de éxitos registrados. Esto provoca en las empresas la prisa por implementar
un ERP sin tener un claro entendimiento de los procesos de negocio y por tanto de sus requisitos
[6]. Este desconocimiento trae como resultado una ineficaz selección del ERP y por tanto del
alineamiento de los requisitos de la empresa con los del ERP. Trayendo como resultado una gran
cantidad de casos de fracaso en la implementación.

2.2.2 Modelo conceptual de un ERP

Los autores han reconocido la falta de literatura asociada con los modelos conceptuales de los
ERP basados en tecnología orientada a objetos. Esta tecnología ha ido ganando atención para
atenuar la crisis del software [52]. Esto significa que la tecnología actual orientada a objetos
puede ser usada para desarrollar sistemas de información para negocios, incluyendo sistemas
ERP. El modelado de sistemas orientados a objetos implica las fases de análisis y diseño
utilizando tecnología orientada a objetos [44]. El modelado orientado a objetos ha probado ser
una técnica excelente para modelar procesos de negocios en una empresa [53]. Recientemente,
el modelado de negocios es una nueva área para modelado orientado a objetos y ha generado
mucho interés.
En general, un modelo es una abstracción de un sistema, especificando el sistema modelado
desde cierto punto y cierto nivel de abstracción [49]. Modelar un sistema complejo es una tarea

11
extensa y complicada. Idealmente, los autores suponen que el sistema entero puede ser descrito
en un solo diagrama. Un solo diagrama define claramente el sistema total de manera no
ambigua, y es fácil de comunicar y entender porque el sistema total puede ser identificado a la
vez [60]. Sin embargo, es generalmente imposible o muy difícil describir todo el sistema en un
solo diagrama debido a que la mayoría de los sistemas de información de negocios son grandes
y complicados. De tal modo que un solo diagrama no puede captar toda la información necesaria
para describir un sistema entero [60]. Cuando los autores están modelando un sistema, el
sistema el sistema puede ser descrito en varios aspectos: Funcional, no funcional y
organizacionalmente. Por eso, los sistemas ERP pueden ser descritos en varias vistas, cada una
representa una proyección de la descripción total del sistema, mostrando un aspecto particular
del sistema. En UML, cada vista es descrita en varios diagramas que hacen énfasis en un
aspecto particular del sistema [60].
El UML es un lenguaje de modelado estándar de la industria adoptado por el Object Management
Group (OMG) en 1977. UML es un lenguaje de modelado que pretende describir modelos de
sistemas – mundo real y software – basados en el concepto de objetos [55]. Debido a que la
meta de UML es describir cualquier tipo de sistemas, UML puede ser usado para modelar
sistemas, el rango de los cuales puede ser muy amplio [13]. UML consta de 2 herramientas
principales: una notación y un meta modelo [58]. La notación es un conjunto de sintaxis de
diagramación, la cual le permite pensar y precisar su análisis y diseño. El meta modelo es la
definición de la notación. UML es una notación rica y complicada para describir sistemas de
software. [58].
Las perspectivas son las vistas con las que vemos los sistemas y describimos diferentes
aspectos de los requerimientos del usuario. En la sección siguiente, los autores discuten varias
vistas de los stakeholders para describir el modelo conceptual de un ERP.

Research Framework

Similarmente a la industria de la construcción, la arquitectura de un sistema ERP se describe en

diferentes vistas del sistema que se desarrolla. Las diferentes vistas se usan para hacer más
visibles las características más importantes del sistema. La arquitectura del sistema es una visión
del sistema completo. La arquitectura del sistema es quizás el artefacto más importante que
puede utilizarse para administrar esos diferentes puntos de vista.
De acuerdo a UML y al Rational Unified Process (RUP), el punto de vista de describir sistemas
está basado en las vistas “4+1” de UML. La figura 1 representa las vistas “4+1” de UML para
describir la arquitectura de sistemas [48] [60]. La vista de casos de uso de un sistema representa
los casos de uso que describe el comportamiento del sistema visto por sus usuarios finales,
analistas y probadores. En otras palabras, describe la funcionalidad que debería proporcionar el
sistema, cómo es percibida por actores externos. Y especifica las fuerzas que abarca la
arquitectura del sistema. En UML se captura en los diagramas de casos de uso y de vez en
cuando en diagramas de actividad. La vista lógica de un sistema incluye: clases, interfaces y
colaboraciones, que se detectan en la narrativa del problema y de su solución. Soportan los
requisitos funcionales del sistema. En UML, se captura en diagramas de clase, diagramas de
objetos, diagramas de estado, diagramas de secuencia, y diagramas de actividad.

12
 Figura 1 “La vista 4 + 1” del Modelo de Arquitectura

La vista de implementación de un sistema implica los componentes y los archivos que se utilizan
para montar y para lanzar el sistema físico. Se dirige a la gerencia de configuración de las
versiones del sistema. En el UML, está por los diagramas componentes, los diagramas de
interacción y los diagramas de la actividad.
La vista de proceso de un sistema consiste en los hilos y los procesos que forman los
mecanismos de la concurrencia y de la sincronización del sistema. Presentan el funcionamiento,
la capacidad de conversión a escala, y el rendimiento de procesamiento del sistema. En UML, es
capturada por las mismas clases de diagramas que para la visión lógica. La vista de despliegue
de un sistema abarca los nodos que forman la topología del hardware de sistema en la cual el
sistema ejecuta. Describe la distribución, la entrega, y la instalación de las partes que componen
el sistema físico. En UML, se captura en diagramas de despliegue, diagramas de la interacción, y
diagramas de la actividad.
Las vistas “4+1” permiten al desarrollador comprender un sistema complejo en términos de sus
características esenciales. Además de la breve explicación de cada vista, es necesario recordar
que las vistas “4+1” de la arquitectura del sistema no son totalmente independientes [60]: el
diagrama de secuencia y el diagrama de colaboración representan el modelo de la interacción del
caso del uso. Los elementos de una visión están conectados con los elementos en otras vistas.
En la sección siguiente, los autores representan resultados de modelar el sistema conceptual del
ERP usando vistas “4+1”. El modelo conceptual del ERP se puede describir con varios diagramas
de la notación de UML. El modelo conceptual del ERP que es introducido en la sección siguiente
depende de una situación verdadera.

Modelo conceptual del ERP

Puesto que la industria de Corea depende fuertemente de la exportación, las negociaciones entre
los países y la manufactura se convierte en un sector importante. Ahora, hay muchas compañías
de manufactura en Corea pequeñas y medianas y ellas hacen con impaciencia su mejor
esfuerzo para la supervivencia en el entorno empresarial electrónico mundial. Es cada vez más
difícil para las pequeñas y medianas compañías sostener un negocio. Debido a la competencia
entre las compañías del mundo se ha calentado al máximo como se abre la economía mundial y
el entorno empresarial llega a ser más global y cambia rápidamente. Ellos no se preparan lo
suficiente con el reajuste del sistema empresarial y del proceso de negocio para ajustarse a los
entornos empresariales internacionales y radicalmente cambiados. Así, muchas compañías
pequeñas y de tamaño mediano, así como compañías de gran tamaño substituyen sus sistemas
ERP, se supone que deberán adoptar un nuevo sistema de ERP que empate con el cambio de
estrategias [42].
Sin embargo, las compañías pequeñas y de tamaño mediano no tienen la misma estructura de
organización ni tanto capital como las compañías de gran tamaño. Los sistemas comerciales
ERP como: Oracle, SAP, y Baan tienen módulos numerosos engranados a las necesidades de
compañías de gran tamaño. Además, es difícil resolver los muchos problemas asociados a
requisitos únicos tales como los sistemas de facturación, porque estos ERP soportan estándares
globales [65]. Hay un riesgo elevado al implementar un paquete comercial de ERP a las

13
compañías pequeñas y de tamaño mediano. Por lo tanto, las compañías pequeñas y de tamaño
mediano necesitan un acercamiento diferente a los sistemas del ERP que el de las compañías de
gran tamaño.
Las funcionalidades de los sistemas ERP se pueden clasificar generalmente en cinco áreas [46].
Primero, los sistemas ERP proporcionan la función para administrar la manufactura híbrida. Por
lo tanto, podemos controlar la multiplicidad de requisitos en conflicto de los usuarios. En segundo
lugar, utilizando la función de simulación, los sistemas ERP tienen la capacidad de Master
Production Schedule /Material Requirements Planning (MPS/MRP) a multinivel. Eso elimina
tiempo de proceso y planeación múltiple. Tercero, los sistemas ERP tienen un alto nivel de
capacidad de integración con el sistema interno y con el sistema externo, el proceso de negocio
y los datos. Cuarto, los sistemas ERP pueden estarse ejecutando en plantas múltiples
simultáneamente con diverso sistema operativo. Así las compañías pueden operar
organizaciones de negocios globales. Finalmente, los sistemas ERP deben soportar operaciones
en múltiples lenguas. Por lo tanto, cada usuario puede tener la capacidad de utilizar su lengua
nacional.
En esta sección, los autores introducirán un modelo conceptual del ERP para las compañías
pequeñas y medianas basadas en funcionalidades de sistemas ERP. Un sistema ERP consiste
de cinco subsistemas: fabricación, ventas, recursos humanos y nómina, comercialización y
contabilidad. Primero, el subsistema de “manufactura” maneja toda la información con respecto a
la manufactura: Artículos, Lista de materiales, de inventarios, compras, de planeación del
producto, producción, producción externa, de equipos y de la calidad. El término “artículo” incluye
partes, semi-productos y productos. Más adelante será explicado utilizando los diagramas. En
segundo lugar, el subsistema de las “ventas” consiste en las funciones de: Administración de
propuestas, administración de órdenes, administración del contrato, administración del envío,
administración de devoluciones, y administración del cliente. Las tareas del negocio para las
ventas pueden incluir los pasos siguientes: (1) al principio identificar al cliente donde está
registrado, (2) proponer al cliente para el producto, recibir la orden del cliente y hacer un contrato
con el cliente para la orden detalladamente, (3) embarcar las mercancías del contrato, y (4)
finalmente completar el proceso de mercancías devueltas. Si no identifican al cliente, el
subsistema de las ventas registra los datos del cliente, y administra los datos de los resultados,
de la valoración y del análisis sobre cliente. Tercero, el subsistema del “recursos humanos y de la
nómina de pago” proporciona la eficacia para la administración de la información del recurso
humano y la administración integrada de la nómina de pago y el establecimiento de la
contabilidad. Consiste en administrar la información del recurso humano, administrar el bienestar
público, maneja la nómina de pago, y maneja el establecimiento de la contabilidad. Cuarto,
comparando con otro sistema ERP, el subsistema de “comercialización” es un subsistema único
en el modelo de sistema del ERP. Proporciona la integración y la eficacia para los procesos de
las importaciones y exportaciones de la compañía. Incluye el formato estándar del documento
para el intercambio de datos electrónicos y tiene información comercial en la consideración a las
reglas internacionales del comercio. Consiste en administrar al comprador, administrar las
ofertas, administrar órdenes, administrar cartas de crédito, administrar los embarques,
administrar los ingresos, y administrar la demanda. Finalmente el subsistema de la “contabilidad”
proporciona eficacia y la flexibilidad para el proceso de la contabilidad. Utiliza la base de datos
integrada y guarda la información de contabilidad correcta. Puede ser clasificado en administrar
la contabilidad general, administrar la contabilidad de los impuestos, administrar presupuestos y
fondos, y administrar la contabilidad directiva.

Use Case View

Un caso de uso son las interacciones típicas entre el usuario y el sistema ERP y describe
funcionalidades de un sistema ERP [48] [63]. Un diagrama de caso del uso muestra un conjunto
de casos de uso, de actores, y de relaciones entre los actores y los casos del uso. El propósito
del diagrama del caso del uso es demostrar un contexto de un sistema ERP. En esta sección, los
autores describen dos diagramas del caso del uso. Uno demuestra la división de un sistema
entero en subsistemas. Las otras demostraciones de cómo describir uno de los subsistemas,
“Manufactura” detalladamente.

14
Un sistema ERP es un paquete muy grande y complejo. Los autores primero dividen el sistema
entero del ERP en subsistemas. Comúnmente, los subsistemas pueden ser definidos y ser
utilizados para organizar sistemas de información en gran escala en uno más pequeño y para
hacerlos más comprensibles o manejables para poderlos describir más fácilmente a las otras
personas [61]. Según las indicaciones de la figura 2, un modelo conceptual del ERP se puede
dividir en cinco subsistemas: Fabricación, ventas, recursos humanos y nómina, comercio y
contabilidad.

Fig. 2 diagrama de caso de uso de alto nivel

En el diagrama de caso de uso de alto nivel, cada caso del uso representa un subsistema a
excepción de caso del uso “ManageLogin”. Cada actor de los casos de uso:
ManufacturingManager, SalesManager, recursos humanos/PayrollManager, TradingManager, y
AccountingManager, es representado por la persona externa asociada al subsistema. Por
ejemplo, cuando describimos el subsistema de la “Manufactura” detalladamente, el agente
“ManufacturingManager” puede ser dividido en el encargado del control de producto, encargado
de la compra, encargado del plan de producto, Producción Encargado y Calidad Encargado
demostrado en la figura 3.

15
 Fig. 3 Diagrama de caso de uso del subsistema de Manufactura

En la figura 3, los autores describen el diagrama del caso del uso enfocado en el subsistema de
“Manufactura”. Según lo mencionado en la sección anterior, ERP es el sucesor de Material
Resource Planning II (MRP II) y tuvo sus orígenes en los sistemas de planeación de la
fabricación y de Manufactura. Además, los autores desarrollaron un modelo conceptual del ERP
para las empresas de manufactura pequeñas y medianas. Por lo tanto, los autores creen que el
subsistema de “manufactura” es la base del Modelo conceptual del ERP y otros subsistemas
puede ser derivados de este.
Según lo visto en la figura 3, el subsistema de “manufactura” consiste en nueve funcionalidades
Casos de uso de:

ManageItems
ManageBillOfMaterials,
ManageInventories,
ManagePurchasing,
ManageProductPlans,
ManageProduction,
ManageOutsideProduction,
ManageEquipments, y
ManageQuality.

En el diagrama de casos de uso, las relaciones entre los casos del uso se representan usando
estereotipo <<extend>> Por ejemplo, los casos de uso ManageBillOfMaterials y
ManagePurchasing comparten funcionalidad de la parte del caso de uso ManageItems. Cuando
se requieren los datos de la producción exterior, el caso de uso ManageProduction se pueden
ampliar al caso de uso ManageOutsideProduction. Y los actores, TradingSubsystem,
SalesSubsystem, AccountingSubsystem, Human Resources y PayrollSubsystem, representan

16
los sistemas externos relacionados con subsistema de “Manufactura”. Es decir cada subsistema
puede ser agente relacionado con el otro subsistema.

Fig. 4 diagrama de clase del subsistema de “Manufactura”

Logical View

Un diagrama de clases describe la vista estática del sistema del ERP en términos de clases y
relaciones entre las clases [48] [57]. Cuando describimos el diagrama de clases del subsistema
de “Manufactura”, agrupamos clases en nueve paquetes de clases demostrados en la figura 4.
Cada paquete de clases corresponde al caso de uso de la figura 3 diagrama de caso del uso.
El diagrama de clase del subsistema de la “Manufactura” describe relaciones entre las clases con
la relación de la dependencia y la relación de la asociación. Las relaciones de la dependencia
entre los paquetes de la clase demuestran que un cambio del paquete “ManageItems” de la clase
puede afectar a los otros paquetes de las clases: ManageInventories, ManagePurchasing,
ManageEquipments, ManageProduction, ManageOutsideProduction, ManageBillOfMaterials,
ManageQuality, y ManageProduction, y proporcionan la información necesaria por otros paquetes
de clases [47]. Es decir todos los paquetes de clases son dependientes del paquete de clases
“ManageItems”. Indica que el paquete de clase de “ManageItems” representa una clase núcleo
en la ejecución de las funcionalidades del subsistema de manufactura. Y la relación de la
asociación representa las relaciones entre las clases que se incluyen en cada paquete.
Las clases en cada paquete de clases no se describen detalladamente: no se incluye ningún
atributo ni operaciones. Debido a la descripción elaborada de clases no es importante en el
modelado conceptual. Es importante en la fase del diseño y de implementación.

4.3 Process View

Un diagrama de secuencia ilustra cómo los objetos obran recíprocamente uno con otro. Acentúa
en cómo los mensajes se envían y se reciben entre los objetos [48] [57]. Para representar el

17
ejemplo del diagrama de secuencia, elegimos “ManageInventories” entre los casos de uso
mostrados del subsistema de “Manufactura”.

Fig. 5 diagrama de secuencia del caso de uso de “Inventory”

Muchos escenarios se pueden describir en un solo caso de uso y un escenario se relaciona con
un diagrama de secuencia. Así como un caso de uso puede tener muchos diagramas de
secuencia. En la figura 5, el diagrama de secuencia representa simplemente el escenario
primario a relacionar con la administración de inventario a excepción de alternativa, de error, y de
la extensión. Por ejemplo, la operación creat(Stock-In_list) recibe datos de :PurchasOrder y
:ItemObject. Y la información de :Stock-In: actualizaciones de la clase :Inventory. Éste es un
proceso de “Manage Stock-In” funciona en el caso de uso “Manage Inventories”.

4.4 Deployment View

Un diagrama de despliegue demuestra la descripción física de la topología del sistema, el incluir
la estructura de las unidades de hardware y software que se ejecuta en cada unidad [48] [57].
Seleccionamos 2 arquitecturas con capas de cliente/servidor para la estructura del hardware del
sistema ERP. Debido a que las compañías pequeñas y medianas tienen debilidad en el
presupuesto, quieren un sistema ERP barato.
Para adoptar los patrones que describen las relaciones entre subsistemas, nosotros elegimos
secuenciar y filtrar el patrón arquitectónico mostrado en la figura 6. En el patrón arquitectónico de
secuenciar y filtrar, cada parte es independiente una de otra y dependiente en la única fecha. Por
lo tanto sin cambiar el subsistema relacionado, los subsistemas pueden ser agregados y
substituidos.

18
 Fig. 6. diagrama de despliegue del modelo conceptual del ERP

Según se muestra en la figura 6, se incluyen dos nodos: Cliente y servidor. El nodo del servidor
consiste en el Web, la base de datos y cinco subsistemas. La base de datos administra los datos
integrados relacionados con todos los subsistemas y el Web tiene el papel de conectar el cliente
y los subsistemas. Y la adopción de la tecnología Web al ERP es importante puesto que los
negocios por Internet se publican en la tecnología de la información y el área comercial.
En el punto de vista de los clientes, el cliente puede tener acceso fácilmente al sistema del ERP y
al servidor web de aplicaciones da a los desarrolladores de aplicaciones empresariales la
flexibilidad para combinar la funcionalidad del ERP con las otras fuentes de datos y para inyectar
nueva lógica de negocio sin cambiar cualquier nada en los procesos del ERP [56]. Las
compañías pequeñas y medianas no tienen mucho presupuesto. Quieren reducir el costo de
hardware adoptando sistemas ERP. Así un servidor consiste en un componente de hardware que
incluye el servidor Web y el servidor de base de datos. Por ejemplo, MS Access se utiliza para
servidor de base de datos.

4.5 Implementation View

Un diagrama de componentes muestra componentes de software y sus dependencias el uno con
el otro, representando la estructura del código. Los componentes son la puesta en práctica en
arquitectura física de los conceptos y de la funcionalidad [48]. El diagrama de componentes no se
encuentra en la fase de análisis. Puesto que el modelo conceptual es comúnmente deducido a
partir de la fase de análisis. Es decir el modelo conceptual tiene la ventaja fuertemente de
acentuar su enfoque en conceptos del dominio, no en entidades del software, tales como
componentes del tipo de archivo. El diagrama de componentes se puede capturar después de la
fase de puesta en práctica o implementación. Hasta ahora, nosotros demostrado varios
diagramas y explicado cada diagrama brevemente. La razón de que utilizamos las vistas “4+1”
fue para describir el modelo conceptual del ERP es que las vistas de los interesados
(stakeholders) son diferentes según las perspectivas al mirar el sistema ERP. Es decir las vistas
“4+1” de la arquitectura son la mejor manera de representar puntos de vista de los stakeholders

19
5. Resultados e implicación

El sistema ERP integra relaciones de: clientes, finanzas, manufactura, inventario, ventas,
recursos humanos y nómina, servicio de campo y cualesquiera otra área de negocio: “logra que
todos los sistemas se hablen el uno al otro,” explicó Sean Fleming [41]. También proporciona
integridad de datos a través de los procesos de negocio. Ahora, el sistema ERP es la aplicación
de software de uso más común para todas las industrias, especialmente las empresas de
manufactura para adoptar entornos empresariales cambiados. En este papel, los autores
representan un modelo conceptual del ERP utilizando UML como técnica de modelado orientada
a objetos. Usando el modelo conceptual del ERP, los desarrolladores del ERP para las
compañías pequeñas y de tamaño mediano pueden obtener muchas ventajas.

El modelo conceptual del ERP junto con el diseño y la puesta en práctica se puede utilizar
durante todo el ciclo de vida de software porque los límites entre el análisis, el diseño y la
implementación no son rígidos [50]. Se llama “ausencia de costuras”. La ausencia de costuras
debe dar considerables ventajas: la flexibilidad y la rastreabilidad hacen a los sistemas ERP de
mejor calidad. También es mucho más fácil mantener sistemas ERP porque un cambio de
requisitos se puede rastrear fácilmente. Y los artefactos de la fase inicial serían utilizados durante
el ciclo de vida del software sin re trabajo adicional en los resultados y entonces se hacen más
eficientes los procesos de desarrollo del software y de implementación [55]. Además, debido a la
reutilización de los artefactos de fases anteriores, el proceso de desarrollo de software se ha
mejorado por la eliminación de algunos pasos de desarrollo del software [59]. El modelo
conceptual del ERP simplifica la funcionalidad de los sistemas ERP. La simplificación del sistema
hace más fáciles de entender los requisitos del ERP. Comúnmente, un mejor sistema es más fácil
de entender, de implementar y de mantener para los usuarios y los desarrolladores.
Los autores eligen el patrón arquitectónico de secuencia y filtrado, así que la nueva funcionalidad
necesaria en el negocio puede ser insertada más fácilmente en el modelo del ERP como cambio
en los requisitos del negocio [51]. Es decir, es posible agregar y suprimir subsistemas en
cualquier momento sin tener que cambiar los otros subsistemas. Cada subsistema, descrito por el
caso de uso en el diagrama del caso de uso de alto nivel, es independiente uno del otro. Las
compañías pequeñas y medianas son inferiores en organización, en recursos humanos, y en la
utilización del proceso de negocios internacional respecto a las compañías grandes. El modelo
conceptual del ERP podría ayudar a los desarrolladores de las compañías pequeñas y medianas
para entender los sistemas ERP claramente y para desarrollar sistemas ERP más fácilmente.
Adoptando el modelo del ERP, las compañías pequeñas y medianas pueden adquirir sistemas
del ERP más con eficacia.

2.2.3 Funciones generales de los ERP

Las funcionalidades de los sistemas ERP se pueden clasificar generalmente en cinco áreas [46].
Primero, los sistemas ERP proporcionan la función para administrar la manufactura híbrida. Por
lo tanto, podemos controlar la multiplicidad de requisitos en conflicto de los usuarios. En segundo
lugar, utilizando la función de simulación, los sistemas ERP tienen la capacidad de proporcionar
la funcionalidad de Master Production Schedule /Material Requirements Planning (MPS/MRP) a
multinivel. Eso elimina tiempo de proceso y planeación múltiple.

Tercero, los sistemas ERP tienen un alto nivel de capacidad de integración con el sistema interno
y con el sistema externo, el proceso de negocio y los datos. Cuarto, los sistemas ERP pueden
estarse ejecutando en plantas múltiples simultáneamente con diverso sistema operativo. Así las
compañías pueden operar organizaciones de negocios globales. Finalmente, los sistemas ERP
deben soportar operaciones en múltiples lenguas. Por lo tanto, cada usuario puede tener la
capacidad de utilizar su lengua nacional.

Un sistema ERP consiste de cinco subsistemas: fabricación, ventas, recursos humanos y nómina,
comercialización y contabilidad. Primero, el subsistema de “manufactura” maneja toda la

20
información con respecto a la manufactura: Artículos, Lista de materiales, de inventarios,
compras, de planeación del producto, producción, producción externa, de equipos y de la calidad.

El término “artículo” incluye partes, semi-productos y productos. Más adelante será explicado
utilizando los diferentes diagramas. En segundo lugar, el subsistema de las “ventas” consiste en
las funciones de: Administración de propuestas, administración de órdenes, administración de
contratos, administración de embarques, administración de devoluciones, y administración del
cliente.

Las tareas del negocio para las ventas pueden incluir los pasos siguientes: (1) al principio
identificar al cliente donde está registrado, (2) proponer al cliente para el producto, recibir la orden
del cliente y hacer un contrato con el cliente para la orden de manera detallada, (3) embarcar las
mercancías del contrato, y (4) finalmente completar el proceso de mercancías devueltas.

Si no se identifica al cliente, el subsistema de ventas registra los datos del cliente, y administra
los datos de los resultados de la valoración y del análisis sobre el cliente. Tercero, el subsistema
de “recursos humanos y de la nómina” proporciona la eficacia para la administración de la
información del recurso humano y la administración integrada de la nómina de pago y el
establecimiento de la contabilidad. Consiste en administrar la información del recurso humano,
administrar el bienestar público, administrar la nómina, y admnistrar el establecimiento de la
contabilidad. Cuarto, comparando con otro sistema ERP, el subsistema de “comercialización” es
un subsistema único en el modelo de sistema del ERP. Proporciona la integración y la eficacia
para los procesos de las importaciones y exportaciones de la compañía. Incluye el formato
estándar del documento para el intercambio de datos electrónicos (EDI) y tiene la información
comercial en consideración a las reglas internacionales de comercio. Consiste en administrar al
comprador, administrar las ofertas, administrar órdenes, administrar cartas de crédito, administrar
los embarques, administrar los ingresos, y administrar la demanda. Finalmente el subsistema de
“contabilidad” proporciona eficacia y la flexibilidad para el proceso de la contabilidad. Utiliza la
base de datos integrada y guarda la información de contabilidad correcta. Puede ser clasificado
en: administrar la contabilidad general, administrar la contabilidad de los impuestos, administrar
presupuestos y fondos, y administrar la contabilidad directiva.

2.2.4 Aplicaciones de los ERP

2.2.4.1 En las universidades

Los sistemas ERP son las aplicaciones informáticas más grandes adoptadas por las
universidades, junto con inversiones absolutamente significativas en su implementación. Sin
embargo, a diferencia de otras aplicaciones poca investigación se ha conducido con respecto a
estos sistemas en un ambiente universitario.

La educación superior ha estado influenciada fuertemente estos últimos años por tendencias
globales, especialmente como resultado de los exhortos de los gobiernos a las universidades de
todo el mundo a mejorar su funcionamiento y eficacia [76].

Cumplir con las expectativas de los interesados (particularmente estudiantes y gobiernos), con
los requisitos de calidad y de funcionamiento, y los ambientes competitivos de educación, junto
con la disminución de la ayuda gubernamental, han ejercido presión sobre las universidades de
todo el mundo para adoptar nuevas estrategias para mejorar su funcionamiento [81]. Por lo tanto,
el sector de educación superior ha puesto sus ojos en los sistemas de planeación de los recursos
de la empresa (ERP) con la esperanza de que los ayude a hacer frente al ambiente cambiante
[86]. Consecuentemente, la administración existente y los sistemas computacionales
administrativos han sido substituidos por sistemas ERP en esas instituciones [89], para alcanzar
más eficacia y accesibilidad para todos los miembros y para mejorar el funcionamiento de los
usuarios finales proporcionando mejores herramientas directivas [85].

21
El volumen de la inversión en estos sistemas ERP ha sido substancial. En los últimos años las
instituciones de educación superior gastaron más de 5 mil millones de dólares en inversión en
sistemas ERP. La finalidad de la implementación del ERP en universidades es proveer a las
universidades, escuelas y departamentos, con una capacidad realzada para la investigación y
enseñanza a un costo razonablemente bajo [90]. Desafortunadamente sin embargo, se ha
reclamado que aproximadamente del 60% al 80% de todos los sistemas ERP no han podido
obtener los resultados previstos [87], mientras que otras implementaciones no mejoraron su
funcionamiento con los usuarios que expresaban explícitamente el descontento con su
funcionamiento.

A la luz de estos hechos y debido a las inversiones significativas de los recursos hechos por
organizaciones para adoptar o para cambiar al sistema ERP, los investigadores tienen un deseo
fuerte de explicar las causas y los factores que llevan al buen funcionamiento con ERP [84], qué
factores influencian la puesta en práctica exitosa y fallida, y las razones detrás de los problemas
que ocurren con la implementación de los sistemas ERP [84], [75], [91].

Las investigaciones anteriores en esta área han intentado contestar a las preguntas antedichas
y/o encontrar soluciones a estos problemas en el nivel de organización. Sin embargo, la
investigación en los aspectos del nivel de usuario y los aspectos resultantes es todavía ambigua
y confusa. Las instituciones de educación superior invierten extensivamente en sistemas ERP
pero encuentran difícil identificar las ventajas derivadas de estos usos en términos del
rendimiento de sus empleados, que se debería reflejar en los resultados y los servicios de la
organización. Por lo tanto, la evaluación rigurosa que captura la tecnología del ERP, usuarios y
resultados de la organización es deseable. Con este fin, se presenta en este estudio una revisión
crítica sobre la investigación anterior en sistema ERP en educación superior, con un enfoque
especial sobre educación superior australiana. Esta revisión ayudará a evaluar la investigación
anterior y determinar la investigación necesaria en esta área e identificar la rentabilidad de los
ERP en este sector. Múltiples perspectivas se consideran en esta revisión, especialmente la
perspectiva del usuario.

Significado y contribución

Los sistemas ERP son a menudo la aplicación informática más grande adoptada por las
universidades con las cantidades de recursos significativas asignadas a su implementación. Sin
embargo, poca investigación se ha conducido sobre los ERP en el ambiente universitario,
comparado a otros ambientes [88]. Las universidades difieren de otras organizaciones porque
tienen diversos ambientes y circunstancias, y utilizan las tecnologías del ERP para propósitos
académicos [87].

La facultad y el personal comúnmente interactúan con actividades institucionales clave a través

de los ERP, y los estudiantes necesitan más información y mejores ambientes de aprendizaje
electrónico (E-Learning). En suma, esto significa que el sistema es, por definición, crítico a la
misión de las instituciones. Además, estas organizaciones son organizaciones gubernamentales
y realizan sus actividades para propósitos lucrativos y no lucrativos, que pudieran hacer funcionar
a los sistemas ERP de estas organizaciones con diversas concomitancias, especialmente con el
alto porcentaje de las implementaciones fallidas.

Todas estas consideraciones llevan a las preguntas críticas sobre el éxito y la ventaja de los ERP
para esas organizaciones. La pieza clave de estas consideraciones centraliza el enfoque del
estudio en si el sistema mejora el rendimiento del usuario, y también si los sistemas ERP
cumplen los requisitos del personal en ambientes de educación superior. Por lo tanto, estudiando
los impactos de los sistemas del ERP en el rendimiento del usuario es una manera significativa
de determinar la utilidad de estas aplicaciones en instituciones de educación superior y cómo
contribuyen a la eficiencia y a la eficacia [77] del rendimiento.

Cuando los sistemas ERP se observan detalladamente en las organizaciones de negocios, allí sí

22
rinden ventajas significativas [80], por ejemplo el acceso mejorado a la información exacta y
oportuna [85], [83]. Sin embargo, las instituciones de educación superior no aprovechan el
potencial de los sistemas ERP debido a la poca exitosa implementación y adopción de esas
aplicaciones. Por ejemplo, en Australia un estudio reciente conducido por [82], encontró que muy
pocos proyectos del sistema ERP se implementaron con éxito. Además, cuando la
implementación del sistema de información falla, una causa pudiera ser su inhabilidad de resolver
las expectativas de sus grupos de interesados [92]. Por lo tanto, proporcionar el conocimiento
sobre el ajuste entre las aplicaciones del ERP y las necesidades de los usuarios en esas
instituciones, debería ayudar por lo menos a evitar cualquier falla causada por las
incompatibilidades entre el sistema y las necesidades de los usuarios.

Discusión

El porcentaje de fallas en la implementación del ERP es muy alto, entre otros obstáculos
encontramos que, los problemas técnicos, y los factores críticos incluyendo el apoyo de la alta
administración, el entrenamiento y obstáculos de la gente se han citado como barreras
importantes [79]. Por lo tanto, durante la última década los investigadores han estado interesados
en los sistemas ERP, especialmente en sus factores de falla. Como resultado al anterior trabajo
concentrado extensivamente en esos factores que afectan críticamente a la implementación del
ERP y contribuyen al éxito del sistema. Esta tendencia ha continuado en detrimento de las
investigaciones tanto en aspectos del usuario como en los factores de éxito de la
implementación.

Para entender más los impactos de la puesta en práctica del ERP en las organizaciones, esta
investigación intenta evaluar impactos reales del sistema del ERP en su funcionamiento del
usuario usando un marco teórico establecido. Esto empieza con la proposición de que los
sistemas de información no pueden solo afectar a la productividad por si mismos, con el factor
principal de que la eficacia yace en la manera en que la gente utiliza estas tecnologías [78]. Así
los usuarios del sistema se convierten en uno de los factores más importantes de crear ventajas
a partir de estas tecnologías. Así, esta noción debería dar especial atención para entender más
completamente las tecnologías del ERP y cómo estas tecnologías pueden mejorar el
funcionamiento de la organización. Sin embargo, hay una carencia de investigación empírica
apoyada sobre beneficios del funcionamiento del sistema y del usuario del ERP. Esta ausencia
es el factor principal de la motivación para evaluar los impactos de los ERP en funcionamiento del
usuario examinando a las instituciones de educación superior desde el punto de vista del usuario,
reconociendo al usuario como el instrumento que proporciona valor a los ERP y con una creencia
fuerte que los usuarios del ERP son de hecho un factor significativo que conduce al éxito de la
implementación y que la carencia de atención sobre los usuarios de sistemas del ERP puede
llevar a la falla en la implementación [78].

Aunque el atraso comparado con otras industrias, del uso de los sistemas de información en
educación superior haya aumentado. Sin embargo, las organizaciones no han abrazado
completamente el recurso valioso de los sistemas ERP. Así, para darse cuenta de los resultados
y las ventajas potenciales de los ERP dentro de estas organizaciones, se ha hecho necesario y
se ha requerido urgentemente la investigación en el alineamiento del funcionamiento del usuario,
el uso del sistema y los sistemas de información. Más específicamente, la mayor parte de los
estudios anteriores han tenido una concentración más teórica o investigan aspectos de la
implementación tales como aceptación de usuario, o evalúan el éxito de la implementación de los
ERP en general.

A nuestro mejor conocimiento, ningunos de los estudios anteriores han intentado recoger lo que
percibimos para ser los factores más importantes que afectan al funcionamiento del usuario

23
desde la perspectiva del usuario, o los impactos de los sistemas ERP en el funcionamiento del
usuario a nivel individual.

En fin, los estudios anteriores han mostrado muchos aspectos de la base de conocimiento en
esta parte del campo de los sistemas de información, abarcando desde los factores de éxito, los
procesos de la implementación, de factores del cambio, de ventajas de la organización y de la
aceptación del usuario. Sin embargo, un hueco del conocimiento existe todavía con respecto al
funcionamiento del usuario y las aplicaciones del ERP; esto casi se ha ignorado en estudios
anteriores con independencia de algunos estudios que intentaron evaluar el funcionamiento de
grupos altamente especializados en diversos tipos de organizaciones. Por consiguiente, parece
que la combinación de diversas variables de la evaluación y su clasificación subsecuente en
dimensiones y factores estructurados pueden contribuir a formar un modelo comprensivo que
ayude a llenar partes esenciales del hueco del conocimiento, y representan otro paso en la
investigación de los ERP y de su impacto en instituciones de educación superior y la teoría de los
sistemas de información también.

Así, como las evaluaciones descritas del ERP se están ensanchando en aspectos técnicos para
incluir aspectos humanos, de organización y tecnológicos también, la importancia de los ERP y
de sus efectos sobre el funcionamiento del usuario será observada, y el grado al cual los ERP
satisfacen su papel para organizaciones específicas será reconocido.
2.2.4.2 En la industria

En la actualidad, el mundo empresarial es altamente competitivo; el entorno global en el que se

desarrollan las empresas ha provocado que sólo las más eficientes logren el éxito. A pesar de
estar en un buen negocio, muchas organizaciones no son capaces de aprovechar el entorno y es
común que el mal manejo de la información les lleve a alcanzar pérdidas importantes en su
organización [68].

Una posible solución para obtener un mejor control de las operaciones en una empresa es la
implementación de un sistema Enterprise Resource Planning (ERP), definido por Deloitte y
Touche, como un sistema de software de negocios que permita a las compañías automatizar e
integrar la mayoría de sus procesos, compartir datos comunes y prácticas a través de toda la
empresa, producir y acceder a la información en tiempo real.

Un ERP es una arquitectura de software que facilita el flujo de información entre las funciones de
manufactura, logística, finanzas y recursos humanos de una empresa [69]. Con este artículo, se
pretende que el lector conozca el funcionamiento e importancia que tienen los Sistema de
Planificación de Recursos conocidos como Enterprise Resource Planning (ERP) en inglés.

Introducción

El objetivo de los ERP es coordinar todas las actividades de negocios de la empresa, desde la
evaluación de un proveedor hasta la facturación para un cliente. ERP utiliza una base de datos
centralizada para ayudar el flujo de información entre los distintos departamentos de la empresa.
Sin embargo, de nada serviría la implementación de un ERP en una empresa si no se trabaja
desde el fondo del problema, al contrario, provocaría un problema mayor y más difícil de
solucionar.

Existe una gran variedad de ERP’s en el mercado, todos flexibles y adaptables a la situación de
la empresa con la que trabajarán. Se debe hacer un estudio minucioso de cuál es el que más le
conviene, pues aunque son muy parecidos, hay diferencias en costos y están enfocados a
diferentes tipos de mercado en particular [70].

Entre algunas compañías que han implementado un ERP están las siguientes: Cinsa en Saltillo
Coahuila, México que utilizó un ERP de ORACLE, GAN AHMSA en Monclova Coahuila, México
implementó el ERP de SAP, KODAK el FOUTH SHIFT, MEXICANA DE

24
TELECOMUNICACIONES el ERP de iBaan, SOFT CHOICE el ERP de ORACLE y CASA
MARZAM implemento el CARDINAL. Como podemos ver, todas las empresas anteriores son
exitosas y aunque no se deba precisamente a la implantación del sistema en ellas, sí tiene
mucho que ver en sus logros. De nada les serviría su crecimiento si no supieran manejarlo y
adaptarse a la nueva situación del mundo donde el manejo de la información es vital [71].

Importancia del ERP en las Empresas

La Planificación de Recursos Empresariales (Enterprise Resource Planning, ERP) es una forma

de utilizar la información en áreas claves como fabricación, compras, administración de
inventario, cadena de suministros, control financiero, administración de recursos humanos,
logística y distribución, ventas, mercadeo y administración de relaciones con clientes. Se trata de
unir estos elementos y proporcionar a los usuarios del sistema una manera universal de acceder,
ver, y utilizar la información que se guarda en diferentes sistemas de gestión empresarial a través
de una sola aplicación.

Con un sistema integrado, como el ERP, las barreras de información entre los diferentes
sistemas y departamentos desaparecen. Todos los sistemas y procesos controlados
computacionalmente en una empresa se pueden integrar bajo un mismo esquema para beneficiar
a toda la organización. Así, la unión entre las áreas de recursos humanos y financiera es cada
vez más importante para ayudar a modernizar los procesos internos y mejorar la eficiencia.

En 1997, más de 20,000 empresas alrededor del mundo pagaron $10 millones a proveedores de
sistemas ERP. Actualmente, existe una gran variedad de ERP’s en el mercado, todos flexibles y
adaptables a la situación de la empresa con la que trabajarán. Entre los cambios más evidentes
que un sistema de ERP proporciona a una corporación, sin dudas, está la mayor confiabilidad de
los datos, monitorizados en tiempo real y la disminución del trabajo [72].

Con la capacidad de integración de los módulos, es posible diagnosticar las áreas más o menos
eficientes y enfocarse en procesos que puedan mejorar el desempeño. Cuando mayor es la
integración de los módulos del ERP, más eficientes serán los procesos. Esto puede hacer la
diferencia a la hora de atender e incluso de retener a un cliente [73]. Normalmente, algunos
procesos internos necesitan ser redefinidos o rediseñados antes de que el sistema ERP entre
efectivamente en operación.

Al momento de seleccionar un ERP, lo ideal es realizar una investigación detallada, lo cual puede
involucrar desde fuentes externas como ser el Internet, publicaciones de información
especializada, compañías del mismo segmento o de perfil similar y consultoras, hasta
investigaciones hechas por los profesionales de tecnología de la información [74].

Es recomendable que las empresas no dejen en manos de un tercero la responsabilidad de la

elección del sistema que será instalado, ya que la empresa es quien conoce las necesidades de
su día a día.

2.2.4.2 En la industria

En la actualidad, el mundo empresarial es altamente competitivo; el entorno global en el que se

desarrollan las empresas ha provocado que sólo las más eficientes logren el éxito. A pesar de
estar en un buen negocio, muchas organizaciones no son capaces de aprovechar el entorno y es
común que el mal manejo de la información les lleve a alcanzar pérdidas importantes en su
organización [68].

Una posible solución para obtener un mejor control de las operaciones en una empresa es la
implementación de un sistema Enterprise Resource Planning (ERP), definido por Deloitte y
Touche, como un sistema de software de negocios que permita a las compañías automatizar e
integrar la mayoría de sus procesos, compartir datos comunes y prácticas a través de toda la

25
empresa, producir y acceder a la información en tiempo real.

Un ERP es una arquitectura de software que facilita el flujo de información entre las funciones de
manufactura, logística, finanzas y recursos humanos de una empresa [69]. Con este artículo, se
pretende que el lector conozca el funcionamiento e importancia que tienen los Sistema de
Planificación de Recursos conocidos como Enterprise Resource Planning (ERP) en inglés.

Introducción

El objetivo de los ERP es coordinar todas las actividades de negocios de la empresa, desde la
evaluación de un proveedor hasta la facturación para un cliente. ERP utiliza una base de datos
centralizada para ayudar el flujo de información entre los distintos departamentos de la empresa.
Sin embargo, de nada serviría la implementación de un ERP en una empresa si no se trabaja
desde el fondo del problema, al contrario, provocaría un problema mayor y más difícil de
solucionar.

Existe una gran variedad de ERP’s en el mercado, todos flexibles y adaptables a la situación de
la empresa con la que trabajarán. Se debe hacer un estudio minucioso de cuál es el que más le
conviene, pues aunque son muy parecidos, hay diferencias en costos y están enfocados a
diferentes tipos de mercado en particular [70].

Entre algunas compañías que han implementado un ERP están las siguientes: Cinsa en Saltillo
Coahuila, México que utilizó un ERP de ORACLE, GAN AHMSA en Monclova Coahuila, México
implementó el ERP de SAP, KODAK el FOUTH SHIFT, MEXICANA DE
TELECOMUNICACIONES el ERP de iBaan, SOFT CHOICE el ERP de ORACLE y CASA
MARZAM implemento el CARDINAL. Como podemos ver, todas las empresas anteriores son
exitosas y aunque no se deba precisamente a la implantación del sistema en ellas, sí tiene
mucho que ver en sus logros. De nada les serviría su crecimiento si no supieran manejarlo y
adaptarse a la nueva situación del mundo donde el manejo de la información es vital [71].

Importancia del ERP en las Empresas

La Planificación de Recursos Empresariales (Enterprise Resource Planning, ERP) es una forma

de utilizar la información en áreas claves como fabricación, compras, administración de
inventario, cadena de suministros, control financiero, administración de recursos humanos,
logística y distribución, ventas, mercadeo y administración de relaciones con clientes. Se trata de
unir estos elementos y proporcionar a los usuarios del sistema una manera universal de acceder,
ver, y utilizar la información que se guarda en diferentes sistemas de gestión empresarial a través
de una sola aplicación.

Con un sistema integrado, como el ERP, las barreras de información entre los diferentes
sistemas y departamentos desaparecen. Todos los sistemas y procesos controlados
computacionalmente en una empresa se pueden integrar bajo un mismo esquema para beneficiar
a toda la organización. Así, la unión entre las áreas de recursos humanos y financiera es cada
vez más importante para ayudar a modernizar los procesos internos
y mejorar la eficiencia.

En 1997, más de 20,000 empresas alrededor del mundo pagaron $10 millones a proveedores de
sistemas ERP. Actualmente, existe una gran variedad de ERP’s en el mercado, todos flexibles y
adaptables a la situación de la empresa con la que trabajarán. Entre los cambios más evidentes
que un sistema de ERP proporciona a una corporación, sin dudas, está la mayor confiabilidad de
los datos, monitorizados en tiempo real y la disminución del trabajo [72].

Con la capacidad de integración de los módulos, es posible diagnosticar las áreas más o menos
eficientes y enfocarse en procesos que puedan mejorar el desempeño. Cuando mayor es la
integración de los módulos del ERP, más eficientes serán los procesos. Esto puede hacer la

26
diferencia a la hora de atender e incluso de retener a un cliente [73]. Normalmente, algunos
procesos internos necesitan ser redefinidos o rediseñados antes de que el sistema ERP entre
efectivamente en operación.

Al momento de seleccionar un ERP, lo ideal es realizar una investigación detallada, lo cual puede
involucrar desde fuentes externas como ser el Internet, publicaciones de información
especializada, compañías del mismo segmento o de perfil similar y consultoras, hasta
investigaciones hechas por los profesionales de tecnología de la información [74].

Es recomendable que las empresas no dejen en manos de un tercero la responsabilidad de la

elección del sistema que será instalado, ya que la empresa es quien conoce las necesidades de
su día a día.

2.2.4.3 En los negocios

Cada invención técnica se diseña inicialmente y se aplica eventualmente para solucionar un

problema del mundo real [93]. La evolución de los sistemas para la Planeación de los recursos
de la empresa (ERP) no es la excepción. Debido a su éxito bien organizado para integrar con
eficacia sistemas de información múltiple aislada y su capacidad de mejorar perceptiblemente la
eficacia de los negocios, los sistemas ERP han emergido como la clave de la gestión acertada de
la información y como la espina dorsal de las empresas y el comercio electrónico.

Los sistemas ERP son paquetes grandes de programas informáticos, que se enfocan en cubrir si
no todas, si la mayoría de las necesidades de información y del proceso de la información de una
empresa [93]. Sin embargo, aún, una organización no puede evaluar la necesidad de estrategias
para los ERP o para los cambios asociados en estrategias de negocios sin una noción clara de
qué utilidad tienen los sistemas ERP.
Para discutir las ventajas, las barreras, y otros factores que afectan a la implementación de los
ERP en las organizaciones así como la relación entre los ERP y el comercio electrónico, la
claridad es necesaria sobre la evolución de los sistemas ERP. Un sistema ERP en sí mismo no
ofrece ventaja competitiva en un ambiente organizacional. La ventaja competitiva viene no del
hecho de que las compañías han adoptado un sistema ERP, puesto que el resto de las
compañías importantes han hecho esto. La ventaja competitiva será desarrollada a partir de
cómo interactúa ese sistema con sus clientes, y de cómo sus clientes lo perciben [93]. Así, las
compañías deben atraer a sus clientes en el autoservicio, haciendo su negocio electrónicamente.
El ERP y el comercio electrónico no son sistemas competitivos. Con todo, la funcionalidad básica
del ERP y del comercio electrónico son diferentes. Este estudio se centrará principalmente en la
evolución del ERP en su contexto histórico. Esto será aclarado en primer lugar introduciendo los
sistemas MRP y MRP II como la primera y segunda fase de los sistemas ERP. Por otra parte, las
razones por las que falla la implementación del MRP y del MRP II así como sus funciones y
jerarquía será examinados para conseguir una descripción clara de la evolución del ERP. En
segundo lugar, las facilidades del ERP, ventajas, y desventajas así como las razones de por que
falla la implementación del ERP serán discutidos. Por último, será presentada la relación entre el
ERP y el comercio electrónico.

El cambio rápido en tecnología y otras habilidades agregadas a los clientes que requerían
productos altamente específicos y personalizados han llevado a la necesidad de mayor
cooperación en el interior y entre las firmas comerciales.

Esta presión cada vez mayor urge a las compañías a explorar un mecanismo confiable que haga
más fácil ahorrar, almacenar y compartir la información útil. Por lo tanto, el sistema de
información de contabilidad (AIS) fue desarrollado para ofrecer una buena fundamentación para
que el control de la información y el conocimiento contribuyan al éxito de una compañía [94].

El AIS puede estar, según [95], con referencia a un sistema de proceso de transacciones porque

27
solo trató con datos financieros y de transacciones de contabilidad. Fue utilizado principalmente
como herramienta de reportes de la información para realizar funciones tales como nómina y
facturación. A medida que el poder y la sofisticación de la tecnología de la información (TI)
continúan creciendo, los potenciales de la cobertura del AIS han llegado a ser gradualmente más
inadecuados, y no suficientes para las necesidades de los negocios [95]. Con los requerimientos
cada vez mayores de información no dolo de datos financieros, las organizaciones comenzaron a
desarrollar sistemas de información adicionales.

Sin embargo, la existencia de sistemas múltiples crea varias discrepancias e insuficiencias [95].
Muy a menudo, los mismos datos, un expediente de venta por ejemplo se deben almacenar para
más de un sistema. Por lo tanto, emergió el término ERP (planeación de recursos de la empresa),
que amplía el AIS para cubrir las áreas como: planeación del producto, logística, contabilidad y
servicios financieros, recursos humanos y distribución de las ventas.

La planeación de los recursos de la empresa (ERP) o la integración de sistemas de información

en general está sin duda alguna entre los asuntos más centrales que se presentan aumentando
la interfaz del sistema de información (SI) y considerando el plazo de los últimos 20 años. [96]
indica que “por el acceso a la información a nivel empresarial desde las bases de datos, la
integración de los sistemas de información está proporcionando oportunidades numerosas de
coordinar actividades de organización facilitando la comunicación y el intercambio de información
a través de los departamentos sin la necesidad de ir arriba y abajo por la cadena de mando
vertical”. El acceso a la información oportuna, exacta y consistente es crucial en la mejora de
proceso de negocio y la contabilidad. La integración de sistemas de información, a través de
redes de comunicaciones y los sistemas de base de datos, permiten a las organizaciones crear y
sostener la mejora de procesos con la recuperación oportuna de la información precisa y
consistente” [96].

Iniciado el ERP desde el gran paquete de aplicaciones ensamblado que ha sido distribuido desde
los años 60. Entre las primeras aplicaciones empresariales empaquetadas disponibles estaba el
de Planeación de Requerimientos de Materiales (MRP), introducido en los años 60 y propuesto
por Joseph Orlicky, que aparece como el padre del MRP en 1960 en los E.E.U.U. [97]. Durante
los años 70 los paquetes del MRP fueron aumentados y se agregaron otras aplicaciones [98].

La mejora dio lugar a la introducción del software: Planeación de Requerimientos de Materiales II

(MRP II); se ha continuado este desarrollo [99]. Por otra parte, estos sistemas dieron lugar más
adelante a los sistemas del Planeación de recursos de la empresa (ERP), un término que
acuñaron en el grupo de investigación de Gartner en 1992 y el nombre se puede derivar
probablemente de los sistemas del MRP y de MRPII [100]. Los sistemas del ERP son paquetes
de programas informáticos altamente integrados [101]. Sin embargo, los sistemas del ERP, como
toda la tecnología de la información, cambian rápidamente. Durante los años 80 esto fue
abandonado y substituido por las arquitecturas Cliente/servidor y nuevamente fueron lanzadas
las versiones en aplicaciones WEB y están llegando a ser cada vez más extensas ahora [102].

Significado de los sistemas ERP

El ERP es la espina dorsal tecnológica del negocio electrónico (comercio electrónico) en el Back-
Office. Era común durante los años 90 encontrar que el software computacional para el
departamento de finanzas era diferente de ése usado por los departamentos de recursos
humanos o almacén. Según [103], el ERP “supera los cambios en la integración presentados por
las aplicaciones de Back-Office desconectadas, no coordinadas que han sobrevivido a menudo a
su utilidad”.

Hay varias definiciones del ERP que son todas más o menos similares [104]. El ERP se define
como “paquetes de programas informáticos integrados basados en módulos que controlan todos
los flujos de información del personal, de materiales y monetarios de una compañía” [105].

28
[106], sugieren una definición alternativa para los sistemas ERP como “paquetes de programas
informáticos integrados diseñados para proporcionar una integración completa de los sistemas de
procesamiento de la información de negocios de una organización y de todos los datos
relacionados. Estos sistemas se basan conceptualmente en los conceptos de sistemas operados
por eventos, que incluyen la captura de datos financieros y no financieros para facilitar el acceso
y el análisis ad hoc” [106].

Otra definición más es dada por [107], indican que los sistemas ERP son un conjunto de
herramientas administrativas que ofrecen una solución a nivel empresarial de sistemas de
información que balancean la oferta y demanda, incluyendo la capacidad de enlazar a clientes y
a proveedores en una cadena de suministro completa, empleando los procesos de negocios
confirmados para la toma de decisiones, y proporcionando altos niveles de integración matricial
entre las ventas, comercialización, fabricación, operaciones, logística, compra, finanzas, y
recursos humanos, de tal modo que permitan a la gente operar su negocio con niveles de
servicio, de atención al cliente y de productividad, y simultáneamente a costos e inventarios más
bajos; proporcionando la base para el comercio electrónico eficaz [107].

Así, para el propósito de este estudio el ERP se puede definir como software que se puede
utilizar para integrar la información a través de todas las funciones de una organización
para automatizar procesos de negocio corporativo. Algunos sistemas del ERP, según [102],
fueron desarrollados fuera de los ambientes administrativos (de recursos financieros y humanos)
del negocio (e.g. SAP y PeopleSoft), y otros crecieron de la planeación de recursos de materiales
en la manufactura (e.g. Baan).

2.3 Lenguaje Unificado de Modelación (UML) DE ACUERDO A ARCH LIX DEL 14 ABR 2012

2.3.1 Introducción

Como define Enrique Hernández Orallo [109], Cualquier rama de ingeniería o arquitectura ha
encontrado útil desde hace mucho tiempo la representación de los diseños de forma gráfica.
Desde los inicios de la informática se han estado utilizando distintas formas de representar los
diseños de una forma más bien personal o con algún modelo gráfico. La falta de estandarización
en la manera de representar gráficamente un modelo impedía que los diseños gráficos realizados
se pudieran compartir fácilmente entre distintos diseñadores.

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores
sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo
se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML se ha
convertido en ese estándar tan ansiado para representar y modelar la información con la que se
trabaja en las fases de análisis y, especialmente, de diseño [109].

El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o
menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso,
el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con
los diagramas de despliegue [109].

Como recomienda Grässle en su libro [110], hay varias razones para utilizar UML como lenguaje
de modelado:

• La unificación de la terminología y la estandarización de la notación llevan a una facilitación

significativa de la comunicación para todas los partes implicadas. Facilita el intercambio de
modelos entre los diversos departamentos o compañías. Por otra parte, facilita la transferencia de
proyectos entre los equipos del proyecto o los miembros de los equipos del proyecto.

29
• UML crece cuando los requisitos por modelar crecen. Porque UML es un lenguaje de modelado
de gran alcance, usted puede comenzar con el desarrollo de modelos simples o modelar
sistemas complejos con gran detalle. Si la funcionalidad básica de UML no es suficiente, usted
puede ampliarla con el uso de estereotipos.

• Las Estructuras de UML se basan sobre acercamientos ampliamente utilizados y probados.

UML no fue ideado en una torre de marfil sino que fue desarrollado principalmente a partir de
problemas del mundo real y de lenguajes de modelado existentes. Esto garantiza la facilidad de
uso y la funcionalidad de la vida real.

• UML se soporta ampliamente.

• Las ofertas basadas en UML para los sistemas informáticos se pueden comparar mucho más
fácilmente.

Según [110] su experiencia con proyectos demostró que:

• A menudo se crean solamente los componentes de un modelo.

• La mayor parte del tiempo el sistema entero no se modela.

• Se dedica poco tiempo para el entrenamiento en Lenguaje de modelado y metodología.

• En pocas palabras: no se le da mucha prioridad al modelado.

Ciertamente, algunos proyectos utilizan el modelo completo de UML apropiadamente [110]. Sin
embargo, el grueso de todos los proyectos utiliza UML u otros lenguajes de modelado,
herramientas de modelado, y métodos de modelado solamente a una pequeña escala, si acaso.
Mientras que el entusiasmo y la motivación son fuertes al principio del proyecto, el modelado y la
documentación de los resultados de modelado son a menudo la primera victima en caer debido a
la presión de tiempo cada vez mayor pues el plazo se acerca.

Desafortunadamente, no se puede cambiar eso [110]. En vista de estas circunstancias, se ha

intentado retratar un cuadro simplificado de UML, para permitir utilizar UML más eficientemente y
apropiadamente con solamente una pequeña inversión de tiempo.

Grässle [110] demuestra con la experiencia, que, dominar solamente algunos elementos de UML
lleva a mejores resultados que el conocimiento superficial de muchos elementos de UML. De
modo que recomienda seleccionar solo algunos de estos elementos subjetivamente. Aunque eso
no es siempre cómo fue pensado originalmente, refleja su experiencia práctica [110].

2.3.2 Conceptos básicos de UML

UML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de
Modelado Unificado. Para comprender qué es el UML, basta con analizar cada una de las
palabras que lo componen, por separado [3].

• Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una
sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre
cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación.

• Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real,

30
que permiten una mejor interpretación y entendimiento de éste.

• Unificado: unifica varias técnicas de modelado en una única. Ya que el UML proviene de
técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto
modelado orientado a objetos.

2.3.2.1 Introducción al caso de estudio del Aeropuerto UML

Para nuestro caso de estudio hemos elegido un aeropuerto, el aeropuerto- UML [110]. Cualquier
persona que haya estado en un vuelo no tendrá ningún problema para entender nuestro ejemplo.
Restringiremos nuestro ejemplo a esas áreas del aeropuerto con las que los pasajeros están en
contacto durante la salida, significa que nosotros tomaremos una vista más atenta en el registro y
el abordaje del pasajero. La figura 7 ilustra cómo los servicios al pasajero pueden ser distinguidos
de otras áreas del aeropuerto. Demuestra las varias etapas que siguen los pasajeros hasta que
los sientan en el avión, se abrochan los cinturones, y el avión está listo para salir. No todas las
etapas que siguen los pasajeros se relacionan con los servicios al pasajero. Las etapas que
pertenecen a los servicios de pasajero se enmarcan y se imprimen en fuente cursiva.

Una secuencia de pasos como esto se llama un escenario [110]. Sin embargo, el escenario
representado es solamente uno de muchos posibles. Las excepciones siguientes son posibles
para el registro y el embarque del pasajero:

• El pasajero tiene solamente equipaje de mano.

• El pasajero no compra nada en el kiosco de periódicos.

• El pasajero está llegando tarde y ahora tiene que llegar a checar lo más rápidamente posible.

• El pasajero pierde su pase de abordar.

• El pasajero llegó en avión y tiene que transbordar simplemente de avión, significando que él o
ella no tienen que salir del área de tránsito.

• El pasajero se registra, pero se duerme en una silla incómoda en la zona de espera, y pierde su
vuelo, a pesar de las llamadas que le hacen en varias ocasiones.

• El pasajero no pasa la inspección del pasaporte porque ha expirado su pasaporte.

Figura 7 Caso de estudio: “el pasajero toma un vuelo para ir de vacaciones”

Figura 8 ilustración esquemática del aeropuerto UML

La ilustración esquemática del aeropuerto UML en la figura 8 debe ayudarle a entender mejor los
acontecimientos del caso de estudio. Muchas áreas alrededor de los servicios principales al
pasajero se relacionan de una o más maneras con los servicios del pasajero. Algunos ejemplos
son:

• Ventas del boleto

• Kiosco de periódicos

31
• Tienda con franquicia

• Inspección/inmigración del pasaporte

• Mandos de vuelo

• Mostrador de información

• Registro y transporte del equipaje

Los servicios al pasajero tienen que intercambiar datos con algunas de estas áreas. También
tienen que comunicarse con otras áreas del aeropuerto. Introduciremos esas áreas cuando
discutimos los modelos de negocios y los modelos de integración del sistema. Por lo tanto, el
estudio de caso será ampliado más delante. El aeropuerto UML es un pequeño aeropuerto y el
caso de estudio a propósito se ha mantenido simple. Cualquier persona que ha estado en un
vuelo debe poder entender los ejemplos. El propósito del caso de estudio es proporcionar un
ejemplo coherente al tratar estos temas de UML. Algunos detalles del caso de estudio requieren
explicación adicional:

• El boleto consiste en el boleto real y hasta cuatro secciones adicionales. El boleto es el pequeño
libro que tiene un cupón separado para cada parte del viaje. Por ejemplo, un boleto podría
contener un cupón para el vuelo de Zúrich a Frankfurt, uno para el vuelo de Frankfurt a Londres,
y uno para el vuelo de vuelta de Londres a Zúrich. Cada vez en el área de registro el cupón
apropiado será intercambiado por un documento de abordaje. El boleto permanece siempre con
el pasajero.

• Distinguimos entre un vuelo y un número de vuelo. Por ejemplo, un número de vuelo podía ser
LH435 o LX016. Representa un vuelo regular que ocurre en cierto momento del aeropuerto de
salida al aeropuerto de destino. Un vuelo, por una parte, sería, por ejemplo, LH435 el 26 de
agosto de 2000. Es, por decir así, la ejecución de un número de vuelo. Un vuelo podía ser
cancelado debido al mal tiempo. Se utiliza un número de vuelo mientras la línea aérea ofrezca
cierto vuelo regularmente.

• Distinguimos entre tres opciones para el registro:

o Registro normal con equipaje en un contador de registros normal

o Registro Express sin equipaje en un contador de registros especia

o Registro automatizado sin equipaje en una máquina

2.3.2.2 Modelos, Vistas, y Diagramas

2.3.2.2.1 ¿Qué es un modelo?

Los modelos se construyen a menudo en el contexto del negocio y de los sistemas de TI para
entender mejor sistemas existentes o futuros [110]. Sin embargo, un modelo nunca corresponde
completamente a la realidad. El modelado significa siempre enfatizar y omitir: acentuar detalles
esenciales y omitir los irrelevantes. ¿Pero cuál es esencial y cuál es irrelevante? No hay
respuesta universal a esta pregunta. En vez de eso, la respuesta depende de cuáles son las
metas del modelo y de quién esta viéndolo o leyéndolo.

32
Cuanto más información da un modelo, se hace más complejo y difícil. Un mapa de Europa, por
ejemplo, que contiene simultáneamente división política, información geológica, demográfica, y
relacionada con el transporte es apenas legible. La solución a este problema es transportar los
diversos tipos de información a mapas individuales. Diversas vistas se forman de los objetos
considerados. Estas vistas se interconectan en de varias maneras. Generalmente, si se cambia
una visión, el resto de las vistas tienen que ser ajustadas también. Si, por ejemplo, en la nueva
tierra holandesa se reclama del Mar del Norte, todas las vistas o sea todos los mapas tienen que
ser puestos al día.

Figura 9 diferentes vistas de un objeto

Lo mismo es verdad para el modelo de un edificio. Si una nueva ala se agrega a un edificio
existente las diferentes vistas son afectadas, incluyendo el plano del piso, las diversas vistas
exteriores, y el modelo de 3 dimensiones hecho en madera (maqueta). La figura 9 ilustra esto de
una manera esquemática. En la sección 2.3.2.6, los modelos de nuestro caso de estudio,
tratamos específicamente las relaciones entre los modelos que utilizamos en este libro. Las
diversas vistas dentro de cada modelo son descritas más detalladamente en paginas posteriores.

2.3.2.2.2 ¿Por qué necesitamos modelos?

Como regla general, un modelo de un sistema tiene que realizar las tareas siguientes [110]:

• Comunicación entre todas las partes implicadas: Para construir el sistema correcto, es esencial
que todos las partes implicadas piensen a en el mismo sentido. Es particularmente importante
que cada uno entienda la terminología usada, que los clientes estén de acuerdo en los mismos
requisitos, que los desarrolladores entiendan esos requisitos, y que las decisiones tomadas se
puedan todavía entender meses más adelante.

• Visualización de todos los hechos por los clientes, los expertos, y los usuarios: Todos los
hechos acumulados relevantes al sistema necesitan ser presentados de una manera tal que cada
quien pueda entenderlos. Sin embargo, según nuestra experiencia de la vida real, golpeamos a
menudo una pared de resistencia cuando queremos comunicarnos con los diagramas en vez de
texto. Es necesario superar esta resistencia. Detrás de él está a menudo un miedo a lo
desconocido; y los diagramas pudieran mirarse algo complicados al principio. Por lo tanto, este
libro contiene direcciones en cómo leer cada diagrama.

• Verificación de hechos en términos de completitud, consistencia, y corrección: Un modelo (más

o menos) formal permite verificar los hechos obtenidos para completitud, la consistencia, y la
corrección. Particularmente, la pintura clara de correlaciones permite hacer preguntas
específicas, y contestarlas. Enumeraremos estas preguntas con cada diagrama.

2.3.2.2.3 Propósito y grupo destinatario de un modelo

En la vida real observamos a menudo que los resultados del modelado incómodo, aburrido, y
costoso desaparecen simplemente en una pila de documentos sobre el escritorio de alguien
[110]. Puede ser que preguntemos porqué esto es así. Dos factores influencian grandemente el
resultado del modelado: para quién creamos nosotros el modelo y para qué propósito se supone
que va a ser utilizado. Si nosotros no discutimos y definimos estos aspectos suficientemente,
corremos el riesgo de crear los modelos que no contienen lo que es importante para el usuario.

33
Es decir si los detalles no se enfatizan y no se omiten apropiadamente, el modelo se hace sin
valor útil. Para definir el propósito y el grupo destinatario, las preguntas siguientes deben ser
contestadas:

• ¿Cuánta experiencia de negocios esperamos encontrar? ¿Podemos asumir el conocimiento

básico del tema, o nosotros tendremos que explicar los fundamentos de eventos y procesos del
modelo?

• ¿Qué cantidad de detalle necesita el grupo destinatario? ¿Qué nivel de complejidad permite el
modelo? Si los procesos y los sistemas están sujetos a cambios constantes, un modelo
altamente detallado puede ser poco realista. Esto es porque, la mayor parte del tiempo, no es
posible mantener esos modelos de una manera satisfactoria. Un modelo menos detallado
requiere menos esfuerzo para convertirse y actualizarse, pero es también menos exacto.

• ¿Cuánto tiempo tiene que leer e interpretar el modelo el grupo destinatario? Evite que su
modelo desaparezca en un apilado de documentos sobre el escritorio de alguien eligiendo el nivel
apropiado de detalle y de complejidad; si no, nadie podría tener bastante tiempo de leerlo.

• ¿Qué lenguaje se puede utilizar en el modelo? ¿El grupo destinatario entiende términos
técnicos del negocio? ¿Entienden terminología de TI? permítame aclararlo con un ejemplo fácil:
Si una botella llena de agua se etiqueta “Agua”, virtualmente cualquier persona que sepa leer
entenderá el contenido de ella. Sin embargo, si la botella se etiqueta “H2O” - aunque éste es
correcto nosotros llegaremos a un grupo de personas mucho más pequeño, por ejemplo, los
trabajadores de un laboratorio de química. Con todo, la ventaja adicional es que demuestra la
composición del contenido: hidrógeno y oxígeno. En cualquier caso, usted tendrá que decidir qué
etiqueta es la más apropiada para su grupo destinatario.

• ¿Qué nivel de abstracción debe usted elegir? Mientras menos abstracto sea un modelo, será
más comprensible y claro para el usuario. Esto es porque un modelo menos abstracto está más
cercano a la aplicación y lenguaje del usuario. Por otra parte, los modelos con un más alto nivel
de abstracción son más reutilizables y se convierten más fácilmente en sistemas de TI. Podemos
también probar más exactamente que están correctos. Los especialistas en TI manejan mejor
probablemente los modelos altamente abstractos. Los usuarios, por la otra parte, pudieran jalarse
sus cabellos si tuvieran que ocuparse de un modelo así.

2.3.2.2.4 Consejos prácticos

Los compromisos tienen que ser hechos entre el nivel de abstracción, la claridad, y la cantidad de
detalle usada por un modelo[110]. Es posible desarrollar varios componentes del modelo,
diferenciando el grado de formalidad y de detalle, para satisfacer diversos grupos destinatarios.
De esta manera la comunicación entre los constructores del modelo, los clientes, los usuarios, y
los desarrolladores se puede facilitar mucho más. Es importante no sobre diseñarlo, pero
ajustarlo a sus grupos destinatarios y a sus aplicaciones.

Los patrones de análisis o diseño son los ejemplos de modelos que describen los métodos de
diseño y modelado. Usted debe, siempre que sea posible, buscar estos modelos de ejemplo: en
el Internet, en libros (por ejemplo, Fowler Martin: Analysis Patterns: Reusable Object Models,
Addison-Wesley, 1999), en revistas, o preguntar a sus compañeros de trabajo.

2.3.2.3 Proceso del análisis

La figura 10 muestra el proceso de análisis, que consiste en la obtención, representación, y

verificación de hechos:

34
Figura 10 proceso del análisis

Éste es el trabajo del analista. El proceso del análisis produce una especificación que viene del
modelo y de otras representaciones [110]. El analista trabaja con los portadores de conocimiento,
tales como clientes, usuarios, y expertos del dominio:

• Los hechos son obtenidos por la colaboración entre los analistas y los expertos del dominio en
quienes los portadores de conocimiento contribuyen al conocimiento del dominio y los analistas
del dominio contribuyen al conocimiento metodológico.

• Los hechos se representan en los diagramas y los documentos, que son elaborados
generalmente por el analista.

• Los hechos son verificados solamente por los portadores de conocimiento, puesto que solos
pueden decidir si los actuales hechos están correctos. La verificación es absolutamente esencial.
Sin ella puede ser que tengamos diagramas bonitos, pero la probabilidad es alta que los hechos
representados sean falsos. En términos simples: ¡el desarrollo de un modelo sin la verificación es
absolutamente sin valor!

2.3.2.3.1 Consejos prácticos

Es imposible desarrollar y verificar un modelo utilizable sin dominar los fundamentos técnicos de
un tema[110]. ¿Donde encontramos a estos portadores de conocimiento que sepan algo sobre
los sistemas que queremos modelar? Hemos tenido buenas experiencias con los grupos de
personas siguientes:

• Gente que está implicada en la ejecución, funcionamiento, y que controlan procesos de negocio

• Usuarios de sistemas similares o relacionados

• Clientes, que son a menudo portadores de conocimiento crítico y creativo

• Socios comerciales

• Expertos del dominio

• Gerencia

• Observadores externos

Varias técnicas provechosas han demostrado ser útiles para el análisis y la comprensión de los
procesos de negocio [110]:

• Observando empleados en su trabajo

• El participar en los procesos de negocio investigados

• Tomando el papel de un forastero (Ejemplo, de un cliente)

• Realizando exámenes

• Conduciendo entrevistas

• Hacer lluvia de ideas con los involucrados

• Discusión con los expertos del dominio

35
• Revisando formas existentes, la documentación, de especificaciones, de los manuales, y de las
herramientas existentes del trabajo

• Describiendo la estructura de la organización y la administración del flujo de trabajo (cartas de

organización, etc.)

2.3.2.4 Diagramas como Vistas

Cada diagrama particular de UML corresponde a una vista de un modelo de un sistema[110].

Dependiendo del tipo de diagrama usado, se acentúan o se omiten diversos aspectos. Todas las
vistas diferentes combinadas resultan en un buen modelo de un sistema. La mayor parte de los
diagramas de UML son gráficos (según la figura 11), implicando que consisten en los elementos
que están conectados a través de líneas:

Figura 11 diagrama como gráficos

Para leer diagramas, usted tiene que saber qué tipos de elementos y de líneas se permiten y lo
que significan. Explicaremos esto para los diagramas que utilizamos en los capítulos siguientes.

Incluso las herramientas automatizadas de la ingeniería de software (CASE) tratan diagramas de

UML como vistas. Utilizan una base de datos en la cual la información sobre el modelo se
almacena. Cada diagrama muestra como una vista una parte de esa información. De esta
manera, la herramienta del CASE ayuda a preservar la consistencia de cada vista. Si, por
ejemplo, el nombre de una clase se cambia en un diagrama de la clase, el diagrama de estado de
esa clase se actualiza automáticamente:

Figura 12 herramienta CASE como base de datos

La base de datos del modelo es lo qué distingue fundamentalmente una herramienta CASE de un
programa gráfico (Figura 12). Cualquier diagrama de UML se puede generar fácilmente con papel
y lápiz o un programa gráfico. En este caso, sin embargo, los varios diagramas no son nada más
que dibujos. Solamente el uso de una herramienta CASE con una base de datos, según
especificaciones de UML, permite la consistente colección, la administración, y la modificación de
la información del modelo. UML proporciona su propio modelo de base de datos: el meta-modelo
de UML, un componente de las especificaciones de UML "OMG: Unified Modeling Language:
Infrastructure, Version 2.0, Final Adopted Specification, September 2003, and OMG: Unified
Modeling Language: Superstructure, Version 2.0, Revised Final Adopted Specification, October
2004": http://www.omg.org). Todos los elementos encontrados en los diagramas de UML, así
como las descripciones de estos elementos, se contienen en el meta-modelo de UML. Establece,
por ejemplo, que una clase puede tener atributos y métodos. Este "modelo de datos"; de UML
como lenguaje, es el fundamento de los modelos de las bases de datos de todas las
herramientas CASE de UML. Desafortunadamente, muchas herramientas CASE consumen
muchos recursos, son costosas, mal desarrolladas, incómodas, y requieren entrenamiento
extenso. A pesar de esto, a excepción de proyectos muy pequeños, su uso es ventajoso.

2.3.2.5 Sistemas de información y tecnologías de sistemas de información

En casi todas las ocupaciones, parte del trabajo es tratar con la información[110]. Ha sido esta
manera para los millares de años y es una de las razones detrás del desarrollo de la escritura.
Algunos de los más viejos textos encontrados en Europa incluyen, por ejemplo, las listas
comunes del palacio de Knossos en Creta. Si pudiéramos mirar a los encargados de almacén

36
trabajar como lo hicieron hace 3.500 años, podríamos trazar probablemente los procesos de
negocio que la gente entonces hacía. Podríamos ver que esta gente trataba con los proveedores
y los compradores, que intercambiaba mercancías, y que guardaba los expedientes escritos de
sus actividades económicas. Igual era verdad para un comerciante de aceitunas romano 1.500
años más adelante, para un mercader del siglo XV en Alemania del norte, o en Lloyd' s de
Londres al principio del siglo pasado. En los ejemplos antedichos, sistemas de información más o
menos complejos fueron utilizados para manejar tareas diarias. El propósito de estos sistemas de
información era, y es, el de manejar la información necesaria para operar un negocio. Por
supuesto, todo el esto ocurrió sin las computadoras. Los sistemas de información fueron
apoyados por otras técnicas tales como pizarras, sistemas clasificadores grandes, y tarjetas
índices. Hoy, las computadoras permiten que ejecutemos sistemas de información como los
sistemas de TI. Esto crea nuevas posibilidades que serían probablemente increíbles para el
comerciante de aceitunas romano. Pero básicamente, el punto es todavía proporcionar y
procesar los datos que son necesarios para ocuparse de procesos de negocio diarios.

Hablaremos generalmente de sistemas de TI en esta tesis, puesto que asumimos que los
sistemas de información modelados con UML son ejecutados por tecnología de TI. En nuestro
caso de estudio de los servicios de pasajeros en el Aeropuerto UML Los empleados en el registro
de los pasajeros, los boletos de avión, y los vuelos son del mundo real. Por una parte, hay una
representación o una imagen de estos pasajeros, boletos de avión, y vuelos en el sistema de
información. Estas imágenes consisten en la información sobre los pasajeros, los boletos, y los
vuelos almacenados en el sistema de información, necesario para operar los procesos, según las
indicaciones de la figura 13:

Figura 13 Objetos del mundo real y de sus imágenes

Un sistema IT es un sistema computarizado que proporciona la información necesaria para la

ejecución de ciertos procesos de negocio, generalmente en respuesta a una pregunta de un
usuario[110]. Por supuesto el sistema IT tiene que ser “alimentado” con información, de modo
que pueda contestar a las preguntas. La figura 14 demuestra la cooperación entre los sistemas
empresariales y los sistemas IT esquemáticamente. En el marco de los procesos de negocio de
un sistema empresarial, la información se recupera de y se almacena en sistemas IT:

Figura 14 sistema IT

Las técnicas de modelado introducidas en [110] no sólo son verdad para el desarrollo de
sistemas IT, sino que pueden también ser utilizadas siempre que un sistema de información
necesite ser analizado. Para ilustrar esto, inventamos un segundo ejemplo en adición a nuestro
de caso de estudio de servicios de pasajero en el aeropuerto UML al que volveremos en diversos
lugares [110].

El segundo ejemplo es una oficina Hanseática de negocios medieval[110]; poseída por el Sr.
Hafenstein. (La liga Hanseática era una alianza de gran alcance de gremios mercantiles en
ciudades de Alemania del norte y del Báltico que controlaron el comercio en esta región durante
la edad media) El supervisor de la oficina es la secretaria fiel y diligente Hildebrandt. La oficina
guarda varios libros, a saber un libro diario, un libro mayor de ventas, y un índice de clientes.
Cada libro es la responsabilidad de un diverso vendedor. A nadie se le permite excepto al
vendedor responsable realizar cualquier cambio en un libro, y solamente él sabe exactamente
dónde se registra en el libro el fragmento de información particular. En nuestra terminología, la
oficina, incluyendo Hildebrandt, los vendedores, y los libros, componen el sistema de información.
Con la ayuda de este ejemplo queremos demostrar en diferentes lugares en este libro que,
aunque un sistema de información se puede ejecutar como sistema IT con la ayuda de la

37
informática, conceptualmente no tiene nada que ver con las computadoras. En vez de eso, puede
ser realizado de muchas maneras.

2.3.2.6 Los modelos de nuestro caso de estudio

En el caso de estudio [110] se construyeron tres modelos de diversos sistemas:

1. El modelo del sistema empresarial describe los servicios de pasajeros, significando el medio
ambiente del negocio del sistema IT. Trata de procesos de negocio, de pasajeros, de socios
comerciales, de los empleados, etc.

2. El modelo del sistema IT explica el sistema IT que fue construido para los servicios de
pasajeros. El modelo del sistema de la empresa de servicios a los pasajeros sirve como base
para el modelo del sistema IT.

3. El modelo de integración del sistema describe la integración en el ambiente, especialmente

entradas del mundo exterior. Aquí también, el modelo del sistema de la empresa de servicios del
pasajero sirve como la base:

Figura 15 modelos del caso de estudio

Los tres modelos son necesarios para construir e integrar los sistemas IT; el modelo del sistema
IT por sí solo es insuficiente[110]. Esto es verdad no sólo para nuestro caso de estudio, sino
también para cualquier caso. Usted puede ver en la figura 15 que el modelo del sistema
empresarial proporciona la base para el resto de los modelos. De esta manera, constituye la base
para trabajar para las personas involucradas en el proyecto. Debido a esto, es una gran ventaja
utilizar un lenguaje de modelado unificado, que se pueda entender por la gente de los diversos
departamentos, así como por los de tecnologías de la información. Esto permite un intercambio
ágil de modelos entre las distintas áreas. También facilita perceptiblemente la verificación de los
modelos. Se tiene el convecimiento [110] de que UML funciona como un acoplamiento que tiene
la capacidad de cerrar el hueco existente entre los requisitos técnicos y las características de
rendimiento reales de los sistemas IT.

2.3.2.7 Historia de UML: Métodos y notaciones

En su historia corta, la tecnología de la información ha producido ya una plétora de métodos y de

notaciones[110]. Se tienen métodos y notaciones para el diseño, la estructura, procesamiento, y
el almacenaje de la información. También se tienen métodos para la planeación, el modelado, la
implementación, el montaje, la prueba, la documentación, el ajuste, etc. de sistemas. Algunos de
los conceptos usados son relativamente fundamentales, y debido a eso, pueden también ser
encontradas más allá del campo de la tecnología de la información. Un ejemplo de esto es la
herencia, que está presente en la naturaleza, pero es también una piedra angular de la
programación orientada a objetos.

Hasta cerca de los años 70, los analistas de programas informáticos vieron el desarrollo del
software como empresa artística [110]. Pero debido a que los sistemas se convirtieron en cada
vez más complejos, el desarrollo y el mantenimiento de programas no se podrían conquistar más
con este enfoque creativo-individual. Eventualmente, este enfoque llevó a la crisis del software.

Esta crisis llevó al enfoque de la ingeniería (ingeniería de software) y a la programación

estructurada. Los métodos fueron desarrollados para la estructuración de sistemas y para los
procesos del diseño, del desarrollo, y del mantenimiento. Los enfoques orientados a procesos,
por ejemplo el método de Hierarchy Input Processing Output (HIPO), acentuaron la funcionalidad
de sistemas. Con este método el sistema total se divide en componentes más pequeños con la

38
descomposición funcional.

La figura 16 da una descripción visual (diagrama jerárquico) de las sub funciones en el ejemplo
de una factura. Un esquema de la entrada-proceso-salida describe cada elemento funcional. Al
mismo tiempo, fue desarrollado el enfoque orientado a la estructura de datos, por ejemplo el
método de Jackson, en el cual la estructura del programa se deriva de la exhibición gráfica de las
estructuras de datos.

La figura 17 muestra, en la columna izquierda, la estructura de un conjunto de datos del

inventario. La columna derecha muestra la estructura del programa que fue derivada de la
estructura de datos:

Figura 16 diagrama HIPO

Figura 17 diagrama de Jackson

2.3.2.8 Especificación de requisitos

Los modelos del sistema que se desarrollará componen una parte integrante de cada
especificación de requisitos. Esta tesis hace énfasis en la verificación (sección 2.3.2.8.2) para el
desarrollo de estos modelos. Desafortunadamente, no hay una receta universal para la
especificación de requisitos. En vez de eso, la opción y el nivel de detalle de los modelos
dependen de varios factores. La experiencia [110] demuestra que los tres puntos siguientes son
los más importantes:

• ¿Quién está especificando?

• ¿Para quién se está especificando?

• ¿Qué se está especificando?

2.3.2.8.1 Dirección para la toma de decisión

Los modelos y las vistas que son proporcionados por [110] son los bloques de construcción de
los cuales usted puede elegir los requeridos para una especificación de requisitos. La tabla
siguiente le apoyará en tomar la decisión apropiada de modelos y vistas:

2.3.2.8.2 Verificación

Todas las vistas introducidas en [110] describen un modelo que documenta los requisitos desde
el punto de vista del usuario. Esto significa que todos los modelos y vistas utilizados:

• Pueden ser creados solamente en cooperación con agentes de usuario

• Pueden ser verificados solamente por los agentes de usuario con respecto a la corrección del
contenido

39
Aunque que se desarrolló el modelo del sistema IT para el público objetivo [110], los agentes IT,
no se puede hacer nada sin los agentes de usuario, que tienen que proporcionar los requisitos y
verificar el modelo. Representan el punto de vista del usuario y son los portadores del
conocimiento del dominio del usuario. Puesto que varios grupos están implicados en el desarrollo
y la verificación de las especificaciones de requisitos, es especialmente importante utilizar un
lenguaje de modelado unificado, para evitar el malentendido y la mala interpretación.

2.3.2.9 UML 2.0

2.3.2.9.1 Descripción de UML 2.0

UML 2.0 en acción [110]: Un tutorial basado en Proyectos se basa en la nueva versión de UML-
UML 2.0. En esta versión, la estructura y la documentación de UML fueron revisadas totalmente.
Ahora hay dos documentos disponibles que describen UML:

• La infraestructura de UML 2.0 define las construcciones básicas del lenguaje en la cual se basa
UML. Esta sección no es directamente relevante a los usuarios de UML, pero se dirige más hacia
los desarrolladores de las herramientas de modelado.

• La superestructura de UML 2.0 define las construcciones de usuario de UML 2.0, significando
esos elementos de UML que los usuarios trabajen con el nivel inmediato.

Entre otras cosas, esta revisión de UML fue creada para perseguir las metas siguientes[110]:

• Para restructurar y refinar UML para simplificar la utilidad, puesta en práctica, y la adaptación.

• Se supone que la infraestructura de UML:

o Proporcione una base reutilizable del metalenguaje, con la cual UML puede definirse

o Proporcione los mecanismos para el ajuste de la lengua

• Se supone que la superestructura de UML:

o Un mejor soporte para el desarrollo basado en componentes

o Mejore las construcciones para la especificación de la arquitectura

o Proporcione mejores opciones para el modelado del comportamiento

Además de la propuesta de las especificaciones de la infraestructura de UML y de la

superestructura de UML, las propuestas separadas fueron publicadas para un nuevo lenguaje de
validación de objetos (OCL) así como para el diagrama de intercambio. Juntos, componen el
paquete completo de UML 2.0, según las indicaciones de la figura 18:

Figura 18 el paquete completo de UML 2.0

UML 2.0, es un todo, es más extenso y más complejo que versiones anteriores. La extensión de
la documentación de UML también ha aumentado. Mientras que la documentación de UML 1.5,
incluyendo el OCL, abarcó cerca de 730 páginas, la documentación de UML 2.0, también
incluyendo el OCL, contiene aproximadamente 1050 páginas.

2.3.2.9.2 Efectos sobre el modelo del sistema empresarial

40
Algunos cambios realizados en el modelado del funcionamiento realzaron las posibilidades de
modelar los sistemas empresariales [110]. Primero, se darán ejemplos de varios de los cambios y
mejoras.

Los diagramas de actividad ya no son más, solo casos especiales del diagrama de estados.
Inicialmente, este hecho no era relevante para el usuario del UML normal. Sin embargo, además
de la nueva autonomía en el meta-modelo, varios otros cambios y mejoras fueron llevados a
cabo: Hasta ahora, los pasos separados en el diagrama de la actividad fueron referidos como
actividades. Ahora el diagrama entero se llama una actividad, mientras que los pasos
previamente llamados actividades ahora se refieren como acciones. Una acción puede llamar una
operación primaria así como a otra actividad. Esto permite la modulación flexible en la vista de
arriba hacia abajo (top-down) de los modelos.

Una división no tiene que necesariamente re-sincronizada.

Una actividad puede tener más de un estado inicial. Con esto, varios acontecimientos se pueden
comenzar al mismo tiempo.

Los parámetros de entrada y de salida se pueden agregar a una actividad.

Una de las mejoras llevadas a cabo en el diagrama de secuencia es la adición de los así
llamados operadores. Estos operadores permiten empaquetar varias acciones/actividades dentro
de un diagrama de secuencia. Por ejemplo, los operadores pueden ser utilizados para referirse a
otros diagramas de secuencia o secuencias individuales. Los operadores apropiados pueden
también representar iteraciones. Con los operadores recientemente presentados, los diagramas
de secuencia ahora soportan una vista de arriba hacia abajo (top-down).

El OCL ahora es una parte inherente de UML [110]. Puede ser utilizado para describir acuerdos,
invariantes, condiciones previas, y condiciones posteriores dentro de modelos de UML, que
permite un modelado más exacto de sistemas empresariales y de procesos de negocio.

2.3.2.9.3 Efectos sobre el modelo del sistema IT

Los diagramas que se han utilizado [110] en las diversas vistas del sistema IT no experimentaron
ningún cambio significativo.

El cambio más grande ocurrió en la notación del diagrama de secuencia. Aquí, entre otras cosas,
la referencia de la interacción está disponible como una construcción para la modularidad. Sin
embargo, nada cambió referente al significado y a la funcionalidad de los diagramas de
secuencia en el nivel de detalle usado [110]. Lo mismo es verdad para el diagrama de clases y el
diagrama del casos de uso.

Los diagramas de estado experimentaron los cambios más interesantes para el modelado de los
sistemas de TI: los puntos de conexión permiten, por ejemplo, una mejor modularidad de los
diagramas de estado [110]. Sin embargo, decidimos no utilizar este elemento del lenguaje en
nuestro acercamiento simplificado a UML.

2.3.2.9.4 Efectos sobre el modelo de integración de sistemas

Por supuesto, las mejoras en el modelado del comportamiento también tenían un efecto sobre la
vista de proceso en el modelo de integración de sistemas. Una mejora significativa es la
capacidad de agregar parámetros de entrada y de salida a las actividades (véase la sección
2.3.2.9.2, efectos sobre el modelo del sistema empresarial).

Apenas cualquier cambio fue realizado en el área de vistas estáticas, significando el diseño de

41
objetos del negocio con diagramas de clase [110].

Además de los cambios que fueron realizados en el marco de UML 2.0, el perfil de UML para la
Enterprise Application Integration (EAI) es de importancia cada vez mayor en el campo de la
integración de sistemas. Además de las operaciones básicas requeridas en el campo de la
integración de sistemas, él demuestra el meta-modelo de varios lenguajes de programación que
no están orientados a objetos. Sin embargo, esto ocurre en un nivel más detallado, que no tiene
ninguna influencia sobre este texto.

2.3.2.9.5 La super estructura de UML

Es en la Superestructura donde encontramos los cambios que más afectan en el día a día a
quienes trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que,
en general, deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones
[112].

Es aquí dónde se definen los diagramas y los elementos que los componen. La Superestructura
se encuentra dividida en niveles. Estos niveles se conocen como:

• Básico (L1): Contiene los elementos básicos del UML 2.0, entre ellos: Diagramas de clases,
Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso

• Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas
de Componentes y Diagramas de despliegue.

• Completo (L3): Representa la especificación del UML 2.0 completa, como por ejemplo: las
Acciones, Características avanzadas y PowerTypes entre otros.

Es importante destacar que basta con que una herramienta implemente el nivel de conformidad
Básico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad
de características (features) bastante amplia entre dos herramientas distintas, aunque éstas sean
UML 2.0 compatibles.

2.3.2.9.6 Organización de la superestructura

El bloque de construcción básico del UML es un diagrama. La estructura de los diagramas UML
está reflejado por el diagrama de la figura 19, de acuerdo con la especificación del UML 2.0 del
Object Development Group. Los detalles sobre estos diagramas específicos se organizan de
acuerdo a esta estructura taxonómica, que da la perspectiva a los diagramas y a sus
interrelaciones [111]. Los diagramas de interacción comparten propiedades y atributos similares,
como lo hacen los diagramas estructurales y de comportamiento. En la figura 19 se distinguen
aquellos diagramas que aparecen en esta versión del UML.

Figura 19 Estructura taxonómica del UML 2.0

2.3.2.9.7 Diagramas de Estructura y Diagramas de comportamiento

Los diagramas estructurales representan elementos y así componen un sistema o una función
[112]. Estos diagramas pueden reflejar las relaciones estáticas de una estructura, como lo hacen
los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecución, tales como
diagramas de Objetos o de Estructura de Composición. Los diagramas de comportamiento
representan las características de comportamiento de un sistema o proceso de negocios y, a su

42
vez, incluyen a los diagramas de: actividades, casos de uso, maquinas de estados, tiempos,
secuencias, repaso de interacciones y comunicaciones.

2.3.2.9.8 Breve descripción sobre los diagramas

En beneficio de quienes quieran seguir investigando dentro del mundo UML, en el siguiente
cuadro se muestra la importancia que tiene, para un desarrollador, conocer cada una de las
nuevas características del UML 2.0 [112].

Figura 20 Características e importancia de los diagramas UML

2.3.2.9.9 Conclusión

Para el usuario normal, UML 2.0 no regresa a las versiones previas de UML de arriba a abajo,
sino que representa una mejora en conceptos existentes. Es probablemente sabio utilizar UML
2.0 para los modelos futuros. Por una parte, debe ser posible continuar usando las
construcciones y los modelos existentes basados en versiones anteriores de UML. Para los
proyectos en curso las ventajas (un modelado más exacto) tienen que ser sopesadas contra las
desventajas (trabajo adicional).

2.3.3 Análisis y diseño de sistemas con UML

2.3.4 Diagramas en UML
2.3.5 Aplicaciones de UML
2.4 Modelado de ERP con UML
2.5 Resumen del capítulo

43
III Aplicación de un ERP: un caso de estudio
3.1 Introducción
3.2. Situación actual de los sistemas
3.3. Funciones generales de la UTC
3.4 Requerimientos en la aplicación de tecnologías de información
3.5 Solución propuesta
3.5.1 Modelo conceptual de un ERP aplicado en la UTC
3.5.2 Modelo sistémico
3.5.2.1 Diagrama general de sistemas
3.5.2.2 Flujos generales de procesos
3.5.2.3 Diagramas generales causales
3.5.2.4 Diagrama de Forrester
3.6 Resumen del capitulo

44
IV. Modelado de un ERP con UML
4.1 Introducción
4.2 Diagramas de análisis con UML

4.2.1 Diagrama de Casos de Uso

4.2.2 Diagrama de Requisitos
4.2.3 Diagrama de Actividad

4.3 Diagramas de diseño

4.3.1 Diagramas de Dominio
4.3.2 Diagramas de Clases
4.4 Diagramas de Secuencia
4.5 Diagramas de Objetos
4.6 Diagramas de Comunicación
4.7 Diagramas de Componentes
4.8 Diagramas de Despliegue
4.9 Diagramas de Implementación
4.10 Diagrama de Estados

Conclusiones

Referencias

45
2 Estado del arte sobre ERP y modelado en UML
2.1 Definición

2.4 Modelado Visual

Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación
de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del
sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación
gráfica. Esto se conoce como modelado visual.

El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la

misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir
un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos que
el ser humano pueda entender.

UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas
software como para la arquitectura hardware donde se ejecuten. Otro objetivo de este modelado
visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños
realizados usando UML se pueda implementar en cualquier lenguaje que soporte las
posibilidades de UML (principalmente lenguajes orientados a objetos).

UML es además un método formal de modelado. Esto aporta las siguientes ventajas:

• Mayor rigor en la especificación.

• Permite realizar una verificación y validación del modelo realizado.
• Se pueden automatizar determinados procesos y permite generar código a partir de los modelos
y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el
código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más
alto nivel, de la estructura de un proyecto.

46
Capítulo 3. Metodología
3.1 Ingeniería de Requisitos

3.1.1 Elicitación

3.1.1.1 Análisis del sistema de Gestión Certificado de Calidad UTC 9001:2008 Procesos:
Gestión, Educativo y Educación Continua

En esta sección se analizaron los procedimientos que están manifestados y

certificados por el sistema de gestión de calidad, para lo cual se analizaron las
interrelaciones con base en la metodología del Diagrama de Flujo de Datos (DFD)
[9]. Para iniciar el análisis de recabaron los documentos del sistema de gestión
calidad: Documentos externos, especificaciones, instrucciones de trabajo,
Procedimientos y formatos, de las siguientes áreas de la Universidad:

 Abogado General
 Administración.
 Autoevaluaciones
 C3 (Centro de Cómputo y
Comiunicaciones)
 Calidad
 Extensión Universitaria
 Filosofía Institucional
 Finanzas
 Planeación y Evaluación
 Planes y Programas de Estudio
 Plantilla del personal docente
 Proceso Académico
 Rectoría
 Vinculación

Del manual de calidad se consultaron los siguientes documentos que se controlan:

PROCEDIMIENTOS REQUERIDOS POR LA NORMA ISO9001:2008

Código Nombre del procedimiento Proceso Proceso Proceso de

Educativo Servicios de Gestión
Educación
Continua
P-GE-01 Control de Documentos   
P-GE-02 Control de Registros   
P-GE-03 Acciones Preventivas   
P-GE-04 Acciones Correctivas   
P-GE-05 Auditorias Internas de Calidad   
P-GE-06 Control del Producto No   
Conforme

47
NECESARIOS DEL SISTEMA DE GESTION DE CALIDAD DE LA UNIVERSIDAD
TECNOLOGICA DE COAHUILA
Código Nombre del procedimiento Proceso Proceso Proceso de
Educativo Servicios de Gestión
Educación
Continua
P-RE-01 Revisión de la Dirección 
P-RE-02 Comunicación Interna 
P-RE-04 Mantenimiento Preventivo y 
Correctivo a equipo de
informático
P-DA-01 Captación de matrícula 
P-DA-02 Evaluación de alumnos de nuevo 
ingreso
P-DA-03 Inscripción y reinscripción de 
Alumnos
P-DA-04 Incorporación de alumnos de 
nuevo ingreso
P-DA-07 Incorporación al Ejercicio 
Profesional
P-DA-08 Titulación 
P-DA-09 Desarrollo y profesionalización 
del personal docente
P-DA-10 Adquisición de materiales 
bibliográficos
P-DA-11 Mantenimiento a Laboratorios 
P-DA-12 Apoyo Psicopedagógico 
P-DA-13 Programa Institucional de 
Tutorías
P-DA-14 Evaluación de las competencias 
profesionales

P-DA-15 Desarrollo del proceso 

enseñanza-aprendizaje por
competencias profesionales
P-VI-02 Formalización de un Servicio de 
Educación Continua (SEC)
P-VI-03 Integración de SEC 
P-VI-04 Identificación y rastreabilidad del 
participante
P-VI-05 Seguimiento al desempeño de 
Egresados
P-VI-06 Gestión de Estadías 
Empresariales
P-VI-07 Visitas empresariales 
P-VI-08 Control del proceso 
P-VI-09 Evaluación de un SEC 
P-VI-10 Evaluación de participantes en 
un SEC
P-VI-11 Selección y Evaluación de 
Instructores de un SEC y
Diplomado Superior de
Gastronomía DSG

P-VI-12 Captación De participantes al 

DSG
P-VI-13 Inscripción y reinscripción de 
participantes al DSG

48
P-VI-14 Desarrollo del proceso 
enseñanza-aprendizaje del DSG
P-VI-15 Evaluación del aprendizaje 
P-VI-16 Seguimiento al mantenimiento de 
los laboratorios de gastronomía
P-VI-17 Evaluación de Diplomado 
Superior de Gastronomía
P-AF-01 Mantenimiento a Infraestructura 
P-AF-02 Elaboración de los Estados 
Financieros
P-AF-03 Reclutamiento, selección y 
contratación de personal
P-AF-04 Adquisición y suministro de 
bienes y servicios
P-AF-05 Licitación de bienes y servicios 
contratados
P-AF-06 Viáticos 
P-AF-07 Control De fondos fijos 
revolventes
P-AF-08 Capacitación y desarrollo del 
personal administrativo
P-AF-10 Control de Activo Fijo 
P-PE-01 Análisis de Datos   
P-PE-04 Planeación Institucional 

P-CI-01 Auditorías Contables y 

Financieras

P-ED-01 Difusión de actividades y 

eventos Institucionales
P-CA-01 Procedimiento para elaborar   
procedimiento
P-CA-02 Tratamiento de Quejas de cliente   

Las convenciones utilizadas por el sistema de calidad para designar el código del
procedimiento son:

AF.- Administración y Finanzas

CA.- Departamento de gestión de Calidad

CI.- Auditorias contables y Financieras

DA.- Desarrollo Académico

ED.- Extensión universitaria

GE.- Procedimientos generales

RE.- Rectoría

PE.- Planeación Institucional

VI.- Vinculación

49
7. Lista de Tablas y Figuras

Figura 1.- Áreas que intervienen en el proceso educativo

50
Figura 2.- Áreas que intervienen en el proceso de Servicios de educación Continua

51
Figura 3.- Recursos que administra la UTC

52
Referencias

1. Mario Gerardo Piattini Velthius, Emilio del Peso Navarro., Auditoría Informática: Un enfoque
práctico., AlfaOmega, Colombia, 2004, p24-28 2. IBM Corporation., Business Modeling
With the UML Student Manual. Rational University, USA, 2001. Version 1.0

3. IBM Corporation., Essentials of visual Modeling with UML 2.0 Student Guide. Rational
University, USA, 2004, Version 2004.06.00

4. Pages, C., de-Marcos, L., Martínez, J., Gutiérrez, J., Definición de Métricas de Calidad en el
Proceso de Parametrización de sistemas ERP. RPM-AEMES, 2007. 4 No. 3: p. 74-81.

5. Markus, M., Cornelius, T., The Enterprise systems experience. From adoption to Success. In
R.W. Zmud, Ed., Framing the Domains of IT Research: Glimpsing the Future through the
Past, Pinnaflex, Educational Resources, 2000.

6. Davenport, T., Putting the enterprise into the enterprise system. Harvard University Graduate
School of Business Administration, 1998. 76, (4) p. 121 - 131.

7. Salazar, G., Botella, P., Dahanajake, A. , Introducing Non-Functional Requirements in UML,

in UML and the Unified Process, L. Favre, Editor. 2003, IRM Press.

8. Craig Larman, UML y Patrones, Prentice Hall, España, 2003

9. Pressman, Roger., Ingeniería del Software: Un enfoque práctico. 5 ed., McGraw Hill.,
España, 2002:

10. ITpreneurs., Curso de Fundamentos de ITIL V3., ITpreneurs Nederland B.V., 2008., Versión
2.2

11. IBM Corporation., Mastering the Management of Iterative Development, Student Manual, ,
Rational University, USA, 2003. Version 2003.06.00

12. Burgleman, R. A., & Maidique, M. A. (1988). Strategic management of technology and
innovation. Homewood, IL: Irwin.

13. Lee,J.,Siau,K.,&Hong,S.(2003).EnterpriseintegrationwithERPandEAI.Communications of the

ACM, 46(2), 54–60.

15. Siau, K., & Messersmith, J. (2002). Enabling technologies for e-commerce and ERP
integration. Quarterly Journal of Electronic Commerce, 3(1), 43–52.

16 Niederman,F.,Brancheau,J.C.,&Wetherbe,J.C.(1991).Information systems management

issues for the 1990s. Management Information Systems Quarterly, 15, 474–500.

17 Siau,K.(1995).Groupcreativityandtechnology.TheJournalofCreativeBehavior,29,201–216.

18. Siau,K.(1996).Electroniccreativitytechniquesfororganizationalinnovation.The Journal of

Creative Behavior, 30, 283–293.

19. Siau, K. (1999). Internet, World Wide Web, and creativity. Journal of Creative Behavior, 33,

53
 191–201.

20. Siau,K.(2000).Knowledgediscoveryasanaidtoorganizationalcreativity.JournalofCreative
Behavior, 34, 248–258.

21. Siau, K., & Messersmith, J. (2002). Enabling technologies for e-commerce and ERP
integration. Quarterly Journal of Electronic Commerce, 3(1), 43–52.

22. Zawacki,R.A.(1993).Key issues in human resource management .Information Systems

Management, 10(1), 72–75.

23. Soffer, P., Golany, B., Dori, D., Aligning an ERP system with entreprise requirements: an
object-process based approach. Elseivier, 2005: p. 639-662.

26. Dean, J., Gravel, A. , Enterprise Resource Planning: Global Opportunities and Challenges.
2002: Springer.

27. Klaus, H., Rosemann, M., Gable, G. , What is ERP? information systems frontiers, 2000. 2
(2): p. 141-162.

28. Kalakota, R., Robinson, M., e-Business 2.0: Roadmap to Success., ed. M.A.-W. Reading.
2001.

29. Møller, C., ERP II: a conceptual framework for next-generation enterprise systems? Journal
of Enterprise Information Management, 2005. 18 No. 4: p. 483-497.

30. Bond, B., Genovese, Y., Miklovic, D., Wood, N., Zrimsek, B., Rayner, N., ERP Is Dead —
Long Live ERP II. GartnerGroup, 2000.

31. IDC-Press. European ERP Applications Market Back to Healthy Growth as New Trends Kick
in, Says IDC consultado 2008 [cited.

32. Jacobson, S., Shepherd, J., D’Aquila, M., Carter, K. The ERP Market Sizing Report, 2006–
011. 2007 [cited.

33. Lucas, K. La Situación de la Adopción de Software de Gestión Empresarial en Europa.

2007 [cited. 34. CB-Consulting. Informe sobre el Mercado de las Soluciones de Gestión
Empresarial en España 2007. 2007 [cited.

35. Gore, A., Exploring the Competitive Advantange Through ERP Systems: From
Implementation to Applications in Agile Betworks, in Industrial Engineering and
Management. 2008, Universidad de OULU.

36. Esteves, J., Pastor, J., An ERP Life-cycle- based Research Agenda. First International
workshop in Enterprise Management and Resource Planning: Methods, Tools and
Architectures – EMRPS’99, Venice, Italy 1999.

37. Pnina, S.B., G.; Dov, D., Aligning an ERP system with entreprise requirements: an object-
process based approach. Elseivier, 2005: p. 639-662.

38. Koch, C., BPR and ERP: realising a vision of process with IT. Business Process
Management Journal, 2001: p. 258-265.

54
39. Gibson, N., Holland, C., Light, B., Enterprise resource planning: A Business Approach to
Systems Development in procedings of the 32nd Hawaii Internation Conference on
Systems Sciences, 1999. 40. Sieso, D., Agüero, A., ERP en Cifras.

40. Sieso, D., Agüero, A., ERP en Cifras.

41. C. Willard, “ERP’s Promised Lands,” Computerworld, Oct, 1999
42. C.P. Holland and B. Light, “Global Enterprise Resource Planning Implementation,”
Proceedings of the 32nd Hawaii International Conference on System Sciences, pp. 1-10,
1999
43. C.P. Holland and B. Light, “A Critical Success Factors Model For ERP Implementation,”
IEEE Software, pp. 30- 36, May/June 1999
44. C. Casanave, “Business-Object Architectures and
Standards,”http://dbdoc.ajou.ac.kr/cetus/oo_business_ objects.html
45. G. Bylinsky, “The challengers move in on ERP,” Fortune, pp. 306c-313c, Nov 1999
46. G.S. Lawson, “Enterprise Resource Planning(ERP)- Breakthrough or Buzzword?,” Oracle,
p291-295
47. I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Modeling Language Reference
Manual, Addison Wesley, 1999
48. I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Modeling Language User Guide,
Addison Wesley, 1999
49. I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process,
Addison Wesley, 1999
50. J.M. Jezequel, Al.L. Guennec, and F. Pennaneac’h, “Validating Dsistrituted Software
Modeled with the Unified Modeling Language,” The Unified Modeling Language: first
international workshop selected paper/UML ’98 : Beyond the Notation, Springer-Verlag,
pp.365-377, 1999
51. J. W. Ross, “Surprising Facts About Implementing ERP,” IT Pro, IEEE, pp. 65-68, 1999
52. J. Sutherland, “Business Objects in Corporate Information Systems,” ACM Computing
Surveys, Vol 27, No 2, June, 1995
53. J. Arlow, W. Emmerich, and J. Quinn, “Literate Modeling-Capturing Business Knowledge
with the UML,” The Unified Modeling Language: first international workshop
selected paper/UML ’98 : Beyond the Notation, Springer-Verlag, pp.189-199, 1999
54. Joshua, “The Origin and Future of ERP Outsourcing,” http://www.erp-outsourcing.com
55. M. Hitz and G. Kappel, “Developing with UML- Some Pitfalls and Workarounds,” The
Unified Modeling Language: first international workshop selected paper/UML ’98 :
Beyond the Notation, Springer-Verlag, pp.9-20, 1999
56. M. Marshall, “Web application servers give green light to ERP,” Informationweek, CMP
Media Inc., Apr, 1999
57. M.M. Kande, S. Mazaher, O. Prnjat, L. Sacks, and M. Wittig, “Applying UML to Design
an Inter-domain Service Management Application,” The Unified Modeling Language: first
international workshop selected paper/UML ’98 : Beyond the Notation, Springer-Verlag,
pp.200-214, 1999
58. P.l Hruby, “Structuring Specification of Business Systems with UML (with an Emphasis
on Workflow Management Systems,” OOPSLA ’98 Business Object Workshop
IV,http://jeffsutherland.org/oopsla98/pavel.html
59. P. Desfray, “Automation of Design Pattern:Concepts, Tools and Practices,” The Unified
Modeling Language: first international workshop selected paper/UML ’98 : Beyond the
Notation, Springer- Verlag, pp.120-131, 1999
60. P. Kruchten, “Architectural Buleprints - The ‘4+1’ View Model of Software Architecture,”
http://www.rational.com/uml/resources/whitepapers
61. R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan, “A standard for architecture
description,” IBM SYSTEMS JOURNAL, Vol 38, No 1, pp.32-50, 1999
62. R.E. Chalmers, “Small manufacturers seek best ERP fit,” Manufacturing Engineering,

55
 Dearborn, pp. 42-46, Oct 1999
63. R. Malan and D. Bredemeyer, “Functional Requirements and Use case,” 1999
64. S. Buckhout, E. Frey, and J. Nemec Jr, “Making ERP Succeed: Turning Fear into Promise,”
IEEE Engineering Management Review, Strategy and Business, Second Quarter, pp.60-
72, 1999
65. T.F. Gattiker and D.L. Goodhue, “Understanding the Plant Level Costs and Benefits of ERP:
Will the Ugly Duckling Always Turn Into a Swan?,” Proceedings of the 33nd Hawaii
International Conference on System Sciences, pp. 1-10, 2000
66. “Mid-sized Firms Face Rough Road with ERP Adoption,” The Manufacturing Report,
Lionheart Publishing, Inc., May, 1999
67. “Survey of Manufacturing : Meet the Global Factory”, IEEE Engineering Management
Review Spring 1999, http://www.economist.com/
68. Liu, Baolin, Zhongning Wang, and Zhixing Jin. "The effects of punctuations in Chinese
sentence comprehension: An ERP study." Journal of Neurolinguistics 23, no. 1 (January
2009): 66-80. Academic Search Premier, EBSCOhost (accessed November 3, 2009).
69. Su, Yi-fen, and Chyan Yang. "A structural equation model for analyzing the impact of ERP
on SCM." Expert Systems with Applications 37, no. 1 (January 2009): 456-469. Academic
Search Premier, EBSCOhost (accessed November 6, 2009).
70. Sylvestre, Uwizeyemungu, and Raymond Louis. "Exploring an alternative method of
evaluating the effects of ERP: a multiple case study." Journal of Information Technology
(Palgrave Macmillan) 24, no. 3 (September 2009): 251-268. Academic Search Premier,
EBSCOhost (accessed November 6, 2009).
71. Kimura M, Katayama J, Ohira H. Event-related brain potential evidence for implicit change
detection: A replication of Fernandez-Duque et al. (2003). Neuroscience Letters [serial on
the Internet]. (2008, Dec 31), [cited November 9, 2009]; 448(3): 236-239. Available from:
Academic Search Premier.
72. Sudip Chahal, K. M. (2003, March). Deploying ERP on Cost-effective Industry-standard
Servers. Intel Information Technology.
73. E.M. Shehab, M. S. (2004). Enterprise resource planning: An integrative review. Business
Process Management Journal , 359 - 386.
74. Maya Daneva, R. W. (2005). Requirements Engineering for Cross-organizational ERP
Implementation: Undocumented Assumptions and Potential Mismatches. Department of
Computer Science, University of Twente, The Netherlands.
75. Al-Mashari, M., Mudimigh, A., Zairi, M. (2003), "Enterprise resource planning: a taxonomy
of critical factors", European Journal of Operational Research, Vol. 146 pp.352-64.
76. Allen, D. and T. Kern (2001). Enterprise Resource Planning Implementation: Stories of
Power, Politics, and Resistance. IFIP Conference Proceedings: Proceedings of the IFIP
TC8/WG8.2 Working Conference on Realigning Research and Practice in Information
Systems Development: The Social and Organizational Perspective Idaho.USA.
77. Arunthari, S. (2005). Information Technology adoption by companies in Thailand: A study
of Enterprise Resources planning System Usage. Information System, Australia,
University of Wollongong. Doctorate thesis.
78. Basoglu, N., T. Daim and Kerimoglu, O. (2007). Organizational adoption of
enterprise resource planning systems: A conceptual framework." Journal of High
Technology Management Research 18: 73- 97.
79. Botta-Genoulaz, V. and P. Millet (2006). "An investigation into the use of ERP systems
in the service sector." International Journal of
Production Economics 99(1): 202-221.

80. Calisir, F. and F. Calisir (2004). "The relation of interface usability characteristics, perceived
usefulness and perceived ease of use to end - user satisfaction with enterprise resource
planning systems." Computer in Human Behavior 20(505-515).
81. Fisher, M. D. (2006). Staff Perceptions of an Enterprise Resource Planning System

56
 Implementation: A Case Study of three Australian Universities. Queensland Central
Queensland University. PhD.
82. Hellens, L., S. Nielsen and Beekhuyzen, J (2005). Qualitative case studies on
implementation of enterprise wide systems. Hershey, Idea Group Publishing.
83. King, P., R. Kvavik and John,V.(2002). "Enterprise Resource Planning Systems in Higher
Education." EDUCAUSE 22: 1-5.
84. Kositanurit, B, Ngwenyama, O and Osei-Bryson, K (2006). An exploration of factors
that impact individual performance in an ERP environment: an analysis using multiple
analytical techniques. European Journal of Information Systems (2006) 15, 556–568.
85. Kvavik, R., R. Katz, Beecher, K, Caruso, J and King, P (2002). "The Promise and
Performance of Enterprise Systems for Higher Education." EDUCAUSE 4: 5-123.
86. McCredie, J. and D. Updegrove (1999). "Enterprise System Implementations:
Lessons from the Trenches." CAUSE/EFFECT 22(4): 1-10.
87. Mehlinger, L. (2006). Indicators of Successful Enterprise Technology Implementations in
Higher Education Business Morgan state Morgan state University. Ph.D
88. Nielsen, J. (2002). Critical success factors for implementing an ERP system in a
university environment: A case study from the Australian HES. Faculty of Engineering and
Information Technology. Brisbane, Griffith University. Bachelor: 189.
89. Pollock, N. and C. James (2004). "ERP systems and the university as a “unique”
organization." Information Technology & People 17(1): 31-52.
90. Watson, E. and H. Schneider (1999). "Using ERP in education” Communications of AIS
1(9): 12- 24.
91. Ifinedo, P. and N. Nahar (2006). "Quality Impact and Success of ERP Systems: A Study
Involving Some Firms in the Nordic-Baltic Region." Journal of Information Technology
Impact 6(1): 19-46.
92. Szajna, B. and R. Scamell (1993). "The effects of information system user expectations on
their performance and perceptions." MIS Quarterly, (23): 493-516.
93. Alwabel S A, Ahmed A M & Professor Zairi M (2005). “The Evolution of ERP and its
Relationship with E-Business”, Working Paper 05/19, Emm Lane, West Yorkshire BD9 4JL,
UK, E-mail: S.A.Alwabel@Bradford.ac.uk
94. Wilkinson, J. W. (2000) Accounting information systems : essential concepts and
applications, (4th) John Wiley, New York ; Chichester.
95. Romney, M. B. and Steinbart, P. J. (1999) Accounting information systems, (8th) Prentice
Hall, Upper Saddle River, N.J.
96. Bhatt, G. D. (1995), Enterprise Information Systems Integration and Business Process
Improvement: an Empirical Study, Proceedings of the Americas Conference of Information
Systems, August 25-27. Pittsburgh. PA. USA.
97. Vollmann, T. E., Berry, W. L. and Whybark, D. C. (1992) Manufacturing planning and
control systems, (3rd) Irwin Professional Publishing, Chicago ; London.
98. Chung, S. H. and Snyder, C. A. (2000),”ERP adoption: a technological evolution approach”,
International Journal of Agile Management Systems; Bradford, Vol. 2 No. 1, pp. 24-32.
99. Koh, S. C., Jones, M. H., Saad, S. M., Arunachalam, S. and Gunasekaran, A.
(2000),”Measuring uncertainties in MRP environments”, Logistics Information
Management; Bradford, Vol. 13 No. 3, pp. 177-183.
100. Klaus, H., Rosemann, M. and Gable, G. G. (2000),”What is ERP?” INFORMATION
SYSTEMS FRONTIERS, Vol. 2 No. 2, pp. 141-162.
101. Holland, C. P., Light, B. and Kawalek, P. (1999), Beyond Enterprise Resource Planning
Projects: Innovative Strategies for Competitive Advantage, Proceedings of the the 7th
European Conference on Information Systems, Copenhagen Business School:
Copenhagen, Denmark, pp. 288-301.
102. Markus, M. L. and Tanis, C. (2000) The enterprise system experience-from adoption to
success, in Zmud, R.W. (Ed.), Framing the Domains of IT Management: Projecting the
Future Through the Past, Pinnaflex Educational Resources, Inc, Cincinnatti, OH, pp. 173-

57
 207.
103. Kalakota, R. and Robinson, M. (2001) E-business 2.0 : roadmap for success, Addison-
Wesley, Boston, Mass.
104. Hicks, D. A. (1997),”The Manager’s Guide to Supply Chain and Logistics Problem Solving
Tools and Techniques, Part II: Tools, Companies, and Industries”, IIE SOLUTIONS, Vol. 29
No. 10, pp. 24-29.
105. Granlund, M. and Malmi, T. (2002),”Moderate impact of ERPS on management
accounting: a lag or permanent outcome?” Management Accounting Research, Vol. 13 No.
3, pp. 299-322. Hammer, M., Champy, J. and Hammer (1993) Reengineering the
corporation: a manifesto for business revolution, (1st) N. Brealey, c1993, London.
106. Gelinas, U. J., Sutton, S. G. and Oram, A. E. (1999) Accounting information systems,
(4th) South- Western College Pub., c1999, Cincinnati, Ohio ; London.
107. Wallace, T. F. and Kremzar, M. H. (2001) ERP : making it happen : the implementers’
guide to success with enterprise resource planning, Wiley, New York ; Chichester.
108. Hernández, O.E., Hernández, J., Lizandra, C. (2001), “C++ Estandar", ITP Paraninfo.
109. Hernández, O. E (2001). “El Lenguaje Unificado de Modelado”, Working Paper, E-mail:
ehernandez@disca.upv.es
110. Grässle, P., Baumann H., Baumann, P. (2005), “UML 2.0 in Action: A Project-Based
Tutorial”, Packt Publishing, Birmingham, B27 6PA, UK.
111. Chonoles, M.J.,Schardt, J.A.(200x) “UML 2 for Dummies” pendiente
112. Valerio A.A.(2008),”Deploying ideas”,Working Paper”, Epidata Consulting Maipú 521 1er
piso Of. A Ofi: 5031 0060 / 61 www.epidataconsulting.com

58