1. Arquitectura de Software EPICOR
Raúl Galván Rodríguez
UNIVA León.
Arquitectura de Software.
Quinto Cuatrimestre.
Maestría en Ingeniería de Software.
Sergio Ellerbracke.
Junio 4 de 2011.
León, Guanajuato.

2. INTRODUCCION.
El presente trabajo contiene un ensayo referente a la Arquitectura del Software EPICOR,
haciendo referencia principalmente a sus deficiencias, en cuanto a funcionalidad y desempeño en
cuanto al ámbito de Organizaciones Manufactureras debido a que algunas de sus principales
funciones cómo la Planeación de Requerimientos de Materiales principalmente se encuentra aun
en desarrollo y con muy poca funcionalidad además de que no presenta grandes ventajas para los
usuarios finales, así como de su estructura de desarrollo y sus funcionalidades principales,
también de otras funcionalidades cómo en los módulos financieros donde aun se siguen
presentando problemas, debido al soporte para múltiples divisas ya que las unidades que maneja
el sistema normalmente se presentan en dólares.

3. ARQUITECTURA DE SOFTWARE DE EPICOR
EPICOR software ha sido desarrollado bajo la arquitectura (SOA) Arquitectura orientada
a servicios, desarrollado principalmente en .NET, bajo esta arquitectura, obviamente lo que
ofrece mediante estos servicios es la integración de los diferentes ambientes encontrados en
diferentes organizaciones bajo la configuración de SOA, ya que esto ayuda a la colaboración y el
compartimiento de información dentro y fuera de la organización, de modo general EPICOR,
dentro de éste ámbito podremos decir que SOA ayuda a personalizar los procesos de negocios
sin modificar el código fuente, debido a que se encuentra desarrollado en .NET, los servicios
web utilizados son estándar (XML) que se supone en una conexión más fácil entre los software
de negocios, ya que esto permitirá poner las propias reglas del negocio y accesar prácticamente
desde cualquier sitio, además de que esto se combina con Epicor Service Connect “Un punto de
integración central para orquestaciones seguras de flujo de trabajo dentro de las aplicaciones de
Epicor y entre aplicaciones de Epicor y otras aplicaciones ajenas a Epicor”1
esto permite la
integración y el flujo de trabajo constante con todas las aplicaciones de EPICOR y otras
aplicaciones ajenas a éste, permitiendo a los usuarios automatizar y reducir pasos para realizar un
proceso, automatizando también tareas repetitivas mediante éste servicio. Esto podrá sonar
demasiado fácil de operar y muy atractivo para la mayoría de las empresas pero que pasa cuando
éste tipo de desarrollo lo llevamos a un medio productivo, donde los tiempos de respuesta, y
programación de requerimientos, cómo se ofrece dentro de éste sistema ERP “Planificación de
Recursos Empresariales, o simplemente ERP (Enterprise Resource Planning), es un conjunto de
sistemas de información gerencial que permite la integración de ciertas operaciones de una
empresa, especialmente las que tienen que ver con la producción, la logística, el inventario, los
1
EPICOR Software Corporation. (1997-2000). Epicor Service Connect. Recuperado el 15 de Mayo de 2011, de
http://www.epicor.com/lac/Solutions/Pages/ServiceConnect.aspx

4. envíos y la contabilidad“2
, no son del todo funcionales u operativos para la organización, debido
a que en un inicio EPICOR plantea la instalación de un software funcional y eficiente, donde
proponen el esfuerzo para la reducción de costos y aumentar la rentabilidad de la organización,
además de proveer las futuras necesidades de la misma con herramientas bastante llamativas para
la misma, ofreciendo dentro de éste sistema una gran variedad de soluciones que le permitirá a la
organización, programar, planear, ejecutar y monitorear aparentemente toda la organización
desde la compra de materias primas hasta la entrega y facturación del producto final, éste sistema
ofrece una gran variedad de aplicaciones para diferentes empresas, como por ejemplo la industria
Aeroespacial, Automotriz, Maquinaria Industrial, Dispositivos Médicos, Metal Mecánica,
Muebles y Accesorios, por mencionar algunas en las cuales éste sistema ha sido caso de éxito
pero la mayoría de ellas basan sus presupuestos en producción bajo demanda, esto quiere decir
que únicamente producirán lo que ya está vendido o lo que ya existe en un pedido en firme, sin
considerar, producción a futuro o considerar un stock en su inventario para abastecer algún tipo
de sobreventa o casos especiales de venta, en organizaciones de éste rubro, éste tipo de sistemas
causa un gran conflicto debido a que su Herramienta MRP “Materials Requirement Planning es
una técnica que permite a las empresas calcular los requerimientos dependientes a sus elementos,
ya que consiste en el desfasamiento de necesidades de materias primas en función del programa
maestro de producción terminado y del tiempo de entrega de las materias primas y/o
materiales”3
, no es de todo funcional, dado que únicamente está mostrando el faltante de
producción y materias primas y/o materiales para cubrir la venta del mes y no producir más
cantidad de lo que se está presupuestando, esto quiere decir que para estas empresas que además
2
Lanzillotta A. (2004). Definición de ERP. Recuperado el 15 de Mayo de 2011, de
http://www.mastermagazine.info/termino/4908.php
3
Iñiguez A. (Diciembre 2003). Desarrollo del MRP. Recuperado el 17 Mayo de 2011, de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lii/iniguez_a_fj/capitulo4.pdf

