1.

INTRODUCCIÓN

Los sistemas ERP son programas de aplicación estándar, que soportan la ejecución de
Procesos de negocios. En el contexto de la fabricación, estos procesos de negocio
comprenden áreas bien conocidas como la planificación y el control de la producción, el
inventario sistemas de control y ejecución de la fabricación. Sin embargo, también los procesos
de negocio en otras áreas se han convertido en parte de los sistemas ERP en los últimos diez a
quince años.

Estas áreas son control de calidad, finanzas, recursos humanos, desarrollo de productos,
marketing, ventas, compras y muchos otros.

La sección 2 de este documento ofrece una descripción general de la naturaleza de los

sistemas ERP actuales para la fabricación y la logística.

La importancia de los sistemas ERP en la práctica está aumentando rápidamente. en cada

sucursal de la industria hay muchas empresas en proceso de implantación de estos sistemas.

Esto demuestra que es posible desarrollar una funcionalidad estándar, que puede ser aplicado
en diferentes empresas y en diferentes ramas de la industria. vamos a discutir en este
documento que la academia también debería prestar más atención a ERP. La razón es, que los
sistemas ERP representan el mejor conocimiento explícito en muchos campos de industria.
Además, estos sistemas transmiten rápidamente este mejor conocimiento de su clase, sobre la
tierra Tanto el conocimiento en sí mismo como la forma en que se representa son interesantes
áreas de investigación científica.

La Sección 3 discute la importancia de Sistemas ERP con más detalle.

El rápido aumento de la funcionalidad no es la única razón del éxito de los sistemas ERP en
general o de algunos sistemas ERP en particular. Playa de las nuevas tecnologías papel que
es igual de importante. Por ejemplo, el emergente ROBMS (relacionales sistemas de gestión de
bases de datos) en los años ochenta representa esta nueva tecnología.

Lo mismo se aplica a los sistemas operativos "abiertos" y a la interfaz gráfica de usuario. (GUI)
técnicas. La sección 4 explica el papel de la tecnología en el advenimiento de ERP. Más
específicamente, las consecuencias de la tecnología para las arquitecturas serán explicado.

A pesar del éxito de los sistemas ERP en términos de crecimiento del mercado. todavía hay
considerables problemas en la implementación de sistemas ERP. Razones para que este tallo
no sólo por la complejidad de los sistemas, sino también por el hecho de que las
implementaciones a menudo conducen a reorganizaciones comerciales sustanciales. Este
punto es discutido en la Sección 5. Además, el papel de los métodos de modelado empresarial
es discutido (Sección 6).

Una descripción general de la evolución de ERP también debe contener una ventana en el
futuro. Este artículo argumentará en la Sección 7 que los sistemas ERP se moverán hacia
configuraciones de sistemas débilmente acoplados. En consecuencia, los futuros sistemas ERP
serán menos monolíticos que los sistemas actuales y estos sistemas mostrarán más
interoperabilidad que los sistemas actuales.

Por supuesto, existe un riesgo en predecir el futuro: desafortunadamente, el futuro es más

difícil de predecir que el pasado. Por lo tanto, la discusión sobre este tema debe ser más
prudente. Sin embargo, existen bastantes argumentos a favor de la opinión presentada aquí,
tanto desde la práctica como desde el mundo académico. Finalmente, la Sección 8 presenta
algunas conclusiones.
¿QUÉ ES ERP?

Los años sesenta: soporte de decisiones algorítmicas: programación y MRP El desarrollo de

sistemas de planificación de recursos empresariales comenzó con simples aplicaciones de
control de inventario.

Sistemas como IMPACT de IBM de 1960 fueron destinados a controlar los niveles de
existencias de un gran número de artículos. Estos sistemas pronósticos calculados de la
demanda futura a través de algoritmos avanzados. Basado en estos números de pronóstico, las
aplicaciones determinaron parámetros de pedido tales como existencias de seguridad, puntos
de pedido y tamaños de lote.

En términos generales, el poder de la computadora se utilizó para realizar cálculos en estos

primeros días. Algo más tarde, alrededor de 1965, LAS PRIMERAS APLICACIONES DE
PLANIFICACIÓN Y PROGRAMACIÓN entró en vigor. Una vez más, un paquete de IBM
(CLASS) es un buen ejemplo. Nuevamente, en El enfoque de estos paquetes estaba en los
cálculos avanzados, tal vez siguiendo el éxito de la programación lineal en la década anterior.

A fines de los años sesenta, el concepto de Planificación de Requerimientos de Material (MRP)

(ver Orlicky (1975) o Fogarty et al. (1991). Este concepto se basaba en dos principios.

En primer lugar, se basó en el consiguiente uso de información de fase temporal para calcular
los pedidos. El conocido time-phaded Las representaciones de MRP se basan en la
representación en fases temporales de todo el material requisitos y representación en fases
temporales de los recibos programados.

El MRP, La lógica de compensación y cálculo del tamaño de los lotes conduce entonces a un
plan por fases para la liberación de pedidos.

Este uso sistemático de representaciones de fases temporales era casi imposible en sistemas
manuales anteriores. Por lo tanto, los cálculos de MRP emplearon la computadora capacidad
de cálculo y memoria.

El segundo principio detrás de MRP es el uso inteligente de la lista de materiales (BoM). El

BoM representa la forma en que la fabricación posterior se superan etapas cuando se
transforman las materias primas en productos terminados.

El BoM se usó para asegurarse de que los cálculos de planificación de materiales no fueran
iterativos, y que usaron la potencia de la computadora de manera eficiente.

Todas estas primeras aplicaciones tienen en común que utilizan TI para fines algorítmicos.

cálculos de una manera que se centra en la eficiencia. se debe notar que el procesamiento de
transacciones todavía era en gran medida manual en los años sesenta. Estas actividades
fueron
basado en archivos en papel clasificados con entidades como pedidos, artículos con datos de
inventario, o cuentas por cobrar. La computadora se utilizó principalmente para realizar
clasificaciones más grandes operaciones con entrada basada en tarjetas pWlched.
Gradualmente, más funcionalidad fue agregado, pero los roles de varios departamentos
(Ventas, Producción, Compras, Finanzas, Calidad, HRM, etc.) permanecieron sin cambios.

Estos eventos: soporte en línea de procesos de negocio y bases de datos: MRPII Estos ventos
trajeron un cambio sustancial, porque el apoyo integrado de las empresas procesos se hicieron
posibles. Escritores como Blumenthal. (1969) hicieron un llamado a arquitecturas que
combinarían soporte de decisiones, procesamiento de transacciones y aplicaciones de
información de gestión en un todo integrado. se hizo realidad, gracias a dos innovaciones
tecnológicas.

La primera innovación fue la cabeza de un procesamiento en línea a través de terminales VCR.

El procesamiento en línea mejoró la eficiencia de entrada de datos porque el aspecto humano
de entrada de datos mejorada y el aspecto técnico mejorado. Por lo tanto, la empresa
aplicaciones como entidad de pedido de ventas, reenvío, pedidos y facturación se convirtieron
posible.

La segunda innovación ha sido el avance de los paquetes estándar para gestión de bases de
datos. Las bases de datos son importantes porque permiten que las aplicaciones cruzar los
límites de las áreas funcionales. Por ejemplo, en el momento de entrar en un el pedido de
venta, las reservas para la entrega se reservan en el área de logística y el futuro las cuentas
por cobrar se registran en el sistema de contabilidad financiera.

las reservas eran difíciles antes cuando cada departamento era una empresa desarrollaron sus
propios sistemas. La combinación de procesamiento de transacciones en línea y base de datos
de módem sistemas de gestión crearon sistemas de información empresarial. Estos sistemas
pavimentaron el camino para BPR. porque cruzaron fronteras funcionales. Pero al mismo
tiempo
estos sistemas no aplicaron BPR, porque muchos sistemas crecieron más o menos armonios a
mediante la integración ad-hoc de aplicaciones funcionales.

En la fabricación, estos sistemas de información comercial se conocieron como Sistemas de

planificación de recursos de fabricación (MRPII). elegido, porque indicaba la continuidad de
MRP a MRP II. extensión adecuada en la toma de decisiones para la fabricación de productos
estandarizados, porque se presta la debida atención a la planificación de capacidad y la
programación maestra en MRP II. Esto es bien conocido en la comunidad de profesionales y
científicos en Manejo y control de la producción. Pero desde la perspectiva de las aplicaciones
de TI, la diferencia no radica tanto en el apoyo a las decisiones ampliado. Más bien, la
innovación es apoyo a los procesos de negocio de forma integrada.

A finales de los setenta y principios de los ochenta, el MRPII era casi sinónimo de control y
panoramización de la producción, al menos en los EE. UU. practicantes, en particular de
Toyota (ver Shingo (1985), y European academics como Burbidge (1989) criticó el concepto
MRP para la planificación y el control, pero ese no es el punto aquí. Desde un punto de vista de
TI, el problema es ese estándar Podrían diseñarse paquetes de software.

Este hecho es a la vez sorprendente y trivial. Es sorprendente, por un lado, porque mucha
gente no puede creer que industrias tan diferentes como la automotriz y los muebles podrían
regirse por los mismos tipos de procesos comerciales. cruzada, sin embargo, cambió esta
forma de pensar en los EE. IBM-mainframes) y MAPICS (para minicomputadoras IBM) y
muchos otros
reclamó aplicabilidad universal para su soporte de procesos de negocio con referencia al
MRPII.

Por otro lado, es trivial que llegue el software estándar, porque en la propiedad más
característica del software es el hecho de que los costes variables de otro copy are zero.'Esto
explica el éxito inicial de los paquetes MRPII

Los
ochenta:másfuncionalidadensoftwareestándarpara
cliente-servidor
arquitecturas
 El software estándar se puede expandir en
funcionalidad, porque el desarrollo
muchos clientes recuperan las inversiones. Y la
necesidad de más funcionalidad
es casi infinito. Por lo tanto, los paquetes MRP-II
se expanden rápidamente con funcionalidad
para las novedades de las empresas de
fabricación, como la gestión de activos fijos, la
tienda
plantaplanificaciónycontrol,distribución,transport
e,servicio,financiero
servicios, EDI, seguimiento y localización,
gestión de datos de productos, etc. (N.B. Aunque
bastantes paquetes se arraigaron en MRP en los
años ochenta, también hubo paquetes
que provino de aplicaciones financieras,
aplicaciones de control de calidad u otras
áreas. Por motivos de simplicidad, no
ampliaremos estos otros campos).
El aumento de la funcionalidad en los paquetes
de software estándar conduce a un aumento
en el número de parámetros necesarios para
"sintonizar" el paquete a un
ambiente.
 La necesidad de aumentar la funcionalidad creó
más complejidad que la mayoría
arquitectura podía soportar a finales de los años
ochenta. Por ejemplo, la necesidad de soportar
La fabricación impulsada por el cliente no se
incorporó fácilmente en los sistemas l\1RP (ver
Wortmannetal. (1997). Del mismo modo, los
requisitos de las industrias de procesos (ver Van
Rijn, Schynseta 1.(1993» o la fabricación
repetitiva (ver Shingo (1985» no son
fáciles de incorporar. Pero especialmente la
integración de soluciones logísticas

variasplantasyalmacenesdentrodeunaempresaaum
entaronlosrequisitos.Estos
las aplicaciones multisitio causan un aumento
drástico de la complejidad.
hecho de que en aplicaciones multisitio casi todas
las actividades pueden implementarse
centralmente o localmente por sitio. Aparte de
eso, cada actividad local puede ser
implementado de manera diferente en diferentes
sitios. Para cubrir todas estas posibilidades, el
el número de parámetros aumentó drásticamente.
 tiempos de implementación. Esto se desarrolla en
la Sección 5.

Paralelamente,hubouncambiosustancialentecnolog
ía.Enhardware,ladominante
La posición de los mainframes no solo se vio
amenazada por las minicomputadoras, sino
especialmente
por arquitecturas de dos niveles cliente-senrer
(CS). Estos consisten en redes de
computadoras, generalmente con uno o más
servidores de base de datos en el corazón y la
aplicación
clientes conectados. Las arquitecturas de
búsqueda permitieron reducir el tamaño de los
mainframes, mientras
reducir los costos de inversión y operación.
Estrechamente relacionado, hubo un cambio en la
tecnología de sistemas operativos
sistemas abiertos. Especialmente el sistema
operativo UNIX era adecuado para ejecutar

diferentestiposdehardware.Creóunmercadoparasof
twaredeaplicación
 independiente del hardware, lo que impulsó la
penetración del estándar
software con una arquitectura CS.
La combinación de la arquitectura CS con
aplicaciones multisitio abre el
posibilidad de operar los principales procesos
comerciales tanto de forma centralizada como
manera descentralizada. Las particiones de la
base de datos pueden convertirse en propiedad
local.
hace posible implementar sistemas en un sitio por
secuencia.
las bases de datos locales deben interpretarse
como partes de un todo conceptualmente
integrado.
Conceptualmente, la solución cliente-servidor
sigue siendo una solución basada en un único
esquema de base de datos con una representación
explícita del esquema multisitio
base de datos.
Los noventa: GUl, Windows, Enterprise
Modeling y comercio electrónico
Aunque los requisitos para una mayor
funcionalidad seguían siendo una presión sobre el
ERP
proveedores, los desarrollos más llamativos no
han estado en la funcionalidad.
Más bien, la apariencia exterior y la sensación de
los paquetes ERP han cambiado
considerablemente.
Muy relacionado, se actualizó la arquitectura.
Finalmente, se agregaron herramientas
para dominar la complejidad del diseño, la
implementación y el mantenimiento.
Los requisitos para una interfaz de usuario
gráfica moderna estaban bajo la guía de UNIX
por el estándar OSF-Motif a principios de los
noventa. Sin embargo, el dominio del mercado
Microsoft pronto obligó a los proveedores de
ERP a lanzar interfaces gráficas de usuario que
cumplen con
MicrosoftWindows. La presión para la interfaz
gráfica de usuario de módem conduce a lo que se
denomina
arquitectura cliente-servidor. En esta arquitectura,
los servidores de la base de datos son
conectado a los clientes de la aplicación de la
misma manera que en la arquitectura CS de dos
niveles.
 Sin embargo, estos clientes de aplicaciones
desempeñan el papel de un servidor de
aplicaciones para el usuario.
programas de interacción con GUI que se ejecutan
en una PC. Hay dos variantes de esto
arquitectura. La llamada arquitectura fatclient
requiere una funcionalidad considerable
a la PC. La llamada arquitectura de cliente
delgado solo toma el usuario
interacción a la PC, y deja toda la funcionalidad
de la aplicación con la aplicación
servidor.
La arquitectura de los sistemas ERP no se vio
más influenciada por el requisito
para la funcionalidad del flujo de trabajo. En el
mundo de la oficina fuera del ERP, la noción de
la funcionalidad del flujo de trabajo fue bastante
bien recibida.
funcionalidad ofrece la posibilidad de monitorear
el flujo de casos en una oficina en gran medida
de la misma manera que se puede seguir el flujo
de órdenes de trabajo en el piso de una
fábrica. Además, las herramientas de flujo de
trabajo permiten a los clientes definir las
actividades
 realizado para un "caso" de manera explícita y
cambiante.
El crecimiento de la funcionalidad ERP como se
describe anteriormente es principalmente
soporte del mundo de la oficina. Por lo tanto, la
gestión del flujo de trabajo es lógica
requisito. Además, bastante funcionalidad de los
sistemas ERP es, de hecho, significa
para crear flexibilidad en las actividades a
realizar, al igual que en los sistemas de flujo de
trabajo.
Por lo tanto, los proveedores de ERP crearon
soluciones de flujo de trabajo en sus sistemas.
las soluciones de flujo de trabajo tienen la
capacidad de convertirse en una capa
independiente de middleware
aliviar al programador de la aplicación de la
necesidad de prever y definir todo
flujos de trabajo. De esta manera, la
funcionalidad del flujo de trabajo se puede
comparar con la
funcionalidad que ofrece un DBMS.
Los flujos de trabajo también pueden
interpretarse como una forma explícita de
representar el negocio
 procesos. Como explicaremos en la Sección 5, la
implementación de sistemas ERP
requiere a menudo una documentación explícita
de los procesos de negocio y
estructuras. Por lo tanto, los sistemas ERP y las
herramientas de modelado empresarial se vuelven
estrechamente
conectado.
Finalmente, la década de los noventa muestra el
rol emergente de internet y el comercio
electrónico.
El comercio electrónico requiere de los
proveedores de ERP no solo que las aplicaciones
sean
estar habilitado para Internet, pero también debe
rediseñar estas aplicaciones para su uso por
clientes remotos. Las arquitecturas con clientes
delgados tienen una ventaja aquí.
argumentan en la Sección 6, que el futuro de ERP
será moldeado por los requisitos de
conectividad

3¿SERÁ IMPORTANTE?
 Como se argumenta en la introducción, hoy en
día los sistemas ERP parecen estar en todas
partes.
¿Por qué? En primer lugar, el software estándar
es de hecho una solución costosa para
empresas, en comparación con el mantenimiento
de información local
sistemas. Dicho de otra manera, el mantenimiento
de estos sistemas
extremadamente caro. Hay básicamente dos
razones para esto.
Por un lado, surgen nuevas tecnologías, que
deberían incorporarse en
sistemas de información si las empresas quieren
permanecer en el negocio.
hoy en día puede permitirse manejar procesos
comerciales como la entrada de pedidos de
clientes en
manual. El pasado era simplemente demasiado
lento e ineficiente.
la automatización de la oficina es hoy evidente,
como un teléfono. La siguiente sección
analiza el papel de las nuevas tecnologías.
Por otro lado, el software estándar incorpora las
mejores soluciones para un
 amplio espectro de procesos empresariales. Por lo
tanto, adoptar un software estándar
la solución es una forma relativamente barata de
transmitir conocimientos profesionales a todos los
interesados
de una organización. Se evita reinventar la rueda.
En segundo lugar, la adopción de paquetes de
software estándar puede conducir a una especie de
racionalización. Allana el camino para BPR y es
un medio eficiente para implementar
BPR. Allana el camino para BPR porque la
implementación de ER requiere cerrar
examen de muchos procesos comerciales, que de
todos modos es necesario para un BPR
proyecto. E incluso sin un proyecto BPR formal,
una implementación de ER a menudo
lleva a menos pasos en los procesos de negocio y
menos paredes en las organizaciones funcionales
(ver Champy (1997).
En tercer lugar, los sistemas ERP se pueden
utilizar en estrecha conexión con unidades de
calidad, como
ISO9000. Debido al hecho de que todos los
procesos comerciales deben documentarse,
 hay una conexión lógica aquí. Pero este punto
puede ser explotado mucho más, si
se emplean herramientas de modelado
empresarial apropiadas. Volveremos a este punto
en
Sección 5.
¿Es el ERP integral? Ciertamente no. En el
campo original de la decisión algorítmica
mientras tanto, existen sistemas de planificación
avanzados para el control de la planta
y la planificación de la cadena de suministro que
se superponen al ERP. En entornos de oficina
para profesionales, como en los departamentos de
ingeniería, hay TIC dedicadas
soluciones como CAD y PDM. Para el trabajo
colaborativo, el software de grupo está
emergiendo.
Para los representantes de ventas, el software de
interacción con el cliente madura.
en.
¿Es ERP preparado para el futuro? Es decir, una
inversión en ERP durará unos cinco o diez
años? La respuesta es probablemente "sí" para los
procesos internos.
colaboraciónorganizacionalexisteunaduda.Elescen
arioesbozadoenlaSección
6tal vez convierta la duda en una "vez" prudente
¿Es ERP realmente barato y flexible? El software
en sí mismo es barato, sin duda.
los costos de implementación son considerables,
como se discutirá en la Sección 5. Hay
Argumentaremos que el software como se
entrega es flexible, pero el software como
implementado no es.
¿Seguirá siendo importante el ER? ¡Por supuesto!
procesos empresariales y bases de datos.
organizaciónsin ella¡

4 EL ROL DE LA TECNOLOGÍA
En la discusión anterior, el papel de las "ondas"
tecnológicas ya ha sido
tocados en varios lugares. En esta sección,
destacaremos este rol y discutiremos el

latecnologíaactualolaenmásprofundidad.Latecnolo
gíacambiaendiferentesniveles.
Hablando en bruto, los niveles son: hardware,
sistemas operativos y comunicación
 estándares, middleware y herramientas para el
desarrollo de aplicaciones.
Hardware
El advenimiento del procesamiento en línea en
los años setenta creó una revolución en los
negocios
sistemas de información, como se describe en la
Sección 2.
minicomputadoras, PC y redes de comunicación
de alta velocidad. Otro hardware
innovaciones como códigos de barras, teléfonos
móviles y LAN no se describen, pero
ha tenido un impacto considerable en campos
relacionados.
Sistemas operativos y estándares de
comunicación
Una vez más, el papel de los sistemas operativos
abiertos como Unix ha sido considerable en
el pasado. Ellos crearon un simple estándar de
facto que hizo programas de aplicación
portable.WindowsNT juega el mismo papel hoy
en día.Comunicación
estándares como Corba o DCOM tienen un efecto
similar en las interfaces entre
programas de aplicación.
 L
software intermedio
El término "middleware" es un nombre colectivo
para los sistemas de gestión de bases de datos,
software de comunicación (p. ej., TCPIIP),
gestión de seguridad, controladores de GUI,
herramientas de monitoreo y optimización de
hardware, y muchas otras piezas de software
que puede ser utilizado por programas de
aplicación en tiempo de ejecución. En la sección
2, hemos visto
que las bases de datos y la GUI tuvieron un gran
impacto en los sistemas ERP.
la tecnología es otro ejemplo.
Herramientas de desarrollo de aplicaciones
Probablemente las tecnologías más importantes
son herramientas que simplifican la vida del
programador de aplicaciones, las llamadas
herramientas en minúsculas.
lenguajes de programación de nivel superior y
generadores de código, bibliotecas con utilidades,
depuradores, documentación y herramientas de
prueba, servicios reutilizables, repositorio
gestión, etc
 Todas estas tecnologías han tenido un impacto
considerable en los sistemas ERP.
una de las principales razones para la mejora de
la productividad a través de ERPi es la
a fondo de las nuevas tecnologías. Esta es
también una de las razones por las
los sistemas no se pueden mantener, como se
argumentó en la sección anterior.
Además, los proveedores de ERP visionarios e
innovadores son los proveedores que adoptan
nuevas tecnologías de manera constante y en
estrecha relación con su etapa de madurez.
surge la tecnología, debe incorporarse en el
producto ERP. Sin embargo, cuando
se establecen estándares y se ofrecen
componentes especializados maduros, el ERP
los vendedores también deben estar preparados
para comprar la nueva tecnología en lugar de
continuar
construir componentes por sí mismos. Sin duda,
Internet y la orientación a objetos
tener un impacto considerable en el futuro
cercano

5EL DIFICULTAD DE IMPLEMENTACIÓN

 A pesar del crecimiento de las ventas de licencias
de ERP, la implementación de sistemas ERP es
.a menudo un proceso engorroso, especialmente
en organizaciones grandes.
los gastos que cubren el software y el hardware
juntos son menores que los gastos
para consultoría y soporte, en implementaciones
más grandes.
también considerable. Hay muchas razones para
esto.
En primer lugar, está la complejidad del software
ERP.
Sección 2, hay muchos parámetros que deben
iniciarse cuando se implementa el estándar
software. Hay miles de software que deben
iniciarse antes de la implementación de
se finaliza un gran sistema (Bancrofte.a.(1997».
+ Más específicamente, la flexibilidad del
software permite muchas formas diferentes de
respaldar los procesos comerciales. Pero el
reverso de la flexibilidad es la complejidad.
Miles de parámetros son extremadamente
difíciles de dominar. Por lo tanto, varios
se han propagado enfoques hacia el soporte de la
configuración de parámetros.
 Los enfoques van desde el uso de inteligencia
artificial (sistemas expertos,
basado en el razonamiento) a través del uso de
plantillas (ajustes de parámetros específicos para
ciertos
mercados verticales) al uso de herramientas de
modelado empresarial para establecer parámetros.
Los enfoques de modelado empresarial suelen
describir los procesos de negocio y el control
estructuras en varios niveles de detalle. La idea es
que la configuración de parámetros se pueda
vinculados a estas descripciones ("modelos"). En
la siguiente sección, por lo tanto,
Elaborar el modelado empresarial en el contexto
de la implementación.
C, · · En segundo lugar, la implementación de ER
requiere una cantidad considerable de
capacitación.
(Los usuarios finales necesitan una formación
intensiva y una cantidad limitada de funciones,
pero
los usuarios y otros (¡consultores!) necesitan una
formación considerable en muchos aspectos de
software empaquetado.
 En tercer lugar, la implementación de ER Pi a
menudo se combina con BPR (consulte la Sección
3).
En el mundo actual, esto significa que la
organización funcional se reemplaza en parte por
una
organización más orientada a los flujos de trabajo
de la empresa.
cambio de los llamados silos funcionales en las
organizaciones hacia las unidades de negocio
a menudo va junto con la implementación de
ERPi (consulte Appleton (1997).
no está claro si este cambio organizacional es un
factor de costo importante, lo que
finalmente desaparecer.
En cuarto lugar, un importante impulsor de costos
de las implementaciones de ER es el hecho de que
adaptaciones no son fáciles. Por lo tanto, algunos
proveedores proporcionan en una empresa
herramientas de sistema de modelado para
describir los cambios planificados en la
implementación (ver
siguiente sección). Sin embargo, la flexibilidad
de la implementación inicial no es fácil
 mantenido cuando un sistema está en
funcionamiento. Muchas alternativas que son
la opción en la implementación inicial no puede
verse como una opción posterior.
Una de las razones es que una nueva
configuración de parámetros puede conducir a una
diagrama de estructura de datos. Esto requiere
que se escriban programas de conversión
específicos, en
para poder continuar con el uso de datos
históricos. Pero una razón más importante es
el hecho de que diferentes versiones de
programas de aplicación relacionados en una suite
ERP
no cooperar. Incluso dentro de la misma suite
ERP, todos los usuarios de los programas de
aplicación
tiene que usar la misma versión de cualquier
aplicación.
Inaceptable en el futuro cercano

6MODELIZACIÓN EMPRESARIAL
Desde los inicios de la fabricación integrada por
computadora se ha argumentado que
 el modelado de procesos de negocio y soluciones
ICf es la única manera de dominar
complejidad. El término modelado tiene muchos
significados.
discusión, técnicas como IDE para SADT fueron
precursores de esfuerzos como
CIMOSA(1993)oARISSeeScheer(1994».

Elbásicodelmodeladoempresarialesunacombinació
ndepoderosaexpresiónde
requisitos comerciales con precisión. Poderosa
expresión de negocios
ha sido perseguido por una potente descripción
de los procesos de negocio y
recursos. Por ejemplo, los procesos comerciales
se pueden describir en varios niveles de
detalles y se pueden representar gráficamente.
Los recursos se pueden modelar mediante datos
complejos

estructuras.frecisiónsehaobtenidomedianteformali
smoscomoPetri-netsoUMLas
lenguaje de modelado de objetos. Sin embargo, el
objetivo de generar código
las descripciones aún no son prácticas.
 El objetivo de las arquitecturas de referencia
empresarial (ver Williamsetal. (1994),
CEN/CELENEC(1994) apoya no sólo las
descripciones de los sistemas de TIC en sus
contexto empresarial, sino también para apoyar el
proceso de diseño como tal.
Los paquetes ERP, las arquitecturas de referencia
requieren una adaptación porque el negocio
conocimiento a especificar, ya está disponible en
el paquete. Por lo tanto, el
la naturaleza del modelado empresarial cambia de
una actividad única a una
modificar-la-actividad-de-la-plantilla..
Herramientas de modelado empresarial como el
conjunto de herramientas ARIS (Scheer, 1994) o
el de Baan

DynamicEnterpriseModeler(VanEsandPost(1996»
arecontributing
considerablemente al esfuerzo de implementación
de los sistemas ERP.
el modelado se está aplicando a gran escala y la
experiencia se captura a través de