5. de producir lo que venderán o se pronostica mantienen cierto tiempo de Stock para atender
sobreventa de algún tipo de producto, no se podrá llevar a cabo debido a la funcionalidad
limitada de éste sistema, EPICOR, ofrece una configuración adicional para éste tipo de
organizaciones, pero a que nos conlleva esto, dado que la organización suponía que esta
herramienta le seria funcional, se encuentra en un conflicto con varios departamentos,
principalmente con el área de compras dado que el sistema no muestra las sugerencias de compra
cómo éste lo previo y teniendo en cuenta un stock en su inventario, ya que únicamente producirá
lo que se presupuesta, esto conlleva a los desarrolladores a buscar una solución que satisfaga las
necesidades de esta operación del sistema, la cual a pesar varios intentos de configuración no
muestra los resultados que sería obvios para un planeador, dado que dentro de esta configuración
se determinan varios aspectos que no se consideran útiles, cómo el tamaño del lote económico, el
tiempo al que se quiere proyectar la producción, mencionando esto, las sugerencias de compra
que muestra el sistema EPICOR no son las adecuadas, ya que ocasionalmente las personas
suelen comparar las sugerencias del sistema con proyecciones que han realizado con algún otro
tipo de sistema o con la ayuda de hojas de cálculo, lo cual suele ser más útil que EPICOR,
además del tiempo que se le invierte en cuanto a la realización de estas tareas, dado que en
EPICOR no permite realizar actividades en segundo plano o programar actividades fuera del
horario de trabajo, es decir que si yo inicio con la ejecución del MRP, éste sistema no me estará
preguntando cuando lo quiero ejecutar si en el horario de trabajo o fuera del horario de trabajo,
además de que esta actividad se ejecutan dentro del horario de trabajo, el total de las terminales
en la organización hacen sus funciones del sistema de manera más deficiente o lenta, es decir
éste proceso de ejecución de MRP disminuye la velocidad de transacciones con las otras
operaciones, a diferencia de otros sistemas cómo lo son SAP, al igual que éste, EPICOR muestra

6. su configuración de Base de Datos en SQL Server, pero a pesar de su Arquitectura Orientada a
Servicios, se puede decir que carece de estos, por ejemplo para realizar algún tipo de prueba con
la misma base de datos, lo ideal sería usar la base de datos actual, la cual contiene los datos
reales, pero para poder realizar esto, dentro de éste sistema se realiza un respaldo de la Base de
Datos colocándola en otra instancia de pruebas, podría sonar lógico utilizarla para realizar unas
pequeñas pruebas, pero si dentro de la misma organización otra área desea realizar pruebas se
tiene que hacer un respaldo con los datos solicitados nuevamente y colocarla en otra instancia, ya
que la parte de pruebas no se encuentra completamente funcional en su totalidad o con todo lo
que se está utilizando del sistema normalmente. En cuanto a confiabilidad del software EPICOR
podremos decir las fallas en éste sistema ERP suelen ser aun muy comunes ya que haciendo un
pequeño recuento de esto, los datos en cuanto al MRP no son precisos además de que la
aplicación suele fallar comúnmente, por ejemplo en una plataforma de Windows XP, el sistema
parece estable, mencionando que cuando éste se suspende la sesión de usuario de Windows, y
reanudar la sesión éste permaneces estable, pero en plataformas cómo Windows Vista y 7 a 32 y
64 bits al momento de reanudar la sesión de usuario el sistema EPICOR muestra un mensaje de
reanudar la sesión de usuario pero al momento de presionar la opción de restablecer éste no
reanuda la sesión por mas que se intente acceder a ella para solucionar esto, hay que salir del
sistema y acceder nuevamente además de otros errores que muestra durante su ejecución,
(figuras 1 a 3), en cuanto a desempeño, EPICOR utiliza bastante recursos del sistema, esto es
debido a que su arquitectura orientada a servicios consume la totalidad de ellos principalmente la
memoria de un equipo en funcionamiento, volviendo al tiempo de respuesta de las aplicaciones
adicionales u otras ajenas a éste dejan de responder al momento de utilizar EPICOR con varias
aplicaciones abiertas de éste, además su tiempo de respuesta es mas tardado en una plataforma

7. Windows XP a diferencia de un Windows Vista y/o 7 a 32 y 64 bits, pero tengamos en cuenta
que los últimos 2 sistemas operativos contienen mayor memoria tanto en RAM cómo en cache.
Figura 1. Mensaje de EPICOR donde indica la reanudación de sesión del sistema.
Figura 2. Mensaje de error del sistema donde indica que la llamada a un objeto no puede ser referenciada.
Figura 3. Mensaje Advertencia donde el sistema indica que no se ha podido reanudar la sesión de usuario y tendrá
que reiniciar la aplicación.
Otro de los aspectos que surgen en cuanto a conectividad dentro de éste sistema es que
por ejemplo, para accesar dentro de una plataforma XP se tiene que acceder en un inicio con el
dominio del servicio (servidor), figura 4, y posteriormente ingresar el nombre de usuario y la
contraseña para poder accesar al sistema, figura 5, además de que durante el acceso se presenta la
carga de lenguajes de aplicación para la generación de las APIS, figura 6, en contraste con una
plataforma de Windows Vista y 7 en donde la configuración únicamente solicita el acceso al
sistema sin tener que logearse con el servidor en un inicio, además de que para poder ejecutar las
herramientas cómo el MRP hay que accesar con otro nombre de usuario y contraseña diferente y
cerrar todas las aplicaciones que se tiene abiertas, para poder ejecutar la aplicación por separado

8. para que no ocasione ningún conflicto, figura 7, y en consecuencia para el área de producción
cuando se quiere realizar la aprobación de un producto en sistema EPICOR, también se requiere
de otro nombre de usuario y contraseña para realizar el movimiento en otro modulo del sistema
ya que aun esta opción no se integra al principal, esto en el Sistema de EPICOR Mes, y logearse
nuevamente, figura 8 y 9, para posteriormente realizar el movimiento en la pantalla de
aprobaciones, figura 10, hay que señalar que esto suele ser bastante laborioso debido a que para
estas funciones hay que tener por lo menos 3 nombres de usuarios y 3 contraseñas para poder
accesar a estas funciones a diferencia de otros sistemas que con un sólo nombre de usuario y
contraseña permiten el acceso a las funciones del sistema en base a los privilegios otorgados, y
las funciones qué estos realizan en el mismo.
Figura 4. Inicio de sesión al servidor antes de iniciar la aplicación, mediante el nombre del servidor y la contraseña
de éste.
Figura 5. Acceso al sistema mediante un nombre de usuario y contraseña.
Figura 6. Generación de los lenguajes de aplicación para la generación de las API’s de EPICOR.

9. Figura 7. Acceso al sistema de generación de MRP para explosionar las materias primas y materiales.
Figura 8. Acceso a EPICOR MES, donde los usuarios de producción realizan el movimiento de probación de
productos.
Figura 9. Pantalla de Acceso al sistema de EPICOR MES para acceder a las opciones de aprobación.
Figura 10. Pantalla principal de EPICOR MES donde los usuarios de producción acceden para realizar la aprobación
de productos.
Dentro de la aplicación financiera de EPICOR, se han detectado algunos principales
problemas de funcionalidad en éste modulo principalmente qué no cuenta con el soporte de

10. múltiples divisas, lo qué significa que en organizaciones donde manejan la compra de productos
en dólares y pago en pesos mexicanos, o viceversa, existe un gran problema, esto porque la
mayoría de los campos utilizados en éste tipo de informes del sistema lo maneja únicamente en
dólares y no cuentan con opción para el intercambio y pago correcto a los clientes, a lo cual esto
genera un conflicto dentro del sistema, pudiera ser el caso en donde la organización factura y
realiza el pago directamente, mediante EPICOR, entonces el proveedor puede recibir una factura
de pago o con un saldo mayor o menor debido a esta problemática de divisas dentro del sistema.
Además de que la generación de costos dentro de la organización no concuerda con los
realizados en otros sistemas elaborados a la medida para la organización, aquí se sugieren dos
alternativas, tratar de pulir detalles dentro de EPICOR para la generación adecuada de estos, o
que los usuarios que cargan tiempos y ejecución de actividades están sobrepasando la línea de
tiempo lo que genera confusión al momento de calcular el costo total de un producto.
A diferencia de otras soluciones de software para organización EPICOR aun está en
proceso de pruebas, muestra o pone en venta alternativas de software que aun no han sido
funcionales en su totalidad para la mayoría de las empresas mexicanas, debido a que manejan
una arquitectura Orientada a servicios, y su objetivo es la producción de un articulo bajo
demanda, a diferencia de otros ERP, que suelen ser funcionales en diferentes ámbitos, cómo la
producción bajo demanda, y tomando en cuenta un inventario de reserva para responder a
sobreventas de un producto, además tomando en cuenta que existen materias primas de difícil
adquisición, ya que esto tendrá cómo fin que la organización produzca en base a estas
adquisiciones de materias primas.

11. CONCLUSIONES
En conclusión podemos EPICOR sigue careciendo de funcionalidad para varias
empresas, y dentro de varias opciones de sus sistema, cómo ya lo hemos mencionado en éste
ensayo, no es un software de mala calidad, sólo que éste ha tenido su éxito en empresas que
producen bajo demanda, sin considerar un inventario para casos especiales, además en la
mayoría de las empresa donde se ha implantado, su objetivo es no manejar inventario extra si no
que producir lo que se venderá o ya está vendido, ya que esto les producirá costos de almacenaje
y espacio en su organización, además de que en otros sistemas cómo SAP ofrecen mejores
alternativas de uso y aplicaciones para diferentes organización y personalizaciones a diferencia
de EPICOR, en donde la personalización es casi inaccesible ya que se tiene una estructura
original y tratar de modificar sería bastante complicado debido a que se tendría que modificar
toda la estructura del sistema para cada organización, a diferencia SAP ofrece el uso de múltiples
personalizaciones para el uso de su sistema, además de que en algunas empresas, han optado por
adquirir SAP con aplicaciones básicas, y que ha funcionado correctamente gracias o su
personalización, y forma de trabajo, también es importante mencionar qué la organización no se
debe de adaptar al software ya que la organización tiene su forma de trabajo, que si bien no es la
mejor pero ha funcionado por bastante tiempo, además de que con la implantación de un sistema
automatizado, se podrán cambiar algunas formas de trabajo pero no la totalidad de realizar sus
procesos, ya que esto implica un costo mayo e incluso más que la implementación de un
software.

12. BIBLIOGRAFIA
EPICOR Software Corporation. (1997-2000). Arquitectura Empresarial Epicor ICE. Recuperado el 16 de
Mayo de 2011, de http://www.epicor.com/lac/Solutions/Pages/ICE-BusinessArchitecture.aspx
EPCIOR Software Corporation. (1997-2000). Arquitectura, Ingeniería y Construcción. Recuperado el 17
Mayo de 2011, de http://www.epicor.com/lac/industries/Services/Pages/Architecture.aspx
EPICOR Software Corporation. (1997-2000). Arquitectura Orientada a Servicios. Recuperado el 16 de
Mayo de 2011, de http://www.epicor.com/lac/Solutions/Pages/Serviceoriented.aspx
EPICOR Software Corporation. (1997-2000). Epicor Service Connect. Recuperado el 15 de Mayo de
2011, de http://www.epicor.com/lac/Solutions/Pages/ServiceConnect.aspx
EPCIOR Software Corporation. (1997-2000). Introducción al Nuevo Lanzamiento de la
Administración de Costos Mejorada y Mayor Satisfacción del Cliente para Impulsar el Crecimiento de
Epicor ERP. Recuperado el 16 de Mayo de 2011, de
http://www.epicor.com/lac/Solutions/Pages/ERP.aspx
EPCIOR Software Corporation. (Marzo 2009). Planeación de Recursos Empresariales sin Límites.
Recuperado el 17 de Mayo de 2011, de http://www.epicor.com/MRCPublic/Epicor-Enterprise-Resource-
Planning-BR-SP-0510.pdf
EPICOR Software Corporation. (2008). EPICOR 9 Application User Guide (2nd Ed.). Irvine, CA: Author
Iñiguez A. (Diciembre 2003). Desarrollo del MRP. Recuperado el 17 Mayo de 2011, de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lii/iniguez_a_fj/capitulo4.pdf
Lanzillotta A. (2004). Definición de ERP. Recuperado el 15 de Mayo de 2011, de
http://www.mastermagazine.info/termino/4908.php
Sosa N. (2008). Novomex Elige Epicor® ERP para Optimizar su Servicio al Cliente. Recuperado el 15 de
Mayo de 2011, de
http://www.evaluandoerp.com/nota-1435-Novomex-Elige-Epicor%C2%AE-ERP-para-Optimizar-su-
Servicio-al-Cliente.html